Методологии проектирования программного обеспечения как программные продукты

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

101

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

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

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

Электронные методологии и технологии (и поддерживающие их CASE-средства) составляют ядро комплекса согласованных инструментальных средств среды разработки АИС.

Методология DATARUN. Одной из наиболее распространен­ных в мире электронных методологий является методология DATARUN. В соответствии с ней жизненный цикл ПО разбивает­ся на стадии, которые связываются с результатами выполнения основных процессов, определяемых стандартом ISO 12207. Каж­дую стадию помимо ее результатов должен завершать план работ на следующую стадию.

Стадия формирования требований и планирования включает в себя действия по определению начальных оценок объема и стоимости проекта. Должны быть сформулированы требования и экономи­ческое обоснование для разработки АИС, функциональные мо­дели (модели бизнес-процессов организации) и исходная кон­цептуальная модель данных, которые дают основу для оценки тех­нической реализуемости проекта. Основными результатами этой стадии должны быть модели деятельности организации (исход­ные модели процессов и данных организации), требования к си­стеме, включая требования по сопряжению с существующими АИС, исходный бизнес-план.

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

На стадии спецификации приложений продолжается процесс создания и детализации проекта. Концептуальная модель данных

102

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

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

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

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

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

Стадия развития фактически является повторной итерацией стадии разработки.

Методология DATARUN опирается на две модели или два пред­ставления:

1) модель организации;

2) модель АИС.

Методология DATARUN базируется на системном подходе к описанию деятельности организации. Построение моделей начи-

103

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

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

Любая АИС представляет собой набор модулей, исполняемых процессорами и взаимодействующих с БД. Базы данных и процес­соры могут располагаться централизованно или быть распреде­ленными. События в системе могут инициироваться внешними сущностями. Все транзакции осуществляются через объекты или модули интерфейса, которые взаимодействуют с одной или более БД.

Методология DATARUN преследует две цели:

1) определить стабильную структуру, на основе которой будет строиться АИС. Такой структурой является модель данных, полу­ченная из первичных данных, представляющих фундаментальные процессы организации;

2) спроектировать АИС на основании модели данных.

Объекты, формируемые на основании модели данных, явля­ются объектами БД, обычно размещаемыми на серверах в среде «клиент/сервер». Объекты интерфейса, определенные в архитек­туре компьютерной системы, обычно размещаются на части кли­ентов. Модель данных, являющаяся основой для спецификации совместно используемых объектов БД и разных объектов интер­фейса, обеспечивает сопровождаемость АИС.

В процессе разработки АИС создается ряд моделей:

• ВРМ (Business Process Model) — модель процессов (бизнес-процессов);

• PDS (Primary Data Structure) — структура первичных данных;

• CDM (Conceptual Data Model) — концептуальная модель дан­ных;

• SPM (System Process Model) — модель процессов системы;

• ISA (Information System Architecture) — архитектура инфор­мационной системы;

• ADM (Application Data Model) — модель данных приложения;

104

• IPM (Interface Presentation Model) — модель представления интерфейса;

• ISM (Interface Specification Model) — модель спецификации интерфейса.

CASE-средство Silverran обеспечивает автоматизацию прове­дения проектных работ в соответствии с методологией DATARUN и обеспечивает создание этих моделей. Предоставляемая этими средствами среда проектирования дает возможность руководите­лю проекта контролировать проведение работ, отслеживать их вы­полнение, вовремя замечать отклонения от графика. Каждый уча­стник проекта, подключившись к этой среде, может выяснить со­держание и сроки выполнения порученной ему работы, детально изучить технику ее выполнения в гипертексте по технологиям и вызвать инструмент (модуль Silverrun) для реального выполнения работы.

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

Создаваемая АИС должна основываться на функциях, выпол­няемых организацией, поэтому первая создаваемая модель — это модель бизнес-процессов, построение которой осуществляется в модуле Silverrun ВРМ. Для этой модели используется специальная нотация ВРМ.

В процессе анализа и спецификации бизнес-функций выявля­ются основные информационные объекты, которые документи­руются как структуры данных, связанные с потоками и хранили­щами модели. Источниками для создания структур являются ис­пользуемые в организации документы, должностные инструкции, описания производственных операций. Эти данные вводятся в том виде, как они существуют в деятельности организации. Нормали­зация и удаление избыточности проводятся позже, при построе­нии концептуальной модели данных в модуле Silverrun ERX. Пос­ле создания модели бизнес-процессов информация сохраняется в репозитории проекта.

