Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (1. Объектно-ориентированные методы анализа и проектирования информационных систем).pdf

Пример диаграммы прецедентов приведен на рисунке 1.

Рисунок 1. Пример диаграммы прецедентов

2.3 Диаграммы деятельности (activity diagram)

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

Старт выполнения прецедента обозначается заполненным кружком, а конец – кружком в окружности. Старт у прецедента может быть только один на всю диаграмму деятельности, тогда как точек окончания может быть сколько угодно (но не менее одной). Сами действия обозначаются скругленными прямоугольниками, а ветвления – ромбами. Пример диаграммы деятельности приведен на рисунке 2.

Рисунок 2. Пример диаграммы деятельности

2.4 Диаграмма классов (class diagram)

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

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

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

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

Помимо имени и типа каждый атрибут характеризуется видимостью (visibility). Эта характеристика показывает, виден ли (т.е. доступен ли) атрибут для других классов. В UML имеется 3 типа видимости атрибутов классов:

• Открытый (public) – атрибут виден для любого другого класса (объекта);
• Защищенный (protected) – атрибут виден для потомков данного класса;
• Закрытый (private) – атрибут не виден внешними классами (объектами) и может использоваться только объектом, его содержащим.

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

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

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

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

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

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

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

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

Пример диаграммы классов приведен на рисунке 3.

Рисунок 3. Пример диаграммы классов

2.5 Диаграмма состояний (statechart diagram)

Диаграмму состояний часто рассматривают в контексте конечного автомата. Тогда можем сказать, что диаграмма состояний (Statechart diagram) показывает автомат, фокусируя внимание на потоке управления от состояния к состоянию.

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

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

Для поиска состояний класса можно просматривать атрибуты этого класса. Хорошим индикатором состояний является такой атрибут класса как «статус».

Диаграмма состояний изображается в виде графа с вершинами и ребрами.

Пример диаграммы класса приведен на рисунке 4.

Рисунок 4. Пример диаграммы состояний

2.6 Диаграммы взаимодействия (interaction diagrams)

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

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

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

– диаграммы последовательности (sequence diagrams);

– кооперативные диаграммы (collaboration diagrams).

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

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

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

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

Пример диаграммы деятельности приведен на рисунке 5.

Рисунок 5. Пример диаграммы взаимодействия

2.7 Диаграмма пакетов (package diagram)

Пакет (package) — общецелевой механизм для организации различных элементов модели в группы.

Подпакет (subpackage) — пакет, который является составной частью другого пакета.

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

Объединять классы в пакеты можно как угодно, однако, существует несколько наиболее распространенных подходов:

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

В дальнейшем можно вкладывать пакеты друг в друга.

Пример диаграммы пакетов приведен на рисунке 6.

Рисунок 6. Пример диаграммы пакетов

Глава 3. Средства реализации объектно-ориентированного моделирования информационных систем

3.1 IBM Rational Rose

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

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

Базовым продуктом является IBM Rational Rose Enterprise Edition, который обладает наиболее полным набором возможностей.

Среди особенности Rational Rose стоит отдельно выделить:

• хорошая интеграция с Microsft visual Studio, которая заключается в возможностях прямой генерации программного кода на основе диаграмм (и нaоборот);
• возможность непосредственной работы с исполняемыми модулями и библиотеками (представленных в форматах EXE, DLL, TLB, OCX);
• поддержка технологии доступа к данным ADO (одной из самых популярных среди разработчиков для операционной системы Windows), а также элементов технологии DCOM;
• полная поддержка языка программирования Java: двусторонняя генерация как программного кода на основе диаграмм, так и диаграмм на основе кодов из файлов формата *.jar.