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

ВУЗ: Не указан

Категория: Курсовая работа

Дисциплина: Не указана

Добавлен: 14.03.2024

Просмотров: 44

Скачиваний: 0

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

2.2 Диаграмма вариантов использования (use case diagram)

Построение объектно-ориентированной модели на языке UMLчаще всего начинают с составления диаграммы прецедентов (или вариантов использования).

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

Под актером (actor) подразумевается любая внешняя сущность, которая каким-то образом взаимодействует с системой (использует ее). Актер – это не обязательно пользователь системы, это может быть совокупность логически объединённых ролей пользователей, программа, техническое устройство или другая системы. Стандартное изображение актера на диаграмме вариантов использования – фигура в виде «человечка».

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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