close

Вход

Забыли?

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

?

Коровина О. В. Архитектура информационных систем (курсовая работа)

код для вставкиСкачать
Министерство образования и науки Российской Федерации
Федеральное государственное бюджетное образовательное учреждение
высшего профессионального образования
«Воронежская государственная лесотехническая академия»
АРХИТЕКТУРА ИНФОРМАЦИОННЫХ СИСТЕМ
Методические указания к выполнению курсовой работы
для студентов по направлению подготовки
230400 – Информационные системы и технологии
Воронеж 2014
2
УДК 004.43
Коровина, О. В. Архитектура информационных систем [Текст] :
методические указания к выполнению курсовой работы для студентов по
направлению подготовки 230400 – Информационные системы и технологии /
О. В. Коровина; М-во образования и науки РФ, ФГБОУ ВПО «ВГЛТА». –
Воронеж, 2014. – 32 с.
3
1.
Общие требования к выполнению курсовой работы.
Целью курсовой работы является закрепление и углубление
теоретических знаний об основных элементах определения и представления,
отработка навыков проектирования и моделирования программных систем с
помощью языка UML и оформления документации на разработку.
Выполнение
курсовой
работы
является
самостоятельной
исследовательской работой студента по заданной преподавателем тематике.
Курсовая работа выполняется студентом индивидуально в соответствии с
выданным преподавателем вариантом.
1.1. Порядок выполнения курсовой работы
Задание на
курсовую работу выдается каждому студенту
индивидуально в виде технического задания и темы курсовой работы.
В ходе выполнения работы студент должен:
1.
ознакомиться с темой задания и выполнить анализ предметной
области,
2.
провести анализ и проработать теоретический материал по
заданной теме,
3.
определить функциональные требования к системе,
4.
разработать диаграмму вариантов использования,
5.
разработать диаграмму деятельности,
6.
разработать диаграмму классов,
7.
оформить пояснительную записку,
8.
защитить курсовую работу.
Задание на курсовую работу выдается за 3 месяца до окончания
семестра. За 4 недели до окончания семестра курсовые работы сдаются
преподавателю на рецензию. Защита курсовых проектов производится в
конце семестра в течение 2-х недель (до начала зачетной недели) в виде
краткого доклада (5-8 минут), ответов на вопросы; при наличии технической
возможности рекомендуется использовать разработанное программное
обеспечение.
Курсовая работа выполняется в среде Rational Rose.
Курсовая работа оформляется в бумажном виде (формат А4) в
соответствии с требованиями Стандарта оформления студенческих работ
ВГЛТА.
Объем проекта должен составлять 20-25 страниц (одинарный интервал,
шрифт Times New Roman, размер 14 пт.) и включать следующие позиции:
4
Содержимое
титульный лист (МОиН РФ, вуз, факультет, кафедра, тема
курсовой работы, дисциплина, группа, Ф.И.О. студента,
Ф.И.О. преподавателя, год, город)
лист задания
содержание
введение
теоретическая часть
описание функциональных требований
описание диаграмм UML
описание диаграмм UML с учетом развития задачи
заключение
список использованных источников
Объем
(страниц)
1
1
1
1-2
5-6
3-5
1-3
1-3
1-2
1
Название разделов и подразделов должно соответствовать тематике
курсовой работы.
Содержание основных разделов пояснительной записки:

введение: цель курсового проектирования, краткие сведения по
теме, обзор литературных источников;

теоретическая часть:
описание
моделирования информационных систем;
принципов
проектирования,

описание требований к системе, функциональных возможностей,
участников проекта и основных ограничений;

описание разработки диаграмм вариантов использования, классов
и деятельности;

описание разработки диаграмм вариантов использования, классов
и деятельности с учетом развития задачи;

заключение: выводы по результатам работы.
Работу следует начинать с внимательной проработки теоретического
материала лекций. В качестве информационных источников следует
использовать основную и дополнительную литературу по дисциплине. Не
допускается использование готовых проектов из среды Интернет.
5
1.2. Методические указания
Унифицированный язык моделирования (Unified Modeling Language UML) это язык для специфицирования, визуализации, конструирования и
документирования программных систем, а так же бизнес моделей и прочих
не программных систем. UML представляет собой объединение инженерных
приемов, которые ранее успешно использовались при моделировании
больших и сложных систем
Создатели UML представляют его как язык для определения,
представления, проектирования и документирования программных систем,
бизнес-систем и других систем различной природы. UML определяет
нотацию и метамодель. Нотация представляет собой совокупность
графических объектов, которые используются в моделях; она является
синтаксисом языка моделирования.
UML предоставляет выразительные средства для создания визуальных
моделей, которые:

единообразно понимаются всеми разработчиками, вовлеченными
в проект;

являются средством коммуникации в рамках проекта.
Унифицированный Язык Моделирования (UML):

не зависит от объектно-ориентированных (ОО) языков
программирования;

не зависит от используемой методологии разработки проекта;

может поддерживать любой ОО язык программирования.
UML является открытым и обладает средствами расширения базового
ядра. На UML можно содержательно описывать классы, объекты и
компоненты в различных предметных областях, часто сильно отличающихся
друг от друга.
Диаграммы UML
Каждая из диаграмм UML конкретизирует различные представления о
модели системы. При этом, диаграмма вариантов использования
представляет концептуальную модель системы, которая является исходной
для построения всех остальных диаграмм. Диаграмма классов является
логической моделью, отражающей статические аспекты структурного
построения системы.
Для диаграмм языка UML существуют три типа визуальных
обозначений, которые важны с точки зрения заключенной в них информации:
6

связи,
которые
представляются
различными
линиями
на
плоскости;

текст, содержащийся внутри границ отдельных геометрических
фигур;
графические символы, изображаемые вблизи визуальных
элементов диаграмм.
При
графическом
изображении
диаграмм
рекомендуется
придерживаться следующих правил:

каждая диаграмма должна быть законченным представлением
некоторого фрагмента моделируемой предметной области;

представленные на диаграмме сущности модели должны быть
одного концептуального уровня;

вся информация о сущностях должна быть явно представлена на
диаграмме;

диаграммы не должны содержать противоречивой информации;

диаграммы не следует перегружать текстовой информацией;

каждая диаграмма должна быть самодостаточной для правильной
интерпретации всех ее элементов;

количество типов диаграмм, необходимых для описания
конкретной системы, не является строго фиксированным и определяется
разработчиком;

модели системы должны содержать только те элементы, которые
определены в нотации языка UML.
Сущности в UML
В UML определены четыре типа сущностей: структурные,
поведенческие, группирующие и аннотационные. Сущности являются
основными объектно-ориентированными элементами языка, с помощью
которых создаются модели.
Структурные сущности - это имена существительные в моделях на
языке UML. Как правило, они представляют статические части модели,
соответствующие концептуальным или физическим элементам системы.
Примерами структурных сущностей являются «класс», «интерфейс»,
«кооперация», «прецедент», «компонент», «узел», «актер».
Поведенческие сущности являются динамическими составляющими
модели UML. Это глаголы, которые описывают поведение модели во

7
времени и в пространстве. Существует два основных типа поведенческих
сущностей:

взаимодействие - это поведение, суть которого заключается в
обмене сообщениями между объектами в рамках конкретного контекста для
достижения определенной цели;

автомат
алгоритм
поведения,
определяющий
последовательность состояний, через которые объект или взаимодействие
проходят в ответ на различные события.
Группирующие сущности являются организующими частями модели
UML. Это блоки, на которые можно разложить модель. Такая первичная
сущность имеется в единственном экземпляре - это пакет.
Пакеты представляют собой универсальный механизм организации
элементов в группы. В пакет можно поместить структурные, поведенческие и
другие группирующие сущности. В отличие от компонентов, которые
реально существуют во время работы программы, пакеты носят чисто
концептуальный характер, то есть существуют только в процессе разработки.
Аннотационные сущности - это пояснительные части модели UML:
комментарии для дополнительного описания, разъяснения или замечания к
любому элементу модели. Имеется только один базовый тип аннотационных
элементов - примечание. Примечание используют, чтобы снабдить
диаграммы комментариями или ограничениями, выраженными в виде
неформального или формального текста.
Отношения в UML
В языке UML определены следующие типы отношений: зависимость,
ассоциация, обобщение и реализация . Эти отношения являются основными
связующими конструкциями UML и также как сущности применяются для
построения моделей.
Зависимость (dependency) - это семантическое отношение между двумя
сущностями, при котором изменение одной из них, независимой, может
повлиять на семантику другой, зависимой.
Ассоциация (association) - структурное отношение, описывающее
совокупность смысловых или логических связей между объектами.
Обобщение (generalization) - это отношение, при котором объект
специализированного элемента (потомок) может быть подставлен вместо
объекта обобщенного элемента (предка). При этом, в соответствии с
8
принципами объектно-ориентированного программирования, потомок (child)
наследует структуру и поведение своего предка (parent).
Реализация (realization) является семантическим отношением между
классификаторами, при котором один классификатор определяет
обязательство, а другой гарантирует его выполнение. Отношение реализации
встречаются в двух случаях:

между интерфейсами и реализующими их классами или
компонентами;

между прецедентами и реализующими их кооперациями.
Общие механизмы UML
Для точного описания системы в UML используются, так называемые,
общие механизмы:

спецификации (specifications);

дополнения (adornments);

деления (common divisions);

расширения (extensibility mechanisms).
UML является не только графическим языком. За каждым графическим
элементом его нотации стоит спецификация, содержащая текстовое
представление соответствующей конструкции языка. Например, пиктограмме
класса соответствует спецификация, которая описывает его атрибуты,
операции и поведение, хотя визуально, на диаграмме, пиктограмма часто
отражает только малую часть этой информации. Более того, в модели может
присутствовать другое представление этого класса, отражающее совершенно
иные его аспекты, но, тем не менее, соответствующее спецификации. Таким
образом, графическая нотация UML используются для визуализации
системы, а с помощью спецификаций описывают ее детали.
Практически каждый элемент UML имеет уникальное графическое
изображение, которое дает визуальное представление самых важных его
характеристик. Нотация сущности «класс» содержит его имя, атрибуты и
операции. Спецификация класса может содержать и другие детали,
например, видимость атрибутов и операций, комментарии или указание на
то, что класс является абстрактным. Многие из этих деталей можно
визуализировать в виде графических или текстовых дополнений к
стандартному прямоугольнику, который изображает класс.
При моделировании объектно-ориентированных систем существует
определенное деление представляемых сущностей.
9
Во-первых, существует деление на классы и объекты. Класс - это
абстракция, а объект - конкретное воплощение этой абстракции. В связи с
этим, практически все конструкции языка характеризуются двойственностью
«класс/объект». Так, имеются прецеденты и экземпляры прецедентов,
компоненты и экземпляры компонентов, узлы и экземпляры узлов. В
графическом представлении для объекта принято использовать тот же
символ, что и для класса, а название подчеркивать.
Во-вторых, существует деление на интерфейс и его реализацию.
Интерфейс декларирует обязательства, а реализация представляет
конкретное воплощение этих обязательств и обеспечивает точное следование
объявленной семантике. В связи с этим, почти все конструкции UML
характеризуются двойственностью «интерфейс/реализация». Например,
прецеденты реализуются кооперациями, а операции - методами.
UML является открытым языком, то есть допускает контролируемые
расширения, чтобы отразить особенности моделей предметных областей.
Механизмы расширения UML включают:

стереотипы (stereotype) - расширяют словарь UML, позволяя на
основе существующих элементов языка создавать новые, ориентированные
для решения конкретной проблемы;

помеченные значения (tagged value) - расширяют свойства
основных конструкций UML, позволяя включать дополнительную
информацию в спецификацию элемента;

ограничения (constraints) - расширяют семантику конструкций
UML, позволяя создавать новые и отменять существующие правила.
Совместно эти три механизма расширения языка позволяют
модифицировать его в соответствии с потребностями проекта или
особенностями технологии разработки.
Диаграмма вариантов использования (use case diagram)
Этот вид диаграмм позволяет создать список операций, которые
выполняет система. Часто этот вид диаграмм называют диаграммой функций,
потому что на основе набора таких диаграмм создается список требований к
системе и определяется множество выполняемых системой функций.
10
Рис.1. Диаграмма вариантов использования банкомата
Диаграммы вариантов использования описывают функциональное
назначение системы или то, что система должна делать. Разработка
диаграммы преследует следующие цели:

определить общие границы и контекст моделируемой
предметной области;

сформулировать общие требования к функциональному
поведению проектируемой системы;

разработать исходную концептуальную модель системы для ее
последующей детализации в форме логических и физических моделей;

подготовить исходную документацию для взаимодействия
разработчиков системы с ее заказчиками и пользователями.
Суть диаграммы вариантов использования состоит в следующем.
Проектируемая система представляется в виде множества сущностей или
актеров, взаимодействующих с системой с помощью вариантов
использования. При этом актером (actor) или действующим лицом
называется любая сущность, взаимодействующая с системой извне. Это
может быть человек, техническое устройство, программа или любая другая
система, которая может служить источником воздействия на моделируемую
систему так, как определит сам разработчик. Вариант использования служит
для описания сервисов, которые система предоставляет актеру.
Цель варианта использования заключается в том, чтобы определить
законченный аспект или фрагмент поведения некоторой сущности без
11
раскрытия её внутренней структуры. В качестве такой сущности может
выступать система или любой элемент модели, который обладает
собственным поведением.
Каждый вариант использования соответствует отдельному сервису,
который предоставляет моделируемая сущность по запросу актера, то есть
определяет способ применения этой сущности. Сервис, который
инициализируется по запросу актера, представляет собой законченную
неделимую последовательность действий. Это означает, что после того как
система закончит обработку запроса, она должна возвратиться в исходное
состояние, чтобы быть готовой к выполнению следующих запросов
Варианты использования могут применяться как для спецификации
внешних требований к проектируемой системе, так и для спецификации
функционального поведения уже существующей системы. Множество
вариантов использования в целом должно определять все возможные
стороны ожидаемого поведения системы. Кроме этого, варианты
использования неявно устанавливают требования, определяющие, как актеры
должны взаимодействовать с системой, чтобы иметь возможность корректно
работать с предоставляемыми сервисами. Для удобства множество вариантов
использования может рассматриваться как отдельный пакет.
Примерами вариантов использования могут являться следующие
действия: проверка состояния текущего счета клиента, оформление заказа на
покупку
товара,
получение
дополнительной
информации
о
кредитоспособности клиента, отображение графической формы на экране
монитора и другие действия.
Диаграмма классов (class diagram)
Центральное место в объектно-ориентированном программировании
занимает разработка логической модели системы в виде диаграммы классов.
Диаграмма классов (class diagram) служит для представления статической
структуры модели системы в терминологии классов объектноориентированного программирования. Диаграмма классов может отражать, в
частности, различные взаимосвязи между отдельными сущностями
предметной области, такими как объекты и подсистемы, а также описывать
их внутреннюю структуру и типы отношений.
В качестве примера на рис. 2 приведена диаграмма классов для
информационной системы театра. Эту систему образует 6 классов.
12
Классы-агрегаты Театр и Труппа имеют операции добавления и
удаления своих частей, которые включаются в агрегаты по ссылке. Частями
Театра являются Зрители и Труппы, а частями Труппы — Актеры.
Отношения агрегации между классом Театр и классами Труппа и Зритель
слегка отличны. Театр может состоять из одной или нескольких трупп, но
каждая труппа находится в одном и только одном театре. С другой стороны,
в театр может ходить любое количество зрителей (включая нулевое
количество), причем зритель может посещать один или несколько театров.
Между классами Труппа и Актер существуют два отношения —
агрегация и ассоциация. Агрегация показывает, что каждый актер работает в
одной или нескольких труппах, а в каждой труппе должен быть хотя бы один
актер. Ассоциация отображает, что каждой труппой управляет только один
актер — художественный руководитель, а некоторые актеры не являются
руководителями.
Ассоциация между классами Спектакль и Актер фиксирует, что в
спектакле должен быть занят хотя бы один актер, впрочем, актер может
играть в любом количестве спектаклей (или вообще может ничего не играть).
Между классами Спектакль и Зритель тоже определена ассоциация.
Она поясняет, что зритель может смотреть любое число спектаклей, а на
каждом спектакле может быть любое число зрителей.
И наконец, на диаграмме отображены два отношения наследования,
утверждающие, что и в зрителях, и в актерах есть человеческое начало.
Значки диаграммы позволяют отображать сложную иерархию систем,
взаимосвязи классов (Classes) и интерфейсов (Interfaces). Данный тип
диаграмм противоположен по содержанию диаграмме Collaboration, на
котором отображаются объекты системы. Rational Rose позволяет создавать
классы при помощи данного типа диаграмм в различных нотациях. похожего
на облако. Таким образом, класс - это лишь шаблон, по которому в
дальнейшем будет создан конкретный объект.
Диаграмма классов представляет собой граф, вершинами которого
являются элементы типа "классификатор", связанные различными типами
структурных отношений. Диаграмма классов может также содержать
интерфейсы, пакеты, отношения и даже отдельные экземпляры, такие как
объекты и связи.
13
Рис. 2 Диаграмма классов информационной системы театра
Класс (class) в языке UML служит для обозначения множества
объектов, которые обладают одинаковой структурой, поведением и
отношениями с объектами других классов. Графически класс изображается в
виде прямоугольника, который дополнительно может быть разделен
горизонтальными линиями на разделы или секции. В этих разделах могут
указываться имя класса, атрибуты (переменные) и операции (методы).
Диаграмма деятельности (activity diagram)
При моделировании поведения проектируемой или анализируемой
системы возникает необходимость не только представить процесс изменения
ее состояний, но и детализировать особенности алгоритмической и
логической реализации выполняемых системой операций.
Фактически данный тип диаграмм может использоваться и для
отражения состояний моделируемого объекта, однако, основное назначение
Activity diagram в том, чтобы отражать бизнес-процессы объекта. Этот тип
диаграмм позволяет показать не только последовательность процессов, но и
ветвление и даже синхронизацию процессов.
14
Этот тип диаграмм позволяет проектировать алгоритмы поведения
объектов любой сложности, в том числе может использоваться для
составления блок-схем.
Для моделирования процесса выполнения операций в языке UML
используются диаграммы деятельности. Применяемая в них графическая
нотация во многом похожа на нотацию диаграммы состояний, поскольку на
этих диаграммах также присутствуют обозначения состояний и переходов.
Каждое состояние на диаграмме деятельности соответствует выполнению
некоторой элементарной операции, а переход в следующее состояние
выполняется только при завершении этой операции.
Таким образом, диаграммы деятельности можно считать частным
случаем диаграмм состояний. Они позволяют реализовать в языке UML
особенности процедурного и синхронного управления, обусловленного
завершением внутренних деятельностей и действий. Основным
направлением использования диаграмм деятельности является визуализация
особенностей реализации операций классов, когда необходимо представить
алгоритмы их выполнения.
В контексте языка UML деятельность (activity) представляет собой
совокупность отдельных вычислений, выполняемых автоматом, приводящих
к некоторому результату или действию (action). На диаграмме деятельности
отображается логика и последовательность переходов от одной деятельности
к другой, а внимание аналитика фокусируется на результатах. Результат
деятельности может привести к изменению состояния системы или
возвращению некоторого значения.
Состояние действия (action state) является специальным случаем
состояния с некоторым входным действием и, по крайней мере, одним
выходящим из состояния переходом. Этот переход неявно предполагает, что
входное действие уже завершилось. Состояние действия не может иметь
внутренних переходов, поскольку оно является элементарным. Обычное
использование состояния действия заключается в моделировании одного
шага выполнения алгоритма (процедуры) или потока управления.
Пример диаграммы деятельности приведен на рис. 3. Эта диаграмма
описывает деятельность покупателя в Интернет-магазине. Здесь
представлены две точки ветвления — для выбора способа поиска товара и
для принятия решения о покупке. Присутствуют три линейки синхронизации:
верхняя отражает разделение на два параллельных процесса, средняя
15
отражает и разделение, и слияние процессов, а нижняя — только слияние
процессов.
Рис. 3 Диаграмма деятельности покупателя в Интернет-магазине
Дополнительно на этой диаграмме показаны две плавательные дорожки
— дорожка покупателя и дорожка магазина, которые разделены
вертикальной линией. Каждая дорожка имеет имя и фиксирует область
деятельности конкретного лица, обозначая зону его ответственности.
Особенности рабочего интерфейса Rational Rose
В CASE-средстве Rational Rose реализованы общепринятые стандарты
на рабочий интерфейс программы, подобно известным средам визуального
программирования. После установки Rational Rose на компьютер
пользователя, запуск этой программы в среде MS Windows приводит к
появлению на экране рабочего интерфейса (рис. 4).
Рабочий интерфейс Rational Rose состоит из различных элементов,
основными из которых являются:
 Главное меню программы
 Окно диаграммы
 Стандартная панель инструментов