В процессе обследования работы организации выявляются и документируются структуры первичных данных (PDS). Эти струк­туры заносятся в репозитории модуля ВРМ при описании цирку­лирующих в организации документов, сообщений, данных. В мо­дели бизнес-процессов первичные структуры данных связаны с потоками и хранилищами информации.

На основе структур первичных данных в модуле Silverrun ERX создается концептуальная модель данных (ER-модель). От струк­тур первичных данных концептуальная модель отличается удале­нием избыточности, стандартизацией наименований понятий и нормализацией. Эти операции в модуле ERX (Entity-Relationship

105

Expert, см. далее) выполняются при помощи встроенной эксперт­ной системы. Целью концептуальной модели данных является опи­сание используемой информации без деталей возможной реализа­ции в БД, но в хорошо структурированном нормализованном виде.

На основе модели бизнес-процессов и концептуальной модели данных проектируется архитектура АИС. Определяются входящие в систему приложения, для каждого приложения специфициру­ются используемые данные и реализуемые функции. Архитектура АИС создается в модуле Silverrun ВРМ с использованием специ­альной нотации ISA. Основное содержание этой модели — струк­турные компоненты системы и навигация между ними. Концепту­альная модель данных разбивается на части, соответствующие вхо­дящим в состав системы приложениям.

Перед разработкой приложений должна быть спроектирована структура корпоративной БД. DATARUN предполагает использо­вание БД, основанной на реляционной модели. Концептуальная модель данных после нормализации переносится в модуль реля­ционного моделирования Silverrun RDM (см. далее) с помощью специального моста ERX—RDM.

Преобразование модели из формата ERX в формат RDM про­исходит автоматически без вмешательства пользователя. После преобразования форматов получается модель реляционной БД. Эта модель детализируется в модуле Silverrun RDM определением физической реализации (типов данных СУБД, ключей, индек­сов, триггеров, ограничений целостности). Правила обработки данных можно задавать как непосредственно на языке програм­мирования СУБД, так и в декларативной форме, не привязанной к реализации. Мосты Silverrun к реляционным СУБД переводят эти декларативные правила на язык требуемой системы, что сни­жает трудоемкость программирования процедур сервера БД, а так­же позволяет из одной спецификации генерировать приложения для разных СУБД.

С помощью модели системных процессов детально документи­руется поведение каждого приложения. В модуле ВРМ создается модель системных процессов, определяющая, каким образом реа­лизуются бизнес-процессы. Эта модель создается отдельно для каж­дого приложения и тесно связана с моделью данных приложения.

Приложение состоит из интерфейсных объектов (экранных форм, отчетов, процедур обработки данных). Каждый интерфейс системы (экранная форма, отчет, процедура обработки данных) имеет дело с подмножеством БД. В модели данных приложения (созданной в модуле RDM) создается подсхема базы данных для каждого интерфейса этого приложения. Уточняются также прави­ла обработки данных, специфичные для каждого интерфейса.

Модель представления интерфейса — это описание внешнего вида интерфейса с точки зрения конечного пользователя системы.

106

Это может быть документ, показывающий внешний вид экрана или структуру отчета, или экран (отчет), созданный с помощью одного из средств визуальной разработки приложений — так на­зываемых языков четвертого поколения (Fourth Generation Lan­guages — 4GL). Так как большинство языков 4GL позволяет быст­ро создавать работающие прототипы приложений, пользователь имеет возможность увидеть работающий прототип системы на ран­них стадиях проектирования.

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

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

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

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

В разряд CASE-средств попадают как относительно дешевые системы для персональных ЭВМ с весьма ограниченными возможностями, так и дорогостоящие системы для неоднород­ных вычислительных платформ и операционных сред. Так, современный рынок программных средств насчитывает около 300 различных CASE-средств, наиболее мощные из которых так или иначе используются практически всеми ведущими западны­ми фирмами.

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

107

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

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

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

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

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

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

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

3) средства разработки приложений, включая языки 4GL и генераторы кодов;

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

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

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

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

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

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

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

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

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

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

108

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

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

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

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

5) средства реинжиниринга, обеспечивающие анализ програм­мных кодов и схем БД и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designer. В области анализа программных кодов наибольшее распространение получают объект­но-ориентированные CASE-средства, обеспечивающие реинжи­ниринг программ на языке C++: Rational Rose (Rational Software), Object Team (Cayenne).

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

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

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

