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

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

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

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

Добавлен: 21.05.2023

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

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

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

Кроме всего остального, язык UML не считается языком зрительного программирования, но модели, разработанные с его поддержкой, имеют все шансы быть переведены на всевозможные языки программирования. Модель, построенную на базе языка UML, возможно переместить на надлежащие языки программирования: Java, C++, Visual Basic, и в том числе и предположить в облике таблиц реляционной базы данных или же устойчивые объекты объектно-ориентированной базы данных.

Словарь языка UML состоит из трех блоков:

  • сущности;
  • отношения;
  • диаграммы.

Сущности - это абстракции, являющиеся основными элементами модели. Отношения связывают различные сущности; диаграммы группируют представляющие интерес совокупности сущностей.

Отношения бывают следующих типов:

  1. Обобщение.
  2. Ассоциации
  3. Агрегации
  4. Композиции
  5. Зависимости
  6. Реализации

В UML выделяют девять типов диаграмм:

  • диаграммы классов;
  • диаграммы вариантов использования;
  • диаграммы прецедентов;
  • диаграммы последовательностей;
  • диаграммы кооперации;
  • диаграммы состояний;
  • диаграммы действий;
  • диаграммы компонентов;
  • диаграммы развертывания.

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

  1. Диаграмма вариантов использования (UML – модель) используется для представления концептуальной модели проектируемой системы, которая описывает ее функциональное назначение.

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

Диаграмма строится на основе следующих компонентов:

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

Use case (варианты использования) – служат для описания сервисов, которые система предоставляет актерам. Каждый такой вариант использования описывает набор действий, выполняемых системой при взаимодействии с актером.

Relationships (связи или отношения) – используются для обозначения отношений между компонентами модели.

Связи бывают следующих видов:

  • Ассоциация – единственно возможная связь между актером и ВИ. Ассоциативная связь специфицирует особенности взаимодействия актера и варианта использования. Она показывает, что актер и ВИ общаются друг с другом, посылая и получая сообщения. Если ассоциация направленная, она показывает направление передачи сообщения. Изображается в виде сплошной линии.
  • Отношение обобщения между двумя вариантами использования означает, что когда осуществляется дочерний вариант использования, необходимо исполнение и родительского. В общем случае для того, чтобы создание родительского ВИ имело смысл, необходимо, чтобы у него было бы хотя бы два дочерних. Единственное исключение – это, когда имеются два ВИ и один из них является детализацией другого, но оба могут осуществляться независимо.
  • Отношение включения, помечаемое стандартом <>, обозначает, то что с целью абсолютного реализации главного (базисного) ВИ следует осуществление также вводимого варианта. В общем случае выделение включаемых ВИ будет целесообразным в тех случаях, когда такой вариант включается в несколько базовых. Об отношении включения “знает” только базовый вариант использования, но никак, однако не применяется.

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

Notes (примечания) - произвольные текстовые комментарии разработчика, имеющие отношение к компонентам Use case – диаграммы. Структурные элементы данной диаграммы представлены в приложении А.

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

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

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

Рисунок 1 – Вид сообщения в поведенческой сущности

Аннотирующие сущности – это части, которые поясняют UML-модели, иными словами, комментарии, используемые для пояснения и выделения некоторого элемента модели. Главной такой сущностью является примечание. В нем отображаются ограничения и комментарии, относящиеся к элементу или набору элементов. Графически представляется прямоугольником с загнутым углом, внутри которого помещается соответствующий комментарий. На рисунке 2 представлено его изображение.

Рисунок 2 – Вид комментария

К структурным сущностям следует относить классы, атрибуты и операции. Опишем каждую из них более подробно.

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

Изображается в виде прямоугольника, разделенного на 3 блока горизонтальными линиями, в которых указывается: имя класса, атрибуты и методы. На рисунке 3 представлен пример класса.


Рисунок 3 – Вид класса

Операции и атрибуты имеют один из трех типов видимости: private (частный), protected (защищенный), public (общий). Она указывается в виде левого символа в строке с именем элемента.

Каждый класс должен обладать своим уникальным идентификатором, в качестве которого выступает имя. Это текстовая строка. Имя не имеет ограничений по длине, содержимому и может записываться в несколько строк.

Имя класса традиционно пишется с заглавной буквы. Пример представлен на рисунке.

Для абстрактного класса имя пишется курсивом.

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

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

Существуют четыре типа отношений между классами:

Зависимость – связь между двумя элементами модели, в которой при изменении одного элемента может привести к изменению семантики другого элемента. Графически представляется в виде пунктирной линии со стрелкой. На рисунке 4 представлен ее вид.

Рисунок 4 – Отношение зависимости

Ассоциация – связь между элементами модели, которая описывает набор связей, между объектами в модели. К примеру, например, класс Человек и класс Среднее учебное заведение имеют ассоциацию, например, как человек имеет возможность обучаться в школе. Ассоциации возможно присвоить имя «учится в». В представлении однонаправленной ассоциации прибавляется стрелка, указывающая на назначение ассоциации. На рисунке 5 представлен пример этой ассоциации.

Рисунок 5 – Отношение ассоциации

Еще связь содержит кратность. Она указывается вблизи с обозначениями связанных компонент диаграммы, и характеризует сплошное численность экземпляров соответственного компонента, которые имеют все шансы играть в качестве составляющих предоставленной ассоциации. Записывается в облике выражения с наименьшим и предельным значением; для их деления применяются 2 точки. Ставя множественность далекого конца ассоциации, вы показываете, сколько объектов имеет возможность поприсутствуешь на далеком конце ассоциации для всякого объекта класса, оказавшегося на ближнем ее конце. Численность объектов надлежит пребывать в границах данного спектра. Множественность имеет возможность задаваться как кол 1, ноль или же раз 0..1, каждое смысл 0..* или же *, раз или же некоторое количество 1..*. Возможно еще задавать в облике интервала цельных значений, то есть это 2 количества разбитых точками. К примеру 2..5, или же ставить четкое количество, к примеру 3. На рисунке 6 представлен пример данного отношения, здесь используется диапазон целых значений.


Рисунок 6 – Множественная ассоциация

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

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

Графически агрегация представляется пустым ромбом на блоке класса «целое», и линией, идущей от этого ромба к классу «часть». На рисунке 7 представлено данное отношение.

Рисунок 7 – Отношение агрегации

Композиция — более строгий вариант агрегации. Известна также как агрегация по значению.

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

Графически представляется, как и агрегация, но с закрашенным ромбиком. На рисунке 8 представлено ее изображение.

Рисунок 8 – Отношение композиции

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

Рисунок 9 – Отношение обобщения

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


Рисунок 10 – Отношение реализации

Структурные элементы данной диаграммы представлены в приложении А.

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

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

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

  • entry – так называемое входное действие, действие, которое выполняется в момент входа в данное состояние;
  • exit – выходное действие, то есть это действие, которое выполняется в момент выхода из данного состояния;
  • do – выполняющаяся деятельность ("do activity") в течение всего времени, пока объект находится в данном состоянии;
  • defer - событие, обработка которого предписывается в другом состоянии, но после того, как все операции в текущем будут завершены.

При использовании диаграммы состояний важно следовать следующим правилам:

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