Семантика DFD

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

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

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

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

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

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

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

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

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

 

3.12 Унифицированный язык визуального моделирования UnifiedModelingLanguage (UML)

 

Диаграммы в UML. Классы и стереотипы классов. Ассоциативные классы. Основные элементы диаграмм взаимодействия - объекты, сообщения. Диаграммы состояний: начального состояния, конечного состояния, переходы. Вложенность состояний. Диаграммы внедрения: подсистемы, компоненты, связи. Стереотипы компонент. Диаграммы размещения.

Существует множество технологий и инструментальных средств, с помощью которых можно реализовать в некотором смысле оптимальный проект ИС, начиная с этапа анализа и заканчивая созданием программного кода системы. В большинстве случаев эти технологии предъявляют весьма жесткие требования к процессу разработки и используемым ресурсам, а попытки трансформировать их под конкретные проекты оказываются безуспешными. Эти технологии представлены CASE-средствами верхнего уровня или CASE-средствами полного жизненного цикла (upper CASE tools или fulllife-cycle CASE tools). Они не позволяют оптимизировать деятельность на уровне отдельных элементов проекта, и, как следствие, многие разработчики перешли на так называемые CASE-средства нижнего уровня (lower CASE tools). Однако они столкнулись с новой проблемой - проблемой организации взаимодействия между различными командами, реализующими проект.

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

Мощный толчок к разработке этого направления информационных технологий дало распространение объектно-ориентированных языков программирования в конце 1980-х - начале 1990-х годов. Пользователям хотелось получить единый язык моделирования, который объединил бы в себе всю мощь объектно-ориентированного подхода и давал бы четкую модель системы, отражающую все ее значимые стороны. К середине девяностых явными лидерами в этой области стали методы Booch (GradyBooch), OMT-2 (JimRumbaugh), OOSE - Object-OrientedSoftwareEngineering (IvarJacobson). Однако эти три метода имели свои сильные и слабые стороны: OOSE был лучшим на стадии анализа проблемной области и анализа требований к системе, OMT-2 был наиболее предпочтителен на стадиях анализа и разработки информационных систем, Booch лучше всего подходил для стадий дизайна и разработки.

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

Создание UML началось в октябре 1994 г., когда Джим Рамбо и ГрадиБуч из RationalSoftwareCorporation стали работать над объединением своих методов OMT и Booch. Осенью 1995 г. увидела свет первая черновая версия объединенной методологии, которую они назвали UnifiedMethod 0.8. После присоединения в конце 1995 г. к RationalSoftwareCorporationАйвара Якобсона и его фирмы Objectory, усилия трех создателей наиболее распространенных объектно-ориентированных методологий были объединены и направлены на создание UML.

В настоящее время консорциум пользователей UMLPartners включает в себя представителей таких грандов информационных технологий, как RationalSoftware, Microsoft, IBM, Hewlett-Packard, Oracle, DEC, Unisys, IntelliCorp, PlatinumTechnology.

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

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

2. содержит механизмы расширения и специализации базовых концепций языка.

UML - это стандартная нотация визуального моделирования программных систем, принятая консорциумом ObjectManagingGroup (OMG) осенью 1997 г., и на сегодняшний день она поддерживается многими объектно-ориентированными CASE-продуктами.

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

1. строить модели на основе средств ядра, без использования механизмов расширения для большинства типовых приложений;

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