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


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

Федеральное государственное бюджетное образовательное
учреждение

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

«Воронежская государственная лесотехническая академия»












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


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

для студентов по направлению подготовки

230400


Информационн
ые системы и технологии














Воронеж 2014

2


УДК
004.43


Коровина, О. В. Архитектура информационных систем [Текст] :

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


Информационные системы и технологии /
О.

В.

Коровина; М
-
во образования и науки РФ, ФГБОУ ВПО «ВГЛТА».


Воронеж, 2014.


5
4

с.





3


СОДЕРЖАНИЕ

Введение

................................
................................
................................
...................

4

Лабораторная работа №1. Установление требований.

................................
......

10

Лабораторная работа № 2. Ознакомление с CASE
-
средством
R
ational
R
ose.

21

Лабораторная работа № 3. Создание модели вариантов использования

........

28

Лабораторная работа № 4. Диаграммы классов

................................
.................

32

Лабораторная работа № 5. Диаграммы взаимодействия

................................
..

38

Лабораторная работа № 6. Диаграммы состояния

................................
............

43

Лабораторная работа № 7. Диаграммы активности

................................
..........

46

Лабораторная работа № 8. Диаграммы пакетов

................................
................

50

Библиографический список.

................................
................................
................

54




4


Введение

Разработка информационной системы состоит из трех этапов:

анализа,
проектирования и реализации, в результате итеративного

выполнения
которых происходит пошаговое
«наращивание» системы.

На этапах анализа и проектирования происходит построение

архитектуры будущей информационной системы.

Архитектура программного обеспечения системы или набора систем

состоит из всех важных проектных решений по поводу структур

программы

и взаимодействий между этими структурами, которые

составляют системы.
Проектные решения обеспечивают желаемый набор

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

Проектные решения предоставляют концептуальную основу для

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

Моделирование предметной области является одним из наиболее
важных этапов работ при проектировании программных систем масштаба

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

продуктов представлен широкий

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

Rose
,
BPwin
,
Silverrun
,
Process

Analyst
.

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

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

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



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



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



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



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



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



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

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

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

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

5


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

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

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

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

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

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

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

Итак, подводя

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

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

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

лиц, их

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

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

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

3. Модель структуры предприятия

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

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

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

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

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

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

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

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

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

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

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

Case
-
средства

Термин
CASE



Computer

Aided

System
/
Softw
are

Engineering

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


предшество
вали исследования в области мет
одологии проектирования.
Методо
логия определяет этапы и шаги реализации проекта, а так
же правила

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


это
процедура или техника генерац
ии описаний компонентов информа
ционной
системы (проектирование потоков и структур данных).
Но
тация


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

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


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

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

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

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

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

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

программного обеспечения. Наиболее

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

в
процессе которых CASE
-
средства

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

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

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

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

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

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

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

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

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

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

1. Репозиторий, являющийся осн
овой CASE
-
средства. Он представ
ляет
собой специализированную ба
зу данных проекта, предназначен
ную для
7


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

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

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

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

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

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

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

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

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

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

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

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

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

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

b) автору,

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

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

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

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

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

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

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

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

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

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

8



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

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

При применении CASE
-
средств

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

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

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

методологию
RUP

(
Rational

Unified

Process
) и нотации языка
UML
.

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

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


основная часть модели описания

системы.

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


описание функциональных
возмож
ностей системы.

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


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

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


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

5. Пред
ставление распределения


описание физической архитекту
ры
системы.

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

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

SADT

(
Structured

Analysis

and

Design

Technique
). Главным разра
бот
чиком
методологии был Дуглас Росс. Он разработал язык структурного анализа,
используемого для описания исследуемого объекта. Этот

язык лег в основу
9


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

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

IDEF0


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

IDEF1Х


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

IDEF2


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

IDEF3


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

IDEF4


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

IDEF5


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

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

Цель данных методических указаний


изучение на практике

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

получать
успешные архитектуры информационных систем.

Методические

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

работы и
приведения комментариев и примеров к их выполнению.

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

последовательное выполнение.

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

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

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

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

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

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

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

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

отчет.

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

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

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

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

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



10


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

Установление требований.


1.

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

1.1.

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

1.2.

В результате выполнения лабораторной работы студенты должны
знать:

-

методы анализа информационных ресурсов;

-

методы разработки различных мо
делей данных;

-

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

-

методы анализа проектных решений.


2.

Теоретический материал для домашнего изучения.

Получить задание у преподавателя

для разработки информационн
ой

систем
ы

(ИС). ИС

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

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

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

таких систем могут служить:



автоматизированные системы управления (АСУ)



электронные магазины, аукц
ионы



веб
-
порталы



сервисы

Составить документ описания требований к разрабатываемой ИС

согласно шаблону.

1.

Установление требований

1.1 Документ описания требований

Документ, описывающий требования, является осязаемым

результатом
этапа установления
требований. Большинство организаций

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

определенным
шаблоном. Шаблон определяет структуру (содержание) и

стиль документа.

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

(изложения)

требований. Требования могут быть сгруппированы в виде

формулировок сервисов
(зачастую называемых функциональными

требованиями) и
формулировок ограничений
. Формулировки сути

сервисов
11


могут быть затем разделены на
требования к функциям
(
function

requiremen
ts
) и
требования к данным
(
data

requirements
). (В литературе

термин «
функциональные требования
» (
functional requirements
) в

широком и
в узком смысле используется как взаимозаменяемый. При

использовании в
узком смысле он соответствует тому, что мы называем

требованиями к
функциям).

Не говоря уже о самих требованиях, документ описания требований

должен обращаться к проектным вопросам. Обычно проектные вопросы

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

Во вводной части документа рассматрива
ется бизнес
-
контекст

проекта,
включая цель проекта, участников проекта и основные

ограничения. Ближе к
заключительной части документа поднимаются

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

работ, бюджет, риски,
документацию и т. д.

1.2 Шаблоны документа

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

Их
можно найти в учебниках, стандартах, выпускаемых такими

организациями
как ISO, IEEE и т. д., на Web
-
страницах консалтинговых

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

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

соответствуют принятой в
организации практике, корпоративной

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

Шаблон документа описания требований определяет с
труктуру

документа и содержит подробные указания о содержании каждого из

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

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

На рис.
1

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

требований.

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

оглавлению.

1.3 Предварительные замечания к проекту

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

предварительные
замечания к проекту, преимущественно дает ориентиры

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

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

целиком. В начале
12


документа необходимо ясно обозначить цели и рамки

проекта, а затем
описать деловой контекст системы.

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

системы. В частности, необходимо упомянуть обо всех усилиях,

приложенных для обоснования необходимости системы на этапе

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

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

достижению деловых целей и решению задач организацией.

Необходимо обозначить участников проекта системы. Важно, чтобы

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


необхо
димо привести конкретные имена.


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

Содержание документа

1. Предварительные замечания к проекту

1.1. Цели и рамки проекта

1.2. Деловой контекст

1.3. Участники проекта

1.4. Идеи в отношении решений

1.5. Обзор документа

2. Системные сервисы

2.1. Рамки системы

2.2. Функциональные

требования

2.3. Требования к данным

3. Системные ограничения

3.1. Требования к интерфейсу

3.2. Требования к производительности

3.3. Требования к безопасности

3.4. Эксплуатационные требования

3.5. Политические и юридические требования

3.6. Другие
ограничения

4. Проектные вопросы

4.1. Открытые вопросы

4.2. Предварительный план
-
график

4.3. Предварительный бюджет

Приложения

Глоссарий

Деловые документы и формы

Ссылки


Рис.
1

Содержание документа описаний требований

13


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

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

Документ описания требований должен предоставлять перечень

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

в
дальнейшем изучены в качестве вариантов возможных решений.

В

заключение раздела предварительных замечаний

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

части документа. Это может подтолкнуть к тому,

чтобы изучить

остальные
части документа, а также способствует лучшему пониманию

содержания
документа. Обзор также может содержать пояснения в

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

разработчиками.

1.4 Системные сервисы

Основная часть доку
мента описания требований посвящена

определению системных сервисов. Эта часть может занимать до половины

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

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


модели

бизнес
-
требований.

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

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

определены рамки
системы. Без подобного определения проект не может

быть застрахован от
попыток «растянуть» его рамки.

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

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

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

Требования к данным можно моделировать

с помощью диаграммы

бизнес
-
классов. Так же, как и в случае функциональных требований,

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

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

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

определить
идентифицирующие атрибуты классов. В противном случае

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

1.5 Системные ограничения

Системные сервисы определяют, что должна делать система.

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

14


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

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



Требования к интерфейсу.



Требования к производительности.



Требования к безопасности.



Эксплуатационные требования.



Политические и юридические
требования.

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

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

«впечатление и ощущение» от GUI
-
интерфейса.

Начальное проектирование (закрашивание экрана) GUI
-
интерфейса

пров
одится во время спецификации требований и позже во время

системного
проектирования.

В зависимости от области приложения требования к

производительности могут играть довольно значительную роль в успехе

проекта. В узком смысле они задают скорость (время
отклика системы), с

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

требования к производительности включают другие ограничения


в
отношении надежности, готовности, пропускной способности и т. д.

Требования к безопасности описывают пользов
ательские права

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

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

права на
выполнение определенных операций с данными.

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

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

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

сопровождение системы.

Политические требования и
юридические требования скорее

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

требований. Подобная ошибка может обойтись очень дорого. Пока эти

требования не выведены явно, программный продукт может быть трудно

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

Возможны и другие виды ограничений. Например, в отношении

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

легкости
15


их использования (требования в отношении пригодности к

использованию)
или легкости их сопровождения (требов
ания в отношении

пригодности к
сопровождению).

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

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

которые провалились из
-
за упущенных или неверно понятых

ограничений.
Эта пробле
ма в равной мере относится как к заказчикам, так

и к
разработчикам. Недобросовестные или нерассудительные

разработчики
могут разыграть «карту системных ограничений», чтобы

получить
преимущество в своем стремлении уклониться от

ответственности.

1.6 Проектны
е вопросы

Заключительная часть документа описания требований обращается к

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

называется «Открытые вопросы».

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

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

Сюда относится ожидаемое возрастание значения некоторых
т
ребований,

которые в текущий момент выходят за рамки проекта. Сюда
можно

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

системы, которые

могут начаться в связи с развертыванием
системы.

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

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

выработки
стандартных

плановых графиков можно использовать

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

система
PERT

(
program

evaluation
_
and
_
review

technique



метод оценки и

пересмотра планов) или
карты Ганта.

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

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

выражена скорее
в виде диапазона значений затрат, а не конкретного

значения. При наличии
надлежащим образом документированных

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

методов.

1.7 Приложения

16


Приложения содержат остальную, полезную для понимания

требований, информацию. Основным добавлением здесь служит

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

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

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

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

Одна из особенностей, которую часто упускают из виду при

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

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

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

процессах делопроизводства. При возможности следует включать в

документ
заполненные формы


«пустые» формы не дают такого ж
е

уровня
понимания бизнес
-
процессов.

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

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

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

источники информации,
но


что, пожалуй
, даже более важно


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

и внутренние документы.

Пример документа описания требований

Документ описания требований ИС «Домашняя бухгалтерия»

1. Предварительные замечания к проекту

1.1. Цели и
рамки проекта

Целью данного проекта является разработка информационной

системы
для ведения и оптимизации семейного бюджета.

ИС «Домашняя бухгалтерия» должна быть проста в использовании

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

1.2. Делово
й контекст

Многие семьи в наше время планируют семейный бюджет. Ведение

семейного бюджета при помощи подручных средств


карандаш,

бумага


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

этих целей
компьютерных программ для ведения бухгалтерии не

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

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

ведения домашней бухгалтерии.

1.3. Участники проекта

17


Заказчик


Васильева

Марья Федоровна (m.vasileva@mypochta.ru)

Разработчик


Петров Степан Николаевич (petrov@coolsoft.com)

1.4. Идеи в отношении решений

Программа должна быть реализована в виде настольного

приложения
для операционных систем семейств MS Windows.

1.5. Обзор док
умента

В разделе «Системные сервисы» описывается, что должна делать

система. В разделе «Системные ограничения» определяется,

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

В разделе «Проектные вопросы» освещаются прочие проектные

вопросы.

2. Сис
темные сервисы

2.1. Рамки системы

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

контекста.


Рис.
2

Контекстная диаграмма ИС «Домашняя Бухгалтерия»


ИС «Домашняя Бухгалтерия» получает данные о доходах и

расходах от
внешней сущности «Домохозяин». Для
передачи этих

данных сущности
«Домохозяин» должен авторизоваться. В своей

работе сущность «Домашняя
Бухгалтерия» использует информацию

о ценах на товары и тарифах и курсах
валют, получаемую от

внешних сущностей «База тарифов и цен на товары» и
«База курса

валют». Результаты своей работы ИС «Домашняя Бухгалтерия»

может отображать как внешней сущности «Домохозяин», так и

генерировать
в виде отчетов формата MS Excel для внешней

сущности «MS Excel».

2.2. Функциональные требования

ИС должна обеспечивать следующи
е функциональные

возможности:

18




учет расходов;



учет доходов;



учет денег, отданных и взятых в долг;



погашение долгов частями;



проценты по долгам;



контроль возврата долгов;



система напоминания по долгам;



составление бюджета расходов и доходов;



планирование
расходов;



планирование доходов;



система счетов;



возможность использовать до пяти валют включительно;



получение курсов валют из интернет;



обмен валют;



импорт данных из файлов Microsoft Excel;



поиск по базе данных;



фильтры и быстрый поиск по базе данных;



экс
порт данных в Excel, XML, текстовый файл;



перенос данных;



резервное копирование;



печать данных;



построение отчетов и диаграмм;



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

2.3. Требования к данным

ИС должна хранить свои данные в специализированных XML
-
файлах.

3. Системные ограничения

3.1. Требования к интерфейсу

ИС должна иметь стандартный интерфейс приложений,

разработанных
для ОС MS Windows.

3.2. Требования к производительности

Особых требований к производительности ИС нет.

3.3. Требования к безопасности

19


С пр
ограммой могут работать несколько человек, входя в

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

конфиденциальности каждое имя
можно защитить паролем.

Добавление, изменение и удаление пользователей осуществляется в

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

3.4. Эксплу
атационные требования

ИС должна функционировать на ОС Windows XP, OC Windows

Vista,
ОС Windows 7. Минимальные аппаратные требования

определяются
минимальными аппаратными требованиями к вышеперечисленным ОС.

3.5. Политические и юридические требования

Нет.

3
.6. Другие ограничения

Нет.

4. Проектные вопросы

4.1. Открытые вопросы

Нет.

4.2. Предварительный план
-
график

1.09.2010


1.10.2010


Анализ и установление требований к ИС

1.10.2010


1.11.2010


Спецификация требований к ИС

1.11.2010


1.12.2010


Кодирова
ние ИС

1.12.2010


31.12.2010


Тестовая эксплуатация ИС

11.01.2011


13.12.2011


Ввод в эксплуатацию

4.3. Предварительный бюджет

Пятьдесят тысяч рублей.

5. Приложения

Глоссарий

ИС


информационная система

ОС


операционная система

Деловые документы и
формы

Нет.

Ссылки

Нет.


3.

Лабораторные

задания
.

1. АСУ деятельностью отдела кадров предприятия
.

20


2. АСУ складского хранения
.

3. АСУ деятельностью библиотеки
.

4. Веб
-
магазин по продаже часов
.

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

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

6. АСУ деятельностью аптечной сети
.

7. Веб
-
сайт букмекерской конторы
.

8. ИС учета успеваемости студентов
.

9. Веб
-
магазин по продаже компьютерных комплектующих
.

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

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

12. ИС «Ежедневник»
.

13. АСУ деятельностью магазина видеопроката
.

14. АСУ деятельностью
автосалона
.

15. Веб
-
магазин по продаже одежды
.

16. ИС «Почтовый коллектор»
.

17. АСУ деятельностью магазина бензозаправки
.

18. АСУ учетом пациентов в поликлинике
.

19. АСУ учетом коммунальных платежей
.

20. АСУ деятельностью службы такси
.

21. ИС сбора и обраб
отки ошибок (багтрекер)
.

22. Веб
-
сайт кафедры
.

23. Веб
-
сайт факультета
.

24. ИС хранения и каталогизации фотографий
.

25. ИС «Каталог недвижимости»
.

26. Транзисторы классифицируются по типу, мощности и
конструктиву; ведется учет поступлений и продаж.

27.
Веб
-
магазин по продаже фотоаппаратов
.

4
. Контрольные вопросы.

1.


Что такое
CASE
-
средство
?

2.


Приведите примеры применения
CASE
-
средств.

3.


Приведите примеры
CASE
-
средств.



21


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

О
знакомление с CASE
-
средством
R
ational
R
ose
.


1.

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

1.1.

Целью лабораторной работы является изучение
интерфейс
а

Rational Rose и принципы работы с ним.

1.2.

В результате выполнения лабораторной работы студенты
должны знать:

-

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

-

принципы работы
с программным проду
ктом
;

-

структуру
и функции
R
ational
R
ose
.


2.

Теоретический материал для домашнего изучения.

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 лежит построение различного рода
диаграмм и спецификаций, определяющих логическую и физическую
структуры модели, ее статические и динамические аспекты. В их число
22


входят диаграммы классов, состояний, сценариев, мод
улей, процессов.В
составе Rational Rose можно выделить 6 основных структурных компонент:



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



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



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



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



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



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

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


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

