Моделирование в реинжиниринге бизнес-процессов

Размещено на http://www.allbest.ru/

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ, МОЛОДЁЖИ И СПОРТА УКРАИНЫ ДОНЕЦКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ

МАТЕМАТИЧЕСКИЙ ФАКУЛЬТЕТ

ДОКЛАД

МОДЕЛИРОВАНИЕ В РЕИНЖИНИРИНГЕ БИЗНЕС-ПРОЦЕССОВ

Выполнили:

студентки группы 5-И

Гузар О.Т.

Проверил: Мичкивский С.Н.

ДОНЕЦК 2011



Введение

визуализация программный интерфейс unified

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

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

Итак, что же такое модель? Попросту говоря, модель - это упрощенное представление реальности. Модель - это чертеж системы: в нее может входить как детальный план, так и более абстрактное представление системы «с высоты птичьего полета». Хорошая модель всегда включает элементы, которые существенно влияют на результат, и не включает те, которые малозначимы на данном уровне абстракции.



1. Значение моделирования

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

Зачем мы моделируем? Для этого есть одна фундаментальная причина.

Мы строим модель для того, чтобы лучше понимать разрабатываемую систему.

Моделирование позволяет решить четыре различные задачи:

1. Визуализировать систему в ее текущем или желательном для нас состоянии;

2. Описать структуру или поведение системы;

3. Получить шаблон, позволяющий сконструировать систему;

4. Документировать принимаемые решения, используя полученные модели.

Существуют общие требования к моделированию бизнеса в целом.

При конструировании компании обязательно необходимо иметь в виду, что компания будет подвержена изменениям. Следовательно важно, чтобы язык был гибким. Должна существовать возможность, менять процессы, но при этом производить продукцию для клиентов бизнеса. Необходимо также иметь возможность адаптировать процессы к новым ситуациям. Например, если компания открывает филиалы, должна быть предусмотрена возможность специализировать процесс продаж так, чтобы он работал и в филиале. При разработке модели бизнеса в ходе прямого или обратного реинжиниринга необходимо создать две модели компании: внешнюю и внутреннюю. Внешняя модель описывает компанию и внешний для нее мир. Она описывает процессы, которые удовлетворяют интересы клиентов и интересы вне компании. Интерфейс между каждым процессом и окружающей средой жизненно важен и должен быть описан с особым вниманием. Внутренняя модель компании описывает: как строится каждый бизнес-процесс из различных рабочих задач (внутренних процессов) и какие ресурсы он использует. Внутренняя модель использует объекты, соответствующие рабочим задачам, и объекты, соответствующие предметам бизнеса, например продукция. Типичными ИС, применяемыми для моделирования деятельности компаний, являлись разнообразные САSЕ-средств которые описывали деятельность компании в статических понятиях например, Е/R-диаграммы, диаграммы потоков данных и т.п. Эти средства позволяли описать компанию в виде взаимосвязанной совокупности блоков (отделений, отделов, лабораторий, групп и т.п.), указывая при этом их функции, входы, выходы, диапазоны передаваемых параметров и т.п. Однако эти ИС не позволяли описывать реальное, текущее состояние компании и ее подразделений, изменяемое во времени.

2. Внешняя модель

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

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

3. Бизнес-система

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

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

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

Рассмотрим более подробно ключевые слова из этого определения:

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

Индивидуальный субъект. Это понятие упрощает нахождение правильных прецедентов, т.е. позволяет избегать слишком сложных прецедентов. Рассмотрение прецедента важно начинать с индивидуальных субъектов - с экземпляров действующих лиц. Например, при моделировании компании, специализирующейся на продаже некоторой продукции, необходимо осознавать, что субъект, названный "клиент", на самом деле представляет трех различных клиентов: во-первых, простого потребителя продукции (каких много); во-вторых, покупателя продукции, т. е. кого-то, кто разбирается в закупках, но не обязательно знает, для чего используется продукция; и, во - вторых покупателя продукции, т.е. кого-то, разбирается в закупках но не обязательно знает для, чего используется продукция; в третьих того, кто может компетентно судить о продукции в сравнении конкурирующими продуктами. Каждый из этих случаев требует дельного прецедента, так как субъекты играют в них различные по отношению к системе.

Измеримая потребительская ценность. Эти слова служат как для выбора не слишком детального уровня прецедента. Должна ( предусмотрена возможность оценить эффективность прецедента терминах цены или стоимости. Например, обращение в банк за кредитом имеет ценность для клиента банка.

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

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

Обслуживание Обеда или Ужина - посетитель приходит в ресторан и его обслуживают. Посетитель может выбрать блюдо из меню или даже заказать блюдо по своему рецепту.

Обслуживание Завтрака - посетитель приходит в ресторан обслуживают в процессе Завтрака. Он может выбрать блюдо из ограниченного меню.

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

Поставка Продуктов - поставляются компоненты, необходимо для приготовления блюд.

Когда окружение бизнеса идентифицировано, можно начинать идентифицировать бизнес-систему изнутри. Как правило эта работа выполняется итеративно. Бизнес-система Ресторан имеет окружности в виде двух типов субъектов: Посетителя и Поставщика. Ресторан взаимодействует с окружением посредством четырех прецедентов: Обслуживание Завтрака, Обслуживание Обеда Ужина, Обслуживание Мероприятия и Поставка Продуктов Конкретные Посетители и Поставщики могут использовать эти четыре прецедента.

4. Описание прецедента

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

Пример. Рассмотрим более подробно пример "Обслуживание Обеда или Ужина". Когда посетитель входит в ресторан, его встречают у двери предлагают снять пальто. После этого его усаживают за столик и дают меню. Когда субъект Посетитель обдумал свои выбор, официант предлагают ему сделать заказ; субъект может сам привлечь внимание официанта выполнения заказа. Посетитель делает заказ официанту, заказ передается кухню, где готовятся соответствующие блюда. Когда заказ готов, его подают посетителю. По окончании еды ожидается, что посетитель даст сип официанту и заплатит. Заплатив, он берет свое пальто в гардеробе и покидает ресторан. На этом прецедент завершается. Это описание упрощено по сравнению с тем, как должен быть описан прецедент для П-модели. Дело в том, что в данном прецеденте возможны различные альтернативы в ходе событий, такие к "какое-либо блюдо не готово" или "посетитель не может заплатит. Если попытаться описать прецедент, содержащий много альтерна1 хода событий, то он станет непонятным. Следовательно, было целесообразно использовать некоторую форму структурного описания. Тогда пример выглядел бы следующим образом:

Основной поток событий:

А. Прецедент начинается, когда Посетитель входит в ресторан.

Б. Посетитель имеет возможность оставить пальто в гардеробе, по этого он приглашается за столик и получает меню.

В. Когда Посетитель ознакомился с меню, официант просит его сделать заказ. Посетитель может сам позвать официанта и сделать заказ.

Г. Когда Посетитель сделал заказ, кухня получает информацию о продуктах и напитках для его приготовления.

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

Е. Когда блюдо готово, его подают Посетителю. Когда обед завершен. ожидается, что посетитель даст сигнал Официанту и заплатит.

Ж. Когда оплата произведена, Посетитель может взять свое пальто в гардеробе и покинуть ресторан. На этом прецедент завершается.

Альтернативы хода событий:

* Альтернатива А: если ресторан переполнен, Посетитель имеет выбор посидеть в баре, пока освободится столик, или уйти из ресторана. В первом случае прецедент используется с этапа Б после некоторого ожидания. Если субъект уходит, пример завершается.

* Альтернатива В: если на этапе В выясняется, что блюдо, которое хочет Посетитель, сегодня не подается, то официант предлагает замену блюда. Если Посетитель решает заказать что-либо другое, то прецедент продолжается с этапа Г, иначе посещение ресторана завершается.

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

Разные экземпляры одного и того же класса могут оказаться весьма отличными друг от друга. Шаги, определенные в описании класса, не должны исполняться в предписанном последовательном порядке; они могут выполняться даже параллельно, когда пример конкретизирован.

Можно также сказать, что прецедент может следовать различными путями. Например, экземпляр прецедента Обслуживание Обеда или Ужина будет действовать особым образом, если у посетителя. нет денег заплатить; возможно, у посетителя потребуют документы или даже вызовут полицию. Если при выполнении другого экземпляра того же класса прецедентов у посетителя есть деньги, то спрашивать документы у него не будут. Однако оба эти экземпляра одного прецедента следуют одному описанию, т. е. подчиняются одному классу.

5. Внутренняя объектная модель

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

В соответствии с современными тенденциями при описании внутренней модели будем базироваться на понятии "объект", поэтому будем называть внутреннюю модель - 0-моделью (объект-моделью). Заметим, что и П-модель (если позволяет инструментальное средство) естественно описывать, базируясь на объектном подходе. Использование объектов дает компании прочную архитектуру, которая понятна, поддается изменениям, адаптируема и может использоваться повторно.

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

Пример. При описании внутренней О-модели для бизнес-системы Ресторан уместно ввести по крайней мере следующих участников: Гардеробщик, Официант и Повар. (На самом деле этот перечень не полон. В зависимости от моделируемых задач могут потребоваться такие участники, как бухгалтер, уборщица и т.п.). К сущностям, используемым в ходе бизнеса, следует отнести Меню и Заказанные блюда (для краткости - Заказ). Итак, для описания бизнес-системы Ресторан вводим следующие классы объектов: Гардеробщик, Официант, Повар, Меню и Заказ (рис. 1.3).

Объект может соответствовать задачам, продукции или сущностям в бизнесе. Задачи могут быть подразделены на два типа: те, что обеспечивают взаимодействие субъектов с бизнесом, и те, которые являются чисто внутренними. Удобно определить различные типы объектов, для того чтобы сделать более ясными задачи, которые они выполняют в модели. Обычно различают следующие типы объектов: объекты-сущности, управляющие объекты и интерфейсные объекты. Все классы объектов будем изображать в виде треугольников с добавлением букв внутри треугольника (см. рис.1.3): и - интерфейсные, у - управляющие.

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

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

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

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

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

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

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

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

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

6. Взаимодействие объектов в прецеденте

Взаимодействие объектов в прецеденте (рис. 1.4) отображает динамику объектной модели. Этот тип представления содержит, помимо объектов, отношения коммуникации, необходимые для выполнения прецедента. Чтобы объяснить, кто и как инициирует потоки событий, необходимо включить в представление субъекты и отношения, связывающие субъекты с объектами.

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

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

Рис. 1.4 Объекты, участвующие в прецеденте

Обслуживание Обеда или Ужина

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

Б. Объект Гардеробщик спрашивает Посетителя, желает ли тот сдать пальто. Как вариант: Посетитель сам может проинформировать Гардеробщика о своем желании. После этого Посетителя встречает Главный Официант, который сажает его за столик в соответствии с Планом Размещения. Затем Главный Официант вызывает Официанта, который будет обслуживать Посетителя. Официант дает Посетителю меню или на словах описывает, что сегодня подают. Предложенные варианты соответствуют текущему экземпляру объекта Меню.

B. После соответствующего промежутка времени объект Официант просит Посетителя сделать заказ. Альтернатива: Посетитель сам может позвать официанта. Посетитель делает заказ и Официант проверяет, все ли из заказанного доступно в Меню.

Г. Официант заносит заказ посетителя в новый экземпляр объекта Заказ. Затем Официант создает новый экземпляр объекта Счет. Официант информирует экземпляр объекта Повар о том, что поступил новый заказ.

Д. Объект Повар готовит различные блюда в соответствии с Рецептами. Он также достает из холодильника заказанные Напитки.

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

Ж. Официант обновляет объект Счет и представляет его Посетителю. Ожидается, что Посетитель заплатит. Затем Посетитель просит объект Гардеробщик вернуть оставленные на хранение вещи и покидает ресторан. На этом прецедент завершается.

Альтернативы хода событий:

Альтернатива А: если на этапе А ресторан полон, объект Гардеробщик сообщает об этом субъекту Посетитель. Посетителю говорят, что он может посидеть в баре, пока освободится столик. Когда объект Главный Официант сообщает объекту Гардеробщик, что освободился столик, он говорит об этом Посетителю. В этом случае прецедент продолжается с этапа Б. Если Посетитель не хочет ждать и уходит, то прецедент завершается.

Альтернатива В: если на этапе В блюдо, которое заказал Посетитель, не включено в объект Меню, то объект Официант говорит Посетителю, что это блюдо сегодня не подается. Независимо от того, по какой причине это блюдо недоступно: из-за несоответствий в напечатанном меню или потому, что у Посетителя какие-то особые требования, Официант должен уметь предложить замену. Когда субъект Посетитель и объект Официант приходят к соглашению, прецедент продолжается с этапа Г.

Заметим, что мы следовали той же структуре, что и в первом описании прецедента. Так легче отслеживать объекты и подпотоки событий в прецеденте.

Унифицированный язык моделирования (Unified ModelingLanguage - UML) - это стандартный инструмент для разработки «чертежей» программного обеспечения. Его можно использовать для визуализации, спецификации, конструирования и документирования артефактов программных систем. UML подходит для моделирования любых систем - от информационных систем масштаба предприятия до распределенных Web - приложений и даже встроенных систем реального времени. Это очень выразительный язык, предназначенный для представления системы со всех точек зрения, относящихся к ее разработке и внедрению. Несмотря на богатство выразительных средств, UML прост для понимания и применения. Изучение эффективного использования UML начинается с формирования концептуальной модели языка, и связи с этим необходимо ознакомиться с тремя основными элементами: базовыми строительными блоками UML, правилами, определяющими, как эти блоки могут сочетаться между собой, а также некоторыми общими механизмами языка.

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

7. UML - язык программирования

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

UML - язык специфицирования

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

UML - язык конструирования

Отображение модели на язык программирования позволяет осуществить прямое проектирование (forward engineering) - генерацию кода на языке программирования из модели UML. Обратное также возможно: вы можете восстановить модель UML на основе существующей реализации. В обратном проектировании (reverse engineering) нет никакой магии. Если только вы не закодировали информацию в реализации, она теряется при переходе от модели к коду.

Краткая история UML

Первым объектно-ориентированным языком принято считать Simula-67, разработанный Далем и Нигардом в Норвегии в 1967 году. Этот язык мало кто взял на вооружение, но его концепция во многом способствовала появлению других языков. Язык Smalltalk получил широкое распространение в начале 1980-х годов, а в конце того же десятилетия за ним последовали другие объектно-ориентированные языки, такие как Objective C, C++ и Eiffel. Объектно-ориентированные языки моделирования появились в 1980-х годах, когда исследователи, поставленные перед необходимостью учитывать новые возможности объектно-ориентированных языков программирования и требования, предъявляемые все более сложными приложениями, вынуждены были начать разработку различных альтернативных подходов к анализу и проектированию. В период с 1989 по 1994 год число объектно-ориентированных методов возросло с десяти более чем до пятидесяти. Тем не менее, многие пользователи испытывали затруднения при выборе языка моделирования, который полностью отвечал бы их потребностям, что послужило причиной так называемой «войны методов». В результате появилось новое поколение методов, среди которых особое значение приобрели метод Буча, OOSE (Object-Oriented Software Engineering) , разработанный Якобсоном, и OMT (Object Modeling Technique) , разработанный Рамбо. Каждый из этих методов можно было считать целостным и законченным, хотя любой из них имел не только сильные, но и слабые стороны. Выразительные возможности метода Буча были особенно важны на этапах проектирования и конструирования системы. OOSE был великолепно приспособлен для анализа и формулирования требований, а также для высокоуровневого проектирования. OMT оказался особенно полезным для анализа и разработки информационных систем. Критическая масса новых идей начала накапливаться к середине 1990-х годов, когда Гради Буч (компания Rational Software Corporation), Джеймс Рамбо (General Electric), Ивар Якобсон (Objectory) и другие предприняли попытку объединить свои методы, уже получившие мировое признание как наиболее перспективные в области объектно-ориентированных методов. Во-первых, все три метода независимо от желания разработчиков уже развивались во встречном направлении. Разумно было продолжить это движение вместе, а не по отдельности, что помогло бы в будущем устранить нежелательные различия и, как следствие, неудобства для пользователей. Во-вторых, унифицировав методы, проще было привнести стабильность на рынок инструментов объектно-ориентированного моделирования, что дало бы возможность сосредоточиться на более продуктивной деятельности. Наконец, следовало полагать, что подобное сотрудничество приведет к усовершенствованию всех трех методов и обеспечит решение задач, для которых любой из них, взятый в отдельности, был не слишком пригоден. Начав унификацию, авторы поставили перед собой три главные цели:

1. Моделировать системы целиком, от концепции до исполняемых компонентов, с помощью объектно-ориентированных методов;

2. Решить проблему масштабируемости, которая присуща сложным, критически важным системам;

3. Создать язык моделирования, который может использоваться не только людьми, но и компьютерами.

Создание языка для объектно-ориентированного анализа и проектирования не слишком отличается от разработки языка программирования. Во-первых, требовалось ограничить задачу. Следует ли включать в язык возможность спецификации требований? Должен ли язык позволять визуальное программирование? Во-вторых, необходимо было найти точку равновесия между выразительной мощью и простотой. Слишком простой язык ограничил бы круг решаемых с его помощью задач, а слишком сложный мог ошеломить неискушенного разработчика. Кроме того, при объединении существующих методов следовало учитывать наличие продуктов, разработанных с их помощью. Внесение слишком большого числа изменений могло бы оттолкнуть уже имеющихся пользователей, а авторы, сопротивляясь развитию языка, потеряли бы возможность привлекать новых пользователей и делать язык более простым и удобным для применения. Создавая UML, авторы старались найти оптимальное решение этих проблем. Официальное создание UML началось в октябре 1994 года, когда Рамбо перешел в компанию Rational Software, где работал Буч. Первоначальной целью было объединение методов Буча и OMT. Первая пробная версия 0.8 Унифицированного метода (Unified Method), как его тогда называли, появилась в октябре 1995 года. Приблизительно в то же время в компанию Rational перешел Якобсон, и проект UML был расширен с целью включить в него OOSE. В результате наших совместных усилий в июне 1996 года вышла версия 0.9 языка UML. На протяжении всего года создатели занимались сбором отзывов от основных компаний, работающих в области создания программного обеспечения. За это время стало ясно, что большинство таких компаний сочло UML языком, имеющим стратегическое значение для их бизнеса. В результате был создан консорциум UML, в который вошли организации, изъявившие желание предоставить ресурсы для работы, направленной на создание полной спецификации UML. Версия 1.0 языка появилась в результате совместных усилий компаний

Digital Equipment Corporation, Hewlett-Packard, I-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhousе, Microsoft, Oracle, Rational, Texas Instruments и Unisys. UML 1.0 оказался хорошо определенным, выразительным, мощным языком, применимым для решения большого количества разнообразных задач. В январе 1997 года он был предоставлен в качестве проекта стандартного языка моделирования консорциуму OMG (Object Management Group). Между январем и июлем 1997 года консорциум UML расширился - в него вошли почти все компании, откликнувшиеся на призыв OMG, а именно: Andersen Consulting, Ericsson, Object Time Limited, Platinum Technology, Ptech, Reich Technologies, Softeam, Sterling Software и Taskon. Чтобы формализовать спецификации UML и координировать работу с другими группами, занимающимися стандартизацией, под руководством Криса Кобрина (Cris Kobryn) из компании MCI Systemhouse и Эда Эйхолта (Ed Eykholt) из Rational была организована рабочая группа. Пересмотренная версия UML (1.1) была представлена на рассмотрение OMG в июле 1997 года. В сентябре версия была утверждена на заседаниях группы по анализу и проектированию и Комитета по архитектуре OMG, а 14 ноября 1997 года была утверждена в качестве стандарта всеми участниками консорциума OMG. В течение нескольких лет специальная рабочая группа OMG (OMG Revision Task Force) поддерживала продвижение проекта UML. Были созданы версии 1.3, 1.4 и 1.5. За 2000-2003 годы новая, расширенная группа участников проекта создала модернизированную версию UML 2.0. Эта версия рассматривалась в течение года рабочей группой Finalization Task Force (FTF) во главе с Брэном Сэликом (Bran Selic) из IBM, а в начале 2005 года члены OMG утвердили официальную версию UML 2.0. UML 2.0 - это последний релиз UML, который включает в себя большое количество дополнительных возможностей. Много изменений было сделано благодаря опыту использования предыдущих версий UML - это результат работы множества специалистов и осмысления опыта их предыдущих разработок. Подсчитать источники, которые использовались при подготовке этого проекта, было бы огромным научным трудом. Но сложнее всего было бы установить все предшествующие наработки, в большей или меньшей степени оказавшие влияние на UML. С учетом всех научных исследований и рабочей практики можно сказать, что UML - это верхушка «айсберга», который вобрал в себя весь предыдущий опыт. При моделировании реальных систем (неважно, из какой проблемной области) вы обнаруживаете, что приходится создавать одни и те же виды диаграмм, поскольку они представляют общие взгляды на общие модели.

Где может использоваться UML?

UML прежде всего предназначен для моделирования и разработки программных систем. Наиболее эффективно его применение в следующих областях:

_ корпоративные информационные системы;

_ банковские и финансовые услуги;

_ телекоммуникации;

_ транспорт;

_ оборона, авиация и космонавтика;

_ розничная торговля;

_ медицинская электроника;

_ наука;

_ распределенные Web-сервисы.

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

Виды диаграмм, используемые в UML

Как правило, статические части системы описываются одной из следующих диаграмм:

1. Диаграмма классов;

2. Диаграмма компонентов;

3. Диаграмма составной структуры;

4. Диаграмма объектов;

5. Диаграмма размещения;

6. Диаграмма артефактов.

Часто вы также будете использовать пять дополнительных диаграмм для представления динамических частей систем:

1. Диаграмма вариантов использования;

2. Диаграмма последовательности;

3. Диаграмма коммуникации;

4. Диаграмма состояний;

5. Диаграмма деятельности.

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

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

Общие свойства

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

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

1. Для моделирования словаря системы.

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

2. Для моделирования простых коопераций.

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

3. Для моделирования логической схемы базы данных.

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

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

Диаграмма компонентов разрабатывается для следующих целей:

· визуализации общей структуры исходного кода программной системы;

· спецификации исполняемого варианта программной системы;

· обеспечения многократного использования отдельных фрагментов программного кода;

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

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

Компоненты

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

В языке UML выделяют три вида компонентов:

· развертывания, которые обеспечивают непосредственное выполнение системой своих функций. Такими компонентами могут быть динамически подключаемые библиотеки с расширением dll, Web-страницы на языке разметки гипертекста с расширением html и файлы справки с расширением hlp;

· рабочие продукты. Как правило, это файлы с исходными текстами программ, например, с расширениями h или срр для языка C++;

· исполнения, представляющие собой исполняемые модули - файлы с расширением ехе.

8. Интерфейсы

Следующим элементом диаграммы компонентов являются интерфейсы. В общем случае, интерфейс графически изображается окружностью, которая соединяется с компонентом отрезком линии без стрелок. Имя интерфейса должно начинаться с заглавной буквы "I" и записываться рядом с окружностью. Семантически линия означает реализацию интерфейса, а наличие интерфейсов у компонента означает, что данный компонент реализует соответствующий набор интерфейсов.

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

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

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



9. Рекомендации по построению диаграммы компонентов

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

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

Диаграмма композитной структуры -- статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса.

Подвидом диаграмм композитной структуры являются диаграммы кооперации, которые показывают роли и взаимодействие классов в рамках кооперации. Кооперации удобны при моделировании шаблонов проектирования.

10. Базовые понятия

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

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

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

Организация коопераций

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

Размещено на Allbest.ru