В начало

Лекция 10

Методы и языки моделирования.

Структурный подход и методика IDEF.

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

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

Язык UML

 

На сегодняшний день, в основном, применяются две методологии моделирования АИС:

•       структурная (функциональная) – рассматривает систему в терминах функций и передачи информации между ними;

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

 

10.1. Структурная методология

Структурная методология использует модели, отражающие:

•       функциональную декомпозицию системы;

•       последовательность выполняемых действий;

•       передачу информации между функциональными процессами;

•       отношения между данными.

Охарактеризуем далее наиболее распространенные модели этих групп и языки (графические нотации) их описания.

 

10.1.1. Функциональная модель IDEF0

Модель IDEF0 является частью семейства стандартов IDEF (IDEF - Integrated DEFinition – взаимная совокупность методик и моделей концептуального проектирования, разработана в США по программе Integrated Computer-Aided Manufacturing) и представляет собой описание системы в целом как множества взаимозависимых действий или функций, причем IDEF0-функции системы исследуются независимо от объектов, которые обеспечивают их выполнение.

Наиболее часто модель IDEF0 используется при исследовании и проектировании систем на концептуальной стадии разработки, для сбора данных и моделирования процессов «как есть» («as is»). При построении модели необходимо определить:

1. Назначение модели – набор вопросов, на которые должна ответить модель.

2. Границы моделирования – ширину охвата предметной области и глубину детализации.

3. Целевую аудиторию, для нужд которой создается модель.

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

Главной организационной единицей модели (как и всех моделей, рассматриваемых ниже) является диаграмма. Графический язык модели содержит всего два элемента – блоки (функции) и стрелки (связи).

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

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

•       I (Input) – вход – потребляемая и/или преобразуемая информация;

•       C (Control) – управление – ограничения и инструкции, влияющие на ход выполнения процесса;

•       О (Output) – выход – информация, получаемая в результате работы функции;

•       M (Mechanism) – исполняющий механизм, который используется для выполнения процесса, но остается неизменными.

 

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

Комбинированные стрелки соединяют функциональные блоки и определяют порядок выполнения функций, передачи информации и управления. Рассматривают пять основных видов соединений (слайд 3):

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

•         «Выход – управление» - один блок управляет работой другого;

•         «Выход – обратная связь на  управление» - зависимый блок формирует обратную связь на управление;

•         «Выход – обратная связь на вход» - описание циклов повторной обработки;

•         «Выход – механизм исполнения» - выход одного блока является инструментом для исполнения другого.

 

10.1.2. Метод моделирования IDEF3

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

Графический язык модели содержит следующие элементы (слайд 4):

•       действия;

•       связи;

•       соединения;

•       указатели.

 

Действия изображаются в виде прямоугольника, содержащего имя действия и составной номер действия, который включает номер родительского действия (на рисунке – 1) и непосредственный номер самого действия (на рисунке – 5), разделенные точкой. Действие моделирует некоторую функцию, преобразующую вход в выход. По своему назначению почти идентиченно функциональным блокам IDEF0 и DFD.

 

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

Связь типа «Временное предшествование» обозначает, что исходное действие должно завершиться прежде, чем начнется конечное действие;

Связь типа «Объектный поток» обозначает, что выход исходного действия является входом конечного действия (очевидно, включает и связь «Временное предшествование»).

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

 

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

Допустимы следующие типы указателей:

•       Объект (Object) – для описания объекта, принимающего участие в действии;

•       Ссылка (GoTo) – для реализации цикличности выполнения действий;

•       Единица действия (Unit of Behavior –UOB) – для многократного изображения на диаграмме одного и того же действия;

•       Заметка (Note) – для документирования информации общего характера;

•       Уточнение (Elaboration – Elab) – для уточнения или более подробного описания элемента, изображенного на диаграмме.

Соединения используются для описания ветвления процесса.

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

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

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

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

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

 

10.1.3. Диаграммы потоков данных (Data Flow Diagrams - DFD)

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

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

Для построения DFD традиционно используются две различные нотации, соответствующие методам Йордона-Де Марко и Гейна-Сэрсона. Эти нотации незначительно отличаются друг от друга графическим изображением символов. Приведем графический язык нотации Гейна-Сэрсона (слайд 6):

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

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

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

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

 

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

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

На слайде 8 приведена сравнительная таблица графических обозначений нотаций Гейна-Сэрсона (Gane-Sarson) и Йордона-ДеМарко (Yourdon-DeMarco).

 

10.2. Объектно-ориентированная методология

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

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

 

10.2.1. Язык UML

Большинство современных методов ООАП основаны на использовании языка UML. Унифицированный язык моделирования UML (Unified Modeling Language) представляет собой язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы. Структуру UML составляет стандартный набор диаграмм и нотаций.

Главными в разработке UML были следующие цели:

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

•            предусмотреть механизмы расширяемости базовых концепций языка;

•            обеспечить независимость от конкретных языков программирования и процессов разработки.

•        интегрировать лучший практический опыт.

В настоящее время UML находится в процессе стандартизации, проводимом организацией по стандартизации в области объектно-ориентированных методов и технологий (OMG - Object Management Group).

Язык UML имеет три основных разновидности понятий: сущности (или предметы), отношения, диаграммы (слайд 9).

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

•       структурные – представляют статические части моделей (понятийные или физические элементы);

•       поведенческие – динамические части моделей, представляющие поведения во времени и пространстве;

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

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

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

 

10.2.2. Диаграммы UML

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

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

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

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

Ребра графа диаграммы – ассоциация, агрегация, обобщение и зависимость.

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

•       * - неограниченное количество;

•       1..* - один или более;

•       0..* - ноль или более;

•       1..10 – заданный диапазон;

•       7 – точное количество.

Агрегация (разновидность ассоциации) - определяет отношение «часть – целое». При этом агрегирующая сущность содержит только указатели на части.

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

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

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

 

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

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

Вершинами графа диаграммы являются актеры и прецеденты.

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

Прецедент (элемент Use Case) – описание последовательности действий, которые выполняются системой и производят для актера видимый результат. Каждый прецедент задает определенный способ использования системы. Совокупность всех прецедентов определяет полный набор функциональных возможностей системы.

Ребра графа диаграммы – ассоциация, обобщение, включение, расширение.

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

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

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

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