
- •Минобрнауки россии
- •Минобрнауки россии
- •График выполнения диссертации на соискание академической степени магистра
- •Содержание
- •Введение
- •Глава 1. Анализ процессов проектирования систем управления
- •1.1. Процессы жизненного цикла программных средств
- •1.2. Российские и международные стандарты в области инженерии программных средств
- •1.3.Постановка задачи исследования
- •1.4. Выводы по главе 1
- •Глава 2. Методы анализа и проектирования систем управления
- •2.1. Методологии анализа и проектирования систем управления
- •2.2. Методы анализа и проектирования систем управления
- •2.3. Классификация методов анализа и проектирования систем управления
- •2.4. Анализ применимости методов анализа и проектирования систем управления на различных этапах жизненного цикла программных средств
- •2.5. Выводы по главе 2
- •Глава 3. Инструментальные средства для анализа и проектирования систем управления
- •3.1. Общая характеристика case-средств
- •3.2. Классификация case-средств
- •3.3. Анализ функциональных характеристик case-средств
- •3.4. Анализ применимости case-средств на этапах процессов жизненного цикла программных средств
- •3.5. Выводы по главе 3
- •Глава 4. Методика выбора case-средств для анализа и проектирования систем управления предприятиями
- •4.1. Методика оценки качества программных средств
- •4.2. Разработка метрики качества case-средств
- •4.3. Обоснование выбора case-средств для анализа и проектирования систем управления предприятиями
- •4.4. Выводы по главе 4
- •Заключение
- •Список литературы
2.2. Методы анализа и проектирования систем управления
Каждая из методологий включает в себя набор методов графического моделирования аспектов предметной области (видов моделей, диаграмм, нотаций). Метод – способ достижения какой-либо цели, решения конкретной задачи; совокупность приёмов или операций практического или теоретического освоения (познания) действительности [3].
Метод SADT (Structured Analysis and Design Technique – метод структурного анализа и проектирования) (рис. 2.2) – это метод, разработанный специально для того, чтобы облегчить описание и понимание искусственных систем, попадающих в разряд средней сложности [43].
В SADT-моделях используются как естественный, так и графический языки. Для передачи информации о конкретной системе источником естественного языка служат люди, описывающие систему, а источником графического языка – сама диаграмма SADT. Графический язык SADT обеспечивает структуру и точную семантику естественному языку модели. Графический язык организует естественный язык определенным и однозначным образом, за счет чего возможно описывать системы, которые до недавнего времени не поддавались адекватному представлению.
SADT-модель дает полное, точное и адекватное описание системы, имеющее конкретное назначение. Целью модели является получение ответов на некоторую совокупность вопросов. Эти вопросы руководят созданием модели и направляют его, т. е. сама модель должна дать ответы на эти вопросы с заданной степенью точности. Если модель отвечает не на все вопросы или ее ответы недостаточно точны, то говорят, что модель не достигла своей цели. Определяя модель таким образом, SADT закладывает основы практического моделирования.
Рис. 2.2. Модель SADT
Модель имеет единственный субъект. Субъектом моделирования служит сама система. Она всегда связана с окружающей средой. Причем часто трудно сказать, где кончается система и начинается среда. В методологии SADT подчеркивается необходимость точного определения границ системы. SADT-модель всегда ограничивает свой субъект. То есть модель устанавливает точно, что является и что не является субъектом моделирования, описывая то, что входит в систему, и подразумевая то, что лежит за ее пределами. Ограничивая субъект, SADT-модель помогает сконцентрировать внимание именно на описываемой системе и позволяет избежать включения посторонних субъектов.
У модели может быть только одна точка зрения. Определение модели тесно связано с позицией, с которой наблюдается система и создается ее модель. Поскольку качество описания системы резко снижается, если оно не сфокусировано ни на чем, SADT требует, чтобы модель рассматривалась все время с одной и той же позиции. Эта позиция называется «точкой зрения» данной модели. Точку зрения лучше всего представлять как место (позицию) человека или объекта, на которое надо встать, чтобы увидеть систему в действии.
Метод IDEF0 (Function Modeling – метод функционального моделирования) (рис. 2.3) предназначен для формализации и описания бизнес-процессов [45]. Отличительной особенностью IDEF0 является его акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами. Метод основан на следующих положениях.
Система представляет собой совокупность взаимосвязанных и взаимодействующих частей, выполняющих некоторую полезную работу. Частями (элементами) системы могут быть любые комбинации разнообразных сущностей, включающие людей, информацию, программное обеспечение, оборудование, изделия, сырье или энергию (энергоносители). Модель описывает, что происходит в системе, как ею управляют, какие сущности она преобразует, какие средства использует для выполнения своих функций и что производит.
Основной концептуальный принцип методологии IDEF – представление любой изучаемой системы в виде набора взаимодействующих и взаимосвязанных блоков, отображающих процессы, операции, действия, происходящие в изучаемой системе. В IDEF0 все, что происходит в системе и ее элементах, принято называть функциями. Каждой функции ставится в соответствие блок. На диаграмме IDEF0, основном документе при анализе и проектировании систем, блок представляет собой прямоугольник. Интерфейсы, посредством которых блок взаимодействует с другими блоками или с внешней по отношению к моделируемой системе средой, представляются стрелками, входящими в блок или выходящими из него. Входящие стрелки показывают, какие условия должны быть одновременно выполнены, чтобы функция, описываемая блоком, осуществилась.
Рис. 2.3. Модель IDEF0
Средства IDEF0 облегчают передачу информации от одного участника разработки модели (отдельного разработчика или рабочей группы) к другому
Разработка моделей IDEF0 требует соблюдения ряда строгих формальных правил, обеспечивающих преимущества метода в отношении однозначности, точности и целостности сложных многоуровневых моделей. Эти правила описываются ниже. Здесь отмечается только основное из них: все стадии и этапы разработки и корректировки модели должны строго, формально документироваться с тем, чтобы при ее эксплуатации не возникало вопросов, связанных с неполнотой или некорректностью документации.
Разработка модели в IDEF0 представляет собой пошаговую, итеративную процедуру [42]. На каждом шаге итерации разработчик предлагает вариант модели, который подвергают обсуждению, рецензированию и последующему редактированию, после чего цикл повторяется. Такая организация работы способствует оптимальному использованию знаний системного аналитика, владеющего методологией и техникой IDEF0, и знаний специалистов – экспертов в предметной области, к которой относится объект моделирования.
Метод DFD (Data Flow Diagrams – диаграммы потоков данных) (рис. 2.4) представляет собой иерархию функциональных процессов, связанных потоками данных [7]. Цель такого представления – продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
Рис. 2.4. Модель DFD
Для построения DFD традиционно используются две различные нотации, соответствующие методам Йордона-ДеМарко и Гейна-Сарсона. Эти нотации незначительно отличаются друг от друга графическим изображением символов.
В соответствии с данным методом модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю. Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям – потребителям информации.
Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут уровень декомпозиции, на котором детализировать процессы далее не имеет смысла.
Главная цель построения иерархии DFD заключается в том, чтобы сделать описание системы ясным и понятным на каждом уровне детализации, а также разбить его на части с точно определенными отношениями между ними. Для достижения этого целесообразно пользоваться следующими рекомендациями:
Размещать на каждой диаграмме от 3 до 6-7 процессов (аналогично SADT). Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один или два процесса.
Не загромождать диаграммы несущественными на данном уровне деталями.
Декомпозицию потоков данных осуществлять параллельно с декомпозицией процессов. Эти две работы должны выполняться одновременно, а не одна после завершения другой.
Выбирать ясные, отражающие суть дела имена процессов и потоков, при этом стараться не использовать аббревиатуры.
Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи DFD. Это можно сделать путем построения диаграммы для каждого события. Каждое событие представляется в виде процесса с соответствующими входными и выходными потоками, накопителями данных, внешними сущностями и ссылки на другие процессы для описания связей между этим процессом и его окружением. Затем все построенные диаграммы сводятся в одну диаграмму нулевого уровня.
Каждый процесс на DFD, в свою очередь, может быть детализирован при помощи DFD или (если процесс элементарный) спецификации. Спецификация процесса должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить их или разработать соответствующую программу.
Метод WFD (Work Flow Diagram - диаграмма потоков работ) (рис. 2.5). Этот метод включает в себя дополнительные объекты, с помощью которых описывается процесс: логические операторы, события начала и окончания процесса, а также элементы, показывающие временные задержки [46].
С помощью логических операторов, которые еще называют блоками принятия решений, показывают альтернативы, которые происходят в процессе, показывается в каких случаях процесс протекает по одной технологии, а в каких случаях по другой. Например, с помощью данных элементов можно описать ситуацию, когда договор, стоимость которого меньше определенной суммы согласуется одной группой сотрудников, а договор с большей стоимостью согласуется по более сложной технологии, в цепочки которой участвуют большее количество сотрудников.
С помощью событий начала и окончания процесса показывается, когда процесс начинается и когда заканчивается. Для жестко формализованных бизнес-процессов, например, таких, как бюджетирование, в качестве событий может выступать время.
В случаях, когда описание бизнес-процесса проводится с целью его дальнейшей временной оптимизации, используют элементы задержки времени, которые показывают места, в которых между последовательно выполняемыми работами имеется временной разрыв. В данном случае последующая работа начинается только через некоторое время после завершения предшествующей.
В классическом подходе WFD на данной схеме не показывают документы, так эти схемы используются для описания процессов нижнего уровня, которые содержат детальные работы, и по названию которых понятно, что является входом и что является выходом.
Рис. 2.5. Модель WFD
Отличительной особенностью WFD-диаграммы является то, что стрелки между операциями бизнес-процесса обозначают не потоки объектов (информационные и материальные), а потоки или временную последовательность выполнения работ.
Метод IDEF3 (Process Description Capture - документирование технологических процессов) (рис. 2.6) предназначен для описания бизнес-процессов нижнего уровня и содержит объекты – логические операторы, с помощью которых показывают альтернативы и места принятия решений и в бизнес-процессе, а также объекты – стрелки, с помощью которых показывают временную последовательность работ в бизнес-процессе [43].
В отличие от классического метода WFD в IDEF3 связи между работами делятся на три типа, обозначения, названия и смысл которых, приведены в таблице 2.3.
Помимо наличия нескольких типов связей между работами в стандарте IDEF3 логические операторы, которые в данном случае называются перекрестками, также делятся на несколько типов: "Исключающий ИЛИ", "И" и "ИЛИ" (рис. 2.7).
Рис. 2.6. Модель IDEF3
Таблица 2.3.
Типы связей между работами в стандарте IDEF3
Название связи |
Вид связи |
Смысл связи |
Связь предшествования |
|
Обозначает, что вторая работа начинает выполняться после завершения первой работы. |
Связь отношения |
|
Обозначает, что вторая работа может начаться и даже закончиться до того момента, когда закончится выполнение первой работы. |
Связь потоков объектов |
|
Одновременно обозначает временную последовательность работ и материальный либо информационный поток. В данном случае вторая работа начинает выполняться после завершения первой работы. При этом выходом первой работы объект название которого надписано над стрелкой (в данном случае документ). Эта связь также обозначает, что объект порождаемый первой работой, используется в последующих работах. |
Рис. 2.7. Применение перекрестков "Исключающий ИЛИ", "И" и "ИЛИ" - схемы расхождения
В таблице 2.4 приведены обозначения, названия и смысл всех типов перекрестков как в схемах схождения, так и в схемах расхождения.
Таблица 2.4.
Обозначения, названия и смысл типов перекрестков в схемах схождения и расхождения
Название перекрестков |
Обозначение перекрестков |
Смысл перекрестков | ||
Схема расхождения |
Схема схождения | |||
"Исключающий ИЛИ" |
|
Только одна последующая работа запускается |
Только одна предшествующая работа должна быть завершена | |
"И" |
Асинхронный |
|
Все последующие работы запускаются |
Все предшествующие работы должны быть завершены |
Синхронный |
|
Все последующие работы запускаются одновременно |
Все предшествующие работы должны быть завершены одновременно | |
"ИЛИ" |
Асинхронный |
|
Одна или несколько последующих работ запускаются |
Одна или несколько предшествующих работ должны быть завершены |
Синхронный |
|
Одна или несколько последующих работ запускаются одновременно |
Одна или несколько предшествующих работ должны быть завершены одновременно |
Метод STD (State Transition Diagram - диаграмма переходов состояний) (рис. 2.8). Моделирует поведение системы во времени в зависимости от происшедших событий (нажатая клавиша, дата отчётного периода) [43]. Такие диаграммы позволяют осуществлять декомпозицию управляющих процессов, происходящих в системе, и описать отношения между управляющими потоками.
Рис. 2.8. Модель STD
С помощью STD можно моделировать последующее функционирование системы исходя из предыдущих состояний. Моделируемая система в текущий момент времени находится только в одном состоянии из всего множества состояний. В течении времени она может изменять своё состояние и тем самым перейти в следующее состояние из заданного множества состояний. Для перехода в новое состояние необходимо условие перехода. Оно может быть информационным (условие появления информации) или временным.
Определим основные объекты STD.
Состояние – рассматривается как устойчивое значение некоторого свойства в течении определённого момента времени. Находясь в текущем состоянии, необходимо знать о предыдущих состояниях, чтобы определить условие перехода в последующее состояние.
Начальное состояние – это узел STD, являющийся стартовой точкой для начального системного перехода. STD имеет только одно начальное состояние, но может иметь множество конечных.
Переход – определяет перемещение моделируемой системы из одного состояния в другое. При этом имя перехода – это событие, которое вызвало этот переход. Переход может быть вызван каким-либо действием (нажатием клавиши)
Триггер – логическое выражение, написанное на макроязыке, которое показывает условие перехода в данное состояние.
Условие перехода – событие, вызывающее переход и определяемое именем перехода. текущее состояние системы определяется ожиданием выбора того или иного пункта меню. выбранный пункт меню – это информационное событие, а сам выбор – действие перехода в следующее состояние системы.
Фактически условие есть некоторое внешнее или внутреннее событие, которое система способна обнаружить и на которое она должна отреагировать определенным образом, изменяя свое состояние. При изменении состояния система обычно выполняет одно или более действий (производит вывод, выдает сообщение на терминал, выполняет вычисления). Таким образом, действие представляет собой отклик, посылаемый во внешнее окружение, или вычисление, результаты которого запоминаются в системе (обычно в хранилищах данных на DFD), для того, чтобы обеспечить реакцию на некоторые из планируемых в будущем событий. Условия (по-другому называемые стимулирующими событиями) идентифицируются именем перехода и возбуждают выполнение перехода. Действия или отклики на события привязываются к переходам и забываются под соответствующим условием.
Метод ERD (Entity-Relationship diagram – диаграмма «Сущность-связь») (рис. 2.9). ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных [7]. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями. Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.). ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации.
Основные понятия диаграмм «Сущность-связь».
Сущность – это класс однотипных объектов, информация о которых должна быть учтена в модели. Каждая сущность должна иметь наименование, выраженное существительным в единственном числе.
Экземпляр сущности – это конкретный представитель данной сущности. Экземпляры сущностей должны быть различимы, т.е. сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности.
Атрибут сущности – это именованная характеристика, являющаяся некоторым свойством сущности. Наименование атрибута должно быть выражено существительным в единственном числе (возможно, с характеризующими прилагательными).
Ключ сущности – это набор атрибутов, значения которых в совокупности являются уникальными для каждого экземпляра сущности. Сущность может иметь несколько различных ключей.
Связь – это некоторая ассоциация между двумя сущностями. Одна сущность может быть связана с другой сущностью или сама с собою. Связи позволяют по одной сущности находить другие сущности, связанные с нею. Каждая связь имеет два конца и одно или два наименования.
Рис. 2.9. Модель ER
Метод IDEF1X (Data Modeling – метод моделирования баз данных) (рис. 2.10) используется для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для удобного построения концептуальной схемы [43].
Концептуальной схемой мы называем универсальное представление структуры данных в рамках коммерческого предприятия, независимое от конечной реализации базы данных и аппаратной платформы. Будучи статическим методом разработки, IDEF1X изначально не предназначен для динамического анализа, тем не менее, он иногда применяется в этом качестве, как альтернатива методу IDEF1.
Использование метода IDEF1X наиболее целесообразно для построения логической структуры базы данных после того, как все информационные ресурсы исследованы и решение о внедрении реляционной базы данных, как части корпоративной информационной системы, было принято. Однако не стоит забывать, что средства моделирования IDEF1X специально разработаны для построения реляционных информационных систем, и если существует необходимость проектирования другой системы, скажем объектно-ориентированной, то лучше избрать другие методы моделирования.
Рис. 2.10. Модель IDEF1X
Модель ESM (Enterprise Structure Model – Модель метаструктуры предприятия) (рис. 2.11) применяется для описания географически распределенной организационной структуры предприятия, описывает географические подразделения компании (офисы, филиалы, пр.), а также материальные и информационные потоки между ними [46]. Данная бизнес-модель по своей сути напоминает классический DFD-стандарт, в котором на разрабатываемой схеме вместо работ, показываются структурные подразделения и взаимодействия между ними.
Модель BCM (Business Control Model – модель управления) (рис. 2.12) – декомпозиция структурных подразделений компании, изображенных на модели метаструктуры предприятия, на которой показываются бизнес-процессы данного структурного подразделения, а также материальные и информационные потоки протекающие между ними [46]. Модель управления BCМ полностью соответствуют классической DFD-схеме и она применяется для описания бизнес-процессов верхнего уровня.
Рис. 2.11. Модель метаструктуры предприятия – ESM
Модель BPM (Business Process Model – процессная модель) (рис. 2.13) – модель, которая применяется для описания бизнес-процессов нижнего уровня и практически соответствуют классической WFD-схеме, за исключением двух особенностей [46]. Первая – блоки принятия решений на модели бизнес-процессов BPM называются управляющими работами и вторая особенность связана с наличием на модели элементов, называемых состоянием, с помощью которых описываются состояния, характеризующие начало и окончания каждой работы. Данный подход, связанный с описанием состояний заимствован из подхода к описанию бизнес-процессов, который называется "Сети Петри".
Рис. 2.12. Модель управления – BCM
Модель BFM (Business Function Model – функциональная модель) (рис. 2.14) – модель, используемая при описании деятельности компании. С помощью этой модели строится дерево функций компании [46].
Модель ERM (Entity-Relationship Model – информационная модель) (рис. 2.15) имеет тип "Сущность-Связь" и предназначена для описания структуры информации, используемой при реализации бизнес-процессов [46]. С помощью данной модели проектируется базы данных.
Модель BOM (Business Organization Model – организационная модель) (рис. 2.16) используется для описания подразделений и должностей организации, а также связей линейного и функционального подчинения [46]. На данной модели также показываются роли, которые играет должность в тех или иных бизнес-процессах. Например, сотрудник, занимающий должность менеджер отдела маркетинга, может играть роль менеджера проекта в проекте по выводу нового проекта на рынок, при этом данный сотрудник может играть и другие роли в других проектах.
Рис. 2.13. Модель бизнес-процессов – BPM
Рис. 2.14. Модель функций – BFM
Рис. 2.15. Информационная модель ERM
Рис. 2.16. Модель организационной структуры – BOM
Модель OD (Objective diagram – диаграмма целей) (рис. 2.17) применяется для описания стратегических целей компании, их иерархической упорядоченности, а также связей целей с продуктами и услугами, производимыми компанией, и бизнес-процессами, поддерживающими их производство [46].
Модель PST (Product/Service tree – дерево продуктов и услуг) (рис. 2.18) применяется для описания продуктов и услуг, производимых в компании, а также их связи со стратегическими целями компании и бизнес-процессами, поддерживающими их производство [46].
Модель FT (Function tree – дерево функций) (рис. 2.19) описывает функции, выполняемые в компании и их иерархию [46]. Данная модель часто применяется для построения дерева бизнес-процессов компании.
Модель FAD (Function allocation diagram – диаграмма окружения процесса) (рис. 2.20) позволяет описать окружение или границы бизнес-процесса, показывая его входы, выходы, поставщиков и клиентов [46].
Рис. 2.17. Модель "Диаграмма целей" – OD
Рис. 2.18. Модель "Дерево продуктов и услуг" – PST
Модель VACD (Value added chain diagram – диаграмма цепочки добавленной стоимости) (рис. 2.21) является аналогом классического DFD-стандарта и используется для описания бизнес-процессов верхнего уровня [46]. Дополнительным отличием данной модели от других процессных моделей является то, что информационные и материальные потоки на схеме VACD изображаются не стрелками, а объектами. При этом для каждого типа потока используется свой объект. На модели VACD, в отличие от классического подхода, также используется логические связи между работами, которые позволяют отобразить логическую последовательность выполнения работ. В качестве одного из вариантов логической последовательности может выступать временная последовательность выполнения работ, что характерно для классического подхода WFD.
Рис. 2.19. Модель "Дерево функций" – FT
Рис. 2.20. Модель "Диаграмма окружения процесса" – FAD
Модель PSM (Process selection matrix – матрица выбора процесса) (рис. 2.22) является аналогом классического DFD-стандарта и используется как альтернатива для модели VACD [46]. Матрица выбора процессов по отношению к диаграмме цепочки добавленной стоимости с одной стороны является более упрощенным вариантом описания процесса, с другой стороны содержит дополнительные объекты, позволяющие показать другие аспекты бизнес-процесса. Простота матрицы выбора бизнес-процессов связана с тем, что на данной модели не показываются информационные и материальные потоки. Что касается других аспектов, то данная модель позволяет на одной схеме компактно и наглядно показать различные варианты выполнения бизнес-процесса, который описывается. Соответственно матрицу выбора процессов целесообразно применять вместо диаграммы цепочки добавленной стоимости в случаях, когда описываемый бизнес-процесс имеет несколько вариантов исполнения, каждый из которых ложится базовую схему.
Рис. 2.21. Модель "Диаграмма цепочки добавленной стоимости" – VACD
Модель eEPC (Extended event driven Process Chain – расширенная цепочка процессов, управляемая событиями) (рис. 2.23) является аналогом классического WFD-стандарта и используется для описания бизнес-процессов нижнего уровня [46]. Дополнительным отличием eEPC-модели от классической WFD-схемы является наличие на модели объекта, который называется событием. С помощью объектов событий изображается факт, время или событие инициирующие начало выполнения работ бизнес-процесса, а также факт или время их завершения.
Рис. 2.22. Модель "Матрица выбора процессов"– PSM
Рис. 2.23. Модель "Расширенная цепочка процессов, управляемая событиями"– eEPC
Модель ORG (Organizational chart – модель организационной структуры) (рис. 2.24) используется для описания организационной структуры компании [46]. На данной модели изображаются структурные подразделения, группы, должности, роли и прочие элементы организационной структуры и связи между ними.
Модель ASTD (Application system type diagram – диаграмма типов информационных систем) (рис. 2.25) используется для описания структуры информационных систем, используемых в компании [46]. На данной модели показываются типы и модули информационных систем, программные продукты, взаимосвязь между ними и бизнес-процессами организации, которые они автоматизируют.
Рис. 2.24. Модель "Организационная структура" – ORG
Рис. 2.25. Модель "Диаграмма типов информационных систем" – ASTD
Диаграмма классов (рис. 2.36). Класс в языке служит для обозначения множества объектов, которые имеют одинаковую структуру, поведение и отношения с объектами из других классов [8].
Рис. 2.36. Диаграмма классов
На диаграмме класс изображают в виде прямоугольника, который дополнительно может быть разделен горизонтальными линиями на две или три секции (рис. 2.37). В этих разделах могут указываться имя класса, атрибуты (переменные) и операции (методы). Иногда в графическом изображении класса добавляется четвертая секция, содержащая описание исключительных ситуаций.
Обязательным элементом обозначения класса является его имя.
На начальных этапах разработки диаграммы класс может обозначаться простым прямоугольником с указанием только его имени (рис. 2.37, а). В дальнейшем диаграммы описания классов дополняются атрибутами (рис. 2.37, б) и операциями (рис. 2.37, в). Чтобы сразу отличить класс от других элементов, секцию атрибутов и операций выделяют горизонтальной линией, даже если она является пустой.
Рис. 2.37. Изображение класса на диаграмме классов
Имя класса должно быть уникальным в пределах диаграммы или совокупности диаграмм классов пакета. Оно указывается в первой верхней секции прямоугольника, записывается по центру секции имени полужирным шрифтом и должно начинаться с заглавной буквы. В качестве имен классов рекомендуется использовать одно или несколько существительных без пробелов между ними. Кроме того, в секции обозначения класса могут находиться ссылки на стандартные шаблоны или абстрактные классы, от которых образован данный класс и, соответственно, от которых он наследует свойства и методы.
Диаграмма объектов – подвид диаграммы классов [44]. Она показывает экземпляры классов (изображенных на диаграмме классов) и отношений между ними в некоторый момент времени, т.е. диаграмма объектов - это своего рода снимок состояния системы в определенный момент времени, показывающий множество объектов, их состояния и отношения между ними в данный момент.
Диаграмма компонентов (рис. 2.38) описывает особенности физического представления системы [44]. Диаграмма компонентов позволяет определить архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый код. Во многих средах разработки модуль или компонент соответствует файлу. Пунктирные стрелки, соединяющие модули, показывают отношения взаимозависимости, аналогичные тем, которые имеют место при компиляции исходных текстов программ. Основными графическими элементами диаграммы компонентов являются компоненты, интерфейсы и зависимости между ними.
Рис. 2.38. Диаграмма компонентов
Диаграмма компонентов разрабатывается для следующих целей:
Визуализации общей структуры исходного кода программной системы.
Спецификации исполнимого варианта программной системы.
Обеспечения многократного использования отдельных фрагментов программного кода.
Представления концептуальной и физической схем баз данных.
В разработке диаграмм компонентов участвуют как системные аналитики и архитекторы, так и программисты. Диаграмма компонентов обеспечивает согласованный переход от логического представления к конкретной реализации проекта в форме программного кода. Одни компоненты могут существовать только на этапе компиляции программного кода, другие - на этапе его исполнения. Диаграмма компонентов отражает общие зависимости между компонентами, рассматривая последние в качестве классификаторов.
Диаграмма автомата (рис. 2.39) — это один из способов детального описания поведения в UML [44]. В сущности, диаграммы автомата, как это следует из названия, представляют собой граф состояний и переходов конечного автомата нагруженный множеством дополнительных деталей и подробностей.
Диаграмма автомата описывает процесс изменения состояний только одного класса, а точнее – одного экземпляра определенного класса, т. е. моделирует все возможные изменения в состоянии конкретного объекта. При этом изменение состояния объекта может быть вызвано внешними воздействиями со стороны других объектов или извне. Именно для описания реакции объекта на подобные внешние воздействия и используются диаграммы автомата.
На диаграмме автомата применяют один основной тип сущностей – состояния, и один тип отношений – переходы, но и для тех, и для других определено множество разновидностей, специальных случаев и дополнительных обозначений. Автомат представляет динамические аспекты моделируемой системы в виде ориентированного графа, вершины которого соответствуют состояниям, а дуги - переходам.
Начальное состояние представляет собой частный случай состояния, которое не содержит никаких внутренних действий. В этом состоянии находится объект по умолчанию в начальный момент времени. Оно служит для указания на диаграмме состояний графической области, от которой начинается процесс изменения состояний.
Конечное (финальное) состояние представляет собой частный случай состояния, которое также не содержит никаких внутренних действий. В этом состоянии будет находиться объект по умолчанию после завершения работы автомата в конечный момент времени.
Рис. 2.39. Диаграмма автомата
Диаграмма деятельности (рис. 2.40) – еще один способ описания поведения, который визуально напоминает блок-схему алгоритма [44]. Используется для моделирования процесса выполнения операций.
Основным направлением использования диаграмм деятельности является визуализация особенностей реализации операций классов, когда необходимо представить алгоритмы их выполнения.
На диаграмме деятельности применяют один основной тип сущностей — действие, и один тип отношений – переходы (передачи управления). Также используются такие конструкции как развилки, слияния, соединения, ветвления. Рекомендуется в качестве имени простого действия использовать глагол с пояснительными словами.
Рис. 2.40. Диаграмма деятельности
Диаграмма вариантов использования (рис. 2.41) – это наиболее общее представление функционального назначения системы [44]. Рассматривая диаграмму вариантов использования в качестве модели системы, можно ассоциировать ее с моделью черного ящика. Каждый вариант использования определяет последовательность действий, которые должны быть выполнены проектируемой системой при взаимодействии ее с соответствующим актером.
На диаграмме использования применяются два типа основных сущностей: варианты использования и действующие лица, между которыми устанавливаются основные типы отношений.
Диаграмма последовательности – это способ описания поведения системы "на примерах" [44]. Фактически, диаграмма последовательности – это запись протокола конкретного сеанса работы системы (или фрагмента такого протокола). В объектно-ориентированном программировании самым существенным во время выполнения является пересылка сообщений между взаимодействующими объектами. Именно последовательность посылок сообщений отображается на данной диаграмме, отсюда и название.
На диаграмме последовательности применяют один основной тип сущностей — экземпляры взаимодействующих классификаторов (в основном классов, компонентов и действующих лиц), и один тип отношений — связи, по которым происходит обмен сообщениями.
Рис. 2.41. Диаграмма вариантов использования
Диаграмма синхронизации (рис. 2.42) представляет собой особую форму диаграммы последовательности, на которой особое внимание уделяется изменению состояний различных экземпляров класса и их временной синхронизации [44].
Рис. 2.42. Диаграмма синхронизации