Norenkov.Osnovy.Avtomatizirovannogo.Proektirovania.2002 (525024), страница 62
Текст из файла (страница 62)
Блоки (прямоугольники) в DFDсоответствуют функциям, дуги - входным и выходным потокам данных. Поясняющий текст представлен в виде «словарей данных», в которых указаны ком2485 5 Инструментальные средства концептуального проектирования- Поток данныхИмя - Хранилище данных-ПроцессИмя-Внешняя сущностьРис. 5.3. Изображения элементов в нотации Йорданапонентный состав потоков данных, число повторений циклов и т.
п. Для описания структуры информационных потоков можно использовать нотацию Бэкуса - Наура. чОдна из нотаций для DFD предложена Е. Йорданом. В ней описывают процессы (функции), потоки данных, хранилища и внешние сущности, их условныеобозначения показаны на рис. 5.3.Разработка DFD начинается с построения диаграммы верхнего уровня, отражающей связи программной системы, представленной в виде единого процесса, с внешней средой. Декомпозиция процесса проводится до уровня, на котором фигурируют элементарные процессы, которые могут быть представленыодностраничными описаниями алгоритмов (мини-спецификациями) на терминальном языке программирования.Для описания информационных моделей наибольшее распространение получили диаграммы сущность - отношение (ERD — Entity-Relation Diagrams), вкоторых предусмотрены средства для описания сущностей, атрибутов и отношений.
Спецификации хранилищ данных в CASE, как правило, даются с помощью диаграмм сущность - отношение. Стандартной методикой построениятаких диаграмм является IDEF1X.Поведенческие модели о'писывают процессы обработки информации. В инструментальных CASE-системах их представляют в виде граф-схем, диаграммперехода состояний, таблиц решений, псевдокодов (языков спецификаций), процедурных языков программирования, в том числе языков четвертого поколения.В граф-схемах, как и в диаграммах DFD, блоки используют для заданияпроцессов обработки, но дуги имеют иной смысл - они описывают последовательность передач управления (вместе со специальными блоками управления).В диаграммах перехода состояний узлы соответствуют состояниям моделируемой системы, дуги - переходам из состояния в состояние, атрибутыдуг - условиям перехода и инициируемым при их выполнении действиям.
Очевидно, что, как и в других конечно-автоматных моделях, кроме графическойформы представления диаграмм перехода состояний можно использовать также табличные формы. Так, при изоморфном представлении с помощью таблицперехода состояний каждому переходу соответствует строка таблицы, в которой указываются исходное состояние, условие перехода, инициируемое приэтом действие и новое состояние после перехода.2495. Методическое и программное обеспечение автоматизированных системif ААВ.../'Следованиеcas 5OfthenВ1~АЛ\then02А2/Условныйвыбор/CASEвыборwhil e AdoВdoВunti 1Afor AdoВ_Операторы циклаРис. 5.4.
Примеры описания операторов в визуальныхязыках программированияБлизкий по своему характеру способ описания процессов основан на таблицах (или деревьях) решений. Каждый столбец таблицы решений соответствуетопределенному сочетанию условий, при выполнении которых осуществляютсядействия, указанные в нижерасположенных клетках столбца.Таблицы решений удобны при описании процессов с многократными ветвлениями. В этих случаях помогают также визуальные языки программирования, в которых для описания процессов используют графические элементы,подобные приведенным на рис. 5.4.В псевдокодах алгоритмы записываются с помощью как средств некоторого языка программирования (преимущественно для управляющих операторов),так и естественного языка (для выражения содержания вычислительных блоков).
Используются конструкции (операторы) следования, условные, цикла.Служебные слова из базового языка программирования или из DFD записываются заглавными буквами, фразы естественного языка - строчными.Языки четвертого поколения предназначены для описания программ каксовокупностей заранее разработанных программных модулей. Поэтому однакоманда языка четвертого поколения может соответствовать значительномуфрагменту программы на языке 3GL. Примерами языков 4GL могут служитьInformix-4GL, JAM, NewEra, XAL.Мини-спецификации процессов могут быть выражены с помощью псевдокодов (языков спецификаций), визуальных языков проектирования или языковпрограммирования.Объектный подход представлен компонентно-ориентированными технологиями разработки ПО. При объектном подходе ПО формируется из компонентов, объединяющих в себе алгоритмы и данные и взаимодействующих путемобмена сообщениями.
Для поддержки объектного подхода разработан рассматриваемый далее стандартный язык моделирования приложений UML.Методики IDEFO и IDEF3Взаимосвязанная совокупность методик IDEF для концептуального проектирования разработана по программе Integrated Computer Aided Manufacturingв США. В этой совокупности имеются методики функционального, информа2505.5. Инструментальные средства концептуального проектированияционного и поведенческого моделирования и проектирования, в ее состав внастоящее время входит ряд IDEF-методик, часть из которых стандартизирована.Методики IDEF задают единообразный подход к моделированию приложений, но не затрагивают проблем единообразного представления данных в процессах информационного обмена между разными компьютерными системамии приложениями.
Необходимость решения этих проблем в интегрированных АСпривела к появлению ряда унифицированных форматов представления данныхв межкомпьютерных обменах, среди которых наиболее известными являютсяформаты IGES, DXF (в машиностроительных приложениях), EDIF (в электронике) и некоторые другие.
Ограниченные возможности этих форматов обусловили продолжение работ в направлении создания более совершенных методики представляющих их стандартов. На эту роль в настоящее время претендуетсовокупность стандартов STEP.Как отмечено выше, наиболее известной методикой функционального моделирования сложных систем является методика SADT (Structured Analysisand Design Technique), положенная в основу стандарта IDEFO.IDEFO - это более четко очерченное представление методики SADT.SADT - методика, рекомендуемая для начальных стадий проектирования сложных искусственных систем управления, производства, бизнеса, включающихлюдей, оборудование, ПО.
Начиная с момента создания первой версии методика успешно применялась для проектирования телефонных сетей, системуправления воздушными перевозками, производственных предприятий и др.Разработку SADT-модели начинают с формулировки вопросов, на которыемодель должна давать ответы, т. е. формулируют цель моделирования. Далеестроят иерархическую совокупность диаграмм с лаконичным описанием функций.Недостатки SADT-моделей - слабая формализованность для автоматического выполнения проектных процедур на их основе. Однако наличие графического языка диаграмм, удобного для восприятия человеком, обусловливает полезность и применимость методики SADT.Описание объектов и процессов в SADT (IDEFO) выполняется в виде совокупности взаимосвязанных блоков (рис.
5.5).Блоки выражают функции (работы), поэтому их названиями обычно являются та,Управление(условия выполнения)голы или отглагольные существительные."'Типичные примеры функций: планировать,1_разработать, классифицировать, измерить, Вход ^» Выходизготовить, отредактировать, рассчитать,IIпродать (или планирование, разработка,Тклассификация, измерение, изготовление,(средс™™олнения)редактирование, расчет, продажа). ЧислоРисблоков на одном уровне иерархии - не бо- 5.5. Блок ICOM в IDEFOлее 6, иначе восприятие диаграмм будетдиаграммах2515.
Методическое и программное обеспечение автоматизированных системзатруднено. Число уровней иерархии не ограничено, но обычно их не более 5.Блоки нумеруются (номер записывается в правом нижнем углу). Дуги (стрелки) отображают множества объектов (данных), их имена — существительные.Управление определяет условия выполнения. Примеры управления: требования, чертеж, стандарт, указания, план. Механизм выражает используемые средства, например: компьютер, оснастка, заказчик, фирма.
Входы и выходы могутбыть любыми объектами.Блоки на рис. 5.5 в англоязычной литературе называют блоками ICOM(Input— Control — Output — Mechanism).Рассмотрим пример функциональной модели для процесса создания САПРна предприятии, на котором ранее автоматизация проектирования была развита слабо.Диаграмма верхнего (нулевого) уровня АО включает единственный блокICOM «Разработать САПР». В качестве исполнителей фигурируют специализированная организация, занимающаяся проектированием автоматизированныхсистем и называемая консалтинговой фирмой, а также представители организации-заказчика, объединенные в создаваемый на предприятии отдел САПР.Диаграмма первого уровня, показанная на рис.
5.6, а, включает блоки А1 —обследования предприятия, А2 — проектирования САПР, A3 - реализации САПРи А4 — испытаний системы. Диаграммы следующего второго уровня, раскрывающие первые блоки A l , A2 и A3, представлены на рис. 5.6,б,виг соответственно (на этих рисунках не отмечены данные, соответствующие внутреннимстрелкам диаграмм, а также стрелки условия «финансы»). При обследованиипредприятия специалисты консалтинговой фирмы вместе с работниками отдела САПР изучают структуру предприятия, типичные маршруты проектирования, информационные потоки и на этой базе разрабатывают модель «As Is».Далее создается новая модель «То Be» с учетом не только требований автоматизации проектирования, но и будущих информационных потребностей процессов управления и делопроизводства. Модель «То Be» составляет основутехнического предложения на создание САПР.При проектировании САПР выбирают аппаратно-программную платформу,базовое ПО проектирующих и обслуживающих подсистем, разрабатываютструктуру корпоративной сети, определяют типы сетевого оборудования, серверов и рабочих станций, выявляют необходимость разработки оригинальныхпрограммных компонентов.Реализация проекта САПР включает подготовку помещений, монтаж кабельной сети, обучение будущих пользователей САПР, закупку и инсталляциюТО и ПО.Разработка SADT-моделей состоит из ряда этапов.1.
Сбор информации. Источниками информации могут быть документы,наблюдение, анкетирование и т. п. Существуют специальные методики выбораэкспертов и анкетирования.2525.5. Инструментальные средства концептуального проектирования2. Создание модели. Используется нисходящий стиль: сначала разрабатываются верхние уровни, затем — нижние.3. Рецензирование модели. Реализуется в итерационной процедуре рассылки модели на отзыв и ее доработки по замечаниям рецензентов, в завершениесобирается согласительное совещание.Связи функциональной модели, отражающей функции, со структурной моделью, отражающей средства выполнения функций, выражаются с помощьюспециальных словарей, дающих однозначное толкование вводимых имен ресурсов.МетодикиСАПРТехническое ,предложениеКонсалтинговаяфирмаОтделСАПРТехническоепредложениеОпределитьинформационныеОтделСАПР*.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