• средства тестирования (Quality Works (Segue Software));
» средства документирования (SoDA (Rational Software)).

На сегодняшний день на российском рынке ПО представлены следующие наиболее развитые CASE-средства: Silverrun; Designer/ 2005; Vantage Team Builder (Westmount I-CASE); ERwin+BPwin; S-Designer; СА8Е.Аналитик. Кроме того, на рынке постоянно по­являются как новые для отечественных пользователей системы (на­пример, CASE/4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE), так и новые версии и модификации пе­речисленных систем.

109

Охарактеризуем основные возможности CASE-средств на при­мере имеющей широкое распространение системы SOverrun.

CASE-средство Silverrun американской фирмы Computer Systems Advisers, Inc. (CSA) используется для анализа и проектирования АИС бизнес-класса и ориентировано в большей степени на спи­ральную модель жизненного цикла. Оно применимо для поддерж­ки любой методологии, основанной на раздельном построении функциональной и информационной моделей (диаграмм потоков данных и диаграмм «сущность—связь»).

Настройка на конкретную методологию обеспечивается выбо­ром требуемой графической нотации моделей и набора правил проверки проектных спецификаций. В системе имеются готовые настройки для наиболее распространенных методологий: DATA-RUN (основная методология, поддерживаемая Silverrun), Gane/ Sarson, Yourdon/DeMarco, Merise, Ward/Mellor, Information Engi­neering. Для каждого понятия, введенного в проекте, имеется воз­можность добавления собственных описателей. Архитектура Silverrun позволяет наращивать среду разработки по мере необхо­димости. Silverrun имеет модульггую структуру и состоит из четы­рех модулей, каждый из которых является самостоятельным про­дуктом и может приобретаться и использоваться без связи с ос­тальными модулями.

Модуль построения моделей бизнес-процессов в форме диаграмм потоков данных (Business Process Modeler — ВРМ) позволяет мо­делировать функционирование обследуемой организации или со­здаваемой АИС. В модуле ВРМ обеспечена возможность работы с моделями большой сложности: автоматическая перенумерация, работа с деревом процессов (включая визуальное перетаскивание ветвей), отсоединение и присоединение частей модели для кол­лективной разработки.

Диаграммы могут изображаться в нескольких предопределен­ных нотациях, включая Йодана — де Марко и Гейна —Сарсона. Имеется также возможность создавать собственные нотации, в том числе добавлять в число изображаемых на схеме дескрипторов оп­ределенные пользователем поля.

Модуль концептуального моделирования данных (Entity-Rela­tionship eXpert — ERX) обеспечивает построение моделей дан­ных «сущность —связь», не привязанных к конкретной реализа­ции. Этот модуль имеет встроенную экспертную систему, позво­ляющую создать корректную нормализованную модель данных по­средством ответов на содержательные вопросы о взаимосвязи дан­ных. Можно автоматически построить модель данных из описаний структур данных. Анализ функциональных зависимостей атрибу­тов дает возможность проверить соответствие модели требовани­ям третьей нормальной формы и обеспечить их выполнение. Про­веренная модель передается в модуль RDM.

ПО

Модуль реляционного моделирования (Relational Data Modeler — RDM) позволяет создавать детализированные модели «сущность— связь», предназначенные для реализации в реляционной БД. В этом модуле документируются все конструкции, связанные с построе­нием БД: индексы, триггеры, хранимые процедуры и т.д. Гибкая изменяемая нотация и расширяемость репозитория позволяют ра­ботать по любой методологии. Возможность создавать подсхемы со­ответствует подходу ANSI SPARC к представлению схемы БД. На языке подсхем моделируются как узлы распределенной обработки, так и пользовательские представления. Этот модуль обеспечивает проектирование и полное документирование реляционных БД.

Менеджер репозитория рабочей группы (Workgroup Repository Manager — WRM) применяется как словарь данных для хранения общей для всех моделей информации, а также обеспечивает ин­теграцию модулей Silverrun в единую среду проектирования.

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

Для автоматической генерации схем БД у Silverrun существуют мосты к наиболее распространенным СУБД: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQL Base, Sybase. Для передачи дан­ных в средства разработки приложений имеются мосты к языкам 4GL: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi. Все мосты позволяют загрузить в Silverrun RDM информацию из каталогов соответствующих СУБД или языков 4GL. Это позволяет документировать, перепроектировать или переносить на новые платформы уже находящиеся в эксплуатации БД и прикладные системы.

