2.2.8 4. Принципы ограничения сложности idef0-диаграмм
Обычно IDEF0-модели несут в себе сложную и концентрированную информацию, и для того, чтобы ограничить их перегруженность и сделать удобочитаемыми, в соответствующем стандарте приняты соответствующие ограничения сложности:
ограничение количества функциональных блоков на диаграмме тремя-шестью. Верхний предел (шесть) заставляет разработчика использовать иерархии при описании сложных предметов, а нижний предел (три) гарантирует, что на соответствующей диаграмме достаточно деталей, чтобы оправдать ее создание;
ограничение количества подходящих к одному функциональному блоку (выходящих из одного функционального блока) интерфейсных дуг четырьмя.
Разумеется, строго следовать этим ограничениям вовсе необязательно, однако, как показывает опыт, они являются весьма практичными в реальной работе.
2.2.8.5. Применение технологии idef0 к решению задачи автотрассировки
С помощью технологии IDEF0 формализуем алгоритм решения задачи автотрассировки печатной платы программой Situs. Программа является частью пакета Altium, одной из ведущих производителей САПР.
Алгоритм выполнения автотрассировки:
поверхность платы разбивается на треугольники, вершины которых образованы позициями ближайших “препятствий”;
запускается алгоритм “плетения”, который находит путь от начальной до конечной точки трассировки;
путь трассировки находится посредством последовательного перехода от одной ячейки сети к другой, пока не будет достигнута конечная точка;
чтобы получить окончательный вариант трассировщик Situs использует специальный алгоритм, привязывающий путь трассировки к координатной сетке.
Результат применения технологии IDEF0 можно увидеть на рисунке 5.
В свою очередь, как уже отмечалось, IDEF0 больше подходит для решения задач, связанных с управленческим консультированием (реинжинирингом процессов). Этому способствует также тесная связь IDEF0 с методом функционально - стоимостного анализа ABC (Activity Based Costing), позволяющим определить схему расчета стоимости выполнения той или иной деловой процедуры. Однако, существует ряд CASE - систем, предлагающих методологию IDEF0 на этапе функционального обследования предметной области. В таких системах на следующий этап передается просто список всех объектов IDEF0-модели (входы, выходы, механизмы, управление), которые затем рассматриваются на предмет включения в информационную модель.
Список литературы
1. http://e-educ.ru/bd14.html
2. http://studysphere.ru/work.php?id=2810
3. http://khpi-iip.mipk.kharkiv.edu/library/technpgm/labs/lab06.html
4. http://easyelectronics.ru/znakomimsya-s-labview.html
2.3. Объектно-ориентированный анализ и проектирование
2.3.1. Общие сведения
Предметом этой работы является объектно-ориентированный анализ (ООА от Object-Oriented Analysis) ‒ метод для отождествления важных сущностей в задачах реального мира, для понимания и объяснения того, как они взаимодействуют между собой. Этот метод, используемый главным образом в контексте программной или системной инженерии, лучше всего описывается в три этапа.
Информационные модели. На этом этапе центральным является абстрагирование концептуальных сущностей в задаче в терминах объектов и атрибутов. Отношения между сущностями формализуются в связях, которые основываются на линиях поведения, правилах и физических законах, превалирующих в реальном мире.
Модели состояний. Второй этап метода связан с поведением объектов и связей во времени. В ООА каждый объект и связь имеет жизненный цикл – регулярную составную часть динамического поведения. Мы используем модели состояний для формализации жизненных циклов как объектов, так и связей. Модели состояний, которые выражаются в переходных диаграммах и таблицах, взаимодействуют между собой посредством событий, их организовывают в уровни, чтобы сделать систему взаимодействия упорядоченной и понятной.
Модели процессов. Все процессы, связанные с задачей, заключены в действиях моделей состояний. Здесь, на третьем этапе метода, действия расчленяются на фундаментальные процессы и многократно используемые и изображаются усиленной формой традиционных диаграмм потоков данных (ДПД) - ДПД действий. Получаемые таким образом процессы в дальнейшем могут быть преобразованы непосредственно в операторы (методы) объектно-ориентированного проектирования.