Автоматизированная информационная система автосалона

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

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

·  сокращение время разработки;

·  уменьшение ручного труда, увеличение продуктивности;

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

·  способность вести большие проекты или группу проектов;

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

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

1.6.1 Диаграмма вариантов  использования

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

·  Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы

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

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

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

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

Средства Rational Rose позволяют для описания функциональной системы воспользоваться графическим  редактором для построения Use Case диаграмм (сценариев). Опишем основные элементы в таблице 1.1. [7] 

Таб.1.1. Условные обозначения диаграммы вариантов  использования

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

Рис. 1.2. Диаграмма  прецедентов  

1.6.2 Диаграммы состояний

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

Таб 1.2. Условные обозначения диаграммы состояний

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

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

С состоянием можно  связывать следующие данные: деятельность, входное действие, выходное действие и событие.

Деятельность (activity) - это поведение, реализуемое объектом, пока он находится в данном состоянии. Деятельность изображают внутри самого состояния; ее обозначению должно предшествовать слово do (делать) и двоеточие.

Входное действие (entry action) - это поведение, которое  выполняется, когда объект переходит  в данное состояние. Входное действие также показывают внутри состояния, его обозначению предшествуют слово entry (вход) и двоеточие.

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

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

Переходы могут  быть рефлексивными. Объект может перейти  в то же состояние, в котором он в настоящий момент находится. Рефлексивные переходы изображают в виде стрелки, начинающейся и завершающейся на одном и том же состоянии.  [1]  

1.6.3 Диаграмма деятельности

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

Средства Rational Rose позволяют для описания функциональной системы воспользоваться графическим  редактором для построения Activity диаграмм (деятельности).  

Таб. 1.3. Условные обозначения диаграммы деятельности

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

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

·  анализ потоков работ (workflow) в различных вариантах использования. Когда варианты использования взаимодействуют друг с другом, диаграммы деятельностей являются мощным средством представления и анализа их поведения. [6] 

1.6.4 Диаграммы взаимодействия

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

информационные (informative) – сообщения, снабжающие объект-получатель информацией для обновления его  состояния;

сообщения –  запросы (interrogative) – сообщения, запрашивающие  выдачу информации об объекте-получателе;

императивные (imperative) – сообщения, запрашивающие у  объекта-получателя выполнение действия.

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

1.  последовательности (sequence diagrams);

2.  кооперативные (collaboration diagrams).

На диаграмме  последовательности объект изображается в виде прямоугольника на вершине  пунктирной вертикальной линии. Эта  вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла  объекта в процессе взаимодействия.

Каждое сообщение  изображается в виде стрелки между  линиями жизни двух объектов. Сообщения  появляются в том порядке, как  они показаны на странице, сверху вниз. Каждое сообщение помечается как  минимум именем сообщения; при желании  можно добавить также аргументы  и некоторую управляющую информацию и, кроме того, показать самоделегирование (self-delegation) -сообщение, которое объект посылает самому себе, при этом стрелка  сообщения указывает на ту же самую  линию жизни. 

Рис. 1.5. Диаграмма  последовательности «заказ дополнительного  оборудования»

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