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

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

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

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

Добавлен: 23.04.2023

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

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

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

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

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

Концептуальная модель UML. Сущности и связи

Существует обобщенная модель, представляющая из себя UML, она помогает разобраться в возможностях, особенностях и способах работы с языком. Ее условно можно разделить на три основных элемента:

  • Строительные блоки
  • Правила взаимодействий этих блоков
  • Общие механизмы построения, свойственные языку.

Строительные блоки в свою очередь подразделяются на три основные части:

  • Сущности (things)
  • Связи (relationships)
  • Диаграммы (diagrams)

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

Схема 1 Классификация сущностей

Структурные сущности представляют собой какие-либо статические данные/значения, представляющие собой какие-либо физические элементы. В совокупности эти элементы называют классификаторами.

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

Интерфейс (Interface) – играет роль сервисной части. Данный набор операций описывает интерфейс класса или его видимое пользователю поведению. Непосредственно на детальные свойства класса никак не влияет.

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


Варианты использования (use case) описание последовательности действий, при котором действующее лицо получает весомый результат вследствие выполнения системой алгоритма действий. Применяются для создания структур поведенческих сущностей.

Активные классы под это понятие попадают объекты, имеющие в свое распоряжении (или совершающие) несколько потоков и процессов единовременно.

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

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

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

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

Класс

Интерфейс

Кооперация

Варианты использования

Активные классы

Компоненты

Артефакты

Узлы


Таблица 2Графическое отображение структурных сущностей

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

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

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

Деятельность (activity) – третий тип поведенческих сущностей. Деятельность рассматривает непосредственно последовательность шагов, абстрагируясь от объектов. Отдельные шаг деятельности называется действием (action).

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

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

Аннотирующие сущности - представляют собой пояснительную часть модели, сопровождающую необходимые места в моделировании комментариями. Экземпляром данной сущности является примечание (note). Данный объект используется для пояснительного, иногда более неформального описания ряда других частей моделей, таких как класс, таблица, интерфейс и т. д...

Поведенческие сущности

Взаимодействия

Автомат (состояние)

Деятельность (действие)

Группирующие

Аннотирующие

Пакет

Примечание


Таблица 3 Графические обозначения поведенческих, группирующих и аннотирующих сущностей.

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

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

  1. Зависимость.
  2. Ассоциация.
  3. Обобщение.
  4. Реализация.

Зависимость (dependency) – указывает на взаимоотношения между двумя объектами, выраженными зависимостью. То есть при изменении одного, в обязательном порядке меняется второе.

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

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

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

Данные четыре элемента представляют собой основу взаимосвязей элементов в модели UML. Их графическое отображение показано на рис.6.

Рисунок 6 Графическое отображение связей в UML.

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

    1. Диаграммы UML и их виды

В рамках данной работы мы рассмотрим восемь типов диаграмм:

  1. Диаграмма вариантов использования или прецедентов (use case diagram)
  2. Диаграмма классов (class diagram)
  3. Диаграмма состояний (statechart diagram)
  4. Диаграммы взаимодействия (interaction diagrams
  5. Диаграмма деятельности (activity diagram)
  6. Диаграмма пакетов (package diagram
  7. Диаграмма компонентов (component diagram
  8. Диаграмма размещения (deployment diagram)

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

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

Мы приведем пример взаимодействия пользователя с часами на рис. 7.

У действующего лица есть несколько вариантов взаимодействия, конкретно: «включение будильника», «отключение будильника», «изменение формата времени» и «изменение мелодии сигнала».

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

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

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

Рисунок 8 Использование диаграмм классов на примере лампы.

Кроме того, классы на время разработки могут быть сгруппированы в пакеты по некоторым общим признакам. Некоторые из них – «интерфейсная часть», «системная часть», «контроллер». Пример выделение пакета – «система» продемонстрирован на рис. 9.

Рисунок 9 Пример объединения объектов в "пакет".

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

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