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

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

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

Эти диаграммы представляют сеть связанных между собой работ. Их удобно использовать для описания документооборота и обработки инфор­мации.

DFD описывает:

1. функции обработки информации (работы);

2. документы (стрелки, arrow), объекты, сотрудников или отделы, ко­торые участвуют в обработке информации;

3. внешние ссылки (external reference), которые обеспечивают интер­фейс с внешними объектами, находящимися за границами модели­руемой системы;

4. таблицы для хранения документов (хранилища данных, data store).

Для построения диаграмм DFD в BPWin используется нотация Гейна -Сарсона.

Таблица 2.1. Нотация Гейна - Сарсона

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

Назначение процесса состоит в продуцировании выходных потоков из входных в соответствии с действием, задаваемым именем процесса. Каж­дый процесс должен иметь уникальный номер для ссылок на него внутри диаграммы. Этот номер может использоваться совместно с номером диа­граммы для получения уникального индекса процесса во всей модели.

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

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

Для дополнения модели IDEF0 диаграммой DFD нужно в процессе де­композиции в диалоге Activity Box Count указать тип диаграммы DFD.

14. Структуры данных и диаграммы отношений компонентов данных. Методика

Джексона.

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

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

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

В первую группу входят множества и кортежи. Наиболее существенная характеристика элемента данных в этих структурах – его принадлежность некоторому набору, т. е. отношение вхождения. Данные абстрактные структуры используют, если никакие другие отношения элементов не являются существенными для описываемых объектов

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

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

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

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

Каждая конструкция представляется в виде двухуровневой иерархии, на верхнем уровне которой расположен блок конструкции, а на нижнем – блоки элементов. Нотации конструкций различаются специальными символами в правом верхнем углу блоков элементов. В изображении последовательности дополнительный символ отсутствует. В изображении выбора ставится символ «о» (латинское) – сокращение английского «или» (or). Конструкции последовательности и выбора должны содержать по два или более элементов второго уровня. В изображении повторения в блоке единственного (повторяющегося) элемента ставится символ «*».

Так схема, показанная на рис. 11.22, а, означает, что конструкция A состоит из элементов В, С и D, следующих в указанном порядке. Схема на рис. 11.22, б означает, что конструкция S состоит либо из элемента Р, либо из элемента Q, либо из элемента R. Схема, изображенная на рис. 11.22, в, показывает, что конструкция I может не содержать элементов или содержать один или более элементов X.

Рис. 11.22. Нотация Джексона для представления конструкций: а – последовательность, б – выбор; в – повторение

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

15. UML-диаграммы вариантов использования. Отношения на диаграмме

вариантов использования. Пример построения диаграммы вариантов

использования

Модель использования представляет собой описание функциональности программного обеспечения с точки зрения пользователя.

Определение «вариантов использования».

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

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

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

• основные - обеспечивают требуемую функциональность разрабатываемого программного обеспечения:

• вспомогательные - обеспечивают выполнение необходимых настроек системы и ее обслуживание (например, архивирование информации и т. п.):

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

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

Диаграммы вариантов использования.

Диаграммы вариантов использования позволяют наглядно представить ожидаемое поведение системы. Основными понятиями диаграмм вариантов использования являются: действующее лицо, вариант использования, связь.

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

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

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

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

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

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

16. UML-диаграмма классов. Отношения между классами. Интерфейсы. Объекты.

Параметризованные классы. Пример построения диаграммы классов

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

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

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

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

Кроме внутреннего устройства или структуры классов на соответствующей диаграмме указываются различные отношения между классами. Базовыми отношениями или связями в языке UML являются:

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

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

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

Отношение реализации (realization relationship) Это отношение служит для выделения специальной формы отношения "часть-целое", при которой составляющие части в некотором смысле находятся внутри целого

17. UML-диаграммы состояний объекта. Переходы на диаграмме состояния.

Последовательные состояния. Параллельные состояния. Сложные переходы на

диаграмме состояния

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

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

а б в г

Рис. 7.5. Основные условные обозначения диаграммы состояний объекта: