Потоки данных являются абстракциями, использующимися для моделирования передачи информации из одной части системы в другую. Потоки на диаграммах изображаются именованными стрелками, ориентация которых указывает направление движения информации.
Процесс (работы) состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Имя процесса должно содержать глагол в неопределенной форме. Каждый процесс имеет уникальный номер для ссылок. Процесс на диаграмме потоков данных изображается, как показано на рисунке 2.15.
Хранилище (накопитель) данных позволяет на указанных участках определять данные, которые будут сохраняться в памяти между процессами. Имя хранилища должно определять его содержимое и быть существительным.
Внешняя сущность представляет собой материальный объект вне контекста системы, являющейся источником или приемником системных данных. Ее имя существительное-«склад товаров». Предполагается, что объекты, представленные как внешние сущности, не должны участвовать ни в какой обработке.
Внешняя сущность обозначается квадратом (рисунок 2.13), расположенным как бы "над" диаграммой и бросающим на нее тень, для того, чтобы можно было выделить этот символ среди других обозначений:
Системы и подсистемы
При построении модели сложной ИС она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого, либо может быть декомпозирована на ряд подсистем.
Подсистема (или система) на контекстной диаграмме изображается следующим образом (рисунок 2.14).
Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями.
Накопители данных
Накопитель данных представляет собой абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми. Накопитель данных может быть реализован физически в виде микрофиши, ящика в картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т.д. Накопитель данных идентифицируется буквой "D" и произвольным числом.
В состав DFD входят словари данных и миниспецификации.
Словари данных являются каталогами всех элементов данных, присутствующих в DFD, включая групповые и индивидуальные потоки данных, хранилища и процессы, а также все их атрибуты.
Миниспецификации обработки — описывают DFD-процессы нижнего уровня. Фактически миниспецификации представляют собой алгоритмы описания задач, выполняемых процессами: множество всех миниспецификаций является полной спецификацией системы.
Процесс построения DFD начинается с создания так называемой основной диаграммы типа «звезда», на которой представлен моделируемый процесс и все внешние сущности. Внешние сущности выделяются по отношению к основному процессу. Для всех внешних сущностей строится таблица событий, описывающая их взаимодействие с основным потоком.
Декомпозиция завершается, когда процесс становится простым, т.е.:
процесс имеет два-три входных и выходных потока;
процесс может быть описан в виде преобразования входных данных в выходные;
процесс может быть описан в виде последовательного алгоритма.
Для простых процессов строится миниспецификация – формальное описание алгоритма преобразования входных данных в выходные.
Следующим шагом после определения полной таблицы событий выделяются потоки данных, которыми обмениваются процессы и внешние сущности.
После построения потоков данных диаграмма должна быть проверена на полноту и непротиворечивость.
Преимущества методики DFD относятся:
возможность однозначно определить внешние сущности, анализируя потоки информации внутри и вне системы;
возможность проектирования сверху вниз, что облегчает построение модели «как должно быть»;
наличие спецификаций процессов нижнего уровня, что позволяет преодолеть логическую незавершенность функциональной модели и построить полную функциональную спецификацию разрабатываемой системы.
Недостатки модели отнесем:
необходимость искусственного ввода управляющих процессов, поскольку управляющие воздействия (потоки) и управляющие процессы с точки зрения DFD ничем не отличаются от обычных;
отсутствие понятия времени, т.е. отсутствие анализа временных промежутков при преобразовании данных (все ограничения по времени должны быть введены в спецификациях процессов).
Универсальный язык моделирования UML.
Собственно с UML началось в 1994 году. Первая версия UML была принята консорциумом OMG (Object Management Group) в январе 1997 года. Авторы UML представляют его как язык для определения, представления, проектирования и документирования программных систем, бизнес-систем и других систем различной природы.
Универсальный язык объектного моделирования UML не зависит от языков программирования и, вследствие этого, может поддерживать любой объектно-ориентированный язык программирования. Он является открытым и позволяет расширять ядро.
Визуальные модели в технологиях управления проектированием систем. В практике эксплуатации программных информационных систем постоянно приходится решать такие задачи как перераспределение вычислений и данных, обеспечение проведения параллельных вычислений,.
Языки и методы моделирования состоят, как правило, из следующих составных частей:
1. Концепции моделирования, их семантика. - это элементы модели
2. Визуальное представление элементов моделирования - нотация
3. Правила применения элементов моделирования. - принципы использования
Плюсы: *одной из решаемых проблем, является все возрастающая сложность систем и проектов.*упрощение общения заказчика и разработчика. Это связано как с повышенной наглядностью модели, так и с ее гибкостью и динамичностью. *Решаются вопросы уменьшения времени, затрачиваемого на разработку проекта, его стоимости и повышения качества.
Синтаксис и семантика основных объектов UML
Классы базовые элементы любой объектно-ориентированной системы. Классы представляют собой описание совокупностей однородных объектов с присущими им свойствами — атрибутами, операциями, отношениями и семантикой.
Атрибут — это свойство класса, которое может принимать множество значений. Операция — реализация функции, которую можно запросить у любого объекта класса. изображение класса «Заказ» в нотации UML.
В языке UML определены три уровня видимости: public (общий) — любой внешний класс, который «видит» данный, может пользоваться его общими свойствами. Обозначаются знаком «+» перед именем атрибута или операции; protected (защищенный) — только любой потомок данного класса может пользоваться его защищнными свойствами. Обозначаются знаком «#»; private (закрытый) — только данный класс может пользоваться этими свойствами. Обозначаются символом «-». Область действия свойства указывает, будет ли оно проявлять себя по-разному в каждом экземпляре класса, или одно и то же значение свойства будет совместно использоваться всеми экземплярами:
instance (экземпляр) — у каждого экземпляра класса есть собственное значение данного свойства;
classifier (классификатор) — все экземпляры совместно используют общее значение данного свойства (выделяется на диаграммах подчеркиванием).
Декомпозиция систем При проектировании сложных информационных систем требуется, для обеспечения наглядности и во избежание потери управления, разбиение системы на части, которые затем рассматриваются отдельно. Различают два вида декомпозиции:
· Структурная - в виде блок-схем, где узлы - это функции, а связи между ними изображают движение данных
· Объектная - в системе выделяются объекты, взаимодействующие между собой по принципу 'клиент-сервер Вот в этом случае и применяется UML для моделирования систем.
Диаграммы в UML основные типы диаграмм, представленные в UML:
Диаграммы использования- описывают функциональность системы. Это изображается в виде так называемых случаев использования (use case), которые определяют взаимодействие пользователя с системой. Они рисуются в виде овалов.
Диаграммы классов- представляют статическую структуру классов, изображаются на диаграммах классов, которые позволяют описать систему в статическом состоянии — определить типы объектов системы и различного рода статические связи между ними.
Диаграммы последовательностей для точного определения логики сценария выполнения прецедента. Диаграммы последовательностей отображают типы объектов, взаимодействующих при исполнении прецедентов
Диаграммы компонентов Диаграммы компонентов позволяют изобразить модель системы на физическом уровне. Элементами диаграммы являются компоненты — физические замещаемые модули системы.
Диаграммы поведения- формирование программного кода на заданном языке программирования.
Диаграммы реализации- описывают динамику системы
Пакеты UMLПакеты представляют собой универсальный механизм организации элементов в группы. В пакет можно поместить диаграммы различного типа и назначения. В отличие от компонентов, существующих во время работы программы, пакеты носят чисто концептуальный характер, то есть существуют только во время разработки. Изображается пакет в виде папки с закладкой, содержащей, как правило, только имя и иногда — описание содержимого.
Методы проектирования с использованием UML