<<
>>

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

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

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

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

Методология DATARUN

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

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

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

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

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

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

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

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

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

Методология БАТАРИШ опирается на две модели или на два представления:

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

♦ модель АИС.

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

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

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

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

Подход БАТАШШ преследует две цели:

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

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

Объекты, формируемые на основании модели данных,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На основе структур первичных данных в модуле Silverrun ERX создается концептуальная модель данных (ER-модель). От структур первичных данных концептуальная модель от­личается удалением избыточности, стандартизацией наиме­нований понятий и нормализацией. Эти операции в модуле ERX выполняются при помощи встроенной экспертной сис­темы. Цель концептуальной модели данных — описать исполь­зуемую информацию без деталей возможной реализации в базе данных, но в хорошо структурированном нормализо­ванном виде.

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

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

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

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

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

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

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

Характеристика современных CASE-cpedcme

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

♦ средства документирования (SoDA (Rational Software)).

На сегодняшний день российский рынок программного

обеспечения располагает следующими наиболее развитыми CASE-средствами:

♦ Silverrun;

♦ Designer/2000;

♦ Vantage Team Builder (Westmount I-CASE);

♦ ERwin+BPwin;

♦ S-Designor;

♦ CASE-Аналитик.

Кроме того, на рынке постоянно появляются как новые для отечественных пользователей системы (например, CASE/ 4/0, PRO-IV, System Architect, Visible Analyst Workbeneh, EasyCASE), так и новые версии и модификации перечислен­ных систем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Имеются реализации Silverrun трех платформ — MS Windows, Macintosh и OS/2 Presentation Manager — с воз­можностью обмена проектными данными между ними.

Помимо системы Silverrun, укажем назначение и дру­гих популярных CASE-средств и их групп.

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

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

CASE-средство Designer/2000 2.0 фирмы Oracle являет­ся интегрированным CASE-средством, обеспечивающим в со­вокупности со средствами разработки приложений Developer/ 2000 поддержку полного ЖЦ ПО для систем, использующих СУБД Oracle.

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

Локальные средства

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

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

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

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

Объектно-ориентированные CASE-cpedcmea

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

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

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

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

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

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

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

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

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

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

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-средства, посколь­ку ни одно из них не решает в целом все проблемы создания и сопровождения ПО. Это подтверждается также полным набором критериев оценки и выбора, которые затрагивают все этапы ЖЦ ПО. Сравниваться могут комплексы методоло­гически и технологически согласованных инструментальных средств, поддерживающие полный ЖЦ ПО и обеспеченные необходимой технической и методической поддержкой со сто­роны фирм-поставщиков (отметим, что рациональное комп- лексирование инструментальных средств разработки ПО ИС является важнейшим условием обеспечения качества этого ПО, причем это замечание справедливо для всех предмет­ных областей). На сегодняшний день наиболее развитым из всех поставляемых в Россию комплексов такого рода являет­ся комплекс технологий и инструментальных средств созда­ния ИС, основанный на методологии и технологии DATARUN.

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

♦ CASE-средство Silverrun;

♦ средство разработки приложений JAM;

♦ мост Silverrun-RDM JAM;

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

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

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

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

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

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

<< | >>
Источник: Балдин К. В., Уткин В. Б.. Информационные системы в экономике: Учебник. — 5-е изд. — М.: Издательско-торго- вая корпорация «Дашков и К0», — 395 с.. 2008

Еще по теме 1.6.4. Методологии проектирования программного обеспечения:

  1. 1.2. Основы проектирования элементов программного обеспечения информационных систем
  2. о методологии социального проектирования
  3. Программное обеспечение
  4. 8.2.6.2. Выбор стандартного программного обеспечения
  5. 2.1.4 . Программное обеспечение АБС
  6. Подсистема «Программно-математическое обеспечение АИС»
  7. 1.6.1. Жизненный цикл программного обеспечения информационной системы
  8. 7.2. Методология концептуального проектирования систем организационного управления
  9. 6.4. Программное обеспечение финансовых решений
  10. 2.4.3. Используемое программное обеспечение
  11. Программное обеспечение системы.
  12. 1.1.3. Место информационных и расчетных задач в составе программного обеспечения ЭВМ
  13. 1.6.3. Структурный метод разработки программного обеспечения
  14. 8.3. Программное обеспечение бухгалтерского учета
  15. 8.3. Программное обеспечение автоматизированных информационных технологий аудиторской деятельности
  16. 3 .РАЗРАБОТКА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ АРМ «ВАЛЮТНЫЙ КАССИР» В СОСТАВЕ СИСТЕМЫ «ОБМЕННЫЙ ПУНКТ»
  17. 8.4. ПРОЕКТИРОВАНИЕ ЭКОНОМИЧЕСКИХ ИНФОРМАЦИОННЫХ СИСТЕМ 8.4.1. ЗАДАЧИ ПРОЕКТИРОВАНИЯ
  18. § 3. Районная планировка — связующее звено между проектированием предприятий и проектированием их размещения
  19. Фаза IV - Проектирование: Проектирование новогоадминистративного бизнес-процесса