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

ТЕМА 4: Методология моделирования бизнес-процессов

1.Сущность моделирования и классификация моделей в реинжиниринге

Основные требования к построению моделей бизнес-процессов в компании

Методика построения прецедентной модели

Методика построения объектной модели

Вопрос 1

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

Абстрактная модель есть отображение реального объекта в виде идеальных конструкций, выполненных средствами мышления. Выделим два основных класса абстрактных моделей: формальные (математические) и семантические (содержательные).

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

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

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

Основой большинства семантических моделей являются базовые модели системного анализа (модель "черного ящика", модель состава и модель структуры) и модели семантических сетей. В последнее время для построения этого вида моделей активно используется объектно-ориентированный подход.

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

Вопрос 2

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

В модели бизнеса должны найти отражение:

1.Функция компании во внешнем мире : что она делает, для кого, с какой целью. Необходимо описать окружающую среду компании, включающую клиентов, партнеров, субподрядчиков и т.д., а также взаимодействие компании с этой средой.

2. Архитектура компании , т.е. наиболее важные статические структуры компании. Элементами структур должны быть:

Внешние и внутренние процессы компании;

Функции (отдельные шаги процессов);

Продукция (выход процессов и функций);

Ресурсы, как человеческие, так и технические.

Элементы могут быть охарактеризованы параметрами, позволяющими описывать их состояния. Для описания структур необходимо также отразить отношения между элементами, в том числе:

Отношения между процессами, отдельными функциями (шагами) процессов;

Отношения между участниками процесса - различного рода ресурсами, средствами и продукцией;

Отношения между людьми (отношения подчиненности, коммуникации и т.д.).

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

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

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

Вопрос 3

Наибольшее распространение получили 2 группы методологий моделирования бизнес-процессов:

1. Методика построения П-О-моделей (прецедент- объект - моделей), Данная методика предполагает последовательное построение двух типов моделей бизнеса: внешней (прецедентной или П-модели) и внутренней (объектной или О-модели).

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

Что такое "прецедент ". Прецедент - это "внешний" бизнес-процесс, ориентированный на клиента. Прецедент заканчивается получением продукта - измеримой потребительской ценности для некоторого индивидуального потребителя бизнес-системы.

Прецеденты могут иметь множество вариантов хода событий. Каждый конкретный прецедент (вариант) называется экземпляром . Экземпляр реализует конкретный поток событий в конкретных условиях для конкретного клиента. Похожие варианты хода событий группируются в классы прецедентов.

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

Построение П-модели начинается с выделения прецедентов и элементов окружения - клиентов, партнеров, поставщиков. Окружение моделируется при помощи действующих лиц, которые называются субъектами . Субъекты обозначают все то в окружении, что взаимодействует с бизнесом. Субъектом может быть: человек (например, клиент, покупатель); другая компания (например, организация-поставщик, субподрядчик); техническая система (например, компьютерная система другой компании).

Так же, как и для прецедентов, для субъектов различают понятия класса и экземпляра. Класс субъекта описывает общие характеристики некоторого типа субъектов, а экземпляр - характеристики конкретного субъекта.

После идентификации субъектов и прецедентов бизнес-системы необходимо описать взаимодействия между ними. На рис. 3.1 представлена графическая модель взаимодействия прецедентов и субъектов.

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

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

Рассмотрим для примера описание прецедента "Продажа продукта". Основной поток событий:

1. Продавец получает заявку клиента

2. Если в заявке указывается готовый продукт, то продавец проверяет наличие требуемого продукта на складе. Далее прецедент продолжается с шага 5.

3. Если в заявке указывается заказной продукт, продавец уточняет сведения о заказе и передает их проектировщику продукта

4. Проектировщик модифицирует продукт в соответствии с требованиями клиента

5. Продавец принимает от клиента оплату

6. Продавец сообщает отправителю количество продукта и адрес клиента и заказывает транспорт

7. Отправитель доставляет клиенту продукт.

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

Вопрос 4

Описание О-модели базируется на понятии "объект". Объекты представляют участников процессов и различного рода сущности (продукция, предметы, задачи и т.д.). Различают классы объектов, описывающие общие характеристики некоторого типа объектов, и экземпляры , описывающие характеристики конкретного объекта. О-модель, представленную в терминах классов объектов, называют идеальной моделью. Такая модель не учитывает некоторых деталей реализации модели на практике. О-модель, описанную в терминах экземпляров объектов, называют реальной. Она учитывает особенности конкретной реализации.

Выделяются следующие типовые классы объектов:

1. Интерфейсные - объекты, осуществляющие взаимодействие с окружением, т.е. с субъектами. Примерами интерфейсных объектов являются Продавец, Регистратор, Секретарь. В роли интерфейсного объекта может выступать не только человек. Это может быть, например, часть информационной системы - графический интерфейс пользователя.

2. Управляющие - активные объекты, управляющие процессами, но не имеющие контакта с окружением. Типичные примеры управляющих объектов в компании - это Разработчик продукции, Менеджер проекта.

3. Объекты-сущности - пассивные объекты, которые обрабатываются бизнесом. Как правило, объекты-сущности не являются человеческими или техническими ресурсами. Типичные примеры сущностей в компании - Продукция, Заказ, Извещение.

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

Объекты (классы и экземпляры) связываются отношениями . Бинарное отношение связывает два объекта. Оно может быть как однонаправленным, так и двунаправленным.

В графической модели взаимодействия объектов прецедента объекты изображаются треугольниками (интерфейсные - с буквой "и" внутри, управляющие - с буквой "у" внутри), а отношения между объектами - дугой (стрелкой). На рис. 3.4 представлена модель взаимосвязей объектов для прецедента "Продажа заказного продукта", описанного в п.3.2.1.

Для того, чтобы иметь представление обо всех ролях и обязанностях объекта, нужно составить описание объекта . Описание объекта состоит из двух частей: описание состояний и описание поведения. Для составления описания состояний объекта, прежде всего, необходимо выделить все его характеристики, свойства, называемые атрибутами. Атрибут должен иметь имя, диапазон возможных значений, а для экземпляра объекта еще и конкретное текущее значение атрибута. Например, объект "Заказ" может иметь атрибуты, указывающие название заказываемого товара, его характеристики, количество, имя клиента, заказавшего товар и т.д. Как правило, состав атрибутов одинаков для всего класса объекта. Различные экземпляры объекта отличаются лишь набором конкретных значений атрибутов.

Различают постоянные атрибуты, значения которых не изменяются в ходе выполнения прецедента и переменные, которые определяют различные состояния объекта. Например, объект «Заказ» может иметь переменный атрибут, указывающий, находится ли заказ в стадии изготовления товара, отправки товара или он уже выполнен.

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

©2015-2019 сайт
Все права принадлежать их авторам. Данный сайт не претендует на авторства, а предоставляет бесплатное использование.
Дата создания страницы: 2017-10-11

Зависимости между классами (объектами)

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

Между объектами можно устанавливать зависимости по данным. Эти зависимости выражают связи или отношения между классами указанных объектов. Примеры таких зависимостей изображены на рисунке 2.6 (первые две зависимости - бинарные, третья зависимость - тренарная). Зависимость изображается линией, соединяющей классы над которой надписано имя этой зависимости, или указаны роли объектов (классов) в этой зависимости (указание ролей - наиболее удобный способ идентификации зависимости).

Рис. 2.6. Зависимости между классами

Зависимости между классами являются двусторонними: все классы в зависимости равноправны. Это так даже в тех случаях, когда имя зависимости как бы вносит направление в эту зависимость. Так, в первом примере на рисунке 2.6 имя зависимости имеет_столицу предполагает, что зависимость направлена от класса страна к классу город (двусторонность зависимости вроде бы пропала); но следует иметь в виду, что эта зависимость двусторонняя в том смысле, что одновременно с ней существует и обратная зависимость является_столицей. Точно таким же образом, во втором примере на рисунке 2.6 можно рассматривать пару зависимостей владеет-принадлежит. Подобных недоразумений можно избежать, если идентифицировать зависимости не по именам, а по наименованиям ролей классов, составляющих зависимость.

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

