- •А.1. Стратегический анализ бизнес-процессов
- •А.1.1. Моделирование стратегических бизнес-процессов
- •А.1.2.Promet
- •А.1.3. Другие методы стратегического моделирования бизнес-процессов
- •А.2. Моделирование на разных уровнях представленияAris а.2.1. Моделирование на уровне функционального представления
- •А.2.1.1. Определение требований на уровне функциональной модели
- •А.2.1.1.1. Структура функций
- •А.2.1.1.2. Последовательности процедур
- •А.2.1.1.3. Типы обработки
- •А.2.1.1.4. Модели решений
- •A.2.1.1.5. Объединение определения требований на уровне функциональной модели
- •А.2.1.2. Конфигурирование функций
- •А.2.1.3. Определение требований на уровне функциональной модели
- •А.2.1.3.1. Проектирование модулей
- •А.2.1.3.2. Мини-спецификация
- •А.2.1.3.3. Представление выхода
- •А.2.1.4. Реализация на уровне функциональной модели
- •А.2.2. Моделирование представления организации
- •А.2.2.1. Определение требований на уровне организационной модели
- •А.2.2.1.1. Организационные структуры (иерархические организации)
- •А.2.2.1.2. Ролевая концепция
- •А.2.2.2. Конфигурирование организационной структуры
- •А.2.2.3.Спецификация проекта на уровне организационной модели
- •А.2.2.3.1. Топология сети
- •А.2.2.3.2. Типы компонентов
- •А.2.2.4. Реализация на уровне организационной модели
- •А.2.3. Моделирование на уровне представления данных
- •А.2.3.1. Определение требований на уровне модели данных
- •А.2.3.1.1. Макроописание
- •А.2.3.1.2. Микроописания
- •А.2.3.2. Конфигурирование данных
- •А.2.3.3. Спецификация проекта в рамках модели данных
- •А.2.3.3.1. Создание отношений
- •А.2.3.3.2. Нормализация — денормализация
- •А.2.3.3.3. Условия целостности
- •А.2.3.3.4. Логические пути доступа
- •А.2.3.3.5. Схема базы данных
- •А.2.3.4. Реализация на уровне модели данных
- •А.2.4. Моделирование на уровне выходов
- •А.2.4.1. Определение требований на уровне модели выходов
- •А.2.4.2. Конфигурирование выходов
- •А.З. Моделирование отношений между разными типами представлений (модель управления)
- •А. 3.1. Отношения между функциями и организацией
- •А.З.1.1. Моделирование определения требований а.З.1.1.1. Диаграммы связи функция-организация
- •А.3.1.1.2. Диаграмма взаимодействия
- •А.3.1.2. Конфигурирование
- •А.3.1.3. Спецификация проекта
- •А.3.2. Отношения между функциями и данными
- •А.3.2.1. Моделирование определения требований а.3.2.1.1. Установление связей между функциями и данными а.3.2.1.1.1. Объектно-ориентированные диаграммы классов
- •А.3.2.1.1.2. Диаграммы привязки функций
- •А.3.2.1.1.3. Поток данных
- •А.3.2.1.1.4. Ассоциация экранов
- •А.3.2.1.2. Управление посредством событий и сообщений
- •А.3.2.1.2.1. Правило суд
- •A.3.2.1.2.2. Событийные диаграммы процессов (сдп)
- •А.3.2.1.2.3. Диаграммы состояний
- •А.3.2.1.2.4. Управление посредством сообщений
- •А.3.2.1.2.5. Связывание объектно-ориентированного моделирования и сдп
- •А.3.2.2. Конфигурирование
- •А.3.2.3. Спецификация проекта а.3.2.3.1. Связывание модулей с базами данных
- •А.3.2.3.1.1. Привязка схемы
- •А.3.2.3.1.2. Выведение структур управления
- •А.3.2.3.1.3. Транзакции баз данных
- •А.3.2.3.2. Управление посредством триггеров
- •А.3.2.3.3. Объектно-ориентированная спецификация проекта
- •А.3.2.3.3.1. Общая детализация
- •А.3.2.3.3.2. Связи с базами данных
- •А.3.2.4. Описание реализации
- •Void cirle::radius (int newradius)
- •А.3.3. Отношения между функциями и выходом
- •А.3.3.1. Моделирование на уровне определения требований
- •А.3.4. Отношения между организационной структурой и данными
- •А.3.4.1. Моделирование определения требований
- •А.3.4.2. Конфигурирование
- •А.3.4.3. Спецификация проекта а.3.4.3.1. Детализация полномочий
- •А.3.4.3.2. Распределенные базы данных
- •А.3.5. Отношения между организационной структурой и выходом
- •А.3.5.1. Моделирование определения требований
- •А.2.5.2. Конфигурирование
- •А.3.6. Отношения между данными и выходом
- •А.3.6.1. Моделирование определения требований
- •А.3.6.2. Конфигурирование
- •А.3.7. Объединение всех представленийAriSв полную модель
- •А.3.7.1. Моделирование определения требований
- •А.3.7.1.1. Модели процессов
- •А.3.7.1.2. Бизнес-объекты
- •А.3.7.2. Конфигурирование
- •А.3.7.2.1. Конфигурирование на базе моделей бизнес-процессов
- •А.3.7.2.2. Конфигурирование бизнес-объектов
- •А.3.7.3. Спецификация проекта
- •Б. Процедурные модели и приложенияAris
- •Б.1. Реализация стандартного программного обеспечения с помощью моделейAris
- •Б.1.1. Разрешение критических вопросов при управлении стандартным проектом
- •Б.1.2. Aris Quickstep for r/3
- •Б. 1.3.QuickstepforR/3: описание фаз реализацииSap
- •Б.1.4. Резюме
- •Б.2. Реализация системworkflowс помощью моделейAris
- •Б.2.1. Факторы успеха при реализации системworkflow
- •Б.2.2. Процедурная модельAriSдля реализацииworkflow
- •Б.З. Разработка систем на базе модели с использованием инфраструктурыArisFramework
- •Б.3.1. Общая процедурная модель
- •Б.3.2. Процедурная модель для моделирования целевых концепций
- •Б.4. Объектно-ориентированная разработка систем с помощью унифицированного языка моделирования (uml)
- •Б.4.1. Разработка и описание процедурных моделей
- •Б.4.2. Фазы процедурной модели
- •Б.4.3. Перспективы
Б.4. Объектно-ориентированная разработка систем с помощью унифицированного языка моделирования (uml)
Д-р Маркус Нюттгенс (Markus Nuttgens)', Майкл Хоффманн (Michael Hoffmann), дипл. Hdl.; Томас Фельд (Thomas Feld), дипл. по информатике; Институт информационных систем (IWi), Университет Саарланда, Германия.
Применительно к объектно-ориентированной разработке приложений в специальной литературе рассматривались преимущественно эволюционные процедурные модели (Boehm. Spiral Model. 1988; Henderson-Sellers, Edwards. Object Oriented System Life Cycle. 1990, c. 152; Meyer. Object Oriented Design. 1989). В основе такой разработки лежат теоремы объектно-ориентированной парадигмы, где объекты представляют отдельные подсистемы «закрытой системы». В соответствии с определением внутренних и внешних объектных структур, можно разрабатывать масштабируемые системы. В эволюционной процедуре каждый цикл завершается созданием исполняемой программы. Это достигается за счет того, что результаты разработки вытекают непосредственно из целей проекта. Эти результаты можно реализовать и поодиночке, что позволяет заранее развернуть и протестировать каждую подсистему. Дополнительная разработка включает внесение усовершенствований на основе тестирования в реальных условиях и внедрение дополнительных подсистем. Это дает возможность представить результаты уже на ранней стадии и избежать «тупиков» в ходе разработки.
Б.4.1. Разработка и описание процедурных моделей
Рассмотрим процедурную модель объектно-ориентированной разработки приложений, используя в качестве примера унифицированный язык моделирования (UML) (UML Notation Guide. 1997). До сегодняшнего дня не существовало ни одного явного описания процедурной модели на языке UML. На рис. 176 представлена предварительная процедурная модель, описывающая возможную процедуру для объектно-ориентированной разработки приложений.

