От моделирования процессов к проектированию автоматизированной системы (часть 2) / хабр

Отношения между классами

Существует четыре типа связей в UML:

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

Эти связи представляют собой базовые строительные блоки для описания отношений в UML, используемые для разработки хорошо согласованных моделей.
Первая из них – зависимость – семантически представляет собой связь между двумя элементами модели, в которой изменение одного элемента (независимого) может привести к изменению семантики другого элемента (зависимого). Графически представлена пунктирной линией, иногда со стрелкой, направленной к той сущности, от которой зависит еще одна; может быть снабжена меткой.
Зависимость – это связь использования, указывающая, что изменение спецификаций одной сущности может повлиять на другие сущности, которые используют ее. Ассоциация – это структурная связь между элементами модели, которая описывает набор связей, существующих между объектами.
Ассоциация показывает, что объекты одной сущности (класса) связаны с объектами другой сущности таким образом, что можно перемещаться от объектов одного класса к другому.
Например, класс Человек и класс Школа имеют ассоциацию, так как человек может учиться в школе. Ассоциации можно присвоить имя «учится в». В представлении однонаправленной ассоциации добавляется стрелка, указывающая на направление ассоциации.

Советы

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

Диаграмму деятельности можно признать хорошо структурированной, если она:

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

Рисуя диаграмму деятельности, руководствуйтесь следующими принципами:

дайте диаграмме имя, соответствующее ее назначению;

начинайте с моделирования главного потока

Ветвления, параллельность и траектории объектов являются второстепенными деталями, которые можно изобразить на отдельной диаграмме;

располагайте элементы так, чтобы число пересечений было минимальным;

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

Знаете ли Вы, что только в 1990-х доплеровские измерения радиотелескопами показали скорость Маринова для CMB (космического микроволнового излучения), которую он открыл в 1974. Естественно, о Маринове никто не хотел вспоминать. Подробнее читайте в FAQ по эфирной физике.

НОВОСТИ ФОРУМАРыцари теории эфира

10.11.2021 — 12:37: ПЕРСОНАЛИИ — Personalias -> — Карим_Хайдаров.10.11.2021 — 12:36: СОВЕСТЬ — Conscience -> — Карим_Хайдаров.10.11.2021 — 12:36: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ — Upbringing, Inlightening, Education -> — Карим_Хайдаров.10.11.2021 — 12:35: ЭКОЛОГИЯ — Ecology -> — Карим_Хайдаров.10.11.2021 — 12:34: ВОЙНА, ПОЛИТИКА И НАУКА — War, Politics and Science -> — Карим_Хайдаров.10.11.2021 — 12:34: ВОЙНА, ПОЛИТИКА И НАУКА — War, Politics and Science -> — Карим_Хайдаров.10.11.2021 — 12:34: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ — Upbringing, Inlightening, Education -> — Карим_Хайдаров.10.11.2021 — 09:18: НОВЫЕ ТЕХНОЛОГИИ — New Technologies -> — Карим_Хайдаров.10.11.2021 — 09:18: ЭКОЛОГИЯ — Ecology -> — Карим_Хайдаров.10.11.2021 — 09:16: ЭКОЛОГИЯ — Ecology -> — Карим_Хайдаров.10.11.2021 — 09:15: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ — Upbringing, Inlightening, Education -> — Карим_Хайдаров.10.11.2021 — 09:13: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ — Upbringing, Inlightening, Education -> — Карим_Хайдаров.

Основы унифицированного языка моделирования UML

Существует большое количество инструментальных средств, используемых для реализации проекта ИС от этапа анализа до создания программногокода. Отдельно выделяют так называемые CASE-средства верхнего уровня (upper CASE tools) и CASE-средства нижнего уровня (lower CASE tools).

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

Средством, позволяющим объединить эти подходы, явился унифицированный язык объектно-ориентированного моделирования (Unified Modeling Language – UML). К преимуществам языка UML можно отнести разнообразные инструментальные средства, которые как поддерживают жизненный цикл ИС, так и позволяют настроить и отразить специфику деятельности разработчиков различных элементов проекта.

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

Основными характеристиками объектно-ориентированного языка моделирования UML являются:

организация взаимодействия заказчика и разработчика (групп разработчиков) ИС путем построения репрезентативных визуальных моделей;
специализация базовых обозначений для конкретной предметной области.

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

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

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

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

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

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

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

Оценка вопросов

Да. Мы можем просканировать столбец с бортовыми номерами, выбрать N12883Q и перейти по строке к значению в столбце «Курс». Если такого бортового номера не нашлось, значит, этого самолета нет в нашем районе.
Да. Проверяем столбец «Высота», выбирая каждую строку со значением меньше 10 000 футов, а потом смотрим в этих строках бортовой номер.
Нет. Наша модель ничего не говорит о зоне управления. Я вообще её только в этом вопросе впервые и упомянул. Предположим, что существует другой класс, «Зона управления», а в таблице «Самолеты» будет ссылка на атрибут какого-нибудь идентификатора зоны управления. Но в этом примере её нет, поэтому ответить на этот вопрос нельзя.
Да. То же самое, что в первом вопросе, найдите бортовой номер и проверьте это значение в столбце «Скорость».
Нет. Чтобы вычислить вероятность столкновения хоть с какой-то значимой степенью уверенности, у нас просто мало данных. Дело в том, что у нас недостаточно пространственных координат для каждого самолета. Да, мы знаем куда и как быстро он летит, но на самом деле не знаем, где он находится. Но это можно исправить.

Самолет

Бортовой номер {I}	Высота	Скорость	Курс	Широта	Долгота

Расширенная таблица, которая может ответить на большее количество вопросов

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

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

Каков курс указанного самолета?
Какие самолеты находятся ниже заданной высоты?
С какой скоростью летит указанный самолет?
Возможно ли столкновение в определенный период времени?

На эти вопросы мы можем ответить при помощи расширенной таблицы без данных, хотя вы явно заметили, что в неё надо добавить столбец «Скорость набора высоты». Это интересная информация, которую мы можем вычислить с помощью уже имеющихся у нас данных. Поэтому мы можем говорить о том, что новая таблица достаточно хороша, чтобы ответить на вопрос о столкновении — с этим произвольным атрибутом или же без него.

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

Бортовой номер {I}	Высота	Скорость	Курс	Широта	Долгота	/Скорость набора высоты

Знак «/» перед скоростью набора высоты даёт понять, что мы получили это значение с помощью вычислений. Решение о том, стоит ли добавлять производные атрибуты, полученные путем вычислений, это тема для отдельной статьи, поэтому давайте пока просто условимся добавлять их по мере необходимости.

Актуальные вакансии компании Retail Rocket

С переводом помогали: Бюро переводов Allcorrect

Редактор: Алексей @Sterhel Якшин

Специализированные подходы к моделированию процессов

Рассмотренные ниже подходы (табл. 5) могут применяться в проектах моделирования и усовершенствования. Они позволяют проанализировать процессы со стороны предприятия в целом.

Таблица 5. Специализированные подходы к моделированию процессов

Цепочка создания ценности

Цепочка создания ценности показывает в графическом виде добавление ценности или шаги, ведущие к достижению цели. Существуют разные варианты этой нотации, каждый с собственным набором символов, но проблем с пониманием не возникает, поскольку обычно они выглядят как стрелки или горизонтальные шевроны. Так же легко разобраться со связями — в основном они показывают отношения «предшественник-последователь».

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

Основные характеристики

В зависимости от средства моделирования:

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

Для чего используется

Для декомпозиции фрагментов процессов, непосредственно вносящих вклад в создание ценности для клиентов.
Для изображения процессов верхнего уровня.

Преимущества

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

Недостатки

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

Рис. 9. Диаграмма цепочки создания ценности

Дополнительная информация

Референтная модель компании The Value Chain Group.
Диаграмму цепочки создания ценностей поддерживает ПО ARIS компании Software AG.

В данном разделе речь идет не обо всем семействе нотаций IDEF, а о самом популярном его представителе IDEF0. — Прим. ред.

Последнее название данного программного продукта — AllFusion Process Modeler, его поддержка прекращена в 2011 году. — Прим. ред.

Версия для печати

Методология IDEF3

IDEF3-модели используются для документирования технологических (информационных) процессов, где важна последовательность выполнения процесса

Выделяют четыре элемента IDEF3-модели: Единица работы — отображают действия, процессы, события, этапы выполнения работ. Единица работы может иметь только один вход и один выход

Ссылки (Referents):
необходимые элементы для выполнения процесса (сырье, материалы);
результат процесса (изделие);
активаторы процесса (клиент, поставщик).

Связи (Links), которые бывают двух типов:
передают действия от одной единицы работ к другой
соединяют ссылку с единицей работ (активируют единицу работ)

Перекрестки (Junctions) – элементы модели, за счет которых описывается логика и последовательность выполнения этапов процесса.
Бывают двух видов:
перекрестки слияния – Fan-in
перекрестки ветвления – Fan-out

Типы перекрестков

Асинхронное И (Asynchronous AND)
выходной процесс запустится, если завершились все входные процессы
после завершения входного процесса запустятся все выходные процессы

Синхронное И (Synchronous AND)
выходной процесс запустится, если завершились одновременно все входные процессы
после завершения входного процесса запустятся все выходные процессы, причем запустятся одновременно

Асинхронное ИЛИ (Asynchronous OR)
выходной процесс запустится, если завершится один или несколько входных процессов
после завершения входного процесса запустятся один или несколько выходных процессов

Синхронное ИЛИ (Synchronous OR)
выходной процесс запустится, если завершились один или несколько входных процессов, причем завершились одновременно
после завершения входного процесса запустится один или несколько выходных процессов, причем запустятся одновременно

Исключающее ИЛИ (XOR, Exclusive OR)
выходной процесс запустится, если завершился только один входной процесс
после завершения входного процесса запустится только один выходной процесс

Правила создания перекрестков

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

Правило относительно единиц работ

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

Номер работы А13.1.2 означает:
родительская работа имеет код А13,
номер декомпозиции – 1
номер работы на текущей диаграмме – 2.

