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

Предыдущая часть

(c) 2000 Семизельникова О.А.

Эта статья была размещена на сайте www.inftech.webservis.ru/

1.3. Объектно-ориентированные CASE-средства

• 1.3.1. Unified Modeling Language - Унифицированный Язык Моделирования

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

Кроме того, классический структурный подход к созданию ИС предполагает последовательную реализацию этапов анализа, проектирования, создания модулей, объединения модулей в единую систему, тестирования и внедрения. Применение CASE-средств и CASE-технологий, подобных ERwin и BPwin, позволяет в несколько раз сократить время разработки (а как следствие – более качественного планирования и проектирования) и автоматической генерации структуры сервера БД и кода клиентского приложения. Однако эта технология не лишена недостатков. Код клиентского приложения генерируется на основе информации о структуре БД. К структуре БД предъявляются определенные требования (нормализации), в результате чего данные хранятся в таблицах БД не всегда в той форме, в которой они должны представляться на экранных формах. Другими словами, если код приложения генерируется не на основе описания предметной области, невозможно построить эффективное приложение со сложной логикой. Кроме того, при структурном подходе к разработке ИС риск остается большим на всех этапах создания системы вплоть до этапа тестирования, когда мы можем обнаружить опущенные ошибки и оценить состоятельность системы. В случае обнаружения ошибки необходимо вернуться на тот этап разработки, на котором допущена ошибка, и заново пройти последующие этапы.

Альтернативой структурному подходу стали лишенные перечисленных недостатков объектно-ориентированные методы разработки ИС. В первой половине 90-х годов был предложен разработанный на основе наиболее популярных объектных методов ОМТ (Rumbaudh), Booch и OOSE (Jacobsom) универсальный язык объектного проектирования – Unified Modeling Language, UML.

Существует несколько CASE-средств, поддерживающих язык UML. Наиболее известным являются PLATINUM Paradigm Plus фирмы PLATINUM technology и выпущенный фирмой Rational Software программный пакет Rational Rose. Эти инструменты позволяют генерировать код приложения в полной мере отвечающий бизнес-правилам, и с наименьшим риском.

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

Модель представляет собой совокупность диаграмм, описывающих различные аспекты структуры и поведения ИС. В дальнейшем в качестве примера будет описана объектная модель, построенная в Rational Rose 98.

1.3.1. Unified Modeling Language - Унифицированный Язык Моделирования

UML – это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997г., и на сегодняшний день она поддерживается многими объектно-ориентированным CASE продуктами, включая Rational Rose 98i.

Визуальное моделирование.

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

• компонентную технологию разработки моделей ИС,
• визуальное программирование (RAD средства),
• использование образцов (patterns) при проектировании ИС,
• визуальное представление различных аспектов проекта (визуальное моделирование, CASE - средства)

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

Построение модели корпоративной ИС до ее программной разработки или до начала проведения архитектурной реконструкции столь же необходимо, как наличие проектных чертежей перед строительством большого здания. Хорошие модели ИС позволяют наладить плодотворное взаимодействие между заказчиками, пользователями и командой разработчиков. Визуальные модели обеспечивают ясность представления выбранных архитектурных решений и позволяют понять разрабатываемую систему во всей ее полноте. Сложность разрабатываемых систем продолжает увеличиваться, и поэтому возрастает актуальность использования "хороших" методов моделирования ИС. Язык моделирования, как правило, включает в себя:

• элементы модели - фундаментальные концепции моделирования и их семантику;
• нотацию - визуальное предоставление элементов моделирования;
• принципы использования - правила применения элементов в рамках построения тех или иных типов моделей ИС.

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

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

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

• повышение качества программного продукта,
• сокращение стоимости проекта,
• поставка системы в запланированные сроки.

Если при проектировании информационная система разбивается на объекты (компоненты), то UML может быть использован для ее визуального моделирования. Если используется функциональная декомпозиция ИС, то UML не нужен, и следует использовать другие (структурные) нотации.

Отдельная тема для обсуждения – нужно ли программировать в объектах (компонентах)? Споры на эту тему относятся к разряду “религиозных войн”. Есть убежденные сторонники в обоих лагерях. Уместно заметить, что все современные RAD-средства программирования используют библиотеки компонент, позволяющие повторно использовать отлаженный программный код, что значительно облегчает сборку программных приложений. Такое "сборочное программирование" стало возможным за счет использования объектов и привело к изменению квалификационной оценки программистов за рубежом - "программист - это тот, кто умеет программировать в компонентах", т.е. это не "писатель программного кода", как принято считать у нас.

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

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

Унифицированный Язык Моделирования (UML):

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

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

Что можно рисовать на UML

При визуальном моделировании на UML используются восемь видов диаграмм, каждая из которых может содержать элементы определенного типа. Типы допустимых элементов и отношений между ними зависят от вида диаграммы. Рассмотрим некоторые диаграммы.

Диаграммы использования системы (диаграммы прецедентов, Use Cases) Этот тип диаграмм служит для проведения итерационного цикла общей постановки задачи вместе с заказчиком (рис.1.6). Поскольку заказчик "... и раньше не знал, и теперь не знает, и в обозримом будущем не будет точно знать, что ему нужно. И это не "злой умысел", а объективная реальность", то диаграммы прецедентов как раз и служат основой для достижения взаимопонимания между программистами-профессионалами, разрабатывающими проект, и "бизнесменами" - заказчиками проекта. Эти диаграммы описывают функциональность ИС, которая будет видна пользователям системы, основные функции, которые должны быть включены в систему (use case), их окружение (actors). "Каждая функциональность" изображается в виде "прецедентов использования" (use case) или просто прецедентов. Прецедент - это типичное взаимодействия пользователя с системой, которое при этом:

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

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

Диаграммы Use Cases включают отношения и ассоциации, показывающие взаимодействие между воздействующими объектами и функциями (изображаются в виде стрелок), и примечания (note), которые могут быть привязаны к любому объекту диаграммы Use Cases.

Рис.1.6.Диаграмма использования

Диаграммы классов (class diagrams). Диаграммы классов описывают статическую структуру классов. Эти диаграммы могут описывать "словарь предметной области" на концептуальном уровне. С другой стороны, на детальном уровне (уровне спецификаций и уровне реализаций) диаграммы определяют структуру программных классов. Они используются для генерации каркасного программного кода на заданном языке программирования, а также для генерации SQL DDL предложений, определяющих логическую структуру реляционных таблиц БД.

Под объектом в UML понимается некоторое абстрактное представление конкретного объекта предметной области. Каждый объект имеет состояние, поведение и индивидуальность. Поведение объекта определяет, как объект взаимодействует с другими объектами. Индивидуальность означает, что каждый объект уникален и отличается от других объектов. Под классом понимается описание объектов, обладающих общими свойствами (атрибутами), поведением, общими взаимоотношениями с другими объектами и общей семантикой. Класс является шаблоном для создания новых объектов. Если система содержит большое количество классов, они могут быть объединены в пакеты (рис. 1.7, 1.8).

Каждый класс может иметь атрибуты (свойства). Так на рис.1.8 класс BankAccountServant имеет атрибут balance_. Кроме того, каждый класс может иметь методы – некоторые действия, описывающие поведение объектов класса. На рис.1.8 класс BankAccountServant имеет методы BankAccountServant( ), Balance( ),   Type(),AcctNumber( ).

Классы могут иметь взаимосвязи, называемые отношениями. В нотации UML имеются несколько типов отношений. Отношение использование показывает, что объект одного класса связан с одним или несколькими объектами другого класса. Отношение включения показывает, что один объект является частью другого. Отношение наследования описывает взаимосвязь между классами, когда один класс (подкласс) наследует структуру и/или поведение одного или нескольких классов. На рис.1.8 подкласс BankAccountServant наследует свойства и поведение класса _BankAccountImplBase.

Рис.1.7. Диаграмма классов (основной вид)

Для описания динамики используются диаграммы поведения (behavior diagrams), которые подразделяются на:

• диаграммы состояний (statechart diagrams),
• диаграммы активностей (activity diagrams) и
• диаграммы взаимодействия (interaction diagrams), состоящие из:

• диаграмм последовательности (sequence diagrams)
• диаграмм взаимодействий (collaboration diagrams)

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

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

Рис.1.8. Диаграмма классов. Пакет “Обслуживание клиентов”

Рис.1.9. Временная диаграмма.

И, наконец, диаграммы реализации (implementation diagrams), с помощью которых описывается архитектура приложения, состоят из компонентных диаграмм (component diagrams) и диаграмм развертывания (deployment diagrams). На диаграммах компонентов изображается вхождение классов и объектов в программные компоненты системы (модули, библиотеки и т.д.). При помощи диаграмм развертывания документируется размещение программных модулей на узлах (физических и логических устройствах) системы.

Продолжение статьи

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Отправить ссылку на страницу по e-mail
Обсудить на форуме