Проектирование информационных систем с использованием ERWin, BPWin

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

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

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

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

* технико-экономическое обоснование проектных решений, включающее определение, оптимизацию и обоснование технико-экономических показателей и характеристик проектируемой системы на основе заданных целевых критериев ее функционирования;

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

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

— определение состава и этапности проектных работ;

— обеспечение календарного планирования хода выполнения проектных работ в соответствии с их этапностью;

— планирование материальных и людских ресурсов, выделенных на реализацию проекта, увязка ресурсного планирования с календарным;

— контроль хода реализации проекта;

* разработка проектно-конструкторской документации на систему.

В качестве средств методической и программно-технической поддержки процесса проектирования в соответствии с приведенной классификацией проектных работ можно выделить:

* для проектирования вычислительной среды — методы экспертных оценок и математико-компьютерного моделирования, а также соответствующие программно-технические средства (ПТС) на основе экспертных систем и ПТС для создания моделей вычислительной среды, в том числе ПТС имитационного моделирования;

* для проектирования программной и информационной среды — компьютерное моделирование и CASE-технологии, а также соответствующие ПТС для проведения моделирования и программные CASE-продукты;

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

Объектно-ориентированное проектирование состоит в описании структуры и поведения проектируемой системы, то есть, фактически, в ответе на два основных вопроса:

· Из каких частей состоит система.

· В чём состоит ответственность каждой из частей.

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

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

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

1. UML как стандарт для создания модели информационной системы

UML (сокр. от англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания создания моделей. UML создавался для использования в процессе разработки программного обеспечения. Главной его целью было достижение единого видения разработчиков и пользователей на создаваемые программы.

Унифицированный язык моделирования (Unified Modeling Language) появился в конце 80-х в начале 90-х годов в основном благодаря усилиям Гради Буча, Джима Рамбо и Ивара Якобсона. В настоящее время консорциум OMG принял этот язык как стандартный язык моделирования, который предоставляет разработчикам четкую нотацию, позволяющую отображать модели общепринятыми и понятными каждому члену проекта графическими элементами.

Производство программного обеспечения — высокозатратный процесс. Стоимость разработки во многом зависит как от объема необходимой работы и от качества принимаемых решений.

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

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

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

2. Особенности работы в средстве проектирования Rational Rose 2003

В CASE-средстве IBM Rational Rose 2003 реализованы общепринятые стандарты на рабочий интерфейс программы, аналогично известным средам визуального программирования. После установки IBM Rational Rose 2003 на компьютер пользователя, что практически не вызывает трудностей у разработчиков, запуск этого средства в среде MS Windows 2000/XP приводит к появлению на экране соответствующего рабочего интерфейса (рис.1).

Рабочий интерфейс программы IBM Rational Rose 2003 состоит из различных элементов, основными из которых являются:

· главное меню;

· стандартная панель инструментов;

· специальная панель инструментов;

· окно браузера проекта;

· рабочая область изображения диаграммы или окно диаграммы;

· окно документации;

· окно журнала.

Рассмотрим назначение и основные функции каждого из этих элементов.

Главное меню программы IBM Rational Rose 2003 выполнено в общепринятом стандарте.

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

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

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

Назначение операций главного меню File и Edit

Рабочий интерфейс средства IBM Rational Rose 2003 имеет главное меню, которое позволяет пользователю загружать и сохранять информацию во внешних файлах, изменять внешний вид элементов графического интерфейса, вызывать справочную информацию, вызывать другие диалоговые окна для работы с программой IBM Rational Rose 2003 и т. д. Рассмотрим назначение отдельных пунктов главного меню средства IBM Rational Rose 2003.

Операции главного меню File (Файл) позволяют создавать новые модели в нотации языка UML, загружать и сохранять разрабатываемую модель во внешнем файле, распечатывать на принтере разработанные диаграммы. Назначение операций этого пункта главного меню представлено в таблице 1.

Операции главного меню Edit (Редактирование) позволяют выполнять действия по редактированию элементов модели и их свойств, а также выполнять поиск элементов в рамках разрабатываемого проекта. Назначение операций этого пункта главного меню представлено в таблице 2.

Таблица 1 — Операции пункта главного меню File (Файл)

Таблица 2 — Операции пункта главного меню Edit (Редактирование)

Назначение операций главного меню View, Format и Browse

Операции главного меню View (Вид) позволяют отображать на экране различные элементы рабочего интерфейса и изменять графическое представление диаграмм. Назначение операций этого пункта главного меню представлено в следующей таблице (табл. 3).

Таблица 3 — Операции пункта главного меню View (Вид)

Операции главного меню Format (Формат) позволяют выполнять действия по изменению внешнего вида элементов модели на различных диаграммах. Назначение операций этого пункта главного меню представлено в следующей таблице (табл. 4).

Таблица 4 — Операции пункта главного меню Format (Формат)

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

Таблица 5 — Операции пункта главного меню Browse (Обзор)

Окно браузера проекта

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

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

· Use Case View — представление вариантов использования, в котором содержатся диаграммы вариантов использования и их реализации в виде вариантов взаимодействия;

· Logical View — логическое представление, в котором содержатся диаграммы классов, диаграммы состояний и диаграммы деятельности;

· Component View — представление компонентов, в котором содержатся диаграммы компонентов разрабатываемой модели;

· Deployment View — представление развертывания, в котором содержится единственная диаграмма развертывания разрабатываемой модели.

Рис. 1 — Внешний вид браузера проекта с иерархическим представление его структуры

При создании нового проекта указанная иерархическая структура формируется программой автоматически.

Специальная панель инструментов и окно диаграммы

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

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

Внешний вид специальной панели инструментов зависит не только от выбора типа разрабатываемой диаграммы, но от выбора графической нотации для изображения самих элементов этих диаграмм. В IBM Rational Rose 2003 реализованы три таких нотации: UML, OMT и Booch. Хотя последние две нотации практически не используются на практике, разработчики неизменно включают их в очередные версии программы IBM Rational Rose 2003, видимо, отдавая этим дань памяти авторам первых версий языка UML. При использовании отдельной нотации одна и та же диаграмма может быть представлена различным образом, для этого достаточно выбрать желаемое представление через соответствующую операцию главного меню View (Вид). При этом никаких дополнительных действий выполнять не требуется — диаграмма преобразуется в выбранную нотацию автоматически. Однако, рассматривая использование программы IBM Rational Rose 2003 только в контексте языка UML, можно оставить без внимания особенности двух других нотаций, которые отражают эволюционный аспект этого программного инструмента.

Окно диаграммы является основной графической областью программы IBM Rational Rose 2003, в которой визуализируются различные представления модели проекта. По умолчанию окно диаграммы располагается в правой части рабочего интерфейса, однако его расположение и размеры также можно изменить. При разработке нового проекта, если не был использован мастер проектов, окно диаграммы представляет собой чистую область, не содержащую никаких элементов модели (рис. 1). По мере разработки отдельных диаграмм в окне диаграммы будут располагаться соответствующие графические элементы модели

Название диаграммы, которая является активной и располагается в данном окне, которое развернуто на всю область диаграммы, указывается в строке заголовка программы IBM Rational Rose 2003. Если же окно диаграммы не развернуто на всю область диаграммы, то название диаграммы указывается в строке заголовка окна диаграммы. Одновременно в графической области диаграмм могут присутствовать несколько окон диаграмм; при этом активной может быть только одна из них. Переключение между диаграммами можно осуществить выбором нужного представления на стандартной панели инструментов, а также с помощью выделения требуемой диаграммы в браузере проекта или с помощью операций главного меню Window (Окно). При активизации отдельного вида диаграммы изменяется внешний вид специальной панели инструментов, которая настраивается под конкретный вид диаграммы.

Окно документации и окно журнала

Окно документации по умолчанию должно присутствовать на экране после загрузки программы. Если по какой-то причине оно отсутствует, то его можно отобразить через пункт меню ViewDocumentation (ВидДокументация), после чего окно документации появится ниже окна браузера проекта (рис. 2). Окно документации, как следует из его названия, предназначено для документирования элементов разрабатываемой модели. В него можно записывать различную текстовую информацию, и что важно — на русском языке. Эта информация при генерации программного кода преобразуется в комментарии и никак не влияет на логику выполнения программного кода.

Рис. 2 — Внешний вид окна документации с информацией о диаграмме деятельности модели В окне документации активизируется та информация, которая относится к выделенному элементу диаграммы или к диаграмме в целом. При этом выделить элемент можно либо в окне браузера, либо непосредственно в окне диаграммы. При добавлении нового элемента на диаграмму, например, класса, документация к нему является пустой (No documentation). В последующем разработчик самостоятельно вносит необходимую пояснительную информацию, которая запоминается программой и может быть изменена в ходе работы над проектом. Так же, как и для других окон рабочего интерфейса программы IBM Rational Rose 2003, разработчик по своему усмотрению может изменять размеры и положение окна документации.

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

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

3. Анализ задачи

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

Что такое модель

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

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

Модели и UML

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

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

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

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

Предметная область:

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

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

3.2 Выбор средств разработки и реализации

Для разработки лабораторного практикума используются следующие средства и технологии: Rational Rose 2003, Microsoft Word 2007.

Rational Rose 2003 — мощное CASE-средство для проектирования программных систем любой сложности. Одним из достоинств этого программного средства является возможность использования диаграмм на языке UML. Можно сказать, что Rational Rose является графическим редактором UML диаграмм.

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

· Use case diagram (диаграмма вариантов использования (прецедентов));

· Activity diagram (диаграмма видов деятельности);

· Interaction diagram (диаграмма взаимодействия);

· Sequence diagram (диаграмма последовательности);

· Collaboration diagram (диаграмма кооперации);

· Class diagram (диаграмма классов);

· Component diagram (диаграмма компонентов).

· Deployment diagram (диаграмма размещений);

· Statechart diagram (диаграмма состояний).

CASE-средство IBM Rational Rose со времени своего появления претерпело серьезную эволюцию, и в настоящее время представляет собой современный интегрированный инструментарий для проектирования архитектуры, анализа, моделирования и разработки программных систем. Именно в IBM Rational Rose язык UML стал базовой технологией визуализации и разработки программных систем, что определило популярность и стратегическую перспективность этого инструментария.

Microsoft Word 2007 — это текстовый процессор, предназначенный для создания, просмотра и редактирования текстовых документов, с локальным применением простейших форм таблично-матричных алгоритмов. Текстовый процессор, выпускается корпорацией Microsoft в составе пакета Microsoft Office.

3.3 Постановка задачи

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

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

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

— диаграммы видов деятельности

— диаграммы последовательности

— диаграммы кооперации

— диаграммы классов

— диаграммы компонентов

— диаграммы размещений

— диаграммы состояний.

4. Разработка лабораторного практикума

4.1 Лабораторная работа № 1

Цель работы: построить в Rational Rose общую модель будущей ИС по представленной предметной области в виде диаграммы вариантов использования. Один из вариантов использования декомпозировать диаграммой видов деятельности.

Use case diagram (Диаграмма вариантов использования).

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

Каждая такая диаграмма или, как ее обычно называют, каждый Use case — это описание сценария поведения, которому следуют действующие лица (Actors).

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

Для разработки диаграммы вариантов использования модели в среде IBM Rational Rose 2003 необходимо активизировать соответствующую диаграмму в окне диаграммы. Это можно сделать следующими способами:

· раскрыть представление вариантов использования Use Case View в браузере проекта и дважды щелкнуть на пиктограмме Main (Главная);

· с помощью операции главного меню BrowseUse Case Diagram (БраузерДиаграмма вариантов использования).

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

Таблица 6 — Назначение кнопок специальной панели инструментов для диаграммы вариантов использования

4.1.1 Создание диаграммы вариантов использования

1. Для создания диаграммы вариантов использования нужно щелкнуть правой кнопкой мыши на пакете представления Вариантов Использования в браузере (рис. 3).

Рис. 3 — Выбор Пакета представления вариантов использования Рис. 4 — Создание Use Case диаграммы

2. Во всплывающем меню выберите пункт New -> Use Case Diagram (рис. 4).

3. Выделив новую диаграмму, введите её имя.

4. Дважды щелкнув по названию диаграммы, откройте её.

5. С помощью кнопки Use Case панели инструментов поместите на диаграмму новый вариант использования.

6.Выделив новый вариант использования, введите его имя «Ввести новый заказ».

7. Добавить так же следующие варианты использования: «Изменить существующий заказ», «Начать инвентарную опись», «Обновить инвентарную опись», «Оформить заказ», «Отклонить заказ»

8. С помощью кнопки Actor поместите на диаграмму следующие действующие лица: «Продавец», «Бухгалтерская система», «Директор магазина», «Менеджер магазина».

9. С помощью кнопки Unidirectional Association добавить ассоциации.

10. С помощью кнопки Generalization панели инструментов добавьте ассоциацию между вариантом использования «Отклонить заказ» и вариантом использования «Оформить заказ». Связь обобщения означает, что вариант использования «Отклонить заказ» при необходимости дополняет функциональные возможности варианта использования «Оформить заказ».

11. Щелкните правой кнопкой мыши на новой связи между вариантами использования, в открывшемся меню выберите пункт Open Specification. В раскрывшемся списке стереотипов введите слово «extends» (расширение), затем нажмите ОК (рис. 5).

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

4.1.2 Создание диаграммы видов деятельности

Activity diagram (диаграммы активности)

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

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

Диаграмма деятельности в среде IBM Rational Rose 2003, так же как и диаграмма состояний, может относиться к отдельному классу, операции класса, варианту использования, пакету или представлению. Общие рекомендации по построению диаграммы деятельности были рассмотрены в лекции 11 курса «Основы объектно-ориентированного моделирования в нотации UML». Для того чтобы построить диаграмму деятельности, ее вначале необходимо создать и активизировать.

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

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

· Выделить логическое представление (Logical View) или представление вариантов использования (Use Case View) в браузере проекта и выполнить операцию контекстного меню: NewActivity Diagram (НоваяДиаграмма деятельности).

· Раскрыть логическое представление (Logical View) в браузере проекта и выделить рассматриваемый класс, операцию класса, пакет, или раскрыть представление вариантов использования (Use Case View) и выбрать вариант использования, после чего выполнить операцию контекстного меню: NewActivity Diagram (НоваяДиаграмма деятельности).

· Выполнить операцию главного меню: BrowseState Machine Diagram (ОбзорДиаграмма состояний), после следует чего выбрать представление и тип разрабатываемой диаграммы — диаграмма деятельности.

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

Таблица 7 — Назначение кнопок специальной панели инструментов для диаграммы видов деятельности

1. Найдите в браузере вариант использования (use case) Изменить существующий заказ

2. В открывшемся меня выберите пункт Sub Diagram -> New Activity Diagramm

3. Добавьте на диаграмму начальное состояние

4. Добавьте на диаграмму два конечных состояния

5. Добавьте на диаграмму следующие виды деятельностей: «Получение запроса на изменение заказа», «Ввод номера заказа», «Отображение формы заказа», «Детализация данных по позициям заказа», «Детализация данных по покупателю», «Запомнить изменения», «Направить информацию в бухгалтерию и на склад»

6. Добавьте на диаграмму два символа горизонтальной синхронизации

7. Добавьте на диаграмму символ принятия решений

8. Используя переходы приведите диаграмму к виду, показанному на рисунке 6.

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

4.2 Лабораторная работа № 2

4.2.1 Создание диаграммы взаимодействий

Interaction diagram (диаграммы взаимодействия). Этот тип диаграмм включает в себя Sequence diagram (диаграммы последовательности) и Collaboration diagram (диаграммы кооперации).Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

4.2.2 Создание диаграммы последовательностей

Sequence diagram (диаграммы последовательности действий)

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

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

Этот тип диаграммы не акцентирует внимание на конкретном взаимодействии, главный акцент уделяется последовательности приема/передачи сообщений. Для того чтобы окинуть взглядом все взаимосвязи объектов, служит Collaboration diagram.

Особенности разработки диаграммы последовательности в среде IBM Rational Rose

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

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

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

· Выполнить операцию главного меню: BrowseInteraction Diagram (БраузерДиаграмма взаимодействия) и выбрать для построения новую диаграмму последовательности.

· Выполнить операцию контекстного меню: NewSequence Diagram (НоваяДиаграмма последовательности) для логического представления или представления вариантов использования в браузере проекта.

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

Таблица 8 — Назначение кнопок

1. Щелкните правой кнопкой на варианте использования «Ввести новый заказ» в браузере.

2. В открывшемся меню выберите пункт New -> Sequence Diagramm.

3. Назовите новую диаграмму «Добавить заказ».

4. Дважды щелкнув по ней, откройте ее.

5. Перетащите действующее лицо «Продавец» из браузера на диаграмму.

6. Поместите объект в верхнюю часть диаграммы, назовите его «Выбор варианта заказа».

7. Создайте еще четыре объекта, назовите их «Форма деталей заказа», «Менеджер по заказам», «Номер заказа» и «Администратор транзакций», соответственно.

8. Создайте сообщение, нажав кнопку Object Message и проведя мышью линии жизни действующего лица «Продавец» к линии жизни объекта «Выбор вариантов заказа».

9. Выделив сообщение, введите его имя «Создать новый заказ».

10. Так же поместите на диаграмму следующие сообщения:

— «Открыть форму», между «Выбор варианта заказа» и «Форма деталей заказа»

— «Ввести номер заказа, покупателя, предметы заказа», между «Продавец» и «Форма деталей заказа»

— «Сохранить заказ», между «Продавец» и «Форма деталей заказа»

— «Сохранить заказ», между «Форма деталей заказа» и «Менеджер по заказам»

— «Создать новый пустой заказ», между «Менеджер по заказам» и «Номер заказа»

— «Указать номер заказа, покупателя, предметы заказа» между «Менеджер по заказам» и «Номер заказа»

— «Сохранить заказ», между «Менеджер по заказам» и «Администратор транзакций»

— «Получить информацию о заказе», между «Номер заказа» и «Администратор транзакций».

11. Также добавить рефлексивное сообщение на «Администратор транзакций»