Главная > Методическое пособие

1

Смотреть полностью

ФЕДЕРАЛЬНОЕ АГЕНСТВО ПО ОБРАЗОВАНИЮ

Государственное образовательное учреждение высшего

профессионального образования

«МАТИ»- РОССИЙСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНОЛОГИЧЕСКИЙ УНИВЕРСИТЕТ

им. К.Э.ЦИОЛКОВСКОГО

Методическое пособие по по дисциплине

«Теоретические основы автоматизированного управления»

и указания к выполнению лабораторных работ

Номер специальности – 230102 «Автоматизированные системы обработки информации и управления»

Факультет: ИСТ (№3)

Кафедра: «Информационные технологии»

Форма обучения: очная

Москва – 2006 г.

Тема Использование Rational Rose для проектирования информационных систем.

Цель

Научиться проектировать информационные системы с использованием объектно-ориентированной методологии - UML (унифицированный язык моделирования) и овладеть навыками работы с CASE средством Rational Rose 2000.

Требования к содержанию отчета:

  • Введение

    • задание к выполнению лабораторной работы.

  • Описание предметной области.

    • описание на естественном языке.

  • Формализация технологического процесса. Представление вариантов использования.

    • диаграмма вариантов использования;

    • описание базового сценария;

    • диаграмма последовательности.

  • Проектирование программного обеспечения. Логическое представление.

    • диаграмма классов.

  • Проектирование архитектуры системы и ее размещения. Представление компонентов и размещения.

    • диаграмма представления;

    • диаграмма размещения.

  • Заключение

    • собственный сравнительный анализ методологий структурного анализа и объектно-ориенторованного.

  • Приложение 1. Исходный код программы.

Порядок проведения и сроки сдачи: Лабораторная работа проводится в компьютерном классе со следующими контрольными точками:

  1. - Описание предметной области.

  2. – Диаграмма вариантов использования.

  3. – Описание базовых сценариев.

  4. – Диаграммы последовательности.

  5. – Диаграмма деятельности .

  6. – Базовая диаграмма классов + ассоциации.

  7. – Диаграмма классов (окончательная).

  8. – Диаграмма компонентов.

  9. – Диаграмма развертывания.

  10. – Защита отчета.

  11. – Защита отчета.

СОДЕРЖАНИЕ

1. УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ UML 7

2. ИСПОЛЬЗОВАНИЕ CASE-СРЕДСТВА RATIONAL ROSE ДЛЯ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ 9

2.1. Описание CASE-средства Rational Rose 9

2.2. Общие принципы работы в среде Rational Rose 11

2.3. Представления Rational Rose 12

2.3.1. Представление Вариантов использования 12

2.3.2. Логическое представление 13

2.3.3. Представление Компонентов 15

2.3.4. Представление Размещения 16

2.4. Диаграммы представления вариантов использования 17

2.4.1. Диаграммы Вариантов Использования 17

2.4.1.1. Работа с вариантами использования 17

2.4.1.2. Документирование потока событий 19

2.4.1.3. Работа с действующими лицами 20

2.4.1.4. Работа со связями 20

2.4.1.5. Работа с пакетами 22

2.4.1.6. Работа с примечаниями 23

2.4.2. Диаграммы Взаимодействия 23

2.4.2.1. Идентификация объектов 24

2.4.2.2. Использование диаграмм Взаимодействия 25

2.4.2.3. Диаграммы Последовательности 26

2.4.2.4. Кооперативные диаграммы 26

2.4.2.5. Работа с действующими лицами на диаграмме 27

Взаимодействия 27

2.4.2.6. Работа с объектами 27

2.4.2.7. Работа с сообщениями 29

2.4.2.8. Работа с примечаниями и скриптами 31

2.4.3. Диаграммы деятельности. 31

2.4.3.1. Состояние действия 33

2.4.3.2. Переходы 34

2.4.3.3. Дорожки 36

2.4.3.4. Рекомендации по построению диаграмм деятельности 38

2.5. Диаграммы Логического представления 39

2.5.1. Диаграммы Классов 39

2.5.1.1. Выявление классов 39

2.5.1.2. Создание диаграмм Классов 41

2.5.1.3. Работа с классами 41

2.5.1.4. Работа с пакетами 45

2.5.1.5. Работа с атрибутами 46

2.5.1.6. Спецификации атрибута 47

2.5.1.7. Работа с операциями 50

2.5.1.8. Спецификации операции 53

2.5.1.9. Соотнесение операций с сообщениями 54

2.5.1.10. Связи 55

2.5.2. Диаграммы Состояний 64

2.5.2.1. Создание диаграмм Состояний 65

2.5.2.2. Задание специальных состояний 68

2.6. Диаграммы Представления Компонентов 69

2.6.1. Представление Компонентов 69

2.6.2.Типы компонентов 69

2.6.3. Диаграмма Компонентов 70

2.6.3.1. Добавление компонентов 71

2.6.3.2. Определение деталей компонентов 72

2.6.3.3. Добавление зависимостей между компонентами 72

2.7. Диаграммы Представления Размещений 73

2.7.1. Узел 74

2.7.2. Соединения 76

2.7.3. Рекомендации по построению диаграммы Размещения 78

2.8. Дополнительные возможности Rational Rose 79

2.8.1. Генерация программного кода 79

2.8.1.1. Подготовка к генерации программного кода 79

2.8.1.2. Этап первый: проверка модели 80

2.8.1.3. Этап второй: создание компонентов 81

2.8.1.4. Этап третий: отображение классов на компоненты 81

2.8.1.5. Этап четвертый: установка свойств генерации программного кода 82

2.8.1.6. Этап пятый: выбор класса, компонента или пакета 82

2.8.1.7. Этап шестой: генерация программного кода 83

2.8.1.8. Результаты генерации 83

2.8.2. Обратное проектирование 84

2.8.3. Проектирование БД с использованием Rational Rose 85

2.8.3.1. Использование стереотипов для представления схем БД 85

2.8.3.2. Прямая и обратная генерация схем БД 91

3. ЗАДАНИЯ К ЛАБОРАТОРНОЙ РАБОТЕ «ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ С ИСПОЛЬЗОВАНИЕМ CASE-СРЕДСТВА RATIONAL ROSE » 113

3.1. Цель лабораторной работы 113

3.2. Требования к выполнению лабораторной работы 113

3.3. Варианты заданий 114

4. ПРИМЕР ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ «СТОЛ ЗАКАЗОВ» 115

4.1. Представление Вариантов Использования 115

4.1.1. Диаграмма Вариантов Использования 115

4.1.2. Диаграммы Взаимодействия 117

4.1.2.1. Диаграммы Последовательности 117

4.1.2.2. Кооперативные диаграммы 117

4.2. Логическое представление 119

4.2.1. Диаграммы Классов 119

4.2.1.1. Выявление классов 119

4.2.1.2. Определение атрибутов и операций классов 119

4.2.1.3. Объединение классов в пакеты 120

4.2.2. Диаграммы Состояний 121

4.2.3. Диаграммы Деятельности 122

4.3. Представление Компонентов 124

4.4. Представление Размещения 124

125

СПИСОК ЛИТЕРАТУРЫ 126

ПРИЛОЖЕНИЕ А. 127

«БАЗОВЫЕ СЦЕНАРИИ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ» 127

ПРИЛОЖЕНИЕ Б. «ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ» 128

ПРИЛОЖЕНИЕ В. «ПАКЕТЫ» 142

1. УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ UML

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

Унифицированный язык моделирования UML (Unified Modeling Language) – это преемник того поколения методов ООАП, которые появились в конце 80-х и начале 90-х гг. Создание UML фактически началось в конце 1994 г., когда Гради Буч и Джеймс Рамбо начали работу по объединению методов Booch и OMT (Object Modeling Technique) под эгидой компании Rational Software. К концу 1995 г. они создали первую спецификацию объединённого метода, названного ими Unified Method, версия 0.8. Тогда же в 1995г., к ним присоединился создатель метода OOSE (Object-Oriented Software Engineering) Ивар Якобсон. Таким образом, UML является прямым объединением и унификацией методов Буча, Рамбо и Якобсона, однако дополняет их новыми возможностями. Главными в разработке UML были следующие цели:

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

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

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

  • обеспечить формальную основу для понимания этого языка моделирования (язык должен быть одновременно точным и доступным для понимания, без лишнего формализма);

  • стимулировать рост рынка объектно-ориентированных инструментальных средств;

  • интегрировать лучший практический опыт.

Язык UML находится в процессе стандартизации, проводимом OMG (Object Management Group) – организацией по стандартизации в области объектно-ориентированных методов и технологий, в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии ПО. Язык UML принят на вооружение практически всеми крупнейшими компаниями – производителями ПО (Microsoft, IBM, Oracle, Sybase и др.). Кроме того, практически все мировые производители CASE-средств, помимо Rational Software (Rational Rose), поддерживают UML в своих продуктах (Paradigm Plus 3.6, System Architec, Microsoft Visual Modeler for Visual Basic, Delphi и др.). Полное описание UML можно найти на сайтах , и . Описание UML на русском языке содержится в книге М. Фаулера и К. Скотта, в дальнейшем изложении терминология языка соответствует данному переводу.

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

- диаграммы вариантов использования (use case diagram) – для моделирования бизнес-процессов организации (требований к системе);

- диаграммы классов (class diagram) – для моделирования статической структуры классов системы и связей между ними;

- диаграммы поведения (behavior diagrams):

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

- диаграммы деятельности (activity diagram) – для моделирования поведения системы в рамках различны вариантов использования или моделирования деятельности;

- диаграммы взаимодействия (interaction diagrams) – для моделирования процесса обмена сообщениями между объектами. Существует два вида диаграмм взаимодействия:

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

- кооперативные диаграммы (collaboration diagram) – для моделирования поведения объектов системы при переходе из одного состояния в другое;

- диаграммы реализации (implementation diagrams):

- диаграммы компонентов (component diagram) – для моделирования иерархии компонентов (подсистем системы);

- диаграммы размещения (deployment diagram) – для моделирования физической архитектуры системы.

2. ИСПОЛЬЗОВАНИЕ CASE-СРЕДСТВА RATIONAL ROSE ДЛЯ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

2.1. Описание CASE-средства Rational Rose

Rational Rose – мощный инструмент анализа и проектирования объектно-ориентированных программных систем. Он позволяет проектировать системы до написания кода, так что вы можете с самого начала быть уверены в адекватности их архитектуры. С помощью готовой модели недостатки проекта легко обнаружить на стадии, когда их исправление не требует ещё значительных затрат.

Среда Rational Rose позволяет проектировать варианты использования и их диаграммы для визуализации функциональных возможностей системы. Диаграммы взаимодействия показывают, как объекты работают совместно, обеспечивая требуемые функциональные возможности. Для отображения объектов системы и их отношений используются диаграммы Классов. Диаграммы Компонентов иллюстрируют, как классы соотносятся с готовыми физическими компонентами системы. Наконец диаграммы Размещения применяются для визуализации проекта распределённых систем.

Модель Rose – это картина системы. Она содержит все диаграммы UML, действующих лиц, варианты использования, объекты, классы, компоненты и узлы системы. Она детально описывает, что система содержит и как функционирует, поэтому разработчики могут использовать её в качестве эскиза или чертежа создаваемой системы.

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

Естественно ожидать различие в стилях программирования; получив одинаковый набор требований, 20 разработчиков создадут 20 различных систем. Таким образом, без подробного обсуждения работы с каждым участником проекта будет трудно понять, какие решения по проекту приняты, из каких элементов состоит система и что представляет собой её общая структура. Не имея документированного проекта, трудно даже быть уверенным, что созданное приложение – это именно то, чего хотели пользователи.

Традиционно процесс, которому мы следуем, выглядит следующим образом:

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

Модель Rose предлагает совершенно другой подход:

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

Однако модели UML используют не только разработчики:

- С помощью диаграмм Вариантов Использования потребители и менеджеры проекта получат общее представление о системе и смогут принять решение о сфере её применения.

- С помощью диаграмм Вариантов Использования и документации менеджеры проекта смогут разделить проект на отдельные управляемые задачи.

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

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

- Из диаграмм Последовательности и Кооперативных диаграмм аналитики и разработчики уяснят, насколько логично работает система, поймут её объекты и сообщения между ними.

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

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

- Из диаграмм Компонентов и Размещения эксплуатационный персонал сможет узнать, какие .EXE и .DLL файлы и другие компоненты будут созданы, а также где в сети они должны быть размещены.

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

Итак, Rose - это средство, которое может быть использовано всеми участниками проекта. Это фактически, хранилище информации о контексте и проекте системы, из которого каждый участник проекта извлекает то, что ему нужно.

Помимо всего вышесказанного, Rational Rose позволяет генерировать «скелетный код» на большом количестве различных языков, включая C++, Java, Visual Basic и PowerBuilder. Более того, можно выполнять обратное проектирование кода и создавать таким образом модели уже существующих систем. Весьма выгодно иметь модели Rose для уже существующих приложений. Если сделано изменение в модели, Rose позволяет модифицировать код для его реализации. Если же был изменён код, можно автоматически обновить соответствующим образом и модель. Благодаря этому удаётся поддерживать соответствие между моделью и кодом, уменьшая риск «устаревания» первой.

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

2.2. Общие принципы работы в среде Rational Rose

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

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

2.3. Представления Rational Rose

Модель Rose поддерживает четыре представления (views): представление Вариантов Использования, Логическое представление, представление Компонентов и представление Размещения. У каждого из них свои цели и своя аудитория.

2.3.1. Представление Вариантов использования

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

Представление Вариантов Использования содержит:

- Действующих лиц, представляющих собой внешние сущности, взаимодействую­щие с создаваемой системой.

- Варианты использования, являющиеся высокоуровневыми элементами функционально­сти, которую обеспечивает система.

- Документацию по вариантам использования, детализирующую происходящие в них про­цессы (потоки событий), включая обработку ошибок.

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

- Диаграммы Взаимодействия, отображающие объекты или классы, которые принимают участие в одном потоке событий варианта использования. Для каждого варианта исполь­зования можно создать множество диаграмм Взаимодействия. Это делается либо в пред­ставлении Вариантов Использования, либо в Логическом представлении системы. Как правило, не зависящие от языка программирования и реализации, диаграммы Взаимо­действия создают в представлении Вариантов Использования. Обычно такие диаграммы показывают взаимодействие объектов, а не классов. Диаграммы Взаимодействия, завися­щие от языка, обычно находятся в Логическом представлении системы. Они, как прави­ло, отображают классы, а не объекты.

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

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

В процессе работы над проектом все члены команды могут ознакомиться с этим представлением, чтобы достичь понимания системы на высоком уровне. Документация варианта использования опи­сывает соответствующий поток событий. С помощью этой информации специалисты по контролю качества смогут приступить к созданию тестовых программ для системы, а технические писатели — документации для пользователей. Аналитики и заказчики будут уверены, что учтены все требования. Разработчики поймут, какие высокоуровневые элементы системы предстоит создать, и как будет рабо­тать ее логика.

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

2.3.2. Логическое представление

Логическое представление концентрируется на том, как система будет реализовывать поведение, описанное в вариантах использования. Оно дает подробную картину составных частей си­стемы и описывает их взаимодействие. Логическое представление включает в себя, помимо прочего, конкретные требуемые классы, диаграммы Классов и диаграммы Состояний. С их помощью разработ­чики могут сконструировать детальный проект создаваемой системы.

Логическое представление содержит:

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

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

- Диаграммы Взаимодействия, применяемые для отображения классов, участвующих в од­ном потоке событий варианта использования. Как упоминалось ранее, диаграммы Взаи­модействия создаются в представлении Вариантов Использования или в Логическом представлении. При этом, как правило, в первом случае на диаграммах изображают объ­екты, а во втором — классы системы.

- Диаграммы Состояний, описывающие динамику поведения объекта. Они включают в себя все состояния, в которых данный объект может существовать. Они также показыва­ют, как объект переходит из одного состояния в другое, в каком состоянии он находится сразу после создания и в каком — непосредственно перед уничтожением.

- Пакеты, являющиеся группами взаимосвязанных классов. Объединять классы в пакеты не обязательно, но настоятельно рекомендуется. Типичная система может содержать сотню или более классов, и объединение их в пакеты помогает уменьшить сложность мо­дели. Для понимания общей картины системы достаточно взглянуть на ее пакеты. Чтобы изучить систему на более детальном уровне, приходится углубляться в пакеты и исследо­вать классы, находящиеся внутри.

Часто разработка Логического представления осуществляется в два этапа. Сначала определяются классы анализа (analysis classes). Они не зависят от языка программирования.

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

Рис.1. Пиктограммы классов анализа

Классы анализа могут появляться также на диаграммах Взаимодействия в представлении Вариан­тов Использования. После определения всех классов анализа каждый из них может быть преобразо­ван в класс проекта (design class). Класс проекта уже содержит специфические для данного языка детали. Например, можно представить себе класс анализа, отвечающий за обмен информацией с дру­гой системой. Нас пока не интересует, на каком языке он будет написан, мы уделяем внимание только его данным и поведению. Но преобразуя его в класс проекта, нам придется коснуться специфических для языка деталей. Причем отсутствует строгое соответст­вие между классами того и другого типа. Классы проекта изображают на диаграммах Взаимодействия Логического представления системы.

В этом представлении основное внимание уделяется логической структуре системы. Мы изучаем данные и поведение системы, определяем ее составные части и исследуем взаимодействие между ними. Одной из ключевых особенностей здесь является возможность повторного использования (re­use). Тщательно соотнося данные и поведение классов, группируя классы вместе и исследуя взаимо­действие между классами и пакетами, можно определить, какие из них допускают повторное использование. Завершая новые и новые проекты, вы будете постепенно увеличивать вашу библиоте­ку повторно используемых классов и пакетов. В результате выполнение будущих проектов будет все более и более становиться процессом сборки целого из имеющихся у вас составных частей, а не раз­работки "с чистого листа".

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

Однако больше всего этим представлением пользуются разработчики и архитекторы. Первые вы­ясняют, какие классы надо создавать, а также какие данные и поведение должен иметь каждый класс. Для вторых важнее всего структура системы в целом. Их задача — добиться того, чтобы архитектура системы была, стабильна, но в то же время гибка настолько, чтобы адаптироваться к изменениям в требованиях. Другая задача — рассмотреть возможность повторного использования.

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

2.3.3. Представление Компонентов

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

В среде Rose компоненты и диаграммы Компонентов показывают в представлении Компонентов. Представление Компонентов системы отображает связи между модулями кода.

Представление Компонентов содержит:

- Компоненты, являющиеся физическими модулями кода.

- Диаграммы Компонентов, отображающие компоненты и их связи. Связи между компо­нентами системы позволяют понять зависимости, возникающие при компиляции. Зная эти зависимости, можно установить порядок компиляции компонентов.

- Пакеты, являющиеся группами связанных компонентов. Как и в случае классов, повтор­ное использование является одним из мотивов объединения компонентов в пакеты. Группу связанных компонентов системы можно использовать в других приложениях при условии, что связи между этой и другими группами тщательно отслеживаются.

