Сущности являются основными объектно-ориентированными элементами языка. С их помощью можно создавать корректные модели. В 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 - это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями). Основная цель диаграмм - визуализация разрабатываемой системы с разных точек зрения. Диаграмма - в самом общем смысле некоторый срез системы. Обычно, за исключением самых простых моделей, диаграммы дают свернутое представление элементов, из которых состоит разрабатываемая система. Один и тот же элемент может присутствовать во всех диаграммах, или только в нескольких (самый часто встречающийся вариант), или не присутствовать ни в одной (очень редко).

UML поддерживает построение следующих диаграмм:

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

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

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

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

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

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

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

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

Диаграммы активности.

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

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

Диаграммы классов (class diagram) показывают классы, интерфейсы, объекты и кооперации, а также их отношения. При моделировании объектно-ориентированных систем этот тип диаграмм используют наиболее часто.

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

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

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

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

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

По причине того, что диаграммы Sequence и Collaboration являются разными взглядами на одни и те же процессы, Rational Rose позволяет создавать из Sequence диаграммы диаграмму Collaboration и наоборот, а также производит автоматическую синхронизацию этих диаграмм.

Диаграммы компонент. Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при физическом проектировании системы. Часто данный тип диаграмм называют диаграммами модулей.

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

Диаграммы топологии. Этот вид диаграмм предназначен для анализа аппаратной части системы, то есть "железа", а не программ. В прямом переводе с английского Deployment означает "развертывание", но термин "топология" точнее отражает сущность этого типа диаграмм.

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

Обычно этот тип диаграмм используется в самом начале проектирования системы для анализа аппаратных средств, на которых она будет эксплуатироваться.

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

1. Цель создания диаграмм на языке UML - не рисование красивых картинок, а визуализация, специфицирование, конструирование и документирование. Диаграммы - это только одно из средств, но не все диаграммы необходимо сохранять. Иногда стоит создавать их на лету путем опроса элементов модели использовать для анализа системы по мере ее построения.

2. Следует избегать избыточных диаграмм, они только загромождают модель.

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

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

5. Не следует делать диаграммы очень большими или очень маленькими.

6. У каждой диаграммы (и у любой сущности) должно быть осмысленное имя, ясно отражающее ее назначение.

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

Соответственно, Rational Rose 2000 является инструментом, который позволяет строить указанные диаграммы при проектировании программных систем. К сожалению, объем статьи не позволяет описать назначение всех диаграмм и спецификаций! Но мы попробуем разобраться в инструменте с точки зрения разработчика, для простоты используя только один тип диаграмм - Class Diagramm.

Все разработчики сталкиваются с ситуацией, когда приходится проектировать большие классы. При ручном вводе и объявлении имеется ряд подводных камней: во-первых, постановщик задач, как правило, описывает "что нужно" на словах, в крайнем случае, с минимальным бумажным сопровождением; во-вторых, разработчик, создающий систему, опять-таки в большинстве случаев игнорирует все комментарии, которыми необходимо сопровождать программный код. Что же получается в итоге? Постановщик задач путается в программе, разработчик сам не помнит, что к чему, а если на его место взят новый сотрудник. … Тут на ум приходит еще одно традиционное для России высказывание разработчика: "мне проще все написать заново”. И ведь пишут. … Тормозя производство программного продукта. Дело в том, что к разработке ПО относятся как к искусству, а необходимо относиться, как к производственному процессу со строгим распределением ролей, полномочий и пр…

Аспекты совместной работы с Oracle

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

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

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

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

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

Возможности Rational Rose