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

Методология IDEF0 разработана на основе методологии SADT (Structured Analysis and Design Technique) и представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. МодельIDEF0 состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга.

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

Функциональный блок (Activity Box) – это графическое изображение в виде прямоугольника (рисунок 4.7) некоторой функции рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «производить услуги», а не «производство услуг»).

Рисунок 4.7 – Функциональный блок нотации IDEF0

Каждая из четырех сторон функционального блока имеет своё определенное значение (роль):

- Control (управление). Стрелки сверху означают на основании чего выполняется данный процесс – законы, стандарты, приказы и т.д.;

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

- Output (выход). Стрелки справа – основные результаты деятельности процесса, конечные продукты;

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

Пример IDF0 - диаграммы приведен на рисунке 4.8.

Рисунок 4.8 – Функциональнаяй модель системы как IDEF0-диаграмма

 

4.2.3 Модель анализа вариантов использования

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

Анализ вариантов использования включает в себя:

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

- распределения поведения, реализуемого вриантом использования, между классами;

- определение атрибутов (свойств) и ассоциаций классов.

В процессе анализа в потоках событий выявляются классы следующих стереотипов:

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

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

- управляющие классы (Control) – обеспечивают координацию поведения объектов в системе.

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

 

Проектирование

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

Проектирование включает в себя:

- идентификацию архитектурных решений и механизмов;

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

- формирование архитектурных уровней;

- проектирование конфигурации системы;

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

 

Модель проектирования

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

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

- специфична для данной реализации;

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

- многоуровневая, динамическая и формализованная;

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

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

Основой для разработки классов проектирования является диаграмма классов. Диаграмма классов (design class diagram) иллюстрирует спецификации программных классов и интерфейсов (например, интерфейсов Java, С#) в приложении. Обычно на такую диаграмму выносится следующая информация:

- классы, ассоциации и атрибуты;

- интерфейсы со своими операциями и константами;

- методы и зависимости.

Пример диаграммы классов (с учетом классов среды разработки MS Visual Studio) приведен на рисунке 4.9. В отличие от диаграммы классов из модели предметной области, диаграммы классов проектирования отображают определения программных сущностей, а не понятия предметной области (рисунок 4.10).

Рисунок 4.9 – Диаграмма классов проектирования

Рисунок 4.10 – От классов предметной области к классам проектирования

 

Класс проектирования может быть реализован в выбранном языке проектирования как интерфейс.

Обычно классы проектирования неактивны. Это значит, что все их объекты «запускаются» в одном адресном пространстве под управлением другого активного объекта.

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

Для описания взаимодейсвия классов проектирования используются диаграммы взаимодействия (последовательности, коммуникации) и состояний. Пример диаграммы состояний приведен на рисунке 4.11.

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

 

Рисунок 4.11 – Диаграмма состояний

Рисунок 4.12 – Декомпозиция системы на подсистемы (диаграмма пакетов)

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

Рисунок 4.13 – Схема взаимодействия программ (ГОСТ 19.701-90)

Модель развертывания

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

Рисунок 4.14 – Диаграмма развертывания

Рисунок 4.15 – Управляющие классы на диаграмме развертывания

Модель развертывания можно представить и в виде «свободного рисунка» (пример на рисунке 4.16).

Рисунок 4.16 – Структура системы

Для модели развертывания характерно следующее:

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

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

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

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

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

Традиционная конфигурация ссистемы предполагает трехуровневую архитектуру:

- уровень клиента (взаимодействие с пользователем);

- уровень взаимодйствия с базой данных;

- уровень прикладной функциональности (прикладная логика).

В современной практике проектирования для представления такой структуры используется шаблон Model-view-controller (MVC, «Модель-представление-поведение»). Данный шаблон – это архитектура программного обеспечения, в которой модель данных приложения, пользовательский интерфейс и управляющая логика разделены на три отдельных компонента, так, что модификация одного из компонентов оказывает минимальное воздействие на другие компоненты.

Шаблон MVC позволяет разделить данные, представление и обработку действий пользователя на три отдельных компонента (рисунок 4.17):

- Модель (Model). Модель предоставляет данные (обычно для View), а также реагирует на запросы (обычно от контролера), изменяя свое состояние.

- Представление (View). Отвечает за отображение информации (пользовательский интерфейс).

- Поведение (Controller). Интерпретирует данные, введенные пользователем, и информирует модель и представление о необходимости соответствующей реакции.

Рисунок 4.17 – Диаграмма классов шаблона MVC

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

 

 

Реализация

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

 

Модель реализации

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

В Унифицированном процессе разработки для отображения решений реализации чаще всего используются диаграммы компонентов. Обозначения компонентов и пример диаграммы приведены на рисунках 4. 18 и 4.19(a, b).

Рисунок 4.18 – Обозначение компонентов (UML)

 

 

a)

b)

Рисунок 4.19 – Диаграмма компонентов

 

Графические решения для отображения программных компонент могут использовать как «свободные рисунки» (рисунок 4.20), так и схемы ГОСТ 19.701-90 (приложение «Примеры схем ГОСТ 19.701-90»)

Рисунок 4.20 – Схема компонентов системы

 

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

 

Пример спецификации класса:

OPCHDAConnectorRuntime

Class Reference

Коннектор в режиме исполнения

Public Member Functions

- OPCHDAConnectorRuntime (TaggedObjectPrimaryTreeNode node)

Конструктор.

- void ChangeDesignModePhase (ProjectItemState state)

- void SetErrorMessage (Exception e)

Установка сообщения об ошибке для системного тега.

- IHistorySyncReader QueryHistorySyncReader (string tag, string attribute)

Возвращает интерфейс опроса истории источника данных.

Protected Member Functions

- override void OnDesignModeChanging (ProjectItemState state)

Запуск/останов.

- override void OnAttributeValueSetting (string tagName, string attributeName,

AttributeValue value)

Устанавливается значение атрибута.

 

Пример функциональной спецификации:

Модуль sendsms.pl:

Название: daemoniz e

Назначение: Перевод выполняемого модуля в режим демона.

Входные параметры: нет.

Выходные параметры: нет.

Название: connectDB

Назначение: Подключение к БД MySQL.

Входные параметры: адрес сервера баз данных, номер порта, имя пользователя, пароль.

Выходные параметры: указатель на объект БД.

Название: LOG

Назначение: Запись строки в LOG-файл.

Входные параметры: Строка для записи в LOG-файл.

Выходные параметры: нет.

Название: sendtextMsg

Назначение: отправка обычного текстового сообщения.

Входные параметры: Номер отправителя, номер получателя, содержимое текстового сообщения.

Выходные параметры: В случае успешной отправки сообщения – 0, в противном случае – 1.

 

 

Модель тестирования

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

- набор тестовых примеров;

- процедры тестирования;

- тестовые компоненты (созданные для автоматизации тестирования).

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

Таблица 4.1 План тестирования

	Функция (вариант использования)	Тест	Результаты
	Начало работы	Запуск программы	Появляется главное окно программы
...	...	...	...

Подтверждение выполнения тестов приводится в виде "скриншотов" (рисунки 4.21, 4.22).

Рисунок 4.21 – Пример тестирования компонент провайдера мобильных услуг

Рисунок 4.22 – Пример создания биометрического пароля

 

 

Примеры описания процесса разработки