ИНФОРМАЦИОННЫЕ...

Ñàíêò-Ïåòåðáóðã2005

Методические указания

к выполнению лабораторных работ № 1–7

ИНФОРМАЦИОННЫЕ СИСТЕМЫ

Использование CASE-средств

при описании бизнес-процессов

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

Ãîñóäàðñòâåííîå îáðàçîâàòåëüíîå ó÷ðåæäåíèåâûñøåãî ïðîôåññèîíàëüíîãî îáðàçîâàíèÿ

ÑÀÍÊÒ-ÏÅÒÅÐÁÓÐÃÑÊÈÉ ÃÎÑÓÄÀÐÑÒÂÅÍÍÛÉ ÓÍÈÂÅÐÑÈÒÅÒ

ÀÝÐÎÊÎÑÌÈ×ÅÑÊÎÃÎ ÏÐÈÁÎÐÎÑÒÐÎÅÍÈß

40

Составители: А. Г. Степанов, Т. Ф. Осипова

Под ред. канд. техн. наук проф. А. Г. Степанова

Рецензент кандидат технических наук доцент Г. В. Преснякова

Методические указания посвящены использованию CASE-средств для описа-

ния бизнес-процессов. Эти средства необходимы для формализованного описания

постановки задачи как основы создания информационной системы. В методичес-

ких указаниях дается краткая характеристика общих принципов разработки инфор-

мационных систем для бизнес-процессов при применении CASE-средств Ration

Rose и BPwin + ERwin (All Fusion Modeling).

Методические указания предназначены для выполнения лабораторных работ

по дисциплинам: "Информационное обеспечение и базы данных", "Информаци-

онные технологии", а также основной дисциплины "Проектирование информаци-

онных систем для специальностей": "Управление качеством", "Менеджмент", "Фи-

нансы , денежное обращение и кредит", "Прикладная информатика в менеджменте",

"Корпоративные информационные системы в экономике и менеджменте". Выпол-

нив лабораторные работы, студент должен узнать, что такое CASE-средства, какие

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

UML, IDF0, IDF3. В результате студент должен уметь построить диаграммы, опи-

сывающие бизнес-процесс в этих нотациях. Методические указания подготовле-

ны к изданию кафедрой прикладных информационных технологий в экономике и

менеджменте и рекомендованы к изданию редакционно-издательским советом

Санкт-Петербургского государственного университета аэрокосмического прибо-

ростроения.

Подписано к печати 06.10.05. Формат 60×84 1/16. Бумага офсетная. Печать офсетная.

Усл. печ. л. 2,38. Уч. -изд. л. 2,53. Тираж 300 экз. Заказ № 447

Редакционно-издательский отдел

Отдел электронных публикаций и библиографии библиотеки

Отдел оперативной полиграфии

ГУАП

190000, Санкт-Петербург, ул. Б. Морская, 67

Редактор В. П. Зуева

Компьютерный набор и верстка Н. С. Степановой

© ГОУ ВПО «Санкт-Петербургский

государственный университет

аэрокосмического приборостроения», 2005

1

ВВЕДЕНИЕ

Моделирование предметной области является одним из наиболее важ-

ных этапов работ при проектировании программных систем масштаба

предприятия. В настоящее время для целей моделирования предмет-

ной области на рынке программных продуктов представлен широкий

спектр CASE-средств. Наиболее популярными в нашей стране CASE-

средствами являются Rational Rose, BPwin, Silverrun, Process Analyst.

Моделирование предметной области в этих средствах имеет скорее

много общего, чем различий. Основными задачами при моделировании

предметной области являются следующие описания:

– бизнес-процессов предприятия;

– действующих лиц бизнес-процессов и их функций, подлежащих авто-

матизации в привязке к структуре автоматизируемого предприятия;

– бизнес-сущностей;

– сценариев выполнения бизнес-функций, подлежащих автоматизации;

– состояний бизнес-сущностей;

– бизнес-правил.

Описания бизнес-процессов используются для описания технологии

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

основе описанной технологии определяются виды деятельности, кото-

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

ной системе).

При описании бизнес-процессов должны быть выявлены связи меж-

ду различными подразделениями предприятия при решении конкретных

производственных задач (горизонтальные связи).

При описании предметной области не следует забывать о моделиро-

вании бизнес-правил.

Модели бизнес-правил предметной области будут являться основой

для моделирования правил программной системы.

Итак, подводя итог сказанному об описании предметной области при

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

1. Описание предметной области должно включать не только описа-

ние бизнес-процессов, но и описание структуры автоматизируемого пред-

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

ментов, связанных с автоматизированными функциями, прочих бизнес-

сущностей, сценариев реализации бизнес-функций и состояний бизнес-

сущностей.

2

2. Модель бизнес-процессов используется для определения бизнес-тре-

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

разделениями, принимающими участие в решение конкретной задачи.

3. Модель структуры предприятия используется для отражения дей-

ствующих лиц предприятия, их автоматизируемых функций в привязке к

подразделениям, в которых эти функции выполняются. На основе модели

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

4. Модели документов, бизнес-сущностей используются при проек-

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

альбома выходных форм системы.

5. Модели сценариев реализации бизнес-функций используются при

проектировании сценариев пользовательского интерфейса.

6. Модели состояний бизнес-сущностей используются при проекти-

ровании пользовательского интерфейса и базы данных системы.

7. Модели бизнес-правил используются при моделировании правил

программной системы.

Полное и детальное описание предметной области удобно произво-

дить с помощью разнообразных CASE-средств.

Case-средства

Термин CASE – Computer Aided System/Software Engineering

используется при автоматизации процесса разработки сложных инфор-

мационных систем в целом. Появлению CASE-средств предшество-

вали исследования в области методологии проектирования. Методо-

логия определяет этапы и шаги реализации проекта, а также правила

использования методов, которыми разрабатывается проект. Метод –

это процедура или техника генерации описаний компонентов информа-

ционной системы (проектирование потоков и структур данных). Но-

тация – отображение структуры системы, элементов данных с помо-

щью специальных графических символов. CASE-средства – это спе-

циальные программы, которые поддерживают одну или несколько ме-

тодологий анализа и проектирования информационных систем. CASE-

технология, в рамках методологии, включает в себя методы, с помо-

щью которых на основе нотаций строятся диаграммы, поддерживае-

мые конкретным CASE-средством. CASE-технологии не могут счи-

таться самостоятельными, они только обеспечивают высокую эффек-

тивность их применения.

3

Краткая характеристика

Современные CASE-средства охватывают обширную область под-

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

систем: от простых средств анализа и документирования до полномас-

штабных средств автоматизации, покрывающих весь жизненный цикл

программного обеспечения. Наиболее трудоемкими этапами разработ-

ки информационных систем являются этапы анализа и проектирования,

в процессе которых CASE-средства обеспечивают качество принимае-

мых технических решений и подготовку проектной документации. При

этом большую роль играют методы визуального представления инфор-

мации. Это предполагает построение структурных или иных диаграмм

в реальном масштабе времени, использование многообразной цветовой

палитры, сквозную проверку синтаксических правил. Графические сред-

ства моделирования предметной области позволяют разработчикам в

наглядном виде изучать существующую информационную систему, пе-

рестраивать ее в соответствии с поставленными целями и имеющими-

ся ограничениями.

Архитектура CASE-средств

Обычно к CASE-средствам относят любое программное средство,

автоматизирующее ту или иную совокупность процессов жизненного

цикла программного обеспечения и включающее в себя:

1. Репозиторий, являющийся основой CASE-средства. Он представ-

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

ную для отображения состояния проектируемой информационной сис-

темы в каждый момент времени. Объекты всех диаграмм синхронизи-

рованы на основе общей информации словаря данных. В репозитории

хранятся описания следующих объектов: проектировщиков и их прав

доступа к различным компонентам системы; организационных струк-

тур; диаграмм; компонентов диаграмм; связей между диаграммами;

структур данных; программных модулей; процедур.

2. Графический редактор, обеспечивающий создание и редактиро-

вание в заданной нотации и в интерактивном (диалоговом) режиме эле-

ментов диаграмм, связей между ними, диаграмм. В любой момент вре-

мени они могут быть распечатаны и включены в техническую доку-

ментацию проекта.

4

3. Верификатор диаграмм (средство тестирования), служащее для

контроля правильности построения диаграмм в заданной методологии

проектирования. Его функции:

а) диагностика,

b) выдача сообщений об ошибках,

с) выделение на диаграмме ошибочных элементов.

4. Документатор проекта, позволяющий получать информацию о про-

ектах в виде отчетов. Отчеты могут строиться:

а) по времени,

b) автору,

с) элементам диаграмм,

d) диаграмме,

е) проекту в целом.

5. Администратор проекта, выполняющий следующие функции:

а) инициализация (запуск),

b) задание начальных параметров проекта,

с) назначение и изменение прав доступа к элементам проекта.

6. Сервис, представляющий собой набор системных утилит по об-

служиванию репозитория (архивация и восстановление данных, созда-

ние нового репозитория).

На рисунке показана архитектура CASE-средства в общем виде.

Используемые методологии

При применении CASE-средств используются методологии струк-

турного и объектно-ориентированного проектирования. Структурное

Репозиторий

(словарь данных)

Графический

редактор

диаграмм

Верификатор

диаграмм

Документатор

проекта Сервис

Администратор

проекта

Архитектура CASE-средства

5

проектирование основано на алгоритмической декомпозиции, а объектно-

ориентированное проектирование основано на объектно-ориентированной

декомпозиции. Разделение по алгоритмам концентрирует внимание на

порядке происходящих событий, а разделение по объектам придает осо-

бое внимание объектам или субъектам действия. CASE-средства, под-

держивающие объектно-ориентированное проектирование используют

методологию RUP (Rational Unified Process) и нотации языка UML.

Представления информационной системы на языке UML:

1. Представление использования – основная часть модели описания

системы.

2. Логическое представление – описание функциональных возмож-

ностей системы.

3. Компонентное представление – описание структуры и взаимосвя-

зей модулей системы.

4. Представление взаимодействия процессов – описание согласован-

ных действий модулей системы.

5. Представление распределения – описание физической архитекту-

ры системы.

Каждое представление состоит из диаграмм, которые строятся из

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

SADT (Structured Analysis and Design Technique). Главным разработ-

чиком методологии был Дуглас Росс. Он разработал язык структурно-

го анализа, используемого для описания исследуемого объекта. Этот

язык лег в основу стандартов семейства IDEF. Их использовали в США

по предложению ВВС. В настоящее время семейство IDEF включают:

IDEF0 – стандарт функционального моделирования

IDEF1Х – стандарт моделирования потоков данных

IDEF2 – стандарт динамического моделирования систем

IDEF3 – стандарт документирования процессов

IDEF4 – стандарт построения объектно-ориентированных систем

IDEF5 – стандарт онтологического (принципиального, структурного)

исследования систем.

Правила оформления лабораторных работ

Порядок выполнения работ

1. Выполнить тестовый пример.

6

2. Получить индивидуальное задание.

3. Сдать отчет по заданию.

4. Ответить на вопросы.

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

После выполнения лабораторной работы должен быть составлен

отчет.

Содержание отчета:

1. Титульный лист.

2. Название и цель выполнения работы.

3. Описание своей задачи с перечислением того, что выполнено.

4. Письменные ответы на заданные вопросы.

Темы лабораторных работ

1. Абитуриент одного из потоков стал студентом одной из групп од-

ного из факультетов вуза.

2. Студент одной из групп изучает дисциплины и сдает экзамены и

зачеты.

3. Студент одной из групп записывается на дисциплину к преподава-

телю одной из кафедр.

4. Преподаватель одной из кафедр одного из факультетов вуза про-

водит занятия по определенным дисциплинам.

5. Студент одной из групп одного из факультетов вуза изучает дис-

циплины определенной специальности на определенном курсе.

6. Студент регистрируется в одной из групп определенной специаль-

ности одного из факультетов одного из вузов города.

7. Абитуриент одного из потоков сдает экзамены по определенным

предметам и получает отметки.

8. На один из складов фирмы поступают товары от различных по-

ставщиков.

9. На один из складов одной из фирм города поступает товар от раз-

личных поставщиков.

10. Со складов фирмы выдаются товары от различных поставщиков

различным потребителям из различных городов.

11. Со складов различных фирм города выдаются товары различным

потребителям из различных городов.

12. Со склада фирмы выдаются товары различных поставщиков и раз-

личных производителей различным потребителям различных городов.

7

13. На склад поступают товары различных производителей различ-

ных стран от поставщиков различных городов

14. На склады различных фирм города поступает товар различных

производителей от различных поставщиков

15. Клиенты делают покупки различных товаров в магазинах торго-

вой фирмы наличными, по карточкам и в кредит.

16. Покупатели магазина делают покупки различных товаров различ-

ных производителей и различных поставщиков.

17. Клиенты покупают товар различных производителей в магазинах

торговой фирмы наличными, по карточкам и в кредит.

18. В магазине торгуют товарами различного вида, различных произ-

водителей и от различных поставщиков.

19. В магазинах торговой фирмы торгуют товарами различного вида,

различных производителей и от различных поставщиков.

20. В магазинах торговой фирмы торгуют товарами различного вида

наличными, по карточкам и в кредит.

21. В магазине торгуют товарами различного вида, различных произ-

водителей и от различных поставщиков наличными, по карточкам и в

кредит.

22. В отделе кадров ведется учет подразделений, должностей и со-

трудников; в личном деле сотрудника регистрируются приказы и изме-

нения в положении сотрудника.

23. Проекты состоят из разного набора документов; документы учи-

тываются и отправляются заказчику.

24. Транзисторы классифицируются по типу, мощности и конструкти-

ву; ведется учет поступлений и продаж.

25. Радиоэлементы классифицируются по типу, наименованию; ведется

учет использования их в проектах.

26. Контролеры определяют качество изделий и ведут журнал учета

годных, списанных и дорабатываемых изделий.

27. Контролеры регистрируют результаты тестирования партии изде-

лий в маршрутных листах.

28. Эксперты назначают эталонные значения параметров изделия оп-

ределенного типа; операторы измеряют параметры каждого изделия.

29. Изделия характеризуются эталонными параметрами, ведется жур-

нал учета отклонений реальных параметров от эталонных.

30. Конденсаторы классифицируются по типу, мощности и конструк-

тиву; ведется учет поступлений и продаж.

8

Лабораторная работа № 1. ОЗНАКОМЛЕНИЕ С CASE-СРЕДСТВОМ

RATIONAL ROSE

Цель работы. Изучить интерфейс Rational Rose и принципы работы

с ним.

Основные понятия

Rational Rose – это CASE-средство фирмы Rational Software

Corporation (США), предназначенное для автоматизации этапов анали-

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

на различных языках и выпуска проектной документации . Rational Rose

использует методологию объектно-ориентированного анализа и проек-

тирования, основанную на подходах трех ведущих специалистов в дан-

ной области: Буча, Рамбо и Джекобсона. Разработанная ими универ-

сальная нотация для моделирования объектов (UML – Unified Modeling

Language) претендует на роль стандарта в области объектно-ориенти-

рованного анализа и проектирования. Конкретный вариант Rational Rose

определяется языком, на котором генерируются коды программ (C++,

Smalltalk, PowerBuilder, Ada, SQLWindows и ObjectPro). Основной вари-

ант – Rational Rose/C++ – позволяет разрабатывать проектную доку-

ментацию в виде диаграмм и спецификаций, а также генерировать про-

граммные коды на С++. Кроме того, Rational Rose содержит средства

реинжиниринга программ, обеспечивающие повторное использование про-

граммных компонент в новых проектах.

Структура и функции

В основе работы Rational Rose лежит построение различного рода

диаграмм и спецификаций, определяющих логическую и физическую

структуры модели, ее статические и динамические аспекты. В их чис-

ло входят диаграммы классов, состояний, сценариев, модулей, про-

цессов.В составе Rational Rose можно выделить 6 основных струк-

турных компонент:

– репозиторий,

– графический интерфейс пользователя,

– средства просмотра проекта (browser),

– средства контроля проекта,

– средства сбора статистики

– генератор документов.

9

К ним добавляются генератор кодов (индивидуальный для каждо-

го языка) и анализатор для С++, обеспечивающий реинжиниринг – вос-

становление модели проекта по исходным текстам программ. Репози-

торий представляет собой объектно-ориентированную базу данных.

Средства просмотра обеспечивают "навигацию" по проекту, в том чис-

ле: перемещение по иерархиям классов и подсистем, переключение от

одного вида диаграмм к другому и т. д. Средства контроля и сбора

статистики дают возможность находить и устранять ошибки по мере

развития проекта, а не после завершения его описания. Генератор от-

четов формирует тексты выходных документов на основе содержа-

щейся в репозитории информации. Средства автоматической генера-

ции кодов программ на языке С++, используя информацию, содержа-

щуюся в логической и физической моделях проекта, формируют фай-

лы заголовков и файлы описаний классов и объектов. Создаваемый

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

го программирования на языке С++. Анализатор кодов С++ реализо-

ван в виде отдельного программного модуля. Его назначение состоит

в том, чтобы создавать модули проектов в форме Rational Rose на

основе информации, содержащейся в определяемых пользователем

исходных текстах на С++. В процессе работы анализатор осуществ-

ляет контроль правильности исходных текстов и диагностику ошибок.

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

ментарно использоваться в различных проектах. Анализатор облада-

ет широкими возможностями настройки по входу и выходу. Например,

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

дать, какая информация должна быть включена в формируемую мо-

дель и какие элементы выходной модели следует выводить на экран.

Таким образом, Rational Rose/С++ обеспечивает возможность повтор-

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

В результате разработки проекта с помощью CASE-средства Rational

Rose формируются следующие документы:

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

– диаграммы состояний;

– диаграммы сценариев;

– диаграммы модулей;

– диаграммы процессов;

– спецификации классов, объектов, атрибутов и операций;

10

– заготовки текстов программ;

– модель разрабатываемой программной системы.

Последний из перечисленных документов является текстовым

файлом, содержащим всю необходимую информацию о проекте

(в том числе необходимую для получения всех диаграмм и специ-

фикаций).

Взаимодействие с другими средствами и организация групповой

работы

Rational Rose интегрируется со средством PVCS для организации

групповой работы и управления проектом и со средством SoDA –

для документирования проектов. Интеграция Rational Rose и SoDA

обеспечивается средствами SoDA. Для организации групповой ра-

боты в Rational Rose возможно разбиение модели на управляемые

подмодели. Каждая из них независимо сохраняется на диске или заг-

ружается в модель. В качестве подмодели может выступать кате-

гория классов или подсистема. Для управляемой подмодели предус-

мотрены операции:

– загрузка подмодели в память;

– выгрузка подмодели из памяти;

– сохранение подмодели на диске в виде отдельного файла;

– установка защиты от модификации;

– замена подмодели в памяти на новую.

Наиболее эффективно групповая работа организуется при интегра-

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

рацией и контроля версий (PVCS). В этом случае защита от модифи-

кации устанавливается на все управляемые подмодели, кроме тех, ко-

торые выделены конкретному разработчику. В этом случае признак

защиты от записи устанавливается для файлов, которые содержат под-

модели, поэтому при считывании "чужих" подмоделей защита их от

модификации сохраняется и случайные воздействия окажутся невоз-

можными.

Среда функционирования

Rational Rose функционирует на различных платформах: IBM PC (в

среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-

Packard (HP UX), IBM RS/6000 (AIX). Для работы системы необходи-

мо выполнение следующих требований:

11

Платформа Windows – процессор 80386SX или выше (рекомендуется

80486), память 8 Mб (рекомендуется 12 Mб), пространство на диске 8Mб

+ + 1–3 Mб для одной модели.

Платформа UNIX – память 32 + (16* число пользователей) Mб,

пространство на диске 30 Mб + 20 при инсталляции + 1–3 Mб для

одной модели. Совместимость по версиям обеспечивается на уров-

не моделей.

Технология выполнения работы

Запуск программы

1. Вызвать кнопкой Пуск Главное меню.

2. Найти в программах Rational Rose Enterprise Edition и выбрать

Rational Rose Enterprise Edition

3. Запустить программу.

4. Программа загрузится и появится окно с набором стандартных

проектов. Нажать на Cancel.

Найти

Выбрать

12

Ознакомление с интерфейсом

CASE – средство Rational Rose имеет простой и понятный пользова-

тельский интерфейс для построения требуемых логических и физичес-

ких моделей данных. Он зависит от используемой технологии. В любом

случае при запуске средства моделирования появляются:

– меню;

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

– панель специальных инструментов;

– навигатор моделей.

13

Окно пакета при запуске

Основная панель инструментов содержит следующие главные кнопки:

– создание новой модели;

– открытие имеющейся модели;

– сохранение построенной модели;

– копирование модели;

– печать модели;

– масштабирование.

Навигатор модели показывает состав модели по уровням разра-

ботки. С его помощью можно легко и быстро переходить от одной

модели к другой. Работа с навигатором модели аналогична работе с

Проводником системы Windows. Навигатор поддерживает четыре

представления:

14

– использования;

– логическое;

– компонентов;

– размещения.

Панель специальных инструментов содержит основные кнопки для

создания выбранной диаграммы, например для построения диаграммы

прецедентов представления использования:

– создание субъекта;

– создание аспекта;

– создание ассоциации субъектов и аспектов;

– создание обобщения;

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

– создание класса;

– создание ассоциации классов.

Окно модели является местом создания логической или физической

модели данных исследуемой системы.

Задания

1. Запустить Rational Rose.

2. Посмотреть навигацию по проекту.

3. Создать любой элемент, дать ему название и комментарий к нему.

4. Сохранить проект.

Вопросы для самостоятельной работы

1. Что такое Rational Rose?

2. Описать окно.

3. Что такое навигатор?

4. Окно диаграмм.

5. Панель инструментов.

6. Назначение специальной панели инструментов.

15

Лабораторная работа № 2. СОЗДАНИЕ МОДЕЛИ ВАРИАНТОВ

ИСПОЛЬЗОВАНИЯ

Цель работы: ознакомиться с созданием функциональной модели

использования; изучить нотации, применяемые при построении диаг-

рамм, и освоить их применение в процессе постановки задачи.


Моделирование в Ration Rose проводится как спуск от концептуаль-

ной модели к логической, а затем к физической модели программной

системы. Концептуальная модель выражается в виде диаграмм вари-

антов использования (Use – case diagram). Этот тип диаграмм служит

для проведения итерационного цикла общей постановки задачи вместе

с заказчиком.

Вариант использования представляет собой последовательность дей-

ствий, выполняемых системой в ответ на событие, инициируемое неко-

торым внешним объектом (действующим лицом). Вариант использова-

ния описывает типичное взаимодействие между пользователем и сис-

темой. В простейшем случае вариант использования определяется в

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

реализовать. Эти диаграммы служат основой для достижения взаимо-

понимания между программистами-профессионалами, разрабатываю-

щими проект, и заказчиками проекта.

Внутри каждого варианта использования (прецедента) могут быть

определены:

– вложенная диаграмма использования,

– диаграмма взаимодействия объектов,

– диаграмма последовательности взаимодействия,

– диаграмма классов,

– диаграмма перехода состояния.

Действующее лицо (Actor) – это роль, которую пользователь играет

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

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

может быть внешней системой, которой необходима информация от дан-

ной системы. На рис. 2 приводится вариант использования, описываю-

щий одну из функций системы управления проектами – обратную связь

между менеджером проекта и исполнителем.

16

Нотации представления использования (диаграмма прецедентов)

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

свои нотации (обозначения). Для представления использования приме-

няются следующие нотации:

– субъект как внешняя сущность, взаимодействующая с сис-

темой; им может быть и человек, и устройство, и другая

система;

– аспект использования как определенное средство, предос-

тавляемое системой;

– односторонняя ассоциация, как взаимодействие, направ-

ленное от одного субъекта или аспекта к другим;

– обобщение от одного субъекта или аспекта к другому;

Примеры обобщения показаны на рис. 1. Это сильный инструмент

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

фирмы обобщаются в клиента фирмы.

Пример. Менеджер модифицирует план, назначает ресурс и получает

отчеты от исполнителей, сотрудников и субподрядчиков проекта. Инфор-

мационную систему назовем "Управление проектами". На рис. 2 показа-

ны функции менеджера относительно выполнения проекта.

Специальные субъекты

Обобщенный субъект

Имя

Имя Имя

Специальные аспекты

Обобщенный аспект

Рис. 1. Обобщения аспектов и субъектов

Имя

17

Диаграмма прецедентов


Технологический процесс создания диаграммы прецедентов

1. Подготовка:

a. В навигаторе модели открыть Use Case View.

b. Там же открыть Main.

c. Дать имя диаграмме прецедентов.

i. В контекстном меню для Main выбрать команду Rename.

ii. Ввести имя диаграммы прецедентов.

2. Создание субъекта:

a. Нажать кнопку создания субъекта.

b. В окне диаграммы прецедентов указать место субъекта.

c. Щелчком вызвать изображение субъекта.

d. Ввести имя субъекта.

3. Создание аспекта:

a. Нажать кнопку создания аспекта.

b. Повторить п.п. 2b, c, d для аспекта.

Рис. 2. Диаграмма использования. Управление проектами

Сотрудник Субподрядчик

Модифицировать план

Назначить ресурсМенеджер проекта

Исполнитель

Получить отчет

Внешняя

сущность по отно-

шению к проекту

Одна из функций

системы

18

4. Создание ассоциации

a. Нажать кнопку создания ассоциации.

b. Нарисовать стрелку от одного элемента диаграммы прецеден-

тов к другому.

c. Отрегулировать размещение элементов диаграммы преце-

дентов.

Задания для построения представления варианта использования

Построить диаграмму прецедентов по разработанному техническо-

му заданию.

1. Присвоить имя диаграмме согласно предметной области и реша-

емой задаче.

2. Определить субъектов (актеров) и прецедентов и присвоить им

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

3. Определить ассоциации между ними.

4. Построить обобщения между субъектами и прецедентами.


1. В чем смысл варианта использования?

2. Назначение вариантов использования.

3. Назовите основные компоненты диаграмм вариантов исполь-

зования.

4. Что такое действующее лицо?

5. Какую роль могут играть действующие лица по отношению к ва-

рианту использования?

6. Назначение обобщения.

7. Аспект в диаграмме прецедентов.

19

Лабораторная работа № 3. ДИАГРАММЫ КЛАССОВ

Цель работы: ознакомиться с созданием логической модели инфор-

мационной системы; изучить нотации, применяемые при построении

диаграмм классов и освоить их применение в процессе объектно-ори-

ентированного анализа и проектирования.


Диаграммы классов являются центральным звеном методологии

объектно-ориентированного анализа и проектирования. Диаграмма клас-

са показывает классы и их отношения, тем самым представляя логи-

ческий аспект проекта. На стадии анализа диаграммы классов исполь-

зуются, чтобы выделить общие роли и обязанности объектов (сущнос-

тей), обеспечивающих требуемое поведение системы, на стадии проек-

тирования – чтобы передать структуру классов, формирующих архи-

тектуру системы. Каждый класс должен иметь имя. Имя каждого клас-

са должно быть уникально в содержащем его проекте. Диаграмма клас-

сов определяет этапы объектов системы и различные статистические

связи, которые существует между ними. Имеется два основных вида

статистических связей:

– ассоциации (например, менеджер может вести несколько проектов);

– подтипы (работник является разновидностью личности).

На диаграммах классов также изображаются атрибуты классов,

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

объектами.

Ассоциации представляют собой связи между экземплярами клас-

сов (личность работает в компании, компания имеет ряд офисов). Лю-

бая ассоциация обладает двумя ролями. Например (рис. 3) – ассоциа-

ция между Исполнителем и Отчетом содержит две роли: одна от Ис-

полнителя к Отчету; другая – от Отчета к Исполнителю. Роль также

обладает множественностью. Пример – символ "0..*" над ассоциацией

между Менеджером и Контрактом показывает, что с одним Менедже-

ром связано много Контрактов. 0 – показывает, что Менеджер может

не управлять контрактом; 1 – показывает, что любой Контракт может

управляться только одним Менеджером.

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

направление не указывается, то ассоциация двунаправленная или ее на-

правление неизвестно.

20

Атрибуты во многом подобны ассоциациям. Разница между ними зак-

лючается в том, что атрибуты предполагают единственное направление

навигации – от типа к атрибуту. На рисунке указаны атрибуты для клас-

сов Контракт и Отчет. В зависимости от степени детализации диаграм-

мы обозначение атрибута может включать имя атрибута, тип и значение,

присваемое по умолчанию. В синтаксисе UML атрибут обозначен: <при-

знак видимости> <имя>: <тип> = <значение по умолчанию>. Признак

видимости может принимать следующие значения:

– общий (public) – атрибут общий, доступен для всех классов клиентов;

– защищенный (protected) – атрибут защищенный, доступен только

для подклассов и друзей класса;

– секретный (private) – атрибут собственный, доступен только для

друзей класса;

– реализация (implementation) – атрибут внедренный, доступен внутри

обрамляющего пакета.

Операции представляют процессы, реализуемые классом. Существу-

ет соответствие между операциями и методами над классом. На рис. 3

приведены операции над классом Контракт Закрыть (), над классом

Отчет – Добавить().

Нотации логического представления (диаграммы классов)

– класс А с известным ключом, набором атрибу-

тов и операциями над объектами,

– ассоциация между классами с обозначением воз-

можных видов связи:

i. m ∈ {1, n, 0..1, 0..*, 1..*},

ii. k ∈ {1, n, 0..1, *, 0..*, 1..*}.

Примечание: Первый атрибут в структуре реляционной таблицы име-

ет характеристику Ключ, что означает однозначное определение объекта

в классе.

А

Ключ

Атрибуты

Операции

k m

21

Пример. Диаграмма классов "Управление проектами". Статическая

модель. Все данные о проекте можно свести в реляционную модель.

Объекты сведены в классы, классы описываются атрибутами. Каж-

дый класс имеет свое поведение по отношению к выполнению проекта.

После создания диаграммы классов в диаграмме прецедентов к

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

раметры класса.

Сотру дник

К од с отруд ника

Ф амилия

Д обавить()

(f rom Use Case Vi ew)

Субподряд ч ик

Код с убпод ряд чика

Ф ирма

Ад рес

Контактное лицо

Добав ить()


К онтракт

Номер контракта

Д ата заклю ч ения

Заказчик

Д ата окончания

Стоимость

Закрыть ()

М енедж ер проекта

Код м енед жера

Ф амилия

Телефон

Назначить()


0..*1 0..*1

О тчет

Ном ер отч ета

Дата


К од ис понителя

Имя

Ф ормиров ать()

(fro m Use Case V i ew)

0..*

1

0..*

1

0..* 0..10..* 0..1

Рис. 2. Диаграмма классов. Управление проектами

лнителя

22


Технологический процесс создания диаграммы классов


a. В навигаторе модели открыть Logical View.

b. Там же открыть Main.

c. Дать имя диаграмме классов.

i. В контекстном меню для Main выбрать команду Rename.

ii. Ввести имя диаграммы классов.

2. Создание класса:

a. Нажать кнопку создания класса.

Внеш няя

су щ нос ть по

отнош ению

к проекту

Одна из

фу нкций

с истемы

Сотрудник

Код сотрудника

Ф амилия

Добавить ()

Субподрядчик

Код с убподрядчика

Ф ирма

Адрес

Контактное лицо

Добавить()

модифицировать план

Назначить ресу рсМенеджер проекта

Код менеджера

Ф амилия

Телефон

Назначить()

Полу чить отчет


Код испонителя

Имя

Ф ормировать()

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

М

лнител я

23

b. В окне диаграммы классов указать место класса.

c. Щелчком вызвать изображение класса.

d. Ввести имя класса:

i. не повторяющееся с именами субъектов диаграммы прецедентов

ii. Являющиеся субъектами, их необходимо привести в стандар-

тный для класса вид командой Format/Stereotype Display.

3. Оформить класс:

a. В контекстном меню класса выбрать команду New Attribute.

b. Ввести имя атрибута.

c. Активизировав класс, щелкнуть по значку атрибута.

d. В списке выбрать требуемый значок атрибута:

public (default)

protected

private

implemented

e. В контекстном меню класса выбрать команду New Operation.

f. Ввести имя операции.

g. Повторить п.п. 2e, iii, iv для операции.

4. Создание ассоциации:

a. Нажать кнопку создания ассоциации.

b. Нарисовать стрелку от одного класса к другому.

c. Отрегулировать размещение классов в диаграмме.

5. Оформить ассоциацию:

a. В контекстном меню ассоциации выбрать команду Multiplicity.

b. В списке выбрать требуемый вид ассоциации

1 – обязательная однозначная;

0 .. * – Zero or More, необязательная многозначная;

1 .. * – One or More, обязательная многозначная;

0 .. 1 – Zero or One, необязательная однозначная;

c. В контекстном меню ассоциации выбрать команду Navigable,

убрав "галочку".

Задания

Построить диаграмму классов для представления использования ва-

рианта лабораторной работы 2.

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

дентов.

24

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

объекты Менеджеры можно поместить в класс Менеджер.

b. Назначить атрибут – ключ (идентификатор объекта), например

для объекта Менеджер – это может быть Код менеджера.

c. Указать основную операцию над классом, например для класса

Менеджер – Добавить().

6. Построить отношения между классами на основе ассоциаций

a. Определить направление и множественность, указав нижние и

верхние границы.


1. Назначение диаграммы классов.

2. Для чего используется диаграмма классов на стадии анализа?

3. Назовите основные компоненты диаграммы классов.

4. Что собой представляет ассоциация?

5. В чем смысл множественной ассоциации?

6. Как описывается класс?

7. Значение характеристики атрибута ключ.

8. Что входит в описание атрибута?

9. Что такое признак видимости?

10. Что представляет собой операция класса?

25

Лабораторная работа № 4. ДИАГРАММЫ ВЗАИМОДЕЙСТВИЯ

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

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

мые при построении диаграмм взаимодействия и освоить их применение в

процессе объектно-ориентированного анализа и проектирования.


Диаграммы взаимодействия являются моделями, описывающими по-

ведение взаимодействующих групп объектов. Как правило, диаграмма

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

зования. На такой диаграмме отображается ряд объектов и те сооб-

щения, которыми они обмениваются между собой в рамках одного вари-

анта использования.

Пример. Управление проектами (рис. 5)

– Менеджер обдумывает поручение отчета исполнителю;

– дает указания на создание Отчета Исполнителю;

– если Отчет неудовлетворительный, Менеджер посылает

– запрос Исполнителю на обновление Отчета;

– Исполнитель создает новый Отчет;

– Менеджер делает повторный запрос Отчета.

Существует два вида диаграмм взаимодействия: диаграммы после-

довательности (sequence diagrams) и кооперативные, или сотрудниче-

ства (collaboration diagrams).

Диаграммы последовательности определяют временную последо-

вательность передаваемых сообщений, порядок, вид и тип сообщения,

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

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

те же процессы, поэтому Rational Rose позволяет создать из диаграм-

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

изводит автоматическую синхронизацию этих диаграмм.

На диаграмме последовательности взаимодействие изображается в

виде двумерной схемы: вертикальное (время) и горизонтальное (объек-

ты, участвующие во взаимодействии). Существенна только последова-

тельность сообщений, однако временная ось может служить реальной

метрикой измерения активности объекта.

– Действующие лица из варианта использования.

– Объекты, требуемые системе для выполнения варианта исполь-

зования.

26

– Линии жизни, представляющие фрагмент жизненного цикла объек-

та в процессе взаимодействия, где течение времени идет сверху вниз,

идут сверху.

– Активный период линии жизни.

– Сообщение, передающееся от одного объекта к другому в поряд-

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

именем и аргументом, управляющим событием, например, сообщение

посылается, если Отчет не устарел.

– Самоделегирование (рекурсивное сообщение) – сообщение самому

себе.

На кооперативной диаграмме экземпляры объектов показаны в виде

пиктограмм. Линии между ними обозначают сообщения, обмен кото-

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

дый вид диаграмм имеет свои преимущества. На диаграмме последо-

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

В случае кооперативных диаграмм можно использовать пространствен-

ное расположение объектов, чтобы показать их статическое взаимо-

действие.

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

Объект1: Имя – Изображение Объекта

– Линия жизни

– Сообщение

– Время активности объекта

– Самоделегирование

– Удаление объекта

27

Изображение диаграммы в виде двумерной схемы

Пример. Последовательность действий и кооперация между объек-

тами при создании отчета "Управление проектами".

Объект1: Имя Объект2: Имя

Менеджер

проектаИсполнитель Отчет

Рис. 4. Диаграмма последовательности создания отчета

"Управление проектами"

28


Технологический процесс создания диаграммы последова-

тельности


d. В меню выбрать команду Browse/Interaction Diagram/New для

вызова окна Select Interaction Diagram.

e. В подокне Package окна Select Interaction Diagram выбрать Use

Case View, нажать ОК.

f. В диалоговом окне New Interaction Diagram в поле Title ввести

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

g. В диалоговом окне New Interaction Diagram выбрать тип диаг-

раммы sequence, нажать ОК.

2. Создание объекта:

a. Нажать кнопку создания объекта.

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

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

линии жизни.

d. Через контекстное меню открыть окно Object Specification и вве-

сти имя объекта и соответствующий ему класс.

Рис. 5. Кооперативная диаграмма "Управление проектами"

проект

а

Исполн

и

1:

6:

4:

3:

5:

2:

Менеджер

проекта

Отчет


29

3. Создание сообщения:

a. Нажать кнопку создания сообщения Object Message.

b. Нарисовать стрелку от линии одного объекта к линии жизни

другого объекта

c. Отрегулировать размещение элементов диаграммы прецедентов.

4. Построение соостветствующей диаграммы кооперации:

a. Нажать функциональную клавишу F5.

b. Изменить сообщение, вызвав закладку Messages.

Задания

Построить диаграмму последовательности на основе диаграмм клас-

сов и диаграммы представления использования, разработанных на пре-

дыдущих занятиях

7. Дать имя диаграмме.

8. Определить объекты, привязав их к диаграмме классов и преце-

дентов.

9. Создать их линии жизни.

10. Установить сообщения между объектами.

11. Присвоить имена сообщениям.


1. Назначение диаграммы взаимодействия.

2. Для чего используется диаграмма последовательности на стадии

анализа?

3. Назовите основные компоненты диаграммы последовательности.

4. Что собой представляет жизненная линия?

5. Как на диаграмме последовательности представляются сообщения?

6. Что такое самоделегирование?

7. Что показывает активизация объекта?

8. Как на диаграмме последовательности представляется уничто-

жение объекта?

30

Лабораторная работа № 5. ДИАГРАММЫ СОСТОЯНИЯ

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

поведение взаимодействующих групп объектов; изучить нотации, при-

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

применение в процессе объектно-ориентированного анализа и проекти-

рования.

Общие понятия

Диаграммы состояния (Statechart) являются средством описания

поведения систем. Они определяют все известные состояния, в кото-

рых может находиться объект, а также процесс смены состояния объек-

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

альных состояния – начальное (start) и конечное (stop). Начальное со-

стояние – состояние объекта, когда он только что создан, конечное –

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

а конечных – сколько вам нужно или вообще не быть. Процесс начина-

ется с начальной точки, а затем переходит в состояние. В поведении

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

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

с переходами и рассматриваются как мгновенные и непрерываемые.

Деятельности связаны с состояниями и могут длиться достаточно дол-

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

торого события. Событие – это то, что вызывает переход из одного

состояния в другое.Переход может содержать метку. Метка перехода

состоит из трех частей, каждая из которых является необязательной

( < Событие>I <Условие >I/<Действие >). Изображается на диаграмме

вдоль линии перехода после имени события. Условный переход. Ис-

тория состояния.

Диаграммы состояний хорошо использовать для описания поведе-

ния некоторого объекта в нескольких различных вариантах использова-

ния, их не надо создавать для каждого класса.

31

Нотации диаграммы состояния

Пример. Получение отчета. Управление проектами.


Технологический процесс создания диаграммы состояния


– В меню выбрать команду Browse/Interaction Diagram/New для


Состояние

Действие

Применение

Переход

Начальное состояние

Конечное состояние

Do:

Выдача

отчета

Отчет

корректируется

Создается

новый отчет

Отчет

проверяется

Отчет

создан

Рис. 6. Диаграмма состояния получения отчета

32

– В подокне Package окна Select Interaction Diagram выбрать Logical

View, нажать ОК.

– В диалоговом окне New Interaction Diagram выбрать тип диаг-

раммы New State Machine Diagram и подтип Statechart, нажать ОК.

– В диалоговом окне New State Machine Diagram в поле Title

ввести имя диаграммы.

2. Начало и создание диаграммы:

– Выбрать объект, использовав кнопку Selection Tool.

– В окне диаграммы состояния создать надпись, использовав кнопку

TextBox.

– вызвать начальное состояние объекта значком Start State.

3. Создание перехода и нового состояния:

– Отразить переход в другое состояние, использовав кнопку State

Transition.

– Отразить состояние, в которое перешел объект, использовав

кнопку State.

– Ввести имя перехода, использовав кнопку.

– Отразить при необходимости переход на себя кнопкой Transition

To Self.

– Спецификация состояния.

– Параметры действия.

– Скрытие вложенных состояний.

4. Создание завершения диаграммы:

– Отразить переход.

– Вызвать завершающее состояние объекта значком EndState.

Задания

Построить диаграмму состояния на основе диаграмм классов и ди-

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

занятиях.


2. Выбрать классы, для объектов которых будет строиться диаг-

рамма состояний.

3. Построить для каждого выбранного класса диаграмму состояний,

характеризующих поведение его объектов в нескольких вариантах ис-

пользования.

33


1. Назначение диаграммы состояний.

2. Как отображаются действия и деятельности на диаграммах со-

стояния?

3. Что такое условный переход и как он описывается на диаграмме?

4. Какие особые состояния отображаются на диаграмме?

5. Что такое история состояния?

6. Что такое вложенные состояния и как их используют и создают?

7. В чем преимущества и недостатки диаграммы?

34

Лабораторная работа № 6. ДИАГРАММЫ АКТИВНОСТИ

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

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

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

ние в процессе объектно-ориентированного анализа и проектирования.


Этот тип диаграмм может использоваться для моделирования раз-

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

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

документов, прохождения оплаты счетов или заказов. Компания, со-

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

здания программного обеспечения. Диаграммы активности (Activity

diagram) – это специальная разновидность диаграмм состояния. Главное

отличие между диаграммами активности и состояния в том, что в пер-

вом случае основное – действие, а во втором – статичное состояние.

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

Из набора значков состояний можно составить представление о всем

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

боты объекта. Нотации используются те же самые, что и при построе-

нии диаграммы состояния, с дополнениями.

Добавляются:

– Activity – значок активности. Похож на значок состо-

яния State, который обозначает ожидание события, а зна-

чок Activity означает действие.

– Значки синхронизации.

– Decision – решение, позволяет показать зависимость

от внешних условий или решений (аналогичен If case в

языках программирования).

– Swimlanes – плавательные дорожки – моделирова-

ние действий различных объектов и связи между ними.

Можно моделировать бизнес-процесы организации, отра-

жая на диаграмме различные подразделения и объекты,

играющие важные роли в процессе. Для этого необходимо

поместить соответствующие значки активности или состоя-

35

ний в зону определенного подразделения, отделенного от

остальных дорожкой.

Пример. Алгоритм получения отчета. Управление проектами.


Технологический процесс создания диаграммы активности

Подготовка:

– В меню выбрать команду Browse/Interaction Diagram/New для


– В подокне Package окна Select Interaction Diagram выбрать Logical

View, нажать ОК.

– Выбрать в диалоговом окне New Interaction Diagram тип диаг-

раммы New State Machine Diagram и подтип Activity, нажать ОК.

– В диалоговом окне New State Machine Diagram в поле Title

ввести имя диаграммы.

Начало создания диаграммы:

– Вызвать начальное состояние объекта значком Start State и

Менеджер проекта Исполнитель

Назначить дату начала и

окончания создания отчета

Выдать

задание

Проверить

отчет

Правильный? Нет

Да

Установить дату

выдачи проекта

Принять

отчет

Доработать

отчет

Создать новый

отчет

Получить задание

на работу

36

состояние Idle.

– Соединить их связью и дать название связи.

– Перенести значки из созданной диаграммы состояний во вновь

созданную нажатием клавиши Ctrl.

– Установить дорожки для различных объектов.

Создание перехода и нового состояния:


Transition.

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

ку State.



To Self.




Настройка спецификаций:

– Отразить переход.

– Вызвать завершающее состояние объекта значком EndState.

Добавление решения.

Синхронизация процессов.

Задания

Построить диаграмму активности на основе диаграммы классов и

диаграммы состояния, разработанных на предыдущих занятиях.


5. Выбрать классы, для объектов которых будут строиться диаг-

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

Построить для выбранных классов диаграмму активности, характе-

ризующую алгоритм выполнения указанной работы.


1. Для чего используется диаграмма активности?

2. Какие отличия между диаграммой активности и состояния?

3. Каков состав инструментов в диаграмме активности?

4. Для чего применяются дорожки?

5. Когда применяется элемент решения?

37

Лабораторная работа № 7. ДИАГРАММЫ ПАКЕТОВ

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

чить нотации, применяемые при построении диаграмм пакетов, и осво-

ить их применение в процессе объектно-ориентированного анализа и

проектирования.


Важной задачей систематизации информации о предметной области

является разбиение большой системы на небольшие подсистемы. Имен-

но здесь особенно заметны структурные и объектно-ориентированные

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

классов в компоненты более высокого уровня. В UML такой механизм

группировки носит название пакетов (package). Диаграммой пакетов

является диаграмма, содержащая пакеты классов и зависимости меж-

ду ними. Строго говоря, пакеты являются элементами диаграммы клас-

сов, т. е. диаграмма пакетов – это всего лишь диаграмма классов. От-

личаются эти диаграммы практическим назначением и использовани-

ем. Зависимость между двумя элементами имеет место в том случае,

если изменения в определении одного элемента могут повлечь измене-

ния в другом.

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

· один класс посылает сообщение другому;

· один класс включает часть данных другого класса;

· один класс ссылается на другой, как на параметр операции.

Если класс меняет свой интерфейс, то сообщение, которое он посы-

лает, может стать неправильным.

На рис. 8 показаны классы предметной области, возникающие при

моделировании деятельности менеджера по управлению проектами. Они

сгруппированы в пакеты: контракты, менеджеры, отчеты, исполнители.

Приложение Проект имеет связь с пакетами предметной области Ме-

неджеры, Отчеты, Контракты. Приложение Специалисты имеет связь

с Исполнителями, через которых можно узнать, какие отчеты они под-

готовили.

Пакеты являются жизненно необходимыми для больших проектов.

Особенно когда диаграмма классов, охватывающая всю систему, труд-

ночитаемая. Пакеты не дают ответа на вопрос, каким образом можно

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

38

помогают выделить эти зависимости. Пакеты полезны при тестирова-

нии системы. Каждый пакет может содержать один или несколько тес-

тируемых классов, с помощью которых проверяется поведение пакета.

Нотации диаграммы состояния

– Activity – значок активности. Похож на значок состо-

яния State, который обозначает ожидание события, а зна-

чок Activity означает действие.

– Значки синхронизации.

Пример. Получение отчета "Управление проектами".

Рис. 7. Диаграмма пакетов "Пользовательский интерфейс"

Пользовательский

интерфейс управление

проектами

Приложение

Проекты

Приложение

Специалисты

КонтрактыИсполнители

МенеджерыОтчеты

39


Технологический процесс создания диаграммы активности

Подготовка:

– В меню выбрать команду Browse/

Component Diagram или воспользоваться

значком Main вызова окна для построения

и соответствующей панели инструментов.

– Присвоить имя диаграмме.

– Выбрать в диалоговом окне New Interaction Diagram тип диаграммы

New State Machine Diagram и подтип Activity, нажать ОК.

– В диалоговом окне New State Machine Diagram в поле Title вве-

сти имя диаграммы.

Начало создания диаграммы:

– Вызвать начальное состояние объекта, значком Start State и

состояние Idle.

– Соединить их связью и дать название связи.

– Перенести значки из созданной диаграммы состояний во вновь

созданную нажатием клавиши Ctrl.

– Установить дорожки для различных объектов.

Создание зависимостей между пакетами:


Transition.

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

ку State.



To Self.




Задания

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

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

40


1. Какую проблему призваны решить диаграммы пакетов?

2. В чем отличия диаграмм пакетов от диаграмм классов?

3. В чем смысл зависимости между элементами диаграммы пакетов?

4. Что такое интерфейс класса?

5. По каким признакам классы группируются в пакеты?

Библиографический список

1. Хоменко А., Цыганков Л., Мальцев М. Базы данных: Учебник выс-

ших и средних учебных заведений. СПб.: КОРОНАпринт, 2000. 416 с.

2. Хансен Г., Хансен Дж. Базы данных: разработка и управление.

М.: ЗАО "Издательство БИНОМ", 1999. 704 с.

3. Карпова Т. С. Базы данных: Учебник. СПб.: Питер, 1999. 310 с.

4. Информационные системы в экономике: Учебник / Под ред. В. В. Дика.

М.: Финансы и статистика, 1996. 00 с.

5. Смирнов Г. Н. Проектирование экономических информационных

систем. М.: Финансы и статистика, 2001. 00 с.

6. Гарнаев А. Office 2000: разработка приложений / Под общ. ред.

Ф. Новикова. СПб.: БХВ – Санкт-Петербург, 2000. 656 с.

7. Миронов Д. Создание Web-страниц в MS Office 2000. СПб.: БХВ –

Санкт-Петербург, 2000. 320 с.

8. Рамбо Дж., Якобсон А., Буч Г. UML: специальный справочник.

СПб.: Питер, 2002. 656 с.

9. Вендров А. Практикум по проектированию программного обеспе-

чения экономических информационных систем: Учеб. пособие. М.: Фи-

нансы и статистика, 2002. 192 с.

10. Кратчен Ф. Введение в Rational Unified Process. М.: Издательс-

кий дом "Вильямс", 2002. 240 с

11. Квартрани Т. Rational Rose и визуальное моделирование. М.: ДМК

Пресс, 2001. 176 с.

12. Фаулер М., Скотт К. UML. СПб.: Символ-Плюс, 2002. 192 с.

13. Федотова Д. CASE – технологии: Практикум. М.: Горячая ли-

ния – Телеком, 2003. 160 с.

14. Маклаков С. BPwin и Erwin. CASE – средства разработки инфор-

мационных систем. М.: Диалог-МИФИ, 2001. 304 с.

15. Маклаков С. Создание информационных систем с OLLFusion

Modeling Suite. M.: Диалог-МИФИ, 2003. 432 с.

41

Содержание

Введение ................................................................................................... 1

Темы лабораторных работ ...................................................................... 6

Лабораторная работа № 1. Ознакомление с CASE-средством

Rational Rose ......................................... 8

Лабораторная работа № 2. Создание модели вариантов

использования ...................................... 15

Лабораторная работа № 3. Диаграммы классов ............................ 19

Лабораторная работа № 4. Диаграммы взаимодействия ............. 25

Лабораторная работа № 5. Диаграммы состояния ........................ 30

Лабораторная работа № 6. Диаграммы активности ...................... 34

Лабораторная работа № 7. Диаграммы пакетов ............................ 37

Библиографический список ..................................................................... 40

ИНФОРМАЦИОННЫЕ...

Documents