Как составить диаграмму для информационной системы

Время на прочтение
8 мин

Количество просмотров 49K

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

Задача архитектора решений ― четко донести проект системы до бизнеса, руководителей проектов и разработчиков. Нельзя просто нарисовать одно изображение, это невозможно и не принесет никому пользы. Вместо этого лучше сгруппировать различные проблемы и создать набор диаграмм, описывающих каждое представление. Конечно, есть миллиард способов сделать это. Как выбрать подходящий? За время работы в качестве архитектора решений я чаще всего использовал 5 диаграмм: контекстную диаграмму C4, диаграмму контейнеров, развертывания, последовательности и вариантов использования. В этой статье я рассмотрю подробно каждую из них.

Контекстная диаграмма

Веб-сайт, посвященный модели С4 (Context, Container, Component and Code), довольно хорошо объясняет свои диаграммы, я же поделюсь своим представлением, как эта модель работает.

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

Пример

На этой диаграмме показана цифровая платформа необанкинга, представленная синим прямоугольником в центре.

Как рисовать

• Определите пользователей.

• Определите внешние системы.

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

• Добавьте связи между системой, пользователями и внешними системами.

• Напишите содержательные комментарии по каждому компоненту.

Инструменты

Существуют различные инструменты, которые можно использовать для создания контекстной диаграммы. Существуют трафареты C4 для OmniGraffle, примеры C4 для LucidChart, шаблоны есть также в draw.io. Чтобы использовать диаграммы как код, попробуйте PlantUML.

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

@startuml
!includeurl https://raw.githubusercontent.com/RicardoNiepel/C4-PlantUML/master/C4_Context.puml
' uncomment the following line and comment the first to use locally
' !include C4_Context.puml


Person(customer, "Customer", "A bank client")
System(abc_system, "Digital Platform", "Allows freelancers and business owners see their transactions.")

System_Ext(idnow, "IDNow", "System for KYC and Qualified Eletronic Signatures")
System_Ext(pay, "Google Pay/Apple Pay", "Google Pay and Apple Pay systems")
System_Ext(dms, "DMS", "Document Management System")
System_Ext(crm, "CRM", "CRM")
System_Ext(current, "Existing Banking System", "Banking Backoffice")

Rel(abc_system, pay, "uses")
Rel(customer, abc_system, "Uses")


Rel_L(abc_system, idnow, "integrates")
Rel_Neighbor(abc_system, dms, "uploads files")
Rel_D(abc_system, crm, "integrates")
Rel_U(abc_system, current, "uses")

@enduml

Мы определяем человека, систему, внешние системы и отношения между ними. Предикаты Person, System и System_ext имеют 3 параметра: ключ, заголовок и описание. Предикат Rel также имеет 3 параметра, но они разные: ключ одной сущности, ключ другой и тип отношений между сущностями.

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

Важно

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

Я боролся с контекстной диаграммой для одной банковской системы. Она должна была включать только недавно созданную систему и одного клиента, который не принесет никакой ценности. После согласования я добавил API Gateway и существующий Auth Provider, который мы собирались использовать. Таким образом, контекстная диаграмма стала обретать смысл и позволяла опустить эти элементы из диаграмм нижнего уровня.

Алексей, архитектор решений

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

Джон, архитектор решений.

Резюме

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

Диаграмма контейнеров

Контейнеры здесь не означают обязательно докер-контейнеры. Контейнер — это любой развертываемый объект или хранилище данных с точки зрения C4. Это может быть мобильное приложение, веб-сайт, виртуальная машина, докер-контейнер, база данных или хранилище объектов; все, что вы можете развернуть. По моему опыту эта диаграмма – самая сложная, а потому привлекает к себе особое внимание. Это, можно сказать, главная диаграмма, над которой нужно работать!

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

Пример

Как рисовать      

• Определите список сущностей: микросервисы, хранилища, внешние сервисы.

• Поместите их на диаграмму.

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

• Добавьте соединения со стрелками.

• Добавьте значимые метки к каждой стрелке.

• Подберите цвет схемы.

• Создайте легенду.

Инструменты

То же, что и для контекстной диаграммы: Draw.io, OmniGraffle, LucidChart и другие.

Важно

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

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

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

• Очень распространенный вопрос, когда используешь облака, включать ли вы управляемые сервисы, такие как очереди сообщений? Я обычно отвечаю: «Нет». Это усложняет диаграмму, делает её нечитабельной. Если некоторые сервисы обмениваются данными через очередь сообщений, отобразите её с помощью стрелки отдельного типа.

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

