Проектирование системы. Проектирование систем. Проектирование информационных систем ( на примере методов структурного системного анализа)
 Скачать 1.64 Mb.
|
|
1967 – Структурное программирование (Structured programming) – Edsger Dijkstra, • примерно 1975 – Структурное программирование Джексона (Jackson Structured Programming) – Michael A. Jackson. Структурное программирование приводит к Структурному проектирова- нию, что в свою очередь приводит к Структурному системному анализу: • примерно 1975 – появление на рынке Метода структурного анализа и проектирования SADT (Structured Analysis and Design Technique) – Doug- las T. Ross; • примерно 1975 – Структурное проектирование (Structured Design) – Larry Constantine, Ed. Yourdon и Wayne Stevens; • примерно 1978 – Структурный анализ (Structured Analysis) – Tom De- Marco, Yourdon, Gane & Sarson, McMenamin & Palmer; • в 1979 опубликован Структурный анализ и системная спецификация (Structured Analysis and System Specification) – Tom DeMarco. В течение 1980х начинают появляться инструменты для автоматизации черчения диаграмм: • 1981 – опубликована (и в 85-93 получает развитие) Методология IDEF0, основанная на SADT и инструментальных средствах создания диаграмм (разработана Дугласом Т. Россом, Douglas T. Ross). • в 1983 впервые представлен Метод структурного системного анализа и проектирования SSADM (Structured Systems Analysis and Design Method), разработанный в UK Office of Government Commerce. По аналогии с Computer-Aided design and Computer-Aided Manufacturing (CAD/CAM), использование этих инструментов было названо Computer-Aided Software Engineering (CASE). Методы СА и СП (в частности, SSADM) сопровождаются нотациями (диаграммами), облегчающими взаимодействие между пользователями и разра- ботчиками. Это были: 164 • структурные схемы (Structure Charts) – для структурного проектирования; • диаграммы потоков данных (Data Flow Diagrams, DFD) – для структурно- го анализа; • модели данных (Data Model Diagrams). Эти диаграммы использовались структурными методами в различных комбинациях. Среди них встречалось множество вариаций. Примерно в 1990 появляется термин «инженерия разработки ПО» (Infor- mation Engineering, IE, James Martin ), являющаяся логическим расширением структурных методов, появившихся в течение 1970х. 4.2. Метод структурного анализа и проектирования SADT Определение SADT SADT (Structured Analysis and Design Technique) – это методология инже- нерии разработки ПО (software engineering) для описания систем в виде иерар- хии функций (функциональной структуры). Предпосылки и история SADT Структурный анализ возник в конце 60-х годов в ходе революции, вы- званной структурным программированием. Метод SADT был предложен Ду- гласом Т. Россом как способ уменьшить количество дорогостоящих ошибок за счет структуризации на ранних этапах создания системы, улучшения контактов между пользователями и разработчиками и сглаживания перехода от анализа к проектированию. Дуглас Т. Росс часть своих PLEX-теорий относящихся к ме- тодологии и языку описания систем, назвал «Методология структурного анали- за и проектирования» (SADT). Исходная работа над SADT началась в 1969 г. Первое ее крупное приложение было реализовано в 1973 г. при разработ- 165 ке большого аэрокосмического проекта, когда она была несколько пересмотре- на сотрудниками SofTech, Inc. В 1974 г. SADT была еще улучшена и передана одной из крупнейших европейских телефонных компаний. Таким образом, к началу 70-х SADT представляет собой четкую фор- мальную процедуру. Появление SADT на рынке произошло в 1975 г. после годичного оформ- ления в виде продукта. К 1981 г. SADT уже использовали более чем в 50 компаниях при работе более чем над 200 проектами, включавшими более 2000 людей и охватывавши- ми дюжину проблемных областей, в том числе телефонные сети, аэрокосмиче- ское производство, управление и контроль, учет материально-технических ре- сурсов и обработку данных. Ее широкое распространение в настоящее время в европейской, даль- невосточной и американской аэрокосмической промышленности (под названием IDEF0) позволяет эти цифры существенно увеличить. Таким об- разом, SADT выделяется среди современных методологий описания систем благодаря своему широкому применению. Почему SADT имеет такое широ- кое применение? Во-первых, SADT является единственной методологией, легко отра- жающей такие системные характеристики, как управление, обратная связь и исполнители. Это объясняется тем, что SADT изначально возникла на базе проектирования систем более общего вида в отличие от других структурных методов, «выросших» из проектирования программного обеспечения. Во-вторых, SADT в дополнение к существовавшим в то время концеп- циям и стандартам для создания систем имела развитые процедуры под- держки коллективной работы и обладала преимуществом, связанным с ее применением на ранних стадиях создания системы. Кроме того, широкое использование SADT показало, что ее можно со- четать с другими структурными методами. Это достигается использованием графических SADT-описаний в качестве схем, связывающих воедино раз- 166 личные методы, примененные для описания определенных частей системы с различным уровнем детализации. Таким образом, неадекватные спецификации систем того времени вызва- ли создание графического языка SADT, а его усиленное использование преоб- разовало SADT в законченную методологию, способную повысить качество продуктов, создаваемых на ранних стадиях развития проекта. Итак, SADT началась как язык описания функционирования систем об- щего вида, а по мере применения ее процедуры описания систем были улучше- ны и дополнены. Основы SADT SADT использует два типа диаграмм: 1) модели деятельности (activity models); 2) модели данных (data models). SADT использует стрелки для построения этих диаграмм и имеет следую- щее графическое представление: • главный блок (box), где определено названиее процесса или действия; • с левой стороны блока – входящие стрелки: входы действия; • сверху – входящие стрелки: данные, необходимые для действия; • внизу – входящие стрелки: средства, используемые для действия; • справа – исходящие стрелки: выход действия. SADT использует декомпозицию на основе подхода «сверху вниз». Каждый уровень декомпозиции содержит до 6 блоков. SADT начинается с уровня (level) 0, затем может быть детализирован на более низкие уровни (1, 2, 3, ...). Например, на уровне 1, блок уровня 0 будет детализирован на несколько элементарных блоков и так далее … 167 Рис. 4.1. Пример уровня 0 На уровне 1 действие «Manufacture computers», может быть разбито (de- clined ), например на 4 блока: 1) получить электронные компоненты («receive electronic components»); 2) сохранить электронные компоненты («store electronic components»); 3) доставить электронные компоненты на сборочную линию («bring electron- ic components to the assembly line»); 4) собрать компьютеры («Assemble computers»). Семантика стрелок для действий (activities): • входы (Inputs) входят слева и представляют данные или предметы по- требления (consumables), нужные действию (that are needed by the activity); • выходы (Outputs) выходят справа и представляют данные или продукты, производимые действием (activity); • управления (Controls) входят сверху и представляют команды, которые влияют на исполнение действия, но не потребляются. В последней редак- ции IDEF0 – условия, требуемые для получения корректного выхода. Данные или объекты, моделируемые как управления, могут быть транс- формированы функцией, создающей выход; 168 • механизмы означают средства, компоненты или инструменты, использу- емые для выполнения действия; представляют размещение (allocation) действий. Семантика стрелок для данных (data): • входы (Inputs) – это действия, которые генерируют эти данные (are activities that produce the data); • выходы (Outputs) потребляют эти данные (consume the data); • управления (Controls) влияют на внутреннее состояние этих данных (influence the internal state of the data). Роли SADT-процесса: • авторы (Authors) – разработчики SADT модели; • комментаторы (Commenters) – рецензируют (review) работу авторов; • читатели (Readers) – возможные (the eventual) пользователи SADT диа- грамм; • эксперты (Experts) – те, от кого авторы получают специальную информа- цию о требованиях и ограничениях; • технический комитет (Technical committee) – технический персонал, от- ветственный за рецензирование (reviewing) SADT модели на каждом уровне; • библиотекарь проекта (Project librarian) – ответственный за все докумен- ты проекта; • менеджер проекта (Project manager) – имеет полную техническую ответ- ственность за системный анализ и проектирование (has overall technical responsibility the system analysis and design); • аналитик (Monitor) (Chief analyst) – эксперт в области SADT, помогаю- щий и консультирующий персонал проекта по использованию SADT; • инструктор (Instructor) – обучает авторов и комментаторов SADT. 169 Этапы моделирования. Разработка SADT модели представляет собой итеративный процесс и состоит из нижеследующих условных этапов. 1. Создание модели группой специалистов, относящихся к различным сфе- рам деятельности предприятия. На этом этапе авторы опрашивают ком- петентных лиц, получая ответы на следующие вопросы: • что поступает в предметную область на «входе»; • какие функции и в какой последовательности выполняются в рамках предметной области; • кто является ответственным за выполнение каждой из функций; • чем руководствуется исполнитель при выполнении каждой из функ- ций; • что является результатом работы объекта (на выходе)? На основе полученных результатов опросов создается черновик модели (Model Draft). 2. Распространение черновика для рассмотрения, получения комментари- ев и согласования модели с читателями. При этом каждая из диаграмм черновика письменно критикуется и комментируется, а затем передается автору. Автор, в свою очередь, также письменно соглашается с критикой или отвергает ее с изложением логики принятия решения и вновь воз- вращает откорректированный черновик для дальнейшего рассмотрения. Этот цикл продолжается до тех пор, пока авторы и читатели не придут к единому мнению. 3. Официальное утверждение модели. Утверждение согласованной моде- ли происходит руководителем рабочей группы в том случае, если у авто- ров модели и читателей отсутствуют разногласия по поводу ее адекват- ности. Окончательная модель представляет собой согласованное пред- ставление о системе с заданной точки зрения и для заданной цели. Метод SADT получил дальнейшее развитие. На его основе в 1981 году раз- работана известная методология функционального моделирования IDEF0. 170 Методология функционального моделирования IDEF0 Основные понятия IDEF0 IDEF0 (Integration Definition for Function Modeling) – методология функ- ционального моделирования для описания функций предприятия, предлагаю- щая язык функционального моделирования для анализа, разработки, реинжи- ниринга и интеграции информационных систем бизнес процессов; или анализа инженерии разработки ПО (or software engineering analysis). Модель IDEF0 – это графическое описание (информационной) системы или предметной области (subject), которое разрабатывается с определенной целью с выбранной точки зрения. Модель IDEF0 представляет собой набор из одной или более (иерархически связанных) IDEF0-диаграмм, которые опи- сывают функции системы или предметной области (subject area) с помощью графики, текста и глоссария. История IDEF0 Методология IDEF0 является развитием метода структурного анализа и проектирования SADT (Structured Analysis and Design Technique). IDEF0 как стандарт был разработан в 1981 году в рамках программы ICAM (Integrated Computer Aided Manufacturing – интегрированная компьютер- ная поддержка производства). IDEF0 – Integration DEFinition language 0 – основан на SADT и в своей исходной форме включает одновременно: 1) определение языка графического моделирования (синтаксис и семанти- ку); 2) описание полной (comprehensive) методологии разработки моделей. Последняя редакция IDEF0 была выпущена в декабре 1993 года Нацио- нальным Институтом по Стандартам и Технологиям США (NIST). 171 В 1993 году IDEF0 была принята в качестве федерального стандарта в США, а в 2000 году – в качестве стандарта в Российской Федерации. Применение IDEF0 IDEF 0 используется для создания функциональной модели, то есть резуль- татом применения методологии IDEF0 к системе есть функциональная модель IDEF0. Функциональная модель – это структурное представление функций, дея- тельности или процессов в пределах моделируемой системы или предметной области. Методология IDEF0 может быть использована для моделирования широ- кого спектра как автоматизированных, так и неавтоматизированных систем. Для проектируемых систем IDEF0 может быть использована сначала для определения требований и функций, и затем для реализации, удовлетворяющей этим требованиям и исполняющей эти функции. Для существующих систем IDEF0 может быть использована для анализа функций, выполняемых системой, а также для учета механизмов, с помощью которых эти функции выполняются. Цели стандарта IDEF0 Основные цели (objectives) стандарта: 1) задокументировать и разъяснить технику моделирования IDEF0 и прави- ла ее использования; 2) обеспечить средства для полного и единообразного (consistently) модели- рования функций системы или предметной области, а также данных и объектов, которые связывают эти функции; 3) обеспечить язык моделирования, который независим от CASE методов или средств, но может быть использован при помощи этих методов и средств; 172 4) обеспечить язык моделирования, который имеет следующие характери- стики: • общий (generic) – для анализа как (информационных) систем, так и предметных областей; • строгий и точный (rigorous and precise) – для создания корректных, пригодных к использованию моделей; • краткий (concise) – для облегчения понимания, коммуникации, согла- сия между заинтересованными лицами и проверки. (to facilitate under- standing, communication, consensus and validation); • абстрактный (conceptual) – для представления функциональных тре- бований, независимых от физических или организационных реализа- ций; • гибкий – для поддержки различных фаз жизненного цикла проекта. Строгость и точность (Rigor and Precision). Правила IDEF0 требуют до- статочной строгости и точности для удовлетворения нужд аналитика без чрезмерных ограничений (to satisfy needs without overly constraining the analyst). IDEF0 правила включают следующее: • управление детализацией (control of the details communicated at each level) – от трех до шести функциональных блоков на каждом уровне декомпо- зиции; • связанный контекст (Bounded Context) – не должно быть недостающийх или лишних, выходящих за установленные рамки деталей; • связанность интерфейса диаграмм (Diagram Interface Connectivity) – нали- чие номеров узлов, функциональных блоков, С-номеров (C-numbers) и подробных ссылочных выражений (Detail Reference Expression); • связанность структуры данных. (Data Structure Connectivity) – коды ICOM и использование круглых скобок (ICOM codes and the use of paren- theses); 173 • уникальные метки и заголовки (Unique Labels and Titles) – отсутствие по- вторяющихся названий в метках и заголовках; • синтаксические правила для графики (Syntax Rules for Graphics) – функ- циональные блоки и стрелки; • ограничения на разветвления стрелок данных (Data Arrow Branch Con- straint) – метки для ограничений потоков данных на разветвлениях; • разделение данных на Вход и Управление (Input versus Control Separation) – правило для определения роли данных); • маркировка стрелок данных. Data Arrow Label Requirements (minimum la- beling rules); • наличие Управления (Minimum Control of Function) – все функции долж- ны иметь минимум одно Управление; • цель и точка зрения (Purpose and Viewpoint) – все модели имеют форму- лировку цели и точки зрения. Ограничения сложности. Обычно IDEF0-модели несут в себе сложную и концентрированную информацию, и для того, чтобы ограничить их перегру- женность и сделать удобочитаемыми, в стандарте приняты соответствующие ограничения сложности, которые носят рекомендательный характер. При том, что, что на диаграмме рекомендуется представлять от трех до шести функцио- нальных блоков, количество подходящих к одному функциональному блоку (выходящих из одного функционального блока) интерфейсных дуг предполага- ется не более четырех. Основные понятия IDEF0 В основе методологии лежат четыре основных понятия: • функциональный блок; • интерфейсная дуга; 174 • декомпозиция; • глоссарий. Функциональный блок (Activity Box) представляет собой некоторую конкретную функцию в рамках рассматриваемой системы. По требованиям стандарта название каждого функционального блока должно быть сформулировано в глагольном наклонении (например, «произ- водить услуги»). На диаграмме функциональный блок изображается прямоугольником (рис.). Каждая из четырех сторон функционального блока имеет свое опреде- ленное значение (роль), при этом: • верхняя сторона имеет значение «Управление» (Control); • левая сторона имеет значение «Вход» (Input); • правая сторона имеет значение «Выход» (Output); • нижняя сторона имеет значение «Механизм» (Mechanism). Рис. 4.2. Функциональный блок |