Лекции по предмету проектирование асоиу
 Скачать 0.94 Mb.
|
|
Модельно-ориентированное проектирование заключается в адаптации состава и характеристик типовой ИС в соответствии с моделью объекта автоматизации. Технология проектирования в этом случае должна обеспечивать единые средства для работы как с моделью типовой ИС, так и с моделью конкретного предприятия. 30 Типовая ИС в репозитории содержит модель объекта автоматизации, на основе которой осуществляется конфигурирование программного обеспечения. Таким образом, модельно-ориентированное проектирование ИС предполагает, прежде всего, построение модели объекта автоматизации с использованием специального программного инструментария. Репозиторий содержит базовую модель ИС, типовые модели определенных классов ИС, модели конкретных ИС предприятий. Базовая модель ИС в репозитории содержит описание бизнес-функций, бизнес-процессов, бизнес-объектов, бизнес-правил, организационной структуры, которые поддерживаются программными модулями типовой ИС. Типовые модели описывают конфигурации ИС для определенных отраслей или типов производства. Модель конкретного предприятия строится либо путем выбора фрагментов основной или типовой модели в соответствии со специфическими особенностями предприятия, либо путем автоматизированной адаптации этих моделей в результате экспертного опроса. Построенная модель предприятия в виде метаописания хранится в репозитории и при необходимости может быть откорректирована. На основе этой модели автоматически осуществляется конфигурирование и настройка ИС. Реализация типового проекта предусматривает выполнение следующих операций: • установку глобальных параметров системы; • задание структуры объекта автоматизации; • определение структуры основных данных; • задание перечня реализуемых функций и процессов; • описание интерфейсов; • описание отчетов; • настройку авторизации доступа; • настройку системы архивирования. 31 12 КЛАССИФИКАЦИЯ СТРУКТУРНЫХ МЕТОДОЛОГИЙ И ИХ КРАТКАЯ ХАРАКТЕРИСТИКА. ТЕХНИЧЕСКИЕ СТРУКТУРНЫЕ КАРТЫ КОНСТАНТАЙНА И ДЖЕКСОНА Методология структурного анализа и проектирования ПО определяет руководящие указания для оценки и выбора проекта разрабатываемого ПО, шаги работы, которые должны быть выполнены, их последовательность, правила распределения и назначения операций и методов. В настоящее время успешно используются практически все известные методологии структурного анализа и проектирования, однако наибольшее распространение получили методологии SADT, структурного системного анализа Гейна-Сарсона, структурного анализа и проектирования Йодана/Де Марко, развития систем Джексона, развития структурных систем Варнье-Орра, анализа и проектирования систем реального времени Уорда-Меллора и Хатли, информационного моделирования Мартина. Несмотря на достаточно широкий спектр используемых методов и диаграммных техник, большинство методологий базируется на следующей совокупности: • диаграммы потоков данных в нотации Йодана/Де Марко или Гейна-Сарсона, обеспечивающие анализ требований и функциональное проектирование информационных систем; • расширения Хатли и Уорда-Меллора для проектирования систем реального времени, основанные на диаграммах переходов состояний, таблицах и деревьях решений, картах и схемах потоков управления; • диаграммы «сущность-связь» (в нотации Чена или Баркера) или скобочные диаграммы Варнье-Орра для проектирования структур данных, схем БД, форматов файлов как части всего проекта; • структурные карты Джексона и/или Константайна для проектирования межмодульных взаимодействий и внутренней структуры модулей, позволяющие развить модель анализа, построенную на базе вышеперечис- ленных средств, до модели реализации. 32 Современные структурные методологии анализа и проектирования классифицируются по следующим признакам: • по отношению к школам – Software Engineering (SE) и Information Engineering (IE); • по порядку построения модели – процедурно-ориентированные, ориентированные на данные и информационно-ориентированные: • по типу целевых систем – для систем реального времени и для ИС. SE является нисходящим поэтапным подходом к разработке ПО, начинающейся с общего взгляда на его функционирование. Затем производится декомпозиция на подфункции, и процесс повторяется для подфункций до тех пор, пока они не станут достаточно малы для их реализации кодированием. В результате получается иерархическая, структурированная, модульная программа. SE является универсальной дисциплиной разработки ПО, успешно применяющейся как при разработке систем реального времени, так и при разработке информационных систем. IE – более новая дисциплина. С одной стороны, она имеет более широкую область применения, чем SE: IE является дисциплиной построения систем вообще, а не только систем ПО, и включает этапы более высокого уровня (например, стратегическое планирование), однако на этапе проектирования систем ПО эти дисциплины аналогичны. С другой стороны. IE – более узкая дисциплина, чем SE. т.к. IE используется только для построения информационных систем, a SE – для всех типов систем. Разработка ПО основана на модели ВХОД-ОБРАБОТКА-ВЫХОД: данные входят в систему, обрабатываются или преобразуются и выходят из системы. Такая модель используется во всех структурных методологиях. При этом важен порядок построения модели. Традиционный процедурно-ориентированный подход регламентирует первичность проектирования функциональных компонент по отношению к проектированию структур данных: требования к данным раскрываются через функциональные требования. При подходе, ориентированном на данные, вход и выход являются наиболее важными – структуры данных определяются первыми, а процедурные компоненты являются производными от данных. Информационно-ориентированный подход, 33 как часть IE-дисциплины, отличается от подхода, ориентированного на данные, тем, что позволяет работать с неиерархическими структурами данных. Основная особенность систем реального времени заключается в том, что они контролируют и контролируются внешними событиями; реагирование на эти события во времени – основная и первоочередная функция таких систем. Главные отличия информационных систем от систем реального времени приведены в таблице 12.1, средствами поддержки этих особенностей и различаются соответствующие структурные методологии. Таблица 12.1 – Отличия ИС от СРВ Информационные системы Системы реального времени Управляемы данными Управляемы событиями Сложные структуры данных Простые структуры данных Большой объем входных данных Малое количество входных данных Интенсивный ввод/вывод Интенсивные вычисления Машинная независимость Машинная зависимость Техника структурных карт используется на фазе проектирования для того, чтобы продемонстрировать, каким образом системные требования будут отражаться комбинацией программных структур. При этом наиболее часто применяются две техники: структурные карты Константайна, предназначенные для описания отношений между модулями, и структурные карты Джексона, предназначенные для описания внутренней структуры модулей. Базовыми строительными блоками программной системы являются модули. Все виды модулей в любом языке программирования имеют ряд общих свойств, нижеперечисленные из которых существенны при структурном проектировании: • модуль состоит из множества операторов языка программирования, записанных последовательно; • модуль имеет имя, по которому к нему можно ссылаться как к единому фрагменту; • модуль может принимать и/или передавать данные как параметры в вызывающей по следовательно сти или связывать данные через фиксированные ячейки или общие области. 34 Структурные карты Константайна являются моделью отношений иерархии между программными модулями. Узлы структурных карт соответствуют модулям и областям данных, потоки изображают межмодульные вызовы. При этом циклические и условные вызовы модулей моделируются специальными узлами, поэтому потоки должны быть изображены проходящими через эти специальные узлы. Межмодульные связи по данным и управлению также моделируются специальными узлами, привязанными к потокам, стрелками указываются направления потоков и связей. Базовым элементом структурной карты является модуль. Возможно использовать различные типы модулей: 1. Модуль – используется для представления обрабатывающего фрагмента для его локализации на диаграмме. 2. Подсистема – ранее определенный модуль, детализированный посредством декомпозиции ранее определенных диаграмм. Может повторно использоваться любое число раз на любых структурных картах. 3. Библиотека – отличается от подсистемы тем, что определена вне проекта данной системы. 4. Область данных – используется для указания модулей, содержащих исключительно области глобальных/распределенных данных. Для взаимоувязывания блоков используются связи следующих типов: • связь по данным; • связь по управлению; • поток – вызов модуля. При построении структурных карт добавление модулей и увязывание их вместе осуществляется с использованием потоков, демонстрирующих иерархию вызовов. Типы потоков: • последовательный; • параллельный; • сопрограмма; 35 При последовательном вызове модули вызываются в порядке их следования. При параллельном вызове модули могут вызываться в любом порядке или одновременно. Для моделирования условных и циклических вызовов применяются узлы: • условный узел – используется для условного вызова модуля-потомка; изображается с помощью ромба, потоки – альтернативные вызовы - изображаются выходящими из него; • итерационный узел – показывает, что модуль-наследник вызывается в цикле; изображается полуокружностью со стрелкой с выходящими из него потоками. Техника структурных карт Джексона основана на методологии структурного программирования Джексона и заключается в продуцировании диаграмм для графического иллюстрирования внутримодульных (а иногда и межмодульных) связей и документирования проекта архитектуры системы ПО. При этом техника позволяет осуществлять проектирование нижнего уровня структуры ПО и на этом этапе является близкой к традиционным блок-схемам. По аналогии со структурными картами Константайна диаграмма Джексона может включать объекты следующих типов: 1. Стуктурный блок – базовая компонента методологии – представляет частную функцию или блок кодов с одним входом и одним выходом. 2. Процедурный блок – является специальным видом структурного блока, представляющим вызов ранее определенной процедуры. 3. Библиотечный блок – аналогичен процедурному и представляет вызов библиотечного модуля. Для взаимоувязывания блоков используются связи следующих типов: • последовательная связь, обеспечивающая последовательное выполнение слева направо; • параллельная связь, обеспечивающая одновременное выполнение блоков; • условная связь, обеспечивающая выбор одной из альтернатив; • итерационная связь, обеспечивающая выполнение блока в цикле. 36 13 МЕТОДОЛОГИЯ SADT Методология SADT разработана Дугласом Россом. На ее основе разработана методология IDEF0. Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этой методоло- гии основываются на следующих концепциях: • графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/ выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих «ограничения», которые, в свою очередь, определяют, когда и каким образом функции выполняются и управляются; • строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают: - ограничение количества блоков на каждом уровне декомпозиции; - связность диаграмм (номера блоков); - уникальность меток и наименований (отсутствие повторяющихся имен); - синтаксические правила для графики (блоков и дуг); - разделение входов и управлений (правило определения роли данных). - отделение организации от функции, т.е. исключение влияния организа- ционной структуры на функциональную модель. Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа 37 функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются. Результатом применения методологии SADT является модель, которая состоит из диаграмм, фрагментов текстов и глоссария, имеющих ссылки друг на друга. Диаграммы – главные компоненты модели, все функции ИС и интерфейсы на них представлены как блоки и дуги. Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как информация, которая подвергается обработке, показана с левой стороны блока, а результаты выхода показаны с правой стороны. Механизм, который осуществляет операцию, представляется дугой, входящей в блок снизу (рисунок 13.1). Одной из наиболее важных особенностей методологии SADT является постепенное введение все больших уровней детализации по мере создания диаграмм, отображающих модель. Рисунок 13.1 – Функциональный блок и интерфейсные дуги Построение SADT-модели начинается с представления всей системы в виде простейшей компоненты – одного блока и дуг, изображающих интерфейсы с функциями вне системы. Поскольку единственный блок представляет всю систему как единое целое, имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг – они также представляют полный набор внешних интерфейсов системы в целом. Затем блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки представляют основные подфункции исходной функции. Данная декомпозиция выявляет полный набор 38 подфункций, каждая из которых представлена как блок, границы которого определены интерфейсными дугами. Каждая из этих подфункций может быть декомпозирована подобным образом для более детального представления. Во всех случаях каждая подфункция может содержать только те элементы, которые входят в исходную функцию. Кроме того, модель не может опустить какие-либо элементы, т.е., как уже отмечалось, родительский блок и его интерфейсы обеспечивают контекст. К нему нельзя ничего добавить, и из него не может быть ничего удалено. Модель SADT представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые представлены в виде блоков. Детали каждого из основных блоков показаны в виде блоков на других диаграммах. Каждая детальная диаграмма является декомпозицией блока из более общей диаграммы. На каждом шаге декомпозиции более общая диаграмма называется родительской для более детальной диаграммы. Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня и выходящие из нее, потому что блок и диаграмма представляют одну и ту же часть системы. На SADT-диаграммах не указаны явно ни последовательность, ни время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции могут быть изображены с помощью дуг. Обратные связи могут выступать в виде комментариев, замечаний, исправлений и т.д. Механизмы показывают средства, с помощью которых осуществляется выполнение функций. Механизм может быть человеком, компьютером или любым другим устройством, которое помогает выполнять данную функцию. Каждый блок на диаграмме имеет свой номер. Блок любой диаграммы может быть далее описан диаграммой нижнего уровня, которая, в свою очередь, может быть далее детализирована с помощью необходимого числа диаграмм. Таким образом, формируется иерархия диаграмм. 39 Для того, чтобы указать положение любой диаграммы или блока в иерархии, используются номера диаграмм. Например, А21 является диаграммой, которая детализирует блок 1 на диаграмме А2. Аналогично, А2 детализирует блок 2 на диаграмме А0, которая является самой верхней диаграммой модели. Одним из важных моментов при проектировании ИС с помощью методологии SADT является точная согласованность типов связей между функциями. Различают по крайней мере семь типов связывания (в скобках указана относительная значимость): 4. Тип случайной связности (0) – наименее желательный. Случайная связность возникает, когда конкретная связь между функциями мала или полностью отсутствует. Это относится к ситуации, когда имена данных на SADT-дугах в одной диаграмме имеют малую связь друг с другом. 5. Тип логической связности (1) – логическое связывание происходит тогда, когда данные и функции собираются вместе вследствие того, что они попадают в общий класс или набор элементов, но необходимых функциональных отношений между ними не обнаруживается. 6. Тип временной связности (2) – связанные по времени элементы возникают вследствие того, что они представляют функции, связанные во времени, когда данные используются одновременно или функции включаются параллельно, а не последовательно. 7. Тип процедурной связности (3) – процедурно-связанные элементы появляются сгруппированными вместе вследствие того, что они выполняются в течение одной и той же части цикла или процесса. 8. Тип коммуникационной связности (4) – диаграммы демонстрируют коммуникационные связи, когда блоки группируются вследствие того, что они используют одни и те же входные данные и/или производят одни и те же выходные данные. 9. Тип последовательной связности (5) – на диаграммах, имеющих последовательные связи, выход одной функции служит входными данными для следующей функции. Связь между элементами на диаграмме является 40 |