Илья, архитектор предприятия.

Резюме

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

Диаграмма последовательностей

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

Пример

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

Как рисовать

• Выберите функцию (вход, покупка и т. д.).

• Определите сущности, участвующие в этом процессе.

• Поместите их на диаграмму.

• Добавьте взаимодействие (стрелки).

• Добавьте ценные комментарии к каждой стрелке.

Инструменты

К сожалению, OmniGraffle не подходит для диаграмм последовательности. Поэтому для создания этой диаграммы я использую draw.io и LucidChart. Последний вариант является хорош тем, что вы можете рисовать диаграмму вручную или использовать диаграмму последовательности UML.

Важно

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

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

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

Владимир, Архитектор решений

Резюме

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

Диаграмма развертывания

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

Есть несколько разных вещей, которые необходимо отобразить.

• Вычислительные ресурсы. Это могут быть виртуальные машины, докеры, кластеры Kubernetes и облачные функции. Мобильные устройства и настольные компьютеры также можно рассматривать как вычислительные ресурсы.

• Хранилища. Постоянные хранилища данных, такие как реляционные базы данных и базы данных nosql, хранилища двоичных файлов, таких как изображения, музыка и видео, хранилища больших данных и так далее.

• Ресурсы обмена сообщениями. Установки Kafka / RabbitMQ, Google Cloud pub / sub, AWS SQS и другие.

• Сети. Ваши компьютеры используют сети для связи друг с другом. Должны отображаться как физические, так и виртуальные сети.

• Зоны доступности. Вы можете думать о них как о центрах обработки данных.

• Узлы инфраструктуры. DNS-серверы, балансировщики нагрузки, брандмауэры, сети CDN

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

Как нарисовать

• Разместите основные блоки: браузеры, мобильные устройства, общедоступное облако, центры обработки данных.

• Разместите вычислительные ресурсы и ресурсы хранения.

• Добавьте узлы инфраструктуры.

• Добавьте сети.

• Добавьте сетевые вызовы между узлами.

• Добавьте ресурсы мониторинга.

Пример

В C4 нотации есть дополнительная диаграмма развертывания:

Обратите внимание на имена вычислительных ресурсов, их типы и номера узлов.

Другой пример для облака AWS:

Инструменты

Существует множество инструментов для создания схемы развертывания. OmniGraffle, LucidChart, Draw.io и другие прекрасно справляются с этой задачей, если установлены соответствующие шаблоны.

Важно

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

Резюме

Диаграмма развертывания дополняет понимание системы с точки зрения внешнего вида.

Диаграмма вариантов использования

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

Как рисовать

• Нарисуйте прямоугольник. Это будет граница системы.

• Определите, кто будет работать с системой.

• Добавьте варианты использования внутри системы с помощью овалов.

• Добавьте связи между участниками и вариантами использования.

Примеры

Инструменты

Архитектор может нарисовать диаграмму с помощью любого графического редактора и того же набора инструментов, что и для других диаграмм. Omnigraffle, LucidChart, Draw.io работают хорошо. Помните, что эта диаграмма является структурированной, поэтому вы можете использовать UML для её создания. В этом помогает PlantUml или LucidChart.

Резюме

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

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

• Масштабируйте внутренние компоненты системы с помощью контейнеров и диаграмм развертывания.

• Документируйте конкретные бизнес-кейсы с помощью диаграмм последовательности.

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

Границы системы, акторы и варианты использования: что такое диаграмма Use Case

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

В качестве иллюстративного примера рассмотрим систему онлайн-оплаты учебного курса. Пользователем этой системы является клиент. В терминологии UML он будет называться актор – сущность за пределами системы, которая взаимодействует с ней. На UML-диаграмме Use Case он изображается в виде человечка. Актору «Клиент» доступен основной вариант использования – «Оплатить договор» (на проведение обучающего курса по бизнес-анализу).  Расширением этого варианта использования является «Оплатить со скидкой по промокоду», который уменьшает сумму платежа. Этот вариант использования является опциональным и расширяет основной, поэтому он будет связан с основным через связь extend, которая выглядит как пунктирная стрелочка с соответствующей надписью.

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

Ликбез по ООП или как построить UML-диаграмму классов

UML соответствует объектно-ориентированной парадигме программирования (ООП), ключевым понятием которой является класс. Класс – это абстракция сущностей с одинаковыми свойствами (атрибутами, полями) и поведением (методами, функциями). Классы могут быть связаны друг с другом через наследование и ассоциации. При наследовании класс-потомки имеют (наследуют) атрибуты и методы класса-родителя, а также свои собственные. А конкретные значения этих атрибутов задаются в реализации классов в виде их отдельных экземпляров, называемых объектами. Например, ООО «Рога и Копыта» и Иванов Иван Иваныч – это конкретные реализации классов «Юрлицо» и «Физлицо» соответственно. В частности, у объекта класса Физлицо есть поля с паспортными данными (ФИО и № паспорта), а у юрлица обязательно должны быть название и ИНН. При этом оба этих класса наследуют от родителя (Класс «Клиент») общие для них атрибуты (тип, номер телефона, email и адрес).

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

Таким образом, в нашей системе интернет-оплаты договора с применением промокода по конкретному курсу будут следующие классы:

• Клиент – абстрактный класс-родитель для классов «Юрлицо» и «Физлицо»;
• Физлицо;
• Юрлицо;
• Договор;
• Курс;
• Промокод;
• Платеж.

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

Теперь, имея диаграмму классов, которая на концептуальном уровне описывает доменную область проектируемой системы, можно показать, как объекты разных классов взаимодействуют друг с другом на UML-диаграмме последовательности (Sequence).

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

А в заключение покажем, как выглядит жизненный цикл объектов класса «Промокод» с помощью UML-диаграммы состояний (StateChart или State Machine). На мой взгляд, из всех UML-диаграмм она самая простая и понятная без дополнительных объяснений. Начиная со стартового события, объект последовательно проходит разные стадии жизненного цикла, меняя свое состояние в зависимости от некоторых условий.

Как описать архитектурные аспекты проектируемой информационной системы с помощью UML, читайте в нашей новой статье.

Проверить свои знания UML вы можете прямо на нашем сайте, выполнив бесплатный интерактивный тест.

Открытый тест по UML: основы бизнес-анализа для начинающих

А научиться самостоятельно разрабатывать эти и другие UML-диаграммы вам поможет специализированный курс «UML для бизнес-аналитиков». Только практика на реальных примерах. После 8-часового интенсива вы сможете дополнять текстовые схемы представления требований User Story и Use Case UML-диаграммами вариантов использования и детализировать их далее в диаграммы деятельности, последовательности и состояний, чтобы наглядно объяснить разработчикам, что именно должна делать программная система.

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

• Диаграмма классов
• Диаграмма компонентов
• Схема развертывания
• Диаграмма объекта
• Схема пакета
• Схема составной структуры
• Диаграмма профиля

Что такое диаграмма классов?

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

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

UML — это нотация, возникшая в результате объединения OMT с

1. Техника объектного моделирования OMT  [ James Rumbaugh  1991] – лучше всего подходит для анализа и информационных систем с интенсивным использованием данных.
2. Booch [ Gradi Booch  1994] — отлично подходил для дизайна и реализации. Грэди Буч много работал с  языком Ада  и был главным игроком в разработке объектно-ориентированных методов для этого языка. Хотя метод Буча был сильным, нотация была принята хуже (в его моделях преобладало множество форм облаков — не очень аккуратно).
3. OOSE (Object-Oriented Software Engineering [ Ivar Jacobson  1992]) — включает модель, известную как варианты использования. Сценарии использования — это мощная техника для понимания поведения всей системы (область, в которой объектно-ориентированный подход традиционно был слабым).

В 1994 году Джим Рамбо, создатель OMT, ошеломил мир программного обеспечения, когда он покинул General Electric и присоединился к Грэди Бучу в Rational Corp. Целью партнерства было объединить их идеи в единый унифицированный метод (рабочее название метод действительно был «унифицированным методом»).

Назначение диаграммы классов

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

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

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

Пример класса

У собаки есть состояния – цвет, имя, порода, а также поведение – виляние, лай, еда. Объект является экземпляром класса.

Обозначение класса UML

Класс представляет концепцию, которая инкапсулирует состояние ( атрибуты ) и поведение ( операции ). Каждый атрибут имеет тип. Каждая  операция  имеет  подпись . Имя класса является  единственной обязательной информацией .

Имя класса:

• Имя класса появляется в первом разделе.

Атрибуты класса:

• Атрибуты показаны во втором разделе.
• Тип атрибута отображается после двоеточия.
• Атрибуты сопоставляются с переменными-членами (элементами данных) в коде.

Классовые операции (методы):

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

Классовые отношения

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

Имена отношений

• Имена отношений пишутся посередине ассоциативной строки.
• Названия хороших отношений имеют смысл, если прочитать их вслух:
  • «Каждая электронная таблица  содержит  некоторое количество ячеек»,
  • «выражение  оценивается  как значение»