Средства просмотра обеспечивают "навигацию" по проекту, в том
числе: перемещение по иерархиям классов и подсистем, переключение от
одного вида диаграмм к другому и т. д. Средства контроля и сбора
статистики дают возможность находить и устранять ошибки по
мере
развития проекта, а не после завершения его описания. Генератор отчетов
формирует тексты выходных документов на основе содержащейся в
репозитории информации. Средства автоматической генерации кодов
программ на языке С++, используя информацию, содержащ
уюся в
логической и физической моделях проекта, формируют файлы заголовков и
файлы описаний классов и объектов. Создаваемый таким образом скелет
программы может быть уточнен путем прямого программирования на языке
С++. Анализатор кодов С++ реализован в вид
е отдельного программного
модуля. Его назначение состоит в том, чтобы создавать модули проектов в
форме Rational Rose на основе информации, содержащейся в определяемых
пользователем исходных текстах на С++. В процессе работы анализатор
осуществляет контрол
ь правильности исходных текстов и диагностику
ошибок.

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

23


Таким образом, Rational Rose/С++ обеспечивает возможность
повторного использов
ания программных компонент.

В результате разработки проекта с помощью CASE
-
средства Rational
Rose формируются следующие документы:



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



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



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



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



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



спецификации

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



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



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

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

Взаимодействие с другими средствами и организация групповой
работы Rational Rose интегрируется со средством PVCS для организации
групповой работы и управления проектом и со средством SoDA


для
документирования
проектов. Интеграция Rational Rose и SoDA
обеспечивается средствами SoDA. Для организации групповой работы в
Rational Rose возможно разбиение модели на управляемые подмодели.
Каждая из них независимо сохраняется на диске или загружается в модель. В
качеств
е подмодели может выступать категория классов или подсистема. Для
управляемой подмодели предусмотрены операции:



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



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



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



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



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

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


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

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

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

SPARC

stations

(
UNIX
,
Solaris
,
SunOS
),

(
HP

UX
),
IBM

RS
/6000 (
AIX
). Для работы систем
ы необходимо выполнение
следующих требований:

Платформа Windows


процессор 80386SX или выше (рекомендуется
80486), память 8 Mб (рекомендуется 12 Mб), пространство на диске 8Mб + +
1

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

Платформа UNIX


память 32 + (16* число пользовате
лей) Mб,
пространство на диске 30 Mб + 20 при инсталляции + 1

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

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

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

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

2.
Найти

в

программах

Ration
al Rose Enterprise Edition
и

выбрать

Rational Rose Enterprise Edition

(
рис
. 1).


Рис. 1 Меню запуска программы

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

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

(рис. 2)
.

25



Рис. 2 Окно выбора
проекта


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

CASE


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



меню;



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



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



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



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

26


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




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




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




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




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




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



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

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



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



логическое;



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



размещения.

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





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





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





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




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

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





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





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

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

системы.


3.

Лабораторные

задания
.

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

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

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

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


27


4.
Контрольные вопросы.

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

2. Опи
шите
окно

приложения и основные функции меню
.

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

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



28


Лабораторная работа №
3
.

Создание модели вариантов

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


1.

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

1.1.

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

1.2.

В результате выполнения лабораторной работы студенты должны
знать:

-

нотации, применяемые при построении диаграмм
;

-

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

-

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


2.

Теоретический материал для домашнего изучения.

Моделирование в Ration Rose проводится как спуск от конц
ептуаль
ной
модели к логической, а затем к физической модели программной

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


case diagram). Этот тип диаграмм служит

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

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

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

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

которые он хотел

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

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

определены:



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



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



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



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



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

29


Действующее лицо (Actor)


это роль, которую пользователь играет

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

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

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

системы управления проектами


обратную связь

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

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


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

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

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




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

система;



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



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




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

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

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

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


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

Пример выполнения задания

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

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


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

b. Повторить п.п. 2b, c, d

для аспекта.

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

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

31


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

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


3.

Лабораторные

задания
.

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

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

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

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

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

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


4.

Контрольные вопросы.

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

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

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

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

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

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

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



32


Лабораторная работа №
4
.

Диаграммы классов


1.

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

1.1.

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

1.2.

В результате выполнения лабораторной работы студенты должны
знать:

-

нотации диаграммы классов;

-


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


2.

Теоретический материал для домашнего изучения.

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

объектно
-
ориентированного анализа и

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

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

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


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

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

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



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



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

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

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

объектами.

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

компания имеет ряд офисов). Лю
бая
ассоциация обладает двумя ролями. Например (рис
.
1
)


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


от Отчета к Исполнителю. Роль также

обладает множественностью.
Пример


символ "0..
*
" над ассоциацией

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

с одним Менедже
ром связано много Контрактов. 0


33


показывает, что Менеджер может

не уп
равлять контрактом; 1


показывает,
что любой Контракт может

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

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

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

Атрибуты

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

навигации


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

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

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

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



общий (publ
ic)


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



защищенный (protected)


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

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



секретный (private)


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

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



реализация (implementa
tion)


атрибут внедренный, доступен внутри

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

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

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

Отчет


Добавить().

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



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



ассоциация ме
жду классами с обозначением воз
можных
видов связи:

i. m

{1, n, 0..1, 0..*, 1..*},

34


ii. k

{1, n, 0..1, *, 0..*, 1..*}.

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

в
классе.

Пример.

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

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

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

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

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

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

35



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ii. Являющиеся субъектами, и
х необходимо привести в стандар
тный
для класса вид командой Forma
t/Stereotype Display.

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

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

36


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

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

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

public (default)

protected

pri
vate

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,

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


3.

Лабораторные

задания
.

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

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

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

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

b. Назначить атри
бут


ключ (идентификатор объекта), например

для
объекта Менеджер


это может быть Код менеджера.

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

37


Менеджер


Добавить().

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

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

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


4.

Контрольные вопросы.

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

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

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

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

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

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

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

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

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

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



38


Лаб
ораторная работа № 5
.

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


1.

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

1.1.

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

1.2.

В результате выполнения лабораторной работы студенты
должны
знать:

-

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

-

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


2.

Теоретический материал для домашнего изучения.

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

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

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



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



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



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



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



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



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

Существует два вида диаграмм
взаимодействия: диаграммы
после
довательности (sequence diagrams)
и кооперативные, или
сотрудниче
ства (collaboration

diagrams).

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

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

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


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

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

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

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

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



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



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



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

идут
сверху.



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



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

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

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



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


сообщение самому

себе.

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

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

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

показать их статическое
взаимо
действие.

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

40



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


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


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

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

41



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

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

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

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

d.
В

меню

выбрать

команду

Browse/Interaction Diagram/New
для

вызова

окна

Select Interaction
Diagram.

e.
В

подокне

Package
окна

Select Interaction Diagram
выбрать

Use

Case
View,
нажать

ОК
.

f
. В диалоговом окне
New

Interaction

Diagram

в поле
Title

ввести

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

g. В диалоговом окне New Inter
action Diagram выбрать тип диаг
раммы
sequence, нажать ОК.

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

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

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

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

линии
жизни.

d. Через контекстное меню открыть
окно Object Sp
ecification и вве
сти имя
объекта и соответствующий ему класс.

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

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

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

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

42


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

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

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

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


3.

Лабораторные

задания
.

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

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

2
. Определить объекты, привязав

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

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

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

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


4. Контрольные вопросы.

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

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

анализа?

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

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

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

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

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

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



43


Лабораторная работа №
6
.

Д
иаграммы состояния


1.

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

1.1

Целью лабораторной работы является
ознаком
ление

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

1.2.

В результате выполнения лабораторной работы студенты должны
знать:

-

нотации, применяемые при построении
диаграмм
состояния
;

-

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

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


2.

Теоретический материал для домашнего изучения.

Диаграммы состояния (Statechart) являются средством описания

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


начальное (start) и конечное (stop
). Начальное со
стояние


состояние объекта,

когда он только что создан, конечное


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

а конечных


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

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

с переходами и
рассматриваются как мгновенные и непрерываемые.

Деятельности связаны с состояниями

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


это то, что вызывает переход из одного

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

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

( < Событие
�I
<Условие >I/<Действие >). Изображается на диаграмме

вдоль линии
перехода после имени события.
Условный переход. Ис
тория состояния.

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

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


44


Нотации диаграммы состояния



Пример
. Получение отчета. Управление проектами.


Рис.
1
. Диаграмма состояния получения отчета

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

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

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



В

меню

выбрать

команду

Browse/Interaction Diagram/New
для

вызова

окна

Select Interaction Diagram.



В

подокне

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. Создание перехода и нового состояния:

45




Отразить переход в другое состояние, использовав кнопку State

Transition.



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

кнопку
State.



Ввести имя перехода, использовав кнопку.



Отразить при необходимости переход на себя кнопкой Transition

To
Self.



Спецификация состояния.



Параметры действия.



Скрытие вложенных сост
ояний.

4. Создание завершения диаграммы:



Отразить переход.



Вызвать завершающее состояние объекта значком EndState.


3.

Лабораторные з
адания
.

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

предыдущих

занятиях.

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

2. Выбрать классы, для объект
ов которых будет строиться диаг
рамма
состояний.

3. Построить для каждого выбранного класса диаграмму состояний,

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


4.

Контрольные вопросы.

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

2. Как отображаются действия
и деятельности на диаграммах
со
стояния?

3. Что такое условный переход и как он описывается на диаграмме?

4. Какие особые состояния отображаются на диаграмме?

5.
Что такое история состояния?

6. Что такое вложенные состояния и как их используют и создают?

7. В чем преимущества и недостатки диаграммы?



46


Лабораторная работа №
7
.

Д
иаграммы активности


1.

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

1.1.

Целью лабораторной работы является
ознаком
ление

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

1.2.

В результате выполнения лабораторной работы студенты должны
знать:

-

нотации, применяемые при построении диаграмм
активности
;

-

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


2.

Теоретический материал для домашнего изучения.

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

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

diagram)


это
специальная разн
овидность диаграмм состояния. Главное

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


действие, а во втором


статичное состояние.

Нотации диаграммы
активности

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

о всем

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

те же самые, что и при построе
нии
диаграммы состояния, с дополнениями.

Добавляются:




Activity


значок ак
тивности. Похож на значок состо
яния
State,
который обозначае
т ожидание события, а зна
чок Activity означает действие.




Значки синхронизации.




Decision


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

от
внешних условий или решений (аналогичен If case в

языках
программирования).

47





Swimlanes


плавательные дорожки


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

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

играющие важные роли в
процессе. Для этого необходимо

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

остальных дорожкой.

Пример
. Алгоритм получения отчета. Управление проектами.


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

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

Подготовка:



В

меню

выбрать

команду

Browse/Interaction Diagram/New
для

вызова

окна

Select Interaction Diagram.



В

подокне

Package
окна

Select Interaction Diagram
выбрать

Logical

View,
нажать

ОК
.



Выбрать

в

диалоговом

окне

New Interaction Diagram
тип

диаграммы

New State Machine Diagram
и

подтип

Activity,
нажать

ОК
.



В диалоговом окне
New

State

Machine

Diagram

в поле
Title

ввести имя
диаграммы.

Начало создания диаграммы:



Вызвать начальное состояние объекта значком Start State и состояние
Idle.



Соединить их связью и дать название связи.

48




Перенести значки из созданной диаграммы состояний во вновь

созданную нажатием клавиши Ctrl.



Установить дорожки для различных объектов.

Создание перехода и нового состояния:



Отразить переход в другое состояние, использовав кнопку State

Transition.



Отразить состояние, в которое п
ерешел объект, использовав кноп
ку
State.



Ввести имя перехода, использовав кнопку.



Отразить при необходимости переход на себя кнопкой Transition

To
Self.



Спецификация состояния.



Параметры действия.



Скрытие вложенных состояний.

Настройка спецификаций:



Отразить переход.



Вызвать завершающее состояние объекта значком EndState.

Добавление решения.

Синхронизация процессов.


3.

Лабораторные з
адани
я
.

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

диаграммы состояния, разработанных на предыдущих занятиях.

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

2
. Выбрать классы, для объект
ов которых будут строиться диаг
раммы
состояний.

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


4 Контрольные вопросы.

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

2. Какие отличия между диаграммой активности и состояния?

3. Каков состав инструментов в диаграмме активности
?

4. Для чего применяются дорожки?

5. Когда применяется элемент решения?

49




50


Лабораторная работа №
8
.

Д
иаграммы пакетов


1.

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

1.1.

Целью лабораторной работы является
ознаком
ление

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

1.2.

В результате выполнения
лабораторной работы студенты должны
знать:

-

нотации, применяемые при построении диаграмм пакетов
;

-

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

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


2.

Теоретический материал для домашнего изучения.

Важной задачей
систематизации информации о предметной области

является разбиение большой систем
ы на небольшие подсистемы. Имен
но
здесь особенно заметны структурные и объектно
-
ориентированные

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

классов в
компоненты более высокого уровня. В UML такой механизм

группировки
носит название пакетов (package). Диаграммой пакетов

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


это в
сего лишь диаграмма классов. От
личаются эти диаграммы практиче
ским
назначением и использовани
ем. Зависимость между двумя элементами имеет
место в том случае,

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

