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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

На рисунке 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 диаграмма - диаграмма вариантов использования. Прежде чем рассматривать диаграмму, познакомимся с вариантами использования (ВИ). Вариант использования фиксирует соглашение между участниками системы о ее поведении.

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

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

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

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

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

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

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

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

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

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

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

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