Алонцева Е.Н., Анохин А.Н., Саакян С.П. Структурное моделирование процессов и систем

Министерство образования и науки Российской Федерации Федеральное государственное автономное образовательное

учреждение высшего профессионального образования «Национальный исследовательский ядерный университет «МИФИ»

ОБНИНСКИЙ ИНСТИТУТ АТОМНОЙ ЭНЕРГЕТИКИ

Обнинск 2015

Министерство образования и науки Российской Федерации Федеральное государственное автономное образовательное

учреждение высшего профессионального образования «Национальный исследовательский ядерный университет «МИФИ»

ОБНИНСКИЙ ИНСТИТУТ АТОМНОЙ ЭНЕРГЕТИКИ

Е. Н. Алонцева, А. Н. Анохин, С. П. Саакян

Структурное моделирование процессов и систем

Учебное пособие по курсу «CASE и CALS технология»

Рекомендовано к изданию Редакционно-издательским советом института

Обнинск 2015

2

УДК 004.01 Алонцева Е. Н., Анохин А. Н., Саакян С. П. Структурное моде-

лирование процессов и систем. Учебное пособие по курсу «CASE и CALS технология». – Обнинск: ИАТЭ НИЯУ МИФИ, 2015. – 72 c.

В учебном пособии описывается сущность структурного подхода к моделированию и разработке автоматизированных систем, рас-сматриваются методы структурного анализа систем и современный инструментарий для его проведения. Подробно рассматриваются нотации моделирования поведения систем, нотации функциональ-ного, информационного и объектно-ориентированного моделирова-ния: IDEF0, IDEF1X, IDEF3, DFD, eEPC, BPMN, Чена, Баркера, Мар-тина, Бахмана, Петри, UML. Нотации иллюстрируются несколькими сквозными примерами.

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

Рецензенты: д-р техн. н., проф. П. И. Падерно д-р техн. н., проф. Н. Л. Сальников Тем. план 2015, поз. 15

© ИАТЭ НИЯУ МИФИ, 2015 г.

© Авторы, 2015 г.

3

Введение

В 1960-е гг. методология структурного моделирования была по-ложена в основу CASE-технологии. Аббревиатура «CASE» тракту-ется по-разному – Computer Assisted или Computer Aided System Engineering. Смысл при этом остается неизменным – системный анализ с помощью компьютерных средств. В основу этой техноло-гии легла серия стандартов, созданных американским военным ве-домством и обозначаемых аббревиатурой IDEF.

К концу 1970-х гг. стали появляться серьезные программные продукты, помогающие аналитикам в построении и анализе графи-ческих диаграмм, применяемых в структурных методах. Позднее продукты такого рода образовали собственную нишу, получившую название «CASE-средства». В совокупности с методиками эти сред-ства образуют так называемую CASE-технологию, являющуюся ин-струментом для проведения анализа управленческих процессов1 и проектирования информационных систем.

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

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

1 В современной литературе используется другой термин – «бизнес-

процесс», появившийся как результат транслитерации английского business process. В русском языке понятие «бизнес» имеет несколько другое значе-ние, поэтому авторы пособия не считают этот термин корректным. Однако дабы избежать противоречий с основной массой литературы по данной тематике, именно термин «бизнес-процесс» будет использоваться в даль-нейшем изложении.

4

Глава 1. Основные понятия структурного моделирования

1.1. Сущность структурного моделирования

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

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

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

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

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

5

Методология структурного моделирования не стоит на месте и является постоянно развивающейся областью. За последние деся-тилетия появились и постоянно трансформируются такие подходы, как онтологии и объектно-ориентированное моделирование, ко-торые объединяют в себе структуры обоих типов – и элементы, и функции – в иерархию классов, объектов и понятий.

В современной инженерной и научной практике структурные мо-дели присутствуют в виде

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

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

объектов или пунктов управления ими.

1. 2. Понятие бизнес-процесса

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

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

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

6

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

Рис. 1. Концептуальная схема управления процессом [6]

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

Сеть процессов «привязывается» к функциональным подразде-лениям предприятия. Структура подразделений организации может оказаться неоптимальной для целей бизнеса. Выделяя, документи-

7

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

Рис. 2. Сеть процессов предприятия [6]

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

Процесс 10, наоборот, ничего не создает. Этот процесс только расходует входы и ресурсы, не выдавая на выход никакого резуль-тата. Такая ситуация тоже может говорить о неполной картине про-цессов или о том, что выход (результат) процесса 10 никому не ну-жен. У процесса 10 нет ни внешних, ни внутренних потребителей, и необходимо рассмотреть целесообразность существования или вы-

8

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

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

К основным процессам организации, как правило, относят про-цессы производства, сбыта и снабжения.

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

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

1.3. Структурное моделирование в описании бизнес-процессов

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

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

кто выполняет функции процесса; как происходит взаимодействие исполнителей при выполнении

этих функций; какие механизмы управления существуют в рамках рассматри-

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

функция процесса;

9

какие исходящие документы (информацию) генерирует каждая функция процесса;

какие ресурсы необходимы для выполнения каждой функции процесса;

какая документация регламентирует выполнение каждой функ-ции;

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

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

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

CASE-средства, ориентированные на поддержку реинжиниринга, получили название BPR-систем (от англ. Business Process Re-engineering) и широкое распространение в 2000-е гг.

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

10

стая и наиболее общая модель жизненного цикла состоит из пяти этапов: 1) анализ; 2) проектирование; 3) реализация; 4) внедрение; 5) сопровождение. Другую номенклатуру этапов жизненного цикла определяет, например, ГОСТ 34.601-902, устанавливающий восемь стадий создания автоматизированной системы (АС): 1) формирова-ние требований к АС; 2) разработка концепции АС; 3) техническое задание; 4) эскизный проект; 5) технический проект; 6) рабочая до-кументация; 7) ввод в действие; 8) сопровождение АС.

1.4. Обзор методов структурного моделирования

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

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

2 ГОСТ 34.601-90. Комплекс стандартов на автоматизированные систе-

мы. Автоматизированные системы. Стадии создания

11

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

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

функциональное моделирование – описание функций, которые система должна выполнять;

информационное моделирование – представление объектов предметной области, их свойств и отношений между ними;

моделирование поведения – представление поведения системы во времени.

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

диаграммы, изображающие функции и связи между этими функ-циями (наиболее популярными в этом классе являются диаграммы потоков данных / работ (Data / Work Flow Diagrams, DFD / WFD) и методика структурного анализа и проектирования (Structured Analy-sis and Design Technique, SADT));

Таблица 1 Основные методы структурного моделирования

Задача Метод Пример нотации Функциональное моделирование

SADT DFD WFD ARIS BPML

IDEF0 Гейна-Сарсона (Gane / Sarson), Йор-дона-Де Марко (Yourdon / DeMarco) IDEF3 (PFDD) eEPC BPMN

Информационное моделирование

ERD Чена (P. Chen), Баркера (R. Barker), Мартина (J. Martin), IDEF1X, Бахма-на (C. Bachman)

Моделирование пове-дения (имитационное моделирование)

STD CPN, IDEF3 (OSTN)

12

диаграммы, моделирующие данные и их взаимосвязи (Entity-Relationship Diagrams, ERD);

диаграммы, моделирующих поведение системы (State Transition / State Chart Diagrams, STD).

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

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

метод функционально-стоимостного анализа, называемый также ABC-анализом (Activity Based Costing); анализ начинается с оценки для каждой функции системы ее стоимости и ресурсоемкости с по-следующим вариативным расчетом общей стоимости бизнес-про-цесса;

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

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

Существенное влияние на развитие методов структурного моде-лирования оказали американские стандарты серии IDEF. Эти стан-дарты были созданы в рамках программы интегрированной компью-теризации производства (Integrated Computer Aided Manufacturing, ICAM), реализованной в 1970-х гг. на предприятиях военно-про-мышленного комплекса США. Целью программы было увеличение эффективности и улучшение координации работы промышленных предприятий. Большой масштаб предстоящих работ и гигантские объемы собираемой информации заставили авторов программы создать четкие, детальные и однозначно трактуемые аналитические методики, которые должны были неукоснительно исполняться все-ми аналитиками проекта. Только так можно было унифицировать собираемую информацию и обеспечить эффективный информаци-

13

онный обмен между специалистами, занимающимися разными про-блемами.

Рис. 3. Пример CASE-технологии реорганизации предприятия и создания

АСУ

В результате на свет появилась серия документов под общим названием IDEF (ICAM Definition). Эти документы были настолько четкими и детальными, что они мгновенно приобрели популярность среди аналитиков из самых разных отраслей и практически затмили большинство известных до этого методик.

14

Семейство стандартов IDEF должно было состоять из 16-ти до-кументов. К 1995 г. были полностью разработаны IDEF0–IDEF5 (табл. 2). Именно эти семь стандартов в разных сочетаниях приме-няются для задач анализа и моделирования информационных сис-тем. Остальные стандарты либо не были доработаны, либо не по-лучили широкого распространения.

Таблица 2 Основные стандарты серии IDEF3

Стандарт Назначение Задача IDEF0, IDEF3

Функциональное моделирование

Описание бизнес-процесса как си-стемы взаимосвязанных функций

IDEF1 Информационное моделирование

IDEF1X Моделирование данных

IDEF4 Объектно-ориентирован-ное описание

IDEF5 Представление онтологий

Описание информационной структуры объектов, идентифика-ция отношений между объектами

IDEF2 Имитационное модели-рование поведения сис-тем

IDEF3 Описание технологиче-ских процессов

Моделирование поведения сис-темы в различных условиях, ана-лиз критических режимов работы, анализ динамических характери-стик бизнес-процессов

Важное место в разработке моделей бизнес-процессов занимает

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

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

3 Полные тексты перечисленных стандартов на английском языке до-

ступны на сайте www.idef.com

15

одного и того же класса имеют один и тот же набор операций и мо-гут реагировать на одни и те же сообщения.

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

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

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

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

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

Объектно-ориентированные методы могут использовать диа-граммы «сущность-связь», однако в современной практике больше используются диаграммы классов (Class Diagrams), отражающие иерархию классов и операции каждого из них.

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

16

Глава 2. Методы функционального моделирования

2.1. Структурная диаграмма в нотации IDEF0

Исторически нотация IDEF0 была далеко не первой методикой структурного моделирования процессов, однако благодаря своей проработанности и высокой степени формализации она стала од-ной из самых известных и популярных среди аналитиков. Ее основ-ной идеей является иерархическая декомпозиция процесса на от-дельные функции4 (activity), рассматриваемые как «черные ящики»5.

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

К функциональному блоку могут примыкать стрелки, с помощью которых изображаются объекты или субъекты деятельности. Стрел-ки, примыкающие к левой стороне функционального блока, – это входные объекты для функции (input). Стрелки, исходящие справа, – выходные объекты (output), т.е. результаты выполнения функции. Стрелками, входящими сверху, показываются объекты, управляю-щие реализацией функции (control). Снизу примыкают механизмы (mechanism), т.е. объекты или субъекты, выполняющие или способ-ствующие выполнению функции. Каждая стрелка имеет имя, отра-жающее название объекта (рис. 4).

Модель в нотации IDEF0 представляет собой функциональную сеть, состоящую из функциональных блоков (вершин сети) и стре-лок (направленных дуг), передающих объекты от одной функции к другой. Вся сеть разбита на фрагменты, представляемые в виде отдельных функциональных диаграмм и образующие иерархию.

4 Функцию здесь можно трактовать как работу, задачу, действие, опера-

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

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

17

Рис. 4. Нотация структурных диаграмм IDEF0

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

В результате декомпозиции блока «Создать сайт» появляется ди-аграмма-потомок, содержащая пять функциональных блоков6 (ниж-няя часть рис. 5). Каждый блок может быть декомпозирован до того уровня детализации, который необходим аналитику, чтобы достичь цели моделирования. Декомпозируемый блок называется роди-тельским блоком, содержащая его диаграмма – родительской диа-граммой, а порождаемая им диаграмма – диаграммой-потомком.

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

6 Каждая диаграмма может содержать от двух до восьми блоков. Это ог-

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

18

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

Рис. 5. Структурная диаграмма «Создание сайта» в нотации IDEF0

19

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

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

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

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

связь по управлению – выход одного блока непосредственно управляет другим блоком с меньшим доминированием;

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

связь выход-механизм – выход одного блока служит средством (механизмом) для реализации другого блока.

Рис. 6. Виды взаимосвязей меж-ду функциональными блоками: 1 – по входу; 2 – обратная связь по входу; 3 – по управлению; 4 – обратная связь по управле-нию; 5 – выход-механизм

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

20

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

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

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

Очевидно, что граничные дуги диаграммы-потомка должны быть согласованы по числу и наименованию с дугами, примыкающими к родительскому блоку. Однако на практике это не всегда выполняет-ся. Так, в приведенном примере к родительскому блоку «Создать сайт» примыкают пять дуг. Четыре из них – «Информация о пред-метной области», «Сайт, доступный пользователям», «Мода» и «Группа разработки» – совпадают с граничными дугами диаграммы-потомка. В то же время к родительскому блоку примыкает «Техни-ческое задание», которого нет в диаграмме-потомке. Зато в этой диаграмме есть граничная дуга «Заказчик», которой нет при роди-тельском блоке. Их отсутствие объясняется тем, что они «помеще-ны в тоннель», который обозначается парой круглых скобок, «обжи-мающих» дугу с двух сторон. Существуют два способа использова-ния тоннеля.

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

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

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

21

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

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

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

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

непомеченные ветви содержат все объекты, указанные в метке дуги перед разветвлением;

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

Примером разветвляющейся дуги является «Группа разработ-ки», осуществляющая создание сайта в примере на рис. 5. Эта группа состоит из дизайнера, программиста, контент-менеджера и специалиста по продвижению сайтов, каждый из которых выполняет свою задачу, как показано на диаграмме-потомке.

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

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

для дуг и блоков – определение (definition – определение объек-та, отображаемого дугой, или функции, отображаемой блоком), при-мечание (note – дополнительная поясняющая информация), ссылку

22

или извлечение из источника, несущего информацию об объекте или функции (source);

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

для модели в целом – название проекта (project), в рамках кото-рого разрабатывается модель; информацию об авторе модели (author); стадию работы над моделью (аналогичную стадиям работы над диаграммами); цель моделирования (purpose); точку зрения, с которой осуществлялось структурирование моделируемого процес-са (viewpoint); определение моделируемого процесса (definition); границы моделирования (scope); перечень источников информации, на основании которой строилась модель (source).

2.2. Диаграмма потоков данных в нотации DFD

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

Базовыми понятиями диаграмм потоков данных являются работа (activity), внешняя ссылка (external reference, entity), хранилище дан-ных (data store), поток данных (data flow) (табл. 3). Аналогично диа-граммам IDEF0 диаграммы потоков данных строятся в виде функ-циональной сети, состоящей из вершин и направленных дуг. Основ-ное отличие потоковых диаграмм состоит в возможности использо-вания трех типов вершин, служащих не только для представления процессов, но и для отображения отдельных объектов и средств накопления и хранения данных.

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

23

Таблица 3 Нотация диаграмм потоков данных DFD

Символ Назначение

Функция, работа, действие, операция преобразования данных

Внешняя сущность

Хранилище данных

Поток данных, объект

Вершины первого типа предназначены для представления про-

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

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

Внешняя сущность

Хранилище Хранилище

Функция Функция

Объект

24

ные, управляющие и обеспечивающие, подводя их к соответствую-щим стороне прямоугольника или сектору круга (см. рис. 7б)

Рис. 7. Диаграмма потоков данных «Создание сайта» в нотации DFD: а – в формате Visio; б – в формате BPWin

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

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

а)

б)

25

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

2.3. Диаграмма рабочих процессов в нотации IDEF3

Стандарт IDEF3 предлагает нотацию построения диаграмм двух видов: функциональных диаграмм для описания процессов (Process Flow Description Diagrams, PFDD) и диаграмм для описания измене-ния состояния объектов (Object State Transition Network, OSTN). В данном разделе мы рассмотрим диаграммы первого типа, диаграм-мы второго типа будут описаны в главе 4.

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

Базовыми понятиями диаграмм процессов являются (табл. 4) единица работы (unit of work), перекресток (junction), объект ссылки (referent), комментарий (note), порядок следования работ (prece-dence), взаимосвязи между работами (relation link). Аналогично пре-дыдущим диаграммам, диаграммы процессов IDEF3 представляют собой функциональную сеть с вершинами четырех типов и направ-ленными дугами трех типов. Рассмотрим их подробнее.

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

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

26

цию IDEF3 от двух предшествующих. Напомним, что в IDEF0 дугами изображаются объекты предметной области, а последовательность исполнения функций задается неявным образом – установлением доминирования функциональных блоков. Ничего не изменится, если дуги в IDEF0 сделать ненаправленными, т.е. обычными линиями вместо стрелок. Таким образом, работая с нотациями IDEF0 и DFD, нужно помнить, что стрелка не указывает путь реализации процес-са, хотя и производит такое обманчивое впечатление.

Таблица 4 Нотация диаграмм рабочих процессов IDEF3

Символ Назначение

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

Перекресток, где С – один из символов: &, O, X

Объект ссылки. В нижней части указывается номер ссылаемого блока

Комментарий. В верхней части указывается номер

Стрелка, определяющая порядок следования работ,

где С – один из символов: , , ,

Линия взаимосвязи между работами

Итак, нотация IDEF3 позволяет показать путь исполнения про-

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

Объект ссылки

Комментарий

С

Единица работы

С

27

Рис. 8. Диаграмма рабочих процессов «Создание сайта» в нотации IDEF3

Первый из них ( ) предписывает, что за работой-предшествен-ником обязательно должна быть выполнена работа-последователь. Второй ( ) указывает, что работа-последователь не может суще-ствовать без работы-предшественника. В примере на рис. 8 показа-но, что пока сайт не прошел приемку заказчиком, его размещение на общедоступном сервере недопустимо. Третий маркер ( ) оз-начает, что обе работы не могут существовать друг без друга. Чет-вертый ( ) может означать любое ограничение, например, пере-рыв между двумя работами не должен превышать 5 мин.

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

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

28

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

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

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

а) б)

Рис. 9. Перекрестки в нотации IDEF3

Вершины двух других типов – объекты ссылок и комментарии яв-ляются вспомогательными и могут использоваться для

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

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

организации цикла работ; представления объекта, причастного к данной единице работы;

29

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

Таблица 5 Перекрестки диаграммы рабочих процессов

Обо-зна-чение

Назва-ние

Функция для сходящихся дуг

Функция для расходящихся дуг

Асин-хронный И

Все предшествующие процессы должны быть завершены

Все последующие про-цессы должны старто-вать

Син-хронный И

Все предшествующие процессы должны быть завершены одновременно

Все последующие про-цессы должны старто-вать одновременно

Асин-хронный ИЛИ

Один или несколько пред-шествующих процессов должны быть завершены

Один или несколько последующих процес-сов должны стартовать

Син-хронный ИЛИ

Один или несколько предшествующих про-цессов должны быть за-вершены одновременно

Один или несколько последующих процес-сов должны стартовать одновременно

Исключающий ИЛИ

Ровно один предшест-вующий процесс должен быть завершен

Ровно один последую-щий процесс должен стартовать

2.4. Диаграмма цепочек процессов в нотации eEPC

Диаграмма в нотации еЕРС (extended Event-driven Process Chain) описывает функционирование системы в виде цепочки процессов, управляемых событиями. Такая модель не только позволяет де-тально описывать бизнес-процесс, но и отражает логику его выпол-нения с помощью логических операторов, определяющих связи ме-жду событиями и функциями и позволяющих изобразить ветвление процесса. Бизнес-процесс в нотации еЕРС представляет собой по-ток последовательно выполняемых работ (функций), расположен-ных в порядке их выполнения. Используемые при построении сим-волы логики позволяют отразить ветвление и слияние ветвей биз-нес-процесса. В таблице 6 приводятся основные объекты, исполь-зуемые в данной нотации.

X

O

O

&

&

30

Таблица 6 Нотация диаграмм цепочек процессов еЕРС

Символ Назначение

Функция (процедура, работа), выполняемая подразделениями и сотрудниками предприятия

Событие – реальное состояние системы, управ-ляющее выполнением функций

Организационная единица – организационное подразделение предприятия (например, управ-ление или отдел)

Документ – реальный носитель информации, например, бумажный документ

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

Логические операторы «И», «ИЛИ», «исклю-чающее ИЛИ»

Помимо указанных в таблице основных объектов, при построе-

нии диаграммы еЕРС могут быть использованы многие другие объ-екты. Однако применение большого числа различных объектов, свя-занных разными типами связей, значительно увеличивает размер модели и делает ее плохо читаемой.

Для понимания смысла нотации еЕРС достаточно рассмотреть основные типы объектов и связей. На рисунке 10 приведен простой пример диаграммы процесса. Из рисунка видно, что модель процес-са в нотации еЕРС представляет собой направленный граф, форми-руемый из событий, функций и узлов ветвления. Исполнители, до-кументы и элементы прикладных комплексов привязываются к функциям. Модель отображает набор действий (функций), которые должны быть выполнены для получения заданного результата.

ХОR ∨ ∧

Функция

Организацион-ная единица

Документ

Прикладная система

Событие

31

Рис. 10. Диаграмма цепочек процессов «Заседание кафедры» в нотации еЕРС

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

32

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

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

2.5. Диаграмма бизнес-процессов в нотации BPMN

В 2000 г. инициативной группой из компаний-разработчиков про-граммного обеспечения и консалтинговых фирм был представлен язык, ориентированный на моделирование бизнес-процессов BPML (Business Process Modeling Language). Этот язык обеспечивает по-строение абстрактной модели взаимодействующих процессов. Биз-нес-процесс в нотации BPML описывается в виде взаимодействия управляющих потоков, потоков данных и потоков событий на фоне бизнес-правил, ролей и контекста взаимодействия. Язык поддержи-вает синхронные и асинхронные транзакции и позволяет получить исполняемую модель, встраиваемую в существующие приложения.

Проект графической нотации (табл. 7) для описания процессов (Business Process Model and Notation, BPMN) появился7 в 2003 г. Права принадлежат консорциуму Object Management Group – веду-щему разработчику стандартов в области IT-архитектур.

Процесс, описанный в нотации BPMN (рис. 11), представляет со-бой последовательное или параллельное выполнение различных действий (операций) с указанием определенных бизнес-правил. В нотации BPMN выделяют пять основных категорий элементов:

элементы потока (события, действия и шлюзы); соединяющие элементы (потоки управления, потоки сообщений

и ассоциации); зоны ответственности (пулы и дорожки); данные (объекты данных и базы данных); артефакты (сноски).

7 Самую новую версию нотации можно найти на сайте www.omg.org/bpmn

33

Таблица 7 Нотация диаграмм бизнес-процессов BPMN

Символ Назначение

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

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

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

Поток управления – определяет порядок операций бизнес-процесса

Поток сообщений – отображает обмен сообщениями между участниками процесса

Ассоциация – устанавливает связи объектов данных с процессами. Связь может быть направленной и ненаправленной

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

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

Сообщение – отображает существо взаимодействия между двумя участниками бизнес-процесса

Сноска – выносной элемент, предназначенный для текстовых комментариев Сноска

Пул

Дорож

ка

Дорож

ка

34

Рис. 11. Диаграмма бизнес-процессов «Заседание кафедры» в нотации BPMN

35

Глава 3. Методы информационного моделирования

3.1. Нотация «сущность-связь» Чена

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

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

Со временем данная нотация претерпела ряд изменений и до-полнений. Для начала автор предложил дополнить данное описание диаграммой атрибутов, на которой показываются атрибуты и их домены. Домены при этом указываются в кружках, а атрибуты изо-бражаются в виде стрелок с именами (рис. 13). В более поздних ра-ботах Чен предлагает уточнять, может ли значение атрибута повто-ряться у разных экземпляров сущности и может ли один атрибут иметь несколько значений . Эта информация представляется с по-мощью кардинальных чисел, показанных на рис. 13. Здесь работник имеет одну фамилию, однако такая фамилия может принадлежать

8 Chen P.P.-S. The entity-relationship model – toward a unified view of data //

ACM Transactions on Database Systems. – 1976. – Vol.1, №. 1. PP. 9–36.

РАБОТНИК

работает в

ПРОЕКТ

выполняет

1

N N

M

имеет

1

ЛИЧНОЕ ДЕЛО ПОДРАЗДЕЛЕНИЕ

36

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

Рис. 13. Диаграмма атрибутов

Рис. 14. Современная нотация Чена

9 Правда, множественное значение атрибута нарушает первую нормаль-

ную форму, упоминание о которой в нотации Чена отсутствует

выполняетN M

Возраст Фамилия

Служебный телефон

Домашний телефон

Табельный номер

РАБОТНИК

Шифр

Название

Сроки

ПРОЕКТ

Годы (целые,

>16)

РАБОТНИК

Фамилии (строки

символов)

Возраст Фамилия

Номера (целые

>0, пяти-значные)