Дальнейшие примеры зависимостей между классами приведены на рисунке 2.7. Первый пример показывает зависимость между клиентом банка и его счетами. Клиент банка может иметь одновременно несколько счетов в этом банке, либо вовсе не иметь счета (когда он впервые становится клиентом банка). Таким образом, нужно изобразить зависимость между клиентом и несколькими счетами, что и сделано на рисунке 2.7. Второй пример показывает зависимость между пересекающимися кривыми (в частности, прямыми) линиями. Можно рассматривать 2, 3, и более таких линий, причем они могут иметь несколько точек пересечения. Наконец, третий пример показывает необязательную (optional) зависимость: компьютер может иметь, а может и не иметь мышь.

Зависимостям между классами соответствуют зависимости между объектами этих классов. На рисунке 2.8 показаны зависимости между объектами для первого примера рисунка 2.6; на рисунке 2.9 показаны зависимости между объектами для примеров, изображенных на рисунке 2.7.

Рис. 2.7. Дальнейшие примеры зависимостей. Обозначения

Рис. 2.8. Зависимости между объектами

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

При проектировании системы удобнее оперировать не объектами, а классами.

Рис. 2.9. Более сложные зависимости между объектами

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

Теперь у нас есть все необходимые понятия, чтобы описать процесс построения объектной модели. Этот процесс включает в себя следующие этапы:

• определение объектов и классов;
• подготовка словаря данных;
• определение зависимостей между объектами;
• определение атрибутов объектов и связей;
• организация и упрощение классов при использовании наследования;
• дальнейшее исследование и усовершенствование модели.

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

Модели помогают:

Проверить работоспособность разрабатываемой системы на ранних этапах ее разработки;

Общаться с заказчиком системы, уточняя его требования к системе;

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

В настоящее время существует несколько технологий объектно-ориентированной разработки прикладных программных систем, в основе которых лежит построение и интерпретация на компьютере моделей этих систем. В данном проекте применена одна из них - OMT (Object Modeling Techniques). Кроме того построена диаграмма объектной модели на языке UML.

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

Определение классов объектной модели

Анализ внешних требований к проектируемой системе позволяет определить объекты и классы объектов, связанные с прикладной проблемой, которую должна решать эта система. Все классы должны быть осмыслены в рассматриваемой прикладной области; классов, связанных с компьютерной реализацией, как например список, стэк и т.п. на этом этапе вводить не следует.

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

В результате получаем следующий список возможных имён классов:

Другой proxy;

Документ;

Удалённый Web сервер;

Конфигурация;

Информация о документе;

Информация об удалённом Web сервере;

Заголовок запроса;

Заголовок ответа.

Прикладная система представляет собой множества взаимозависимых объектов. Каждый объект характеризуется набором свойств, значения которых определяют состояние объекта, и набором операций, которые можно применить к этому объекту.

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

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

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

Одним из таких средств является динамическая модель под­системы. Она строится после того, как объектная модель подсистемы построена и предварительно согласована и отлажена. Динамическая модель подсистемы состоит из диаграмм сос­тояний ее объектов подсистем.

Текущее состояние объекта характеризуется совокупностью текущих значений его атрибутов и связей. Во время работы системы составляющие её объекты взаимодействуют друг с другом, в результате чего изменяются их состояния. Единицей влияния является событие : каждое событие приводит к смене состояния одного или нескольких объектов в системе, либо к возникновению новых событий. Работа системы характеризуется последовательностью происходящих в ней событий.

Событие происходит в некоторый момент времени. Примеры событий: старт ракеты, старт забега на 100 м, начало проводки, выдача денег и т.п. Событие не имеет продолжительности (точнее, оно занимает пренебрежимо малое время).

Если события не имеют причинной связи (т.е. они логически независимы), они называются независимыми (concurrent ). Такие события не влияют друг на друга. Независимые события не имеет смысла упорядочивать, так как они могут происходить в произвольном порядке. Модель распределенной системы обязательно должна содержать независимые события и активности.

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

При возникновении события происходит не только переход объекта в новое состояние, но и выполняется действие, связанное с этим событием. Действием называется мгновенная операция, связанная с событием.

Процесс построения объектной модели включает в себя следующие этапы:

Определение объектов и классов;

Подготовка словаря данных:

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

Определение свойств объектов и связей;

Организация и упрощение классов при использовании наследования;

Дальнейшее исследования и усовершенствование модели.

Объектная модель существующего бизнеса показывает как, и за счет чего реализуются прецеденты. Данная модель раскрывает внутреннее устройство бизнеса, а именно: какие виды ресурсов используются для реализации прецедентов и каким образом они взаимодействуют. Описание объектной модели базируется на понятии "объект". Объекты представляют участников процессов и различного рода сущности (готовая продукция, заказ и т.д.).

Интерфейсные объекты, исследуемого бизнес-процесса:

• 1. Менеджер по работе с клиентами. Атрибуты: ФИО, должность, заработная плата. Обязанности: взаимодействует с клиентами, оформляет заказы, принимает оплату от клиентов за заказы.
• 2. Материально-ответственный кладовщик. Атрибуты: ФИО, должность, заработная плата. Обязанности: взаимодействие с поставщиками, принимает материалы и подписывает счет-фактуру.
• 3. Водитель-экспедитор. Атрибуты: ФИО, должность, заработная плата. Обязанности: доставка готового изделия клиенту.

Управляющие объекты, исследуемого бизнес-процесса:

• 1. Проектировщик. Атрибуты: ФИО, должность, заработная плата. Обязанности: проектирование изделия, управление исполнением проекта, контроль.
• 2. Оператор автоматизированного учета. Атрибуты: ФИО, должность, заработная плата. Обязанности: ведение автоматизированного учета, работа с базой данных.
• 3. Мебельный мастер (Сборщик). Атрибуты: ФИО, должность, заработная плата. Обязанности: изготовление продукта в соответствии с проектом.

Объекты-сущности, исследуемого бизнес-процесса:

• 1. Чек - документ, выдаваемый по факту оплаты заказа.
• 2. Каталог - документ отражающий ассортимент выпускаемой продукции.
• 3. Бланк заказа - документ, в который входит номер заказа, дата заказа, информация о клиенте, выбранный тип, эскиз изделия, пожелания клиента.
• 4. Проект изделия - проект заказанной мебели.
• 5. Заявка на материалы - документ, характеризующий необходимые материалы и их объемы.
• 6. База данных - программа, позволяющая вести материальный учет в фирме.
• 7. Материалы - необходимы для производства заказного изделия.
• 8. Счет-фактура - документ, подписываемый по факту отгрузки материалов.
• 9. Готовое изделие - результат производства, характеризуется принадлежностью к какому-либо заказу.

В таблице 5.1 приведено описание взаимосвязи объектов друг с другом.

Таблица 5.1 Описание взаимодействия объектов друг с другом

Примечание: В случае если необходимые материалы имеются на складе, то пункты 18, 19, 20, 21 данной таблицы пропускаются.

Динамическая модель взаимодействия подразделений и заказчика, в прецеденте "Продажа заказного продукта" изображена на рисунке 5.1 Динамическая модель взаимодействия подразделения, сотрудника и заказчика, в прецеденте "Оформление заказа" изображена на рисунке 5.2 Динамическая модель взаимодействия подразделения, сотрудников и заказчика, в прецеденте "Проектирование" изображена на рисунке 5.3 Динамическая модель взаимодействия сотрудников, в прецеденте "Изготовление" изображена на рисунке 5.4.

Рисунок 5.1 Диаграмма последовательности прецедента "Продажа заказного продукта"

Рисунок 5.2 Диаграмма последовательности прецедента "Оформление заказа"

Рисунок 5.3 Диаграмма последовательности прецедента "Проектирование"

Рисунок 5.4 Диаграмма последовательности прецедента "Изготовление"