2015_Alontseva_Anokhin_Saakyan_Structural_analysis

для имени, атрибутов и операций. Так, класс Преподаватель имеет атрибуты Табельный номер и Фамилия и допустимые операции – Заключить контракт и Разорвать контракт.

Классы можно связывать между собой, и здесь UML предоставляет очень богатые изобразительные средства. Существуют три наиболее распространенных и важных вида связи: ассоциация, обобщение и зависимость. Привычная для ER-диаграмм связь между сущностями здесь носит название ассоциации. Ассоциации могут быть унарными (т.е. связывающими объекты одного класса), бинарными (связывающими объекты двух классов, они являются наиболее распространенными) и n-арными (связывающими объекты n классов). Последняя показана на примере ассоциации между Преподавателем, Дисциплиной и Группой.

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

Если ассоциированные классы соотносятся друг с другом как часть и целое, то это можно показать с помощью незакрашенного ромбика со стороны целого. Так, студент является частью группы. Ромбик закрашивается, если между целым и его частями явно выражено отношение владения – что-то вроде идентифицирующей связи в базах данных. Такая ассоциация называется композицией и представлена на рис. 25 парой классов – Филиал МИФИ и Группа.

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

60

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

альный элемент – ассоциация-класс.

Рис. 25. Диаграмма классов «Институт»

61

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

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

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

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

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

В показанном на рис. 26 примере обобщенной функцией является «Ввести оценку». В течение семестра и сессии преподаватель вносит в рейтинговую систему три типа оценок – результат проме-

62

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

Рис. 26. Диаграмма вариантов использования «Рейтинговая система»

63

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

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

5.5. Диаграмма взаимодействия

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

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

Существует два вида диаграмм взаимодействия: диаграмма последовательности (sequence diagram);

диаграмма коммуникации (communication diagram).

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

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

64

Рис. 27. Диаграмма последовательности для варианта использования «Распечатать ведомость»

Рис. 28. Диаграмма коммуникации для варианта использования «Распечатать ведомость»

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

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

65

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

Рис. 29. Диаграмма деятельности «Заседание кафедры»

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

При моделировании бизнес-процессов диаграмма деятельности разделяется на группы деятельности для обозначения границ ответственности отдела или исполнителя. В таком представлении диаграмма деятельности похожа на нотацию BPMN. На рисунке 29 представлена диаграмма деятельности для процесса «Заседание кафедры», который был описан в нотации BPMN на рис. 11.

66

5.7. Диаграмма автомата

Диаграмма автомата предназначена для детального описания поведения системы. Аналогично сети Петри и сети переходов состояний IDEF3, описанным в главе 4, диаграмма автомата представляет собой граф переходов состояний. Переходы системы в различные состояния инициируются событиями и условиями переходов.

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

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

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

Рис. 30. Диаграмма автомата «Обработка детали»

67

Заключение

Избегайте «механического» решения проблем. В среде про-

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

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

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

Сначала нужно четко понять цель моделирования. Из этого последует решение о том, какие категории предметной области должны быть представлены в модели: объекты, процессы, состояния, логические условия и т.п. Отсюда станет понятно, какие диаграммы и нотации предпочтительнее всего. Затем нужно определить, какие методы анализа будут использованы (например, имитационное моделирование или оценка риска). Это позволит проверить выбран-

68

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

Особое место занимают структурные методы при проектировании баз данных. Естественно, основную роль здесь играют диаграммы «сущность-связь» (ERD), позволяющие описать концептуальную схему данных. Однако на пути к ERD необходим анализ предметной области. Учитывая, что базы данных создаются для информационной поддержки пользователя при решении определенных производственных задач, то вполне естественно, что цель такого анализа состоит в выявлении именно той информации, которая необходима и достаточна пользователю для решения этих задач. Поскольку описание должно быть сосредоточено на задачах, разумным представляется использование функциональных сетей. Дальше дело сугубо личное – кому-то нравится IDEF0, кому-то DFD. В любом случае, выполняя моделирование в интересах последующего построения схемы базы данных, нужно опираться на конкретные документы, конкретные формы и конкретные действия пользователя. Иначе модель может оказаться бесполезной.

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

Комбинируйте и интегрируйте модели. В последнее время все больше специалистов прибегают к комбинированию нескольких методов. Это возможно благодаря программным пакетам, предоставляющим возможность построения диаграмм в нескольких нотациях. Например, популярный пакет BPWin18 предлагал три нотации –

18 С 1999 г. – AllFusion Process Modeler, приобрел огромную популяр-

ность в России благодаря нескольким книгам на русском языке по CASEтехнологиям; в 2011 г. выпуск прекращен

69