При использовании моста Silverrun расширяет свой внутрен­ний репозиторий специфичными для целевой системы атрибута­ми. После определения значений этих атрибутов генератор прило­жений переносит их во внутренний каталог среды разработки или использует при генерации кода на языке SQL. Таким образом можно полностью определить ядро БД с использованием всех возможно­стей конкретной СУБД: триггеров, хранимых процедур, ограни­чений ссылочной целостности. При создании приложения на язы­ке 4GL данные, перенесенные из репозитория Silverrun, исполь­зуются либо для автоматической генерации интерфейсных объек­тов, либо для их быстрого создания вручную.

Для обмена данными с другими средствами автоматизации проектирования, создания специализированных процедур анали-

111

за и проверки проектных спецификаций, составления специали­зированных отчетов в соответствии с различными стандартами в системе Silverrun имеется три способа выдачи проектной инфор­мации во внешние файлы:

1) система отчетов. Можно, определив содержимое отчета по репозиторию, выдать отчет в текстовый файл. Этот файл затем загружают в текстовый редактор или включают в другой отчет;

2) система экспорта/импорта. Для более полного контроля над структурой файлов в системе экспорта/импорта имеется возмож­ность определять не только содержимое экспортного файла, но и разделители записей, полей в записях, маркеры начала и конца текстовых полей. Файлы с указанной структурой можно не только формировать, но и загружать в репозиторий. Это дает возмож­ность обмениваться данными с разными системами: другими CASE-средствами, СУБД, текстовыми редакторами и электрон­ными таблицами;

3) хранение репозитория во внешних файлах через ODBC-драй­веры. Для доступа к данным репозитория из наиболее распро­страненных СУБД обеспечена возможность хранения всей проект­ной информации непосредственно в формате этих СУБД.

Групповая работа поддерживается в системе Silverrun двумя способами:

• в стандартной однопользовательской версии имеется меха­низм контролируемого разделения и слияния моделей. Разделив модель на части, можно раздать их нескольким разработчикам. После детальной доработки модели объединяются в единые спе­цификации;

• сетевая версия Silverrun позволяет осуществлять одновремен­ную групповую работу с моделями, хранящимися в сетевом репо­зиторий на базе СУБД Oracle, Sybase или Informix. При этом не­сколько разработчиков могут работать с одной и той же моделью, так как объекты блокируются на уровне отдельных элементов мо­дели.

Существуют реализации Silverrun трех платформ: MS Windows, Macintosh и OS/2 Presentation Manager, с возможностью обмена проектными данными между ними. Помимо системы Silverrun ука­жем назначение и других популярных CASE-средств и их групп.

Vantage Team Builder представляет собой интегрированный программный продукт, ориентированный на реализацию каскад­ной модели жизненного цикла ПО и поддержку полного жизнен­ного цикла ПО.

Uniface 6.1 — продукт фирмы Compuware (США) — представ­ляет собой среду разработки крупномасштабных приложений в архитектуре «клиент—сервер».

Designer/2005 фирмы ORACLE является интегрированным CASE-средством, обеспечивающим в совокупности со средства-

112

ми разработки приложений Developer/2000 поддержку полного жизненного цикла ПО для систем, использующих СУБД Oracle.

Пакет CASE/4/0 (microTOOL GmbH), включающий структур­ные средства системного анализа, проектирования и программи­рования, обеспечивает поддержку всего жизненного цикла разра­ботки (вплоть до сопровождения) на основе сетевого репозито-рия, контролирующего целостность проекта и поддерживающего согласованную работу всех его участников (системных аналити­ков, проектировщиков, программистов).

Также существуют локальные CASE -средства. Пакет ERwin (Logic Works) используется при моделировании и создании БД произ­вольной сложности на основе диаграмм «сущность — связь». В на­стоящее время ERwin является наиболее популярным пакетом моделирования данных благодаря поддержке широкого спектра СУБД самых разных классов — SQL-серверов (Oracle, Informix, Sybase SQL Server, MS SQL Server, Progress, DB2, SQL Base, Ingress, Rdb и др.) и «настольных» СУБД типа xBase (Clipper, dBASE, FoxPro, MS Access, Paradox и др.).

BPwin — это средство функционального моделирования, реа­лизующее методологию IDEF0. Модель в BPwin представляет со­бой совокупность SADT-диаграмм, каждая из которых описывает отдельный процесс, разбивая его на шаги и подпроцессы.

