Структурная методология. Роль структурного подхода при проектировании ИС. - презентация

1 Структурная методология

2 Роль структурного подхода при проектировании ИС

3 На основе SADT разработан стандарт IDEF0 (Icam DEFinition), ICAM (Integrated Computer-Aided Manufacturing – Интеграция Компьютерных и Промышленных Технологий) Общие положения основой структурного подхода является методология SADT (Structured Analysis and Design Technique - "Технология структурного анализа и проектирования "). Дуглас Т. Росс Методология моделирования SADT (IDEF0) предназначена для анализа всей системы как множества взаимодействующих взаимосвязанных функций. Ориентация исключительно на анализ функций позволяет рассматривать функции независимо от объектов, которые их выполняют. Функциональный подход позволяет четко отделить проблемы анализа и проектирования от проблем реализации. Т.о., структурный подход является чрезвычайно удобным на этапе анализа и проектирования - поскольку аналитики имеют дело с бизнес- процессами, по сути, являющимися функциями или группами функций.

4 Что такое SADT (IDEF0)? SADT (IDEF0) - это методология функционального моделирования. Основу методологии составляет графический язык описания бизнес- процессов

5 Стандарты серии IDEF IDEF0 - Function Modeling - методология функционального моделирования сложных систем.; IDEF0 - Function Modeling - методология функционального моделирования сложных систем.; IDEF1 - Information Modeling - методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи; IDEF1 - Information Modeling - методология моделирования информационных потоков внутри системы, позволяющая отображать и анализировать их структуру и взаимосвязи; IDEF1X (IDEF1 Extended) - Data Modeling - методология проектирования реляционных баз данных. Заключается в построении моделей данных типа "сущность-связь" (ERD - Entity- Relationship Diagram) в нотации этого стандарта; IDEF1X (IDEF1 Extended) - Data Modeling - методология проектирования реляционных баз данных. Заключается в построении моделей данных типа "сущность-связь" (ERD - Entity- Relationship Diagram) в нотации этого стандарта; IDEF2 - Simulation Model Design - методология динамического моделирования систем. (CPN - Color Petri Nets); IDEF2 - Simulation Model Design - методология динамического моделирования систем. (CPN - Color Petri Nets); IDEF3 - Process Description Capture - методология документирования процессов, происходящих в системе, которая используется, например, при исследовании технологических процессов на предприятиях; IDEF3 - Process Description Capture - методология документирования процессов, происходящих в системе, которая используется, например, при исследовании технологических процессов на предприятиях; IDEF4 - Object-Oriented Design - методология построения объектно-ориентированных систем; IDEF4 - Object-Oriented Design - методология построения объектно-ориентированных систем; IDEF5 - Ontology Description Capture - методология онтологического исследования сложных систем; IDEF5 - Ontology Description Capture - методология онтологического исследования сложных систем; IDEF6 - Design Rationale Capture - методология использования рационального опыта проектирования; IDEF6 - Design Rationale Capture - методология использования рационального опыта проектирования; IDEF7 - Information System Auditing - методология аудита информационной системы; IDEF7 - Information System Auditing - методология аудита информационной системы; IDEF8 - User Interface Modeling - методология проектирования интерфейса пользователя; IDEF8 - User Interface Modeling - методология проектирования интерфейса пользователя; IDEF9 - Scenario-Driven IS Design - методология анализа имеющихся условий и ограничений, в том числе физических, юридических, политических, и их влияния на принимаемые решения в процессе реинжиниринга; IDEF9 - Scenario-Driven IS Design - методология анализа имеющихся условий и ограничений, в том числе физических, юридических, политических, и их влияния на принимаемые решения в процессе реинжиниринга; IDEF10 - Implementation Architecture Modeling - моделирование архитектуры выполнения; IDEF10 - Implementation Architecture Modeling - моделирование архитектуры выполнения; IDEF11 - Information Artifact Modeling - информационное моделирование артефактов; IDEF11 - Information Artifact Modeling - информационное моделирование артефактов; IDEF12 - Organization Modeling - организационное моделирование; IDEF12 - Organization Modeling - организационное моделирование; IDEF13 - Three Schema Mapping Design - трехсхемный дизайн карт; IDEF13 - Three Schema Mapping Design - трехсхемный дизайн карт; IDEF14 - Network Design - методология моделирования компьютерных сетей. IDEF14 - Network Design - методология моделирования компьютерных сетей.

6 Язык IDEF0 графический язык IDEF0 содержит только ДВА символа: блоки и дуги

