Лекции по предмету проектирование асоиу
 Скачать 0.94 Mb.
|
|
Тип функциональной связности (6) – диаграмма отражает полную функциональную связность, при наличии полной зависимости одной функции от другой. Диаграмма, которая является чисто функциональной, не содержит чужеродных элементов, относящихся к последовательному или более слабому типу связности. Одним из способов определения функционально-связанных диаграмм является рассмотрение двух блоков, связанных через управляющие дуги. 41 14 МЕТОДОЛОГИЯ СТРУКТУРНОГО СИСТЕМНОГО АНАЛИЗА ГЕЙНА-САРСОНА Структурный анализ – это систематический пошаговый подход к анализу требований и проектированию спецификаций системы независимо от того, является ли она существующей или создается вновь. Целью методологии Гейна-Сарсона является преобразование общих, неясных знаний о требованиях к системе в точные определения. Обе методологии фокусируют внимание на потоках данных, их главное назначение – создание базированных на графике документов по функциональным требованиям. Методологии поддерживаются традиционными нисходящими методами проектирования спецификаций и обеспечивают один из лучших способов связи между аналитиками, разработчиками и пользователями системы за счет интеграции множества следующих средств: 1. DFD – диаграммы потоков данных. Являются графиче скими иерархическими спецификациями, описывающими систему с позиций потоков данных. В состав DFD могут входить четыре графических символа, представляющих потоки данных, процессы преобразования входных потоков данных в выходные, внешние источники и получатели данных, а также файлы и БД, требуемые процессами для своих операций. 2. Словари данных. Являются каталогами всех элементов данных, присутствующих в DFD, включая групповые и индивидуальные потоки данных, хранилища и процессы, а также все их атрибуты. 3. Миниспецификации обработки, описывающие DFD-процессы нижнего уровня и являющиеся базой для кодогенерации. Фактически миниспецифи- кации представляют собой алгоритмы описания задач, выполняемых процессами: множество всех миниспецификации является полной специфи- кацией системы. Миниспецификации содержат номер и/или имя процесса, списки входных и выходных данных и тело процесса, собственно и являющееся спецификацией алгоритма или операции, трансформирующей входные потоки данных в выходные. 42 DFD-диаграммы являются ключевой частью документа спецификации требований. Каждый узел – процесс в DFD может развертываться в диаграмму нижнего уровня, что позволяет на любом уровне абстрагироваться от деталей. Проектные спецификации строятся по DFD и их миниспецификациям автоматически. Наиболее часто для описания проектных спецификаций используется методика структурных карт Джексона, иллюстрирующая иерархию модулей, связи между ними и некоторую информацию об их исполнении. DFD моделируют функции, которые система должна выполнять, но ничего не сообщают об отношениях между данными, а также о поведении системы в зависимости от времени – для этих целей методологии использует диаграммы «сущность-связь» и диаграммы переходов состояний. Главной отличительной чертой методологии Гейна-Сарсона является наличие этапа моделирования данных, определяющего содержимое хранилищ данных в DFD в третьей нормальной форме. Этот этап включает построение списка элементов данных, располагающихся в каждом хранилище данных; анализ отношений между данными и построение соответствующей диаграммы связей между элементами данных; представление всей информации по модели в виде связанных нормализованных таблиц. Методология основана на концепции нисходящего поэтапного разбиения функций системы на подфункции. На первом этапе формируется контекстная диаграмма верхнего уровня, идентифицирующая границы системы и определяющая интерфейсы между системой и окружением. Затем, после интервьюирования эксперта предметной области, формируется список внешних событий, на которые система должна реагировать. Для каждого из таких событий строится пустой процесс в предположе- нии, что его функция обеспечивает требуемую реакцию на это событие, которая в большинстве случаев включает генерацию выходных потоков и событий. На следующем уровне детализации аналогичная деятельность осуществляется для каждого из пустых процессов. 43 15 МЕТОДОЛОГИИ РАЗВИТИЯ СИСТЕМ ДЖЕКСОНА, РАЗВИТИЕ СРВ УОРДА-МЕЛЛОРА, ИНФОРМАЦИОННОГО МОДЕЛИРОВАНИЯ МАРТИНА Классическим примером методологий, ориентированных на данные, является структурное проектирование Джексона. Его базовая процедура проектирования предназначена для «простых» программ («сложная» программа разбивается на «простые» традиционными методами) и включает следующие 4 этапа: 1. Этап проектирования данных. 1.1. Построение системной сетевой диаграммы, демонстрирующей все хранилища, источники и стоки данных в программе. 1.2. Представление каждой входной и выходной структуры данных древовидной структурной диаграммой. 2. Этап проектирования программ. 2.1. Формирование структуры программы комбинированием структур данных. 2.2. Идентификация всех связей между компонентами структур данных. 2.3. Верификация полученной структуры программы. 3. Этап проектирования операций. 3.1. Построение списка операций, необходимых для продуцирования выходных структур данных из входных. 3.2. Назначение операций компонентам структуры программы. 4. Этап проектирования текстов. 4.1. Трансляция построенной модели программы в текстовый вид с добавлением ряда логических условий для управления выполнением циклов и выбором данных. IE-методология Мартина предоставляет общую стратегию разработки информационных систем, фокусирующую внимание на стратегическом планировании и бизнес-процессах. В то же время она является и инженерным подходом к разработке ПО, т.к. обеспечивает нисходящую пошаговую 44 процедуру построения информационной системы. Подход Мартина базируется на двух концепциях: • послойного целостного подхода к разработке интегрированных приложений, базирующегося на стратегическом плане развития информационных систем; • первоначальной направленности на моделирование данных, а затем на функциональное моделирование Основные этапы подхода Мартина: 1. Этап стратегического информационного планирования. Начинается с построения стратегического плана для бизнес-системы, включающего цели и стратегии их достижения. Далее строится модель предметной области, отражающая существующую специфику и определяющая основные бизнес- процессы и организационную структуру бизнес-системы, а также определяется порядок разработки информационной системы. При моделировании используются диаграммы декомпозиции и диаграммы «сущность-связь» для представления основных бизнес-процессов и структур данных, соответственно. 2. Этап анализа. Основные бизнес-процессы, разработанные на первом этапе, используются для разбиения общей задачи на частные, при этом основное внимание уделяется определению информационной и функциональной моделей для частных задач. При этом диаграммы «сущность-связь» трансформируются в нормализованную модель данных, а диаграммы декомпозиции распределяются по подзадачам. Для представления процессов служат DFD, диаграммы зависимости данных и диаграммы декомпозиции, а для соотнесения данных и процессов, в которых эти данные используются, применяются матрицы «сущность/процесс». 3. Этап логического проектирования. Базой для проектирования являются процессы, разработанные на этапе анализа. Используя методики нисходящей функциональной декомпозиции, проектируются спецификации обработки в процессах и их логические структуры данных. При этом используются диаграммы структуры данных, определяющие типы сущностей, их атрибуты и связи, диаграммы декомпозиции и диаграммы 45 деятельности (вид миниспецификации), детализирующие логику процессов. Для согласования требований пользователя создаются прототипы пользовательских интерфейсов с помощью схем экранов/отчетов. 4. Этап физического проектирования и реализации. Производится преобразование логической модели ИС в физическую и ее реализация. 46 16 СПИРАЛЬНАЯ МОДЕЛЬ ЭТАПОВ ПРОЕКТИРОВАНИЯ АСОИУ Используется подход к организации проектирования ИС «сверху-вниз», когда сначала определяется состав функциональных подсистем, а затем постановка отдельных задач. Соответственно сначала разрабатываются такие общесистемные вопросы, как организация базы данных, технология сбора, передачи и накопления информации, а затем технология решения конкретных задач. В рамках комплексов задач программирование осуществляется по направлению от головных программных модулей к исполняющим отдельные функции модулям. При этом на первый план выходят вопросы взаимодействия интерфейсов программных модулей между собой и с базой данных, а на второй план – реализация алгоритмов. В основе спиральной модели жизненного цикла лежит при- менение прототипной технологии или RАD-технологии (технологии быстрой разработки приложений). Согласно этой технологии ИС разрабатывается путем расширения программных прототипов, повторяя путь от детализации требований к детализации программного кода. Естественно, что при прототипной технологии сокращается число итераций и меньше возникает ошибок и несоответствий, которые необходимо исправлять на последующих итерациях, а само проектирование ИС осуществляется более быстрыми темпами, упрощается создание проектной документации. Для более точного соответствия проектной документации разработанной ИС все большее значение придается ведению общесистемного репозитория и использованию САSЕ-технологий. Жизненный цикл при использовании RАD-технологии предполагает активное участие на всех этапах разработки конечных пользователей будущей системы и включает четыре основные стадии информационного инжиниринга: 1. Анализ и планирование информационной стратегии. Пользователи вместе со специалистами-разработчиками участвуют в идентификации проблемной области. 47 2. Проектирование. Пользователи принимают участие в техническом проектировании под руководством специалистов-разработчиков. 3. Конструирование. Специалисты-разработчики проектируют рабочую версию ИС с использованием ЯВУ. 4. Внедрение. Специалисты-разработчики обучают пользователей работе в среде новой ИС. 48 17 МЕТОДОЛОГИЯ ФУНКЦИОНАЛЬНОГО МОДЕЛИРОВАНИЯ IDEF0 Стандарт IDEF0 представляет совокупность методов, правил и процедур, предназначенных для построения функциональной модели, являющейся иерархически связанным структурным представлением действия (или множества действий) некоторого объекта, а также вещественных и информационных объектов (данных), необходимых для функционирования или являющихся результатом этого функционирования. Функциональная модель бизнес-процессов состоит из диаграмм, фрагментов текста и глоссария, имеющих ссылки друг на друга. Диаграммы – главные компоненты модели, которые отображают последовательности взаимосвязанных через общие объекты функций бизнес-процесса. Достоинство функциональной модели заключается в простоте графического представления, которое использует всего два конструктивных элемента: • функциональный блок – описание функций, операций, действий, работ; • интерфейсная дуга – линия, связывающая функциональные блоки и описывающая объекты (потоки объектов). Методология IDEF0 основана на следующих положениях: 1. Цели моделирования. Модель разрабатывается для понимания, анализа и принятия решений о реорганизации или замене существующего либо проектировании нового БП. Модель описывает, что происходит в БП, как им управляют, какие сущности он преобразует, какие ресурсы использует и что производит, частями БП могут быть любые комбинации разнообразных сущностей, включающие людей, информацию, программное обеспечение, оборудование, изделия, сырье или энергию (энергоносители). 2. Блочное моделирование и его графическое представление. Изучаемый БП представляется в виде набора взаимодействующих и взаимосвязанных блоков, отображающих работы, операции, действия. В IDEF0 работы, операции, действия, происходящие в БП и его элементах, принято называть функциями. Каждой функции ставится в соответствие блок. На IDEF0- 49 диаграмме, основном документе при анализе и проектировании БП, блок представляется прямоугольником. Интерфейсы, посредством которых блок взаимодействует с другими блоками или с внешним по отношению к моделируемому БП окружению, представляются стрелками, входящими в блок или выходящими из него. 3. Лаконичность и точность. Документация, описывающая БП, должна быть точной и лаконичной. Многословные характеристики, изложенные в форме традиционных текстов, неудобны. Графический язык позволяет лаконично, однозначно и точно показать все блоки БП и все отношения и связи между ними, выявить ошибочные, лишние или дублирующие связи. 4. Передача информации. Средства IDEF0 облегчают передачу информации от одного участника разработки модели к другому. К числу таких средств относятся: 4.1. диаграммы, основанные на простой графике блоков и стрелок, легко читаемые и понимаемые; 4.2. метки на естественном языке для описания блоков и стрелок, а также глоссарий и сопроводительный текст для уточнения смысла элементов диаграммы; 4.3. последовательная декомпозиция диаграмм, строящаяся по иерархическому принципу, при котором на верхнем уровне отображаются основные функции, а затем, на нижних уровнях, происходит их детализация и уточнение; 4.4. древовидные схемы иерархии диаграмм и блоков, обеспечивающие обозримость модели в целом и всех входящих в нее деталей. 5. Строгость и формализм. Разработка моделей IDEF0 требует соблюдения ряда строгих формальных правил, обеспечивающих преимущества методологии в отношении однозначности, точности и целостности сложных многоуровневых моделей. 6. Итерационное моделирование. Разработка модели в IDEF0 представляет собой итерационную процедуру. На каждом шаге итерации разработчик предлагает вариант модели, который подвергают обсуждению, 50 рецензированию и последующему редактированию, после чего цикл повторяется. Такая организация работы способствует оптимальному использованию знаний системного аналитика, владеющего методологией и техникой IDEF0, и знаний специалистов – экспертов в предметной области, к которой относится объект моделирования. 7. Отделение «организации» от «функции». При разработке моделей следует избегать изначальной «привязки» функций исследуемой системы к существующей организационной структуре моделируемого объекта. Это п ом о г а е т и з бе ж ат ь субъ е кт и в н о й точ к и з р е н и я , н а вя з а н н о й организационной структурой и ее руководством. Организационная структура должна явиться результатом использования модели. Сравнение результата с существующей структурой позволяет, во-первых, оценить адекватность модели, а во-вторых, предложить решения, направленные на совершенствование этой структуры. Компонентами синтаксиса IDEF0 являются: • блоки – представляют функции, определяемые как деятельность, процесс, операция, действие или преобразование; • стрелки – представляют данные или материальные объекты, связанные с функциями; • диаграммы – обеспечивают формат графического и словесного описания моделей. Достоинство функциональной модели заключается в простоте графического представления, которое использует всего два конструктивных элемента: «блок» и «стрелки». Функциональный блок изображается в виде прямоугольника и представляет функцию или активную часть процесса, продуцирующую действие. Поэтому названиями блоков должны быть глаголы в неопределенной форме с последующим дополнением, например, «принять заказ», «определить потребность» и т.д. Название записывается внутри прямоугольника, поэтому должно быть кратким, но в то же время отражать суть процесса. Как правило, 51 название дается по названию действия, обеспечивающего основной выходной результат процесса. Блоки на диаграмме нумеруются. Номер проставляется в правом нижнем углу. Номера блоков используются для их идентификации на диаграмме и в соответствующем тексте. Число блоков на одной диаграмме должно быть от двух до семи. Блоки размещают на диаграмме в определенном порядке – по степени важности или по порядку очередно сти выполнения. Этот порядок называется доминированием. Более доминирующие блоки размещаются выше и левее относительно менее доминирующих. В результате получается ступенчатая схема, показывающая, какие функции оказывают большее влияние на остальные. Каждый блок при необходимости может подвергаться декомпозиции, т.е. разделяться на составляющие действия. В ходе разработки модели могут возникать различные альтернативные варианты декомпозиции. Такие варианты должны особым образом обозначаться (как правило, в виде префикса FEO) к номеру диаграммы). Каждая сторона функционального блока имеет определенное назначение: • левая предназначена для входов; • верхняя – для управления; • правая – для выходов; • нижняя – для механизмов (исполнителей). Такая спецификация отражает определенные системные принципы, принятые при построении диаграмм модели в стандарте IDEF0: • входы преобразуются в выходы; • управление предписывает или ограничивает условия выполнения преобразований; управление в ходе выполнения БП, как правило, остается неизменным; • механизмы (исполнители) показывают, кто или что выполняет преобразование. По завершении БП механизмы могут покидать из БП практически в неизменном состоянии. 52 Интерфейсные дуги изображаются в виде стрелок, ориентация которых отображает направление потоков объектов. Объекты могут быть различной природы: материальные, финансовые, информационные. Стрелки не представляют последовательность событий, как в традиционных блок-схемах. Они лишь показывают потоки объектов. Потоки объектов однонаправленны, т.е. на интерфейсной дуге может быть только одна стрелка. Дуги помечаются текстовыми метками. Так как метки изображают объекты, то метки должны быть именами существительными или существительными с определениями. По характеру использования в функциональных блоках объекты могут быть: • входными; • выходными; • управляющими; • механизмами (исполнителями). |