Анализ объекта автоматизации. Методологии анализа.

 

Виды моделей:

· Функциональные (SADT, DFD, etc);

· Объектные (UML);

· Смешанные (ARIS).

Функциональные модели удобны, когда производится автоматизация производства с хорошо описанным производственным циклом. Модель показывает управление объектом автоматизации. В данных моделях выделяем функции у объектов, основные связи между функциями, формальные ресурсы для функций, входы и выходы у функций.

Объектный поход удобен при анализе объекта автоматизации с точки зрения ИС. Рассматривать ОА будем как применяемую на ней информационную систему. В данных моделях выделяем различные компоненты у объекта автоматизации.

Методологии:

· SADT

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

Основные элементы этой методологии основываются на следующих концепциях:

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

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

· Строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика.

Правила SADT включают:

· ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);

· связность диаграмм (номера блоков);

· уникальность меток и наименований (отсутствие повторяющихся имен);

· синтаксические правила для графики (блоков и дуг);

· разделение входов и управлений (правило определения роли данных).

· отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель.

 

· IDEF

IDEF 0 - методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временна́я последовательность (поток работ).

Стандарт IDEF0 представляет организацию как набор модулей, здесь существует правило — наиболее важная функция находится в верхнем левом углу, кроме того есть правило стороны:

· стрелка входа приходит всегда в левую кромку активности,

· стрелка управления — в верхнюю кромку,

· стрелка механизма — нижняя кромка,

· стрелка выхода — правая кромка.

Описание выглядит как «чёрный ящик» с входами, выходами, управлением и механизмом, который постепенно детализируется до необходимого уровня. Также для того чтобы быть правильно понятым, существуют словари описания активностей и стрелок. В этих словарях можно дать описания того, какой смысл вы вкладываете в данную активность либо стрелку.

Также отображаются все сигналы управления, которые на DFD (диаграмме потоков данных) не отображались. Данная модель используется при организации бизнес-проектов и проектов, основанных на моделировании всех процессов: как административных, так и организационных.

IDEF 1X - данный метод применяется для построения информационной модели, которая представляет собой структурированную информацию, необходимую для поддержки функций производственной системы или среды. Реляционные модели данных.

IDEF 3 – стандарт оформления документации технических процессов.

IDEF 4 – объектно-ориентированная система.

 

· DFD

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

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

Кроме того, нотация DFD поддерживает понятие подсистемы — структурного компонента разрабатываемой системы.

 

· UML

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

Используемые диаграммы:

§ Диаграмма классов – статическая структура классов и их связи;

§ Поведенческие диаграммы – взаимодействие и кооперация;

§ Диаграмма состояний – поведение объектов при переходах;

§ Диаграмма деятельности – сценарии использования системы;

§ Диаграмма реализации – рассмотрение компонентов системы и их размещение.

Однако использования для моделирования не очень эффективно из-за «общности» UML.

· Rup

(по идее, это методология разработки ПО, но почему-то ИРВ её упомянул немного в лекции)

В основе RUP лежат следующие принципы:

· Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков.

· Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов (вариантов использования)).

· Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки.

· Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта.

· Постоянное обеспечение качества на всех этапах разработки проекта (продукта).

· Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.

RUP использует итеративную модель разработки. В конце каждой итерации (в идеале продолжающейся от 2 до 6 недель) проектная команда должна достичь запланированных на данную итерацию целей, создать или доработать проектные артефакты и получить промежуточную, но функциональную версию конечного продукта. Итеративная разработка позволяет быстро реагировать на меняющиеся требования, обнаруживать и устранять риски на ранних стадиях проекта, а также эффективно контролировать качество создаваемого продукта.

Этапы:

· Начало (определение требований, границ, рисков и т.д.);

· Уточнение (анализ предметной области и построение исполняемой архитектуры – основных частей);

· Построение (реализация большей части функционала)

· Внедрение (Финальная реализация и внедрение заказчику).

· BPMN

BPMN - Спецификация BPMN описывает условные обозначения для отображения бизнес-процессов в виде диаграмм бизнес-процессов. BPMN ориентирована как на технических специалистов, так и на бизнес-пользователей. Для этого язык использует базовый набор интуитивно понятных элементов, которые позволяют определять сложные семантические конструкции. Кроме того, спецификация BPMN определяет, как диаграммы, описывающие бизнес-процесс, могут быть трансформированы в исполняемые модели на языке BPEL. Основная цель BPMN — создание стандартного набора условных обозначений, понятных всем бизнес-пользователям. Бизнес-пользователи включают в себя бизнес-аналитиков, создающих и улучшающих процессы, технических разработчиков, ответственных за реализацию процессов и менеджеров, следящих за процессами и управляющих ими. Следовательно, BPMN призвана служить связующим звеном между фазой дизайна бизнес-процесса и фазой его реализации. Так же BPMN очень удобна для описания документооборота в системе.

Объекты поток управление - события, действия и логический оператор.

События так или иначе обозначаются различными видами кружочков (внутри условные обозначения дающие понять что за события)

Действия - прямоугольник с названием (существует возможность вложенности заданий)

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

Логический оператор - ромбик

Отдельные элементы соединяются стрелочками: сплошная - поток управления, пунктирная - поток сообщения и просто штрих - ассоциация

Пул - делится на дорожки- предназначен для объединения нескольких объектов потока управления в определенный набор (ролевой)

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

 

· ARIS

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

ARIS Express - Пользуются SAP3 Oracle.

Есть крыша - организационное представление о объекте автоматизации (связи между ними, различная привязка структурных подразделений)

Есть три крыла:

o Функциональные модели - описывают иерархию целей перед управленческим аппаратом компании

o Информационные модели - отображают структуру информации необходимые для реализации всей системы

o Модели управления - показывает комплексный подход к реализации деловых процессов в рамках системы

Есть фундамент - представление выходов - то что получается на выходе системы (интерфейсное представление).

Все 4 компонента могут разрабатываться независимо.

Общий подход - для каждого компонента существует три уровня представления:

o Определение требований

o уровень проектной спецификации

o Уровень описания реализации

ARIS - позволяет смоделировать, протестировать в различных условиях и получить какие то результаты ( оптимизационные …)