Рис. 176. Предварительная процедурная модель для объектно-ориентированной разработки приложений
Объектно-ориентированная разработка приложений обычно базируется на оптимизированной модели бизнес-процессов (Oestereich. Objektorientierte Softwareentwicklung. 1997, с. 85; Yourdon et al. Mainstream Objects. 1996, c. 71).
Подпроцессы объектно-ориентированной разработки приложений (анализ, проектирование и сборка) описывают цикл, содержащий обратные связи с каждым элементом процедурной модели. После утверждения проекта объектно-ориентированной разработки приложения выполняется анализ и проектирование приложения объектно-ориентированным методом. Если на стадии объектно-ориентированного проектирования возникают какие-либо противоречия или вопросы, которые не могут быть разрешены на этом этапе, то приложение возвращается на стадию объектно-ориентированного анализа.
После того как результаты проектирования выданы, они становятся входным элементом для объектно-ориентированной сборки. Проектные модели реализуются более или менее автоматически с помощью генераторов кода. При выявлении ошибок, возникших на стадии генерации кода, выполняется возврат на предыдущую стадию. К развертыванию приложения можно приступать после выдачи соответствующего программного компонента. Это завершает переход от проектного цикла к реальной эксплуатации. Если возникает необходимость в переделке программного компонента, цикл начинается заново с объектно-ориентированного анализа.
Теперь перейдем к описанию подпроцессов процедурной модели на более детальном уровне транзакций.