Пример кода и диаграммы классов для него

Программа получает данные с датчика температуры (вводятся с консоли) — по 5 измерений для каждого из двух объектов класса TemperatureMeasure и усредняет их. Также предусмотрен класс ShowMeasure для вывода измеренных значений.

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778

#include <iostream>using namespace std;class Sensor { int value;public: Sensor() { value = 0; } void setValue(int value) { this->value += value; } int getValue() { return value; }};class MeasureCount{ int number; static int total;public: MeasureCount() { number = 0; } void increment() { number++; total++; } int getNumber() { return number; } static int getTotal() { return total; }};int MeasureCount::total = 0;class ITemperatureMeasure{public: virtual void setValue() = 0; virtual double getValue() = 0;};class TemperatureMeasure : public virtual ITemperatureMeasure{private: Sensor *h; // агрегация MeasureCount *measure; // композицияpublic: TemperatureMeasure(Sensor *h); int getNumber() { return measure->getNumber(); } double getValue() { return (double)h->getValue() / measure->getNumber(); } void setValue() { int value; measure->increment(); cout << «t= «; cin >> value; h->setValue(value); } static int getTotal() { return MeasureCount::getTotal(); }};TemperatureMeasure::TemperatureMeasure(Sensor *h){ measure = new MeasureCount(); this->h = h;}class ShowTemperature // зависимость{public: static void Show(TemperatureMeasure t) { cout << t.getNumber() << «: «; cout << t.getValue() << » oC» << endl; }};int main(){ Sensor *h1 = new Sensor(); TemperatureMeasure tc1(h1); for(int i=0; i<5; i++) tc1.setValue(); ShowTemperature::Show(tc1); cout << endl; Sensor *h2 = new Sensor(); TemperatureMeasure tc2(h2); for (int i = 0; i<5; i++) tc2.setValue(); ShowTemperature::Show(tc2); cout << endl; cout << «Total: » << TemperatureMeasure::getTotal() << endl; cin.get(); cin.get(); return 0;}

TemperatureMeasureSensorTemperatureMeasureSensorTemperatureMeasureMeasureCounttotalcountTemperatureMeasureMeasureCountTemperatureMeasureMeasureCountTemperatureMeasureITemperatureMeasureTemperatureMeasureпоставщикомShowTemperatureTemperatureMeasureShowShowTemperatureTemperatureMeasureАлгоритмизация

Возможности инструментальных средств

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

Использованная литература

1. Национальный исследовательский Томский политехнический университет. Томск. Силич М.П. 2016. 75 с. Презентация к лекции.

4.3
6
Голоса

Рейтинг статьи

Кто пользуется UML

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

Прецедентная модель бизнеса

Отражает основные бизнес-процессы, их взаимодействие с окружением.
Начинается с построения внешней диаграммы (вариантов использования — Use Case Diagram), показывающей, как бизнес виден извне

Актор (действующее лицо, business actor) — субъект окружения бизнеса. Примеры акторов: Клиент, Покупатель, Поставщик, Партнер, Акционер, Заказчик.

Прецедент (вариант использования, business use case) — относительно законченная последовательность действий в рамках некоторого бизнес-процесса, приносящая ощутимый результат конкретному актору .
Примеры прецедентов: Производство продукта Продажа продукта, Сервисное обслуживание, Разработка продукта, Маркетинг и сбыт.

Экземпляр (реализация) прецедента – конкретный вариант хода событий класс прецедентов — обобщенный прецедент.

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

Между прецедентами и акторами устанавливаются отношения коммуникации (отношения ассоциации со стереотипом communicate).
Они моделируют взаимосвязи прецедентов с окружением (информационные и материальные потоки)
Между прецедентами, как правило, устанавливаются только отношения зависимости а также отношения, структурирующие прецеденты – отношения обобщения, включения (зависимости со стереотипом include), расширения (зависимости со стереотипом extend).

Для каждого из элементов модели составляется спецификация.
В спецификации актора: наименование, стереотип (business actor), описание, список атрибутов, список обязательств и др.

В спецификации прецедента: наименование, стереотип (business use case), краткое описание, перечень связанных с прецедентом поддиаграмм и документов

Диаграмма деятельности

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

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

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

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

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

Подробнее о диаграмме деятельности можно прочитать здесь.

Статические модели могут выражать динамические правила

Модели классов статичны. Как и правила. Давайте на простом примере.

— Со взлетно-посадочной полосы в каждый отдельный момент времени может взлетать только один самолет.

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

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

Предисловие

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

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

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

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

Использование ООП может существенно упросить жизнь программисту. Это достигается за счёт сокрытия особенностей внутренней реализации классов. Программисту остаётся лишь пользоваться её удобствами. Кажется, что ООП – панацея от всех проблем. Однако на практике, если не иметь чёткого представления о том, какие классы нужно реализовать и как ими потом пользоваться, в результате может получиться очень запутанная система, которая начнёт порождать спагетти-коду (от англ. “spaghetti code”), который будет лишь мешаться, когда вы захотите добавить что-то новое в систему.