 |
||
|
||
1.3. Объектно-ориентированные CASE-средства
1.3.1. Unified Modeling Language - Унифицированный Язык Моделирования
Как было указано выше, при разработке крупных проектов критичным становится время реализации проекта. Одним из решений проблемы может стать автоматическая генерация кода приложения CASE-средствами на основе модели предметной области. Хотя большинство средств решают эту задачу, код генерируется обычно основе реляционной модели данных (например, ERwin генерирует код на основе модели IDEF1X, т.е. фактически на основе реляционной модели данных), которая наряду с ее достоинствами обладает рядом недостатков (см. п.1.2.2).
Кроме того, классический структурный подход к созданию ИС предполагает последовательную реализацию этапов анализа, проектирования, создания модулей, объединения модулей в единую систему, тестирования и внедрения. Применение 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 [3].
Визуальное моделирование.
В последнее время наблюдается общее повышение интереса ко всем аспектам, связанным с разработкой сложных программных приложений. Для многих компаний корпоративное программное обеспечения и базы данных (БД) представляют стратегическую ценность. Существует высокая заинтересованность в разработке и верификации методов и подходов, позволяющих автоматизировать создание сложных программных информационных систем (ИС). Известно, что систематическое использование таких методов позволяет значительно улучшить качество, сократить стоимость и время поставки ИС. В настоящее время эти методы включают в себя:
Визуальные модели широко используются в существующих технологиях управления проектированием систем, сложность, масштабы и функциональность которых постоянно возрастают. В практике эксплуатации ИС постоянно приходится решать такие задачи как: физическое перераспределение вычислений и данных, обеспечение параллелизма вычислений, репликация БД, обеспечение безопасности доступа к ИС, оптимизация балансировки нагрузки ИС, устойчивость к сбоям и т.п.
Построение модели корпоративной ИС до ее программной разработки или до начала проведения архитектурной реконструкции столь же необходимо, как наличие проектных чертежей перед строительством большого здания. Хорошие модели ИС позволяют наладить плодотворное взаимодействие между заказчиками, пользователями и командой разработчиков. Визуальные модели обеспечивают ясность представления выбранных архитектурных решений и позволяют понять разрабатываемую систему во всей ее полноте. Сложность разрабатываемых систем продолжает увеличиваться, и поэтому возрастает актуальность использования "хороших" методов моделирования ИС. Язык моделирования, как правило, включает в себя:
Построение визуальных моделей позволяет решить сразу несколько типичных проблем. Во-первых, и это главное, технология визуального моделирования, позволяет работать со сложными и очень сложными системами и проектами. И не важно, преобладает ли в проекте "техническая сложность" (статическая) или "динамическая сложность управления". Сложность программных систем возрастает по мере создания новых версий. И в какой-то момент наступает "эффект критической массы", когда дальнейшее развитие ИС становиться невозможным, поскольку уже никто не представляет в целом "что и почему происходит". Происходит потеря управлением проектом. Внешней причиной или толчком возникновения этого неприятного эффекта может послужить, например, увольнение ведущего программиста или системного аналитика.
Во-вторых, визуальные модели позволяют содержательно организовать общение между заказчиками и разработчиками. Шутка о том, что "заказчик что-то хочет, но точно не знает, чего именно", с завидным постоянством часто оказывается былью. А если на начальном этапе работы над проектом ИС заказчик думает, что точно знает, что хочет, то, как правило, и об этом свидетельствует богатый опыт, его требования изменяются ("плывут") в ходе выполнения проекта. С одной стороны, аппетит приходит во время еды, а с другой, высокая динамика бизнеса объективно заставляет менять требования к разрабатываемой (или поддерживаемой) ИС.
Визуальное моделирование не является "серебряной пулей", способной раз и навсегда решить все проблемы, однако его использование существенно облегчает достижения таких целей как:
Если при проектировании информационная система разбивается на объекты (компоненты), то 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), которые подразделяются на:
Диаграммы состояний определяют модель конечного автомата, описывающего поведение класса. Каждое состояние класса задается своей вершиной, для которой определены входные и выходные состояния, а также условия перехода из состояния в состояние.
На рис.1.9 представлена диаграмма последовательности (временная диаграмма), которая демонстрирует поведение объектов во времени. Она показывает объекты и последовательность сообщений, посылаемых объектами. Диаграмма взаимодействий показывает последовательность сообщений, которые реализуют функционирование.
Рис.1.8. Диаграмма классов. Пакет “Обслуживание клиентов”
Рис.1.9. Временная диаграмма.
И, наконец, диаграммы реализации (implementation diagrams), с помощью которых описывается архитектура приложения, состоят из компонентных диаграмм (component diagrams) и диаграмм развертывания (deployment diagrams). На диаграммах компонентов изображается вхождение классов и объектов в программные компоненты системы (модули, библиотеки и т.д.). При помощи диаграмм развертывания документируется размещение программных модулей на узлах (физических и логических устройствах) системы.
Rational Rose 98 - это инструментальное средство визуального моделирования для создания сложных коммерческих приложений (или КИС - корпоративных информационных систем), ориентированное на разработчиков архитектуры информационных систем и программистов.
Rational Rose доминирует на рынке продуктов для объектно-ориентированного анализа, моделирования, проектирования и инструментальных средств разработки. International Data Corporation (IDC) - независимая фирма, лидирующая на рынке исследования технологий, в мае 1998 опубликовала отчет, в котором подтверждается, что доля Rational Rose в данном секторе рынка превышает суммарную долю продуктов следующих трех поставщиков вместе взятых и превышает более чем в три раза долю самого близкого конкурента.
Достоинства продукта состоят в следующем:
Rose 98 занимает уникальное место в этом ряду CASE-средств и имеет стратегическое преимущество в плане развития продукта, поскольку:
1. Поддерживает генерацию кода и обратное проектирование (т.е. построение модели по программному коду) для нескольких языков, включая:
2. Поддерживает визуальное моделирование, полностью совместимое с UML (Unified Modeling Language), который с 1997 года определен как стандарт языка для этой быстро развивающейся области инструментальных средств.
3. Имеет утилиты-"переходники" (Links), создаваемые многочисленными независимыми разработчиками инструментальных средств в рамках программы Rational Rose Link Partner Program.
Этапы проведения моделирования в Rational Rose 98
Проектирование в Rational Rose 98 реализуется как дисциплинированный и упорядоченный подход, который используется для итерационного "изобретения" решения заданной проблемы. Это обеспечивает "движение модели" от требований заказчика к программной реализации. Цель проектирования состоит в том, чтобы полученная система:
1. Удовлетворяла заданным (возможно неформальным) спецификациям.
2. Соответствовала ограничениям целевой вычислительной аппаратуры.
3. Удовлетворяла (явным и/или неявным) требованиям на производительность и используемые ресурсы.
4. При ее разработке были выполнены ограничения на сам процесс проектирования по цене, времени, и т.п.
При построении общей модели в Rational Rose 98 используются принципы:
Моделирование проводится как "поуровневый спуск" от концептуальной модели к логической, а затем к физической модели программной системы. Концептуальная модель выражается в виде "диаграмм прецедентов" (use case diagram). Внутри каждого прецедента могут быть определены:
Логическая модель позволяет определять два различных взгляда на системы: статический и динамический. Статическая модель выражается Диаграммами классов (Class diagram). Именно диаграммы классов служат основой для генерации программного кода на целевом языке программирования. Возможна очень гибкая настройка генерации кода, позволяющая учитывать конкретные соглашения (например, по префиксам имен идентификаторов), принятые в команде разработчиков проекта.
Динамически модели задаются двумя типами диаграмм:
В текущей версии Rational Rose 98 эти диаграммы не влияют на генерируемый код, однако, существуют приложения фирм-партнеров Rational Software, использующие эти диаграммы в своих приложениях. Так, последовательные диаграммы используются в пакете SQA Suite для автоматизированного проведения тестирования компонент, разработанных в Rational Rose 98. Классы, введенные на этих диаграммах, попадают в список классов модели и могут использоваться при конструировании диаграмм классов.
Физическая модель задается компонентной диаграммой (Component diagram), описывающей распределение классов по модулям, и диаграммой развертывания (Deployment diagram).
После построения "первого/последующего слоя" статической модели с использование диаграмм классов, можно провести генерацию кода на целевом языке программирования. На уровне кода можно ввести новые "уточняющие" классы, изменить атрибуты и методы классов модели и затем синхронизовать код и модель, выполнив "обратное проектирование". Т.е. по модифицированному коду Rational Rose 98 позволяет построить новую логическую модель взаимосвязи классов между собой! Повторение такой процедуры несколько раз называется итерационным моделированием (round-trip modeling), которое составляет основу мягкого и постепенного уточнения постановки задачи и согласования требований заказчика с имеющимися ресурсами (вычислительными, временными, финансовыми и т.п.).
Rational Rose 98 предназначен для генерации клиентской части приложения, но сгенерированный код не является готовым приложением. Здесь генерируются лишь заголовки методов, сами методы необходимо дописывать в ручную. Для генерации схемы БД нужно использовать другие системы. Например, объектную модель Rational Rose можно конвертировать, используя модуль ERwin Translation Wizard, в модель данных IDEF1X, поддерживаемую в ERwin. ERwin позволяет сгенерировать схему БД на любой из поддерживаемых СУБД.
| Site of Information
Technologies Designed by inftech@webservis.ru. |
|