16




Окно документации
Окно браузера
Окно журнала
Специальная панель инструментов
Рис. 4 Общий вид рабочего интерфейса программы Rational Rose
Главное меню программы
Главное меню программы выполнено в общепринятом стандарте и
имеет следующий вид (рис. 5).
Отдельные пункты меню, назначение которых понятно из их названий,
объединяют сходные операции, относящиеся ко всему проекту в целом.
Некоторые из пунктов меню содержат хорошо знакомые функции (открытие
проекта, вывод печать диаграмм, копирование в буфер и вставка из буфера
различных элементов диаграмм). Другие настолько специфичны, что могут
потребовать дополнительных усилий на изучение (опции генерации
программного кода, проверка согласованности моделей, подключение
дополнительных модулей).
Рис. 5 Внешний вид главного меню программы
Стандартная панель инструментов
Стандартная панель инструментов располагается ниже главного меню
программы и имеет следующий вид (рис. 6). Некоторые из инструментов
недоступны (новый проект не имеет никаких элементов). Стандартная панель
17
инструментов обеспечивает быстрый доступ к тем командам меню, которые
выполняются разработчиками наиболее часто.
Рис. 6 Внешний вид стандартной панели инструментов
Пользователь может настроить внешний вид этой панели по своему
усмотрению. Для этого необходимо выбрать пункт меню Tools -> Options
(Инструменты -> Параметры) и открыть вкладку Toolbars (Панели
инструментов). Этим способом можно показать или скрыть различные
кнопки инструментов, а также изменить их размер.
Окно браузера
Окно браузера по умолчанию располагается в левой части рабочего
интерфейса под стандартной панелью инструментов (рис. 7).
Браузер организует представления модели в виде иерархической
структуры, которая упрощает навигацию и позволяет отыскать любой
элемент модели в проекте. При этом любой элемент, который разработчик
добавляет в модель, сразу отображается в окне браузера. Соответственно,
выбрав элемент в окне браузера, мы можем его визуализировать в окне
диаграммы или изменить его спецификацию. Браузер позволяет также
организовывать элементы модели в пакеты и перемещать элементы между
различными представлениями модели. При желании окно браузера можно
расположить в другом месте рабочего интерфейса либо скрыть вовсе,
используя для этого пункт меню View (Вид). Можно также изменить размеры
браузера, переместив мышью границу его внешней рамки.
Рис. 7 Внешний вид браузера
Специальная панель инструментов
Специальная панель инструментов располагается между окном
браузера и окном диаграммы в средней части рабочего интерфейса. По
18
умолчанию предлагается панель инструментов для построения диаграммы
классов модели (рис. 8).
Рис. 8 Внешний вид специальной панели инструментов для диаграммы
классов
Расположение специальной панели инструментов можно изменять,
переместив рамку панели в нужное место. Можно настраивать и состав
панели, добавляя или удаляя отдельные кнопки, соответствующие тем или
иным инструментам. Назначения кнопок можно узнать из всплывающих
подсказок, появляющихся после задержки указателя мыши над
соответствующей кнопкой.
Окно диаграммы
Окно диаграммы является основной рабочей областью ее интерфейса, в
которой визуализируются различные представления модели проекта. По
умолчанию окно диаграммы располагается в правой части рабочего
интерфейса, однако его расположение и размеры также можно изменить. При
разработке нового проекта, если не был использован мастер проектов, окно
диаграммы представляет собой чистую область, не содержащую никаких
элементов модели (рис. 9).
Название диаграммы, которая располагается в данном окне,
указывается в строке заголовка программы (самая верхняя строка
программы) или, если окно не развернуто во весь экран, в строке заголовка
окна диаграммы. Одновременно в окне диаграммы могут присутствовать
несколько диаграмм, однако активной может быть только одна из них.
Например, на рис. 9 активной является диаграмма развертывания, хотя
имеются и другие диаграммы. Переключение между диаграммами можно
осуществить выбором нужного представления на стандартной панели
инструментов либо через пункт меню Window (Окно). При активизации
отдельного вида диаграммы изменяется внешний вид специальной панели
инструментов, которая настраивается под конкретный вид диаграммы.
19
Рис. 9 Внешний вид окна диаграмм с различными видами
представлений модели
Окно документации
Окно документации по умолчанию может не присутствовать на экране.
В этом случае оно может быть активизировано через пункт меню View ->
Documentation (Вид->Документация), после чего появится ниже браузера
(рис. 10).
Окно документации, как следует из его названия, предназначено для
документирования элементов представления модели. В него можно
записывать самую различную информацию, и что важно - на русском языке.
Эта информация в последующем преобразуется в комментарии и никак не
влияет на логику выполнения программного кода.
В окне документации активизируется та информация, которая
относится к отдельному выделенному элементу диаграммы. При этом
выделить элемент можно либо в окне браузера, либо в окне диаграммы. При
добавлении нового элемента на диаграмму (например, класса) автоматически
генерируется документация к нему, которая является пустой (No
documentation). В последующем разработчик самостоятельно вносит
необходимую пояснительную информацию, которая запоминается и может
быть изменена в ходе работы над проектом.
20
Так же, как и для других окон рабочего интерфейса, можно изменять
размеры и положение окна документации.
Рис. 10 Внешний вид окна документации
Окно журнала
Окно журнала (Log) предназначено для автоматической записи
различной служебной информации, образующейся в ходе работы с
программой. В журнале фиксируется время и характер выполняемых
разработчиком действий, таких как обновление модели, настройка меню и
панелей инструментов, а также сообщений об ошибках, возникающих при
генерации программного кода.
Окно журнала всегда присутствует на рабочем интерфейсе в области
окна диаграммы (рис. 11). Однако оно может быть закрыто другими окнами с
диаграммами или быть свернутым. Активизировать окно журнала можно
через меню Window->Log (Окно->Журнал). В этом случае оно изображается
поверх других окон в правой области рабочего интерфейса. Полностью
удалить это окно нельзя, его можно только минимизировать.
Рис. 11 Внешний вид окна журнала
21
2.
Варианты заданий
Вариант 1
Теоретическая часть на тему «Способы использования UML».
Практическая часть: Для выполнения необходимо для своей
предметной области разработать и описать
•
Первоначальная постановка задачи: диаграмму прецедентов,
диаграмму деятельности, диаграмму классов.
•
Развитие постановки задачи: диаграмму прецедентов, диаграмму
деятельности, диаграмму классов.
Страховая компания
Описание предметной области
Вы работаете в страховой компании. Вашей задачей является
отслеживание финансовой деятельности компании.
Компания имеет различные филиалы по всей стране. Каждый филиал
характеризуется названием, адресом и телефоном. Деятельность компании
организована следующим образом: к Вам обращаются различные лица с
целью заключения договора о страховании. В зависимости от принимаемых
на страхование объектов и страхуемых рисков, договор заключается по
определенному виду страхования (например, страхование автотранспорта от
угона, страхование домашнего имущества, добровольное медицинское
страхование). При заключении договора Вы фиксируете дату заключения,
страховую сумму, вид страхования, тарифную ставку и филиал, в котором
заключался договор.
Классы объектов
Договоры (Номер договора, Дата заключения, Страховая сумма,
Тарифная ставка, Филиал, Вид страхования).
Вид страхования (Вид страхования, Наименование).
Филиал (Филиал, Наименование филиала, Адрес, Телефон).
Развитие постановки задачи
Нужно учесть, что договоры заключают страховые агенты. Помимо
информации об агентах (фамилия, имя, отчество, адрес, телефон), нужно еще
хранить филиал, в котором работают агенты. Кроме того, исходя из базы
данных, нужно иметь возможность рассчитывать заработную плату агентам.
Заработная плата составляет некоторый процент от страхового платежа
22
(страховой платеж это страховая сумма, умноженная на тарифную ставку).
Процент зависит от вида страхования, по которому заключен договор.
Вариант 2
Теоретическая часть на тему «Назначение UML. Спецификация.
Визуализация. Проектирование. Документирование».
Практическая часть: Для выполнения необходимо для своей
предметной области разработать и описать
•
Первоначальная постановка задачи: диаграмму прецедентов,
диаграмму деятельности, диаграмму классов.
•
Развитие постановки задачи: диаграмму прецедентов, диаграмму
деятельности, диаграмму классов.
Гостиница
Описание предметной области
Вы работаете в гостинице. Вашей задачей является отслеживание
финансовой стороны работы гостиницы.
Ваша деятельность организована следующим образом: гостиница
предоставляет номера клиентам на определенный срок. Каждый номер
характеризуется вместимостью, комфортностью (люкс, полу-люкс, обычный)
и ценой. Вашими клиентами являются различные лица, о которых Вы
собираете определенную информацию (фамилия, имя, отчество и некоторый
комментарий). Сдача номера клиенту производится при наличии свободных
мест в номерах, подходящих клиенту по указанным выше параметрам. При
поселении фиксируется дата поселения. При выезде из гостиницы для
каждого места запоминается дата освобождения.
Классы объектов
Клиенты (Клиент, Фамилия, Имя, Отчество, Паспортные данные,
Комментарий).
Номера (Номер, Количество человек, Комфортность, Цена).
Поселение (Клиент, Номер, Дата поселения, Дата освобождения,
Примечание).
Развитие постановки задачи
Необходимо хранить информацию не только по факту сдачи номера
клиенту, но и осуществлять бронирование номеров. Кроме того, для
постоянных клиентов, а также для определенных категорий клиентов,
предусмотрена система скидок. Скидки могут суммироваться.
23
Внести в структуру сущностей изменения, учитывающие этот факт, и
изменить существующие запросы. Добавить новые запросы.
Вариант 3
Теоретическая часть на тему «Декомпозиция информационных систем
на слои и уровни. Выделение подсистем в архитектуре».
Практическая часть: Для выполнения необходимо для своей
предметной области разработать и описать
•
Первоначальная постановка задачи: диаграмму прецедентов,
диаграмму деятельности, диаграмму классов.
•
Развитие постановки задачи: диаграмму прецедентов, диаграмму
деятельности, диаграмму классов.
Распределение учебной нагрузки
Описание предметной области
Вы работаете в высшем учебном заведении и занимаетесь
распределением нагрузки между преподавателями кафедры.
В Вашем распоряжении имеются сведения о преподавателях кафедры,
включающие наряду с анкетными данными сведения об их ученой степени,
занимаемой административной должности и стаже работы. Преподаватели
Вашей кафедры должны обеспечить проведение занятий по некоторым предметам. По каждому из них существует определенное количество часов. В
результате распределения нагрузки у Вас должна получится информация
следующего рода: «Такой-то преподаватель проводит занятия по такому-то
предмету с такой-то группой».
Классы объектов
Преподаватели (Фамилия, Имя, Отчество, Ученая степень, Должность,
Стаж). Предметы (Название, Количество часов). Нагрузка (Преподаватель,
Предмет, Номер группы).
Развитие постановки задачи
Теперь ситуация изменилась. Выяснилось, что все проводимые занятия
делятся на лекционные и практические. По каждому виду занятий
устанавливается свое количество часов. Кроме того, данные по нагрузке
нужно хранить несколько лет.
Вариант 4
24
Теоретическая часть на тему «Правила языка UML. Общие механизмы
языка UML».
Практическая часть: Для выполнения необходимо для своей
предметной области разработать и описать
•
Первоначальная постановка задачи: диаграмму прецедентов,
диаграмму деятельности, диаграмму классов.
•
Развитие постановки задачи: диаграмму прецедентов, диаграмму
деятельности, диаграмму классов.
Реализация готовой продукции
Описание предметной области
Вы работаете в компании, занимающейся оптово-розничной продажей
различных товаров. Вашей задачей является отслеживание финансовой
стороны работы компании.
Деятельность Вашей компании организована следующим образом:
Ваша компания торгует товарами из определенного спектра. Каждый из этих
товаров характеризуется наименованием, оптовой ценой, розничной ценой и
справочной информацией. В Вашу компанию обращаются покупатели. Для
каждого из них Вы запоминаете в базе данных стандартные данные
(наименование, адрес, телефон, контактное лицо) и составляете по каждой
сделке документ, запоминая наряду с покупателем количество купленного им
товара и дату покупки.
Классы объектов
Товары (Наименование, Оптовая цена, Розничная цена, Описание).
Покупатели (Телефон, Контактное лицо, Адрес).
Сделки (Дата сделки, Товар, Количество, Покупатель, Признак оптовой
продажи).
Развитие постановки задачи
Теперь ситуация изменилась. Выяснилось, что обычно покупатели в
рамках одной сделки покупают не один товар, а сразу несколько. Также
компания решила предоставлять скидки в зависимости от количества
закупленных товаров и их общей стоимости.
25
Вариант 5
Теоретическая часть на тему «Принципы объектного подхода».
Практическая часть: Для выполнения необходимо для своей
предметной области разработать и описать
•
Первоначальная постановка задачи: диаграмму прецедентов,
диаграмму деятельности, диаграмму классов.
•
Развитие постановки задачи: диаграмму прецедентов, диаграмму
деятельности, диаграмму классов.
Ведение заказов
Описание предметной области
Вы работаете в компании, занимающейся оптовой продажей различных
товаров. Вашей задачей является отслеживание финансовой стороны работы
компании.
Деятельность Вашей компании организована следующим образом:
Ваша компания торгует товарами из определенного спектра. Каждый из этих
товаров характеризуется ценой, справочной информацией и признаком
наличия или отсутствия доставки. В Вашу компанию обращаются заказчики.
Для каждого из них Вы запоминаете в базе данных стандартные данные
(наименование, адрес, телефон, контактное лицо) и составляете по каждой
сделке документ, запоминая наряду с заказчиком количество купленного им
товара и дату покупки.
Классы объектов
Заказчики (Наименование, Адрес, Телефон, Контактное лицо). Товары
(Цена, Доставка, Описание). Заказы (Заказчик, Товар, Количество, Дата).
Развитие постановки задачи
Теперь ситуация изменилась. Выяснилось, что доставка разных товаров
может производиться разными способами, различными по цене и скорости.
Нужно хранить информацию по тому, какими способами может
осуществляться доставка каждого товара и информацию о том, какой вид
доставки (а, соответственно, и какую стоимость доставки) выбрал клиент при
заключении сделки.
Вариант 6
Теоретическая часть на тему «Отношения зависимости, ассоциации,
обобщения и реализации».
26
Практическая часть: Для выполнения необходимо для своей
предметной области разработать и описать
•
Первоначальная постановка задачи: диаграмму прецедентов,
диаграмму деятельности, диаграмму классов.
•
Развитие постановки задачи: диаграмму прецедентов, диаграмму
деятельности, диаграмму классов.
Бюро по трудоустройству
Описание предметной области
Вы работаете в бюро по трудоустройству. Вашей задачей является
отслеживание финансовой стороны работы компании.
Деятельность Вашего бюро организована следующим образом: Ваше
бюро готово искать работников для различных работодателей и вакансии для
ищущих работу специалистов различного профиля. При обращении к Вам
клиента-работодателя, его стандартные данные (название, вид деятельности,
адрес, телефон) фиксируются в базе данных. При обращении к Вам клиентасоискателя, его стандартные данные (фамилия, имя, отчество, квалификация,
профессия, иные данные) также фиксируются в базе данных. По каждому
факту удовлетворения интересов обеих сторон составляется документ. В
документе указываются соискатель, работодатель, должность и
комиссионные (доход бюро).
Классы объектов
Работодатели (Название, Вид деятельности, Адрес, Телефон). Сделки
(Работодатель, Должность, Комиссионные). Соискатели (Фамилия, Имя,
Отчество, Квалификация, Вид деятельности, Иные данные, Предполагаемый
размер заработной платы).
Развитие постановки задачи
Оказалось, что база данных не совсем точно описывает работу бюро. В
базе фиксируется только сделка, а информация по открытым вакансиям не
храниться. Кроме того, для автоматического поиска вариантов, необходимо
вести справочник «виды деятельности».
27
Вариант 7
Теоретическая часть на тему «Методы структурного моделирования».
Практическая часть: Для выполнения необходимо для своей
предметной области разработать и описать
•
Первоначальная постановка задачи: диаграмму прецедентов,
диаграмму деятельности, диаграмму классов.
•
Развитие постановки задачи: диаграмму прецедентов, диаграмму
деятельности, диаграмму классов.
Нотариальная контора
Описание предметной области
Вы работаете в нотариальной конторе. Вашей задачей является
отслеживание финансовой стороны работы компании.
Деятельность Вашей нотариальной конторы организована следующим
образом: Ваша фирма готова предоставить клиенту определенный комплекс
услуг. Для наведения порядка Вы формализовали эти услуги, составив их
список с описанием каждой услуги. При обращении к Вам клиента, его
стандартные данные (название, вид деятельности, адрес, телефон)
фиксируются в базе данных. По каждому факту оказания услуги клиенту
составляется документ. В документе указываются услуга, сумма сделки,
комиссионные (доход конторы), описание сделки.
Классы объектов
Клиенты (Название, Вид деятельности, Адрес, Телефон). Сделки
(Клиент, Услуга, Сумма, Комиссионные, Описание). Услуги (Название,
Описание).
Развитие постановки задачи
Теперь ситуация изменилась. В рамках одной сделки клиенту может
быть оказано несколько услуг. Стоимость каждой услуги фиксирована.
Кроме того, компания предоставляет в рамках одной сделки различные виды
скидок. Скидки могут суммироваться.
Вариант 8
Теоретическая часть на тему «Интеграция различных информационных
систем, параллельные архитектуры».
Практическая часть: Для выполнения необходимо для своей
предметной области разработать и описать
28
•
Первоначальная постановка задачи: диаграмму прецедентов,
диаграмму деятельности, диаграмму классов.
•
Развитие постановки задачи: диаграмму прецедентов, диаграмму
деятельности, диаграмму классов.
Фирма по продаже запчастей
Описание предметной области
Вы работаете в фирме, занимающейся продажей запасных частей для
автомобилей. Вашей задачей является отслеживание финансовой стороны
работы компании.
Основная часть деятельности, находящейся в Вашем ведении, связана с
работой с поставщиками. Фирма имеет определенный набор поставщиков, по
каждому из которых известны название, адрес и телефон. У этих
поставщиков Вы приобретаете детали. Каждая деталь наряду с названием
характеризуется артикулом и ценой (считаем цену постоянной). Некоторые
из поставщиков могут поставлять одинаковые детали (один и тот же
артикул). Каждый факт покупки запчастей у поставщика фиксируется в базе
данных, причем обязательными для запоминания являются дата покупки и
количество приобретенных деталей.
Классы объектов
Поставщики (Поставщик, Название, Адрес, Телефон). Детали
(Название, Артикул, Цена, Примечание). Поставки (Поставщик, Деталь,
Количество, Дата).
Развитие постановки задачи
Теперь ситуация изменилась. Выяснилось, что цена детали может
меняться от поставки к поставке. Поставщики заранее ставят Вас в
известность о дате изменения цены и о его новом значении. Нужно хранить
не только текущее значение цены, но и всю историю изменения цен.
Вариант 9
Теоретическая часть на тему «Архитектуры масштабируемых
информационных систем».
Практическая часть: Для выполнения необходимо для своей
предметной области разработать и описать
•
Первоначальная постановка задачи: диаграмму прецедентов,
диаграмму деятельности, диаграмму классов.
•
Развитие постановки задачи: диаграмму прецедентов, диаграмму
деятельности, диаграмму классов.
Курсы по повышению квалификации
Описание предметной области
Вы работаете в учебном заведении и занимаетесь организацией курсов
повышения квалификации.
В Вашем распоряжении имеются сведения о сформированных группах
студентов. Группы формируются в зависимости от специальности и
отделения. В каждой из них включено определенное количество студентов.
Проведение занятий обеспечивает штат преподавателей. Для каждого из них
у Вас в базе данных зарегистрированы стандартные анкетные данные
(фамилия, имя, отчество, телефон) и стаж работы. В результате
распределения нагрузки Вы получаете информацию о том, сколько часов
занятий проводит каждый преподаватель с соответствующими группами.
Кроме того, хранятся также сведения о виде проводимых занятий (лекции,
практика), предмете и оплате за 1 час.
Классы объектов
Группы (Специальность, Отделение, Количество студентов).
Преподаватели (Фамилия, Имя, Отчество, Телефон, Стаж). Нагрузка
(Преподаватель, Группа, Количество часов, Предмет, Тип занятия, Оплата).
Развитие постановки задачи
В результате работы с базой данных выяснилось, что размер почасовой
оплаты зависит от предмета и типа занятия. Кроме того, каждый
преподаватель может вести не все предметы, а только некоторые.
Вариант 10
Теоретическая часть на тему «Сервис–ориентированная архитектура
(SOA). Эволюция распределенных систем в сервис–ориентированные
системы, облачные информационные системы и сервисы».
Практическая часть: Для выполнения необходимо для своей
предметной области разработать и описать
•
Первоначальная постановка задачи: диаграмму прецедентов,
диаграмму деятельности, диаграмму классов.
•
Развитие постановки задачи: диаграмму прецедентов, диаграмму
деятельности, диаграмму классов.
Определение факультативов для студентов
Описание предметной области
Вы работаете в высшем учебном заведении и занимаетесь
организацией факультативов.
В Вашем распоряжении имеются сведения о студентах, включающие
стандартные анкетные данные (фамилия, имя, отчество, адрес, телефон).
Преподаватели Вашей кафедры должны обеспечить проведение
факультативных занятий по некоторым предметам. По каждому
факультативу существует определенное количество часов и вид проводимых
занятий (лекции, практика, лабораторные работы). В результате работы со
студентами у Вас появляется информация о том, кто из них записался на
какие факультативы. Существует некоторый минимальный объем
факультативных предметов, которые должен прослушать каждый студент.
По окончанию семестра Вы заносите информацию об оценках, полученных
студентами на экзаменах.
Классы объектов
Студенты (Фамилия, Имя, Отчество, Адрес, Телефон).
Предметы (Название, Объем лекций, Объем практик, Объем
лабораторных работ).
Учебный план (Студент, Предмет, Оценка).
Развитие постановки задачи
Теперь ситуация изменилась. Выяснилось, что некоторые из
факультативов могут длиться более одного семестра. В каждом семестре для
предмета устанавливается объем лекций, практик и лабораторных работ в
часах. В качестве итоговой оценки за предмет берется последняя оценка,
полученная студентом.
3.
Библиографический список
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 с.
Олеся Владимировна Коровина
АРХИТЕКТУРА ИНФОРМАЦИОННЫХ СИСТЕМ
Методические указания к выполнению курсовой работы
для студентов по направлению подготовки
230400 – Информационные системы и технологии
Редактор Е.А. Богданова
Подписано в печать . . . Формат 60×90 /16. Объем п. л.
Усл. печ. л. . Уч.-изд. л. . Тираж экз. Заказ
ФГБОУ ВПО «Воронежская государственная лесотехническая
академия»
РИО ФГБОУ ВПО «ВГЛТА». 394087, г. Воронеж, ул. Тимирязева, 8
Отпечатано в УОП ФГБОУ ВПО «ВГЛТА».
394087, г. Воронеж, ул. Докучаева, 10
Документ
Категория
Без категории
Просмотров
10
Размер файла
552 Кб
Теги
архитектура, информационные, система, коровина, работа, курсовая
1/--страниц
Пожаловаться на содержимое документа