Наиболее известной реализацией IDEF0 является методология SADT, разработанная Дугласом Россом. Основная задача методологии SADT – это построение древовидной функциональной модели.
Сначала функциональность описывается в целом – это называется контекстной диаграммой. При создании контекстной диаграммы формулируется цель моделирования, область (т.е., что будет рассматриваться, как компонент системы, а что как внешнее воздействие) и позиция, в соответствии с которой будет строиться модель.
Методология SADT представляет собой совокупность методов правил и процедур, предназначенных для построения функциональной модели объекта какой либо предметной области. Такая модель отображает функциональную структуру обрабатываемого объекта, т.е. производимые им действия и связи между этими действиями. Методология базируется на следующих принципах:
Во-первых, - блочное моделирование. Функции отображаются в виде блоков, а интерфейсы представлены дугами (т.е. стрелками), входящими в блок и выходящими из него.
Во-вторых, - точность модели, требуя точности описания, не накладывает излишних ограничений на действия аналитика, однако, требует выполнения следующие правила:
-количество блоков на каждом уровне декомпозиции должно быть ограничено (как правило3-6),
-связность диаграмм реализуется при помощи нумерации блоков (иерархическая нумерация),
-метки и наименования должны быть уникальными,
-соблюдение синтаксических правил для графики (блоков, дуг),
-правило определения роли данных (разделение входов и управлений),
SADT- методология может использоваться, как в процессе моделирования и разработки новой системы, так и для анализа функций в уже существующей системы (например в процессе ее модернизации).
Диаграммы потоков данных и диаграммы "сущность-связь" —
наиболее часто используемые в CASE-средствах виды моделей.
Конкретный вид перечисленных диаграмм и интерпретация их
конструкций зависят от стадии ЖЦ ПО.
На стадии формирования требований к ПО SADT-модели и DFD
используются для построения модели "AS-IS" и модели "ТО-ВЕ",
отражая, таким образом, существующую и предлагаемую структу-
ру бизнес-процессов организации и взаимодействие между ними
(использование SADT-моделей, как правило, ограничивается толь-
ко данной стадией, поскольку они изначально не предназначались
для проектирования ПО). С помощью ERD выполняется описа-
ние используемых в организации данных на концептуальном уров-
не, не зависимом от средств реализации базы данных (СУБД).
На стадии проектирования DFD используются для описания
структуры проектируемой системы ПО, при этом они могут уточнять-
ся, расширяться и дополняться новыми конструкциями. Аналогич-
но ERD уточняются и дополняются новыми конструкциями, опи-
сывающими представление данных на логическом уровне, пригод-
ном для последующей генерации схемы базы данных. Данные моде-
ли могут дополняться диаграммами, отражающими системную
архитектуру ПО, структурные схемы программ, иерархию экранных
форм и меню и др.
Перечисленные модели в совокупности дают полное описание
ПО ЭИС независимо от того, является ли система существующей или
вновь разрабатываемой. Состав диаграмм в каждом конкретном слу-
чае зависит от сложности системы и необходимой полноты ее опи-
сания.
Предметной областью для большинства примеров диаграмм,
приведенных в данной главе, является налоговая система РФ, наи-
более полное описание которой содержится в Налоговом кодексе РФ.
Информационные технологии, применяемые в налоговой системе
РФ, имеют определенные особенности*.
ussser
15.06.2008 1:32:05
При разработке модульных программ применяются два метода проектирования – нисходящее и восходящее. При нисходящем проектировании разработка программного комплекса идет сверху вниз.
На первом этапе разработки кодируется, тестируется и отлаживается головной модуль, который отвечает за логику работы всего программного комплекса. Остальные модули заменяются заглушками, имитирующими работу этих модулей. Применение заглушек необходимо для того, чтобы на самом раннем этапе проектирования можно было проверить работоспособность головного модуля. На последних этапах проектирования все заглушки постепенно заменяются рабочими модулями.
При восходящем проектировании разработка идет снизу вверх. На первом этапе разрабатываются модули самого низкого уровня. На следующем этапе к ним подключаются модули более высокого уровня и проверяется их работоспособность. На завершающем этапе проектирования разрабатывается головной модуль, отвечающий за логику работы всего программного комплекса. Методы нисходящего и восходящего программирования имеют свои преимущества и недостатки.
Недостатки нисходящего проектирования:
* Необходимость заглушек.
* До самого последнего этапа проектирования неясен размер программного комплекса и его эксплутационные характеристики, за которые, как правило, отвечают модули самого низкого уровня.
Преимущество нисходящего проектирования – на самом начальном этапе проектирования отлаживается головной модуль (логика программы).
Преимущество восходящего программирования – не нужно писать заглушки.
Недостаток восходящего программирования – головной модуль разрабатывается на завершающем этапе проектирования, что порой приводит к необходимости дорабатывать модули более низких уровней.
На практике применяются оба метода. Метод нисходящего проектирования чаще всего применяется при разработке нового программного комплекса, а метод восходящего проектирования – при модификации уже существующего комплекса.
http://festival.1september.ru/2005_2006/index.php?numb_artic=311526
