Стандарт описания архитектуры IDEF
Существует несколько стандартов, используемых при описании архитектуры.
SADT (Structured Analysis and Design Teqnique)
Этот стандарт сложился к 70–м годам, когда программирование из стихийного процесса стало превращаться в процесс организованный, когда появилось понятие структурного программирования.
Система SADT помогает строить диаграммы при проектировании. Эти диаграммы описывают как структуру, проектированного ПО, так и его модульную декомпозицию, и систему управления.
SADT получило свое дальнейшее развитие в стандарте IDEF0. Этот стандарт был разработан в 1981 году.
В 1993 образовалось семейство стандартов IDEF (Icam DEFinition – название программы).
Их целью является функциональные схемы проектируемого ПО, позволяющей однозначно описать все необходимые процессы этого ПО.
Функциональная методика IDEF базируется на 4 основных понятиях:
1)функциональный блок;
2)интерфейсная дуга;
3)декомпозиция;
4)глоссарий;
Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы.
По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «производить услуги»). На диаграмме функциональный блок изображается прямоугольником (рис. 6.1.). Каждая из четырех сторон функционального блока имеет свое определенное значение (роль), при этом:
- верхняя сторона имеет значение «Управление» (Control);
- левая сторона имеет значение «Вход» (Input);
- правая сторона имеет значение «Выход» (Output);
- нижняя сторона имеет значение «Механизм» (Mechanism).
Рис. 6.1. Функциональный блок
|
|
|
Интерфейсная дуга (Arrow) отображает элемент системы, который обрабатывается функциональным блоком или оказывает иное влияние на функцию, представленную данным функциональным блоком.
С помощью интерфейсных дуг отображают различные объекты, в той или иной степени определяющие процессы, происходящие в системе. Такими объектами могут быть элементы реального мира (детали, вагоны, сотрудники и т.д.) или потоки данных и информации (документы, данные, инструкции и т.д.).
В зависимости от того, к какой из сторон функционального блока подходит данная интерфейсная дуга, она носит название «входящей», «исходящей» или «управляющей».
Любой функциональный блок должен иметь одну управляющую и одну исходящую интерфейсную дугу. Обязательное наличие управляющих интерфейсных дуг является одним из главных отличий стандарта IDEF0 от других методологий.
Декомпозиция (Decomposition) является основным понятием стандарта IDEF0. Принцип декомпозиции применяется при разбиении сложного процесса на составляющие его функции. При этом уровень детализации процесса определяется непосредственно разработчиком модели.
|
|
|
Декомпозиция позволяет постепенно и структурированно представлять модель системы в виде иерархической структуры отдельных диаграмм, что делает ее менее перегруженной и легко усваиваемой.
Глоссарий (Glossary). Для каждого из элементов IDEF0 — диаграмм, функциональных блоков, интерфейсных дуг — существующий стандарт подразумевает создание и поддержание набора соответствующих определений, ключевых слов, повествовательных изложений и т.д., которые характеризуют объект, отображенный данным элементом. Этот набор называется глоссарием и является описанием сущности данного элемента. Глоссарий гармонично дополняет наглядный графический язык, снабжая диаграммы необходимой дополнительной информацией.
Модель IDEF0 всегда начинается с представления системы как единого целого – одного функционального блока с интерфейсными дугами, простирающимися за пределы рассматриваемой области. Такая диаграмма с одним функциональным блоком называется контекстной диаграммой.
В пояснительном тексте к контекстной диаграмме должна быть указана цель (Purpose) построения диаграммы в виде краткого описания и зафиксирована точка зрения разработчика. (Viewpoint).
|
|
|
Определение и формализация цели разработки IDEF0-модели является крайне важным моментом. Фактически цель определяет соответствующие области в исследуемой системе.
Точка зрения определяет основное направление развития проекта и уровень необходимой детализации. Это позволяет «разгрузить проект», отказавшись от детализации отдельных элементов системы, на которых необходимо фокусироваться в первую очередь.
Затем происходит выделение подпроцессов – декомпозиция. Функциональный блок подвергается детализации на другой диаграмме. Эта диаграмма второго уровня содержит функциональные блоки, отображающие главные подфункции блока, отображённого на контекстной диаграмме, и называется дочерней по отношению к нему.
Функциональный блок – предок называется родительским блоком по отношению к дочернему. Далее каждая подфункция дочернего блока детализируется путем аналогичной декомпозиции.
В любом случае декомпозиции все интерфейсные дуги, входящие в родительский блок, фиксируются на дочерней диаграмме. Этим достигается структурная целостность IDEF проекта. Иногда отдельные интерфейсные дуги высшего уровня не имеет смысла продолжать рассматривать на диаграммах нижнего уровня или наоборот, так как это усложняет восприятие. Для таких случаев стандарт IDEF предусматривает понятие тоннелирования. Обозначения «тоннеля» в виде двух круглых скобок вокруг начала интерфейсной дуги означает, что эта дуга не была унаследована от родительского блока и появилась из «тоннеля» только на этой диаграмме. Аналогично такое же обозначение вокруг конца интерфейсной дуги вблизи от блока приёмника означает, что в дочерней диаграмме данного блока эта дуга рассматриваться не будет.
|
|
|
Обычно, IDEF – диаграммы несут в себе сложную и концентрированную информацию. Чтобы сделать их удобно читаемыми, в стандарты приняты ограничения сложности:
- представлять на диаграмме от 3-х до 6-ти функциональных блоков;
- количество дуг, подходящих к функциональному блоку и выходящих из него не более четырёх.
Стандарт IDEF предполагает следующую технологию создания проекта большой группы людей, занимающихся разной деятельностью.
Три основных этапа (условно - рекомендательные):
1) Создание проекта группой специалистов разных сфер деятельности предприятия, для которых создаётся ИС. Эта группа в терминах IDEF0 называется авторами. Они создают черновик проекта, который отвечает на вопросы:
- какие функции и в какой последовательности выполняются в рамках подразделения;
- кто является ответственным за выполнение каждой функции;
- чем руководствуется исполнитель при выполнении каждой из функций;
- что является результатом работы подразделения на выходе.
2) Распространение черновика для рассмотрения согласований и комментариев. Он обсуждается с широким кругом компетентных лиц в терминах IDEF0 читателей.
Все диаграммы черновой модели письменно критикуются и затем возвращаются в рассмотрение автора.
Автор, в свою очередь, письменно соглашается с критикой или опровергает её. Его соображения опять возвращаются читателю. Цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению.
3) Официальное утверждение людьми.
Если у автора и читателя отсутствуют разногласия по поводу адекватности проекта, руководитель рабочей группы его утверждает.
Стандарт DFD
Цель: Построение модели рассматриваемой системы в виде потоков данных.
Эта модель описывает правильный отклик системы в виде данных (выход) при заданном воздействии на вход.
Диаграммы DFD используют четыре основные понятия:
1) Потоки данных – абстракции, использующиеся для обозначения передачи информации (или физический компонент) из одной части системы в другую. Изображаются именованными стрелками.
2) Процесс (работа) - состоит в генерации выходных потоков из входных в соответствии с действием, которое дает название процессу. Имя процесса должно содержать глагол в неопределенной форме с последующим дополнением (например, получить документы при отгрузке продукции). Каждый процесс имеет уникальный номер, который добавляется к номеру диаграммы и этим задается уникальный индекс процесса по всей модели.
3) Внешняя сущность – материальный объект вне контекста системы, который является источником или приемником данных. Ее имя должно содержать существительное (например, склад товара). Внешние сущности не должны, участвовать ни в какой обработке.
4) Хранилище данных (накопитель данных) – фактически, это срезы потоков данных во времени, место, где данные сохраняются в памяти между процессами. Информация, которая там содержится, может использоваться в любое время после ее получения. При этом данные могут выбираться в любом порядке. Имя хранилища – существительное, которое должно определять его содержимое.
Техническое задание. 1
Проектирование ИС.. 1
Архитектурное проектирование. 1
ОО методология. 2
Функционально – ориентированная методика. 2
Стандарт описания архитектуры IDEF. 3
Стандарт DFD.. 5
Дата добавления: 2022-06-11; просмотров: 22; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!