close

Вход

Забыли?

вход по аккаунту

?

Лапшина М.Л. Архитектура современных информационных систем

код для вставкиСкачать
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ
ФЕДЕРАЦИИ
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ
ОБРАЗОВАТЕЛЬНОЕ
УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ
«ВОРОНЕЖСКИЙ ГОСУДАРСТВЕННЫЙ ЛЕСОТЕХНИЧЕСКИЙ
УНИВЕРСИТЕТ ИМЕНИ Г.Ф. МОРОЗОВА»
Кафедра вычислительной техники и информационных систем
АРХИТЕКТУРА СОВРЕМЕННЫХ
ИНФОРМАЦИОННЫХ СИСТЕМ
Методические указания к лабораторным работам
для студентов по направлению подготовки
09.04.02 – Информационные системы и
технологии
Воронеж 2016
УДК 004.43
Лапшина, М.Л.. Архитектура современных информационных систем
[Текст] : методические указания к лабораторным работам для студентов по
направлению подготовки 09.04.02 – Информационные системы и
технологии / М.Л. Лапшина, Д. Д. Лапшин; М-во образования и науки РФ,
ФГБОУ ВО «ВГЛТУ им. Г.Ф. МОРОЗОВА». – Воронеж, 2016. – 54 с.
СОДЕРЖАНИЕ
Введение ................................................................................................................... 4
Лабораторная работа №1. Установление требований ....................................... 10
Лабораторная работа № 2. Ознакомление с CASE-средством Rational Rose. 21
Лабораторная работа № 3. Создание модели вариантов использования ........ 28
Лабораторная работа № 4. Диаграммы классов................................................. 32
Лабораторная работа № 5. Диаграммы взаимодействия .................................. 38
Лабораторная работа № 6. Диаграммы состояния............................................. 43
Лабораторная работа № 7. Диаграммы активности........................................... 46
Лабораторная работа № 8. Диаграммы пакетов................................................. 50
Библиографический список. ................................................................................ 54
Введение
Разработка современной информационной системы состоит из трех
этапов: анализа, проектирования и реализации, в результате итеративного
выполнения которых происходит пошаговое «наращивание» системы.
На этапах анализа и проектирования происходит построение
архитектуры будущей информационной системы.
Архитектура программного обеспечения системы или набора систем
состоит из всех важных проектных решений по поводу структур программы
и взаимодействий между этими структурами, которые составляют системы.
Проектные решения обеспечивают желаемый набор свойств, которые должна
поддерживать система, чтобы быть успешной.
Проектные решения предоставляют концептуальную основу для
разработки системы, ее поддержки и обслуживания.
Моделирование предметной области является одним из наиболее
важных этапов работ при проектировании программных систем масштаба
предприятия. В настоящее время для целей моделирования предметной
области на рынке программных продуктов представлен широкий спектр
CASE-средств. Наиболее популярными в нашей стране CASE-средствами
являются Rational Rose, BPwin, Silverrun, Process Analyst.
Моделирование предметной области в этих средствах имеет скорее
много общего, чем различий. Основными задачами при моделировании
предметной области являются следующие описания:
– бизнес-процессов предприятия;
– действующих лиц бизнес-процессов и их функций, подлежащих
автоматизации в привязке к структуре автоматизируемого предприятия;
– бизнес-сущностей;
– сценариев выполнения бизнес-функций, подлежащих автоматизации;
– состояний бизнес-сущностей;
– бизнес-правил.
Описания бизнес-процессов используются для описания технологии
выполнения производственной задачи, подлежащей автоматизации. На
основе описанной технологии определяются виды деятельности, которые
следует автоматизировать (бизнес-требования к будущей программной
системе).
При описании бизнес-процессов должны быть выявлены связи между
различными подразделениями предприятия при решении конкретных
производственных задач (горизонтальные связи).
При описании предметной области не следует забывать о
моделировании бизнес-правил. Модели бизнес-правил предметной области
будут являться основой для моделирования правил программной системы.
Итак, подводя итог сказанному об описании предметной области при
разработке программных систем, отметим следующее:
1. Описание предметной области должно включать не только описание
бизнес-процессов, но и описание структуры автоматизируемого предприятия,
его действующих лиц, их автоматизируемых функций, документов,
связанных с автоматизированными функциями, прочих бизнес-сущностей,
сценариев реализации бизнес-функций и состояний бизнес-сущностей.
2. Модель бизнес-процессов используется для определения бизнестребований к разрабатываемой системе и выявления всех связей между
подразделениями, принимающими участие в решение конкретной задачи.
3. Модель структуры предприятия используется для отражения
действующих лиц предприятия, их автоматизируемых функций в привязке к
подразделениям, в которых эти функции выполняются. На основе модели
структуры предприятия разрабатывается модель функций системы.
4. Модели документов, бизнес-сущностей используются при
проектировании пользовательского интерфейса, базы данных, формирования
альбома выходных форм системы.
5. Модели сценариев реализации бизнес-функций используются при
проектировании сценариев пользовательского интерфейса.
6. Модели состояний бизнес-сущностей используются при
проектировании пользовательского интерфейса и базы данных системы.
7. Модели бизнес-правил используются при моделировании правил
программной системы.
Полное и детальное описание предметной области удобно производить
с помощью разнообразных CASE-средств.
Case-средства
Термин CASE – Computer Aided System/Software Engineering
используется при автоматизации процесса разработки сложных
информационных
систем
в
целом.
Появлению CASE-средств
предшествовали исследования в области методологии проектирования.
Методология определяет этапы и шаги реализации проекта, а также правила
использования методов, которыми разрабатывается проект. Метод – это
процедура или техника генерации описаний компонентов информационной
системы (проектирование потоков и структур данных). Нотация –
отображение структуры системы, элементов данных с помощью специальных
графических символов. CASE-средства – это специальные программы,
которые поддерживают одну или несколько методологий анализа и
проектирования информационных систем. CASE-технология, в рамках
методологии, включает в себя методы, с помощью которых на основе
нотаций строятся диаграммы, поддерживаемые конкретным CASEсредством. CASE-технологии не могут считаться самостоятельными, они
только обеспечивают высокую эффективность их применения.
Краткая характеристика
Современные CASE-средства охватывают обширную область
поддержки многочисленных технологий проектирования информационных
систем: от простых средств анализа и документирования до
полномасштабных средств автоматизации, покрывающих весь жизненный
цикл программного обеспечения. Наиболее трудоемкими этапами разработки
информационных систем являются этапы анализа и проектирования, в
процессе которых CASE-средства обеспечивают качество принимаемых
технических решений и подготовку проектной документации. При этом
большую роль играют методы визуального представления информации. Это
предполагает построение структурных или иных диаграмм в реальном
масштабе времени, использование многообразной цветовой палитры,
сквозную проверку синтаксических правил. Графические средства
моделирования предметной области позволяют разработчикам в наглядном
виде изучать существующую информационную систему, перестраивать ее в
соответствии с поставленными целями и имеющимися ограничениями.
Архитектура CASE-средств
Обычно к CASE-средствам относят любое программное средство,
автоматизирующее ту или иную совокупность процессов жизненного цикла
программного обеспечения и включающее в себя:
1. Репозиторий, являющийся основой CASE-средства. Он представляет
собой специализированную базу данных проекта, предназначенную для
отображения состояния проектируемой информационной системы в каждый
момент времени. Объекты всех диаграмм синхронизированы на основе
общей информации словаря данных. В репозитории хранятся описания
следующих объектов: проектировщиков и их прав доступа к различным
компонентам системы; организационных структур; диаграмм; компонентов
диаграмм; связей между диаграммами; структур данных; программных
модулей; процедур.
2. Графический редактор, обеспечивающий создание и редактирование
в заданной нотации и в интерактивном (диалоговом) режиме элементов
диаграмм, связей между ними, диаграмм. В любой момент времени они
могут быть распечатаны и включены в техническую документацию проекта.
3. Верификатор диаграмм (средство тестирования), служащее для
контроля правильности построения диаграмм в заданной методологии
проектирования. Его функции:
а) диагностика,
b) выдача сообщений об ошибках,
с) выделение на диаграмме ошибочных элементов.
4. Документатор проекта, позволяющий получать информацию о
проектах в виде отчетов. Отчеты могут строиться:
а) по времени,
b) автору,
с) элементам диаграмм,
d) диаграмме,
е) проекту в целом.
5. Администратор проекта, выполняющий следующие функции:
а) инициализация (запуск),
b) задание начальных параметров проекта,
с) назначение и изменение прав доступа к элементам проекта.
6. Сервис, представляющий собой набор системных утилит по
обслуживанию репозитория (архивация и восстановление данных, создание
нового репозитория).
На рисунке 1 показана архитектура CASE-средства в общем виде.
Рис.1. Архитектура CASE-средства
Используемые методологии
При
применении
CASE-средств
используются
методологии
структурного и объектно-ориентированного проектирования. Структурное
проектирование основано на алгоритмической декомпозиции, а объектноориентированное проектирование основано на объектно-ориентированной
декомпозиции. Разделение по алгоритмам концентрирует внимание на
порядке происходящих событий, а разделение по объектам придает особое
внимание
объектам
или
субъектам
действия.
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. Выполнить тестовый пример.
2. Получить индивидуальное задание.
3. Сдать отчет по заданию.
4. Ответить на вопросы.
Результаты выполнения работ
После выполнения лабораторной работы должен быть составлен отчет.
Содержание отчета:
1. Титульный лист.
2. Название и цель выполнения работы.
3. Описание своей задачи с перечислением того, что выполнено.
4. Письменные ответы на заданные вопросы.
Лабораторная работа №1. Установление требований.
1.
Цель лабораторной работы.
1.1. Целью лабораторной работы является получение навыков в
проведении анализа и сопровождения современных информационных
систем.
1.2. В результате выполнения лабораторной работы студенты должны
знать:
методы анализа информационных ресурсов;
методы разработки различных моделей данных;
методы конструирования программных модулей;
методы анализа проектных решений.
2.
Теоретический материал для домашнего изучения.
Получить задание у преподавателя для разработки информационной
системы (ИС). ИС должна представлять собой программный комплекс,
наделенный
функциональностью,
автоматизирующей
конкретную
деятельность в рамках предметной области, для которой разрабатывается
система. Примером таких систем могут служить:

