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

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

Моделирование имеет следующие преимущества:.

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

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

• Позволяет рассматривать различные аспекты взаимодействия системы с различных точек зрения.

• Поддерживает системный анализ.

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

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

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

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

3.2 Методы моделирования для разработки требований 3.2.1 Диаграммы потоков данных.

Диаграммы потоков данных (Data flow diagrams или DFDs) являются базовым понятием для многих традиционных методов моделирования. Диаграммы потоков данных имеют достаточно ограниченный набор графических элементов для представления структуры системы и ее интерфейсов. И, несмотря на то, что изначально диаграммы потоков данных предназначались для описания информации и информационных потоков, диаграммы этого типа могут использоваться для описания потоков любого типа, независимо от того базируется система на использовании компьютерной техники или нет. К сожалению, диаграмма потоков данных не отражает один важный поток информации - поток управления.

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

На диаграммах потоков данных используются следующие элементы:.

• потоки данных (обозначаются стрелками с названиями);.

• элементы преобразования данных (обозначаются окружностями или овалами);.

• хранилища данных (отрезки горизонтальных параллельных линий);.

• внешние сущности (прямоугольники).

На рис. 3.1 приведен простой пример традиционного использования диаграммы потоков данных для моделирования информационный системы.

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

Для определения всех потоков и хранилищ данных используется словарь данных. Каждых овал (окружность) определяет базовую функциональность, которую обеспечивает компонент системы. Эта функциональность описывается с помощью П-спецификаций (Рspec) или мини-спецификаций (mini-spec), которые представляют собой текстовое описание, зачастую написанное с помощью псевдокода.

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

Рис. 3.2 Контекстная диаграмма.

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

Рис. 3.3 Функциональная декомпозиция.

Для иллюстрации применения диаграмм потоков данных рассмотрим пример контекстной диаграммы для системы управления и контроля скорой помощи (рис. 3.4).

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

Рис. 3.4 Контекстная диаграмма для системы управления и контроля скорой помощи.

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

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

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

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

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

Рис. 3.5 Модель системы управления и контроля скорой помощи.

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

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

Рис. 3.6 Детализированная модель системы управления и контроля скорой помощи.

Рис. 3.7 Функциональная структура системы управления и контроля скорой помощи.

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

Рис. 3.8 Системные операции.

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

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

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

Рис. 3.9 Системные операции для системы управления и контроля скорой помощи.

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

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

Таким образом, диаграммы потоков данных:.

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

• определяют функции, потоки и хранилища данных;.

• определяют интерфейсы между функциями;.

• обеспечивают базу для получения системных требований;.

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

широко используются в разработке программного обеспечения; применимы для проектирования системам вообще (не только для ПО).

3.2.2 Диаграммы «сущность-связь».

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

Диаграммы сущность-связь были впервые разработаны Ченом (Chen) в 1976 г и в настоящее время существует множество нотаций ERD.

В таких диаграммах часто используется принятая терминология.

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

Свойство (или атрибут) это информация, которая описывает сущность.

Связь характеризуется множественностью, которая описывает тип связи между сущностями (один к одному, один ко многим, многие ко многим).

Подтипом называется подмножество объектов сущности (например, тип Х является подтипом Y, если любой член множества X принадлежит к Y).

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

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

Рис. 3.10 Диаграмма сущность-связь для системы управления и контроля скорой помощи.