Файл: ПРИМИНЕНИЕ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПОДХОДА ПРИ ПРОЕЕКТИРОВАНИИ ИНФОРМАЦТОННОЙ СИСТЕМЫ.pdf

1. Диаграммы – группируют сущности. Основными в языке UML являются диаграммы:

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

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

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

В языке UML имеется набор правил, называемый семантическим, который корректно определяет:

• Имена сущностей
• Область действия
• Видимость
• Целостность
• Выполнение

Основные составляющие диаграмм UML

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

---

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

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

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

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

Тип – это стереотип класса, который используется для определения области значений объектов вместе с их операциями

Роль - это поведение сущности в данном контексте.

Графически интерфейс изображается в виде кружочка с именем данного интерфейса.

Для того чтобы отличить интерфейс от класса, в начало его имени добавляют «I», тоже самое делают и с типами добавляя в начало «T».

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

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

---

+ (плюс) - открытый элемент (все открытые элементы составляют интерфейс пакета)

# - защищенный элемент

- (минус) – закрытый элемент

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

Состояние объекта – совокупность свойств и текущих значений. В свойства входят: атрибуты объекта все его агрегированные части.

Диаграммы объектов

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

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

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

• Объекты
• Связи

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

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

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

---

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

Кооперация – это сообщество с определенными ролями объектов, совместное поведение которых более значимо, чем сумма его слагаемых.

Роли – это прототипы классов, компонентов, интерфейсов, прецедентов и узлов, аспекты которых визуализируются, конструируются, специфицируются и документируются в виде потоков управления.

Взаимодействия моделируются двумя методами:

• Концентрируясь на временной упорядоченности сообщений
• Концентрируясь на последовательность сообщений в контексте структуре объекта.

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

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

Взаимодействия анализируют потоки по двум критериям:

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

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

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

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

• Association – объект видим для ассоциации
• Self – объект видим, так как является диспетчером для ассоциации
• Global – объект видим глобально
• Local – объект видим локально
• Parameter – объект виден, потому что является параметром

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

UML позволяет выполнять несколько видов действий:

Call – вызвать

Return – вернуть

Send – послать

Create – создать

Destroy – уничтожить

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

---

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

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

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

Сообщения и объекты во взаимодействии визуализируются двумя способами:

1. Концентрируя внимания на временном порядке сообщений (называется диаграммой последовательности)
2. Акцентируя внимание на структурной организации объектов присылающих и отправляющих сообщения (является разновидностью диаграмм коопераций)

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

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

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

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

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

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

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

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

---