Раздел 6. Концептуальные основы методологии структурного анализа и проектирования SADT

Предыдущий раздел	Разделы	Следующий раздел
	Раздел 1. Современное понимание процессного управления Раздел 2. Бизнес-моделирование в разработке программ и в описании деятельности предприятия Раздел 3. Введение в теорию систем Раздел 4. Принципы системного подхода как базис моделирования открытых систем Раздел 5. Моделирование как главный метод системного обследования Раздел 6. Концептуальные основы методологии структурного анализа и проектирования SADT Раздел 7. Задания и вопросы для самостоятельной работы Раздел 8. Темы рефератов Раздел 9. Вопросы к экзамену

 

Структурный анализ является методологической разновидностью системного анализа [11]. Концептуально в основе структурного анализа лежит выявление структуры в системе – как относительно устойчивой совокупности отношений, признания методологического примата отношений над элементами в системе.

Вспомним знаменитую фразу «Глокая куздра штеко будланула бокра и курдячит бокрёнка». Каждый ее элемент непонятен, но смысл фразы достаточно ясен – некое одушевленное существо женского рода (причем весьма неприятное) сделало какой-то агрессивный выпад (действие быстрое, сильное) в отношении существа мужского рода и в настоящий момент делает что-то нехорошее-длительное с детенышем существа мужского рода. Причем мы имеем все основания предположить, что бокр без сознания или физически не может защитить своего ребенка. Перед нами забавный и поучительный пример того, что связи в системе могут быть важнее (в определенном отношении), чем ее элементы. Синтаксис, семантика и прагматика языка, по правилам которых составлено предложение, задают структуру (связи его элементов), а также позволяют придать смысл всему предложению.

Структурным анализом называется метод исследования системы (сопровождаемый построением серии моделей), который начинается с ее общего обзора и затем детализируется, приобретая нисходящую иерархическую структуру с все большим числом уровней *. Для таких методов характерно:

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

Цель структурного анализа заключается в преобразовании общих, расплывчатых знаний о предметной области в точные модели, описывающие различные аспекты рассмотрения моделируемого объекта или явления.
Все методологии структурного анализа базируются на ряде общих принципов, составляющих основы инженерии программного обеспечения. Многие из этих принципов являются базовыми правилами моделирования и в других областях знания.

Первым является принцип «разделяй и властвуй» – трудная проблема разбивается на множество меньших, независимых задач (частей), легких для понимания и решения. Части – это те самые черные ящики, о которых говорилось выше. Пользователю неважно знать, КАК работает черный ящик. Важно знать, ЧТО он делает, его функцию.

Вторым является принцип иерархического упорядочивания. Он декларирует, что внутреннее устройство частей также существенно для понимания и построения системы. Спускаясь по уровням иерархии, следует все более подробно описывать систему. Сколько должно быть таких уровней? Это определяется точкой зрения модели и теми вопросами, на которые должна ответить модель. Ведь в когнитивном аспекте любая модель является инструментом ответа на вопросы – и для научных исследований, и для конструирования чего-либо. Сами вопросы, если они корректно и грамотно заданы, определяют те понятия и степень подробности, в которых должна быть представлена моделируемая система.

В инженерии программного обеспечения не менее важны следующие принципы, которые определяют методологии моделирования и проектирования систем как в структурном, так и в объектно-ориентированном подходе

• Принцип абстрагирования заключается в выделении существенных с некоторых позиций аспектов системы и отвлечении от несущественных с целью представления проблемы в простом общем виде.
• Принцип формализации заключается в необходимости строгого методического подхода к решению проблемы.
• Принцип упрятывания заключается в утаивании несущественной на конкретном этапе информации, каждая часть «знает» только необходимую ей информацию.
• Принцип концептуальной целостности заключается в единообразном (даже унифицированном) представлении объекта моделирования, подчиненном общей идее. Как верно отмечает Дж. Фокс [14], концептуальную целостность лучше пояснять «от противного» – на отрицательных примерах, когда эта целостность нарушается.
• Принцип полноты заключается в контроле на присутствие лишних элементов.
• Принцип непротиворечивости заключается в обоснованности и согласованности элементов.
• Принцип логической независимости заключается в том, что в описании системы на уровне логики (строения, поведения) не должны использоваться и приниматься в расчет понятия/элементы, которые будут реализовывать эту логику на уровне физического проектирования – независимость логической модели от модели, реализующей логику.
• Принцип независимости данных – модели данных должны быть проанализированы и спроектированы независимо от процессов их логической обработки, а также от их физической структуры и распределения.
• Принцип структурирования данных – данные должны быть структурированы и иерархически организованы.
• Принцип доступа конечного пользователя – пользователь должен иметь средства доступа к данным (к БД), которые он может использовать непосредственно, без программирования.

Важнейшей характеристикой структурной методологии является порядок построения модели. Есть функционально-ориентированные и информационно-ориентированные методологии.
Методология SADT (Structured Analysis and Design Technique) – одна из самых известных методологий анализа и проектирования систем, введенная в 1973 г. Д. Россом (D. Ross). Она успешно использовалась в военных и коммерческих организациях для решения широкого круга задач, таких как программное обеспечение телефонных сетей, системная поддержка и диагностика, долгосрочное и стратегическое планирование, автоматизированное производство и проектирование, конфигурация компьютерных систем, управление финансами и материально-техническим снабжением и др. Данная методология широко поддерживается министерством обороны США, которое было инициатором разработки стандарта IDEF0 как подмножества SADT.

С точки зрения SADT модель может основываться либо на функциях системы, либо на ее предметах (планах, данных, оборудования, информации и т. д.). Традиционный функционально-ориентированный подход регламентирует первичность проектирования функциональных компонентов по отношению к проектированию структур данных – требования к данным раскрываются через функциональные требования. При информационно-ориентированном подходе вход и выход являются наиболее важными – структуры данных определяются первыми, а процедурные компоненты являются производными от данных.

При моделировании бизнеса, производства, управления производством исторически использовался функциональный подход. Во времена первых АСУ (автоматизированных систем управления) объектно-ориентированный подход еще не появился. В наши дни предпочтительное использование функционального моделирования задач предприятия связано с тем, что современное предприятие рассматривается в процессной парадигме как совокупность взаимодействующих бизнес-процессов и бизнес-правил.

Неспециалисты в программировании – руководители производства, технологи, плановики и пр. – интуитивно лучше понимают процессные (функциональные) модели предприятия, поскольку руководство воспринимает деятельность предприятия в понятиях технологий, должностных инструкций и бизнес-процессов. Информационная модель предприятия, как правило, содержит несколько сотен объектов, а функциональная иерархическая модель может содержать десятки тысяч объектов. Подтверждением первичности функциональной модели является тот факт, что на Западе, где различные методики реорганизации применяются уже дли-тельное время, большинство методологий являются функционально-ориентированными.

В методологии SADT система описывается в трех измерениях.

• Уровень детализации. Описывает структуру системы в виде иерархии элементов с определением целей системы и точки зрения (аспекта, ракурса) ее рассмотрения для задач моделирования. Это может быть деление большой задачи на подзадачи, большой системы на подсистемы, большого процесса на подпроцессы. Это может быть организационная структура предприятия – иерархия его подразделений. Важно, что структура задает связи, не зависящие от времени, – статические связи между элементами. Они определяют относительную устойчивость системы, поскольку в процессе функционирования структура может меняться.
Отвечает на вопросы – из чего состоит система с данной точки зрения и какая у нее цель.

• Уровень функционирования. Описывает логику поведения системы. Для человеко-машинных систем, определяющих работу предприятия, для бизнес-моделирования, при описании функций используется четыре вида отношений:
1) вхождение – описывает отношение между функциями (один к одному, один ко многим, многие ко многим);
2) предметное отношение описывает связи по передаче материалов, энергии, информации, финансов и пр. между функциями. Обобщенно это можно назвать описание материальных потоков между элементами системы;
3) причинное отношение описывает причинно-следственные связи между функциями, логику их связей во времени. Обобщенно это можно назвать описание потоков управления между элементами системы;
4) приоритетное отношение – описывает приоритеты между функциями при распределении ресурсов, требуемых для исполнения функции.

Подчеркнем, что этот уровень описывает только логику функционирования – что должна делать система без привязки к реализации этой логики.
Отвечает на вопрос – ЧТО должна делать система, какие действия/функции должна выполнять.

• Технологический, или технический уровень. Описывает эрготехнические средства, обеспечивающие практическую реализацию функций, логики поведения системы, описанной на втором уровне. К типам эрготехнических средств относятся:
1) аппаратное обеспечение – станки, оборудование, приборы, вычислительные машины и сети и пр.;
2) программное обеспечение – программы и программные комплексы, специализированные информационные системы управления предприятием;
3) руководящие документы – инструкции, стандарты, нормативы, приказы руководителей, технологии и пр.;
4) персонал – все работники/сотрудники, действующие в соответствии с руководящими документами.

Отвечает на вопрос – КАК, какими средствами и силами будет практически осуществляться функционирование системы.
Воплощение идей структурного анализа реализуется в конкретных технологиях и инструментах – IDEF0, DFD, IDEF3, Erwin, BPwin.

Раздел 7. Задания и вопросы для самостоятельной работы

Предыдущий раздел	Разделы	Следующий раздел
	Раздел 1. Современное понимание процессного управления Раздел 2. Бизнес-моделирование в разработке программ и в описании деятельности предприятия Раздел 3. Введение в теорию систем Раздел 4. Принципы системного подхода как базис моделирования открытых систем Раздел 5. Моделирование как главный метод системного обследования Раздел 6. Концептуальные основы методологии структурного анализа и проектирования SADT Раздел 7. Задания и вопросы для самостоятельной работы Раздел 8. Темы рефератов Раздел 9. Вопросы к экзамену

 

1. Специфика программного изделия как объекта труда. Восемь признаков сложности.
2. Кривая Лемана – причины экспоненциального роста сложности программы при эксплуатации, меры борьбы с ростом сложности.
3. Девять главных проблем организации процесса разработки программ. Подходы к их решению. Три источника этих проблем по Кауфману.
4. Условия применимости различных моделей ЖЦПО (водопад, каскадная, итерационная, спиральная). Достоинства и недостатки каждого вида моделей.
5. Типы требований к программной системе. Примеры спецификации требований.
6. Моделирование архитектуры программной системы. Метод Дейкстры.
7. Правила предотвращения ошибок при внешней спецификации программы.
8. Методология структурного анализа SADT. Три измерения и этапность моделирования системы.
9. Методология модульного программирования. Какие проблемы разработки программ она решает. Ее связи со структурным программированием и ООП.
10. Методология структурного программирования, какие характеристики ПО и как она улучшает, ее связи с ООП.
11. Три подхода к доказательному программированию. Связи этих подходов.
12. Достоинства и недостатки языка UML для моделирования бизнес-процессов.
13. Характеристики качества программ. Их приоритеты для различных типов программ.
14. Характеристики качества процесса разработки программ. Модели ISO, TQM, CMM, SPICE.
15. Статические методы контроля программ. Инспекции, статические анализаторы, сквозной контроль.
16. Инкрементная разработка в технологии стерильного цеха. Концепция и метод структурных ящиков.
17. Способы обеспечения надежности и отказоустойчивости программы. Статистическое тестирование, модель возрастающей надежности.
18. Сравнительный анализ возможностей применения методологий XP, RAD, RUP.
19. Проблемы применения CASE-систем. Выбор состава и функций интегрированной среды разработки.
20. Метод бригады главного программиста, какие проблемы он решает, условия применимости в малых и крупных проектах.
21. Управление рисками, типовые риски SEI. Оценка возможностей типовых методологий по управлению рисками.
22. Задачи и методы конфигурационного контроля в периоды разработки программы и ее эксплуатации.
23. Спецификация содержания и функций информационной системы для построения внутренних моделей стоимости. Методика модели СОСОМО.

Вопросы к экзамену

1. Причины экспоненциального роста сложности программы при эксплуатации, меры борьбы с ростом сложности.

2. Девять главных проблем организации процесса разработки программ. Подходы к их решению. Три источника этих проблем по Кауфману.

3. Условия применимости различных моделей ЖЦПО (водопад, каскадная, итерационная, спиральная). Достоинства и недостатки каждого вида моделей.

4. Типы и примеры требований к программной системе.

5. Моделирование архитектуры программной системы. Метод Дейкстры.

6. Методология структурного анализа SADT. Три измерения и этапность моделирования системы.

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

8. Методология структурного программирования, какие характеристики ПО и как она улучшает, ее связи с ООП.

9. Три подхода к доказательному программированию. Связи этих подходов.

10. Использование языка UML для моделирования бизнес-процессов. Достоинства и недостатки языка UML

11. Характеристики качества программ. Их приоритеты для различных типов программ.

12. Характеристики качества процесса разработки программ. Модели ISO, TQM, CMM, SPICE.

13. Статические методы контроля программ. Инспекции, статические анализаторы, сквозной контроль.

14. Инкрементная разработка в технологии стерильного цеха. Концепция и метод структурных ящиков.

15. Способы обеспечения надежности и отказоустойчивости программы. Статистическое тестирование, модель возрастающей надежности.

16. Сравнительный анализ возможностей применения методологий XP, RAD, RUP.

17. Проблемы применения CASE-систем. Выбор состава и функций интегрированной среды разработки.

18. Метод бригады главного программиста. Какие проблемы он решает, условия применимости в малых и крупных проектах.

19. Задачи и методы конфигурационного контроля в периоды разработки программы и ее эксплуатации.

20. Cпецифика программного изделия как объекта труда. Восемь признаков сложности.