35. Правила отображения информационной модели в Rational Rose и bpWin. Назначение нотаций.

Кравченко посоветовал привести примеры своих диаграмм из ВКРБ

RationalRose - CASE-средство моделирования фирмы Rational Software Corporation (США) - предназначено для автоматизации этапов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose содержит средства реинжиниринга программ, обеспечивающие повторное использование программных компонент в новых проектах.

Структура и функции

В основе работы Rational Rose лежит построение различного рода диаграмм и спецификаций, определяющих логическую и физическую структуры модели, ее статические и динамические аспекты. В их число входят диаграммы классов, состояний, сценариев, модулей, процессов.

Типы диаграмм:

Use case diagram (диаграммы прецедентов); Statechart diagram (диаграммы состояний);

Activity diagram (диаграммы активности);

Interaction diagram (диаграммы взаимодействия); Sequence diagram (диаграммы последовательностей действий);

Collaboration diagram (диаграммы сотрудничества); Class diagram (диаграммы классов);

Component diagram (диаграммы компонентов); Deployment diagram (диаграммы развертывания). Артефакт – представляет описание реальной сущности, такой как конкретный исполняемый файл.;

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

BPwin поддерживает функциональное моделирование, моделирование потока работ и потока данных. Соответствующие диаграммы реализованы на основе стандартов IDEF0, IDEF3 и DFD.

Правила построения моделей:

1.Правило балансировки.

2.Правило нумерации.

3.Правило семи.

BPwin позволяет создавать следующие виды моделей:

• Функциональные диаграммы, построенные на основе стандарта IDEF0. Эти диаграммы разделяются на четыре вида:

• Диаграммы потока работ (FCD), построенные на основе стандарта IDEF3.

• Диаграммы потока данных (DFD).

• Модели стоимостного анализа.

• Динамические модели.

35. Технология формирования структурной модели объекта автоматизации to-be.

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

Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) - модели новой организации бизнес-процессов. Модель нужна ТО-ВЕ для анализа альтернативных/лучших путей выполнения работы и документирования того, как компания будет делать бизнес в будущем. Цель: разработка технологии формирования структурной модели TO-BE. Входы информационной модели: модель AS-IS, недостатки модели AS-IS, средства реализации для построения модели AS-IS .

1. Получение модели AS-IS. 2. Анализ и выявление недостатков в модели AS-IS. 3. Формирования путей устранения недостатков. 4. Выбор нотации для построения модели TO-BE. 5. Формирование цели построения модели TO-BE на основании выявленных недостатков и анализа модели As-is. 6. Определение глубины изменений, которым подвергнется существующая структура организации процесса. 7. Анализ категории недостатков и переход к п.8 – 12. 8. Устранение дублирующих работ. 9. Устранение неуправляемых работ. 10. Устранение недостатков в документообороте. 11. Устранение недостатков отсутствия обратных связей по управлению. 12. Устранение недостатков отсутствия обратных связей по входу. 13. Формирование и анализ новых бизнес-процессов. 14. Сравнение преимуществ новых и существующих бизнес-процессов в модели AS-IS. 15. Выявление преимуществ новых бизнес-процессов. 16. Анализ средств реализации. 17. Выбор средств реализации. 18. Построение функциональной модели. 19. Контроль соответствия поставленным целям и переход в п.20 или 22. 20. Анализ категории ошибок и переход в п.7 или 13. 21. Доработка . 22. Согласование с заказчиком и переход в п.23 или 20. 23. Утверждение модели

Заключение: на основе построения модели TO-BE устраняются недостатки модели AS-IS, а так же строится модель данных, прототип и затем окончательный вариант ИС.