Объектно-ориентированные среды для автоматизированного проектирования и разработки программного обеспечения (CASE-средства)
На данный момент в технологии разработки программного обеспечения существуют два основных подхода к разработке программных систем, отличающиеся критериями декомпозиции: функционально-модульный (структурный) и объектно-ориентированный.
Функционально-модульный подход основан на принципе алгоритмической декомпозиции с выделением функциональных элементов и установлением строгого порядка выполняемых действий.
Объектно-ориентированный подход основан на объектной декомпозиции с описанием поведения системы в терминах взаимодействия объектов.
Главным недостатком функционально-модульного подхода является однонаправленность информационных потоков и недостаточная обратная связь. В случае изменения требований к системе это приводит к полному перепроектированию, поэтому ошибки, заложенные на ранних этапах, сильно сказываются на продолжительности и стоимости разработки. Другой важной проблемой является неоднородность информационных ресурсов, используемых в большинстве информационных систем. В силу этих причин в настоящее время наибольшее распространение получил объектно-ориентированный подход.
Под CASE-технологией будем понимать комплекс программных средств, поддерживающих процессы создания и сопровождения программного обеспечения, включая анализ и формулировку требований, проектирование, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом (CASE-средство может обеспечивать поддержку только в заданных функциональных областях или в широком диапазоне функциональных областей).
В связи с наличием двух подходов к проектированию программного обеспечения существуют CASE-технологии ориентированные на структурный подход, объектно-ориентированный подход, а также комбинированные. Однако сейчас наблюдается тенденция переориентации инструментальных средств, созданных для структурных методов разработки, на объектно-ориентированные методы, что объясняется следующими причинами:
• возможностью сборки программной системы из готовых компонентов, которые можно использовать повторно;
• возможностью накопления проектных решений в виде библиотек классов на основе механизмов наследования;
• простотой внесения изменений в проекты за счет инкапсуляции данных;
• быстрой адаптацией приложений к изменяющимся условиям за счет использования свойств наследования и полиморфизма;
• возможностью организации параллельной работы аналитиков, проектировщиков и программистов.
Существует несколько объектно-ориентированных методов. В настоящее время наблюдается процесс сближения объектно-ориентированных методов. В частности, разработан унифицированный метод UML (Unified Modeling Language – унифицированный язык моделирования).
Классическая постановка задачи разработки программной системы (инжиниринг) представляет собой спиральный цикл итерационного чередования этапов объектно-ориентированного анализа, проектирования и реализации (программирования).
В реальной практике в большинстве случаев имеется предыстория в виде совокупности разработанных и внедренных программ, которые целесообразно использовать при разработке новой системы. Процесс проектирования в таком случае основан на реинжиниринге программных кодов, при котором путем анализа текстов программ восстанавливается исходная модель программной системы.
Современные CASE-средства поддерживают процессы инжиниринга и автоматизированного реинжиниринга.
Идеальное объектно-ориентированное CASE-средство (рисунок) должно содержать четыре основных блока: анализ, проектирование, реализация и инфраструктура.
| Анализ | Проектирование | Реализация | |
| Возможность добавлять пояснительные надписи к диаграммам и в документацию | Возможность создавать различные представления и скрывать ненужные в данный момент слои системы | Возможность просматривать и выбирать элементы и бизнес-объекты для использования в системе | Возможность генерировать заготовки программного кода на нескольких объектно-ориентированных языках |
| Среда для создания диаграмм разнообразных моделей | Возможность создания пользовательского интерфейса (поддержка OLE, ActiveX, OpenDoc, HTML) | Возможность проверки программного кода на синтаксическую корректность | |
| Поддержка различных нотаций | Возможность динамического моделирования событий в системе | Возможности определения бизнес-модели и бизнес-правил | Возможность генерировать код для 4GL и клиент-серверных продуктов |
| Возможность генерации документации для печати | Возможность динамической коррекции одной диаграммы из другой | Возможность связи с объектно-ориентированными базами данных и распределенными модулями (поддержка CORBA, DCOM, HTML) | |
| Инфраструктура | |||
| Контроль версий. Блокирование и согласование частей системы при групповой разработке | Репозиторий | Возможность реинжиниринга программного кода, 4GL, клиент-серверных систем в диаграммы моделей |
Рисунок – Идеальное объектно-ориентированное CASE-средство
Основные требования к блоку анализа:
• возможность выбора выводимой на экран информации из всей совокупности данных, описывающих модели;
• согласованность диаграмм при хранении их в репозитории;
• внесение комментариев в диаграммы и соответствующую документацию для фиксации проектных решений;
• возможность динамического моделирования в терминах событий;
Основные требования к блоку проектирования:
• поддержка всего процесса проектирования программной системы;
• возможность работы с библиотеками, средствами поиска и выбора;
• возможность разработки пользовательского интерфейса;
• поддержка стандартов OLE, ActiveX и доступ к библиотекам HTML или Java;
• поддержка разработки распределенных или двух- и трехзвенных клиент-серверных систем (работа с CORBA, DCOM).
Основные требования к блоку реализации:
• генерация кода полностью из диаграмм;
• возможность доработки приложений в клиент-серверных CASE-средствах;
• реинжиниринг кодов и внесение соответствующих изменений в модель системы;
• наличие средств контроля, которые позволяют выявлять несоответствие между диаграммами и генерируемыми кодами и обнаруживать ошибки как на стадии проектирования, так и на стадии реализации.
Основные требования к блоку инфраструктуры:
• наличие репозитория на основе базы данных, отвечающего за генерацию кода, реинжиниринг, отображение кода на диаграммах, а также обеспечивающего соответствие между моделями и программными кодами;
• обеспечение командной работы (многопользовательской работы и управление версиями) и реинжиниринга.
Выделим основные критерии оценки и выбора CASE-средств:
1) функциональные характеристики:
• среда функционирования: проектная среда, программное обеспечение/технические средства;
• функции, ориентированные на фазы жизненного цикла: моделирование, реализация, тестирование;
• общие функции: документирование, управление конфигурацией, управление проектом.
2) надежность;
3) простота использования;
4) эффективность;
5) сопровождаемость;
6) переносимость;
7) общие критерии (стоимость, затраты, эффект внедрения, характеристики поставщика).
3.3 Характеристика унифицированного языка моделирования UML. Диаграмма вариантов использования – концептуальная модель программной системы
Язык UML (Unified Modeling Language) предназначен для описания, визуализации и документирования программных систем в процессе их создания.
Классы диаграмм (моделей) языка UML:
• структурные диаграммы (статические модели) – описывают структуру сущностей или компонентов проектируемой системы, включая их классы, интерфейсы, атрибуты и отношения;
• поведенческие диаграммы (динамические модели) – описывают поведение или функционирование объектов системы, включая их методы, взаимодействие и сотрудничество между ними, а также процесс изменения состояний отдельных компонентов и системы в целом.
К структурным диаграммам относятся:
• диаграммы пакетов или контейнеров;
• диаграммы классов;
• диаграммы объектов;
• диаграммы компонентов;
• диаграммы развертывания.
К поведенческим диаграммам относятся:
• диаграммы вариантов (прецедентов) использования;
• диаграммы активности (деятельности);
• диаграммы состояний;
• диаграммы связей;
• диаграммы последовательностей;
• диаграммы взаимодействия.
Диаграммы пакетов используются для разделения модели программной системы на пакеты и для описания межпакетного взаимодействия. Цель разделения – упрощение структуры и организации работы с моделью системы. Одни пакеты могут быть вложены в другие. Целесообразно классы, разделяющие одно и то же пространство имен или связанные отношениями наследования, помещать в один пакет, пакеты будут соответствовать папкам в памяти компьютера.
В диаграммах классов отображаются классы и их связи. Класс характеризуется именем, атрибутами, операциями (методами). Операция – абстракция того, что можно делать с объектом класса. Класс может содержать любое число операций (в частности, не содержать ни одной операции). Набор операций класса является общим для всех объектов данного класса.
Диаграммы объектов служат для более детального представления классов и их элементов (объектов).
Диаграммы компонентов иллюстрируют структуру системы в виде множества составляющих ее частей, таких как программные компоненты (обычно представляющие собой некоторые совокупности классов), встроенные контроллеры и т.п.
Диаграммы развертывания служат для показа распределения компонентов между физическими устройствами.
Диаграммы активности предназначены для моделирования потока действий, включая генерируемые процессы и точки принятия решений.
Диаграммы состояний служат для описания поведения отдельного объекта в терминах его состояний и переходов из состояния в состояние. Диаграммы состояний являются основой для полностью автоматической генерации исполняемого кода по UML-моделям.
Диаграмма последовательностей представляет сценарий передачи сообщений между объектами или между элементами диаграммы вариантов использования.
Диаграммы взаимодействия аналогичны диаграммам активности, но они отражают связи не между операциями, а между другими диаграммами.
Диаграмма вариантов использования характеризует функциональность программной системы с позиций пользователя и служит для отображения взаимодействия пользователя с системой. В диаграмме в виде овалов представляются варианты (прецеденты) использования, то есть те функции, которые выполняет программная система. Пользователи (актеры) изображаются в виде стилизованных фигурок «человечков», ими могут быть не только люди, но и любые внешние системы (программные комплексы, технические устройства), пользующиеся услугами данной программной системы. Основными типами отношений между пользователями и вариантами использования, между двумя вариантами использования являются:
отношения ассоциации, изображаемые отрезками сплошных прямых и соединяющие пользователей и варианты использования;
отношения включения, изображаемые отрезками пунктирных прямых со стрелками на конце, над которыми пишется ключевое слово «include», и соединяющие варианты использования.
Отношение включения, направленное от базового варианта использования к включаемому варианту использования, указывает, что каждый экземпляр базового варианта включает в себя функциональные свойства, заданные для включаемого варианта. Эти свойства специализируют поведение базового варианта на данной диаграмме.
Например, пользователями программного комплекса для выбора геометрических параметров процесса вакуумформования изделий типа «круговой цилиндр» являются проектировщик формующих матриц и разработчик программного комплекса. UML-диаграмма вариантов использования программного комплекса проектировщиком представлена на рисунке.
Рисунок – Диаграмма вариантов использования программного комплекса конечным пользователем
UML-диаграмма вариантов использования программного комплекса для моделирования процесса нагрева полимерных материалов представлена на рисунке.
Рисунок – Диаграмма вариантов использования программного комплекса администратором