Основные виды диаграмм, применяемые в IT
г. Старый Оскол
Войти
Сайт системного аналитика
Заказать звонок

Основные виды диаграмм, применяемые в IT

Самые читаемые
21 июн 2023
21 июн 2023
21 июн 2023
12 дек 2022
28 ноя 2022
25 окт 2022
#Моделирование

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

Введение

К таким способам относятся:

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

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

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

Модели визуального представления

К моделям визуального представления относятся:

  • Диаграммы «сущность — связь» (entity-relationship diagrams, ERD)
  • USE CASE диаграммы
  • Диаграммы классов
  • Диаграммы последовательности

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

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

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

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

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

Тип слова Примеры Компоненты модели анализа
Существительные Люди, организации, системы ПО,
элементы данных или существующие объекты
Объекты или хранилища данных (диаграммы потоков данных)
Действующие лица (диаграммы вариантов использования)
Объекты или их атрибуты (диаграммы “сущность - связь”)
Классы или их атрибуты (диаграммы классов)
Глаголы Действия, задачи, которые пользователь может выполнить, или события, которые могут произойти Процессы (диаграммы потоков данных, BPMN диаграммы)
Варианты использования (диаграммы вариантов использования)
Взаимосвязи (диаграммы “сущность - связь”)
Преобразования (диаграммы перехода состояний)
Процессы (диаграммы процессов, диаграммы последовательности)

Модель «сущность-связь»

Модель «сущность-связь» (Entity-Relationship model - ER-модель) – модель данных, позволяющая описывать концептуальные схемы предметной области.

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

Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.)

ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма сущность-связь (ER-диаграмма) (англ. entity-relationship diagram, ERD). Модель «сущность-связь» была предложена в 1976 году Питером Пин-Шен Ченом (англ. Peter Pin-Shen Chen), американским профессором компьютерных наук в университете штата Луизиана.

Анализ диаграммы «сущность — связь» помогает понять и связать компоненты данных компании или системы, не подразумевая, что в продукт будет обязательно включена база данных. И наоборот, когда вы создаете эту диаграмму в ходе разработки системы, вы определяете логическую или физическую структуру базы данных системы.

На диаграмме ER есть три основных элемента: сущность, атрибут, связь. Существует больше элементов, которые основаны на основных элементах. Это слабая сущность, многозначный атрибут, производный атрибут, слабая связь и рекурсивная связь.

Элементы ER диаграммы
Рис.1

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

Атрибут – это свойство, черта или характеристика сущности, связи или другого атрибута. Сущность может иметь столько атрибутов, сколько необходимо. В то же время, атрибуты могут иметь свои собственные специфические атрибуты. Например, в атрибуте “Адрес клиента” (Рис.2) может быть указан номер атрибута, улица, город и штат. Это называется составными атрибутами.

Составные атрибуты
Рис.2

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

Диаграмма «Сущность – связь»
Рис.3

На рисунке 3 показана часть диаграммы «сущность – связь» для Системы создания проектов с использованием одной из нескольких применяемых для диаграмм такого типа систем обозначений. Объект представляет действующее лицо – сотрудника, взаимодействующего с системой (Сотрудник, работающий в отделе и выполняющий проекты).

Каждый объект описывается несколькими атрибутами. У отдельных экземпляров объекта будут различные значения атрибутов. Например, в атрибуты сотрудника включен уникальный идентификатор, должность, ФИО.

Ромбы на диаграмме «сущность — связь» обозначают взаимоотношения (relationships), показывающие логические и числовую связь пар объектов. Названия взаимоотношениям даются в соответствии с природой соединений. Например, взаимоотношения между элементами «Сотрудник» и «Отдел» определяются как “работать”. Вы можете прочитать это взаимоотношения как «Сотрудник работает в Отделе».

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

UML диаграммы

UML (англ. Unified Modeling Language — унифицированный язык моделирования) – язык графического описания для:

  • объектного моделирования в области разработки программного обеспечения;
  • моделирования бизнес-процессов;
  • моделирования системного проектирования;
  • отображения организационных структур.

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

UML 2.4.1 принят в качестве международного стандарта ISO/IEC 19505-1, 19505-2 Текущая версия 2.5.1

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

  • Структурные диаграммы:
    • диаграмма классов;
    • диаграмма компонентов;
    • диаграмма композитной/составной структуры;
    • диаграмма кооперации (UML 2.0);
    • диаграмма развёртывания;
    • диаграмма объектов;
    • диаграмма пакетов;
    • диаграмма профилей (UML 2.2).
  • Диаграммы поведения
    • диаграмма деятельности;
    • диаграмма состояний;
    • диаграмма вариантов использования;
    • диаграммы взаимодействия:
      • диаграмма коммуникации (UML 2.0);
      • диаграмма обзора взаимодействия (UML 2.0);
      • диаграмма последовательности;
      • диаграммы синхронизации (UML 2.0).

USE case диаграмма

Диаграмма вариантов использования (англ. use case diagram) в UML – диаграмма, отражающая отношения между акторами и ВИ (прецедентами) и являющаяся составной частью модели прецедентов, позволяющей описать систему на концептуальном уровне.

Use case диаграмма - диаграмма вариантов использования. Прежде чем рассматривать диаграмму, познакомимся с вариантами использования (ВИ). Вариант использования фиксирует соглашение между участниками системы о ее поведении.

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

Варианты использования применяются для выявления требований к поведению системы.

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

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

USE CASE диаграмма. Рис.4
Рис.4

Если актору доступны несколько вариантов использования, то к каждому из них отдельная линия (не стрелка!)

Use Case диаграмма. Рис.5
Рис.5

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

Use Case диаграмма. Рис.6
Рис.6

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

Use Case диаграмма. Рис.7
Рис.7

Обобщение возможно также между акторами. На следующем рисунке показано, что у системы есть два актора: обычный пользователь и администратор. Если согласно требованиям администратор должен иметь возможность делать все то, что и обычный пользователь и плюс что-то еще. Например, он должен иметь возможность удалять документ из облака. Вместо того, чтобы соединять актора “администратор” со всеми вариантами использования, которые доступны обычному пользователю, можно упростить диаграмму: администратор обобщает пользователя. В итоге получается, что администратор в наследство получает все, что доступно пользователю. В обратную сторону ситуация не симметрична: пользователь не может удалить документ из облака.

Use Case диаграмма. Рис.8
Рис.8

Помимо операции “обобщения” есть еще два вида зависимостей. Зависимости в нотации UML рисуются пунктирной линией и незакрашеной стрелкой. Первый вид зависимости – включение (include). Такая зависимость означает выполнение включаемого варианта использования является обязательным. В данном случае показано открытие документа с выполнением обязательного варианта использования “Выбрать имя документа”. Стрелка рисуется в направлении включаемого варианта использования с подписью <<include>> или <<включить>>.

Use Case диаграмма. Рис.9
Рис.9

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

Use Case диаграмма. Рис.10
Рис.10

Следующая зависимость называется расширение (рис. 11). Отличие от предыдущего варианта зависимости в том, что вместо обязательности здесь опциональность. Например, при открытии документа на просмотр я могу его отредактировать, а могу и нет. Чаще всего расширение ставится когда вариант находится внутри основного сценария. Если же опциональность находится в конце после последнего шага основного сценария, то можно это сделать отдельным вариантом использования. Такая диаграмма выглядела бы следующим образом: никакого расширения не было бы, от пользователя была связь к редактированию документа, но при описании текстового варианта использования в начальном условии было бы записано: выполнен вариант использования “открыть документ для просмотра”.

Use Case Диаграмма. Рис. 11
Рис.11

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

Use Case Диаграмма. Рис.12
Рис.12