Студопедия

Главная страница Случайная страница

Разделы сайта

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника






Язык UML






 

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

Альтернативой структурному подходу стали лишенные перечисленных недостатков объектно-ориентированные методы разработки ИС. В первой половине 90-х годов был предложен разработанный на основе наиболее популярных объектных методов ОМТ (Rumbaudh), Booch и OOSE (Jacobsom) универсальный язык объектного проектирования - Unified Modeling Language, UML (The Unified Method, Draft Edition [0.8]. Rational Software Corporation, October 1995).

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

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

Модель представляет собой совокупность диаграмм, описывающих раз­личные аспекты структуры и поведения ИС. В дальнейшем в качестве при­мера будет описана объектная модель, построенная в Rational Rose for Java (version 4.0). Для просмотра модели в Rational Rose используется иерархи­ческий навигатор модели - Browser (рис. 5.1).

 

Рис. 5.1. Навигатор модели в Rational Rose - Browser

 

Рассмотрим в общих чертах некоторые диаграммы UML.

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

 

Рис. 5.2. Диаграмма Use Cases. Здесь Customer, Salespeople - Actors; Register for Order, Validate User - Use case

 

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

 

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

Если система содержит большое количество классов, они могут быть объединены в пакеты (package).

Каждый класс может иметь атрибуты (свойства). Так, на рис. 5.3 класс Customer Information (информация о клиенте) имеет атрибуты Customer lD (идентификатор клиента), Name (имя) и Account (счет). Кроме того, каждый класс может иметь методы (operations) - некоторые действия, которые описывают поведение объектов класса. На рис. 5.3 класс Customer Information имеет метод Check Account. Для внесения свойств класса следует правой кнопкой мыши щелкнуть по классу и выбрать во всплывающем меню пункт Specification.

 

 

Рис. 5.3. Диаграмма классов

 

Классы могут иметь взаимосвязи (relationship), называемые отношениями. В нотации UML имеется несколько типов отношений. Отношение использования (associations, кнопка палитры инструментов) показывает, что объект одного класса связан с одним или несколькими объектами другого класса. Отношение включения (aggregation, кнопка ) является част­ным случаем отношения использования. Оно показывает, что один объект является частью другого. При воздействии на один объект, связанный отношением включения, некоторые операции автоматически могут затронуть другой объект. Например, на рис. 5.3 класс Customer Information связан отношением включения с классом Contract. При удалении объекта класса Customer Information (информация о клиенте) должны удаляться вес объекты класса Contract (относящиеся к данному клиенту контракты). Каждая связь может быть охарактеризована определенной фразой, называемой именем роли. Связь между классами Customer Information и Contract имеет имя negotiates. Каждая связь может иметь индикатор множественности, который показывает, сколько объектов одного класса соответствует объект другого класса. На рис. 5.3 связь negotiates имеет индикатор 1..* (один или много).

Наследование (inheritance) описывает взаимосвязь между классами, когда один класс (называется подклассом, subclass) наследует структуру или поведение одного или нескольких классов. На рис. 5.3 подкласс VIP наследует свойства и поведение класса Customer Information. Связь классов иерархии наследования называется отношением наследования (generalization, кнопка ).

Временная диаграмма (Sequences) демонстрирует поведение объектов bi времени. Она показывает объекты и последовательность сообщений, посылаемых объектами. Сообщения на диаграмме сценариев изображаются в виде стрелок (рис. 5.4).

 

Рис. 5.4. Временная диаграмма (Sequence)

 

Архитектура приложения описывается в диаграммах компоненте (Component Diagram) и диаграммах развертывания (Deployment Diagram На диаграммах компонентов изображается вхождение классов и объектов программные компоненты системы (модули, библиотеки и т. д.). При помощи диаграмм развертывания документируется размещение программных модулей на узлах (физических и логических устройствах) системы.

Генерация кода осуществляется на основе диаграмм классов. Для генерации необходимо в Rational Rose выбрать пункт меню Tools/Java/Generate Java.

Ниже приведен код на языке Java, соответствующий классу Customer Information (см. рис. 5.3):

 

При генерации кода Rational Rose включает строки комментария, начинающиеся последовательностью символов //##. Сгенерированный код (в отличие от кода, сгенерированного ER-win) не является готовым приложением. Здесь генерируются лишь заголовки методов (Check_Account), сами методы необходимо дописывать вручную.






© 2023 :: MyLektsii.ru :: Мои Лекции
Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав.
Копирование текстов разрешено только с указанием индексируемой ссылки на источник.