Проектирование информационной системы средствами Rational Rose

Компания Rational Software является лидирующей в области создания методологий и программных решений, ориентированных на программистов, аналитиков, тестировщиков. Спектр выпускаемого программного обеспечения целиком покрывает потребность всех участников проекта: от аналитиков до разработчиков и внедренцев.

В данной курсовой работе для разработки приложения учета реализации товара был использован программный продукт IBM Rational Rose Enterprise Edition.

Семейство продуктов IBM Rational Rose предназначено для разработки приложений на основе Unified Modeling Language (UML). Архитекторы, аналитики, проектировщики программного обеспечения и баз данных и разработчики систем могут использовать это семейство продуктов для создания визуальных моделей архитектуры программного обеспечения, баз данных, требований приложения и многоразовых ресурсов, а также определения связи на уровне руководства.

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

Являясь объектно-ориентированным инструментом моделирования, Rational Rose базируется на UML (Universal Modeling Language) – универсальном языке моделирования, который был разработан компанией Rational именно с целью создания наиболее оптимального и универсального языка для описания как предметной области, так и конкретной задачи в программировании. Любая задача программируется при помощи определенных диаграмм. UML поддерживает построение следующих диаграмм:

- Activity diagram (диаграммы описаний технологий, процессов, функций);

- Use case diagram (диаграммы функций);

- Class diagram (диаграммы классов);

- State diagram (диаграммы состояний);

- Sequence diagram (диаграммы последовательностей действий);

- Collaboration diagram (диаграммы взаимодействий);

- Component diagram (диаграммы компонент);

- Deployment diagram (диаграммы топологии).

Основополагающими элементами языка UML являются сущности, отношения и диаграммы.

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

- структурные;

- поведенческие;

- группирующие;

- аннотационные.

Структурные сущности – это имена существительные в моделях на языке UML. Как правило, они представляют собой статические части модели, соответствующие концептуальным или физическим элементам системы.

Существует семь разновидностей структурных сущностей:

- Класс (class) – это описание совокупности объектов с общими атрибутами, операциями отношениями и семантикой. Графически класс изображается в виде прямоугольника, в котором записаны его имя, атрибуты и операции;

- Интерфейс (interface) – это совокупность операций, которые определяют определенную службу (сервис, набор услуг), которые предоставляет класс или компонент. На диаграммах интерфейс изображается в виде круга, под которым указывается его имя. Интерфейс очень редко существует сам по себе - обычно он присоединяется к реализующему его классу или компоненту;

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

- Прецедент (use case) – это описание последовательности выполняемых системой действий, которая производит наблюдаемый результат, значимый для какого-то определенного актера (actor). Графически прецедент тоже изображается в виде эллипса, только ограниченного непрерывной линией, обычно содержащего только его имя;

- Активным классом (active class) называется класс, объекты которого вовлечены в один или несколько процессов, или нитей (threads), и поэтому могут инициировать управляющее воздействие. Графически активный класс изображается также как и простой класс, но ограничивается прямоугольником, который рисуется жирной линией, и включает имя, атрибуты и операции;

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

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

Поведенческие сущности (behavioral things) являются динамическими составляющими модели UML. Это глаголы языка, они описывают поведение модели во времени и в пространстве. Существует всего два основных типа поведенческих сущностей:

- Взаимодействие (interaction) – это поведение, суть которого заключается в обмене сообщениями (messages) между объектами в рамках конкретного контекста для достижения определенной цели. С помощью взаимодействия можно описать как отдельную операцию, так и поведение совокупности объектов. Взаимодействие предполагает ряд других элементов, таких как сообщения, последовательности действий (поведение, инициированное сообщениями) и связи (между объектами). Графически сообщение изображается в виде стрелки. Над которой почти всегда пишется имя соответствующей операции;

- Автомат (state machine) – алгоритм поведения, определяющий последовательность состояний, через которые объект или взаимодействие проходят на протяжении своего жизненного цикла в ответ на различные события, а также реакции на эти события. С помощью автоматов описываются поведение отдельного класса или кооперации классов. С автоматом связан ряд других элементов: состояния, переходы из одного состояния в другое, события – сущности инициирующие переходы и виды действий – реакция на переходы. Графически состояние изображается в виде прямоугольника с закругленными углами, содержащего имя и, возможно, промежуточные состояния.

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

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

Аннотационные сущности – пояснительные части модели UML. Это комментарии для дополнительного описания, разъяснения или замечания к любому элементу модели. Имеется только один базовый тип аннотационных элементов – примечание.

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

Отношения – это средства языка UML, с помощью которых связывают различные сущности. Существует 4 типа отношений:

- зависимости;

- ассоциации;

- обобщения;

- реализации.

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

Ассоциация (association) – структурное отношение, описывающее совокупность связей, где под связью понимается некоторая смысловая связь между объектами. Разновидностью ассоциации является агрегирование (aggregation) – так называется структурное отношение между целым и его частями. Графически ассоциация изображается в виде линии (иногда завершающейся стрелкой или содержащей метку), рядом с которой могут присутствовать дополнительные обозначения, например кратность и имена ролей.

Обобщение (generalization) – это отношение "специализация/обобщение", при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (родителя, предка). Как и положено в объектно-ориентированном программировании, потомок (child) наследует структуру и поведение своего предка (parent). Графически отношение обобщения изображается в виде линии с незакрашенной стрелкой, указывающей на предка.

Реализация (realization) – это семантическое отношение между классификаторами, при котором один классификатор определяет обязательство, а другой гарантирует его выполнение. Отношение реализации встречаются в двух случаях: во-первых, между интерфейсами и реализующими их классами или компонентами, а во-вторых, между прецедентами и реализующими их кооперациями. Отношение реализации изображается в виде пунктирной линии с незакрашенной стрелкой, как нечто среднее между отношениями обобщения и зависимости.

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

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

Рис.1. Диаграмма вариантов использования ООО «Мир Компьютеров»

На данной диаграмме вариантов использования изображены актеры, варианты использования и отношения между ними для фирмы ООО "Мир Компьютеров".

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

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

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

На данной диаграмме рассматривается последовательность действий оформления заказа на товар у поставщиков (рис. 2).

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

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

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

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

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

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

Глава II. Функциональное проектирование информационной системы ООО "Мир Компьютеров"