S-Designer 4.2 (Sybase/Powersoft) представляет собой CASE-средство для проектирования реляционных БД. По своим функ­циональным возможностям и стоимости он близок к ERwin, от­личаясь используемой на диаграммах нотацией. S-Designer реали­зует стандартную методологию моделирования данных и генери­рует описание БД для таких СУБД, как Oracle, Informix, Ingres, Sybase, DB/2, Microsoft SQL Server и др.

CASE. Аналитик 1.1 («Эйтекс») в настоящее время является практически единственным конкурентоспособным отечественным CASE-средством функционального моделирования и реализует построение диаграмм потоков данных в соответствии с описан­ной ранее методологией.

Среди объектно-ориентированных CASE -средств рассмотрим Rational Rose (Rational Software Corporation, CIIIA) — средство, предназначенное для автоматизации этапов анализа и проектиро­вания ПО, а также генерации кодов на разных языках и выпуска проектной документации.

Rational Rose использует синтез-методологию объектно-ориен­тированного анализа и проектирования, основанную на подходах трех ведущих специалистов в данной области: М. Буча, К. Рамбо и Т. Джекобсона. Разработанная ими универсальная нотация для мо­делирования объектов (язык UML — Unified Modeling Language) является в настоящее время и, очевидно, останется в будущем общепринятым стандартом в области объектно-ориентирован-

113

ного анализа и проектирования. Конкретный вариант Rational Rose определяется языком, на котором генерируются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Ос­новной вариант — Rational Rose/C++ — позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций, а также генерировать программные коды на C++. Кроме того, Rational Rose содержит средства реинжиниринга программ, обес­печивающие повторное использование программных компонен­тов в новых проектах.

Целью конфигурационного управления является обеспечение управляемости и контролируемости процессов разработки и со­провождения ПО. Для этого необходима точная и достоверная ин­формация о состоянии ПО и его компонентов в каждый момент времени, а также о всех предполагаемых и выполненных измене­ниях.

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

Наиболее распространенным средством конфигурационного управления является PVCS фирмы Intersolv (США), включающее ряд самостоятельных продуктов: PVCS Version Manager, PVCS Tracker, PVCS Configuration Builder и PVCS Notify.

Для создания документации в процессе разработки АИС ис­пользуются разнообразные средства формирования отчетов, а так­же компоненты издательских систем.

Обычно средства документирования встроены в конкретные CASE-средства. Исключением являются некоторые пакеты, пре­доставляющие дополнительный сервис при документировании. Из них наиболее активно используется SoDA (Software Document Automation).

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

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

114

вать места, где будет размещаться извлекаемая из разнообразных источников информация. Изменения автоматически вносятся толь­ко в те части документации, на которые они повлияли в програм­ме. Это сокращает время подготовки документации за счет отказа от перегенерации всей документации. SoDA реализована на базе издательской системы FrameBuilder и предоставляет полный на­бор средств по редактированию и верстке выпускаемой докумен­тации.

Итоговым результатом работы системы SoDA является гото­вый документ (или книга). Документ может храниться в файле формата SoDA (Frame Builder), который получается в результате генерации документа. Вывод на печать этого документа (или его части) возможен из системы SoDA. Среда функционирования SoDA — ОС типа UNIX на рабочих станциях Sun SPARCstation, IBM RISC System/6000 или Hewlett Packard HP 9000 700/800.

Под тестированием понимается процесс исполнения програм­мы с целью обнаружения ошибок. Регрессионное тестирование — это тестирование, проводимое после усовершенствования функ­ций программы или внесения в нее изменений!

Одно из наиболее развитых средств тестирования QA (новое название — Quality Works) представляет собой интегрированную многоплатформенную среду для разработки автоматизированных тестов любого уровня, включая тесты регрессии для приложений с графическим интерфейсом пользователя. Средство QA позволя­ет начинать тестирование на любой фазе жизненного цикла, пла­нировать и управлять процессом тестирования, отображать изме­нения в приложении и повторно использовать тесты для более чем 25 различных платформ.

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

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

115

DATARUN. В состав комплекса входят следующие инструменталь­ные средства:

« CASE-средство Silverran;

• средство разработки приложений JAM; . мост Silverran-RDM <-> JAM;

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

• менеджер транзакций Tuxedo;

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

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

• объектно-ориентированное CASE-средство Rational Rose;

• средство документирования SoDA.

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

ГЛАВА 8. СОВРЕМЕННЫЕ КОМПЬЮТЕРНЫЕ СЕТИ

⇐ Предыдущая14151617181920212223Следующая ⇒

Поделиться: