Научная электронная библиотека

Монографии, изданные в издательстве Российской Академии Естествознания

ТЕХНОЛОГИЯ РАЗРАБОТКИ ПРИКЛАДНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Соловьев С. В., Цой Р. И., Гринкруг Л. С.,

МЕТОДОЛОГИЯ ПРОЕКТИРОВАНИЯ ПО

Методологии, технологии и инструментальные средства проектирования ПО составляют основу проекта любой информационной системы (ИС). Методология реализуется через конкретные технологии и поддерживающие их стандарты, методики и инструментальные средства, которые обеспечивают выполнение процессов ЖЦ. Технология проектирования

Технология проектирования определяется как совокупность трех составляющих:

 пошаговой процедуры, определяющей последовательность технологических операций проектирования;

 критериев и правил, используемых для оценки результатов выполнения технологических операций;

 нотаций (графических и текстовых средств), используемых для описания проектируемой системы.

Технологические инструкции, составляющие основное содержание технологии, должны состоять из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций.

Технология проектирования, разработки и сопровождения ИС должна удовлетворять следующим общим требованиям:

 должна поддерживать полный ЖЦ ПО;

 должна обеспечивать достижение целей разработки ИС с заданным качеством и в установленное время;

 должна обеспечивать возможность выполнения крупных проектов в виде подсистем (т.е. возможность декомпозиции проекта на составные части, разрабатываемые группами исполнителей ограниченной численности с последующей интеграцией составных частей);

 должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;

 должна обеспечивать минимальное время получения работоспособной информационной системы;

 должна предусматривать возможность управления конфигурацией проекта, ведения версий проекта и его составляющих, возможность автоматического выпуска проектной документации и синхронизацию ее версий с версиями проекта;

 должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (СУБД, операционных систем, языков и систем программирования);

 должна быть поддержана комплексом согласованных CASE-средств, обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ.

Применение любой технологии проектирования, разработки и сопровождения ИС в конкретной организации и конкретном проекте невозможно без выработки ряда стандартов (правил, соглашений), которые должны соблюдаться всеми участниками проекта. К таким стандартам относятся следующие:

 стандарт проектирования;

 стандарт оформления проектной документации;

 стандарт пользовательского интерфейса.

Стандарт проектирования должен устанавливать:

 набор необходимых моделей (диаграмм) на каждой стадии проектирования и степень их детализации;

 правила фиксации проектных решений на диаграммах, в том числе: правила именования объектов (включая соглашения по терминологии), набор атрибутов для всех объектов и правила их заполнения на каждой стадии, правила оформления диаграмм, включая требования к форме и размерам объектов;

 требования к конфигурации рабочих мест разработчиков, включая настройки операционной системы, настройки CASE-средств, общие настройки проекта;

 механизм обеспечения совместной работы над проектом, в том числе: правила интеграции подсистем проекта, правила поддержания проекта в одинаковом для всех разработчиков состоянии (регламент обмена проектной информацией, механизм фиксации общих объектов), правила проверки проектных решений на непротиворечивость.

Стандарт оформления проектной документации должен ус- танавливать:

 комплектность, состав и структуру документации на каждой стадии проектирования;

 требования к ее оформлению (включая требования к содержанию разделов, подразделов, пунктов, таблиц), правила подготовки, рассмотрения, согласования и утверждения документации с указанием предельных сроков для каждой стадии;

 требования к настройке издательской системы, используемой в качестве встроенного средства подготовки документации;

 требования к настройке CASE-средств для обеспечения подготовки документации в соответствии с установленными требованиями.

Стандарт интерфейса пользователя должен устанавливать:

 правила оформления экранов (шрифты и цветовая палитра), состав и расположение окон и элементов управления;

 правила использования клавиатуры и мыши;

 правила оформления текстов помощи;

 перечень стандартных сообщений;

 правила обработки реакции пользователя. CASE-средства

Общая характеристика и классификация

Современные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО.

Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.

Обычно к CASE-средствам относят программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО и обладающее следующими основными характерными особенностями:

 мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком;

 интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС;

 использование специальным образом организованного хранилища проектных метаданных (репозитория).

Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты:

 репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость;

 графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС;

 средства разработки приложений и генераторы кодов;

 средства конфигурационного управления;

 средства документирования;

 средства тестирования;

 средства управления проектом;

 средства реинжиниринга.

Современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit), и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:

 применяемым методологиям и моделям систем и БД;

 степени интегрированности с СУБД;

 доступным платформам.

Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:

 средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works));

 средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных;

 средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV;

 средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun;

 средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций.

Вспомогательные типы включают:

 средства планирования и управления проектом (SE Companion, Microsoft Project и др.);

 средства конфигурационного управления (PVCS (Intersolv));

 средства тестирования (Quality Works (Segue Software));

 средства документирования (SoDA (Rational Software)). Методология RAD

Одним из возможных подходов к разработке ПО является методология быстрой разработки приложений RAD (Rapid Application Development). Под этим термином обычно понимается процесс разработки ПО, содержащий три элемента:

 небольшую команду программистов (от 2 до 10 человек);

 короткий, но тщательно проработанный производственный график (от 2 до 6 мес.);

 повторяющийся цикл, при котором разработчики, по мере того, как приложение начинает обретать форму, запрашивают и реализуют в продукте требования, полученные через взаимодействие с заказчиком.

Команда разработчиков должна представлять из себя группу профессионалов, имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с использованием CASE-средств. Члены коллектива должны уметь трансформировать в рабочие прототипы предложения конечных пользователей.

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

 фаза анализа и планирования требований;

 фаза проектирования;

 фаза построения;

 фаза внедрения. На фазе анализа и планирования требований пользователи системы определяют функции, которые она должна выполнять, выделяют наиболее приоритетные из них, требующие проработки в первую очередь, описывают информационные потребности. Определение требований выполняется в основном силами пользователей под руководством специалистов-разработчиков. Ограничивается масштаб проекта, определяются временные рамки для каждой из последующих фаз. Кроме того, определяется сама возможность реализации данного проекта в установленных рамках финансирования, на данных аппаратных средствах и т.п. Результатом данной фазы должны быть список и приоритетность функций будущей ИС, предварительные функциональные и информационные модели ИС. На фазе проектирования часть пользователей принимает участие в техническом проектировании системы под руководством специалистов-разработчиков.

CASE-средства используются для быстрого получения работающих прототипов приложений. Пользователи, непосредственно взаимодействуя с ними, уточняют и дополняют требования к системе, которые не были выявлены на предыдущей фазе. Более подробно рассматриваются процессы системы. Анализируется и, при необходимости, корректируется функциональная модель. Каждый процесс рассматривается детально. При необходимости для каждого элементарного процесса создается частичный прототип: экран, диалог, отчет, устраняющий неясности или неоднозначности. Определяются требования разграничения доступа к данным. На этой же фазе происходит определение набора необходимой документации. После детального определения состава процессов оценивается количество функциональных элементов разрабатываемой системы и принимается решение о разделении ИС на подсистемы, поддающиеся реализации одной командой разработчиков за приемлемое для RAD-проектов время - порядка 60-90 дней. С использованием CASE-средств проект распределяется между различными командами (делится функциональная модель). Результатом данной фазы должны быть:

 общая информационная модель системы;

 функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;

 точно определенные с помощью CASE-средств интерфейсы между автономно разрабатываемыми подсистемами;

 построенные прототипы экранов, отчетов, диалогов.

Все модели и прототипы должны быть получены с применением тех CASE-средств, которые будут использоваться в дальнейшем при построении системы. Данное требование вызвано тем, что в традиционном подходе при передаче информации о проекте с этапа на этап может произойти фактически неконтролируемое искажение данных. Применение единой среды хранения информации о проекте позволяет избежать этой опасности.

В отличие от традиционного подхода, при котором использовались специфические средства прототипирования, не предназначенные для построения реальных приложений, а прототипы выбрасывались после того, как выполняли задачу устранения неясностей в проекте, в подходе RAD каждый прототип развивается в часть будущей системы. Таким образом, на следующую фазу передается более полная и полезная информация. На фазе построения выполняется непосредственно сама быстрая разработка приложения. На данной фазе разработчики производят итеративное построение реальной системы на основе полученных в предыдущей фазе моделей, а также требований нефункционального характера. Программный код частично формируется при помощи автоматических генераторов, получающих информацию непосредственно из репозитория CASE-средств. Конечные пользователи на этой фазе оценивают получаемые результаты и вносят коррективы, если в процессе разработки система перестает удовлетворять определенным ранее требованиям. Тестирование системы осуществляется непосредственно в процессе разработки.

После окончания работ каждой отдельной команды разработчиков производится постепенная интеграция данной части системы с остальными, формируется полный программный код, выполняется тестирование совместной работы данной части приложения с остальными, а затем тестирование системы в целом. Завершается физическое проектирование системы:

 определяется необходимость распределения данных;

 производится анализ использования данных;

 производится физическое проектирование базы данных;

 определяются требования к аппаратным ресурсам;

 определяются способы увеличения производительности;

 завершается разработка документации проекта.

Результатом фазы является готовая система, удовлетворяющая всем согласованным требованиям. На фазе внедрения производится обучение пользователей, организационные изменения и, параллельно с внедрением новой системы, осуществляется работа с существующей системой (до полного внедрения новой). Планирование и подготовка к внедрению должны начинаться заранее, как правило, на этапе проектирования системы. Приведенная схема разработки ИС не является абсолютной. Возможны различные варианты, зависящие, например, от начальных условий, в которых ведется разработка: разрабатывается совершенно новая система; уже было проведено обследование предприятия и существует модель его деятельности; на предприятии уже существует некоторая ИС, которая может быть использована в качестве начального прототипа или должна быть интегрирована с разрабатываемой.

