Case-технологии

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

На рисунке №3 представлена схема архитектуры CASE-средства.

Рисунок №3

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

Репозиторий содержит информацию об объектах проектируемой ЭИС и взаимосвязях между ними, все подсистемы обмениваются данными с ним. В репозитории хранятся описания следующих объектов:

1. Описание проектировщиков и их прав доступа к различным компонентам систем.

2. Описание организационных структур, диаграмм, компонентов диаграмм, связей между диаграммами.

3. Описание структур данных, программных модулей, процедур, библиотек модулей и т.д.

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

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

1. создавать элементы диаграмм и взаимосвязи между ними;

2. задавать описания элементов диаграмм;

3. задавать описания связей между элементами диаграмм;

4. редактировать элементы диаграмм, их взаимосвязи и описания.

Верификатор диаграмм служит для контроля правильности построения диаграмм в заданной методологии проектирования ЭИС. Он выполняет следующие функции:

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

• диагностику и выдачу сообщений об ошибках;

• выделение на диаграмме ошибочных элементов.

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

Администратор проекта представляет собой инструменты, необходимые для выполнения следующих административных функций:

• инициализации проекта;

• задания начальных параметров проекта;

• назначения и изменения прав доступа к элементам проекта;

• мониторинга выполнения проекта.

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

Основные преимущества CASE-технологии по сравнению с традиционной технологией оригинального проектирования сводятся к следующему:

• улучшение качества разрабатываемого программного приложения за счет средств автоматического контроля и генерации;

• возможность повторного использования компонентов разработки;

• поддержание адаптивности и сопровождения ИС;

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

• освобождение разработчиков от рутинной работы по документированию проекта, так как при этом используется встроенный документатор;

• возможность коллективной разработки ИС в режиме реального времени.

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

Методология определяет шаги и этапность реализации проекта, а также правила использования методов, с помощью которых разрабатывается проект.

Метод - это процедура или техника генерации описаний компонентов ИС (например, проектирование потоков и структур данных).

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

Инструментальные средства CASE - специальные программы, которые поддерживают одну или несколько методологии анализа и проектирования ИС.

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

1. по поддерживаемым методологиям проектирования: функционально (структурно) - ориентированные, объектно-ориентированные и комплексно-ориентированные (набор методологий проектирования);

2. по поддерживаемым графическим нотациям построения диаграмм: с фиксированной нотацией, с отдельными нотациями и наиболее распространенными нотациями;

3. по степени интегрированности: tools (отдельные локальные средства), toolkit (набор неинтегрированных средств, охватывающих большинство этапов разработки ИС) и workbench (полностью интегрированные средства, связанные общей базой проектных данных - репозиторием);

4. по типу и архитектуре вычислительной техники: ориентированные на ПЭВМ, ориентированные на локальную вычислительную сеть (ЛВС), ориентированные на глобальную вычислительную сеть (ГВС) и смешанного типа;

5. по режиму коллективной разработки проекта: не поддерживающие коллективную разработку, ориентированные на режим реального времени разработки проекта, ориентированные на режим объединения подпроектов;

6. по типу операционной системы (ОС): работающие под управлением WINDOWS 3.11 и выше; работающие под управлением UNIX и работающие под управлением различных ОС (WINDOWS, UNIX, OS/2 и др.).

В данный момент времени case-технологии разработки ПО в основном используются 2 подхода:

1. Функционально-модульный или структурный;

2. Объектно-ориентированный.

Функционально-модульный подход основан на принципе алгоритмической декомпозиции с выделением функциональных элементов со строгим порядков выполнения действий.

ООП - основан на объектной декомпозиции с описанием поведения ИС в терминах взаимодействия объектов.

Недостатки функционально-модульного подхода:

1. Однонаправленность информационных потоков и недостаточная обратная связь.

2. В случае изменения требований к системе это приводит к полному переконструированию системы, существенно влияет на время разработки и на ее стоимость.

3. Неоднородность информационных ресурсов, используемых в большинстве информационных систем.

В настоящее время наблюдается тенденция переориентации инструментальных средств, созданных для структурной разработки на ОО методы. Это объясняется следующими причинами:

1. Возможность сборки программной системы из готовых компонентов, которые можно использовать неоднократно.

2. Возможность накопления проектов в виде библиотек определенных классов на основе механизмов наследования.

3. Простотой внесения изменений в проект за счет инкапсуляции данных в объектах.

4. Адаптация к изменяющимся условиям за счет использования свойств наследования и полиморфизма.

5. Возможность организации параллельных работ проектировщиков, аналитиков и программистов.

Рассмотренные выше концепции ОО подходов и распределенных вычислений в первые были созданы и использованы в case-технологиях в консорциуме Object Managment Group (OMG), в состав которых входят около 500 компаний. Основными направлениями действий этого консорциума является разработка стандартов для создания распределенных систем в разнородных средах. Созданная базовая концепция: Object Managment Architecture (OMA), которая состоит из 4х компонентов:

1. Архитектура брокеров систем CORBA определяет механизм взаимодействия объектов в разнородной сети.

2. Объектные сервисы (Object Service) являются основными системными сервисами для создания приложений.

3. Универсальные средства (Common Facilities).

4. Прикладные объекты (Application Object) предназначены для решения конкретных прикладных задач.

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

Идеальное объектно-ориентированное САSЕ-средство должно содержать четыре основных блока: анализ, проектирование, разработка и инфраструктура. См. Таблицу 4.

Таблица 4

Анализ				Проектирование		Реализация
Возможность добавлять пояснительные надписи к диаграммам и в документацию		Возможность создавать различные представления и скрывать ненужные в данный момент слои системы		Возможность просматривать и выбирать элементы и бизнес-объекты для использования в системе		Возможность генерировать заготовки программного кода на несколь­ких объектно-ориентирован­ных языках
Среда для создания диаграмм разнообразных моделей				Возможность создания пользовательского интерфейса (поддержка OLE, ActiveX, ОpenDoc, НTML)		Возможность проверки кода на синтаксичес­кую корректность
Поддержка различных нотаций	Возможность динамического моделирования событий в системе			Возможности определения бизнес-модели и бизнес-правил		Возможность генерировать код для 4GL и клиент-серверных продуктов (PowerBuider, Forte, VisuaLAge, Visual Works)
Возможность генерации документации для печати	Возможность динамической коррекции одной диаграммы из другой			Возможность связи с объектно-ориентированными базами данных и распределенными модулями (поддержка COBRA, DCOM, HOP, HTML)
Инфраструктура
Контроль версий. Блокирование и согласование частей системы при групповой разработке			Репозиторий		Возможность реин­жиниринга програм­много кода, 4GL, клиент-серверных систем в диаграммы моделей

Основные требования к блоку анализа:

• возможность выбора выводимой на экран информации из всей совокупности данных, описывающих модели;

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

• внесение комментариев в диаграммы и соответствующую документацию для фиксации проектных решений;

• возможность динамического моделирования в терминах событий;

• поддержка нескольких нотаций (хотя бы три нотации - Г.Буча, И.Джекобсона и ОМТ).

Основные требования к блоку проектирования:

• поддержка всего процесса проектирования приложения;

• возможность работы с библиотеками, средствами поиска и выбора;

• возможность разработки пользовательского интерфейса;

• поддержка стандартов ОLE, ActiveX и доступ к библиотекам HTML или Java;

• поддержка разработки распределенных или двух- и трехзвенных клиент-серверных систем (работа с CORBA, DCOM, Internet).

Основные требования к блоку реализации:

• генерация кода полностью из диаграмм;

• возможность доработки приложений в клиент-серверных САSЕ-средствах типа Power Builder;

• реинжиниринг кодов и внесение соответствующих изменений в модель системы;

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

Основные требования к блоку инфраструктуры:

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

• обеспечение командной работы (многопользовательской работы и управление версиями) и реинжиниринга.

В таблице 5 представлен обзор объектно-ориентированных CASE-средств.

Таблица 5