автоматизированные системы управления (АСУ)


электронные магазины, аукционы
веб-порталы

сервисы
Составить документ описания требований к разрабатываемой ИС
согласно шаблону.
1. Установление требований
1.1 Документ описания требований
Документ, описывающий требования, является осязаемым результатом
этапа установления требований. Большинство организаций вырабатывает
документ описания требований в соответствии с заранее определенным
шаблоном. Шаблон определяет структуру (содержание) и стиль документа.
Ядро документа описания требований состоит из формулировок
(изложения) требований. Требования могут быть сгруппированы в виде
формулировок сервисов (зачастую называемых функциональными
требованиями) и формулировок ограничений. Формулировки сути сервисов
могут быть затем разделены на требования к функциям (function
requirements) и требования к данным (data requirements). (В литературе
термин «функциональные требования» (functional requirements) в широком и
в узком смысле используется как взаимозаменяемый. При использовании в
узком смысле он соответствует тому, что мы называем требованиями к
функциям).
Не говоря уже о самих требованиях, документ описания требований
должен обращаться к проектным вопросам. Обычно проектные вопросы
рассматриваются в начале документа, а затем в конце документа.
Во вводной части документа рассматривается бизнес-контекст проекта,
включая цель проекта, участников проекта и основные ограничения. Ближе к
заключительной части документа поднимаются другие проектные вопросы,
включая план-график выполнения проектных работ, бюджет, риски,
документацию и т. д.
1.2 Шаблоны документа
Шаблоны для документов описания требований широко доступны. Их
можно найти в учебниках, стандартах, выпускаемых такими организациями
как ISO, IEEE и т. д., на Web-страницах консалтинговых фирм, программных
средствах разработки и т. д. Со временем каждая организация разрабатывает
свои собственные стандарты, которые соответствуют принятой в
организации практике, корпоративной культуре, кругу читателей, типам
разрабатываемых систем и т. д.
Шаблон документа описания требований определяет структуру
документа и содержит подробные указания о содержании каждого из
разделов документа. Указания могут включать содержание вопросов,
мотивацию, примеры и дополнительные соображения.
На рис. 1 показано типичное оглавление документа описания
требований. Последующие разделы включают объяснение к приведенному
оглавлению.
1.3 Предварительные замечания к проекту
Часть документа описания требований, содержащая предварительные
замечания к проекту, преимущественно дает ориентиры тем руководителям и
участникам проекта, ответственным за принятие решений, которые,
вероятно, не станут подробно изучать документ целиком. В начале
документа необходимо ясно обозначить цели и рамки проекта, а затем
описать деловой контекст системы.
Документ описания требований должен создать прецедент для
системы. В частности, необходимо упомянуть обо всех усилиях,
приложенных для обоснования необходимости системы на этапе
планирования системы. Документ описания требований должен прояснить
вопрос о том, каким образом предлагаемая система может способствовать
достижению деловых целей и решению задач организацией.
Необходимо обозначить участников проекта системы. Важно, чтобы
заказчик выступал не в виде безликого подразделения или офиса —
необходимо привести конкретные имена.
Документ описания
требований Содержание
документа
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 Содержание документа описаний требований
Хотя документ описания требований может быть как угодно далек от
технических решений, все же важно обсудить идеи, касающиеся решения на
самых ранних этапах жизненного цикла (ЖЦ) разработки.
Документ описания требований должен предоставлять перечень
существующих программных пакетов и компонент, которые должны быть в
дальнейшем изучены в качестве вариантов возможных решений.
В заключение раздела предварительных замечаний к
проекту
документа описания требований необходимо привести обзор оставшейся
части документа. Это может подтолкнуть к тому, чтобы изучить остальные
части документа, а также способствует лучшему пониманию содержания
документа. Обзор также может содержать пояснения в отношении
методологии анализа проектирования, выбранной разработчиками.
1.4 Системные сервисы
Основная часть документа описания требований посвящена
определению системных сервисов. Эта часть может занимать до половины
всего объема документа. Это также, пожалуй, единственная часть документа,
которая может содержать обобщенные модели — модели бизнес-требований.
Рамки системы можно моделировать с помощью диаграммы контекста.
В пояснениях к диаграмме контекста должны быть четко определены рамки
системы. Без подобного определения проект не может быть застрахован от
попыток «растянуть» его рамки.
Функциональные требования можно моделировать с помощью
диаграммы бизнес-прецедентов. Однако диаграмма охватывает перечень
функциональных требований только в самом общем виде. Все требования
необходимо обозначить, классифицировать и определить.
Требования к данным можно моделировать с помощью диаграммы
бизнес-классов. Так же, как и в случае функциональных требований,
диаграмма бизнес-классов не дает полного определения структур данных для
бизнес-процессов. Каждый бизнес-класс требует дальнейших пояснений.
Необходимо описать атрибутное наполнение классов и определить
идентифицирующие атрибуты классов. В противном случае невозможно
правильно представить ассоциации.
1.5 Системные ограничения
Системные сервисы определяют, что должна делать система.
Системные ограничения определяют, насколько система ограничена при
выполнении обслуживания. Системные ограничения связаны со следующими
видами требований.

Требования к интерфейсу.



Требования к производительности.
Требования к безопасности.
Эксплуатационные требования.

Политические и юридические требования.
Требования к интерфейсу определяют, как система взаимодействует с
пользователями. В документе описания требований определяется только
«впечатление и ощущение» от GUI-интерфейса.
Начальное проектирование (закрашивание экрана) GUI-интерфейса
проводится во время спецификации требований и позже во время системного
проектирования.
В
зависимости
от
области
приложения
требования
к
производительности могут играть довольно значительную роль в успехе
проекта. В узком смысле они задают скорость (время отклика системы), с
которой должны выполняться различные задания. В широком смысле,
требования к производительности включают другие ограничения — в
отношении надежности, готовности, пропускной способности и т. д.
Требования к безопасности описывают пользовательские права доступа
к информации, контролируемые системой. Пользователям может быть
предоставлен ограниченный доступ к данным или ограниченные права на
выполнение определенных операций с данными.
Эксплуатационные требования определяют программно-техническую
среду, если она известна на этапе проектирования, в которой должна
функционировать система. Эти требования могут оказывать влияние на
другие стороны проекта, такие как подготовка пользователей и
сопровождение системы.
Политические требования и юридические требования скорее
подразумеваются, чем явно формулируются в документе описания
требований. Подобная ошибка может обойтись очень дорого. Пока эти
требования не выведены явно, программный продукт может быть трудно
развернуть по политическим или юридическим причинам.
Возможны и другие виды ограничений. Например, в отношении
некоторых систем могут предъявляться повышенные требования к легкости
их использования (требования в отношении пригодности к использованию)
или легкости их сопровождения (требования в отношении пригодности к
сопровождению).
Значение выработки недвусмысленных определений для системных
ограничений трудно переоценить. Существует немало примеров проектов,
которые провалились из-за упущенных или неверно понятых ограничений.
Эта проблема в равной мере относится как к заказчикам, так и к
разработчикам. Недобросовестные или нерассудительные разработчики
могут разыграть «карту системных ограничений», чтобы получить
преимущество в своем стремлении уклониться от ответственности.
1.6 Проектные вопросы
Заключительная часть документа описания требований обращается к
другим проектным вопросам. Один из важных разделов этой части
называется «Открытые вопросы».
Здесь поднимаются все вопросы, которые могут сказаться на успехе
проекта и которые не рассматривались в других разделах документа.
Сюда относится ожидаемое возрастание значения некоторых
требований, которые в текущий момент выходят за рамки проекта. Сюда
можно отнести также любые потенциальные проблемы и отклонения в
поведении системы, которые могут начаться в связи с развертыванием
системы.
В этой же части необходимо представить предварительный планграфик выполнения основных проектных заданий. Сюда же относится
предварительное распределение людских и других ресурсов. Для выработки
стандартных плановых графиков можно использовать программные средства
управления проектами, например, такие как система PERT (program
evaluation_and_review technique — метод оценки и пересмотра планов) или
карты Ганта.
Прямым результатом составления план-графика может быть разработка
предварительного бюджета. Стоимость проекта может быть выражена скорее
в виде диапазона значений затрат, а не конкретного значения. При наличии
надлежащим образом документированных требований для оценки затрат
можно использовать один из подходящих методов.
1.7 Приложения
Приложения содержат остальную, полезную для понимания
требований, информацию. Основным добавлением здесь служит глоссарий.
Глоссарий определяет термины, сокращения и аббревиатуры, используемые в
документе описания требований. Значение толкового глоссария трудно
переоценить. Неверное истолкование терминологии таит в себе большую
опасность для проекта.
Одна из особенностей, которую часто упускают из виду при
составлении документа описания требований, состоит в том, что в
проблемной области, определяемой документом, можно довольно неплохо
разобраться с помощью изучения документов и форм, используемых в
процессах делопроизводства. При возможности следует включать в документ
заполненные формы — «пустые» формы не дают такого же уровня
понимания бизнес-процессов.
Раздел ссылок содержит перечень документов, которые упоминаются
или используются при подготовке документа описания требований. К ним
могут относиться книги и другие опубликованные источники информации,
но — что, пожалуй, даже более важно — необходимо также упомянуть
протоколы совещаний, служебные записки и внутренние документы.
Пример документа описания требований
Документ описания требований ИС «Домашняя бухгалтерия»
1. Предварительные замечания к проекту
1.1. Цели и рамки проекта
Целью данного проекта является разработка информационной системы
для ведения и оптимизации семейного бюджета.
ИС «Домашняя бухгалтерия» должна быть проста в использовании и не
требовать от пользователя знаний бухгалтерского учета.
1.2. Деловой контекст
Многие семьи в наше время планируют семейный бюджет. Ведение
семейного бюджета при помощи подручных средств – карандаш, бумага – не
всегда удобно и всегда трудоемко. Использование для этих целей
компьютерных программ для ведения бухгалтерии не оправдано с точки
зрения сложности их освоения и избыточного функционала для ведения
домашней бухгалтерии. В связи с этим возникает необходимость создания
специализированной программы ведения домашней бухгалтерии.
1.3. Участники проекта
Заказчик – Васильева Марья Федоровна (m.vasileva@mypochta.ru)
Разработчик – Петров Степан Николаевич (petrov@coolsoft.com)
1.4. Идеи в отношении решений
Программа должна быть реализована в виде настольного приложения
для операционных систем семейств MS Windows.
1.5. Обзор документа
В разделе «Системные сервисы» описывается, что должна делать
система. В разделе «Системные ограничения» определяется, насколько
система ограничена при выполнении обслуживания.
В разделе «Проектные вопросы» освещаются прочие проектные
вопросы.
2. Системные сервисы
2.1. Рамки системы
Рамки системы можно моделировать с помощью диаграммы контекста.
Рис.2 Контекстная диаграмма ИС «Домашняя Бухгалтерия»
ИС «Домашняя Бухгалтерия» получает данные о доходах и расходах от
внешней сущности «Домохозяин». Для передачи этих данных сущности
«Домохозяин» должен авторизоваться. В своей работе сущность «Домашняя
Бухгалтерия» использует информацию о ценах на товары и тарифах и курсах
валют, получаемую от внешних сущностей «База тарифов и цен на товары» и
«База курса валют». Результаты своей работы ИС «Домашняя Бухгалтерия»
может отображать как внешней сущности «Домохозяин», так и генерировать
в виде отчетов формата MS Excel для внешней сущности «MS Excel».
2.2. Функциональные требования
ИС должна обеспечивать следующие функциональные возможности:

учет расходов;


учет доходов;
учет денег, отданных и взятых в долг;


погашение долгов частями;
проценты по долгам;


контроль возврата долгов;
система напоминания по долгам;

составление бюджета расходов и доходов;


планирование расходов;
планирование доходов;


система счетов;
возможность использовать до пяти валют включительно;


получение курсов валют из интернет;
обмен валют;


импорт данных из файлов Microsoft Excel;
поиск по базе данных;


фильтры и быстрый поиск по базе данных;
экспорт данных в Excel, XML, текстовый файл;



перенос данных;
резервное копирование;
печать данных;

построение отчетов и диаграмм;

настройка пользовательского интерфейса.
2.3. Требования к данным
ИС должна хранить свои данные в специализированных XML-файлах.
3. Системные ограничения
3.1. Требования к интерфейсу
ИС должна иметь стандартный интерфейс приложений, разработанных
для ОС MS Windows.
3.2. Требования к производительности
Особых требований к производительности ИС нет.
3.3. Требования к безопасности
С программой могут работать несколько человек, входя в программу
под своими именами. Для обеспечения конфиденциальности каждое имя
можно защитить паролем.
Добавление, изменение и удаление пользователей осуществляется в
администраторе пользователей.
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-средством Rational
Rose.
1. Цель лабораторной работы.
1.1.
Целью лабораторной работы является
изучение
интерфейса Rational Rose и принципы работы с ним.
1.2.
В результате выполнения лабораторной работы студенты
должны знать:
назначение программного продукта и его возможности;
принципы работы с программным продуктом;
структуру и функции Rational Rose.
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 лежит построение различного рода
диаграмм и спецификаций, определяющих логическую и физическую
структуры модели, ее статические и динамические аспекты. В их число
входят диаграммы классов, состояний, сценариев, модулей, процессов.В
составе Rational Rose можно выделить 6 основных структурных компонент:
– репозиторий,
– графический интерфейс пользователя,
– средства просмотра проекта (browser),
– средства контроля проекта,
– средства сбора статистики
– генератор документов.
К ним добавляются генератор кодов (индивидуальный для каждого
языка) и анализатор для С++, обеспечивающий реинжиниринг –
восстановление модели проекта по исходным текстам программ.
Репозиторий представляет собой объектно-ориентированную базу данных.
Средства просмотра обеспечивают "навигацию" по проекту, в том
числе: перемещение по иерархиям классов и подсистем, переключение от
одного вида диаграмм к другому и т. д. Средства контроля и сбора
статистики дают возможность находить и устранять ошибки по мере
развития проекта, а не после завершения его описания. Генератор отчетов
формирует тексты выходных документов на основе содержащейся в
репозитории информации. Средства автоматической генерации кодов
программ на языке С++, используя информацию, содержащуюся в
логической и физической моделях проекта, формируют файлы заголовков и
файлы описаний классов и объектов. Создаваемый таким образом скелет
программы может быть уточнен путем прямого программирования на языке
С++. Анализатор кодов С++ реализован в виде отдельного программного
модуля. Его назначение состоит в том, чтобы создавать модули проектов в
форме Rational Rose на основе информации, содержащейся в определяемых
пользователем исходных текстах на С++. В процессе работы анализатор
осуществляет контроль правильности исходных текстов и диагностику
ошибок.
Модель, полученная в результате его работы, может целиком или
фрагментарно использоваться в различных проектах. Анализатор обладает
широкими возможностями настройки по входу и выходу. Например, можно
определить типы исходных файлов, базовый компилятор, задать, какая
информация должна быть включена в формируемую модель и какие
элементы выходной модели следует выводить на экран.
Таким образом, Rational Rose/С++ обеспечивает возможность
повторного использования программных компонент.
В результате разработки проекта с помощью CASE-средства Rational
Rose формируются следующие документы:
– диаграммы классов;
– диаграммы состояний;
– диаграммы сценариев;
– диаграммы модулей;
– диаграммы процессов;
– спецификации классов, объектов, атрибутов и операций;
– заготовки текстов программ;
– модель разрабатываемой программной системы.
Последний из перечисленных документов является текстовым файлом,
содержащим всю необходимую информацию о проекте (в том числе
необходимую для получения всех диаграмм и спецификаций).
Взаимодействие с другими средствами и организация групповой
работы Rational Rose интегрируется со средством PVCS для организации
групповой работы и управления проектом и со средством SoDA – для
документирования проектов. Интеграция Rational Rose и SoDA
обеспечивается средствами SoDA. Для организации групповой работы в
Rational Rose возможно разбиение модели на управляемые подмодели.
Каждая из них независимо сохраняется на диске или загружается в модель. В
качестве подмодели может выступать категория классов или подсистема. Для
управляемой подмодели предусмотрены операции:
– загрузка подмодели в память;
– выгрузка подмодели из памяти;
– сохранение подмодели на диске в виде отдельного файла;
– установка защиты от модификации;
– замена подмодели в памяти на новую.
Наиболее эффективно групповая работа организуется при интеграции
Rational Rose со специальными средствами управления конфигурацией и
контроля версий (PVCS). В этом случае защита от модификации
устанавливается на все управляемые подмодели, кроме тех, которые
выделены конкретному разработчику. В этом случае признак защиты от
записи устанавливается для файлов, которые содержат подмодели, поэтому
при считывании "чужих" подмоделей защита их от модификации сохраняется
и случайные воздействия окажутся невозможными.
Среда функционирования
Rational Rose функционирует на различных платформах: IBM PC (в
среде Windows), Sun SPARC stations (UNIX, Solaris, SunOS), HewlettPackard
(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. Найти в программах Rational Rose Enterprise Edition и выбрать
Rational Rose Enterprise Edition (рис. 1).
Рис. 1 Меню запуска программы
3. Запустить программу.
4. Программа загрузится и появится окно с набором стандартных
проектов. Нажать на Cancel (рис. 2).
Рис. 2 Окно выбора проекта
Ознакомление с интерфейсом
CASE – средство Rational Rose имеет простой и понятный
пользовательский интерфейс для построения требуемых логических и
физических моделей данных. Он зависит от используемой технологии. В
любом случае при запуске средства моделирования появляются:
– меню;
– основная панель инструментов;
– панель специальных инструментов;
– навигатор моделей.
Рис. 3 Окно пакета при запуске
Основная панель инструментов содержит следующие главные кнопки:
– создание новой модели;
– открытие имеющейся модели;
– сохранение построенной модели;
– копирование модели;
– печать модели;
– масштабирование.
Навигатор модели показывает состав модели по уровням разработки. С
его помощью можно легко и быстро переходить от одной модели к другой.
Работа с навигатором модели аналогична работе с Проводником системы
Windows. Навигатор поддерживает четыре представления:
– использования;
– логическое;
– компонентов;
– размещения.
Панель специальных инструментов содержит основные кнопки для
создания выбранной диаграммы, например для построения диаграммы
прецедентов представления использования:
– создание субъекта;
– создание аспекта;
– создание ассоциации субъектов и аспектов;
– создание обобщения;
Для логического представления:
– создание класса;
– создание ассоциации классов.
Окно модели является местом создания логической или физической
модели данных исследуемой системы.
3.
Лабораторные задания.
1. Запустить Rational Rose.
2. Посмотреть навигацию по проекту.
3. Создать любой элемент, дать ему название и комментарий к нему.
4. Сохранить проект.
4. Контрольные вопросы.
1. Что такое Rational Rose?
2. Опишите окно приложения и основные функции меню.
3. Что такое навигатор?
4. Назовите назначение специальной панели инструментов.
Лабораторная работа № 3. Создание модели вариантов использования
1.
Цель лабораторной работы.
1.1. Целью лабораторной работы является ознакомление с созданием
функциональной модели использования.
1.2. В результате выполнения лабораторной работы студенты должны
знать:
нотации, применяемые при построении диаграмм;
применение диаграмм в процессе постановки задачи;
основные элементы диаграммы вариантов использования.
2.
Теоретический материал для домашнего изучения.
Моделирование в Ration Rose проводится как спуск от концептуальной
модели к логической, а затем к физической модели программной системы.
Концептуальная модель выражается в виде диаграмм вариантов
использования (Use – case diagram). Этот тип диаграмм служит для
проведения итерационного цикла общей постановки задачи вместе с
заказчиком.
Вариант использования представляет собой последовательность
действий, выполняемых системой в ответ на событие, инициируемое
некоторым внешним объектом (действующим лицом).
Вариант
использования описывает типичное взаимодействие между пользователем и
системой. В простейшем случае вариант использования определяется в
процессе обсуждения с пользователем тех функций, которые он хотел
реализовать. Эти диаграммы служат основой для достижения
взаимопонимания
между
программистами-профессионалами,
разрабатывающими проект, и заказчиками проекта.
Внутри каждого варианта использования (прецедента) могут быть
определены:
– вложенная диаграмма использования,
– диаграмма взаимодействия объектов,
– диаграмма последовательности взаимодействия,
– диаграмма классов,
– диаграмма перехода состояния.
Действующее лицо (Actor) – это роль, которую пользователь играет по
отношению к системе. Действующие лица представляют собой роли, а не
конкретных людей или наименования работ. Действующее лицо может быть
внешней системой, которой необходима информация от данной системы. На
рис. 2 приводится вариант использования, описывающий одну из функций
системы управления проектами – обратную связь между менеджером проекта
и исполнителем.
Нотации представления использования (диаграмма прецедентов)
Каждое представление строится из диаграмм, которые используют свои
нотации (обозначения). Для представления использования применяются
следующие нотации:
– субъект как внешняя сущность, взаимодействующая с системой;
им может быть и человек, и устройство, и другая система;
–
аспект
использования
предоставляемое системой;
как
определенное
средство,
– односторонняя ассоциация, как взаимодействие, направленное
от одного субъекта или аспекта к другим;
– обобщение от одного субъекта или аспекта к другому;
Примеры обобщения показаны на рис. 1. Это сильный инструмент
построения диаграмм. Так, один клиент, другой клиент обслуживающей
фирмы обобщаются в клиента фирмы.
Рис. 1. Обобщения аспектов и субъектов
Пример выполнения задания
Менеджер модифицирует план, назначает ресурс и получает отчеты от
исполнителей, сотрудников и субподрядчиков проекта. Информационную
систему назовем "Управление проектами". На рис. 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. Нажать кнопку создания ассоциации.
b. Нарисовать стрелку от одного элемента диаграммы прецедентов к
другому.
c. Отрегулировать размещение элементов диаграммы прецедентов.
3. Лабораторные задания.
Построить диаграмму прецедентов по разработанному техническому
заданию.
1. Присвоить имя диаграмме согласно предметной области и решаемой
задаче.
2. Определить субъектов (актеров) и прецедентов и присвоить им
имена согласно предметной области.
3. Определить ассоциации между ними.
4. Построить обобщения между субъектами и прецедентами.
4. Контрольные вопросы.
1. В чем смысл варианта использования?
2. Назначение вариантов использования.
3. Назовите основные компоненты диаграмм вариантов использования.
4. Что такое действующее лицо?
5. Какую роль могут играть действующие лица по отношению к
варианту использования?
6. Назначение обобщения.
7. Аспект в диаграмме прецедентов.
Лабораторная работа № 4. Диаграммы классов
1.
Цель лабораторной работы.
1.1. Целью лабораторной работы является ознакомление с созданием
логической модели информационной системы.
1.2. В результате выполнения лабораторной работы студенты должны
знать:
нотации диаграммы классов;
применение диаграммы классов в процессе объектноориентированного анализа и проектирования.
2.
Теоретический материал для домашнего изучения.
Диаграммы классов являются центральным звеном методологии
объектно-ориентированного анализа и проектирования. Диаграмма класса
показывает классы и их отношения, тем самым представляя логический
аспект проекта. На стадии анализа диаграммы классов используются, чтобы
выделить общие роли и обязанности объектов (сущностей), обеспечивающих
требуемое поведение системы, на стадии проектирования – чтобы передать
структуру классов, формирующих архитектуру системы. Каждый класс
должен иметь имя. Имя каждого класса должно быть уникально в
содержащем его проекте. Диаграмма классов определяет этапы объектов
системы и различные статистические связи, которые существует между
ними. Имеется два основных вида статистических связей:
– ассоциации (например, менеджер может вести несколько проектов);
– подтипы (работник является разновидностью личности).
На диаграммах классов также изображаются атрибуты классов,
операции и ограничения, которые накладываются на связи между объектами.
Ассоциации представляют собой связи между экземплярами классов
(личность работает в компании, компания имеет ряд офисов). Любая
ассоциация обладает двумя ролями. Например (рис. 1) – ассоциация между
Исполнителем и Отчетом содержит две роли: одна от Исполнителя к Отчету;
другая – от Отчета к Исполнителю. Роль также обладает множественностью.
Пример – символ "0..*" над ассоциацией между Менеджером и Контрактом
показывает, что с одним Менеджером связано много Контрактов. 0
–
показывает, что Менеджер может не управлять контрактом; 1 – показывает,
что любой Контракт может управляться только одним Менеджером.
Для ассоциации может указываться направление навигации, если
направление не указывается, то ассоциация двунаправленная или ее
направление неизвестно.
Атрибуты во многом подобны ассоциациям. Разница между ними
заключается в том, что атрибуты предполагают единственное направление
навигации – от типа к атрибуту. На рисунке указаны атрибуты для классов
Контракт и Отчет. В зависимости от степени детализации диаграммы
обозначение атрибута может включать имя атрибута, тип и значение,
присваемое по умолчанию. В синтаксисе UML атрибут обозначен: <признак
видимости> <имя>: <тип> = <значение по умолчанию>. Признак видимости
может принимать следующие значения:
– общий (public) – атрибут общий, доступен для всех классов клиентов;
– защищенный (protected) – атрибут защищенный, доступен только для
подклассов и друзей класса;
– секретный (private) – атрибут собственный, доступен только для
друзей класса;
– реализация (implementation) – атрибут внедренный, доступен внутри
обрамляющего пакета.
Операции представляют процессы, реализуемые классом. Существует
соответствие между операциями и методами над классом. На рис. 3
приведены операции над классом Контракт Закрыть (), над классом Отчет –
Добавить().
Нотации логического представления (диаграммы классов)
– класс А с известным ключом, набором атрибутов и
операциями над объектами,
– ассоциация между классами с обозначением возможных
видов связи:
i. m {1, n, 0..1, 0..*, 1..*},
ii. k{1, n, 0..1, *, 0..*, 1..*}.
Примечание: Первый атрибут в структуре реляционной таблицы имеет
характеристику Ключ, что означает однозначное определение объекта в
классе.
Пример. Диаграмма классов "Управление проектами". Статическая
модель. Все данные о проекте можно свести в реляционную модель.
Объекты сведены в классы, классы описываются атрибутами. Каждый
класс имеет свое поведение по отношению к выполнению проекта.
Рис. 1. Диаграмма классов. Управление проектами
После создания диаграммы классов в диаграмме прецедентов к
субъектам, используемым диаграммой классов, будут добавлены параметры
класса.
Рис. 2. Диаграмма прецедентов после создания диаграммы классов
Технология выполнения работы
Технологический процесс создания диаграммы классов
1. Подготовка:
a. В навигаторе модели открыть Logical View.
b. Там же открыть Main.
c. Дать имя диаграмме классов.
i. В контекстном меню для Main выбрать команду Rename.
ii. Ввести имя диаграммы классов.
2. Создание класса:
a. Нажать кнопку создания класса.
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, убрав
"галочку".
3. Лабораторные задания.
Построить диаграмму классов для представления использования
варианта лабораторной работы 2.
1. Определить объекты (сущности), привязав их к диаграмме
прецедентов.
a. Дать имя классу для однотипной группы объектов, например
объекты Менеджеры можно поместить в класс Менеджер.
b. Назначить атрибут – ключ (идентификатор объекта), например для
объекта Менеджер – это может быть Код менеджера.
c. Указать основную операцию над классом, например для класса
Менеджер – Добавить().
2. Построить отношения между классами на основе ассоциаций
a. Определить направление и множественность, указав нижние и
верхние границы.
4. Контрольные вопросы.
1. Назначение диаграммы классов.
2. Для чего используется диаграмма классов на стадии анализа?
3. Назовите основные компоненты диаграммы классов.
4. Что собой представляет ассоциация?
5. В чем смысл множественной ассоциации?
6. Как описывается класс?
7. Значение характеристики атрибута ключ.
8. Что входит в описание атрибута?
9. Что такое признак видимости?
10. Что представляет собой операция класса?
Лабораторная работа № 5. Диаграммы взаимодействия
1.
Цель лабораторной работы.
1.1. Целью лабораторной работы является ознакомление с созданием
моделей, описывающих поведение взаимодействующих групп объектов.
1.2. В результате выполнения лабораторной работы студенты должны
знать:
нотации,
применяемые
при
построении
диаграмм
взаимодействия;
применение диаграмм взаимодействия в процессе объектноориентированного анализа и проектирования.
2.
Теоретический материал для домашнего изучения.
Диаграммы взаимодействия являются моделями, описывающими
поведение взаимодействующих групп объектов. Как правило, диаграмма
взаимодействия
охватывает
поведение
только
одного
варианта
использования. На такой диаграмме отображается ряд объектов и те
сообщения, которыми они обмениваются между собой в рамках одного
варианта использования.
Пример. Управление проектами (рис. 1)
– Менеджер обдумывает поручение отчета исполнителю;
– дает указания на создание Отчета Исполнителю;
– если Отчет неудовлетворительный, Менеджер посылает
– запрос Исполнителю на обновление Отчета;
– Исполнитель создает новый Отчет;
– Менеджер делает повторный запрос Отчета.
Существует два вида диаграмм взаимодействия: диаграммы
последовательности
(sequence
diagrams)
и
кооперативные,
или
сотрудничества (collaboration diagrams).
Диаграммы
последовательности
определяют
временную
последовательность передаваемых сообщений, порядок, вид и тип
сообщения, происходящих в рамках варианта использования. Диаграммы
последовательности и кооперативные являются разными взглядами на одни и
те же процессы, поэтому Rational Rose позволяет создать из диаграммы
последовательности диаграмму Кооперации и наоборот, а также производит
автоматическую синхронизацию этих диаграмм.
На диаграмме последовательности взаимодействие изображается в
виде двумерной схемы: вертикальное (время) и горизонтальное (объекты,
участвующие во взаимодействии). Существенна только последовательность
сообщений, однако временная ось может служить реальной метрикой
измерения активности объекта.
– Действующие лица из варианта использования.
– Объекты, требуемые системе для выполнения варианта
использования.
– Линии жизни, представляющие фрагмент жизненного цикла объекта
в процессе взаимодействия, где течение времени идет сверху вниз, идут
сверху.
– Активный период линии жизни.
– Сообщение, передающееся от одного объекта к другому в порядке
следования жизненного цикла, при желании может быть помечено именем и
аргументом, управляющим событием, например, сообщение посылается,
если Отчет не устарел.
– Самоделегирование (рекурсивное сообщение) – сообщение самому
себе.
На кооперативной диаграмме экземпляры объектов показаны в виде
пиктограмм. Линии между ними обозначают сообщения, обмен которыми
осуществляется в рамках данного варианта использования. Каждый вид
диаграмм имеет свои преимущества. На диаграмме последовательности легче
наблюдать порядок, в котором происходят события.
В
случае
кооперативных
диаграмм
можно
использовать
пространственное расположение объектов, чтобы показать их статическое
взаимодействие.
Нотации диаграммы последовательности
Изображение диаграммы в виде двумерной схемы
Пример. Последовательность действий и кооперация между объектами
при создании отчета «Управление проектами».
Рис. 1. Диаграмма последовательности создания отчета «Управление
проектами»
Рис. 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 Interaction Diagram выбрать тип диаграммы
sequence, нажать ОК.
2. Создание объекта:
a. Нажать кнопку создания объекта.
b. В окне диаграммы классов указать место объекта.
c. Щелчком вызвать изображение объекта и соответствующей ему линии
жизни.
d. Через контекстное меню открыть окно Object Specification и ввести имя
объекта и соответствующий ему класс.
3. Создание сообщения:
a. Нажать кнопку создания сообщения Object Message.
b. Нарисовать стрелку от линии одного объекта к линии жизни другого
объекта
c. Отрегулировать размещение элементов диаграммы прецедентов.
4. Построение соответствующей диаграммы кооперации:
a. Нажать функциональную клавишу F5.
b. Изменить сообщение, вызвав закладку Messages.
3. Лабораторные задания.
Построить диаграмму последовательности на основе диаграмм классов
и диаграммы представления использования, разработанных на предыдущих
занятиях
1. Дать имя диаграмме.
2. Определить объекты, привязав их к диаграмме классов и
прецедентов.
3. Создать их линии жизни.
4. Установить сообщения между объектами.
5. Присвоить имена сообщениям.
4. Контрольные вопросы.
1. Назначение диаграммы взаимодействия.
2. Для чего используется диаграмма последовательности на стадии
анализа?
3. Назовите основные компоненты диаграммы последовательности.
4. Что собой представляет жизненная линия?
5. Как на диаграмме последовательности представляются сообщения?
6. Что такое самоделегирование?
7. Что показывает активизация объекта?
8. Как на диаграмме последовательности представляется уничтожение
объекта?
Лабораторная работа № 6. Диаграммы состояния
1.
Цель лабораторной работы.
1.1 Целью лабораторной работы является ознакомление с созданием
моделей, описывающих поведение взаимодействующих групп объектов.
1.2. В результате выполнения лабораторной работы студенты должны
знать:
нотации, применяемые при построении диаграмм состояния;
применение диаграмм состояния в процессе объектноориентированного анализа и проектирования.
2.
Теоретический материал для домашнего изучения.
Диаграммы состояния (Statechart) являются средством описания
поведения систем. Они определяют все известные состояния, в которых
может находиться объект, а также процесс смены состояния объекта в
результате влияния некоторых событий. Существуют два специальных
состояния – начальное (start) и конечное (stop). Начальное состояние –
состояние объекта, когда он только что создан, конечное – перед его
уничтожением. Начальное состояние может быть только одно, а конечных –
сколько вам нужно или вообще не быть. Процесс начинается с начальной
точки, а затем переходит в состояние. В поведении объекта в системе можно
выделить действия, отображаемые переходами, и деятельности,
отображаемые состояниями. Действия связаны с переходами и
рассматриваются как мгновенные и непрерываемые.
Деятельности связаны с состояниями и могут длиться достаточно
долго. Деятельность может быть прервана в результате наступления
некоторого события. Событие – это то, что вызывает переход из одного
состояния в другое.Переход может содержать метку. Метка перехода состоит
из трех частей, каждая из которых является необязательной ( < Событие>I
<Условие >I/<Действие >). Изображается на диаграмме вдоль линии
перехода после имени события. Условный переход. История состояния.
Диаграммы состояний хорошо использовать для описания поведения
некоторого объекта в нескольких различных вариантах использования, их не
надо создавать для каждого класса.
Нотации диаграммы состояния
Пример. Получение отчета. Управление проектами.
Рис. 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. Создание перехода и нового состояния:
– Отразить переход в другое состояние, использовав кнопку State
Transition.
– Отразить состояние, в которое перешел объект, использовав кнопку
State.
– Ввести имя перехода, использовав кнопку.
– Отразить при необходимости переход на себя кнопкой Transition To
Self.
– Спецификация состояния.
– Параметры действия.
– Скрытие вложенных состояний.
4. Создание завершения диаграммы:
– Отразить переход.
– Вызвать завершающее состояние объекта значком EndState.
3. Лабораторные задания.
Построить диаграмму состояния на основе диаграмм классов и
диаграммы представления использования, разработанных на предыдущих
занятиях.
1. Дать имя диаграмме.
2. Выбрать классы, для объектов которых будет строиться диаграмма
состояний.
3. Построить для каждого выбранного класса диаграмму состояний,
характеризующих поведение его объектов в нескольких вариантах
использования.
4. Контрольные вопросы.
1. Назначение диаграммы состояний.
2. Как отображаются действия и деятельности на диаграммах
состояния?
3. Что такое условный переход и как он описывается на диаграмме?
4. Какие особые состояния отображаются на диаграмме?
5. Что такое история состояния?
6. Что такое вложенные состояния и как их используют и создают?
7. В чем преимущества и недостатки диаграммы?
Лабораторная работа № 7. Диаграммы активности
1.
Цель лабораторной работы.
1.1. Целью лабораторной работы является ознакомление с созданием
моделей, описывающих поведение взаимодействующих групп объектов.
1.2. В результате выполнения лабораторной работы студенты должны
знать:
нотации, применяемые при построении диаграмм активности;
применение диаграмм активности в процессе объектноориентированного анализа и проектирования.
2.
Теоретический материал для домашнего изучения.
Этот тип диаграмм может использоваться для моделирования
различных типов действий. Например, финансовая компания может
использовать данный тип диаграмм для моделирования потоков финансовых
документов, прохождения оплаты счетов или заказов. Компания, создающая
программные продукты, отслеживать процесс разработки и создания
программного обеспечения. Диаграммы активности (Activity diagram) – это
специальная разновидность диаграмм состояния. Главное отличие между
диаграммами активности и состояния в том, что в первом случае основное –
действие, а во втором – статичное состояние.
Нотации диаграммы активности
Из набора значков состояний можно составить представление о всем
жизненном цикле объекта, у которого есть начало и конец действия работы
объекта. Нотации используются те же самые, что и при построении
диаграммы состояния, с дополнениями.
Добавляются:
– Activity – значок активности. Похож на значок состояния State,
который обозначает ожидание события, а значок Activity означает действие.
– Значки синхронизации.
– Decision – решение, позволяет показать зависимость от
внешних условий или решений (аналогичен If case в языках
программирования).
– 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.
– Соединить их связью и дать название связи.
– Перенести значки из созданной диаграммы состояний во вновь
созданную нажатием клавиши Ctrl.
– Установить дорожки для различных объектов.
Создание перехода и нового состояния:
– Отразить переход в другое состояние, использовав кнопку State
Transition.
– Отразить состояние, в которое перешел объект, использовав кнопку
State.
– Ввести имя перехода, использовав кнопку.
– Отразить при необходимости переход на себя кнопкой Transition To
Self.
– Спецификация состояния.
– Параметры действия.
– Скрытие вложенных состояний.
Настройка спецификаций:
– Отразить переход.
– Вызвать завершающее состояние объекта значком EndState.
Добавление решения.
Синхронизация процессов.
3. Лабораторные задания.
Построить диаграмму активности на основе диаграммы классов и
диаграммы состояния, разработанных на предыдущих занятиях.
1. Дать имя диаграмме.
2. Выбрать классы, для объектов которых будут строиться диаграммы
состояний.
Построить для выбранных классов диаграмму активности,
характеризующую алгоритм выполнения указанной работы.
4 Контрольные вопросы.
1. Для чего используется диаграмма активности?
2. Какие отличия между диаграммой активности и состояния?
3. Каков состав инструментов в диаграмме активности?
4. Для чего применяются дорожки?
5. Когда применяется элемент решения?
Лабораторная работа № 8. Диаграммы пакетов
1.
Цель лабораторной работы.
1.1. Целью лабораторной работы является ознакомление с созданием
диаграмм пакетов.
1.2. В результате выполнения лабораторной работы студенты должны
знать:
нотации, применяемые при построении диаграмм пакетов;
применение диаграмм пакетов в процессе объектноориентированного анализа и проектирования.
2.
Теоретический материал для домашнего изучения.
Важной задачей систематизации информации о предметной области
является разбиение большой системы на небольшие подсистемы. Именно
здесь особенно заметны структурные и объектно-ориентированные различия
между подходами. Одна из идей заключается в группировке классов в
компоненты более высокого уровня. В UML такой механизм группировки
носит название пакетов (package). Диаграммой пакетов является диаграмма,
содержащая пакеты классов и зависимости между ними. Строго говоря,
пакеты являются элементами диаграммы классов, т. е. диаграмма пакетов –
это всего лишь диаграмма классов. Отличаются эти диаграммы практическим
назначением и использованием. Зависимость между двумя элементами имеет
место в том случае, если изменения в определении одного элемента могут
повлечь изменения в другом.
Что касается классов, то причины зависимостей могут быть разными:
· один класс посылает сообщение другому;
· один класс включает часть данных другого класса;
· один класс ссылается на другой, как на параметр операции.
Если класс меняет свой интерфейс, то сообщение, которое он посылает,
может стать неправильным.
На рис. 1 показаны классы предметной области, возникающие при
моделировании деятельности менеджера по управлению проектами. Они
сгруппированы в пакеты: контракты, менеджеры, отчеты, исполнители.
Приложение Проект имеет связь с пакетами предметной области
Менеджеры, Отчеты, Контракты. Приложение Специалисты имеет связь с
Исполнителями, через которых можно узнать, какие отчеты они
подготовили.
Пакеты являются жизненно необходимыми для больших проектов.
Особенно когда диаграмма классов, охватывающая всю систему,
трудночитаемая. Пакеты не дают ответа на вопрос, каким образом можно
уменьшить количество зависимостей в разрабатываемой системе, они
помогают выделить эти зависимости. Пакеты полезны при тестировании
системы. Каждый пакет может содержать один или несколько тестируемых
классов, с помощью которых проверяется поведение пакета.
Нотации диаграммы пакетов
– Activity – значок активности. Похож на значок состояния State,
который обозначает ожидание события, а значок Activity означает действие.
– Значки синхронизации.
Пример. Получение отчета «Управление проектам».
Рис. 1. Диаграмма пакетов «Пользовательский интерфейс»
Технология выполнения работы
Технологический процесс создания диаграммы активности
Подготовка:
– В меню выбрать команду 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. В чем отличия диаграмм пакетов от диаграмм классов?
3. В чем смысл зависимости между элементами диаграммы пакетов?
4. Что такое интерфейс класса?
5. По каким признакам классы группируются в пакеты?
Библиографический список
Основная литература
1. Хорошевский В. Г. Архитектура вычислительных систем [Текст] : доп.
М-вом образования и науки Рос. Федерации в качестве учеб. пособия
для студентов высш. учеб. заведений / В. Г. Хорошевский. - Изд. 2-е,
перераб. и доп. - М. : МГТУ им. Н. Э. Баумана, 2008. - 520 с.
2. Голицына О. Л. Информационные системы [Электронный ресурс] : рек.
УМО вузов Рос. Федерации по образованию в обл. прикладной
информатики в качестве учеб. пособия для студентов высш. учеб.
заведений, обучающихся по специальности "Прикладная информатика
(по обл.)" / О. Л. Голицын, Н. В. Максимов, И. И. Попов. - М. :
ФОРУМ, 2009. - 496 с. - ЭБС "Знаниум".
Дополнительная литература
1. Трутнев Д. Р. Архитектуры информационных систем. Основы
проектирования [Электронный ресурс]: учеб. пособие / Д. Р. Трутнев. СПб.: НИУ ИТМО, 2012. - 66 с. - ЭБС "Единое окно".
2.Заботина Н.Н. Проектирование информационных систем [Электронный
ресурс]: рек.УМО по образованию в области прикладной информатики в
качестве учебного пособия / Н.Н. Заботина. - М.: НИЦ ИНФРА-М, 2014.
- 331 с. - ЭБС "Знаниум".
3.Желваков Б.Б. Архитектура корпоративных информационных систем
[Электронный ресурс]: Учебное пособие / Б. Б. Желваков. - СПб.:
СПбГИЭУ, 2012. - 622 с. - ЭБС "Единое окно".
Документ
Категория
Без категории
Просмотров
29
Размер файла
690 Кб
Теги
современные, лапшина, архитектура, информационные, система
1/--страниц
Пожаловаться на содержимое документа