другом.

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

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

· один класс включает часть данных другого класса;

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

Если класс меняет свой интерф
ейс
, то сообщение, которое он посы
лает,
может стать неправильным.

На рис.
1

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

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

сгруппированы в пакеты: контракты, менеджеры, отчеты, исполнит
ели.

Приложение Проект имеет связь с

пакетами предметной области
Ме
неджеры, Отчеты, Контракты. Приложение Специалисты имеет связь

с
51


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

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

Особенно когда диаграмма классов,

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

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

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

Нотации диаграммы
пакетов




Activity


значок ак
тивности. Похож на значок состо
яния State,
который обо
значает ожид
ание события, а зна
чок Activity означает действие.




Значки синхронизации.

Пример. Получение отчета «Управление проектам»
.


Рис.
1
. Диаграм
ма пакетов «
Пользовательский интерфейс
»

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

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

Подготовка:


52





В меню выбрать команду Browse/Component Diagram
или воспользоваться

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

и
соответствующей панели инструментов.



Присвоить имя диаграмме.



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

New

State

Machine

Diagram

и

подтип

Activity
,
нажать

ОК
.



В диалоговом окне
New

State

Machine

Diagram

в поле
Title

ввести имя
диаграммы.

Начало создания диаграммы:



Вызвать начальное состояние объекта, значком Start State и

состояние
Idle.



Соединить их связью и дать название связи.



Перенести значки из созданной диаграммы состояний во вновь

созданную нажатием клавиши Ctrl.



Установить дорожки для различных объектов.

Создание зависимостей между пакетами:



Отразить переход в другое состояни
е, использовав кнопку State

Transition.



Отразить состояние, в которое перешел объект, использовав кнопку
State.



Ввести имя перехода, использовав кнопку.



Отразить при необходимости переход на себя кнопкой Transition

To
Self.



Спецификация состояния.



Параметры действия.



Скрытие вложенных состояний.


3.

Лабораторные з
адания
.

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

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


4. Контрольные вопросы.

1. Какую проблему призваны решить
диаграммы пакетов?

2. В чем отличия диаграмм пакетов от диаграмм классов?

53


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

4. Что такое интерфейс класса?

5. По каким признакам классы группируются в пакеты?



54


Библиографический список
.


1.

Проекти
рование информационных систем: Учебное пособие /
В.В. Коваленко.
-

М.: Форум: НИЦ ИНФРА
-
М, 2014.
-

320 с.

2.

Архитектура и проектирование программных систем:
Монография / С.В. Назаров.
-

М.: НИЦ Инфра
-
М, 2013.
-

351 с.

3.

Информационные технологии: разработка
информационных
моделей и систем: Учеб. пос. / А.В.Затонский
-

М.: ИЦ РИОР: НИЦ ИНФРА
-
М, 2014
-

344с.

4.

Леоненков, А. В. Самоучитель UML 2 / А.В. Леоненков.


СПб.:
БХВ
-
Петербург, 2007.


568 с.

5.

Разработка и эксплуатация автоматизированных
информационных систем: Учебное пособие / Л.Г. Гагарина.
-

М.: ИД
ФОРУМ: НИЦ Инфра
-
М, 2013.
-

384 с.

6.

Методологии и технологии системного проектирования
информационных систем: Учебник / Э.Р. Ипатова, Ю.В. Ипатов;
РАО.
-

М.:
Флинта: МПСИ, 2008.
-

256 с.

7.

Кватрани
,
Т
. Rational Rose 2000
и

UML.
Визуальное
моделирование [Электронный ресурс] ; Пер. с англ.
-

М.: ДМК Пресс, 2009.
-

176 с.

8.

Трофимов С.А. CASE
-
технологии: практическая работа в Rational
Rose. Изд. 2
-
е.


М.:
Бином
-
Пресс, 2002 г.
-

288 с.

9.

Беляев К.С.
Проектирование архитектур информационных
систем

: методические указания к лабораторным работам/ сост. К. С. Беляев.


Ульяновск : УлГТУ, 2010.


48 с.

10.

Степанов А.Г., Осипова Т.Ф. Информационные системы.
Использован
ие
CASE
-
средств при описании бизнес
-
процессов: методические
указания к лабораторным работам:
ГОУ ВПО
«
Санкт
-
Петербургский
государственный университет аэрокосмического приборостроения
»
, 2005.


43 с.


Приложенные файлы

  • pdf 1013121
    Размер файла: 751 kB Загрузок: 0

Добавить комментарий