7 Блок (функциональный блок; SA- блок) ОПР1.: В основе IDEF0 методологии лежит понятие блока, который отображает некоторую функцию. В соответствии с методологией IDEF0 любой процесс представляется в виде функционального блока, который преобразует входы в выходы при наличии необходимых ресурсов (механизмов) в управляемых условиях.

8 Блок (функциональный блок; SA- блок) ОПР2.: Функциональный блок (или Функция) преобразует Входы в Выходы. Управление определяет, когда и как это преобразование может или должно произойти. Механизмы непосредственно осуществляют это преобразование.

9 Блок (функциональный блок; SA- блок) ОПР.: В основе IDEF0 методологии лежит понятие блока, который отображает некоторую функцию. Четыре стороны блока имеют разную роль: левая сторона имеет значение входа, правая - выхода, верхняя - управления, нижняя - механизма функция вход (Input) выход (Output) Управление (Control) Механизм (Mechanism) Выход (Output) – это материалы, предметы, информация, производимые функцией, это результат выполнения функции. Каждый блок обязательно имеет хотя бы одну стрелку выхода. При моделировании непроизводственных процессов, выходом функции часто являются данные, которые были обработаны или переработаны по алгоритму, определяемому функцией. Вход (Input) - это материалы, предметы или информация, которые трансформируются в процессе выполнения функции с целью получения результата. Стрелки входа соединяются с левой стороной блока. Некоторые блоки могут не иметь стрелок входа, поскольку не каждая функция преобразует или изменяет что -либо. Управление (Control) определяет как, когда и в каком случае выполняется функция, и какой результат от нее ожидается. Каждая функция (IDEF0-блока) должна иметь как минимум один вход управления. Управление часто представляется в виде правил, норм, процедур, стандартов. Они оказывают влияние на выполнение функции, не изменяясь при этом сами. Управление – это особый тип входных данных функции. Часто даже возникает вопрос, какого типа должна быть стрелка: вход или управление.

10 Блок (функциональный блок; SA- блок) ОПР.: В основе IDEF0 методологии лежит понятие блока, который отображает некоторую функцию. Четыре стороны блока имеют разную роль: левая сторона имеет значение входа, правая - выхода, верхняя - управления, нижняя - механизма функция вход (Input) выход (Output) Управление (Control) Механизм (Mechanism) Механизм (Mechanism) – это те ресурсы, при помощи которых выполняется функция. В качестве механизма выступают люди, машины, оборудование, которые обеспечивают все необходимое для реализации функции. IDEF0-блок может не содержать стрелок механизма. Это объясняется тем, что знание механизма, осуществляющего функцию, зачастую не является целью моделирования системы.

11 Дуги Дуги ОПР.: Взаимодействие между функциями (блоками) в IDEF0 представляется в виде дуги, которая отображает поток данных или материалов, поступающий с выхода одной функции на вход другой. Выходы одной функции могут быть Входами, Управлением или Механизмами для другой. В зависимости от того, с какой стороной блока связан поток, его называют соответственно входным, выходным, управляющим.

12 Дуги Дуги С дугами связаны надписи (или метки) на естественном языке, описывающие данные, которые они представляют. С дугами связаны надписи (или метки) на естественном языке, описывающие данные, которые они представляют. Дуги могут разветвляться и соединяться. Дуги могут разветвляться и соединяться.

13 варианты взаимодействия функциональных блоков выход - вход выход - управление выход - механизм с обратной связью найти книгу выдать книгу запрос запрошенная книга ББК инструкции библиотекарь выданная книга отметка о выдаче выбратьязыкпрогр. создание программы постановка задачи язык прогр- ия технология программирования программист данные о ПО решение задачи написать программу произвести вычисления программа программист данные для расчета постановка задачи ПК инструкция ОС выход - управление ОС выход - вход построить модель «ToBe» рецензировать модель ToBe на рецензию аналитик модель «AsIs» комментарии по модели эксперт методология

14 Модель в IDEF0

15 Общие положения Модель в IDEF0 представляет собой совокупность иерархически упорядоченных и взаимосвязанных диаграмм ( каждая диаграмма располагается на отдельном листе ).

16 функция вход (Input) выход (Output) Управление (Control) Механизм (Mechanism) д 1 д 1 д 2 д 2 д 3 д 3 д 4 д 4 д 1 д 1 д 2 д 2 д 3 д 3 д 4 д 4

17 Принципы IDEF0 моделирования (1) Функциональный блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных между собой дугами. Функциональный блок, который представляет систему в качестве единого модуля, детализируется на другой диаграмме с помощью нескольких блоков, соединенных между собой дугами. Эти блоки представляют основные подфункции (подмодули) единого исходного модуля. Эти блоки представляют основные подфункции (подмодули) единого исходного модуля. Данная декомпозиция выявляет полный набор подмодулей, каждый из которых представлен как блок, границы которого определены дугами. Данная декомпозиция выявляет полный набор подмодулей, каждый из которых представлен как блок, границы которого определены дугами. Каждый из этих подмодулей может быть декомпозирован подобным же образом для более детального представления. Каждый из этих подмодулей может быть декомпозирован подобным же образом для более детального представления. Принцип функциональной декомпозиции (разделяй и властвуй)

18 Принципы IDEF0 моделирования (2) При работе с IDEF0 диаграммами существенным является условие их разборчивости и удобочитаемости количество блоков на диаграмме должно быть не менее двух и не более шести. Практика показывает, что соблюдение этого принципа приводит к тому, что функциональные процессы, представленные в виде IDEF0 модели, хорошо структурированы, понятны и легко поддаются анализу. Принцип ограничения сложности

19 Принципы IDEF0 моделирования (3) Модель должна отвечать на вопросы о системе («М есть модель системы S, если М может быть использована для получения ответов на вопросы относительно S с точностью А») Цель моделирования (Purpose) Точка зрения (Viewpoint) Границы моделирования (Scope). Принцип контекста (целеполагания)

20 Принципы IDEF0 моделирования: Принцип функциональной декомпозиции Принцип функциональной декомпозиции Принцип ограничения сложности Принцип ограничения сложности Принцип контекста Принцип контекста

21 12 ПРАВИЛ ПОСТРОЕНИЯ IDEF0 ДИАГРАММ

22 Общие правила

23 Правило контекста. В составе модели должна присутствовать контекстная диаграмма number prefix-0 (например, А-0), которая содержит только один блок. Номер единственного блока на контекстной диаграмме А-0 должен быть 0 Правила построения диаграмм number prefix номер блока Принципы IDEF0 моделирования: Принцип функциональной декомпозиции Принцип функциональной декомпозиции Принцип ограничения сложности Принцип ограничения сложности Принцип контекста Принцип контекста

24 Правило «доминирования». Блоки на диаграмме должны располагаться по диагонали - от левого верхнего угла диаграммы до правого нижнего в порядке присвоенных номеров. Блоки на диаграмме, расположенные вверху слева «доминируют» над блоками, расположенными внизу справа. «Доминирование» понимается как влияние, которое блок оказывает на другие блоки диаграммы. Правила построения диаграмм

25 4. Правило ограничения сложности. Неконтекстные диаграммы должны содержать не более шести блоков. Это ограничение поддерживают сложность диаграмм на уровне, доступном для чтения, понимания и использования. Диаграммы с количеством блоков более шести сложны для восприятия читателями и вызывают у автора трудности при внесении в нее всех необходимых графических объектов и меток Принципы IDEF0 моделирования: Принцип функциональной декомпозиции Принцип функциональной декомпозиции Принцип ограничения сложности Принцип ограничения сложности Принцип контекста Принцип контекста Правила построения диаграмм

26 Правило выбора управления. Если одни и те же данные служат и для управления, и для входа, вычерчивается только стрелка управления. Этим подчеркивается управляющий характер данных и уменьшается сложность диаграммы Правила построения диаграмм Ф1 Ф2 ошибка Ф1 Ф2

27 Правила нумерации и именования диаграмм, блоков и дуг

28 Правило нумерации блоков. Каждый блок диаграммы декомпозиции получает номер, помещаемый в правом нижнем углу; порядок нумерации - от верхнего левого к нижнему правому блоку (в соответствии с доминированием блоков) Правила построения диаграмм номера блоков

29 4. Правило нумерации диаграмм. Каждая диаграмма имеет свой уникальный код, который формируется следующим образом: NP N.M … где: NP – number prefix (например TD); N – номер блока на диаграмме NP0; M – номер блока на диаграмме NP N. Правила построения диаграмм А-0 0 А А А Примечание: Каждый блок, подвергнутый декомпозиции, должен иметь отметку об этом

30 Правило именования. Имена блоков (выполняемых функций) и метки стрелок должны быть уникальными. Если метки стрелок совпадают, это значит, что стрелки отображают тождественные данные Правила построения диаграмм имена блоков метки стрелок Имя функции данныеданныеОШИБКА данные обработанные данные Функция ФункцияОШИБКА Ф1 Ф2

