ГОСы / ФБИ ПРИС 2016

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

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

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

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

В основе работы 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. Моделирование потока работ обеспечивает анализ логики выполнения процесса. Моделирование потока данных позволяет сконцентрировать внимание на обмене данными между различными задачами. Для анализа работы организации в комплексе, и построения больших моделей, в BPwin предусмотрена детализация.

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

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

2.Правило нумерации. При детализации процессов должна поддерживаться их иерархическая нумерация. Например, процессы, детализирующие процесс с номером А1, получают номера А11,А12,А13 и т.д.

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

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

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

Первый вид, это контекстная диаграмма. Она представляет описание процесса на самом верхнем уровне. На этой диаграмме дается общее представление процесса и его взаимосвязи с внешней средой или другими процессами;

Второй вид – диаграмма декомпозиции. Она детализирует информацию контекстной диаграммы;

Третий вид – диаграмма дерева узлов. Эта диаграмма в BPwin предназначена для отображения иерархии функций;

Четвертый вид – диаграмма описаний. Применяется для представления отдельных частей процесса. С ее помощью можно дать различные описания, которые не поддерживаются стандартом IDEF0.

Диаграммы потока работ (FCD), построенные на основе стандарта IDEF3. Эти диаграммы даютвозможность показать логику процесса, за счет представления задач в определенной последовательности. В дальнейшем, эти модели можно использовать в качестве основы для создания динамических моделей.

Диаграммы потока данных (DFD). Эти диаграммы наглядно отображают, каким образом информация перемещается от задачи к задаче в рамках процесса. DFD

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

Модели стоимостного анализа. Эти модели строятся по правилам стоимостного анализа (ActivityBaseCosting - анализ). Модель может быть построена, только если уже существует полностью законченная и непротиворечивая функциональная модель. На каждую из задач функциональной модели назначаются метрики, представляющие затраты. Для модели определяются центры затрат. В результате получается модель стоимостного анализа.

Динамические модели. Эти модели могут быть построены на основе диаграмм потока работ. BPwin позволяет исследовать эффекты в ходе дискретного изменения состояния задач процесса. Для этого могут задаваться различные сценарии поведения процесса. Чтобы провести динамическое моделирование необходимо экспортировать диаграммы на основе IDEF3 в специальный программный продукт – business process simulator (для BPwin 4.0) или Arena (для

BPwin 7).

36 Технология формирования структурной модели объекта автоматизации 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, а так же строится модель данных, прототип и затем окончательный вариант ИС.

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

Цель: разработка технологии формирования структурной модели объекта автоматизации AS-IS.

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

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

неэффективный документооборот (нужный документ не оказывается в нужном месте в нужное время), отсутствие обратных связей по управлению (на проведение работы не оказывает влияния ее результат), входу (объекты или информация используются нерационально) и т. д. Найденные в модели AS-IS недостатки можно исправить при создании модели ТО-ВЕ (как будет) - модели новой организации бизнес-процессов

Входы: Результаты анализа ОА (объекта автоматизации), предметной области.

Выходы: структурная модель ОА AS-IS, количественные характеристики (время,

затраты).

Технологий формирования модели:

1)Локализация ОА

2)Выбор методов проведения обследования ОА

3)Обследование ОА – получение параметрического описания ОА

4)Формирование цели, области обследования

5)Определение уровней декомпозиции

6)Определение средств для реализации модели

7)Определение входных потоков

8)Определение выходных потоков

9)Объединение входных и выходных потоков по классификационному признаку по группам

10)Определение управляющих воздействий входных и выходных потоков

11)Объединение управляющих воздействий по классификационному признаку

12)Формирование механизмов (инструментов, приспособлений, оборудования,

человеческих ресурсов) для каждого из входных и выходных потоков

13)Объединение механизмов по классификационному признаку

14)Формирование контекстной диаграммы

15)Проверка на полноту соответствия предметной области

16)Определение количества фрагментов диаграмм декомпозиций

17)Определения порядка следования фрагментов

18)Определение входных потоков фрагмента

19)Определение выходных потоков фрагмента

20)Определение взаимосвязей между объектами

21)Определение управляющих воздействий

22)Определение механизмов

23)Проверка на полноту предметной области, цели, назначению, реальных бизнес-

процессов

24)Если соответствует (да)  п. 26

25)Если нет 

26)Анализ ошибки

27)Доработка  18-22

28)Проверка соответствия количества фрагментов

29)Если соответствует количеству (да)  п. 27

30)Если нет  п. 18

31)Согласование построенной диаграммы с заказчиком, специалистом в ПО,

экспертом, и устранение недостатков

32)Доработка модели в соответствии с рекомендациями

33)Получение количественных характеристик (время, затраты).

38 Технология анализа объекта автоматизации в нотации DFD.

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

В случае наличия в моделируемой системе программной/программируемой части (практически всегда) предпочтение, как правило, отдается DFD по следующим соображениям.

1.DFD-диаграммы создавались как средство проектирования программных систем, тогда как IDEF0 - как средство проектирования систем вообще, поэтому DFD имеют более богатый набор элементов, адекватно отражающих их специфику (например, хранилища данных являются прообразами файлов или баз данных).

2.Наличие мини-спецификаций DFD-процессов нижнего уровня позволяет преодолеть логическую незавершенность IDEF0, а именно обрыв модели на некотором достаточно низком уровне, когда дальнейшая ее детализация становится бессмысленной, и построить полную функциональную спецификацию разрабатываемой системы.

3.Существуют и поддерживаются рядом CASE-инструментов алгоритмы автоматического преобразования иерархии DFD в структурные карты, демонстрирующие межсистемные и внутрисистемные связи, а также иерархию систем, что в совокупности с мини-спецификациями является завершенным заданием для программиста.

Предполагается, что перед началом проведения анализа объекта автоматизации в нотации DFD было проведено исследование предметной области и объекта автоматизации, в т.ч. на предмет обмена информацией объекта автоматизации с другими объектами (системами). Таким образом, исходными данными являются документы с формализованным представлением материалов обследования объекта автоматизации, включая описание текущей информационной модели объекта автоматизации, а также, знания основных принципов и правил построения моделей в нотации DFD.

1)определения назначения построения модели;

2)Определение временных и стоимостных ресурсов на построение модели.

3)формирование точки зрения, с которыми будет представлена модель;

4)определение глобальной функции объекта автоматизации;

5)формирование множества требований к объекту автоматизации;

6)расчленение множества требований на функциональные группы;

7)определение внешних объектов, имеющих отношение к каждой из выполняемых функций объекта автоматизации;

8)определение всех информационных потоков, связываемых объекта автоматизации с внешними объектами из п.5 и передаваемых между процессами;

9)определение числа и состава хранилищ данных на основании характеристик информационных потоков, определенных в п.6;

10)построение контекстной диаграммы AS-IS;

11)проверка соответствия построенной контекстной диаграммы целям и требованиям;

12)корректировка контекстной диаграммы в случае выявления неточностей;

13)группировка функций объекта автоматизации в подгруппы в соответствии с типом обрабатываемой информации;

14)выделение внешних объектов, связанных с выполнением каждой из подфункций;

15)выделение потоков данных, связанных с выполнением каждой из подфункций;

16)идентификация потоков данных, требующих последовательной обработки после реализации подфункции;

17)выделение хранилищ данных на основании информационных потоков, определенных в п.17;

18)формирование диаграммы потоков данных первого уровня

19)согласование диаграммы потоков данных с источниками информации и проверка соответствия представленных взаимосвязей реально существующей схеме движения информационных потоков;

20)внесение изменений в диаграмму потоков данных, перегруппировка функций;

21)определение необходимости дальнейшей декомпозиции моделис учетом п.1 и

п.2;

22)дальнейшая декомпозиции функций объекта автоматизации с повторением пп.14-17 для каждой из выделенных подфункций;

23)проверка соответствия на каждом уровне декомпозиции модели реальным потокам данных;

24)выявление недостатков модели: несоответствия, несогласованности потоков информации, недостатков организации хранения, обработки и последовательности прохождения информации;

25)Процесс принятия решения о реорганизации существующей диаграммы потоков данных;

26)добавление, укрупнения хранилищ данных, изменения системы хранения данных на основании принятых решений, добавление или устранение внешних сущностей;

27)построение модели TO-BE;

28)согласование каждого уровня декомпозиции диаграммы потоков данных TOBE;

29)планирование и формирования списка необходимых ресурсов для организации новой схемы движения информационных потоков;

30)оформление документации по результатам анализа объекта автоматизации

31)формирование требований о внесении изменений в существующую схему документооборота объекта автоматизации.

39 Применение BPWin при проектировании информационных систем.

1.Определение цели и назначения проектирования ИС

2.Сбор информации о предметной области и об объекте автоматизации.

3.Формирование основных параметров и характеристик деятельности объекта автоматизации. Выявление основных источников информации.

4.Определение степени уникальности создаваемой системы. Изучение существующих аналогов проектируемой ИС.

5.Определение бюджета разработки проекта информационной системы.

6.Определение точки зрения на объект проектирования

7.Выделение комплекса задач ОА

8.Определение перечня функциональных подсистем (перечня функций) объекта автоматизации.

9.Определение существующих взаимодействий объекта автоматизации с другими объектами.

10.Формирование команды проектировщиков в соответствии со схемой Захмана.

11.Построение модели объекта автоматизации в нотации IDEF0, диаграмм AS-IS, если система уже существует (сюда входят такие диаграммы, как контекстная диаграмма, диаграммы декомпозиции; диаграммы дерева узлов;диаграммы только для экспозиции (FEO)..

Замечание: можно построить DFD, а потом некоторые ее участки детализировать через

IDEF0.

12.Согласование построенной модели, с основными источниками информации.

13.Определение возможных недостатков модели. Определение необходимости более детального обследования объекта автоматизации.

14.Определение существующих схем движения потоков данных, мест хранения, характеристик документопотока.

15.Построение модели объекта автоматизации в нотации DFD, диаграмм AS-IS.

Замечание: степень детализации определяется 1)целью анализа 2)масштабом ИС 3)количеством денег у заказчика. Как правило, детализация до рабочих мест/операций на РМ.

16.Согласование построенной модели, выявление недостатков. Определение необходимости более детального анализа потоков данных, с синхронизацией процессов.

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

18.Построение модели объекта в нотации IDEF3, диаграмм AS-IS.

19.Согласование построенной модели, определение недостатков.

20.Формирование требований к существующей модели.

Замечание: требования формирует заказчик (что его не устраивает в текущем положении дел?)