• Они часто имеют  небольшую стрелку, указывающую направление,  в котором следует читать отношения, например, выражения оцениваются как значения, но значения не оцениваются как выражения.

Отношения — Роли

• Роль – это направленная цель ассоциации.
• Роли написаны на концах ассоциативной линии и описывают цель, которую играет этот класс в отношениях.
  • Например, ячейка связана с выражением. Характер связи таков, что выражением является  формула  клетки.

Судоходность

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

Диаграмма выше предполагает, что,

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

Видимость атрибутов класса и операций

В объектно-ориентированном дизайне есть нотация видимости атрибутов и операций. UML определяет четыре типа видимости:  public ,  protected ,  private и  package .

Символы +, -, # и ~ перед именем атрибута и операции в классе обозначают видимость атрибута и операции.

• + обозначает общедоступные атрибуты или операции
• – обозначает частные атрибуты или операции
• # обозначает защищенные атрибуты или операции
• ~ обозначает атрибуты пакета или операции

Пример видимости класса

В приведенном выше примере:

• attribute1 и op1 MyClassName являются общедоступными
• attribute3 и op3 защищены.
• attribute2 и op2 являются частными.

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

Право доступа	общественный (+)	частный (-)	защищенный (#)	Пакет (~)
Члены одного класса	да	да	да	да
Члены производных классов	да	нет	да	да
Члены любого другого класса	да	нет	нет	в том же пакете

Множественность

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

• Ровно один — 1
• Ноль или единица – 0..1
• Многие – 0..* или *
• Один или несколько – 1..*
• Точное число — например, 3..4 или 6
• Или сложное отношение — например, 0..1, 3..4, 6.* будет означать любое количество объектов, кроме 2 или 5.

Пример множественности

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

Пример агрегации — компьютер и комплектующие

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

Пример наследования — таксономия ячеек

• Наследование — еще один частный случай ассоциации, обозначающей «своего рода» иерархию.
• Наследование упрощает модель анализа, вводя таксономию
• Дочерние классы наследуют атрибуты и операции родительского класса.

Диаграмма классов — пример инструмента диаграммы

Диаграмма классов может также иметь примечания, прикрепленные к классам или отношениям. Примечания отображаются серым цветом.

В приведенном выше примере:

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

1. Форма — это абстрактный класс. Он показан курсивом.
2. Форма — это суперкласс. Круг, прямоугольник и многоугольник являются производными от формы. Другими словами, Круг — это Форма. Это отношение обобщения/наследования.
3. Существует связь между DialogBox и DataController.
4. Форма является частью окна. Это агрегационные отношения. Shape может существовать без Window.
5. Точка является частью Круга. Это композиционные отношения. Точка не может существовать без Окружности.
6. Окно зависит от события. Однако Event не зависит от Window.
7. Атрибутами Circle являются радиус и центр. Это класс сущности.
8. Имена методов Circle: area(),circ(), setCenter() и setRadius().
9. Радиус параметра в Circle является параметром in типа float.
10. Метод area() класса Circle возвращает значение типа double.
11. Атрибуты и имена методов Rectangle скрыты. У некоторых других классов на диаграмме также скрыты атрибуты и имена методов.

Пример диаграммы классов: система заказов

Пример диаграммы классов: графический интерфейс

Диаграмма классов может также иметь примечания, прикрепленные к классам или отношениям.

Работа со сложной системой — диаграмма нескольких или одного класса?

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

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

Перспективы диаграммы классов в жизненном цикле разработки программного обеспечения

Мы можем использовать диаграммы классов на разных этапах  жизненного цикла разработки программного обеспечения  и, как правило, моделируя диаграммы классов в трех различных перспективах (уровнях детализации) постепенно по мере продвижения вперед:

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

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

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

Ищете бесплатный инструмент для построения диаграмм классов?

Visual Paradigm Online (VP Online) Free Edition — это бесплатное онлайн-программное обеспечение для рисования, которое поддерживает диаграммы классов, другие диаграммы UML, инструменты ERD и инструменты организационных диаграмм. Он имеет простой, но мощный редактор, который позволяет быстро и легко создавать диаграммы классов. В этом бесплатном редакторе UML нет рекламы, нет сроков доступа и нет ограничений, например, на количество диаграмм, количество фигур и т. д. Вы являетесь владельцем диаграмм, которые создаете для личных и некоммерческих целей.

Ищете более формальное моделирование UML на рабочем столе?

Visual Paradigm Community Edition был запущен в 2004 году для предоставления  бесплатного программного обеспечения UML  исключительно для некоммерческих целей, поддержки пользователей, которые делали свои первые шаги в моделировании UML и которым требуется бесплатное и кросс-платформенное программное обеспечение для моделирования UML для личного использования, например как применение UML в студенческих проектах.

Бесплатный инструмент моделирования UML для всех видов некоммерческих целей. Поддержка 13 диаграмм UML 2.x

Нас приняли более 1 миллиона установок по всему миру, и эта цифра продолжает расти. Многие люди используют платные версии Visual Paradigm для ежедневного рисования профессиональных диаграмм UML и ERD для проектирования и анализа систем и баз данных.

Причина 2

Доверие ИТ-специалистов и крупных организаций

Многие крупные организации, ИТ-компании, консультанты, университеты, неправительственные организации и правительственные учреждения по всему миру приняли Visual Paradigm (платные версии). На рисунке ниже показаны некоторые из наших платных клиентов.

Причина 3

Высокое качество – награда

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

Причина 4

Самая широко используемая платформа для моделирования в академических кругах.

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

Причина 5

Сотни примеров UML и ERD,  готовых для импорта в Visual Paradigm для мгновенного эксперимента или для начала работы с собственной моделью UML. Все бесплатно.

Причина 6

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

Простое обновление для огромного набора дополнительных функций (например, BPMN и поддержки совместной работы) и для коммерческого использования, начиная с  6 долларов США в месяц .

Причина 7

Форум активных пользователей для получения помощи и обмена идеями и опытом

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

Причина 8

Кроссплатформенное, удобное, быстрое и отзывчивое приложение

Visual Paradigm может работать на разных платформах, таких как Windows, Linux и Mac. Его интуитивно понятный интерфейс и мощные функции моделирования делают моделирование быстрым и легким!

В
настоящее время большинство проектов
информационных систем (ИС) разрабатывается
в соответствии с какой-либо методологией
разработки ПО. Как следствие, разработчикам
требуется инструмент для моделирования
данных на этапах анализа и проектирования.
Таким инструментом являются ER-диаграммы
(Entity-Relationship, «Сущность-Связь»). Фактически
их использование является обязательным
при разработке информационных систем.

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

Сущность
(Entity) – это объект, о котором в системе
будет накапливаться информация, например,
СТУДЕНТЫ или ПРЕПОДАВАТЕЛИ.

Атрибуты
– данные,
описывающие свойства сущности. Пример
атрибутов сущности СТУДЕНТЫ: ФИО,
домашний адрес, год рождения.

Совокупность
сущностей, характеризующихся в
информационной системе одним и тем же
перечнем свойств, называется классом
сущностей (набором объектов). Так,
например, совокупность всех сущностей
СТУДЕНТЫ составляет класс сущностей
СТУДЕНТЫ.

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

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

Таблица
1 – Преподаватель

Название атрибута	Тип данных	Длина в знаках	Диапазон принимаемых значений	Ключевое поле
Код преподавателя Фамилия преподавателя Имя преподавателя Отчество преподавателя Разряд Стаж работы	Счётчик Строковый Строковый Строковый Числовой Числовой	3 50 20 25 2 4	1-999 — — — 9 – 14 0-50	Да Нет Нет Нет Нет Нет

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

Процесс
построения ER-диаграммы называется
ER-моделированием.
При этом используются следующие
классические обозначения. Класс сущностей
представляется в виде четырехугольника,
в котором записано уникальное имя класса
сущности (прописными буквами) и имена
атрибутов строчными буквами. По типу
различают множественные связи «один
к одному» (1:1), «один ко многим»
(1:n) и «многие ко многим» (m:n).
ER–диаграмма, содержащая различные типы
связей, приведена на рисунке 6. Степень
связи определяется количеством сущностей,
которые охвачены данной связью.

Рис.
6 ER–диаграмма

Для
создания реляционной БД необходимо
определить:

1. сколько
   и каких таблиц должна включать БД;

2. сколько
   столбцов содержит каждая таблица;

3. какие
   атрибуты используются в качестве
   ключей;

4. как
   устанавливаются связи
   между
   разными таблицами:

1. использование
   в разных таблицах одного и того же
   ключа;

2. помещение
   ключа одной таблицы в качестве атрибута
   в записи другой таблицы;

3. создание
   специальных связующих таблиц;

1. как
   обеспечить полноту, непротиворечивость
   и согласованность информации, хранящейся
   в БД.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #