DFD (Data Flow Diagrams) - диаграммы потоков данных, обеспечивающих анализ требований и функциональное проектирование информационных систем.
STD (State Transition Diagram) - диаграммы перехода состояний для проектирования систем реального времени.
Структурные карты Джексона и /или Константайна для проектирования межмодульных взаимодействий и внутренней структуры объектов.
FDD (Functional Decomposition Diagrams) - диаграммы функциональной декомпозиции.
SADT (Structured Analysis and Design Technique) - технология структурного анализа и проектирования семейство.
Методология IDEF0 основана на подходе, разработанном Дугласом Россом в начале 70-х годов и получившем название SADT (Structured Analysis & Design Technique, - метод структурного анализа и проектирования). Является также основой IDEF1X.
Семейство IDEF (ICAM - Integrated Computer Aided Manufacturing Definition):
IDEF0 (Integration Definition method for Function Modeling) - методологияфункциональногомоделирования, позволяющаяописатьпроцессввидеиерархическойсистемывзаимосвязанныхфункций
IDEF1 (Integration Definition method for Information Modeling) - применяется для построения информационной модели, которая представляет структуру информации, необходимой для поддержки функций производственной системы или среды.
IDEF1X (Integration Definition method for Semantic Data Modeling) - методология моделирования структуры информации, основанная на концепции «сущность-связь».
ERD (Entity-Relationship Diagrams) - диаграммы «сущность-связь».
IDEF2 (Integration Definition method for Simulation Modeling) - позволяет построить динамическую модель меняющегося во времени поведения функций, информации и ресурсов производственной системы или среды.
IDEF3 (Integration Definition method for Process Description Capture) - методологиядокументированиятехнологическихпроцессов. Методика потокового моделирования, а не структурного как IDEF0. WFD (Work Flow Diagram) - диаграмма потоков событий, инструмент графического представления функций системы, моделируемой в нотации IDEF3.
IDEF4 (Integration Definition method for Object-Oriented Design) - методология объектно-ориентированного проектирования сложных систем, описывающая структуру, поведение и реализацию систем в терминах класса объектов.
IDEF5 - методология, обеспечивающая наглядное представление данных обработки онтологических запросов. IDEF5 - методология онтологического анализа систем, т.е. анализа основных терминов и понятий (словаря), используемых для характеристики объектов и процессов, границ использования, взаимосвязей между ними.
CASE-системы (Computer-Aided Software/System Engineering): BPwin, Erwin
Инструментальные системы: MS Visio.
6.6. Методология структурного анализа и проектирования (SA/SD)
SA/SD (Structured Analysis/Structured Design) - эта методология основана на классической и весьма успешной методологии структурного проектирования программного обеспечения и информационных систем.
Методология SA/SD (Structured Analysis/Structured Design) содержит несколько вариантов систем обозначений для формальной спецификации программных систем. На этапе анализа требований и предварительного проектирования для логического описания проектируемой системы используются спецификации (формальные описания) процессов, словарь данных, диаграммы потоков данных, диаграммы состояний и диаграммы зависимостей объектов.
Диаграммы потоков данных (они подробно рассмотрены в п. 2.5.1), составляющие основу методологии SA/SD, моделируют преобразования данных при их прохождении через систему. Методология SA/SD состоит в последовательном рассмотрении процессов, входящих в состав ДПД, с представлением каждого процесса через ДПД, содержащую в своем составе более простые процессы. Эта процедура представления более сложных процессов через ДПД начинается с ДПД всей системы и заканчивается, когда все полученные ДПД содержат достаточно элементарные процессы. Для каждого процесса самого нижнего уровня составляется спецификация; спецификация описывается с помощью псевдокода, таблиц принятия решений и т.п.
Детали, не учтенные в наборе ДПД, содержатся в словаре данных, который определяет потоки и хранилища данных, а также семантику различных имен.
Набор диаграмм состояния процессов играет ту же роль, что и динамическая модель в методологии OMT.
Диаграммы зависимостей объектов отражают зависимости между хранилищами данных. Эти диаграммы аналогичны объектной модели методологии OMT.
Так в методологии SA/SD организован этап структурного анализа (SA). После структурного анализа начинается этап структурного конструирования (SD), в процессе которого разрабатываются и уточняются более тонкие детали проектируемой системы.
Таким образом, мы видим, что у методологий SA/SD и OMT много общего: обе методологии используют похожие конструкции для моделирования и поддерживают три взаимно-ортогональных представления проектируемой системы. Методологии SA/SD и OMT можно рассматривать как два способа использования инструментального средства - OMTTool.
Но в методологии SA/SD ведущей является функциональная модель (набор ДПД), на втором месте по важности стоит динамическая модель и на последнем месте - объектная модель. Таким образом, в методологии SA/SD проектируемая система описывается с помощью процедур (процессов), что несколько противоречит объектно-ориентированному подходу. Методология OMT гораздо ближе к нему: в ней моделирование концентрируется вокруг объектной модели, т.е. вокруг объектов, из которых строится проектируемая система.
Процедурная ориентированность методологии SA/SD является ее недостатком: системы, спроектированные по этой методологии, имеют менее четкую структуру, так как разбиение процесса на подпроцессы во многом произвольно, зависит от реализации и плохо отражает структуру проектируемой системы.
В то же время методология SA/SD является одним из первых хорошо продуманных формальных подходов к разработке программных систем.
Методология SADT
SADT (Structured Analysis and Disign Tecchnique) - технология структурного анализа и проектирования), основанная на концепции «сущность-связь» (entity-relationship). Представляет собой дальнейшее развитие методологии структурного анализа и проектирования.
Методология SADT разработана Дугласом Россом. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.
Методология SADT представляет собой совокупность методов, правил и процедур, предназначенных для построения функциональной модели объекта какой-либо предметной области. Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями. Основные элементы этой методологии основываются на следующих концепциях:
1. графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются;
2. строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают:
3. ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);
4. связность диаграмм (номера блоков);
5. уникальность меток и наименований (отсутствие повторяющихся имен);
6. синтаксические правила для графики (блоков и дуг);
7. разделение входов и управлений (правило определения роли данных).
8. отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель.
Методология SADT может использоваться для моделирования широкого круга систем и определения требований и функций, а затем для разработки системы, которая удовлетворяет этим требованиям и реализует эти функции. Для уже существующих систем SADT может быть использована для анализа функций, выполняемых системой, а также для указания механизмов, посредством которых они осуществляются.
Другие методологии
Методология JSD
Методология JSD (Jackson Structured Development) предлагает свой стиль разработки программных систем; он отличается от стиля, принятого в методологиях SA/SD или OMT. Методология JSD, разработанная Майклом Джексоном в середине 80-х годов, особенно популярна в Европе. В методологии JSD не делается различий между этапом анализа требований к системе и этапом ее разработки; оба этапа объединяются в один общий этап разработки спецификаций проектируемой системы. На этом этапе решается вопрос "что должно быть сделано"; вопрос "как это должно быть сделано" решается на следующем этапе - этапе реализации системы. Методология JSD часто применяется для проектирования систем реального времени.
Как и другие методологии, методология JSD использует систему графических обозначений, хотя эта методология и менее ориентирована на графику, чем методологии SA/SD и OMT.
Разработка модели JSD начинается с изучения объектов реального мира. Целью системы является обеспечение требуемой функциональности, но Джексон понимает, что сначала следует убедиться, что эта функциональность согласуется с реальным миром. Модель JSD описывает реальный мир в терминах сущностей (объектов), действий и порядка выполнения действий. Разработка системы по методологии JSD включает следующие шесть фаз:
1. разработка действий и объектов;
2. разработка структуры объектов;
3. разработка исходной модели;
4. разработка функций;
5. разработка временных ограничений;
6. реализация системы.
На фазе разработки действий и объектов разработчик, руководствуясь внешними требованиями к проектируемой системе, составляет перечень сущностей (объектов) и действий реального мира, связанных с этой системой. Так например, проектируя систему управления двумя лифтами в шестиэтажном доме, можно выделить два объекта "лифт" и "кнопка" и три действия - "нажатие кнопки", "лифт приходит на этаж n" и "лифт покидает этаж n". И объекты, и действия взяты из реального мира, а не искусственно введены в рассмотрение проектировщиком. Все действия являются атомарными (неразложимыми на поддействия) и происходят в фиксированные моменты времени.
На фазе разработки структуры объектов действия каждого объекта частично упорядочиваются во времени. Так, в рассматриваемом примере действия "лифт приходит на этаж n" и "лифт покидает этаж n" должны чередоваться: два действия "лифт приходит на этаж n" не могут идти одно за другим.
Фаза разработки исходной модели связывает реальный мир с абстрактной моделью, устанавливая соответствие между вектором состояния и потоком данных. Вектор состояния обеспечивает "развязку" по управлению; так в примере с лифтами первая же нажатая кнопка вверх установит значение переключателя (флажка) "вверх" после чего лифт не будет реагировать на дальнейшие нажатия кнопок вверх, так что нажатие кнопки вверх один или пять раз приведет к одинаковому результату. Аналогично, поток данных позволяет обеспечить "развязку" по данным: примером может служить буфер файла.
На фазе разработки функций с помощью специального псевдокода устанавливаются выходные данные каждого действия. Для системы управления лифтами примером функции является переключение лампочек на панели лифта при прибытии лифта на очередной этаж.
На фазе разработки временных ограничений решается вопрос о допустимых временных отклонениях системы от реального мира. В результате получается множество временных ограничений. В примере с лифтами одним из временных ограничений будет решение вопроса о том, как долго нужно нажимать на кнопку лифта, чтобы добиться его реакции.
Наконец, на фазе реализации системы решаются проблемы управления процессами и распределения процессов по процессорам.
Методология JSD может быть названа объектно-ориентированной с большой натяжкой: в ней почти не рассматривается структура объектов, мало внимания уделяется их атрибутам. Некоторые действия в смысле методологии JSD являются, по существу, зависимостями между объектами в смысле методологии OMT.
Тем не менее, методология JSD может успешно применяться для проектирования и реализации следующих типов прикладных программных систем:
1. Параллельные асинхронные программные системы, в которых процессы могут взаимно синхронизировать друг друга.
2. Программные системы реального времени; методология JSD ориентирована именно на такие системы.
3. Программные системы для параллельных компьютеров; парадигма, принятая в методологии JSD может здесь оказаться полезной.
Методология JSD плохо приспособлена для решения следующих проблем:
1. Высокоуровневый анализ: методология JSD не обеспечивает широкого понимания проблемы; она неэффективна для абстракции и упрощения проблем.
2. Разработка баз данных: это слишком сложная проблема для методологии JSD.
Методология OMT
Методология OMT (Object Modeling Technique), поддерживает две первые стадии разработки программных систем:
1. Анализ требований и предварительное проектирование системы.
2. Конструирование системы.
Эта методология опирается на программный продукт OMTTool, который позволяет разрабатывать модели проектируемой программной системы в интерактивном режиме с использованием многооконного графического редактора и интерпретатора наборов диаграмм, составляемых при анализе требований к системе и ее проектировании с использованием методологии OMT. Таким образом, как только получен достаточно полный набор диаграмм проектируемой программной системы, его можно проинтерпретировать и предварительно оценить различные свойства будущей реализации системы.
В настоящее время OMTTool входит в состав системы Paradigm+.
Методология OSA
Методология OSA (Object-Oriented System Analysis) обеспечивает объектно-ориентированный анализ программных систем и не содержит возможностей, связанных с поддержкой этапа разработки.
Методологии объектно-ориентированного анализа нередко критикуются за то, что они являются больше реализационно-ориентированными, чем проблемно-ориентированными, обеспечивая больше предварительную разработку, чем анализ требований к системе. Действительно, все рассмотренные методологии (такие, как OMT, SA/SD, JSD) поддерживают прежде всего предварительную разработку программных систем, а не анализ требований к ним.
ROOM (Real-Time Object-Oriented Modeling Language) - эта методология была разработана фирмой ObjecTime и предназначается для разработки систем реального времени. Используя эту методологию, системы представляются как сети взаимодействующих агентов, которые взаимодействуют при помощи обмена сообщениями через свои интерфейсы.
STD (State Transition Diagrams) - диаграммы переходов состояний - методология моделирования последующего функционирования системы на основе ее предыдущего и текущего функционирования.
ТQМ (Total Quality Management) - системное управление качеством - направление деятельности, изучающее бизнес-процесс с целью такой их организации, которая гарантирует идеальное качество продукции.
EPC (Event-driven Process Chain) - метод описания процессов, нашедший применение для описания процессов системы SAP R/3 [используется в ARIS].
Методы бизнес-анализа
ABB (Activity Based Budgeting) - планирование бюджета на основе выполняемых функций (операционное планирование бюджета): планирование бюджета компании или инвестиционного проекта с использованием принципов, средств и методов ABC. Фактически представляет собой обратное проектирование ABC-системы
ABC (Activity Based Costing) - функционально-стоимостной анализ: метод определения стоимости и других характеристик изделий и услуг на основе функций и ресурсов, задействованных в бизнес-процессах.
АВМ (Activity Based Management) - управление на основе ABC-информации (операционное управление): методология, описывающая средства и способы управления организацией для совершенствования бизнес-процессов и повышения прибыльности на основе информации, предоставляемой в результате ABC-анализа.
ARP (Activity Resource Planning) - функциональное планирование ресурсов: метод планирования ресурсов компании на основе анализа функций, задействованных в бизнес-процессах и данных ЛВС-анализа.
Benchmarking: методология определения эффективности производственной системы посредством выбора системы показателей, проведения измерений и сравнения с эталоном.
ВРI (Business Process Improvement) - непрерывное совершенствование (улучшение) бизнес-процессов: концепция плавного (пошагового) изменения организации бизнес-процессов в направлении достижения требуемых показателей эффективности и качества.
BPR (Business Process Redesign) - перепроектирование бизнес-процессов: концепция изменения организации деятельности компании на основе пересмотра отдельных бизнес-процессов.
BPR (Business Process Reengenering) - реорганизация бизнес-процессов: направление деятельности, включающее «фундаментальное переосмысление и радикальное перепланирование бизнес-процессов для достижения скачкообразных улучшений в решающих показателях деятельности компании, таких как затраты, качество выполнения и скорость».
СРI (Continuous Process Improvement) - непрерывное совершенствование процессов: один из подходов к совершенствованию качества бизнес-процессов.
CPN (Color Petri Nets) - раскрашенные сети Петри: методология создания динамической модели бизнес-процесса, позволяющая проанализировать зависящие от времени характеристики выполнения процесса и распределение ресурсов, для входящих потоков различной структуры.
