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

21

7. CASE-технологии в системной инженерии

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

временной CASE-технологии анализа и проектирования информационных систем со-

ставляют:

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

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

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

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

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

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

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

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

Основная цель использования CASE-технологий в системной инженерии за-

ключается в максимальной автоматизации стадий анализа и концептуального проек-

тирования систем с целью построения формальных и непротиворечивых моделей сис-

темы.

Анализ является первым этапом создания ИС, на котором требования заказчика уточняются, формализуются и документируются. Фактически на этом этапе дается от-

вет на вопрос: «Что должна делать будущая система?». Именно здесь лежит ключ к успеху всего проекта.

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

22

мы с помощью ее графического модельного представления, которое начинается с об-

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

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

фикации, а также генерация функционального описания системы.

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

первых, необходимо понять, что предполагается сделать, а во-вторых, — документи-

ровать выдвинутые предложения, так как если проектные требования не зафиксирова-

ны и не сделаны доступными для участников разработки, то они вроде бы и не суще-

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

Вот проблемы, с которыми сталкиваются участники проекта ИС:

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

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

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

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

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

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

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

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

ла ИС.

23

В упрощенном виде применение структурного анализа выглядит как создание нескольких типов моделей (рис. 7.1).

Рис. 7.1

Как правило, разработка каждой последующей модели начинается еще до пол-

ного завершения разработки предыдущей, а иногда работы ведутся параллельно. В хо-

де разработки моделей специфицируются:

внешние условия работы системы;

функциональная структура системы;

распределение функций между человеком и системой, интерфейсы;

требования к техническим, информационным и программным компонентам системы;

условия эксплуатации.

Разработка перечисленных выше спецификаций при создании ИС, предназна-

ченной для автоматизации управленческих процессов, в общем случае, проходит че-

тыре стадии.

Структурный анализ начинается с исследования того, как организована сис-

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

ти, отображающую ее функциональную структуру, особенности основной деятельно-

сти и информационное пространство, в котором эта деятельность осуществляется. Ис-

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

формате «как есть».

24

Вторая стадия работы, к которой привлекаются заинтересованные представи-

тели заказчика, а при необходимости и независимые эксперты, состоит в анализе мо-

дели «как есть», выявлении ее недостатков и узких мест, определении путей совер-

шенствования системы управления на основе согласованных критериев качества.

Третья стадия анализа, содержащая элементы проектирования, — создание усовершенствованной обобщенной логической модели, отображающей реорганизо-

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

дель называют моделью в формате «как надо».

На четвертой стадии процесс заканчивается разработкой «карты автоматиза-

ции», представляющей собой модель реорганизованной предметной области, на кото-

рой обозначены «границы автоматизации».

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

перечисленных определений и спецификаций, также сведения об очередности созда-

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

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

Главная особенность рассмотренных процессов состоит в концентрации слож-

ности на начальных этапах ЖЦ (анализ, концептуальное проектирование) при мень-

шей сложности и трудоемкости последующих этапов. Это наглядно видно из структу-

ры процесса проектирования автоматизированной системы по ГОСТ 34.601-90

(табл. 2.1), где видно, что рабочая документация проекта создается на шестой его ста-

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

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

25

8.CASE-технологии в программной инженерии

Вистории проектирования программного обеспечения для компьютеров нико-

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

Структура процесса проектирования программного обеспечения была рассмот-

рена в разделе 4. Результат выполнения каждого этапа ЖЦ — определенный набор до-

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

CASE-технологии успешно применяются на всех этапах ЖЦ ПО. К числу наи-

более востребованных CASE-технологий относятся следующие.

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

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

интеграция данных;

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

интеграция представления (изображения).

Базовые ИТ различного назначения (СУБД, компиляторы, отладчик, текстовые редакторы, оболочки экспертных систем, баз знаний и т.д.).

Графические технологии (диаграммеры), обеспечивающие:

создание иерархически связанных диаграмм, в которых сочетаются графические и текстовые объекты;

создание и редактирование объектов в любом месте диаграммы;

создание, перемещение и выравнивание групп объектов, изменение их размеров, масштабирование;

сохранение связей между объектами при их перемещении и изменении размеров.

Технологии управления требованиями.

Технологии управления конфигурацией ПО.

Технологии документирования.

Технологии тестирования.

Технологии управления проектом.

Технологии реверсного инжиниринга ПО и БД.

26

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

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

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

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

Технологии автоматизированной или автоматической кодогенерации для:

получения документации;

формирования БД, ввода и модификации данных;

получение выполняемых машинных кодов из спецификаций ПО;

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

автоматической конверсии файлов в новые форматы.

9. CASE– средства

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

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

27

Рис. 9.1

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

Наиболее информативной представляется классификация CASE-средств по функциональности. В этом случае классификация CASE-средств будет практически совпадать с перечнем CASE-технологий, приведенном в разделе 8.

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

В качестве примера ниже приведено краткое описание CASE-средства Rational Rose (рис. 9.2).

28

Рис. 9.2

Rational Rose [7] — средство, предназначенное для автоматизации этапов анализа и проектирования ПО, а также, для генерации кодов на различных языках программирования и выпуска проектной документации.

Конкретный вариант Rational Rose определяется языком, на котором генериру-

ются коды программ (C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro).

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

Рассмотрим версию продукта IBM Rational Rose V2003.06.13.

1.Продукт поддерживает следующие типы UML-диаграмм:

Use case diagram (диаграммы прецедентов);

Deployment diagram (диаграммы развертывания);

Statechart diagram (диаграммы состояний);

Activity diagram (диаграммы активности);

Interaction diagram (диаграммы взаимодействия);

29

Sequence diagram (диаграммы последовательностей действий);

Collaboration diagram (диаграммы коопераций);

Class diagram (диаграммы классов);

Component diagram (диаграммы компонент).

2.Поддерживает генерацию исходного кода для языков C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro.

3.Поддерживается обратный инжиниринг для C++, Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro.

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

5.Интегрируется с MS Visual Studio 6 (в ключает поддержку на уровне прямой

иобратной генерации кодов и диаграмм Visual Basic и Visual С++ с использованием

ATL (Microsoft Active Template Library), WebКлассов, DHTML и протоколов доступа к различным базам данных). Также есть возможность интеграции с любой системой контроля, совместимой со стандартом интерфейса прикладного программирования

SCC, в том числе с IBM Rational ClearCase.

6.Интегрируется со средством PVCS для организации групповой работы и управления проектом. Для организации групповой работы в Rational Rose возможно разбиение модели на управляемые подмодели. Каждая из них независимо сохраняется на диске или загружается в модель.

7.Для документирования проектов интегрируется со средством SoDA.

8.Функционирует на различных платформах: в среде Windows, Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX)

9.Цена лицензии составляет от $2000 до $ 12000.

10.Реализована возможность отмены/повтора действий пользователя.

11.Другие функциональные возможности Rational Rose:

непосредственная работа (инжиниринг и обратный инжиниринг) с исполняемыми модулями и библиотеками форматов EXE, DLL, TLB, OCX;

поддержка технологий MTS (Microsoft Transaction Server) и ADO (ActiveX Data Objects) на уровне шаблонов и исходного кода, а также элементов технологии Microsoft - COM+ (DCOM);

30

полная поддержка компонентов CORBA и J2EE, включая реализацию технологии компонентной разработки приложений CBD (Component-

Based Development), языка определения интерфейса IDL (Interface Definition Language) и языка определения данных DDL ( Data Definition

Language );

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

иобратную генерацию классов Java формата JAR , а также работу с файлами формата CAB и ZIP.

Еще один пример — CA ERwin Modeling фирмы Computer Associates (рис. 9.3.).

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

Главными инструментами CA ERwin Modeling являются ERwin Process Modeler (ранее: BPwin) и ERwin Data Modeler (ранее: ERwin).

CA ERwin® Process Modeler — ведущий инструмент для моделирования биз- нес-процессов. Позволяет оптимизировать деятельность организации и проверить ее на соответствие стандартам ISO9000, спроектировать оргструктуру, снизить издержки, исключить ненужные операции и повысить эффективность. Являясь стандартом дефакто, BPwin поддерживает сразу три нотации моделирования: IDEF0, IDEF3 и DFD.