Следует отметить, что методология RAD, как и любая другая, не может претендовать на универсальность, она хороша, в первую очередь, для относительно небольших проектов, разрабатываемых для конкретного заказчика. Если разрабатывается типовая система, которая не является законченным продуктом, а представляет собой комплекс типовых компонент, централизованно сопровождаемых, адаптируемых к программно-техническим платформам, СУБД, средствам телекоммуникации, организационно-экономическим особенностям объектов внедрения и интегрируемых с существующими разработками, то на первый план выступают такие показатели проекта, как управляемость и качество, которые могут войти в противоречие с простотой и скоростью разработки. Для таких проектов необходимы высокий уровень планирования и жесткая дисциплина проектирования, строгое следование заранее разработанным протоколам и интерфейсам, что снижает скорость разработки.

Методология RAD неприменима для построения сложных расчетных программ, операционных систем или программ управления космическими кораблями, т.е. программ, требующих написания большого объема (сотни тысяч строк) уникального кода. Не подходят для разработки по методологии RAD приложения, в которых отсутствует ярко выраженная интерфейсная часть, наглядно определяющая логику работы системы (например, приложения реального времени) и приложения, от которых зависит безопасность людей (например, управление самолетом или атомной электростанцией), так как итеративный подход предполагает, что первые несколько версий наверняка не будут полностью работоспособны, что в данном случае исключается. Оценка размера приложений производится на основе так называемых функциональных элементов (экраны, сообщения, отчеты, файлы и т.п.) Подобная метрика не зависит от языка программирования, на котором ведется разработка. Размер приложения, которое может быть выполнено по методологии RAD, для хорошо отлаженной среды разработки ИС с максимальным повторным использованием программных компонентов, определяется следующим образом: менее 1 000 функциональных элементов - один человек; 1 000-4 000 функциональных элементов - одна команда разработчиков; более 4 000 функциональных элементов - из расчета 4 000 функциональных элементов на одну команду разработчиков.

Отметим основные принципы методологии RAD:

 разработка приложений итерациями;

 необязательность полного завершения работ на каждом из этапов жизненного цикла;

 обязательное вовлечение пользователей в процесс разработки ИС;

 необходимое применение CASE-средств, обеспечивающих целостность проекта;

 применение средств управления конфигурацией, облегчающих внесение изменений в проект и сопровождение готовой системы;

 необходимое использование генераторов кода;

 использование прототипирования, позволяющее полнее выяснить и удовлетворить потребности конечного пользователя;

 тестирование и развитие проекта, осуществляемое одновременно с разработкой;

 ведение разработки немногочисленной, хорошо управляемой командой профессионалов;

 грамотное руководство разработкой системы, четкое планирование и контроль выполнения работ. Инструменты разработки программных средств

При разработке программных средств используется, в той или иной мере, компьютерная поддержка процессов разработки и сопровождения ПО. Это достигается путем представления некоторых программных документов ПО (прежде всего, программ) и предоставлению в распоряжение разработчика ПО специальных программных средств (ПС), или включенных в состав компьютера специальных устройств, созданных для какой-либо обработки таких документов. В качестве такого специального ПС можно указать компилятор с какого-либо языка программирования.

В качестве специального устройства, поддерживающего процесс разработки ПО, можно указать, например, эмулятор какого-либо языка. ПС, предназначенное для поддержки разработки ПО, будем называть программным инструментом разработки ПО, а устройство компьютера, специально предназначенное для поддержки разработки ПО, будем называть аппаратным инструментом разработки ПО.

Инструменты разработки ПО могут использоваться в течение всего жизненного цикла ПО для работы с разными программными документами. Так, текстовый редактор может использоваться для разработки практически любого программного документа.

С точки зрения функций, которые инструменты выполняют при разработке ПО, их можно разбить на следующие четыре группы:

 редакторы;

 анализаторы;

 преобразователи;

 инструменты, поддерживающие процесс выполнения программ. Редакторы поддерживают конструирование (формирование) программных документов на различных этапах жизненного цикла. На этапе программирования (кодирования) вместо текстового редактора может оказаться более удобным синтаксически управляемый редактор, ориентированный на используемый язык программирования. Анализаторы производят либо статическую обработку документов, осуществляя различные виды их контроля, выявление определенных свойств и накопление статистических данных (например, проверку соответствия документов указанным стандартам), либо динамический анализ программ (например, с целью выявление распределения времени работы программы по программным модулям). Преобразователи позволяют автоматически приводить документы к другой форме представления (например, форматеры) или переводить документ одного вида к документу другого вида (например, конверторы или компиляторы), синтезировать какой-либо документ из отдельных частей и т.п. Инструменты, поддерживающие процесс выполнения программ, позволяют выполнять на компьютере описания процессов или отдельных их частей, представленных в виде, отличном от машинного кода, или машинный код с дополнительными возможностями его интерпретации. Примером такого инструмента является эмулятор кода другого компьютера. К этой группе инструментов следует отнести и различные отладчики.