Представление Компонентов более всего используется теми участниками проекта, кто отвечает за управление кодированием, компиляцию и размещение приложения. Часть компонентов — это биб­лиотеки кода. Остальные — динамические компоненты, такие как, исполняемые файлы и файлы ди­намических библиотек (.DLL). С помощью этого представления разработчики могут понять, какие библиотеки кода были созданы и какие классы содержатся в каждой из них.

2.3.4. Представление Размещения

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

Например, система может иметь трехуровневую логическую архитектуру: интерфейс логически отделен от бизнес-логики, а она, в свою очередь, отделена от базы данных. Однако размещение систе­мы может быть и двухуровневым: интерфейс находится на одном компьютере, а остальные две час­ти — на другом.

Представление Размещения отражает и такие проблемы, как отказоустойчивость системы, шири­на полосы пропускания сети, восстановление после сбоев и время отклика.

В представление Размещения входят:

- Процессы, которые являются потоками (threads), исполняемыми в отведенной для них области памяти.

- Процессоры, т.е. компьютеры, способные обрабатывать данные. Любой процесс выпол­няется на одном или нескольких процессорах.

- Устройства, т.е. аппаратура, не способная обрабатывать данные. К числу таких устройств относятся, например, терминалы ввода-вывода и принтеры.

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

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

2.4. Диаграммы представления вариантов использования

2.4.1. Диаграммы Вариантов Использования

Диаграмма Вариантов Использования содержит некоторые варианты использования системы, некото­рых действующих лиц и связи между ними. Вариант использования (use case) — это описание функцио­нальности системы на "высоком уровне". Действующее лицо (actor) — это все, что взаимодействует с системой.

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

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

2.4.1.1. Работа с вариантами использования

В
ариант использования иллюстрирует, как можно использовать систему. Например, система Контроля исполнения поручений (КИП) предоставляет пользователю некоторый базовый на­бор функциональных возможностей. Она позволяет принимать новое поручение на контроль, рассылать напоминания, снимать поручение с контроля, каждая из них — это самостоятельный вариант использования. На языке UML вариант использования “Принять новое поручение” изображают, как показано на рис.2:

Принять новое поручение

Рис.2. Пример Варианта Использования

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

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

- Не моделируйте связи между действующими лицами. По определению действующие лица нахо­дятся вне сферы действия системы. Это означает, что связи между ними также не относятся к ее компетенции. Для изучения коммуникации между действующими лицами применяется диа­грамма потоков работ (workflow diagram).

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

- Каждый вариант использования должен быть инициирован действующим лицом. Это означа­ет, что всегда должна быть стрелка, начинающаяся на действующем лице и заканчивающаяся на варианте использования. Исключением являются рассматриваемые далее связи использова­ния и расширения.

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

Для того чтобы обнаружить варианты испо­льзования. Необходимо внимательно прочитать документацию заказчика. Часто помогает также рас­смотрение области использования системы на высоком уровне и документов концептуального характера. Учтите мнение каждого из заинтересованных лиц проекта. Подумайте, чего они ожидают от готового продукта. Каждому заинтересованному лицу можно задать следующие вопросы:

- Что он хочет делать с системой?

- Будет ли он с ее помощью работать с информацией (вводить, получать, обновлять, удалять)?

- Нужно ли будет информировать систему о каких-либо внешних событиях?

- Должна ли система в свою очередь информировать пользователя о каких-либо изменениях или событиях?

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

Для того чтобы убедиться, что вы обнаружили все варианты использования необходимо ответить на вопросы:

- Присутствует ли каждое функциональное требование хотя бы в одном варианте использования? Если требование не нашло отражение в варианте использования, оно не будет реализовано.

- Учтено ли, как с системой будет работать каждое заинтересованное лицо?

- Какую информацию будет передавать системе каждое заинтересованное лицо?

- Какую информацию будет получать от системы каждое заинтересованное лицо?

- Учтены ли проблемы, связанные с эксплуатацией? Кто-то должен будет запускать готовую сис­тему и выключать ее.

- Учтены ли все внешние системы, с которыми будет взаимодействовать данная?

- Какой информацией каждая внешняя система будет обмениваться с данной?

2.4.1.2. Документирование потока событий

Варианты использования начинают описывать, что должна будет делать ваша система. Но чтобы фак­тически разработать систему, потребуются более конкретные детали. Они определяются в документе, называемом "потоком событий" (flow of events). Целью потока событий является документирование процесса обработки данных, реализуемого в рамках варианта использования. Этот документ подроб­но описывает, что будут делать пользователи системы и что — сама система.

Поток событий также не должен зависеть от реализации. Составляя этот документ, представьте себе, что создается автоматизированная система. Ваша цель — описать, что будет де­лать система, а не как она будет это делать.

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

- Описание того, каким образом запускается вариант использования

- Различные пути выполнения варианта использования

- Нормальный, или основной, поток событий варианта использования

- Отклонения от основного потока событий (так называемые альтернативные потоки)

- Потоки ошибок

- Описание того, каким образом завершается вариант использования

2.4.1.3. Работа с действующими лицами

Действующее лицо (actor) — это то, что взаимодействует с создаваемой системой. Если варианты исполь­зования описывают все, что происходит внутри области действия системы, действующие лица опре­деляют все, что находится вне ее. На языке UML действующие лица представляют в виде фигур (рис. 3).


Рис. 3. Пример актёра

Действующие лица делятся на три основных типа: пользователи системы, другие системы, взаимо­действующие с данной, и время.

Первый тип действующих лиц — это физические личности. Они наиболее типичны и имеются практически в каждой системе. В системе Стол заказов к этому типу относятся оператор и клиент.

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

2.4.1.4. Работа со связями

Связи коммуникации

Связь коммуникации (communicates relationship) — это связь между вариантом использования и действующим лицом. На языке UML связь коммуникации изображают в виде стрелки. Направление стрелки показывает, кто инициирует коммуникацию. Каждый вариант использования должен быть инициирован действующим лицом; исключения составляют лишь варианты использования в связях использования и расширения.

Связь использования

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

Для этого заведём один вариант использования “Выделить поручения”

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

Связь использования изображается в UML с помощью стрелок и слова «использование» (uses), как показано на рис. 4.

Р
ис.4. Связь использования

В этом примере варианты использования “Распечатать поручение или группу поручений” и “Редактировать поручение” применяют функциональность варианта использования “Выделить поручения”. Последний является абстрактным вариантом использования, т.е. таким, который предоставляет возможность другим вариантам использовать свою функциональность через связи использования и расширения. Варианты исполь­зования “Распечатать поручение или группу поручений” и “Редактировать поручение” — это конкретные варианты использования.

Связь использования предполагает, что один вариант использования всегда применяет функцио­нальные возможности другого. Напротив, связи расширения (extends relationships) позволяют варианту использования толь­ко при необходимости применять функциональные возможности другого.

Связь расширения

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

На языке UML связи расширения изображают в виде стрелки со словом «расширение» (extends), как показано на рис.5.

Р
ис.5. Связь расширения

В нашем примере вариант использования "Снять поручение с контроля" иногда применяет функциональные воз­можности, предоставляемые вариантом использования "Снять невыполненное поручение с контроля".

Предоставляющий дополнительные возможности вариант использования "Снять не выполненное поручение с контроля" является абстрактным. Вариант использования "Снять поручение с контроля" — конкретный.

2.4.1.5. Работа с пакетами

На языке UML такие элементы, как действующие лица, варианты использования, классы и компонен­ты, можно сгруппировать в пакеты (packages). В частности, в представлении Вариантов Использова­ния можно сгруппировать в пакеты варианты использования и действующих лиц.

Т
ак изучив предметную область можно выявить, что в КИП необходимо реализовать три типа функций. Можно представить группы функций в виде пакетов: ”Поддержка справочников”, ”Оперативная работа с поручениями” и “Формирование аналитической информации” (см. рис. 6).

Рис.6. Главная диаграмма вариантов использования

Для упорядочения элементов модели в среде Rose можно создавать столько пакетов, сколько нужно. При необходимости, для лучшей организации разрешается помещать один пакет внутрь другого.

2.4.1.6. Работа с примечаниями

При работе над диаграммой имеет смысл связывать примечания (notes) с действующими лицами и ва­риантами использования. Например, иногда нужно пояснить, почему конкретное действующее лицо взаимодействует с конкретным вариантом использования, почему вариант использования участвует в связях использования или расширения или почему одно действующее лицо наследуется от другого. До­бавление примечаний в Rose выполняется с помощью кнопки Note (Примечание) панели инструмен­тов.

На диаграмму можно поместить примечания двух типов: собственно примечания (notes) и текстовую область (text box). В общем случае, примечания позволяют добавить комментарий к какому-то одному элементу диаграммы, а текстовая область содержит сведения, общие для всей диаграммы, например ее имя.

2.4.2. Диаграммы Взаимодействия

Диаграммы Взаимодействия моделируют взаимодействия между объектами системы. Существуют два типа диаграмм Взаимодействия: диаграммы Последовательности(Sequence) и Кооперативные диаграммы(Collaboration). Оба отображают события, участвующие в процессе обработки информации варианта ис­пользования, и сообщения, которыми обмениваются объекты. События на диаграмме Последователь­ности упорядочены по времени, а Кооперативная диаграмма организована вокруг самих объектов.

На диаграмме Взаимодействия (Interaction) отображают один из процессов обработки информации в ва­рианте использования. Если у варианта использования имеется несколько альтернативных потоков, то для данного варианта использования нужно создать неско­лько диаграмм Взаимодействия.

Рассмотрим два типа диаграмм Взаимодействия — диаграммы Последовательности (Sequence) и Кооперативные диаграммы (Collaboration). Диаграммы первого типа организованы по времени. Пример такой диаграммы приведен на рис.7.

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

Диаграммы Взаимодействия визуализируют практически те же детали, что уже были описаны в потоке событий, однако представляют их в форме, более удобной для разработчика. Главное здесь - объекты, которые должны быть созданы для реализации функциональных возможностей, заложен­ных в вариант использования. На диаграммах Последовательности и Кооперативных диаграммах мо­гут быть показаны объекты, классы или то и другое вместе.

Рис.7. Диаграмма Последовательности

2.4.2.1. Идентификация объектов

Объектом называют нечто, заключающее (инкапсулирующее) в себе некоторые данные и поведе­ние. Это термин, описывающий реальные, конкретные предметы.

Данные объекта называются атрибутами (attributes). Хотя их значения изменяются, время от времени, сами атрибуты неизменны.

Поведение объекта представляется его операциями (operations).

В среде Rose объекты помещают на диаграммы Взаимодействия. Когда действующее лицо (пред­ставляющее собой стереотип класса) или какой-то другой класс переносится на диаграмму Взаимо­действия, автоматически создается экземпляр объекта этого класса. Удаление объекта с диаграммы Rose не приводит к удалению класса из модели.

Класс — это некая сущность, представляющая собой как бы схему объекта. Иными словами, класс определяет данные и поведение, которыми должен обладать объект. Класс — более общий термин, являющийся, по существу, шаблоном для объектов.

Хороший способ первоначального выявления некоторых объектов — это изучение имен существите­льных в потоке событий. Можно также прочитать документы, описывающие определённый сценарий. Под сценарием понимается конкретный экземпляр потока событий. У каждого потока событий существует обычно много сценариев. Диаграмма Последовательности или Кооперативная диаграмма отображает один из таких сценариев.

Некоторые существительные в ваших сценариях будут действующими лицами, другие — объекта­ми, а третьи — атрибутами объекта. При разработке диаграмм Взаимодействия существительные по­кажут вам, что может быть объектом. Если вы не понимаете, что описывает существительное: объект или атрибут, подумайте, есть ли у него поведение. Если нет, то это, вероятно, атрибут; если да, то, скорее всего, объект.

Не все объекты появляются в потоке событий. Там, например, может не быть форм для заполне­ния, но их необходимо показать на диаграмме, чтобы позволить действующему лицу вводить новую информацию в систему или просматривать ее. В потоке событий скорее всего не будет и управляю­щих объектов (control objects). Эти объекты управляют последовательностью потока в варианте испо­льзования.

2.4.2.2. Использование диаграмм Взаимодействия

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

Диаграммы Последовательности упорядочены по времени. Они полезны для того, кто хочет по­нять логическую последовательность событий в сценарии. Хотя информация о последовательности входит и в Кооперативные диаграммы, она лучше воспринимается на диаграмме Последовательно­сти.

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

Диаграммы Взаимодействия содержат объекты и сообщения.

Причём для объектов можно использовать имена как объектов, так и классов, или того и другого.

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

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

2.4.2.3. Диаграммы Последовательности

Диаграмма Последовательности — это упорядоченная по времени диаграмма Взаимодействия, читать ее следует сверху вниз. Как упоминалось раньше, у каждого варианта использования имеется большое количество альтернативных потоков. Каждая диаграмма Последовательности описывает один из по­токов варианта использования. Участвующие в потоке объекты нарисованы в прямоугольниках в верхней части диаграммы. У каждого объекта имеется линия жизни (lifeline), изображаемая в виде вертикальной штриховой линии под объектом. Сообщения, соответствующие коммуникациям между объектами, рисуют между линиями жизни объектов.

Сообщение показывает, что один объект вызывает функцию другого. Да­лее, когда мы определим операции классов, каждое сообщение станет операцией. Сообщения могут быть рефлексивными, что соответствует обращению объекта к своей собственной операции. Например, на диаграмме последовательности для варианта использования “Принять новое поручение” (см. рис.7.) объект Поручение обращается сам к себе, чтобы присвоить вновь введённому поручению идентификационный номер.

2.4.2.4. Кооперативные диаграммы

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

В Rose диаграмму Последовательности можно преобразовать в Кооперативную диаграмму и наобо­рот.

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

2.4.2.5. Работа с действующими лицами на диаграмме
Взаимодействия

На любой диаграмме Последовательности или Кооперативной диаграмме должен быть объект-дейст­вующее лицо. Он является внешним стимулом, дающим системе команду на выполнение какой-то фун­кции. Объекты-действующие лица на диаграмме Взаимодействия содержат действующих лиц, взаимодействующих с вариантом использования на диаграмме Вариантов Использования.

2.4.2.6. Работа с объектами

Одним из первых этапов в создании диаграмм Последовательности и Кооперативных диаграмм явля­ется добавление к ним объектов. Чтобы найти их, изучите имена существительные в вашем потоке со­бытий и сценарии.

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

При удалении объекта с диаграммы Последовательности Rose автоматически удалит его и с соот­ветствующей Кооперативной диаграммы, но оставит его класс. Аналогично, при удалении объекта с Кооперативной диаграммы он будет автоматически удален и с диаграммы Последовательности.

При удалении объекта с диаграммы соответствующий класс модели сохраняется.

2.4.2.6.1. Спецификации объекта

На следующем этапе необходимо задать спецификации объектов.

Rose предоставляет большое количество различных полей, позволяющих детализировать объекты диаграммы. Вы можете ввести имя и класс объекта, указать устойчивость его существования (persisten­ce) и возможность наличия у него нескольких экземпляров. В показанном на рис.8 окне специфика­ции объекта можно добавить также документацию.

Работа с несколькими экземплярами объекта Rose дает возможность с помощью одной пиктограм­мы представлять несколько экземпляров одного и того же класса.

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

Рис. 8. Окно спецификации объекта

2.4.2.6.2. Именование объекта
  1. Каждому объекту на диаграмме Последовательности или Кооперативной диаграмме должно быть дано уникальное имя. В отличие от имен классов, которые, как правило, носят общий характер (“ИсточникПоручения”), имена объектов конкретны (“Отдел кадров”). На диаграмме Взаимодействия может быть два объекта, являющихся экземплярами одного и того же класса. Имя каждого присутствующего на диаграмме объекта можно задать непосредственно на этой диаграмме или в окне его спецификации.

Если объект уже был соотнесен с классом, введенное таким образом описание будет добавлено и к классу. В противном случае оно будет связано только с объектом. Описание объекта не повлияет на генерацию кода, описание класса будет присутствовать и в коде. Описание объекта можно просмотреть в отчете, генерируемом командой File > Print Specifications (Файл >Печать специфика­ций) меню модели.

2.4.2.6.3. Соотнесение объекта с классом

Каждый объект диаграммы Последовательности или Кооперативной диаграммы может быть соотне­сен с классом. Для назначе­ния объекту класса можно воспользоваться полем Class окна спецификации данного объекта. По умолчанию объекту назначается класс Unspecified (He определен).

При назначении объекту класса можно либо указать уже существующий класс модели, либо со­здать новый класс.

К моменту генерации кода все объекты должны быть соотнесены с классами.

Если удалить класс, с которым вы соотнесли объект, имя класса сохранится на диаграмме рядом с объектом, но будет заключено в скобки.

2.4.2.6.4. Определение устойчивости объекта

В среде Rose для каждого объекта на диаграмме можно задать его устойчивость (persistence). Поддер­живаются следующие варианты:

Persistent (Устойчивый) Устойчивый объект сохраняется в базе данных или другим способом, обеспечивающим постоянное хранение. Такой объект будет существовать даже после прекраще­ния работы программы.

Static (Статичный) Статичный объект сохраняется в памяти компьютера в течение всего време­ни работы программы. Он, в частности, продолжает существование после выполнения отражен­ных на диаграмме Последовательности действий, но не сохраняется после прекращения работы программы.

Transient (Временный) Временный объект сохраняется в памяти в течение очень короткого времени (например, пока не закончится выполнение процессов, определенных в диаграмме По­следовательности).

Если продолжительность жизни класса объекта установлена в Persistent, то для самого объекта ее можно указать как Persistent, Static или Transient. Если же продолжительность жизни класса объекта соответствует Transient, то для само­го объекта она может быть только Static или Transient.

2.4.2.7. Работа с сообщениями

Сообщение (message) — это связь между объектами, в которой один из них (клиент) требует от другого (сервера) выполнения каких-то действий.

При генерации кода сообщения транслируются в вызовы функций.

2.4.2.7.1. Работа с сообщениями на диаграмме Последовательности

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

Иногда требуется изменить порядок сообщений на диаграмме Последовательности. В среде Rose для этого достаточно перетащить сообщение на новое место. При изменении порядка следования сооб­щений они автоматически перенумеровываются.

2.4.2.7.2. Работа с сообщениями на Кооперативной диаграмме

Перед тем как поместить сообщение на Кооперативную диаграмму, необходимо установить путь ком­муникации между объектами. Этот путь называется связью (link) и создается с помощью кнопки Object Link (Связь объекта) панели инструментов. После создания связи можно поместить сообщение между объектами.

2.4.2.7.2.1. Добавление потоков данных к Кооперативной диаграмме

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

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

2.4.2.7.3. Спецификации сообщений

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

Кроме того, разрешается определять параметры синхронизации и частоты.

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

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

2.4.2.7.3.1. Соотнесение сообщения с операцией

Прежде чем приступить к генерации кода, следует соотнести сообщения диаграмм Последовательно­сти и Кооперативных диаграмм с операциями классов.

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

2.4.2.8. Работа с примечаниями и скриптами

Имена сообщений и объектов на диаграмме Взаимодействия несут в себе много информации. Однако иногда требуется поместить на диаграмму дополнительные сведения. Это делается с помощью приме­чаний или программных сценариев — скриптов (scripts).

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

Скрипты позволяют связать комментарий с сообщением. Они применяются только на диаграммах Последовательности и пишутся или с левой стороны диаграммы напротив соответствующего сообщения или над сообщением.

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

В общем случае старайтесь избегать слишком большого количества условий на диаграмме, чтобы не усложнять ее. При усложнении условий создайте дополнительные диаграммы Последовательности: одну для описания событий, происходящих при выполнении усло­вия IF, другую — для ELSE и т.д.

Пример скрипта для случая отсутствия в базе данных нужного источника поручений (см. рис.9).

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

2.4.3. Диаграммы деятельности.

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

Р
ис. 9. Пример применения условия

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

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

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

Именно диаграммы деятельности позволяют реализовать в языке UML осо­бенности процедурного и синхронного управления, обусловленного заверше­нием внутренних деятельностей и действий. Метамодель UML предоставля­ет для этого необходимые термины и семантику.

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

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

2.4.3.1. Состояние действия

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

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

Действие может быть записано на естественном языке, некотором псевдо­коде или языке программирования. Никаких дополнительных или неявных ограничений при записи действий не накладывается. Рекомендуется в каче­стве имени простого действия использовать глагол с пояснительными сло­вами. Если же действие может быть представлено в некотором формальном виде, то целесообразно записать его на том языке программи­рования, на котором предполагается реализовывать конкретный проект.

Иногда возникает необходимость представить на диаграмме деятельности некоторое сложное действие, которое, в свою очередь, состоит из несколь­ких более простых действий. В этом случае можно использовать специаль­ное обозначение так называемого состояния под-деятельности. Такое состояние является графом деятельности и обозначается специ­альной пиктограммой в правом нижнем углу символа состояния действия. Эта конструкция может применяться к любому элементу языка UML, который поддерживает "вложенность" своей структуры. При этом пиктограмма может быть дополнительно помечена типом вложенной струк­туры.

Каждая диаграмма деятельности должна иметь единственное начальное и единственное конечное состояния. При этом каждая деятельность начинается в начальном состоянии и заканчивается в конечном состоянии. Саму диаграмму деятельности принято располагать таким образом, чтобы дейст­вия следовали сверху вниз. В этом случае начальное состояние будет изо­бражаться в верхней части диаграммы, а конечное — в ее нижней части.

2.4.3.2. Переходы

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

Переход может быть направлен в то же состояние, из которого он выходит. Этот переход изображается петлёй со стрелкой.

Переход осуществляется при наступлении некоторого события: окончания выполнения деятельности, получении объектом сообщения или приёмом сигнала

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

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

Графически ветвление на диаграмме деятельности обозначается небольшим ромбом, внутри которого нет никакого текста (рис. 10).

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

Рис. 10. Диаграмма деятельности.

Выполняемые действия могут соединяться либо в конечном состоянии, либо в ещё одном символе ветвления, который будет иметь несколько входящих переходов и один выходящий.

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

В языке UML для изображения параллельных процессов используется специальный символ для разделения и слияния параллельных вычислений или потоков управления. Таким симво­лом является прямая черточка.

Как правило, такая черточка изображается отрезком горизонтальной линии, толщина которой несколько шире основных сплошных линий диаграммы деятельности. При этом разделение имеет один входящий переход и несколько выходящих (рис. 11, а). Слияние, на­оборот, имеет несколько входящих переходов и один выходящий (рис. 11, б).





а) разделение б) слияние

Рис. 11.

На рис.10. изображена диаграмма деятельности для варианта использования «Изменить заказ». Процессы выдачи бланка заказа и ассортимента протекают одновременно. Переход в следующее состояние («Пересчитать стоимость заказа») осуществляется только после выполнения сторожевого условия: [заказ изменён]. После проверки кредитоспособности клиента принимается решение о разрешении или запрещении изменения заказа.

2.4.3.3. Дорожки

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

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

Рис.12. Вариант диаграммы деятельности с дорожками.

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

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

Этим подразделениям будут соответствовать три дорожки на диаграмме дея­тельности, каждая из которых специфицирует зону ответственности подраз­деления. В данном случае диаграмма деятельности заключает в себе не толь­ко информацию о последовательности выполнения рабочих действий, но и о том, какое из подразделений торговой компании должно выполнять то или иное действие (рис. 12.).

2.4.3.4. Рекомендации по построению диаграмм деятельности

Диаграммы деятельности играют важную роль в понимании процессов реа­лизации алгоритмов выполнения операций классов и потоков управления в моделируемой системе. Эти диаграммы строятся для отдельного класса, варианта использования, отдельной операции класса или целой под­системы.

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

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

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

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

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

2.5. Диаграммы Логического представления

2.5.1. Диаграммы Классов

На диаграммах Классов отображаются некоторые классы и пакеты системы. Это статические картины фрагментов системы и связей между ними.

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

По умолчанию существует одна диаграмма Классов, называемая Главной (Main) и располагающая­ся непосредственно под Логическим представлением в браузере. На этой диаграмме показывают па­кеты классов модели. Внутри каждого пакета также имеется Главная диаграмма, включающая в себя все классы этого пакета. Двойной щелчок мыши на пакете диаграммы Классов в среде Rose открывает Главную диаграмму этого пакета.

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

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

2.5.1.1. Выявление классов

Класс — это некоторая сущность, инкапсулирующая данные и поведение. Например, в системе КИП есть класс для работы с данными о поручениях - это класс Task. Он содержит такие данные, как идентификационный номер поручения (taskNumber), его содержание (taskText), дата исполнения поручения (executionDate), исходящий номер (sourceNumber), исходящая дата (sourceDate), дата выдачи поручения (taskDate). Класс Task имеет также свое поведение. Он знает, как создать поручение (create), заполнить реквизиты (setInfo), извлечь (getInfo), сделать пометку о снятии поручения с контроля(closeTask).

На языке UML класс Task изображается с помощью следующей нотации (см. рис.13).



Рис.13. Изображение классов в UML

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

На диаграммах этого типа можно также отобразить видимость всех атрибутов и операций, тип данных атрибутов и сигнатуру всех операций.

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

- Действующее лицо;

- Класс;

- Атрибут класса;

- Выражение, не являющееся действующим лицом, классом или атрибутом.

Изучив все эти существительные, вы определите классы вашей системы.

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

Каждый объект диаграмм Последовательности и Кооперативных диаграмм должен быть соотне­сен с соответствующим классом.

Поток событий и диаграммы Взаимодействия являются прекрасным местом, где можно начать по­иск классов. Тем не менее некоторые классы вы там не найдете. При выявлении классов следует рас­смотреть три возможных стереотипа: сущность (entity), границу (boundary) и управление (control). Не все они содержатся в потоке событий и на диаграммах Взаимодействия.

2.5.1.2. Создание диаграмм Классов

В среде Rose диаграммы Классов создаются в Логическом представлении модели.

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

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

2.5.1.3. Работа с классами

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

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

2.5.1.3.1. Спецификации классов

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

Рис.14. Окно спецификации класса

2.5.1.3.2. Именование классов

Каждому классу модели Rose необходимо дать уникальное имя. Большинство организаций имеет собст­венные соглашения по именованию классов. В общем случае используются существительные в единст­венном числе. Обычно имена классов не содержат пробелов. Используемый для именования классов регистр символов определяется обычно организацией. Важно только, чтобы принятый подход применялся ко всем клас­сам модели.

2.5.1.3.3. Назначение стереотипа для класса

Стереотип — это механизм, позволяющий категоризировать классы. Допустим, вы хотите найти все формы в вашей модели. Для этого можно создать стереотип Form (Форма) и назначить его всем окнам вашего приложения. В дальнейшем при поиске форм нужно только искать классы с этим стереотипом. На языке UML определены три основных стереотипа: Boundary (Граница), Entity (Объект) и Cont­rol (Управление).

Пограничными классами (boundary classes) называются такие классы, которые расположены на границе системы со всем остальным миром. Они включают в себя формы, отчеты, интерфейсы с аппаратурой (такой, как принтеры или сканеры) и интерфейсы с другими системами.

Для выявления пограничных классов необходимо исследовать диаграммы Вариантов Использования. Для каждого взаимодействия между действующим лицом и вариантом использования должен су­ществовать хотя бы один пограничный класс. Именно он позволяет действующему лицу взаимодействовать с системой (см. рис.15).

Р
ис.15. Место нахождения пограничного класса “Форма ввода поручения”

Необязательно создавать уникальные пограничные классы для каждой пары "действующее лицо — вариант использования". Например, если два действующих лица иниции­руют один и тот же вариант использования, они могут применять общий пограничный класс для взаимодействия с системой.

Классы-сущности (entity classes) содержат информацию, хранимую постоянно. Классы-сущности можно обнаружить в потоке событий и на диаграммах Взаимодействия. Они имеют наибольшее значе­ние для пользователя, и потому в их названиях часто применяют термины из предметной области. Источник поручения, Исполнитель поручения, Поручение – это всё классы-сущности.

Часто для каждого класса-сущности создают таблицу в базе данных. В этом заключается еще одно отличие от типичного подхода к конструированию системы. Вместо того чтобы с самого начала зада­вать структуру базы данных, у нас теперь есть возможность разрабатывать ее на основе информации, получаемой из объектной модели. Это позволяет отслеживать соответствие всех полей базы данных и требований к системе. Требования определяют поток событий. Поток событий определяет объек­ты, классы и атрибуты классов. Каждый атрибут класса-сущности становится полем в базе данных. Применяя такой подход, легко отслеживать соответствие между полями базы данных и требования­ми к системе, что уменьшает вероятность сбора ненужной информации.

Управляющие классы (control classes) отвечают за координацию действий других классов. Обычно у каж­дого варианта использования имеется один управляющий класс, контролирующий последователь­ность событий этого варианта использования. Сам управляющий класс не несет в себе никакой функциональности — остальные классы посылают ему мало сообщений. Но сам он посылает множество сообщений. Управ­ляющий класс делегирует ответственность другим классам. По этой причине управляющий класс час­то называют классом-менеджером.

В системе могут применяться и другие управляющие классы, общие для нескольких вариантов ис­пользования. Например, класс SecurityManager (Менеджер безопасности) может отвечать за конт­роль событий, связанных с безопасностью, а класс TransactionManager (Менеджер транзакций) — заниматься координацией сообщений, относящихся к транзакциям с базой данных. Могут быть и дру­гие менеджеры для работы с такими элементами функционирования системы, как разделение ресур­сов, распределенная обработка данных и обработка ошибок.

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

Помимо упомянутых выше стереотипов, вы можете создавать и свои собственные. Для этого нуж­но ввести новый стереотип в поле Stereotype, после чего он будет доступен в текущей модели Rose. Разрешается добавлять стереотип для использования во всех моделях и даже создавать для него кноп­ки и пиктограммы панели инструментов.

2.5.1.3.4. Задание видимости класса

Параметр Visibility (Видимость) показывает, будет ли класс виден вне своего пакета. Вы можете ука­зать для класса одно из трех значений:

- Public (Открытый)- этот класс виден всем остальным классам системы;

- Protected, Private (Защищенный, закрытый) –этот класс может быть виден во вложенных в него классах, "друзьям" (friends) этого класса или из самого класса;

- Package or Implementation (Пакет или реализация)- этот класс может быть виден только из клас­сов того же пакета.

2.5.1.3.5. Задание множественности класса

Поле Cardinality (Множественность) позволяет указать, сколько у данного класса должно быть экземп­ляров. Например, в системе КИП можно ожидать наличия множест­ва экземпляров у класса Поручение. Следовательно, множественность этого класса нужно определить как n.

2.5.1.3.6. Задание устойчивости класса

В среде Rose на основе модели можно генерировать DDL (Data Definition Language — Язык Описа­ния Данных). DDL определяет структуру вашей базы данных.

При генерации DDL приложение Rose ищет устойчивые (persistent) классы. Поле Persistence окна спецификации класса применяется для определения этого параметра. Он может принимать одно из следующих значений:

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

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

В системе КИП классы Источник поручения, Исполнитель поручения, Поручение надо пометить как устойчивые, чтобы они сохранились в БД.

2.5.1.3.7. Создание абстрактного класса

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

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

Например класс List (Список) является абстрактным и в нем содержится общие для всех потомков операции displayList, addItem, deleteItem (см. рис. 16).

Рис.16. Абстрактный класс

2.5.1.4. Работа с пакетами

Пакеты (packages) применяются для группирования классов, обладающих некоторой общностью.

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

Рис.17. Пакеты классов

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

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

2.5.1.5. Работа с атрибутами

Атрибут— это фрагмент информации, связанный с классом.

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

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

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

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

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

Определив атрибуты, внимательно соотнесите их с соответствующими классами. Атрибут должен соответствовать назначению класса.

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

Иногда могут возникнуть сомнения, соответствует ли обнаруженная вами информация атрибуту или классу. Рассмотрим, например, такой атрибут, как название компании. Является ли он атрибутом класса Person (Человек), или лучше создать отдельный класс Company (Компания)? Ответ зависит оттого, какое приложение вы пишете. Если вы собираете сведения о компании и имеется связанное с ней поведение, она может быть классом. Допустим, что вы проектируете систему работы с заказчика­ми. В таком случае может потребоваться информация о компаниях, которым вы поставляете товары или услуги. Вам нужно знать, сколько сотрудников работает в компании, ее имя и адрес, контактный телефон и т.д.

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

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

2.5.1.5.1. Добавление и удаление атрибутов

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

Добавление атрибута выполняется непосредственно на диаграмме Классов, в браузере или в окне спецификации класса.

С атрибутом можно связать некоторое текстовое описание. Как правило, это короткое описание или определение атрибута. В генерируемый код оно войдет в качестве комментария. Таким образом, документируя атрибут, вы начинаете документировать и код.

2.5.1.6. Спецификации атрибута

В Rose, можно определить подробные спецификации атрибута. Они включают в себя, помимо прочего, тип данных, значение по умолчанию, стереотип и видимость атрибута. Все спецификации можно просматривать или изменять в окне спецификации атрибута, показан­ном на рис. 18.

Рис. 18.Окно спецификации атрибута

2.5.1.6.1. Задание типа данных атрибута

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

В качестве типов данных можно использовать либо встроенные типы языка программирования, либо определенные в вашей модели имена классов. Для того чтобы имена определенных в модели классов выводились в раскрывающемся списке типов данных атрибутов, уста­новите флажок Show Classes (Показать классы).

Для атрибута можно задать значение по умолчанию в поле Initial Value (Начальное значение). Для генерации кода задавать начальные значения необязательно. Тем не менее при их наличии генерируемый код будет соответствующим образом инициализировать ат­рибут.

2.5.1.6.2. Назначение стереотипа для атрибута

Как у действующих лиц, вариантов использования и классов, у атрибутов могут быть стереотипы. Сте­реотип атрибута является способом его классификации. Например, некоторые атрибуты могут соот­ветствовать полям базы данных, а другие нет. Для каждого такого типа можно определить свой стереотип.

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

2.5.1.6.3. Задание видимости атрибута

Так как атрибуты содержатся внутри класса, они скрыты от других классов. В связи с этим нужно указать, какие классы имеют право читать и изменять атрибуты. Это свойство называется видимостью атрибута (attribute visibility)

Допустимы четыре значения этого параметра:

1) Public (Общий, открытый) - атрибут виден всем остальным классам. Любой класс может про­смотреть или изменить значение атрибута. В соответствии с нотацией UML общему атрибуту предшествует знак "+".

2) Private (Закрытый, секретный) - атрибут не виден никаким другим классам. Доступ к таким атрибутом обычно делается с помо­щью общих операций. В соответствии с нотацией UML закрытый атрибут обозначает­ся знаком "-".

3) Protected (Защищенный) - атрибут доступен только самому классу и его потомкам. Нотация UML для защищенного атрибута — знак "#".

4) Package or Implementation (Пакетный) - атрибут является общим, но только в пределах своего пакета, т.е. он может быть изменен из класса находящегося в том же пакете. Данный тип види­мости не обозначается никаким специальным значком.

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

В среде Rose поддерживаются два набора нотаций видимости. Первый — это нотация UML (+,-,#) для общих, закрытых и защищенных атрибутов соответственно. Вторая включает в себя четыре знач­ка Rose, показанных в таблице 1.

Таблица 1

Пиктограммы видимости Rose и UML

Пиктограмма Rose

UML

Описание

+

Public

-

Private

#

Protected

<нет значка>

Package or Implementation

2.5.1.6.4. Задание метода локализации атрибута

Возможны три значения этого параметра:

By value (По значению) - предполагается, что атрибут содержится внутри класса. Например, если атрибут относится к типу string, эта строка будет содержаться внутри определения класса.

By reference (По ссылке) - предполагается, что атрибут локализован вне класса, но класс содер­жит указатель на него. Например, у класса Task (Поручение) может быть ат­рибут типа TaskSource (Источник поручения). Сам объект taskSource размещен вне объекта task. Таким образом, этот атрибут является указателем на внешний объект taskSource.

Unspecified (He определен) - метод локализации атрибута еще не определен. В этом случае при генерации кода по умолчанию применяется значение By value этого параметра.

2.5.1.6.5. Определение статичного атрибута

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

Статичный атрибут (static) — это такой атрибут, который используется всеми экземплярами клас­са. Если бы атрибут ЕxecutionDate был статичным, он был бы общим для всех трех созданных экземпляров поручений.

На языке UML статичный атрибут помечают символом "$" ($ЕxecutionDate).

2.5.1.6.6. Определение производного атрибута

Производным (derived) называется атрибут, созданный из одного или нескольких других атрибутов. На­пример, класс Поручение может иметь атрибуты имя и фамилия. У него также может быть производный атрибут полное имя, вычисляемый как конкатенация имени и фамилии. В UML производные атрибуты помечают символом "/".

2.5.1.7. Работа с операциями

Операцией называется связанное с классом поведение. Операция состоит из трех частей: имени, пара­метров и типа возвращаемого значения. Параметры — это аргументы, получаемые операцией "на вхо­де". Тип возвращаемого значения относится к результату действия операции.

На диаграмме Классов можно показывать как имена операций, так и их параметры и типы возвра­щаемого значения.

На некоторых диаграммах полезно показывать полную сигнатуру операций. Если же нужно упрос­тить диаграмму, лучше оставить только имена.

В языке UML операции имеют следующую нотацию:

Имя операции (аргумент1 : тип данных аргумента1, аргумент2 : тип данных аргумента2,...): тип возвращаемого значения.

Операции определяют ответственности классов. При идентификации операций и анализе клас­сов имейте в виду следующее:

- Относитесь с подозрением к любому классу, имеющему только одну или две операции. Возмож­но, класс написан совершенно правильно, но его следует объединить с каким-нибудь другим классом.

- С величайшим подозрением относитесь к классу без операций. Как правило, класс инкапсули­рует не только данные, но и поведение. Класс без поведения лучше моделировать как один или несколько атрибутов.

- С осторожностью относитесь к классу со слишком большим числом операций. Набор ответственностей класса должен быть управляем. Если класс очень большой, им будет трудно управ­лять. В такой ситуации лучше разделить класс на два меньших.

2.5.1.7.1. Выявление операций

Создав диаграммы Последовательности и Кооперативные диаграммы, вы проделаете большую часть работы, требуемой для выявления операций.

Следует рассмотреть четыре различных типа операций:

1) Операции реализации (implementor operations) реализуют некоторую бизнес-функциональность. Такие операции можно найти, исследуя диаграммы Взаимодействия. Диаграммы этого типа фокусируются на бизнес-функциональности, и каждое сообщение диаграммы скорее всего можно соотнести с опера­цией реализации.

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

2) Операции управления (manager operations) управляют созданием и разрушением объектов. В эту катего­рию попадают конструкторы и деструкторы классов.

В среде Rose не требуется вручную создавать конструкторы и деструкторы классов. При генера­ции кода вам предоставляется возможность сделать это автоматически.

3) Операции доступа. Атрибуты обычно бывают закрытыми или защищенными. Тем не менее другие классы иногда должны просматривать или изменять их значения. Для этого предназначены операции доступа (access operati­ons).

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

Создание операций Get и Set (получения и изменения значения) для каждого атрибута класса явля­ется промышленным стандартом.

Как и в случае операций управления, операции доступа не нужно вводить вручную. При генерации кода Rose автоматически создаст операции Get и Set для каждого атрибута класса.

4) Вспомогательными (helper operations) называются такие операции класса, которые необходимы ему для выполнения его ответственностей, но о которых другие классы не должны ничего знать. Это за­крытые и защищенные операции класса.

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

Для идентификации операций выполните следующие действия:

- Изучите диаграммы Последовательности и Кооперативные диаграммы. Большая часть сообще­ний на этих диаграммах является операциями реализации. Рефлексивные сообщения будут вспомогательными операциями.

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

- Рассмотрите операции доступа. Для каждого атрибута класса, с которым будут работать другие классы, необходимо создать операции Get и Set. Как и в случае управляющих операций, Rose может создать указанные операции автоматически.

2.5.1.7.2. Добавление операций

Как и атрибуты, операции можно добавить в модель Rose на диаграмму Классов или в браузер. Можно также воспользоваться окном спецификации класса.

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

Имя (Аргумент1 : Тип данных аргумента) : Тип возвращаемого значения.

Например:

-Delete() :Long

-Print(taskSourceID : Long) : Boolean.

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

2.5.1.8. Спецификации операции

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

Все спецификации операции можно просмотреть и изменить в окне спецификации операции.

2.5.1.8.1. Задание возвращаемого класса операции

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

При определении возвращаемого класса можно использовать либо встроенные типы языка про­граммирования (такие, как string, char или integer) либо определенные в вашей модели классы.

2.5.1.8.2. Назначение стереотипа для операции

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

- Implementor (Реализация) - операции, реализующие некоторую бизнес-логику;

- Manager (Управляющая) - Конструкторы, деструкторы и операции управления памятью;

- Access (Доступ) - операции, позволяющие другим классам просматривать или редактировать атрибуты данного класса;

- Helper (Вспомогательная) - Закрытые или защищенные операции, которые используются клас­сом, но не видны другим классам.

Назначение операциям стереотипов не требуется для генерации кода. Тем не менее, они облегча­ют понимание модели. Кроме того, они помогают убедиться в том, что ни одна операция не была пропущена.

2.5.1.8.3. Задание видимости операций

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

- Public (Общая) -операция доступна всем остальным классам. Любой класс может запросить, ее выполнение;

- Private (Закрытая)-операция не доступна ни одному другому классу;

- Protected (Защищенная) Доступ к операции разрешен только для самого класса и его потомков;

- Package or Implementation (Пакетная)-операция доступна только классам данного пакета.

2.5.1.8.4. Добавление аргументов к операции

Аргументы, или параметры, операции — это получаемые ею входные данные. Для каждого аргумента должны быть заданы имя и тип данных. На диаграмме Классов аргументы и их типы указываются в скобках после имени операции. Можно задавать также их значения по умолчанию. В таком случае но­тация UML будет иметь вид: Имя операции (аргумент1 : тип данных аргумента1 = значение по умолчанию аргумента1) : тип возвращаемого значения операции.

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

2.5.1.9. Соотнесение операций с сообщениями

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

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

После соотнесения всех операций Диаграмма последовательности для варианта использования “Принять новое поручение” (см. рис. 7) примет следующий вид (см. рис.19).

Рис.19. Диаграмма последовательности с соотнесенными операциями.

2.5.1.10. Связи

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

2.5.1.10.1. Ассоциации

Ассоциация (association) — это семантическая связь между классами. Ассоциация дает классу возможность узнавать об общих атрибутах и операциях другого класса. Ее рисуют на диаграмме клас­сов в виде обыкновенной линии. После того как классы связали ассоциацией, они могут передавать друг другу сообщения на диа­грамме Последовательности или Кооперативной диаграмме. Ассоциации могут быть двунаправлен­ными или однонаправленными. На языке UML двунаправленные ассоциации изображают в виде простой линии без стрелок или со стрелками с обеих сторон. На однонаправленной ассоциации ставят только одну стрелку, показывающую направление связи (см. рис.20).

Если между классами ас­социация двунаправленная, то соединенные классы знают об общих атрибутах и операци­ях друг друга, и могут посылать сообщения друг другу (см. рис.20).

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

Направление ассоциации можно определить, изучая диаграммы Последовательности и Коопера­тивные диаграммы. Если все сообщения на них отправляются только Формой и принимаются толь­ко Списком исполнителей, но не наоборот, между этими классами существует однонаправленная связь. Если хотя бы одно сообщение идет в обратную сторону, ассоциация должна быть двунаправленной.

Рис.20. Связи ассоциации

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

При генерации кода для двунаправленной ассоциации создаются дополнительные атрибуты у каж­дого класса.

В случае однонаправленной ассоциации атрибут приёмника будет помещен внутри источника, но не наобо­рот.

Ассоциации могут быть рефлексивными. Рефлексивная ассоциация предполагает, что один экзем­пляр класса взаимодействует с другими экземплярами этого же класса. Рассмотрим класс ПапкаПоручений, с помощью которого организуется иерархический список. Тогда одна папка может быть родителем других папок. Поскольку все они являются взаи­модействующими друг с другом экземплярами класса ПапкаПоручений, мы получаем рефлексивную ассоциацию (см. рис.21).

Рис.21. Рефлексивная ассоциация

2.5.1.10.2. Зависимости

Связь зависимости показывает, что один класс ссылается на другой. Таким образом, изменения во вто­ром классе повлияют на первый. При генерации кода для классов, между которыми установлена связь зависимости, Rose не добавляет к ним никаких новых атрибутов. Предположим, что между классами ИсточникПоручения и Поручение существует связь зависимости. Ее изображают пунктирной линией (см. рис. 22).

Рис. 22. Связи зависимости

При генерации кода для этих классов к ним не добавляются новые атрибуты, но со­здаются специфические для языка операторы, необходимые для поддержки связи. Например, на язы­ке C++ в код войдут операторы #include.

Делается предположение, что существуют другие способы извещения источника поручения о существовании поручения. Направление стрелки показывает, что класс ИсточникПоручения зависит от класса Поручение. Иначе говоря, суще­ствует диаграмма Последовательности или Кооперативная диаграмма, на которой ИсточникПоручения посылает Поручение сообщение. Если бы между ними была обыкновенная ассоциация, Поручение был бы атрибутом класса ИсточникПоручения, и для передачи сообщения Поручению класс ИсточникПоручения должен был бы только взглянуть на свой собст­венный атрибут. Для зависимостей, однако, такой механизм не реализуется.

Класс ИсточникПоручения должен узнавать о Поручении каким-то другим способом. Здесь предусмотрены три воз­можности. Во-первых, класс Поручение можно сделать глобальным, и тогда ИсточникПоручения будет знать о его сущест­вовании. Во-вторых, Поручение можно инстанцировать как локальную переменную внутри операции класса ИсточникПоручения. Наконец, Поручение можно передавать операциям класса ИсточникПоручения в качестве параметра. При нали­чии связей зависимости необходимо следовать одному из этих трех подходов.

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

2.5.1.10.2.1. Зависимости между пакетами

Зависимости можно устанавливать не только между классами, но и между пакетами. Фактически, это единственный тип связей, существующий между пакетами. Как и в случае классов, зависимость между пакетами изображают пунктирной линией.

Связь зависимости между пакетами Control и Entities означает, что некоторый класс пакета Control связан однонап­равленной связью с некоторым классом пакета Entities. Иначе говоря, класс Control должен знать что-либо о классе Entities (см. рис. 23).

Зависимости определяют возможность повторного использования пакетов. На приведенном выше рисунке пакет Control зависит от Entities. Это означает, что при создании других приложений пакет Control мож­но использовать только совместно с пакетом Entities. Однако сам пакет Entities можно использовать повторно, так как он не зависит ни от чего больше.

Зависимости между пакетами можно обнаружить, исследуя связи на диаграмме Классов. Если два класса из различных пакетов связаны, эти пакеты также связаны.

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

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

Рис.23. Зависимости между пакетами.

2.5.1.10.3. Агрегации

Агрегация — это более сильная форма ассоциации. Агрегацией называют связь между целым и его час­тями. Например, класс TaskSourceList(Список источников поручений) может состоять из классов TaskSource(Источник поручений). На языке UML агрегацию изображают в виде соединяющей два класса линии с ромбиком на конце, указывающем на класс-целое (см. рис. 24).

Рис.24. Связь агрегации

При генерации кода для агрегации автоматически создаются поддерживающие ее дополнитель­ные атрибуты. Так, класс-целое TaskSourceList получит атрибуты, соответствующие классам TaskSource, т.е. всем частям связи агрегации.

2.5.1.10.4. Обобщения

Обобщение — это связь наследования между двумя классами. Оно дает классу возможность наследо­вать общие и защищенные атрибуты и операции другого класса (см. рис. 25.)

Класс TaskExecuter называется суперклассом (superclass), а оба производных от него класса — подклассами (subclass). Стрелка показывает направление от подкласса к суперклассу. Общие для обоих типов элементы размещаются в классе TaskExecuter.

Р
ис. 25. Связь обобщения

Помимо наследуемых, каждый подкласс имеет свои собственные уникальные атрибуты, операции и связи. Связи обобщения позволяют сэкономить время и усилия, как при разработке, так и при дальнейшей поддержке программы. В приведенном примере не требуется писать и поддерживать две различ­ные копии операции ctreateChild () — для каждого подкласса. Достаточно разработать только одну копию. Лю­бые сделанные в ней изменения будут автоматически наследоваться классами Organisation, Person и всеми остальными подклассами суперкласса TaskExecuter.

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

Создаваемая структура должна быть управляемой. Иерархия со слишком большим количеством уровней может стать плохо управляемой. Каждое изменение в верхней части структуры немедленно отразится во всех производных классах. Являясь, с одной стороны, преимуществом, это может за­труднить анализ и управление системой. В некоторых языках большое количество уровней усложня­ет работу приложения.

2.5.1.10.4.1. Создание обобщений

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

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

При удалении связей обобщения из модели помните, что атрибуты, операции и связи суперкласса больше не будут наследова­ться подклассами. Если они нужны в подклассе, их необходимо туда добавить.

2.5.1.10.5. Выявление связей

Для выявления связей следует изучить созданные к этому моменту элементы модели. Почти вся ин­формация о связях уже описана вами на диаграммах Последовательности и Кооперативных диаграм­мах. Просмотрите их еще раз, и вы найдете ассоциации и зависимости. Агрегации и обобщения можно обнаружить, изучив имеющиеся классы. Для обнаружения связей сделайте следующее:

  1. Начните с изучения диаграмм Последовательности и Кооперативных диаграмм. Если класс А посылает сообщение классу В, между этими классами должна быть установлена связь. Как пра­вило, обнаруживаемые таким способом связи — это ассоциации или зависимости.

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

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

  4. Изучите классы еще раз и найдите остальные связи обобщения. Постарайтесь обнаружить такие классы, которые имеют много общего.

Будьте осторожны, работая с классами, у которых слишком много связей. Одной из особенностей хорошо спроектированного приложения является сравнительно небольшое количество связей в сис­теме. Класс, у которого много связей, должен знать о большом числе других классов системы. В резу­льтате его трудно будет использовать во второй раз. Кроме того, сложно будет вносить изменения в готовое приложение. Если изменится любой из классов, это может повлиять на данный.

2.5.1.10.6. Задание множественности

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

Множественность (multiplicity) показывает, сколько экземпляров одного класса взаимодействуют с помощью связи с одним экземпляром другого класса в данный момент времени см. табл.2.

Таблица 2

Варианты множественности связи

Множественность

Значение

*

много

0

нуль

1

один

0..*

нуль или больше

1..1

ровно один

1..*

один или больше

Помните, что значение множественности позволяет понять, является ли данная связь обязатель­ной.

Если равна 0, то связь необязательная, если больше 0 то обязательная.

2.5.1.10.7. Использование имен связей

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

В Rose можно указать также направление связи. Направление действия имени устанавливается в окне спецификации связи.

2.5.1.10.7.1. Использование ролей

Ролевые имена применяют в связях ассоциации или агрегации для описания назначения связи.

Ролевые имена — это обычно имена существительные или фразы.

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

В окне спецификации связи можно добавить к роли текстовое описание. При генерации кода оно войдет в комментарий. Чтобы увидеть роль на диаграмме, щелкните правой кнопкой мыши на связи и в открывшемся меню выберите пункт Role name (Имя роли).

2.5.1.10.8. Использование статичных связей

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

Если роль статичная, то создаваемый при генерации кода соответствующий ей атрибут также бу­дет статичным. На диаграмме Классов перед статичной ролью ставится знак $.

2.5.1.10.9. Использование дружественных связей

Дружественная (friend) связь предполагает, что класс-клиент имеет право доступа к атрибутам и опе­рациям класса-сервера, не являющимся общими. Это свойство можно задать для ассоциаций, агрега­ций, зависимостей и обобщений. В исходный код класса-сервера войдет логика, поддерживающая дружественную видимость для клиента.

2.5.1.10.10. Задание метода включения

Параметр Containment of <Имя класса> определяет, каким образом будут включаться созданные атрибуты аг­регации: по значению или по ссылке. Если два класса связаны отношением агрегации, то в класс-целое войдут атрибуты для каждого класса-части. В поле Containment of <Имя класса> устанавливается, будут ли эти данные атрибутами по значению пли по ссылке.

Значение By Value (По значению) этого параметра предполагает, что целое и часть создаются и разрушаются одновременно. Например, если между классами Window (Окно) и Button (Кнопка) уста­новлена агрегация по значению, соответствующие объекты создаются и разрушаются в одно и то же время. На языке UML агрегацию по значению помечают закрашенным ромбиком (см. рис. 26).

Рис. 26. Агрегация по значению

Агрегация по ссылке (By Reference) предполагает, что целое и часть создаются и разрушаются в раз­ное время. Если класс TaskSourceList состоит из классов TaskSource, то агрегация по ссылке означает, что как класс TaskSourceList, так и классы TaskSource могут находиться или не находиться в памяти компьютера в любой момент времени независимо друг от друга. Если они имеются в памяти, то взаи­модействуют друг с другом посредством агрегации. Классы TaskSource и TaskSourceList создаются и разрушаются в разное время. Агрегация по ссылке отображается в виде пустого ромбика (см. рис. 27).

Рис. 27. Агрегация по ссылке

2.5.1.10.11. Элемент связи

Элементом связи (link element), известным также как класс Ассоциаций (Association class), называется место, где хранятся относящиеся к ассоциации атрибуты. Допустим, что у нас есть два класса: Student и Course, и необходимо добавить на диаграмму атрибут Grade (Год обучения).

В этом случае возникает вопрос: в какой класс добавить атрибут? Если мы поместим его в класс Stu­dent, то придется вводить атрибут для каждого посещаемого студентом курса, что значительно увели­чит этот класс. Если же мы поместим его в класс Course, то придется задавать атрибут для каждого посещающего этот курс студента.

Для решения подобной проблемы можно создать класс Ассоциаций. В него следует поместить ат­рибут Grade, относящийся в большей степени к связи между курсом и студентом, чем к какому-то клас­су конкретно. Нотация UML для класса Ассоциаций представлена на рис. 28.

Рис. 28. Элементы связи (классы Ассоциаций)

2.5.2. Диаграммы Состояний

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

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

Для анализа динамики поведения класса необходимо рассмотреть его атрибуты. Экземпляр класса может вести себя по-разному в зависимости от их значений. Полезно исследовать также связи между классами. Рассмотрите все связи, множественность кото­рых может принимать нулевое значение. Нули указывают, что данная связь не является обязатель­ной. Ведет ли себя экземпляр класса по-разному при наличии и отсутствии связи? Если да, то он имеет несколько состояний.

В
среде Rose на основании диаграмм Состояний не генерируется никакого исходного кода. Они нужны для того, чтобы документировать динамику поведения класса, благодаря чему аналитики и разработчики получат о нем четкое представление. Реализацией заложенной в эти диаграммы логики будут заниматься разработчики. Как и в случае других диаграмм UML, диаграммы Состояний дают команде возможность обсудить и документировать логику перед началом процесса кодирования.

Рис. 29. Диаграмма состояний для класса Заказ.

2.5.2.1. Создание диаграмм Состояний

В среде Rose можно создать одну диаграмму Состояний для класса. На ней отображаются все опреде­ленные для этого класса состояния и переходы. В браузере диаграмма Состояний располагается ниже класса.

2.5.2.1.1. Добавление состояний

Состоянием (state) называется одно из возможных условий, в которых может существовать объект. Как уже говорилось, для выявления состояний объекта необходимо исследовать две области модели: зна­чения атрибутов объекта и связи с другими объектами. Рассмотрите различные значения, принимае­мые атрибутами. Определите также состояние объекта в зависимости от того, существует некоторая связь или нет.

Находясь в конкретном состоянии, объект может выполнять определенные действия. Например, он может генерировать отчет, осуществлять некоторые вычисления или посылать событие другому объ­екту. В Rose информация такого типа добавляется к модели посредством окна спецификации состоя­ния.

С состоянием можно связывать данные пяти типов: деятельность, входное действие, выходное действие, событие и история состояния.

Деятельностью (activity) называется поведение, реализуемое объектом, когда он находится в данном со­стоянии. Например, когда поручение находится в состоянии "Инициализация", пользователь вносит данные. Деятельность — это прерываемое поведение. Оно может выполняться до своего завершения, если объект находится в данном состоянии, или может быть прервано переходом объек­та в другое состояние. Если деятельностей много, то их можно выделить в отдельную диаграмму. Деятельность изображают внутри самого состояния, ей должны предшество­вать слово do (делать) и "/". Например: do/ заполнить все поля.

Входным действием (entry action) называется поведение, которое выполняется, когда объект переходит в данное состояние. Например, при переходе поручения в состояние "Инициализация" выпол­няется действие "Сгенерировать новый номер поручения", независимо от того, откуда объект переходит в это со­стояние. Таким образом, данное действие осуществляется не после того, как объект перешел в состояние, а скорее как часть этого перехода. В отличие от деятельности, входное действие рассмат­ривается как непрерываемое.

Входное действие также показывают внутри состояния, ему предшествуют слово entry (вход) и "/". Например: entry/ Сгенерировать новый номер поручения.

Выходное действие (exit action) подобно входному. Однако оно осуществляется как составная часть про­цесса выхода из данного состояния. Как и входное, выходное действие является непрерываемым. Например: exit/ Сохранить информацию в БД

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

Do/ ^Цель.Событие(Аргументы),

где Цель — это объект, получающий событие, Событие — посылаемое сообщение, а Аргументы явля­ются параметрами посылаемого сообщения. В Rose все эти детали можно добавить к посылаемому со­бытию.

Деятельность может также выполняться в результате получения объектом некоторого события.

2.5.2.1.2. Добавление переходов

Переходом (transition) называется перемещение из одного состояния в другое. Совокупность переходов диаграммы показывает, как объект может переходить из одного состояния в другое. На диаграмме все переходы изображают в виде стрелки, соединяющей два состояния.

Переходы могут быть рефлексивными: объект переходит в то же состояние, в котором он в насто­ящий момент находится. Рефлексивные переходы изображают в виде стрелки, начинающейся и за­вершающейся на одном и том же состоянии.

У перехода существует несколько спецификаций: события, аргументы, ограждающие условия, дейст­вия и посылаемые события.

Событие (event) — это то, что вызывает переход из одного состояния в другое.

Для отображения события на диаграмме можно использовать как имя операции, так и обычную фразу. У событий могут быть аргументы. Большинство переходов должно иметь события, так как именно они инициируют переход. Тем не менее, бывают и автоматические переходы, не имеющие событий. При этом объект сам перемещает­ся из одного состояния в другое со скоростью, предусматривающей выполнение входных действий, деятельности и выходных действий.

Ограждающие условия (guard conditions) определяют, когда переход может быть выполнен, а когда нет. В нашем примере событие " Сохранить в БД" переведет поручение из состояния "Инициализация" в состоя­ние "Поручение не выполнено", но только если все поля поручения заполнены. В противном случае переход не осуществится. На диаграмме ограждающие условия заключают в квадратные скобки и размещают вдоль линии перехода после имени события. Ограждающие условия задавать необязательно. Однако если существует несколько автоматиче­ских переходов из состояния, необходимо определить для них взаимно исключающие ограждающие условия. Это поможет читателю диаграммы понять, какой путь перехода будет выбран автоматиче­ски.

Действием (action) является непрерываемое поведение, выполняющееся как часть перехода. Входные и выходные действия показывают внутри состояния, поскольку они определяют, что происходит, ког­да объект входит или выходит из состояния. Другие действия изображают вдоль линии перехода, так как они не должны осуществляться при входе или выходе из состояния. Действие размещают вдоль линии перехода после имени события, ему предшествует косая чер­та (/).

2.5.2.2. Задание специальных состояний

На диаграмму можно добавить два специальных состояния объекта: Начальное состояние и Конечное состояние.

Начальным (start) называется состояние, в котором объект находится сразу после своего создания. В нашем примере при создании счет имеет состояние "Открыт". На диаграмме его изображают в виде закрашенного кружка. От него к первоначальному состоянию проводится переход.

Начальное состояние обязательно — читатель должен знать, с чего начинается объект. На диаграмме может быть только одно начальное состояние.

Конечным (stop) называется состояние, в котором объект находится непосредственно перед уничтоже­нием. Его изображают в виде закрашенного кружка с незакрашенным ободком. Конеч­ные состояния не являются обязательными, их может быть сколько угодно.

2.5.2.2.1. Использование вложенных состояний

Для уменьшения беспорядка на диаграмме можно вкладывать состояния одно в другое. Вложенные со­стояния называются подсостояниями (substates), а те, в которые они вложены, — суперсостояниями (su­perstates).

Если у нескольких состояний имеются идентичные переходы, эти состояния можно сгруппиро­вать вместе в суперсостояние. Затем, вместо того чтобы поддерживать одинаковые переходы (по од­ному на каждое состояние), их можно объединить, перенеся в суперсостояние.

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

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

Во-вторых, чтобы запомнить, где был объект, можно использовать историю состояний (state histo­ry). В таком случае объект может выйти из суперсостояния, а затем вернуться точно в то место, отку­да вышел.

При подключении истории состояний в углу диаграммы располагается буква "Н" в кружке.

2.6. Диаграммы Представления Компонентов

2.6.1. Представление Компонентов

Компонентом (component) называется физический модуль кода. Компонентами бывают как библиоте­ки исходного кода, так и исполняемые файлы. Например, если вы работаете на языке C++, то файлы .СРР и .Н будут отдельными компонентами. Получающийся при компиляции исполняемый .ЕХЕ файл также является компонентом системы.

Перед началом генерации кода необходимо соотнести каждый из файлов с соответствующими компонентами. На языке C++ каждый класс соотносится с двумя компонентами, один из которых со­ответствует .СРР файлу этого класса, а другой — .Н файлу. На Java каждый класс соответствует одному компоненту — файлу с расширением JAVA этого класса. При генерации кода Rose использует инфор­мацию о компонентах для создания соответствующих файлов библиотек кода.

После создания компонентов их помещают на диаграмму Компонентов и рисуют связи между ними. Единственный тип связей между компонентами — это зависимости. Он показывает, что один из компонентов должен компилироваться перед началом компиляции другого.

2.6.2.Типы компонентов

В среде Rose можно использовать различные пиктограммы для изображения компонентов разных ти­пов. Как уже упоминалось, существуют два основных типа компонентов: библиотеки исходного кода и исполняемые компоненты. Для представления каждого из них также применяется несколько различ­ных значков (см. рис. 30).

Рис.30. Типы компонентов

Компонент (Component). Этот значок соответствует программному модулю с хорошо опреде­ленным интерфейсом. В поле Stereotype (Стереотип) окна спецификации компонента можно определить его тип (ActiveX, Applet, Application, DLL, исполняемый файл и другие).

Спецификация и тело подпрограммы (Subprogram Specification and Body). Эти значки представляют видимую спецификацию подпрограммы и тело ее реализации. Обычно подпрог­рамма состоит из коллекции стандартных программных компонентов (subroutines) и не содер­жит определений класса.

Главная программа (Main Program) Это файл, содержащий корень программы. Например, в среде PowerBuilder такой файл содержит объект приложения.

Спецификация и тело пакета (Package Specification and Body) Пакет в данном случае — это реализация класса. Спецификацией пакета является заголовочный файл со сведениями о прото­типах функций для класса. На C++ это файл с расширением .Н. Тело пакета содержит код опера­ций класса. На C++ это файл .СРР. При использовании языка Java значок спецификации пакета представляет файл с расширением JAVA.

Спецификация и тело задачи (Task Specification and Body) Эти пиктограммы отображают пакеты, имеющие независимые потоки управления. Исполняемый файл обычно представляют как спецификацию задачи с расширением .ЕХЕ.

При выборе в качестве языка Delphi, можно в качестве стереотипа компонента выбирать просто Component (Компонент).

2.6.3. Диаграмма Компонентов

Диаграммой Компонентов (Component diagram) называется диаграмма UML, на которой показаны ком­поненты системы и зависимости между ними (см. рис. 31).

На такой диаграмме можно видеть исходный код и исполняемые компоненты системы.

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

Рис.31. Диаграммой Компонентов.

2.6.3.1. Добавление компонентов

После создания диаграммы необходимо поместить туда компоненты. В панели инструментов диаграм­мы Компонентов имеются кнопки для всех описанных выше типов. В проектах на C++, Java и Visual Ba­sic чаще всего используются значки спецификации пакета, тела пакета и исполняемых файлов. Как говорилось ранее, пиктограмма спецификации пакета применяется для обозначения заголовочных файлов. Для файлов, созданных на языке Java, проектов Visual Basic и файлов DLL используются знач­ки спецификации пакета или значки компонента. Пиктограмму тела пакета применяют для представ­ления файлов .СРР.

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

Как и классы, компоненты можно объединять в пакет для лучшей организации. Как правило, для каждого пакета Логического представления системы создается один пакет представления Компонен­тов.

2.6.3.2. Определение деталей компонентов

Как и для остальных элементов модели Rose, для компонентов можно определить подробные специ­фикации:

1) Stereotype (Стереотип) Стереотип компонента. Определяет пиктограмму, применяемую для представления компонента на диаграмме.

Выше рассматривались следующие стереотипы: <none> (отсутствует, будет использована пик­тограмма компонента), спецификация подпрограммы, тело подпрограммы, главная программа, спецификация пакета, тело пакета, исполняемый файл, DLL-файл, спецификация задачи и тело задачи. Кроме того, существуют стереотипы для компонентов ActiveX, апплетов (applet), прило­жений (application), пакетов общего типа (generic package) и подпрограмм общего типа (generic subprogram).

Для представления компонентов других типов на используемом языке программирования в приложении вы можете создать дополнительные стереотипы самостоятельно.

2) Language (Язык) Rose позволяет назначать языки для программирования отдельных компонен­тов. Если вы работаете с версией Rose Enterprise, то можете программировать часть модели на C++, часть — на Java, часть — на Visual Basic и т.д.

3) Declarations (Декларации) Rose позволяет создавать дополнительные декларации, добавляе­мые для каждого компонента при генерации кода. Декларациями называют специфичные для языка операторы, применяемые для объявления переменных, классов и т.д. Оператор #include языка C++ также считается декларацией.

4) Classes (Классы) Перед началом генерации кода класса нужно соотнести класс с компонентом. Это действие позволяет Rose определить, в каком физическом файле следует сохранить код класса. С каждым компонентом можно соотнести один или несколько классов. В результате в Логиче­ском представлении после имени класса появится имя соответствующего компонента, заклю­ченное в скобки.

2.6.3.3. Добавление зависимостей между компонентами

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

Здесь компонент А зависит от компонента В. Иначе говоря, в компоненте А существует некото­рый класс, зависящий от какого-то класса компонента В.

Эти связи имеют значение при компиляции. Так как А зависит от В, А не может быть скомпилиро­ван до В. Анализируя эту диаграмму, можно понять, что сначала компилируется В, а затем уже А.

Как и в случае пакетов, следует избегать циклических зависимостей между компонентами. Если А зависит от В, а В от А, то ни один из них нельзя компилировать, пока не скомпилирован другой. Та­ким образом, оба компонента должны рассматриваться как один большой компонент. Все цикличе­ские зависимости необходимо устранить до начала генерации кода.

Зависимости связаны также с проблемами управления системой. Если А зависит от В, то любые из­менения в В повлияют на А. С помощью диаграммы Компонентов персонал сопровождения системы может оценить последствия любых вносимых изменений. Если компонент зависит от большего числа других компонентов, велика вероятность того, что его затронут изменения в системе.

Наконец, зависимости дают возможность понять, какие части системы можно использовать по­вторно, а какие нельзя. В нашем примере А трудно будет применить второй раз. Поскольку он зави­сит от В, то сделать это можно только совместно с В. С другой стороны, В легко использовать повторно, так как он ни от чего не зависит. Чем от меньшего числа компонентов зависит данный, тем легче его будет использовать повторно.

2.7. Диаграммы Представления Размещений

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

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

Диаграмма Размещения содержит графические изображения процессоров, устройств, процессов и связей между ними. В отличие от диаграмм логического представления, диаграмма Размещения является единой для системы в целом, поскольку должна всецело отражать особенности её реализации. Эта диаграмма, по сути, завершает процесс объектно-ориентрованного анализа и проектирования для конкретной программной системы и её разработка, как правило, является последним этапом спецификации модели.

Перечислим цели, преследуемые при разработке диаграммы Размещения:

- определить распределение компонентов системы по её физическим узлам;

- показать физические связи между всеми узлами реализации системы на этапе её исполнения;

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

Для обеспечения этих требований диаграмма Размещения разрабатывается совместно системными аналитиками, сетевыми инженерами и системотехниками.

2.7.1. Узел

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

Графически на диаграмме Размещения узел изображается в форме трёхмерного куба. Узел имеет собственное имя, которое указывается внутри этого графического символа. Сами узлы могут представляться как в качестве типов (рис.32, а), так и в качестве экземпляров (рис. 32, б).



(а) (б)

Рис.32. Графическое изображение узла на диаграмме Размещения.

В первом случае имя узла записывается без подчёркивания и начинается с заглавной буквы. Во втором имя узла-экземпляра записывается в виде <имя узла ‘:’ имя типа узла>. Имя типа узла указывает на некоторую разновидность узлов, присутствующих в модели системы.

Например, аппаратная часть системы может состоять из нескольких персональных компьютеров, каждый из которых соответствует определённому узлу-экземпляру в модели. Однако все эти узлы-экземпляры относятся к одному типу узлов, а именно узлу с именем типа «Персональный компьютер». Так, на представленном выше рисунке (рис. 32, а) узел с именем «Сервер» относится к общему типу и никак не конкретизируется. Второй же узел (рис. 32, б) является анонимным узлом-экземпляром конкретной модели принтера.

Так же, как и на диаграмме Компонентов, изображения узлов могут расширяться, чтобы включить некоторую дополнительную информацию о спецификации узла. Если дополнительная информация относится к имени узла, то она записывается под этим именем в форме помеченного значения

(рис.33).

Рис. 33. Графическое изображение узла-экземпляра с дополнительной

информацией в форме помеченного значения

Если необходимо явно указать компоненты, которые размещаются на отдельном узле, то это можно сделать двумя способами. Первый из них позволяет разделить графический символ узла на две секции горизонтальной линией. В верхней секции записывают имя узла, а в нижней секции – размещённые на этом узле компоненты (рис. 34, а).

Второй способ разрешает показывать на диаграмме Размещения узлы с вложенными изображениями компонентов (рис.34, б). Важно помнить, что в качестве таких вложенных компонентов могут выступать

т
олько исполняемые компоненты.

(а) (б)

Рис. 34 Варианты графического изображения узлов-экземпляров

с размещёнными на них компонентами

В качестве дополнения к имени узла могут использоваться различные стереотипы, которые явно специфицируют назначение этого узла. Хотя в языке UML стереотипы для узлов не определены, в литературе встречаются следующие их варианты: «процессор», «датчик», «модем», «сеть», «консоль» и др.

2.7.2. Соединения

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

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

или ограничением. Так, на представленном ниже фрагменте диаграммы Размещения (рис. 35) явно определены не только требования к скорости передачи данных в локальной сети с помощью помеченного значения, но и рекомендации по технологии физической реализации соединений в форме примечания.



Рис. 35. Фрагмент диаграммы Размещения с соединения ми между узлами.

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

Рис.36. Диаграмма Размещения с отношением зависимости между узлами.

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

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

2.7.3. Рекомендации по построению диаграммы Размещения

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

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

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

- Моделирование программных систем, реализующих технологию доступа к данным «клиент-сервер». Для подобных систем характерно чёткое разделение полномочий и, соответственно, компонентов между клиентскими рабочими станциями и сервером базы данных. Возможность реализации «тонких» клиентов на простых терминалах или организация доступа к хранилищам данных приводит к необходимости уточнения не только топологии системы, но и её компонентного состава.

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

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

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

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

2.8. Дополнительные возможности Rational Rose

2.8.1. Генерация программного кода

2.8.1.1. Подготовка к генерации программного кода

Процесс генерации программного кода состоит из шести основных этапов:

1) проверка модели;

2) создание компонентов;

3) отображение классов на компоненты;

4) установка свойств генерации программного кода;

5) выбор класса, компонента или пакета;

6) генерация программного кода.

В разных языках не все этапы обязательны. Так, программы C++ генерируются и без предварите­льного создания компонентов. Создавать код программ на любом языке можно, не выполняя шага проверки модели, хотя во время генерации это порой приводит к различным ошибкам. Проверка модели поможет выявить ее неточности и недостатки, нежелательные с точки зрения последующей генерации программ. Этапы, на которых рассматриваются компоненты, — это способ отобразить логическую схему системы на ее физическую реализацию, причем на этих этапах собирается большой объем полезной информации. Если пропустить эти этапы, то для создания ком­понентов Rose воспользуется пакетной структурой логического представления.

2.8.1.2. Этап первый: проверка модели

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

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

В представленном далее сообщении указано, что объект диаграммы Последовательности или Ко­оперативной диаграммы не был отображен на класс.

Unresolved reference from use case “<Имя варианта использования>” to Classltem with name (Unspecified) by object <Имя объекта>

Посмотрите на объекты диаграммы Последовательности или Кооперативной диаграммы. В каж­дом поле должно быть указано имя объекта с двоеточием, за которым следует имя класса.

Найдите объект без имени класса. Щелкните правой клавишей мыши на объекте и выберите Open Specification в сокращенном меню. В раскрывающемся списке Class окна спецификации объекта выбе­рите класс объекта.

Следующее сообщение позволяет узнать о том, что некоторому сообщению диаграммы Последова­тельности или Кооперативной диаграммы не соответствует никакая операция:

Unresolved reference to Operation with name <Имя сообщения> in message <Имя сообщения> between <Имя класса> and <Имя класса> in Sequence diagram <Имя варианта использования>/<Имя диаграммы Последовательности> Щелкните правой клавишей мыши на соответствующем сообщении диаграммы (ошибка в окне журнала позволит узнать имя сообщения и его диаграмму Последовательности или Кооперативную диаграмму) и отобразите сообщение на операцию. При необходимости создайте для сообщения но­вую операцию.

2.8.1.2.1. Нарушения правил доступа

С помощью пункта меню Check Model можно выявить большую часть неточностей и ошибок в модели. Пункт меню Access Violations позволяет обнаружить нарушения правил доступа, возникающие тогда, когда существует связь между двумя классами разных пакетов. При этом связи между самими пакетами нет. Например, если существует связь между классами Task пакета Entities и FillForm пакета Boundaries, то обязательно должна существовать и связь между пакетами Entities и Boundaries. Если послед­няя связь не установлена, Rose выявит нарушение правил доступа.

2.8.1.3. Этап второй: создание компонентов

Второй этап процесса генерации программного кода — создание компонентов для реализации клас­сов. Существуют компоненты самых разных типов: файлы исходного программного кода, исполняе­мые файлы, runtime-библиотеки, компоненты ActiveX, алплеты и т.д. Перед генерацией программ можно отобразить каждый из классов на соответствующий компонент исходного программного кода.

После создания компонентов можно связать их на диаграмме Компонентов. Связи между компо­нентами — это зависимости компиляции в системе.

При генерации программ на C++, Java или Visual Basic выполнять подобный шаг необязательно, В Java и Visual Basic соответствующий компонент для каждого из классов Rose создаст автоматически, однако при этом зависимости между классами не генерируются.

2.8.1.4. Этап третий: отображение классов на компоненты

Каждый компонент — это файл с исходным программным кодом для одного или нескольких классов. В C++ каждый класс отображается на два компонента с исходным кодом: файл заголовка и основной файл (тело). В PowerBuilder на один компонент отображается несколько классов. Компонентом с ис­ходным программным кодом в PowerBuilder является файл библиотеки PowerBuilder (.PBL). В Java каждый компонент — это один файл . JAVA.

Третий этап процесса генерации программного кода — отображение каждого из классов на соот­ветствующие компоненты. В PowerBuilder необходимо отобразить каждый класс на компонент перед генерацией программы, в то время как в C++, Java и Visual Basic этот шаг не является обязательным, Rose может генерировать программный код самостоятельно. При генерации в Rose программ Java и Visual Basic производится еще и генерация нужных компонентов и отображение классов. Однако для C++ компоненты не создаются автоматически, а кроме того, ни для одного из языков не генерируются зависимости. Поэтому рекомендуем выполнять этот шаг независимо от применяемого языка программирования.

2.8.1.5. Этап четвертый: установка свойств генерации программного кода

Можно установить несколько параметров генерации программного кода для классов, атрибутов, ком­понентов и других элементов модели.

Этими свойствами определяется способ генерации программ. В Rose предлагаются общеупотреби­тельные установки по умолчанию.

Например, одним из свойств генерации программного кода для атрибута C++ является GenerateGetOperation, которым определяется, будет ли создана для этого атрибута операция Get(). Одним из свойств класса Java является GenerateDefaultConstructor, которое определяет, создавать или нет кон­структор для класса автоматически. Одним из свойств связи в Visual Basic является GenerateDataMember. Оно определяет, создавать или нет атрибут для поддержки этой связи.

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

Для анализа свойств генерации программного кода выберите Tools > Options, а затем вкладку со­ответствующего языка.

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

Любые изменения, вносимые в набор свойств в окне Tools > Options, воздействуют на все элемен­ты модели, для которых используется данный набор. Так, при изменении свойства GenerateDefaultConstructor класса во вкладке Java изменятся все классы модели, реализуемой в Java.

Иногда нужно изменить свойства генерации программного кода для одного класса, атрибута, опе­рации и т.д. Для этого откройте окно спецификации элемента модели. Выберите вкладку языка (C++, Java или PowerBuilder) и измените свойства здесь. Все изменения, вносимые в окне спецификации элемента модели, оказывают влияние только на этот элемент.

2.8.1.6. Этап пятый: выбор класса, компонента или пакета

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

При выборе пакета представления Компонентов генерируются все его компоненты.

Программный код можно генерировать одновременно для нескольких классов, компонентов или пакетов. На диаграмме с помощью клавиши Ctrl выберите классы, компоненты или пакеты, для кото­рых нужно сгенерировать программный код, а затем — соответствующую команду генерации в меню см. ниже.

2.8.1.7. Этап шестой: генерация программного кода

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

2.8.1.8. Результаты генерации

Во время генерации программного кода Rose выбирает информацию из логического и компонентно­го представлений модели. Хотя полностью законченное приложение не может быть создано ни одним инструментом моделирования, Rose генерирует большой объем "скелетного" программного кода.

Генерируются все классы модели. Код включает атрибуты каждого класса, в том числе видимость, тип данных и значе­ние по умолчанию.

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

2.8.1.8.1. Компоненты

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

После генерации файлов остается сделать два шага. Сначала разработчики обращаются к файлам и кодируют каждую из операций классов. Затем проектируется графический пользовательский интер­фейс.

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

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

Если компоненты не установлены, то для определения структуры каталогов Rose использует па­кетную структуру логического представления. И в этом случае каталогом по умолчанию является ката­лог Rose, а изменить его можно свойствами генерации программного кода.

2.8.2. Обратное проектирование

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

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

В процессе обратного проектирования Rose собирает сведения о: Классах, Атрибутах, Операциях, Связях, Пакетах, Компонентах. Используя эти сведения, Rose создает или обновляет объектную модель. В зависимости от того, ка­кой язык применяется для обратного проектирования, можно создать новую модель Rose или обно­вить текущую.

Если существует файл с исходным программным кодом, содержащий класс, то в процессе обратного проектирования создается соответствующий класс модели Rose. Каждый из атрибутов и каждая из операций класса становятся атрибутами и опе­рациями нового класса модели. Вместе с именами атрибутов и операций Rose выбирает информацию об их видимости, типах данных и значениях по умолчанию.

Если классы первоначально были созданы с помощью Rose и если в их программный код были внесены некоторые изменения, то они в процессе обратного проектирования отражаются в модели. Например, если удалить из программы операцию, то во время обратного проектирования она удалит­ся и из модели. Если добавить атрибут или операцию непосредственно в программный код, то он или она при обратном проектировании добавится в модель.

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

2.8.3. Проектирование БД с использованием Rational Rose

Проектирование модели данных и физической структуры для СУБД очень трудоемкий процесс, связанный, в основном, с рутинным описанием большого числа однотипных объектов, использующихся для представления данных и структуры БД. Rational Rose даёт возможности по автоматизации создания концептуальных, логических и физических моделей данных, дополняя классический подход проектирования реляционных схем ER моделями, возможностями более абстрактного семантического моделирования на основе объектного подхода и средств UML. Использование UML дает возможность проектировать схемы БД, ориентированные как на классические реляционные, так и на объектно-реляционные СУБД.

Встроенные в пакет Rational Rose Enterprise Edition утилиты Rational Rose Data Modeler и Rose Oracle8 позволяют осуществлять прямую и обратную генерацию схем БД. Под схемой БД понимается модель структуры хранения данных, элементов для их представления и манипулирования в форме позволяющей без дополнительной обработки отображать такую модель в описание БД на языке, принятом в выбранной целевой СУБД.

Утилита Rational Rose Data Modeler ориентированна на создание реляционных схем БД для наиболее часто используемых СУБД, поддерживающих язык описания и манипулирования данными SQL (Structured Query Language – структурированный язык запросов) в той или иной разновидности (диалекте конкретной СУБД). При построении схемы используются термины реляционных БД: отношение, атрибут, триггер, хранимая процедура и т. д.

Rose Oracle8 ориентированна на объектно-реляционную концепцию фирмы Oracle Corporation. Данная утилита позволяет в процессе создания схемы БД использовать как реляционные, так и специфические для СУБД Oracle объекты представления данных: типы, определенные пользователем, коллекции, методы объектных типов и т.д.

2.8.3.1. Использование стереотипов для представления схем БД

В Rational Rose активно используется механизм стереотипов, что позволяет адаптировать процесс моделирования на UML под нужды представления схем БД. Элементы модели ИС, связанные с проектированием БД, с соответствующими стереотипами для элементов стандартных диаграмм UML, приведены в таблицах 3 и 4.

Таблица 3 – Элементы модели данных (для моделей Rational Data Modeler)

Элемент модели данных

UML диаграмма

Элемент UML

Название стереотипа

БД

компонентов

компонент

Database

Табличное пространство

компонентов

компонент

Tablespace

Схема

пакет

Schema

Набор доменов

пакет

Domain Package

Домен

классов

класс

Domain

Таблица

классов (Data Model Diagram)

класс

Table

Просмотр

классов (Data Model Diagram)

класс

View

Хранимые процедуры

классов (Data Model Diagram)

класс

SP Container

Таблица 4 – Элементы модели данных (для моделей Rational Oracle8)

Элемент модели данных

UML диаграмма

Элемент UML

Название стереотипа

БД

компонентов

компонент

Database

Табличное пространство

компонентов

компонент

Tablespace

Схема

компонентов

компонент

Schema

Объектный тип

классов

класс

ObjectType

Реляционная таблица

классов

класс

RelationalTable

Объектная таблица

классов

класс

ObjectTable

Встраиваемая таблица

классов

класс

NestedTable

Реляционный просмотр

классов

класс

RelationalView

Объектный просмотр

классов

класс

ObjectView

Коллекция

классов

класс

VARRAY

БД

Б
аза данных для модели ИС представляется в качестве системы физического хранения данных и обеспечения доступа к ним. С БД взаимодействуют другие компоненты системы (например, прикладное ПО), с ней связаны схемы данных. Изображение БД на диаграмме компонентов приведено на рисунке 37.

Рис.37. БД в контексте диаграммы компонентов

Табличное пространство

Табличное пространство представляет собой физическое хранилище объектов данных. С ним связан файл БД и хранимые в нем объекты. Изображение табличного пространства приведено на рисунке 38.



Рис.38. Табличные пространства

Схема

Для моделей Rose Data Modeler схемы представляются как логически связанные группы объектов данных. Описание схемы производится на базе пакета (Рисунки 39 и 40). В моделях Rational Oracle8, схема – компонент, в котором реализуются объекты данных, логическое размещение которых может быть представлено разнообразными пакетами (Рисунки 41 и 42).



Р
ис.39. Вид схемы в браузере Rational Rose (Data Modeler)

Р
ис.40. Пакет со стереотипом «Schema» (Data Modeler)

Рис.41. Вид схемы в браузере Rational Rose (Oracle8)



Рис.42. Компонент со стереотипом «Schema» (Oracle8)

Домены

Описание прототипов для сходных атрибутов таблиц помещается в домены (Рисунки 43 и 44). В дальнейшем, при описании таблиц, указав для атрибута домен, автоматически осуществляется определение типа, индекса, ограничений.



Р
ис.43. Отображение доменов в браузере Rational Rose

Рис.44. Отображение доменов на диаграмме классов

Таблица, просмотр, хранимые процедуры

Н
а рисунке 45 показан пример диаграммы классов (Data Model Diagram), содержащий таблицы: EMP, DEPT; просмотр: V_0; хранимые процедуры: SP_0.

Рис.45. Пример диаграммы реляционной схемы БД

Объектный тип, реляционная таблица, объектная таблица, встраиваемая таблица, реляционный просмотр, объектный просмотр, коллекция

На рисунке 46 показан пример диаграммы классов (Oracle 8), содержащий:

- OT1 – объектный тип;

- V1 – коллекцию объектов (максимум 30) типа ОТ1;

- OTBL1 – объектную таблицу, содержащую объекты типа ОТ1;

- NT1 – встраиваемую таблицу, содержащую объекты типа ОТ1, являющуюся типом атрибута T1 таблицы RT4;

- OV1 – объектный просмотр, типа ОТ1, содержащий объекты, значения атрибутов которых инициализируются значениями атрибутов реляционной таблицы RT1

- RT1, RT2, RT4 – реляционные таблицы;

- RV1 – реляционный просмотр, в котором задействованы атрибуты таблиц RT2 и RT1.


Рис.46. Пример диаграммы объектно-реляционной схемы БД

2.8.3.2. Прямая и обратная генерация схем БД
2.8.3.2.1. Формирование схем на основе диаграмм классов

Процесс преобразование логической модели данных, представленной каноническими диаграммами классов, в схемы БД заключается в интерпретации существующих объектов модели в объекты схемы. Такая интерпретация может быть проведена вручную, путем использования мастеров создания и описания объектов схемной модели, а может быть выполнена автоматически. Rational Rose предоставляет возможности автоматического преобразования диаграммы классов в реляционную схему БД для выбранной СУБД, путем применения утилиты Rose Data Modeler.

Создание компоненты БД

На диаграмме компонентов, используя функцию «Data Modeler–>New–>Database», можно создать компонент БД (Рисунок 47). Для компонента определяется имя, целевая СУБД и текстовое описание. Вид целевой СУБД определяет специфику описания объектов БД и диалект SQL для генерации кода БД. Rose Data Modeler поддерживает следующие виды СУБД (DBMS):

- ANSI SQL 92 (по умолчанию),

- IBM DB2 5.x/6.x/7.x,

- IBM DB2 OS390 5.x/6.x,

- Microsoft SQL Server 6.x/7.x/2000.x,

- Oracle 7.x/8.x,

- Sybase Adaptive Server 12.x.



Рис.47. Компонент БД и клиентское приложение

Зависимости между БД и компонентами, являющимися частью ПО, должны быть отражены вручную.

Определение табличных пространств

Д
ля созданной БД можно определить табличные пространства. Выбрав компонент БД, командой «Data Modeler–>New–>Tablespace», можно создать табличное пространство (Рисунок 48). Для табличного пространства определяется, помимо имени, файл БД, для его физического хранения. С ним связываются все объекты схем БД, которые создаются для данного табличного пространства.

Рис.48. Компонент табличное пространство, определенный для БД

Зависимость между БД и табличным пространством отображается на диаграммах автоматически.

Создание доменов

Командой «Data Modeler–>New–>Domain Package» создается пакет, группирующий определяемые домены. Для пакета определяется вид целевой СУБД. Он должен соответствовать СУБД, для которой проектируются схемы, с использованием создаваемых доменов. В пакете, командой «Data Modeler–>New–>Domain», создаются домены (Рисунки 43 и 49). При этом указывается:

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

- значение по умолчанию;

- ограничения на уникальность (Unique Constraint) и на обязательность присутствия значения (Not Null);

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



Рис.49. Домен с ограничением на возможные значения

Создание схемы

Схему можно создать вручную. Для этого командой «Data Modeler–>New–>Schema» создается схема. Для схемы можно создать диаграмму реляционной схемы БД (Data Model Diagram) на которой могут быть отображены создаваемые таблицы, просмотры и хранимые процедуры. Для схемы указывается имя и БД, для которой она проектируется.

Автоматическое генерация схемы предполагает наличие пакета с «постоянными» (persistent) классами. Такие классы отображаются в таблицы. В таблицы также раскрываются связи-ассоциации многие ко многим. Автоматическое создание схемы выполняется при помощи команды «Data Modeler–>Transform To Data Model», применяемой к пакету с классами логической модели данных. Между пакетом с исходными классами и пакетом-схемой обычно указывается связь зависимость, существенная для модели ИС в целом (см. рис.50).



Рис.50. Пакет с классами и созданная на его основе схема

Построение таблицы на основе класса

«Постоянные» (persistent) классы автоматически отображаются в таблицы, при этом не учитываются операции классов (см. рис.51). Для таблицы после её генерации можно указать табличное пространство, для реализации.



Рис.51. Класс «Item» c соответствующей таблицей

Атрибуты классов автоматически становятся атрибутами таблиц. Типы атрибутов таблиц формируются на основе соответствия между скалярными типами диаграмм классов и типами, принятыми в диалекте SQL целевой СУБД. Например, для Oracle 8.x: Long преобразуется в NUMBER (10), String – VARCHAR2, Double – NUMBER (20).

Для атрибутов могут быт указаны:

- домен;

- тип;

- значение по умолчанию;

- ограничения на уникальность (Unique Constraint) и на обязательность присутствия значения (Not Null);

- произвольное число ограничений на возможные значения атрибута.

Атрибут может быт выбран в качестве первичного ключа, уникального ключа, части составного ключа.

В

<<PK>> PK_OTCustomer22()

<<FK>> FK_OTCustomer16()

<<Trigger>> TRIG_OTCustomer0()

<<Unique>> TC_OTCustomer271()

<<Check>> TC_OTCustomer272()

<<Index>> TC_OTCustomer274()


PK OTUser_ID:NUMBER(10,0)

money: NUMBER(5,0)

Any: NUMBER(5,0)


OTCustomer


качестве операции класса-таблицы выступают ограничения целостности (определения первичного ключа, внешних ключей), ограничения на возможные состояния таблицы (check constraints), триггеры, индексы (Рисунок 52). По умолчанию при генерации таблицы создаются первичные ключи, можно выбрать опцию для автоматического определения индексов для внешних ключей.

Рис.52. Таблица с определенными ограничениями, индексным атрибутом и триггерами

Преобразования зависимостей

Связи-ассоциации 1:1 и 1:N автоматически преобразуются в не идентифицирующие связи. Пример преобразования показан на рисунке 53.



Р
ис.53. Преобразование связей-ассоциаций 1:1 и 1:N

С
вязь-ассоциация N:N автоматически преобразуется в таблицу, отражающую наличие ассоциации, и идентифицирующие связи от таблиц, соответствующих классам участвующих в ассоциации, к таблице-связи. Пример преобразования показан на рисунке 54.

Рис.54. Преобразование связей-ассоциаций N:N

Внешние ключи таблицы-связи автоматически индексируются для повышения быстродействия работы с данными.

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

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



Рис.55. Преобразование связи-агрегации

Так как класс принадлежности таблицы OTCustomer к связи не обязательный (степень 0..1), то для внешнего ключа таблицы OTAddress (ссылающейся на OTCustomer), автоматически будет определенно ограничение на возможность отсутствия значения у атрибута.

Связь-композиция (агрегация по значению) автоматически преобразуется в идентифицирующую связь (см. рис.56).



Р
ис.56. Преобразование связи-композиции

Связь-обобщение также как и связь-композиция автоматически преобразуется в идентифицирующую связь (см. рис.57).




Рис.57. Преобразование связи-обобщения

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

Создание просмотров

Просмотры создаются на уровне схемы БД. При помощи мастера редактирования просмотров из имеющихся таблиц выбираются необходимые атрибуты и определяются условия выборки, определяется область распространении изменений данных, отображаемых в просмотре (в случае если он определен как модифицируемый). Пример просмотра приведен на рисунке 58.



Рис.58. Пример отображения просмотра на диаграмме схемы БД

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

Создание хранимых процедур

В целях обеспечения эффективности обработки данных в БД могут быть определены хранимые процедуры, представляющие собой подпрограмм работы с данными, исполняемые на сервере БД. Создание хранимых процедур выполняется на уровне схемы БД командой «Data Modeler–>New–>Stored Procedure». По средствам использования соответствующего мастера для процедур могут определяться входные и выходные параметры, тело процедуры.

На схемах БД хранимые процедуры отображаются в виде класса, в котором каждой операции соответствует одна из процедур. Для СУБД Oracle в качестве физической реализацией класса-контейнера хранимых процедур может быть определен «Package» (опция Generate Package), являющийся специфической для СУБД Oracle внутренней структурой, включающей в себя хранимые процедуры.

Генерация SQL скрипта

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

Команда «Data Modeler–>Forward Engineer» примененная к компоненте БД, приведет к созданию скрипта для всех ассоциированных с ней схем и табличных пространств (в случаи их наличия), в которых должны реализовываться объекты этих схем. Применяя команду «Data Modeler–>Forward Engineer» к пакету-схеме, SQL скрипт сгенерируется только для объектов выбранной схемы. Результат генерации можно сохранить в текстовом файле или, пользуясь возможностью подключения к серверу БД, выполнить SQL скрипт. При необходимости исполнения скрипта на сервере БД нужно прежде убедится в наличии всей необходимой для подключения информации (имя сервера, имя пользователя, пароль) и прав на создания и изменение объектов БД.

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

- табличные пространства;

- комментарии;

- таблицы;

- просмотры;

- триггеры;

- хранимые процедуры;

- индексы.

Кроме того, можно выбрать следующие опции:

  • генерация кода для первоначального удаления из БД выбранных

объектов;

  • формирование имён таблиц с учётом префикса,

соответствующего имени схемы БД;

- использование в качестве имен создаваемых объектов строки в двойных кавычках.

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

2.8.3.2.2. Отображение существующих БД в диаграммы Rational Rose

Процесс обратного проектирования БД в Rational Rose заключается в переходе от физической реализации БД к схемной модели, из которой в свою очередь можно осуществить переход к каноническим диаграммам классов. Для обеспечения автоматизации данных переходов Rational Rose предоставляет утилиты Rational Data Modeler и Rational Oracle8. Rational Data Modeler позволяет получать схемы БД и строить для них диаграммы классов. Rational Oracle8 дает возможности для работы с объектно-реляционными схемами Oracle, позволяя анализировать существующие БД (строить для них схемы, проверять синтаксис, формировать отчеты об объектах схемы) и генерировать SQL скрипт для внесения изменений в БД.

Использование Rational Data Modeler

С помощью команды «Data Modeler–>Reverse Engineer» на основе выбранного текстового файла с SQL скриптом, описывающим структуру БД, или подключения к серверу БД, автоматически строится реляционная схема БД. При этом на ней отображаются:

- обязательно: таблицы и связанные с ними ограничениями;

- по выбору: просмотры, триггеры, хранимые процедуры, индексы.

Комментарии, определенные в БД, также отображаются на схеме в качестве документации к объектам.

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

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

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

Полученная схема может быть преобразована в диаграмму классов. Автоматическое преобразование выполняется с помощью команды «Data Modeler–>Transform to Object Model», примененной к пакету-схеме. При генерации диаграммы классов можно определить будут ли при преобразовании рассматриваться табличные атрибуты, соответствующие в схеме первичным ключам. Соответствие между элементами схемы и элементами диаграммы классов, в которые они отображаются, приведено в таблице 5.

Таблица 5 – Соответствие элементов диаграмм классов элементам исходных схем

Элемент схемы

Элемент диаграммы классов

Описание преобразования

степень связи

множествен-ность (multiplicity)

Степень связи таблицы принимается в качестве множественности класса.

атрибут таблицы

атрибут класса

- Каждый атрибут таблицы преобразовывается в атрибут класса с сохранением имени.

- Тип преобразовывается исходя из соответствия, определенного для исходной СУБД. Значение по умолчанию преобразуется в значения для инициализации, вычислимые атрибуты таблиц и атрибуты внешних ключей не рассматриваются.

ограничения

Не рассматриваются.

домены

Не преобразуются, используются в качестве типов для атрибутов классов.

индексы

Не рассматриваются.

идентифици-рующая связь

связь-композиция

Все идентифицирующие связи преобразуются в связи-композиции.

таблица-пересечение (intersection table)

класс-ассоциация,

связь-ассоциация N:N, класс

- Если таблица-пересечение, дополнительно содержит атрибуты не являющиеся первичными или внешними ключами, то создается класс-ассоциация, связанный со связью-ассоциацией N:N.

- Если таблица-пересечение, содержит только атрибуты составного первичного ключа, являющиеся внешними ключами, то создается связь-ассоциация N:N.

- Если таблица-пересечение, содержит дополнительный первичный ключ, то создается класс, раскрывающий связь-ассоциацию N:N.

не идентифицирующая связь

связь-ассоциация

Все не идентифицирующие связи преобразуются в связи-ассоциации.

схема

пакет

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

хранимые процедуры

Не рассматриваются.

триггеры

Не рассматриваются.

таблица

класс

Все таблицы преобразуются в постоянные (persistent) классы с идентичными именами.

Использование Rational Oracle8

Rational Oracle8 позволяет анализировать схемы существующих БД. Использую команду «Oracle8–>Analyze Schema» и осуществив соединение с сервером БД Oracle, Rational Oracle8 автоматически построит диаграмму классов, для выбранной схемы. При этом на диаграмме компонентов создаться компонент-схема с именем схемы БД, выбранной для анализа. В ней будут реализованы все сгенерированные в процессе автоматического анализа объекты. Rational Oracle8 позволяет генерировать: объектные типы, реляционные таблицы, объектные таблицы, встраиваемые таблицы, реляционные просмотры, объектные просмотры и коллекции. Комментарии к объектам, созданные в БД, отображаются комментариями к соответствующим объектам диаграммы классов.

Команда «Oracle8–>Import Oracle8 Data Types» автоматически генерирует скалярные типы, используемые в СУБД Oracle8, в виде классов сгруппированных в пакете Scalar Types (Рисунок 59). Сам пакет реализуется компонентом Oracle8 Scalar, создающимся автоматически и имеющим стереотип «Subprogram Specification». Сгенерированные скалярные типы можно использовать при описании произвольных объектов модели, в случае использования этих типов в схеме БД, связь между схемой и компонентом-контейнером скалярных типов можно отразить при помощи связи-зависимости (см. рис.60).

Рис.59. Классы скалярных типов Oracle8 в окне браузера


Рис.60. Компонент-схема и компонент-контейнер скалярных типов

в окне браузера (слева) и на диаграмме компонентов (справа)

Полученные автоматически схемы можно изменять, создавая новые объекты и редактируя набор имеющихся. Создание новых объектов выполняется при помощи специального мастера, вызываемого командой «Oracle8–>Data Type Creation Wizard». Редактирование осуществляется по средствам обычного мастера работы с классами, используя вкладку свойств Oracle8, или по средствам команд:

- «Oracle8–>Edit Foreign Keys» – редактирование связей между таблицами по средствам управления внешними ключами;

- «Oracle8–>Ordering Wizard» – изменение порядка следования атрибутов (важного для некоторых программ работы с объектными БД).

После внесения в схему БД необходимых корректировок, можно воспользоваться следующими командами:

- «Oracle8–>Syntax Checker» – применительно к выбранному объекту схемы, проверка корректности соответствующего ему SQL скрипта и вывод сведений об ошибках, в случае их наличия;

- «Oracle8–>Reports» – создание подробного отчета об присутствующих на схеме объектах, с возможностью выбора интересующих параметров (критерии группировки, типы интересующих объектов и их свойств и т. д.);

- «Oracle8–>Schema Generation» – генерация SQL скрипта для разработанной схемы (выбор необходимых объектов, синтаксический контроль схемы) с возможностью сохранения его в текстовом файле или исполнения на сервере БД Oracle.

Ниже приведены примеры моделируемых с помощью Rational Oarcle8 объектов данных и соответствующих им SQL скриптов.

Генерация объектных типов (Object Types)

Объектный тип характеризуется набором свойств и методов. Свойства сами могут иметь в качестве своего типа объектный тип. Объектные типы могут быть связаны между собой по ссылке: в одном объекте присутствовать ссылка на другой. Пример отображения объектных типов на диаграмме классов изображен на рисунке 61.


Рис.61. Объектные типы, связанные по ссылке

Соответствующий объектным типам, изображенным на рисунке 61, SQL скрипт имеет следующий вид:

CREATE OR REPLACE TYPE HR.ORDER AS OBJECT (

OR_ID VARCHAR(1),

OR_DATE DATE);

объектный тип ORDER

CREATE OR REPLACE TYPE HR.CUSTOMER AS OBJECT (

CUST_ID VARCHAR(1),

NAME VARCHAR(25),

ORDERS REF HR.ORDER,

MEMBER FUNCTION GET_COUNT RETURN NUMBER);

объектный тип CUSTOMER

ссылка

CREATE OR REPLACE TYPE BODY HR.CUSTOMER IS

MEMBER FUNCTION GET_COUNT RETURN NUMBER IS

aNUMBER NUMBER;

BEGIN

aNUMBER = 123;

return aNUMBER;

END;

END;

метод для CUSTOMER

Генерация объектных просмотров (Object Views)

Объектные просмотры – инструмент, позволяющий перейти от реляционных таблиц на уровень объектно-ориентированного представления данных. Объектные просмотры могут представлять данные различных реляционных таблиц. Связь между ними, порождающими объектными типами, и реляционными таблицами отображается в виде связей-зависимостей (Рисунок 62). Объектный просмотр может содержать условие выборки, редактировать которое позволяет вкладка Oracle8 в мастере редактирования классов.

Р
ис.62. Объектный просмотр,

зависящий от объектного типа и реляционных таблиц

Соответствующий объектному просмотру, изображенному на рисунке 62, SQL скрипт имеет следующий вид:

CREATE OR REPLACE TYPE HR.OTV1 AS OBJECT (

JOB_ID VARCHAR2(10),

JOB_TITLE VARCHAR2(35),

REGION_ID NUMBER(2,6),

REGION_NAME VARCHAR2(25));

объектный тип OTV1, предок для OV1

CREATE OR REPLACE VIEW HR.OV1 OF HR.OTV1

WITH OBJECT OID (JOB_ID) AS

SELECT JOBS.JOB_ID, JOBS.JOB_TITLE,

REGIONS.REGION_ID, REGIONS.REGION_NAME

FROM HR.JOBS,HR.REGIONS

WHERE REGION_NAME LIKE '%TYMEN%';

объектный просмотр OV1 типа OV1, идентификатор объектов просмотра – JOB_ID

задействованные таблицы

условие выборки

Генерация объектных таблиц (Object Tables)

О
бъектные таблицы позволяют помещать объектные типы в реляционную структуру. Каждый картеж объектной таблицы содержится в объекте. Атрибутам таблицы соответствуют свойства объектного типа. Пример изображения объектной таблицы на схеме БД приведен на рисунке 63.

Рис.63. Объектная таблица, определенная на основе объектного типа

Для объектной таблицы, изображенной на рисунке 63, SQL скрипт имеет следующий вид:

CREATE TABLE HR.RT_CUSTOMER OF HR.CUSTOMER;

объектная таблица типа CUSTOMER

Генерация коллекций (VARRAYs)

Коллекция – тип, создаваемый как упорядоченная последовательность элементов одного типа (массив). Тип элементов может быть как скалярным, так и объектным. коллекция может быть использованы в качестве типа для свойств объектов или атрибутов таблиц.

П
ри определении коллекции указывается максимальное число элементов, которое она может содержать. Пример изображения коллекции объектных типов с максимальным числом элементов равным 30 представлен на рисунке 64.

Рис.64. Коллекция объектных типов

Соответствующий коллекции, изображенной на рисунке 64, SQL скрипт имеет следующий вид:

CREATE TYPE HR.OVAR1 AS VARRAY(30) OF HR.OTV1;

коллекция элементов типа OTV1

Генерация встраиваемых таблиц (Nested Tables)

Встраиваемые таблицы – особый вид таблиц, которые могут вкладываться в другие таблицы или объектные типы в качестве их атрибутов или свойств. Пример встраиваемой таблицы объектного типа, вложенной в реляционную таблицу, изображен на рисунке 65.



Рис.65. Встраиваемая таблица и связанные с ней элементы.

Для изображенной на рисунке 65 схемы, SQL скрипт имеет следующий вид:

CREATE TYPE HR.NT1 AS TABLE OF HR.CUSTOMER;

встраиваемая таблица типа CUSTOMER

CREATE TABLE HR.RTWNT1 (

ID NUMBER(5,5) NOT NULL UNIQUE,

NT HR.NT1,

CONSTRAINT RTWNT1_PK PRIMARY KEY (ID))

NESTED TABLE NT STORE AS NT_NTS;

реляционная таблица

NT – вложенная таблица типа NT1

Генерация реляционных таблиц (Relational Tables)

Атрибуты реляционных таблиц представлены атрибутами классов. Ограничения первичных ключей и индексы представлены в виде скрытых (implementation) атрибутов классов, со значениями инициализации, соответствующими атрибутам, для которых они определены. Ограничение внешнего ключа определяется через однонаправленную связь-ассоциацию от таблицы потомка (ссылающейся) к таблице предку (ссылочной). Имени ограничения соответствует имя связи; атрибуту внешнего ключа – имя утончающего (Key/Qualifier) связь атрибута; значение, инициализирующее утончающий атрибут, – уникальный ключ, на который ссылается определяемый таким образом внешний ключ. Редактировать параметры атрибутов (в том числе, задавать дополнительные ограничения) можно при помощи стандартного редактора атрибутов класса, используя вкладку Oracle8.

Реляционные таблицы связанные не идентифицирующей связью показаны на рисунке 66.



Рис.66. Реляционные таблицы на диаграмме классов

Для изображенной на рисунке 66 схемы, SQL скрипт имеет следующий вид:

CREATE TABLE HR.COUNTRIES (

COUNTRY_ID CHAR(2),

COUNTRY_NAME VARCHAR2(40),

CONSTRAINT COUNTRY_C_ID_PK PRIMARY KEY (COUNTRY_ID));

таблица COUNTRIES

ограничение первичного ключа

CREATE TABLE HR.LOCATIONS (

LOCATION_ID NUMBER(4,0),

STREET_ADDRESS VARCHAR2(40),

POSTAL_CODE VARCHAR2(12),

CITY VARCHAR2(30) CHECK (CITY <> 'TYMEN'),

STATE_PROVINCE VARCHAR2(25),

COUNTRY_ID CHAR(2),

CONSTRAINT LOC_ID_PK PRIMARY KEY (LOCATION_ID),

CONSTRAINT LOC_C_ID_FK FOREIGN KEY(COUNTRY_ID) REFERENCES HR.COUNTRIES(COUNTRY_ID));

таблица LOCATIONS

ограничение на возможные значения

ограничение первичного ключа

ограничение внешнего ключа

CREATE INDEX HR.LOC_CITY_IX ON HR.LOCATIONS (CITY);

CREATE INDEX HR.LOC_STATE_PROVINCE_IX ON HR.LOCATIONS (STATE_PROVINCE);

CREATE INDEX HR.LOC_COUNTRY_IX ON HR.LOCATIONS (COUNTRY_ID);

индекс

индекс

индекс

Генерация реляционных просмотров (Relational Views)

Реляционные просмотры – стандартный механизм БД Oracle для представления данных из различных реляционных таблиц, объеденных на основе заданной выборки. Пример просмотра, содержащего данные двух реляционных таблиц, приведен на рисунке 67.



Рис.67. Схема БД из двух реляционных таблиц и основанного на них просмотра

Соответствующий реляционному просмотру, изображенному на рисунке 67, SQL скрипт имеет следующий вид:

CREATE OR REPLACE VIEW HR.RV1 (LOCATION_ID, COUNTRY_ID,

COUNTRY_NAME,STATE_PROVINCE,POSTAL_CODE,CITY,

STREET_ADDRESS)

AS SELECT LOCATIONS.LOCATION_ID, LOCATIONS.COUNTRY_ID,

COUNTRIES.COUNTRY_NAME, LOCATIONS.STATE_PROVINCE,

LOCATIONS.POSTAL_CODE, LOCATIONS.CITY,

LOCATIONS.STREET_ADDRESS

FROM HR.LOCATIONS,HR.COUNTRIES

WHERE LOCATION.COUNTRY_ID = COUNTRIES.COUNTRY_ID;

просмотр RV1

параметры выборки

задействованные таблицы и

условие выборки

3. ЗАДАНИЯ К ЛАБОРАТОРНОЙ РАБОТЕ «ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ С ИСПОЛЬЗОВАНИЕМ CASE-СРЕДСТВА RATIONAL ROSE »

3.1. Цель лабораторной работы

Научиться на практике использовать унифицированный язык моделирования (UML) при проектировании информационных систем с применением CASE-средства Rational Rose (IBM).

3.2. Требования к выполнению лабораторной работы

  1. Диаграмма вариантов использования в представлении вариантов использования должна содержать не менее 7 прецедентов (вариантов использования), из которых 2 являются абстрактными: один – расширяющий, другой – используемый (связь со стереотипами <расширение> и <использование>).

  2. Для каждого варианта использования проектируемой системы необходимо расписать на естественно языке его базовый сценарий (перечень работ) и представить его в виде диаграммы последовательности.

  3. Для одного нетривиального варианта использования или группы вариантов (связанных по определённому смыслу несколько вариантов использования) необходимо разработать диаграмму деятельности.

  4. При проектировании диаграммы классов в Логическом представлении Rational Rose необходимо на первом этапе выделить базовые классы (концептуальный уровень) и определить связи ассоциации между ними. На втором этапе необходимо определить атрибуты и операции проектируемых классов и в целом проверить логическую модель проекта (выделить новые классы, определить слияние классов, определить связи агрегации, наследования).

  5. Для одного сложного класса разработать диаграмму состояний.

  6. Подготовить отчёт о выполнении лабораторной работы со следующим содержанием:

        1. Описание предметной области

        2. Представление вариантов использования

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

2.2. Динамическое поведение системы

2.2.1. Описание базового сценария

2.2.2. Диаграмма последовательности

2.2.3. Диаграмма деятельности

        1. Логическое представление

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

3.2. Диаграмма состояний

        1. Заключение (привести собственные размышления о преимуществах и недостатках применяемой объектно-ориентированной технологии UML при проектировании информационных систем в сравнении со структурными технологиями SADT и DFD).

3.3. Варианты заданий

Варианты заданий определяются в соответствии с заданиями курсовых работ по курсу «Базы данных».

4. ПРИМЕР ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ «СТОЛ ЗАКАЗОВ»

4.1. Представление Вариантов Использования

4.1.1. Диаграмма Вариантов Использования

В качестве действующих лиц (актёров) информационной системы «Стол заказов» могут выступать два субъекта, один из которых является оператором, а другой – клиентом.

Определим варианты использования системы оператором. Для этого обратимся к функциям оператора, описанным в Постановке задачи. Это регистрация пользователей, пополнение счетов клиентов, редактирование ассортимента и корректирование состояния заказа. Оформим их в качестве прецедентов, дав соответственно названия: «Зарегистрировать пользователя», «Пополнить баланс», «Изменить ассортимент» и «Изменить состояние заказа». Кроме того, оператор при каждом входе в систему должен пройти процедуру аутентификации (предоставить свои логин и пароль) для подтверждения прав доступа. «Аутентификация» - ещё один вариант использования системы оператором.

Другой пользователь системы – клиент – также может инициировать этот вариант использования («Аутентификация») для входа в систему, предъявив свои логин и пароль.

После входа в систему клиент может просмотреть ассортимент продукции, оформить новый заказ, изменить или отменить оформленный, но ещё не выполненный заказ. На основе этого можно выделить два варианта использования: «Просмотреть ассортимент» и «Управление заказом». Прецедент «Управление заказом» включает в себя оформление, изменение и отмену заказов. Эти функции работы с заказом целесообразно объединить для избежания загромождения диаграммы и учитывая их общую направленность.

Для удобства оформления нового заказа добавим в систему функцию копирования клиентом своего ранее оформленного заказа. Это будет абстрактный вариант использования «Копировать заказ», расширяющий прецедент «Управление заказом».

Чтобы осуществить функции копирования, редактирования и отмены заказа понадобится вариант использования «Найти заказ», который будет инициироваться пользователем.

При оформлении и редактировании заказов появляется необходимость обращаться к прецеденту «Просмотреть ассортимент». Следовательно, этот вариант использования может инициироваться не только клиентом, но и прецедентом «Управление заказом», поэтому между ними существует связь использования (от прецедента «Управление заказом» к прецеденту «Просмотреть ассортимент»).

Вариант использования «Просмотреть ассортимент» должен предоставлять клиенту возможность просмотра списка продукции, имеющейся в данный момент на складе. При оформлении, редактировании и отмене любого заказа количество товара на складе (а, возможно, и сам факт наличия) меняется. Исходя из этого, необходимо создать ещё один абстрактный вариант использования – «Учёт товаров на складе». Он будет использоваться прецедентами «Просмотреть ассортимент» и «Управление заказами».

П
остроенная согласно этим рассуждениям диаграмма Вариантов Использования представлена на рисунке 68.

Рис.68. Диаграмма Вариантов Использования.

Базовые сценарии всех вариантов использования приведены в приложении А.

4.1.2. Диаграммы Взаимодействия

4.1.2.1. Диаграммы Последовательности

Диаграмма Последовательности – это упорядоченная по времени диаграмма Взаимодействия, читать её надо сверху вниз. У каждого варианта использования имеется большое количество альтернативных потоков. Каждая диаграмма Последовательности описывает один из потоков варианта использования.

Зарегистрировать пользователя

Объектами в этом случае будут являться Оператор и Картотека пользователей. Оператора будем рассматривать в качестве действующего лица, он играет активную роль и поэтому получает фокус управления сразу после своего появления в системе, Картотека пользователей имеет только линию жизни.

Процесс взаимодействия в этой системе начинается с запроса Оператором бланка регистрации пользователя у Картотеки пользователей. Тем самым он посылает сообщение Картотеке пользователей, которое переводит её в активное состояние и вызывает действие – выдачу бланка регистрации пользователей Оператору. Картотека пользователей переходит в состояние ожидания.

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

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

Диаграмма последовательности для варианта использования «Зарегистрировать пользователя» представлена на рисунке 69.

Остальные диаграммы последовательности приведены в приложении Б.

4.1.2.2. Кооперативные диаграммы

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

Rational Rose предоставляет возможность автоматического создания Кооперативных диаграмм на основе диаграмм Последовательности и наоборот.



Рис.69. Диаграмма Последовательности «Зарегистрировать пользователя»

Ниже приведена Кооперативная диаграмма «Зарегистрировать пользователя».



Рис.70. Кооперативная диаграмма «Зарегистрировать пользователя»

4.2. Логическое представление

4.2.1. Диаграммы Классов

Диаграмма Классов служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. На данной диаграмме не указывается информация о временных аспектах функционирования системы.

4.2.1.1. Выявление классов

Проанализировав диаграммы Последовательности, можно выделить следующие классы-сущности: Заказ, Картотека заказов, Картотека пользователей, Клиент, Оператор, Пользователь и Складской учёт. С этими классами будут соотнесены одноимённые объекты диаграмм Взаимодействия.

Помимо вышеперечисленных, целесообразно будет ввести следующие классы-сущности: Товар (характеризует товар), Хранилище (реализует базовые методы работы с БД); а также интерфейсные классы для осуществления взаимодействия с пользователями системы:

- Форма анкета пользователей, окно доступное только оператору, предназначенное для редактирования параметров пользователя;

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

- Форма аутентификации, окно предназначенное для реализации процедуры аутентификации в системе содержит поля ввода "логин" и "пароль";

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

- Форма редактор ассортимента, окно, позволяющее редактировать ассортимент (для оператора) и выбирать товары для включения их в заказ;

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

- Форма управление заказами, окно, предоставляющее возможности управления заказами пользователя.

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

4.2.1.2. Определение атрибутов и операций классов

Заказ

Атрибуты:

- номер паспорта заказчика (pass_num);

- номер заказа (order_num);

- дата заказа (date);

- полная стоимость (total_prise);

- список пунктов заказа (spisok;,

- текущее состояние заказа (status).

Операций нет.

4.2.1.3. Объединение классов в пакеты

На main диаграмме разместим управляющий класс (Главная форма). Остальные классы, учитывая их функциональное назначение, разобьем на четыре пакета: Аутентификации, Работа с пользователями, Работа с товарам и Работа с заказами. Между этими пакетами и управляющим классом существуют связи зависимости (от управляющего класса к пакетам).

Полученная main диаграмма представлена на рисунке 71.

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

Аутентификация

Поместим в этот пакет классы, участвующие в процессе аутентификации: Форма аутентификации, Оператор, Клиент, Пользователь, Картотека пользователей, Хранилище.

Классы Клиент и Оператор являются наследниками класса Пользователь, от них к родительскому классу строится связь обобщения.

Клиент и Оператор также имеют связь с классом Форма аутентификации. Это однонаправленная ассоциация от класса Форма аутентификации ко классам Клиент и Оператор (направление ассоциации отражает направление передачи сообщений между классами). Один экземпляр класса Форма аутентификации может взаимодействовать с одним экземпляром класса Клиент или Оператор – множественность связи ноль или один. Каждый экземпляр класса Клиент или Оператор может взаимодействовать ровно с одним экземпляром класса Форма аутентификации – множественность один.

Между классами Картотека пользователей и Хранилище существует связь агрегации (класс-целое – Картотека пользователей, класс-часть - Хранилище).

Картотека пользователей связана двунаправленной ассоциацией с классом Форма аутентификации, множественность связи один к одному.

Диаграмма представлена на рисунке 72.

Р
ис.72. Пакет «Аутентификация»

Остальные пакеты представлены в приложении В.

4.2.2. Диаграммы Состояний

Рассмотрим класс Заказ. Экземпляр этого класса может находиться в одном из трёх состояний: «Оформлен», «Выполнен», «Отменён». В первое состояние он переходит сразу после создания (оформление заказа), далее поступает на склад, и после окончания комплектации переходит в состояние «Выполнен». В состояние «Отменён» заказ может попасть по желанию клиента, но лишь в том случае, если он ещё не укомплектован.

Диаграмма Состояний для класса Заказ представлена на рисунке 73.



Рис.73. Диаграмма Состояний для класса Заказ

У класса Товар можно выделить два состояния: «Активный» и Пассивный». В первое состояние экземпляр класса Товар попадает сразу после своего создания и при закупке новой партии товара. Во второе – после того, как товар на складе закончится, но будет принято решение о его закупке.


Диаграмма Состояний представлена на рисунке 74.

Рис.74. Диаграмма Состояний класса Товар

4.2.3. Диаграммы Деятельности

Рассмотрим диаграмму Деятельности для операции «Изменить заказ». Первоначально выполняются два действия – выдача бланка заказа и выдача ассортимента. Они могут осуществляться параллельно. Следующее действие – пересчёт стоимости заказа – начнётся только после окончания предыдущих действий и при условии внесения изменений. Затем осуществляется проверка кредитоспособности клиента: если клиент кредитоспособен, последовательно осуществляются действия – сохранение заказа и изменения баланса клиента; если некредитоспособен – отказ в изменении.

П
олученная диаграмма представлена на рисунке 75.

Рис.75. Диаграмма Деятельности «Изменить заказ»

4.3. Представление Компонентов

Диаграммой Компонентов (Component diagram) называется диаграмма UML, на которой показаны ком­поненты системы и зависимости между ними.

На такой диаграмме можно видеть исходный код и исполняемые компоненты системы.

Для нашего примера исполняемый файл stola.exe. Сгруппируем классы по стереотипу: классы-сущности, пограничные и управляющие. Для каждой группы выделим заголовочные файлы и файлы кода операций. Диаграмма Компонентов представлена на рисунке 76.



Рис.76. Диаграмма Компонентов

4.4. Представление Размещения

На рисунке 77 приведена Диаграмма Размещения для проектируемой системы. Здесь показано взаимодействие через локальную сеть узла-экземпляра Сервер и узла Рабочая станция, представленного в виде типа.

Р
ис.77 Диаграмма Размещения

СПИСОК ЛИТЕРАТУРЫ

        1. Крэг Ларман, «Применение UML и шаблонов проектирования». М.: «Вильямс», 2002.

2. Грэйди Буч, Джеймс Рамбо, Айвар Джекобсон, «Язык UML Руководство пользователя». СПб.: ДМК Пресс, 2004.

3. М. Богс, У. Богс, «UML и Rational Rose». М.: «Лори», 2001.

  1. А. Леоненков, «Самоучитель UML». СПб.: «BHV-СПб», 2000.

  2. Л. Мацяшек, «Анализ требований и проектирование систем. Разработка информационных систем с использованием UML». М.: «Вильямс», 2002.

6. Терри Кватрани, «Rational Rose 2000 и UML. Визуальное моделирование». М.: ДМК Пресс, 2001.

  1. А.М. Вендров, «Проектирование программного обеспечения ЭИС.». М.: «Финансы и статистика», 2000.

ПРИЛОЖЕНИЕ А.

«БАЗОВЫЕ СЦЕНАРИИ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ»

1. «Зарегистрировать пользователя»

Внести в базу пользователей логин и пароль нового оператора или клиента. Для клиента открыть счёт.

  1. «Пополнить баланс»

При получении квитанции от клиента увеличить его баланс на указанную сумму.

3. «Изменить ассортимент»

Удалить из списка активной на данный момент продукции товары, которых нет на складе, и завоз которых не планируется в ближайшее время. Пополнить список активной продукции новыми товарами (или неактивными в данный момент), завезёнными на склад.

4. «Изменить состояние заказа»

При получении со склада информации о том, что заказ укомплектован, заказ переводится в состояние запрета редактирования и отмены.

5. «Аутентификация»

Идентификация пользователя при каждом входе в систему.

  1. «Просмотреть ассортимент»

Выдать список активных на данный момент товаров.

  1. «Управление заказом»

Предоставляет возможности оформления нового заказа (редактирования бланка ранее оформленного заказа), изменения и отмены ещё не выполненных заказов.

  1. «Найти заказ»

По введённым критериям поиска (дата регистрации заказа, стоимость заказа) найти ранее оформленный заказ данного клиента.

  1. «Копировать заказ»

Копирование всех полей ранее оформленного заказа в текущий заказ.

  1. «Учёт товаров на складе»

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

ПРИЛОЖЕНИЕ Б. «ДИАГРАММЫ ПОСЛЕДОВАТЕЛЬНОСТИ»

1.«Пополнить баланс»

Эта диаграмма содержит два объекта – Оператор и Картотека пользователей. Оператор является действующим лицом и получает фокус управления сразу после инициирования варианта использования «Пополнить баланс». Он сообщает Картотеке пользователей данные, идентифицирующие клиента, и сумму, на которую увеличивается баланс этого клиента. При этом управление передаётся Картотеке пользователей.

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

Соответствующая диаграмма изображена на рисунке Б-1.

Р
ис. Б-1. Диаграмма Последовательности «Пополнить баланс»

2. «Изменить ассортимент»

На этой диаграмме Последовательности будут изображены два объекта: Оператор и Склад. Первоначально фокус управления есть только у Оператора. Он посылает объекту Склад запрос на выдачу ассортимента. Склад, получив управление, передаёт Оператору сообщение «Ассортимент» и переходит в состояние ожидания.

Оператор вносит изменения в предложенный список товаров, передавая тем самым управление Складу.

Склад путём использования рефлексивного сообщения проверяет корректность внесённых изменений. В случае отсутствия ошибок, также передав рефлексивное сообщение, сохраняет изменения, в противном случае – посылает Оператору сообщение об ошибке.

Диаграмма представлена на рисунке Б-2.

Р
ис. Б-2. Диаграмма Последовательности «Изменить ассортимент»

3. «Изменить состояние заказа»

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

Оператор, изменив состояние заказа, посылает Картотеке заказов сообщение «Сохранить изменения».

Диаграмма представлена на рисунке Б-3.

Р
ис. Б-3. Диаграмма Последовательности «Изменить состояние заказа»

4. «Аутентификация»


Объекты диаграммы: Клиент и Картотека пользователей. Клиент получает фокус управления сразу после появления в системе. Он посылает Картотеке пользователей логин и пароль и передаёт ей управление. Картотека пользователей с помощью рефлексивного сообщения определяет права доступа Клиента и предаёт ему сообщение о регистрации в системе.

Диаграмма представлена на рисунке Б-4.

Рис. Б-4. Диаграмма Последовательности «Аутентификация»

5. «Просмотреть ассортимент»

Объекты: Клиент, Склад. Клиент, изначально обладая фокусом управления, посылает Складу сообщение «Выдать ассортимент». Получив управление, Склад отправляет Клиенту сообщение «Ассортимент».

Диаграмма представлена на рисунке Б-5.

Р
ис. Б-5. Диаграмма Последовательности «Просмотреть ассортимент»

6. «Управление заказом»

Так как в прецеденте «Управление заказом» мы объединили несколько вариантов взаимодействия клиента с системой, диаграмму Последовательности необходимо будет построить для каждого из них.

- Оформить заказ

Объекты: Клиент, Заказ, Картотека заказов, Склад и Картотека пользователей. Клиент получает фокус управления сразу после появления в системе, остальные объекты на начальном этапе имеют только линии жизни.

Процесс взаимодействия начинается с отправления Клиентом сообщения «Создать новый заказ», адресованного Заказу. У Картотеки пользователей запрашивается баланс клиента, а у Склада – список товаров. После их получения Клиентом в Картотеку заказов, при желании копировать заказ, отправляется запрос на копирование ключевых полей заказа. Картотека заказов в форме сообщения посылает их Заказу. В противном случае Клиент заполняет ключевые поля вручную.

Затем он проверяет правильность ввода и свою кредитоспособность. Если проверка дала положительный результат – отправляет Заказу сообщение «Записать данные». Тот в свою очередь отправляет Картотеке заказов сообщение «Сохранить заказ», а Складу – «Проверить количество товара».

Если товара на складе недостаточно, Склад посылает рефлексивное сообщение «Закупить партию товара» и сообщение «Подтверждение наличия товара» Заказу.

Заказ посылает Картотеке пользователей сообщение «Изменить баланс» и получает от неё подтверждение изменений. Затем Заказ посылает Клиенту сообщение о принятии заказа к исполнению.

Полученная диаграмма представлена на рисунке Б-6.

- Изменить заказ

Объекты: Клиент, Заказ, Картотека заказов, Картотека пользователей и Склад. Взаимодействие в системе начинается с отправления Клиентом Заказу запроса бланка заказа. Заказ, получив управление, Возвращает бланк заказа Клиенту.

После этого Клиент посылает сообщение «Выдать ассортимент», адресованное Складу. Тот, в свою очередь, предоставляет требуемую информацию.

Клиент вносит в Заказ изменения. Заказ с помощью рефлексивного сообщения пересчитывает общую стоимость. После этого он посылает запрос о кредитоспособности Картотеке пользователей. Та в ответ передаёт Заказу сведения о балансе клиента.

Если клиент кредитоспособен, Заказ отправляет два сообщения: «Сохранить заказ» - в Картотеку заказов, «Изменить баланс» - в Картотеку пользователей; если нет – одно: «Отказать в изменении», адресованное Клиенту.

Диаграмма представлена на рисунке Б-7.



Рис. Б-6. Диаграмма Последовательности «Оформить заказ»

Р
ис. Б-7. Диаграмма Последовательности «Изменить заказ»

-Отменить заказ

Объекты: Клиент, Картотека заказов, Картотека пользователей.

Клиент посылает Картотеке заказов сообщение «Найти заказ». Картотека заказов с помощью рефлексивного сообщения осуществляет поиск заказа и выдаёт Клиенту список активных заказов.

Выбрав один из них, Клиент посылает Картотеке заказов запрос на его удаление. Картотека заказов, используя рефлексивное сообщение, производит удаление заказа и отправляет в Картотеку пользователей сообщение «Найти клиента».

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

Д
иаграмма представлена на рисунке Б-8.

Рис. Б-8. Диаграмма Последовательности «Отменить заказ»

7. «Найти заказ»

На этой диаграмме будут присутствовать два объекта: Клиент и Картотека заказов. Взаимодействие в системе начинается с отправления Клиентом Картотеке пользователей сообщения «Параметры поиска».

Картотека заказов рефлексивно осуществляет поиск заказа и осуществляет передачу Клиенту списка подходящих заказов.

Д
иаграмма представлена на рисунке Б-9.

Рис. Б-9. Диаграмма Последовательности «Найти заказ»

8. «Копировать заказ»

Объекты: Клиент, Заказ, Картотека заказов. Клиент посылает Картотеке заказов сообщение «Критерии поиска заказа». Картотека заказов осуществляет поиск заказа. В случае неудачи, посылает Клиенту сообщение об отсутствии заказа, в случае успеха – передаёт ему бланк заказа.

Клиент посылает Заказу сообщение «Копировать поля заказа», а затем «Внесение изменений». Далее Заказ осуществляет проверку правильности ввода и наличия товаров в ассортименте. Если результат положительный – Заказ сохраняет изменения и посылает Картотеке заказов сообщение «Сохранить заказ», иначе передаёт пользователю сообщение «Отменить копирование». Пользователь ответным сообщением даёт Заказу согласие.

Д
иаграмма представлена на рисунке Б-10.

Рис. Б-10. Диаграмма Последовательности «Копировать заказ»

9. «Учёт товаров на складе»

Объекты: Заказ, Склад. На начальном этапе активным является Заказ, он отправляет Складу сообщение «Проверить количество товара». Если товара недостаточно, Склад производит его закупку, а затем пересчитывает количество товара и посылает Заказу сообщение о подтверждении его наличия.

Диаграмма представлена на рисунке Б-11.



Рис. Б-11. Диаграмма Последовательности «Учёт товаров на складе»

ПРИЛОЖЕНИЕ В. «ПАКЕТЫ»

Ниже приведены диаграммы классов для всех пакетов, изображённых на главной диаграмме классов.

1. «Работа с пользователями»


Рис. В-1. Пакет «Работа с пользователями»

2. «Работа с заказами»

Р
ис. В-2. Пакет «Работа с заказами»

3. «Работа с товарами»



Рис. В-3. Пакет «Работа с товарами»

1

Смотреть полностью


Скачать документ

Похожие документы:

  1. Рабочая программа дисциплины теоретические основы автоматизированного управления

    Программа
    ... ПРОГРАММА дисциплины ТЕОРЕТИЧЕСКИЕ ОСНОВЫ АВТОМАТИЗИРОВАННОГО УПРАВЛЕНИЯ индекс по учебному плану – СД.01 Рекомендовано Методическим Советом ... ERP 2005 и QPR7. Наименования лабораторных работ с указанием разделов дисциплины, к которым они относятся, ...
  2. Методическое пособие по дисциплине «операционные системы» и указания по выполнению лабораторных работ

    Методическое пособие
    ... технологии» Методическое пособие по дисциплине «Операционные системы» и указания по выполнению лабораторных работ Направление 230100 «Информатика и вычислительная техника» Специальность 230102 «Автоматизированные ...
  3. Методические указания по выполнению лабораторных работ по дисциплине «метрология стандартизация и сертификация»

    Методические указания
    ... технологии» Методические указания по выполнению лабораторных работ по дисциплине «Метрология, стандартизация и сертификация» Специальность 230102 «Автоматизированные системы обработки информации и управления» Составитель ...
  4. Методические указания к выполнению контрольной работы по всс и тк

    Методические указания
    ... , Учебники, Лабораторные работы =>файл Методические указания для выполнения лабораторных работ). 2. Выбрать вариант по последней цифре номера ... пособия Е.В. Молнина. Основы построения и функционирования вычислительных машин» для изучения дисциплины ...
  5. Методические указания по выполнению лабораторных работ по дисциплине «компьютерная графика»

    Методические указания
    ... технологии» Методические указания по выполнению лабораторных работ по дисциплине «Компьютерная графика» Направление 230100 «Информатика и вычислительная техника» Специальность 230102 «Автоматизированные ...

Другие похожие документы..