31 Правила компоновки объектов диаграмм

32 Правило компоновки блоков. Следует обеспечить максимальное расстояние между блоками и поворотами стрелок, а также между блоками и пересечениями стрелок для облегчения чтения диаграммы. Одновременно уменьшается вероятность перепутать две разные стрелки Правила построения диаграмм

33 Правило рисования стрелок. Надо пытаться максимально увеличивать расстояние между параллельными стрелками, что облегчает размещение меток, их чтение и позволяет проследить пути стрелок Правила построения диаграмм Ф1 Ф2 Ф3 Ф1 Ф2 Ф3 более предпочтительно менее предпочтительно

34 Правило минимизации пересечений. При соединении большого числа блоков необходимо избегать необязательных пересечений стрелок. Следует минимизировать число петель и поворотов каждой стрелки Правила построения диаграмм Ф1 Ф2 Ф3 Ф1 Ф2 Ф3 Ф1 Ф2 Ф3 Ф1 Ф2 Ф3 более предпочтительно менее предпочтительно более предпочтительно менее предпочтительно

35 Правило связывания стрелок. Стрелки связываются (сливаются), если они представляют сходные данные и их источник не указан на диаграмме Стрелки объединяются, если они имеют общий источник или приемник, или они представляют связанные данные. Общее название лучше описывает суть данных. Следует минимизировать число стрелок, касающихся каждой стороны блока, если, конечно, природа данных не слишком разнородна Правила построения диаграмм Ф1 Ф2 Ф1 Ф2 Ф1 Ф2 Ф3 Ф1 Ф2 Ф3 более предпочтительно менее предпочтительно более предпочтительно менее предпочтительно

36 Правило присоединения стрелок к блокам. Если возможно, стрелки присоединяются к блокам в одной и той же позиции. Тогда соединение стрелок конкретного типа с блоками будет согласованным и чтение диаграммы упростится Правила построения диаграмм Ф1 Ф2 Ф3 Ф1 Ф2 Ф3 более предпочтительно менее предпочтительно

37 Стандарт создания SADT-модели (РД IDEF ) Управление: В соответствии с чем? Выход: Какой результат? Функциональный блок: Что делать? Механизм: Кто? Как? Вход: Из чего? ВОПРОС: Как выглядит контекстная диаграмма?

38 Стандарт создания SADT-модели (РД IDEF ) ВОПРОС: Сколько этапов? Какие этапы?

39 Выводы Выводы Общая схема предпроектного обследования включает в себя следующие этапы: Интервьюирование должностных лиц предприятия Заказчика, причастных к проекту. Интервьюирование должностных лиц предприятия Заказчика, причастных к проекту. Заполнение составленных аналитиками опросных листов лицами, причастными к проекту. Заполнение составленных аналитиками опросных листов лицами, причастными к проекту. Подбор и изучение образцов форм используемых первичных и отчетных документов, образующих документооборот предприятия Заказчика. Подбор и изучение образцов форм используемых первичных и отчетных документов, образующих документооборот предприятия Заказчика. Сбор данных о существующей (модернизируемой) системе - печатные формы, формы ввода, инструкции и т.п. Сбор данных о существующей (модернизируемой) системе - печатные формы, формы ввода, инструкции и т.п. Изучение материалов внешних исследований, изложенных в отчетах, публикациях, монографиях и т.п. Изучение материалов внешних исследований, изложенных в отчетах, публикациях, монографиях и т.п. Обследование инфраструктуры Заказчика (рабочие станции, серверы, сети). Обследование инфраструктуры Заказчика (рабочие станции, серверы, сети).

40 Выводы Выводы Основным результатом предпроектного обследования является комплекс материалов обследования, содержащий: схемы и описания организационной структуры; схемы и описания организационной структуры; развернутое описание основных принципов взаимодействия между субъектами; развернутое описание основных принципов взаимодействия между субъектами; схемы и описание бизнес-процессов; схемы и описание бизнес-процессов; реестр документов и отчетных форм; реестр документов и отчетных форм; описание топологии корпоративной сети и конфигурации оборудования; описание топологии корпоративной сети и конфигурации оборудования; оценку уровня подготовки персонала, формулирование необходимого обучения пользователей; оценку уровня подготовки персонала, формулирование необходимого обучения пользователей; смету предлагаемого проекта автоматизации с описанием работ, планируемых к проведению в рамках разработки системного проекта. смету предлагаемого проекта автоматизации с описанием работ, планируемых к проведению в рамках разработки системного проекта.