Табельный номер

Служебный телефон

Домашний телефон

1 N 1

1

1 1

N M N N

Номера теле-фонов

37

Затем представление атрибутов и доменов упрощается и объе-диняется в один элемент – круг или овал (рис. 14). За 30 лет суще-ствования нотация Питера Чена претерпела большое число моди-фикаций и дополнений, часть из которых являются довольно спор-ными. В таблице 8 представлены наиболее часто используемые устоявшиеся символы для диаграмм «сущность-связь»10.

Таблица 8 Нотация Чена для диаграмм «сущность-связь»

Символ Назначение

Сущность (независимая сущность), представ-ляющая объект предметной области (имя – су-ществительное)

Ассоциированная сущность – сущность, образо-ванная из связи и зависящая от двух или более других сущностей (имя – существительное или отглагольное существительное)

Зависимая сущность – сущность, являющаяся зависимой в идентифицирующей связи

Атрибут (простой атрибут)

Атрибут, являющийся или входящий в состав первичного ключа

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

Связь, представляющая отношения между од-ним (унарная), двумя (бинарная) или n (n-арная) объектами предметной области (имя – глагол или отглагольное существительное; X∈{0,1} – нижнее кардинальное число, Y∈{1,N} – верхнее кардинальное число)

Идентифицирующая связь

10 Напомним, что нотация Чена предусматривает еще один вид диа-

грамм – диаграммы атрибутов

имя

Y Y

X,Y

имя

имя

Имя

Имя

Имя

ИМЯ

имя

ИМЯ

X,Y

38

3.2. Нотация «сущность-связь» Баркера

Свою нотацию для изображения структур данных Ричард Баркер (Richard Barker) предложил в 1986 г., работая в собственной консал-тинговой фирме, которая позднее присоединилась к корпорации Oracle. Его нотация диаграмм «сущность-связь»11 до сих пор явля-ется основной нотацией для разработки баз данных в СУБД Oracle с помощью специального пакета Designer.

Сущность в нотации Баркера изображается в виде прямоуголь-ника со скругленными углами, внутри которого указывается имя сущности и атрибуты (рис. 15). Наряду с основным именем для сущности могут использоваться синонимы, отделяемые от основно-го имени наклонной чертой. Ниже имени в столбик перечисляются атрибуты. Название каждого атрибута сопровождается специаль-ным символом:

буквой О (optional, необязательный) – для атрибутов, значения которых могут отсутствовать (т.е. быть равными NULL);

символом «–» для атрибутов, значения которых обязательно должны быть указаны;

символом «#» для атрибутов, входящих в состав первичного ключа.

Рис. 15. Диаграмма «сущность-связь» в нотации Баркера

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

11 Barker R. CASE method: entity relationship modelling. – Reading, MA:

Addison-Wesley Professional, 1990

СТУДЕНТ # Номер студбилета* Фамилия * Имя * Отчество О Пол О Дата рождения

ДИСЦИПЛИНА / ПРЕДМЕТ # Шифр дисциплины * Название * Трудоемкость * Отчетность

изучает

преподается для

39

плину, а дисциплина преподается для студента. Мощность связи изображается с помощью символов на конце линии:

«–––» – одинарная прямая линия означает, что связь с этой сто-роны имеет мощность «один»;

« » – символ «воронья лапка» означает мощность «много» (линия связи как бы разветвляется в месте соприкосновения с сущ-ностью)12.

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

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

Рис. 16. Категориальное отношение

В нотации Баркера имеется одна интересная возможность – так называемая «исключающая связь». Эта связь используется, когда

12 Рядом с этим символом разрешается указывать верхнее кардиналь-

ное число, например, ≤15

КЛИЕНТ # Идентификатор клиента О Дата первого обращения в банк * Участие в бонусной программе

ЮРИДИЧЕСКОЕ ЛИЦО # ИНН * Название

…

ФИЗИЧЕСКОЕ ЛИЦО # Номер паспорта * Фамилия

…

40

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

Рис. 17. Исключающая связь

3.3. Нотация «сущность-связь» Бахмана

Чарльз Бахман13 (Charles W. Bachman) – выдающийся исследо-ватель и практик в области компьютерных наук, удостоенный в 1973 г. премии Тьюринга14. Он основал собственную фирму, кото-рая занималась разработкой СУБД и линейкой CASE-средств.

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

PK (primary key) – первичный ключ; FK (foreign key) – внешний ключ; 13 Иногда (редко) упоминается в русскоязычной литературе как Бэчмен 14 Премия Тьюринга – самая престижная премия в области информаци-

онных технологий, вручаемая ежегодно ассоциацией вычислительной тех-ники (Association for Computing Machinery, ACM). Ее часто сравнивают с но-белевской премией, но только для IT-области.

СЧЕТ # Номер счета * Вид счета * Дата открытия …

ФИЗИЧЕСКОЕ ЛИЦО # Номер паспорта * Фамилия …

открыт для

ЮРИДИЧЕСКОЕ ЛИЦО # ИНН * Название …

открыт для

имеет

имеет

41

PFK (primary and foreign key) – внешний ключ в составе пер-вичного;

I (inherited) – атрибут, унаследованный от обобщенной сущности. Необходимо отметить, что названия наследуемых атрибутов и

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

Связи в нотации Бахмана изображаются линией с двумя назва-ниями. Мощность связи указывается с помощью стрелок:

« » – мощность «один-к-одному», « » – мощность «один-ко-многим», « » – мощность «многие-ко-многим»,

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

Рис. 18. Диаграмма «сущность-связь» «Институт» в нотации Бахмана

В показанном на рис. 18 примере шифры учебных групп в раз-личных филиалах НИЯУ МИФИ могут совпадать. Во избежание не-

СТУДЕНТ PK, Номер студбилета FK, ГРУППА.Шифр группы FK, ФИЛИАЛ МИФИ. Код Фамилия …

СТУДЕНТ ЗАОЧНОГО ОТДЕЛЕНИЯ IPK, СТУДЕНТ.Номер студбилета IFK, ГРУППА.Шифр группы IFK, ФИЛИАЛ МИФИ. Код I СТУДЕНТ.Фамилия I … Место работы Второе образование

учится в

состоит из

СТУДЕНТ ВЕЧЕРНЕГО ОТДЕЛЕНИЯ

…

ГРУППА PK, Шифр группы PFK, ФИЛИАЛ МИФИ. Код Год набора …

ФИЛИАЛ МИФИ PK, Код

Название

обучается в

имеет

42

однозначности сущность ГРУППА сделана зависимой и в состав ее первичного ключа введен код филиала МИФИ.

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

3.4. Нотация «сущность-связь» IDEF1X

Данная нотация появилась в рамках программы ICAM в 1985 г., заменив не очень удачную нотацию IFEF1, предложенную четырьмя годами ранее. Автором нотации, которой мало что известно, счита-ется Мэри Лумис (Mary E. Loomis).

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

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

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

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

43

местом нотации IDEF1X является сильно запутанная система изо-бражения кардинальных чисел – полноты и мощности связи.

Рассмотрим кардинальные числа идентифицирующей связи, представляющей собой сплошную линию с точкой со стороны зави-симой сущности . Как известно, эта связь может иметь мощность «один-к-одному» или «один-ко-многим» и должна быть полной со стороны зависимой сущности. Полнота и мощность связи указываются с помощью метки рядом с точкой. Если метка отсутст-вует, то это связь «один-ко-многим», неполная со стороны основной сущности. Именно такой является связь между филиалом МИФИ и группой (рис. 19): в филиале может быть много групп, а может не быть ни одной. Меткой «P» обозначается полная связь «один-ко-многим», а меткой «Z» – частично полная связь «один-к-одному».

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

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

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

– полная категоризация означает, что набор сущностей-категорий полный и каждый экземпляр обобщенной сущности дол-жен быть ассоциирован с одним экземпляром какой-либо сущности-категории (в примере, показанном на рис. 19, студент обязательно должен быть либо очником, либо заочником, либо вечерником);

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

44

Рис. 19. Диаграмма «сущность-связь» «Институт» в нотации IDEF1X

Так же, как и в нотации Чена, методика IDEF1X предлагает сред-ство для изображения доменов, вернее, иерархии доменов. На верхнем уровне этой иерархии указывается базовый домен, кото-рый определяется на числовом, текстовом, логическом, двоичном и других типах данных. Затем этот домен может быть декомпозирован на домены-типы, для каждого из которых задаются свои дополни-тельные ограничения (рис. 20).

3.5. Нотация Мартина и кардинальные числа

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

Студент

Номер студбилета Шифр группы (FK) Код (FK) Фамилия …

Номер студбилета (FK) Место работы Второе образование

Студент-вечерник

Код Название

Филиал МИФИ Шифр группы Код (FK) Год набора …

Группа

образована в / включает в себя

Студент-заочник

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

Студент-очник

Номер студбилета (FK) Стипендия

Номер студбилета (FK) Место работы

состоит из / учится в

P

45

Рис. 20. Иерархия доменов

популярного пакета Power Designer15 и упоминаемая в литературе как нотация Джеймса Мартина (James Martin) или нотация Informa-tion Engineering. Она очень близка к нотации Баркера, а ее отличи-тельной чертой является лаконичное и удобное обозначение карди-

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

Если связь идентифицирующая, то со стороны зависимой сущ-ности используется другой символ:

– идентифицирующая связь мощностью «один-ко-многим»;

– идентифицирующая связь мощностью «один-к-одному». Отношение категоризации изображается похожим на IDEF1X

способом. Если внутри дискриминатора (символа разветвления связи) указан символ «Х», то такая связь является исключающей. Это означает, что экземпляр обобщенной сущности может быть ас-социирован с экземпляром только одной из сущностей-категорий. Если дискриминатор пуст, то возможны ассоциации сразу с не-сколькими категориями. В показанном на рис. 21 примере связь ис-

15 В начале 2000-х гг. этот пакет занимал 38% рынка CASE-средств для

информационного моделирования. Сегодня его производитель – фирма Sybase входит в состав компании SAP, а сам пакет позиционируется как инструмент для моделирования бизнес-процессов.

Температура (число)

Температура по шкале Цельсия

(число ≥ –273,15)

Температура по шкале Кельвина

(число ≥ 0)

Температура по шкале Фаренгейта (число ≥ –459,67)

46

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

Кроме того, как видно из рис. 21, на диаграмме «сущность-связь» в данной нотации традиционно не показываются внешние ключи, мигрировавшие через связи. Миграция происходит лишь на этапе создания физической модели, которая генерируется из концепту-альной с привязкой к определенной СУБД. Атрибуты, входящие в состав первичного ключа, подчеркиваются.

учится в

образована вФилиал МИФИКодНазвание

ГруппаШифрГод набора

СтудентНомер студбилетаФамилия...

Студент-очникСтипендия

Студент-заочникМесто работыВторое образование

Студент-вечерникМесто работы

Рис. 21. Диаграмма «сущность-связь» «Институт» в нотации Мартина

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

Таблица 9 Изображение кардинальных чисел в различных нотациях

Мощность Полнота Чена Баркера Бахмана IDEF1X Неполная (0,1:0,1)

Частичная (0,1:1,1) (1,1:0,1)

1:1 неидентифи-цирующая

Полная (1,1:1,1) Частичная (1,1:0,1) – 1:1

идентифи-цирующая Полная (1,1:1,1) –

Неполная (0,1:0,N)

Частичная (0,1:1,N) (1,1:0,N)

1:N неидентифи-цирующая

Полная (1,1:1,N)

Частичная (1,1:0,N) – 1:N идентифи-цирующая Полная (1,1:1,N) –

Неполная (0,N:0,M)

Частичная (0,N:1,M) (1,N:0,M)

N:M неидентифи-цирующая

Полная (1,N:1,M) P

P

47

48

Глава 4. Моделирование поведения

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

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

4.1. Сеть Петри

Модель была предложена в 1962 г. немецким математиком Кар-лом Адамом Петри16, внесшим огромный вклад в теорию сетей, тео-рию автоматов, параллельных и распределенных вычислений. Сеть Петри представляет собой ориентированный граф с вершинами двух типов – позициями и переходами (табл. 10). Дуги этого графа могут соединять только вершины различных типов.

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

16 К. Петри впервые использовал свою сеть в возрасте 13-ти лет, однако

официальной датой ее опубликования считается защита диссертации, про-исшедшая 23 года спустя

49

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

Таблица 10 Нотация сетей Петри

Символ Назначение

Позиция – может использоваться для отображения состоя-ния объекта предметной области

Переход – может использоваться для отображения события или функции

Дуга – указывает возможные пути реализации процесса На рисунке 22 приведен пример сети Петри с четырьмя позиция-

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

Рис. 21. Сеть Петри «Обработка детали»

50

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

На практике также применяются более сложные и развитые сети Петри. Модификации, как правило, касаются следующих трех ком-понентов:

введение иерархии – иерархические сети Петри; определение различий в маркерах, каждый из которых имеет

свои уникальные характеристики – раскрашенные сети Петри (Coloured Petri Nets, CPN);

введение многоместных (содержащих несколько маркеров) пози-ций как последовательных, так и параллельных – сети Петри с мно-гоместными позициями.

Динамическое моделирование с использованием сетей Петри осуществляется на основании статической функциональной и час-тично информационной моделей. Соответствующие инструмен-тальные средства (например, Design/CPN для SADT и CPN-AMI, INCOME для DFD) осуществляют автоматическое преобразование функциональных моделей в прообразы сетей Петри, которые затем дорабатываются вручную. Такое преобразование базируется на том, что маркер моделирует порцию потока данных, а позиция – на-копление и хранение таких порций. Каждая из диаграмм функцио-нальной модели трансформируется в соответствующий компонент (подсеть) иерархической сети Петри. При этом работы и потоки данных DFD-диаграммы (или функции и объекты SADT-диаграммы) отображаются соответственно переходами и позициями. Хранили-ща данных и внешние сущности также преобразуются в позиции для каждого входящего (исходящего) потока (при этом для внешних сущностей маркируются позиции, соответствующие исходящим из них потокам). На основе информационной модели определяются правила срабатывания переходов в зависимости от значений, кото-рые принимают атрибуты используемых сущностей.

С использованием динамической модели подобного типа можно описать и проанализировать

51

механизмы взаимодействия процессов (последовательность, па-раллелизм, альтернатива);

временные отношения между выполнениями процессов (одно-временность, наложение, поглощение, одинаковое время запуска (завершения) и т.п.);

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

управление исключительными ситуациями, определяемое нару-шениями.

Построенные динамические модели позволяют осуществлять следующие операции:

статический анализ системы (компоненты сети, иерархия сети, соответствие типов);

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

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

4.2. Сеть переходов состояний в нотации IDEF3

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

Основой сети являются объекты, изменяющие свои состояния, благодаря чему авторы нотации относят ее к «объектно-центричес-кому» типу. Базовым элементом при этом является круг, который может обозначать как сам объект предметной области, так и его состояние (табл. 11). Внутри круга помещается надпись формата «Объект» или «Объект: состояние». Объекты могут быть связаны друг с другом отношениями обобщения или агрегации. В этом слу-чае связи между объектами могут трактоваться как «является» или «является частью».

52

Таблица 11 Нотация сетей состояний IDEF3

Символ Назначение

Объект, состояние объекта

Переход из одного состояния в другое: слабый – оди-нарная стрелка, сильный – двойная стрелка

Перекрестки И, ИЛИ, исключающее ИЛИ

Символы для организации различных видов связей и отношений

Объект ссылки. В нижней части указывается номер ссылаемого блока

Различные состояния объекта могут быть связаны друг с другом

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

Операция может не только «запускать» переход из одного со-стояния в другое, но и поддерживать некоторое состояние объекта. В этом случае операция ассоциируется не с переходом (со стрел-кой), а с состоянием объекта (с кругом).

Некоторые состояния могут формироваться с использованием более сложной логики, включающей операторы И, ИЛИ, исключаю-

Объект ссылки

Состо-яние

Связь

& O X

53

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

На рисунке 22 показан пример сети переходов состояний, описы-вающей процесс проектирования сайта. Этот процесс ранее уже был смоделирован в виде структурной диаграммы в нотации IDEF0 (см. рис. 5) и диаграммы рабочих процессов в нотации IDEF3 (см. рис. 8). Данный пример полностью совместим с обеими моделями, а ссылки содержат номера единиц работ, показанных на диаграмме рис. 8.

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

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

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

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

54

Рис. 22. Сеть переходов состояний «Создание сайта» в нотации IDEF3

55

Глава 5. Объектно-ориентированное моделирование

Концептуальной основой объектно-ориентированного проектиро-вания является объектная модель, основные принципы которой сформулированы Г. Бучем (Grady Booch), Дж. Рамбо (James Rum-baugh) и И. Якобсоном (Ivar Jacobson) на рубеже 1980–90-х гг. Уни-версальный язык моделирования UML является одним из наиболее известных современных объектных языков и принят в качестве ме-ждународного стандарта17. UML – графический язык моделирова-ния, предназначенный для описания (спецификации), визуализации, моделирования (конструирования) и документирования систем. Од-ним из назначений UML является создание моделей программного обеспечения и информационных систем для автоматической гене-рации программного кода, например, на языках Java или С++.

5.1. Элементы модели UML

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

Таблица 12 Основные сущности UML

Символ Назначение 1 2

Структурные сущности

Объект (object) – сущность, обладающая уникально-стью

Класс (class) – множество объектов с общими атри-бутами

Интерфейс (interface) – множество операций, опре-деляющих набор услуг

17 ISO/IEC 19505:2012. Information technology – Object Management Group Unified Modeling Language (OMG UML)

56

Продолжение табл. 12

1 2

Кооперация (collaboration) – совокупность объектов, взаимодействующих для достижения цели

Действующее лицо (actor) – сущность, находящаяся вне системы и взаимодействующая с ней

Компонент (component) – модульная часть системы с набором интерфейсов

Артефакт (artifact) – элемент информации, который порождается или используется в процессе разработ-ки системы

Узел (node) – вычислительный ресурс, на котором размещаются и выполняются артефакты

Поведенческие сущности

Состояние (state) – период в жизненном цикле объек-та, при котором объект осуществляет деятельность или ожидает наступления события

Деятельность (activity) / действие (action) – частный случай состояния, характеризующийся продолжи-тельными/простыми вычислениями

Вариант использования (use case) – сценарий, опи-сывающий последовательность действий с опреде-ленным результатом

Группирующие сущности

Пакет (package) – группа элементов модели

Аннотационные сущности

Примечание (comment)

57

В UML используются четыре типа отношений, представленные в

табл. 13. Таблица 13

Основные типы отношений UML

Символ, пример Назначение Зависимость – изменения независимой сущ-ности влияют на зависимую. Стрелка на-правлена от зависимой сущности к незави-симой

Ассоциация – одна сущность непосредст-венно связана с другой. Например, частным случаем ассоциации является отношение часть-целое (агрегация)

