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

Введение

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

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

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1. CASE-технологии

 

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

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

 возможностью  сборки программной системы из  готовых компонентов, которые можно использовать повторно;

 возможностью  накопления проектных решений  в виде библиотек классов на  основе механизмов наследования;

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

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

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

 Концепции  объектно-ориентированного подхода  и распределенных вычислений стали базой для создания консорциума Object Management Group (OMG), членами которой являются более 500 ведущих компьютерных компаний (Sun, DEC, IBM, HP, Motorola и др.). Основным направлением деятельности консорциума является разработка спецификаций и стандартов для создания распределенных объектных систем в разнородных средах. Базисом стали спецификации под названием Object Management Architecture (ОМА).

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

 архитектура  брокера запросов объектов (CORBA - Common Object Request Broker Architecture) определяет  механизмы взаимодействия объектов  в разнородной сети;

 объектные  сервисы (Object Services) являются основными  системными сервисами, используемыми разработчиками для создания приложений;

 универсальные  средства (Common Facilities) являются высокоуровневыми  системными сервисами, ориентированными  на поддержку пользовательских  приложений (электронная почта, средства  печати и др.);

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

 Исходя из  основных положений объектно-ориентированного  подхода рассмотрим концепцию  идеального объектно-ориентированного CASE-средства.

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

 Классическая  постановка задачи разработки  программной системы (инжиниринг) представляет собой спиральный  цикл итеративного чередования  этапов объектно-ориентированного анализа, проектирования и реализации (программирования).

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

 Современные  CASE-средства поддерживают процессы  инжиниринга и автоматизированного реинжиниринга.

 Идеальное  объектно-ориентированное CASE-средство  должно содержать четыре основных  блока: анализ, проектирование, разработка  и инфраструктура.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 Сравнительный анализ CASE-систем показывает, что на сегодняшний день одним из наиболее приближенных к идеальному варианту CASE-средств является семейство Rational Rose фирмы Rational Software Corporation. Следует отметить, что именно здесь работают авторы унифицированного языка моделирования Г. Буч, Д. Рамбо и И. Джекобсон, под руководством которых ведется разработка нового CASE-средства, поддерживающего UML.

 Выделим основные критерии  оценки и выбора CASE-средств. Функциональные  характеристики:среда функционирования: проектная среда, программное обеспечение/технические средства, технологическая среда; функции, ориентированные на фазы жизненного цикла: моделирование, реализация, тестирование; общие функции: документирование, управление конфигурацией, управление проектом; Надежность; Простота использования; Эффективность; Сопровождаемость; Переносимость;

Общие критерии (стоимость, затраты, эффект внедрения, характеристики поставщика).

 

 

2. Диаграмма последовательности (sequence diagram)

 

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

 

Объекты

На диаграмме последовательности изображаются только те объекты, которые  непосредственно участвуют во взаимодействии. Ключевым моментом для диаграмм последовательности является динамика взаимодействия объектов во времени.

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

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

Вторым измерением диаграммы  последовательности является вертикальная временная ось, направленная сверху вниз. Начальному моменту времени соответствует самая верхняя часть диаграммы. Взаимодействия объектов реализуются посредством сообщений, которые посылаются одними объектами другим. Сообщения изображаются в виде горизонтальных стрелок с именем сообщения, а их порядок определяется временем возникновения. То есть, сообщения, расположенные на диаграмме последовательности выше, инициируются раньше тех, которые расположены ниже. Масштаб на оси времени не указывается, поскольку диаграмма последовательности моделирует лишь временную упорядоченность взаимодействий типа «раньше-позже».

Линия жизни объекта

Линия жизни объекта (object lifeline) изображается пунктирной вертикальной линией, ассоциированной с единственным объектом на диаграмме последовательности. Линия жизни служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях. Если объект существует в системе постоянно, то и его линия жизни должна продолжаться по всей плоскости диаграммы последовательности от самой верхней ее части до самой нижней.

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

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

Фокус управления

В процессе функционирования объектно-ориентированных систем одни объекты могут находиться в активном состоянии, непосредственно выполняя определенные действия, или состоянии пассивного ожидания сообщений от других объектов. Чтобы явно выделить подобную активность объектов, в языке UML применяется специальное понятие, получившее название фокуса управления (focus of control). Фокус управления изображается в форме вытянутого узкого прямоугольника, верхняя сторона которого обозначает начало получения фокуса управления объекта (начало активности), а его нижняя сторона - окончание фокуса управления (окончание активности). Прямоугольник располагается ниже обозначения соответствующего объекта и может заменять его линию жизни, если на всем ее протяжении он является активным.

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

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