№ п/п	Продукт, фир­ма-разработчик (от указ. ver. и выше)	Поддержи­ваемые платформы (от указ. ver. и выше)	Используе­мые коды	Генера­ция кода	Описание
1	BridgePoint (ver. 3.2.1), Project Tehnology	Unix, SIG-Irix	Шлеер/ Меллор	C/C++	Поддержка полного жизненного цикла в рам­ках методики «Шлеер/ Меллор», генерация кода
2	Grapical Designer (ver. 2.0), Advanced Software Technologies	Unix, Windows NT Windows 95	ГБуч, ИДжекоб-сон, ОМТ, Шлеер/ Меллор, UML.08 и структурная нотация	С/С++	Генерация кода и реин­жиниринг для каждого из поддерживаемых языков и методологий. Команд­ная работа. Возможность создания собственной но­тации
3	LifeModel for OOOIE (ver. 1), InteliCorp	Unix, Windows NT	Мартин/ Оделл (OOIE)	С	Средство является верх­ним уровнем фирменного продукта искусственного интеллекта Карра. Прото-типирование в режиме ин­терпретатора, генерация кода, создание экранов и т.д. Возможность про­граммирования на С или на внутреннем Script- язы­ке типа Prolog
4	ObjectTime, ObjectTime Ltd	Unix	ROOM	C++	Создание и визуализа­ция исполняемых моде­лей систем реального времени на основе ОО-методологии реального времени (ROOM). Внут­ренний Script-язык — подмножество «Smalltalk»
5	Dbjectory (ver. 3.7), Rational Software	Unix, OS/2, DOSS, Windows 3.1, 95, NT	И. Джекобсон	C++, Small­talk	Два варианта: Analysis Workbench для ОО-ана-лиза и Design Workbench для проектирования. Связь с VisualWorks и C++ Softbench. BPR на основе метода Джекобсона.
6	Object Partner (ver. 2.0), Verilog	Unix	ОМТ	C++	Распространяет Verilog, а также LogLscope и Object-Geode
7	ObjectTeamEnter-prise (ver. 1) Cayenne Software	Unix	ОМТ	C++	Cayenne объединяет Cadre и Bachman technlotogy. Пользователям ObjectTeam (метод Шлеер/Меллор) предлагается обратиться к продуктам BridgePoint
8	ObjectMaker (ver. 4.2, 1995) MarkV	Unix, Windows 3.1, 95, NT	15 нотаций, в частности: Г.Буч, ОМТ, Шлеер/Меллор, Код/Йордон и др.	Ada '83, '95, C/C++, Smalltalk	Общий репозиторий в сети, командная работа. Есть локальный продукт ObjectMaker Consulant
9	ParadigmPlus (ver. 3.0) Platinum Technology (formerly Protosoft)	Unix, OS/2, Windows 3.1,95,NT	8 нотаций, в частности: Г.Буч, ОМТ, Шле- ер/Меллор, Fusion и гл.	Ada, C/C++, Smalltalk, Java	Генерация SQL, OO и реляционные БД. Реин- жиниринг для Forte, PowerBuilder, VisualWorks, Visual Smalltalk Enterprise, VisuaJAge, ObjectPro. Object- Store. OODB в качестве репозитория
10	Ptech (ver.4.0), Ptech Inc.	Windows 95, NT, Unix	Мар-тин/Оделл (OOIE)	C++, Forte 2.0	Интегрирован с Object-Store, Objectivity, ONTOS. Генерация кода для библиотек классов Tools.h++, USL
11	Rational Rose (ver. 3.0), Rational Software	Windows 3.1, 95, NT, Unix (Solaris, HP UX.AIX)	Г.Буч, ОМТ	Ada, C++, Smalltalk, Visual Basic, Java, Forte SQL, Windows, PowerBu ilder	Конвертация Буч/ОМТ. Поддержка Java, COBRA. Реинжиниринг кода из Forte SQLWindows, Power- Builder и ОО-языков. Объявлено о выпуске но- вого средства работы с COBRA.
12	System Architect Object (ver. 3.1), Popkin Software and System	Windows 3.1, OS/2	Г.Буч, ОМТ, Шле­ер/Меллор, Код/Йор — дон, CRC, И. Джекобсон	C++, Smaftaflc, Java	Поддержка структур­ных методологий. BPR на основе IDEF-диаграмм. Связь с PowerBuilder
13	Software through Pictures/OMT and BUCH (ver. 3.2), Interactive Development Environments	Unix	OMT или Г. Буч, И.Джекобсон	C++, Smalltalk, Java и OMGI DL	Есть продукты для структурных методоло­гий. CASE для BPR. Под­держка, Java, HTML, Netscape Navigator, COBRA, связь NetUnks Orbitaze, SN1FF+. Реинжиниринг
14	SES/Objectbench (ver. 2.2), Scientific and Engineering Software	Unix	ООА	C/C++	Объектно -ориентиро­ванный анализ
15	Together/C++, Object International	Windows 3. 1	Код/Йордон	C++	Версия для командной работы, работающая и под Windows 3.1

Сравнительный анализ таблицы показывает, чо лучшим CASE-средством является разработка компании Rational Software. Именно в ней был создан универсальный язык программирования.