Обобщение – одна сущность является част-ным случаем другой. Стрелка направлена от частного к общему

Реализация – указывает, что одна сущность является реализацией другой

5.2. Классификация диаграмм UML

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

Структурные диаграммы соответствуют концептуальным и физи-ческим элементам системы и являются статическими компонентами модели. Каждая структурная диаграмма используются для выпол-нения следующих задач:

58

диаграмма классов (class diagram) – моделирование статической структуры классов системы и их взаимосвязей;

диаграмма объектов (object diagram) – моделирование объектов модели и их взаимосвязей;

диаграмма внутренней структуры (composite structure diagram) – более подробное моделирование структуры классов и компонентов системы;

диаграмма пакетов (package diagram) – представление модели системы и управление сложностью;

диаграмма компонентов (component diagram) – моделирование иерархии компонентов системы;

диаграмма развертывания (deployment diagram) – моделирова-ние физической архитектуры системы.

Рис. 24. Структура диаграмм UML

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

59

диаграмма автомата (state machine diagram) – моделирование динамического поведения системы и ее компонентов при переходе из одного состояния в другое;

диаграмма деятельности (activity diagram) – моделирование по-ведения системы в рамках различных вариантов использования;

диаграммы взаимодействия (interaction diagrams) – моделирова-ние процесса обмена сообщениями между объектами.

Диаграмма вариантов использования занимает промежуточное положение между структурными диаграммами и диаграммами пове-дения и часто выделяется в отдельный класс. Диаграмма вариантов использования (use case diagram) предназначена для моделирова-ния функционирования системы в окружающей среде.

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

5.3. Диаграмма классов

Диаграмма классов является центральной диаграммой UML для описания структуры системы. Эта диаграмма может использоваться как для составления словаря или иерархии объектов предметной области, так и для проектирования базы данных. Рассмотрим ос-новные понятия диаграммы классов на расширенном примере «Сту-дент – Группа – Филиал МИФИ», разобранном в главе 4 (рис. 25).

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

60

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

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

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

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

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

61

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

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

62

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

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

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

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

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

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

63

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

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

64

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

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

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

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

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

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

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

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

65

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

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

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

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

66

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

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

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

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

67

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

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

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

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

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

68

Заключение

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

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

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

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

69

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

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

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

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

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

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

70

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

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

Другим примером интегрированной методологии моделирования и анализа систем является продукт, носящий название ARIS (Archi-tecture of Integrated Information Systems), разработанный германской фирмой IDS Scheer19 (в 2010 г. вошла в Software AG). Система ARIS представляет собой комплекс средств анализа и моделирования деятельности предприятия. Ее методическую основу составляет совокупность различных методов моделирования, отражающих раз-ные взгляды на исследуемую систему. Одна и та же модель может разрабатываться с использованием нескольких методов, что позво-ляет использовать ARIS специалистам с различными теоретически- ми знаниями и настраивать его на работу с системами, имеющими свою специфику.

ARIS поддерживает четыре типа моделей, отражающих различ-ные аспекты исследуемой системы:

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

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

19 По имени автора методологии ARIS Августа-Вильгельма Шеера

(August-Wilhelm Scheer)

71

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

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

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

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

организационная диаграмма (Organizational chart); диаграмма цепочек процессов, добавляющих стоимость (Value

added chain diagram, VACD); дерево функций (Function tree); диаграмма цепочек процессов, управляемых событиями (eЕРС)

и ее упрощенная форма – Office process. Останется ли модель на бумаге? Несбывшаяся мечта идеоло-

гов CASE-технологии состояла в изобретении методов и средств, позволяющих автоматически превращать создаваемые структурные модели предметной области в программные коды. Язык объектно-ориентированного моделирования UML придуман именно с этой целью. На формирование инструментальной линейки средств, обеспечивающих конвейер от структурного моделирования до от-ладки программного кода нацелены такие среды, как ARIS, Rational Software и др. Особых успехов удалось достичь в проектировании баз данных, где большинство CASE-средств способны автоматиче-ски преобразовать концептуальную схему в код на SQL определен-ной СУБД.

Однако опыт показывает, что ни одна из используемых на сего-дняшний день нотаций не позволяет выполнять достаточно тонкую

72

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

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

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

Литература

1. Анфилатов В. С., Емельянов А. А., Кукушкин А. А. Системный анализ в управлении / Под ред. А. А. Емельянова. – М.: Финансы и статистика, 2002. – 368 с.

2. Калянов Г. Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов. – М.: Финансы и статистика, 2007. – 240 с.

3. Советов Б. Я., Цехановский В. В., Чертовской В. Д. Теоретические ос-новы автоматизированного управления. – М.: Высшая школа, 2006. – 463 с.

4. Каменнова М. С., Громов А. И., Ферапонтов М. М., Шматалюк А. Е. Мо-делирование бизнеса. Методология ARIS. – М.: Весть-Метатехнология, 2001. – 327 с.

5. Репин В. В., Елиферов В. Г. Процессный подход к управлению. Моде-лирование бизнес-процессов. – М.: РИА «Стандарты и качество», 2004. – 408 с.

6. Елиферов В. Г., Репин В. В. Бизнес-процессы: регламентация и управ-ление. – М.: ИНФРА-М, 2005. – 319 с.

7. Буч Г., Рамбо Д., Якобсон И. Язык UML. Руководство пользователя. – М.: ДМК Пресс, 2006. – 496 с.

8. Фаулер М., Скотт К. UML. Основы. – СПб.: Символ-Плюс, 2002. – 192 с.

73

Содержание

Введение ..................................................................................................3

Глава 1. Основные понятия структурного моделирования.........................4

Глава 2. Методы функционального моделирования................................ 16

Глава 3. Методы информационного моделирования............................... 35

Глава 4. Моделирование поведения....................................................... 48

Глава 5. Объектно-ориентированное моделирование ............................. 55

Заключение............................................................................................ 68

Литература ............................................................................................ 72

Редактор З. И. Сныкова Компьютерная верстка – авторы

ЛР № 02713 от 27.04.1998 Подписано к печати Формат бумаги

60х84/16 Печать ризограф. Бумага МВ Печ. л. 4,5 Заказ № Тираж 72 экз. Цена договорная

Отдел множественной техники ИАТЭ НИЯУ МИФИ 249040, Калужская обл., г. Обнинск, Студгородок, 1