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

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

23.10.2007.

Развитие внешней П-модели осуществляется через описание прецедентов. Поскольку прецедентов много и они могут быть одинаковыми, то их классифицируют, поэтому при моделировании необходимо различать класс субъектов и фактических субъектов. В модели реальные люди являются не экземплярами некоторого класса, а реализациями экземпляров этого класса. Каждый субъект представляет собой некоторую роль, которую играют реальные люди. Запишем, что один и тот же человек моет играть несколько ролей, т.е. реализовывать несколько экземпляров субъекта. Т.о. следует различать класс и экземпляр прецедента. Класс прецедентов определяется его писанием, а экземпляр прецедента – действиями, которые выполняются когда поток событий, соответствующий описанию прецедентов, проходит через систему. Класс прецедентов может содержать несколько альтернативных путей через систему, но экземпляр должен следовать только одному  из них. Чтобы придать П-модели большую глубину, составляются детальные описания каждого прецедента и взаимодействие между ними. Фактически эти действия можно рассматривать как машину состояния событий. В этой машине событий состояние экземпляра прецедента представляется как стимул, который может быть получен от другого прецедента и может вызывать переход к другому состоянию после завершения транзакции. Можно так сказать, что прецедент может следовать различными путями, экземпляр внутри него – своим, но все это направленно на завершение транзакции. При построении П-модели необходимо исследовать взаимодействие между субъектом и прецедентом. Известно, что субъекты взаимодействуют с системой, посылая стимулы. Чтобы лучше понять субъект, необходимо знать в каком прецеденте он участвует. В П-модели он показывается стрелкой. Рассмотрение П-модели позволяет сделать такие выводы, что П-модель дает внешнее представление системы. Это означает, что модель предназначена в 1 очередь для заказчиков и пользователей системы, а не для тех кто ее реализует. Прецеденты должны выражать что бизнес должен делать в то время,  как внутренняя будет выражать как работает. П-модель – «что модель».

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

Внутренняя объектная модель. П-модель – хорошее средство для описания требований к бизнесу, они иллюстрирует функции к бизнесу, его окружение и бизнес-процессы, которые он предлагает внешнему миру. Тем не менее П-модель не дает ясной картины о внутреннем устройстве бизнеса, т.е. о том как различные виды деятельности реализуют бизнес-процессы. Для более полного понимания бизнеса необходимо разработать внутреннюю модель. В отличае от П-модели, внутренняя модель не описывает аспекты бизнеса, которые не могут иметь прямое отношение к бизнесу. Бизнес не может заниматься ничем. В расчет необходимо принимать требования, регулирующие бизнес-процессы и называть эти вещи процессами, относящимися к бизнесу. Используют 2 вида внутренних моделей: идеальные и реальные. Идеальная модель – модель, не учитывающая как компания должна реализовываться на практике. Например, географическое расположение, наличие филиалов. Реальная – учитывает все факторы. Например, что компания не располагает потребным персоналом с нужной компетенцией, предполагаемой идеальной модели. В соответствии с тенденциями, намечающимися сегодня, при описании внутренней модели будем базироваться на понятии объект, поэтому внутреннюю модель обозначим как О-модель. При описании О-модели, объекты представляют участников процессов и различного рода сущности (продукты, предметы, задачи), используемые в ходе выполнения процессов. Имя, которое дается классу объектов, должно как более ясно выражать суть, свойственную экземплярам этого класса. Классам часто дают имена, состоящие из нескольких слов. Имя модели должно быть уникальным, т.е. похожих имен не должно быть. Имена классов как правило выражаются существительными (меню, повар, гардеробщик….). Объект может соответствовать задачам, продукции, или сущностям бизнеса. Задачи делятся на 2 типа: те, что обеспечивают взаимодействие субъекта с бизнесом и те, которые являются внутренними. Удобно определить тип объекта для того, чтобы сделать ясными задачи, которые они выполняют в модели – это объекты сущности, выполняющие модели и интерфейсные модели. Интерфейсные и управляющие объекты представляют задачи, а не типы ресурсов. Но задачи выполняются людьми, относящимися к определенной категории ресурсов (см. рис 5.3.). Интерфейсные – представляют в бизнесе операции, которые должны выполняться каким-то ресурсом, причем одним и тем же. Эта задача включает взаимодействие с окружающим бизнесом => к коммуникабельности людей, выполняющих эту задачу, предъявляются определенные требования. Интерфейсный объект может участвовать в нескольких прецедентах. Часто они несут ответственность за координацию процесса. Управляющие объекты представляют операции бизнеса. Они, как правильно, многоэкземплярные и их объединяют в какой-то управляющий объект, например, разработчик продукции. Между объектами существуют отношения, которые устанавливаются разработчиками и изображаются стрелками или дугами. Отношения связывают 2 объекта – экземпляр и класс. Между ними есть ссылка от 1 экземпляра объекта к другому. Отношения бывают: наследование (связывают 2 класса), так же может потребоваться соотнести класс с экземпляром (метаотношения). Чаще всего используют бинарные направления отношения. Если отношения двунаправленные, то используют стрелку (дугу).

30.10.2007.

Отношения между прецедентами устанавливаются в виде отношений между объектами и их классами и указываются стрелками. (рис 5.4.).

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

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

Агрегаты объектов - отношения «состоит из» и представляет собой варианты отношения ссылки. Они используются для выражения того, что объект состоит их других объектов. Конструкция такого типа называется агрегатом. (см рис 5.6.). Отношения коммуникаций правильно называть в дипломе. Отношения коммуникации должны иметь возможность обмениваться данными. В нашем случае объект повар должен узнать из объекта заказ какие блюда он должен готовить. (см рис 5.7.). Отношения коммуникаций говорит о том, что они могут разговаривать друг с другом.

Отношения наследования.

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

Атрибуты. Характеристики объекта моделируются атрибутами объекта. Атрибут представляет собой единицу информации, хранящуюся в объекте и состоит из отношения «быть атрибутом» и его типа.  Отношение «атрибут» представляет собой значение атрибута в то время, как тип атрибута обозначает его структуру и тип. Отношение «атрибут» имеет имя, описывающее роль, которую атрибут играет по отношению к объекту. Атрибут характеризуется мощностью, которая указывает сколько экземпляров атрибута может быть ассоциировано с этим отношением. Отношения «атрибут» обычно связывают экземпляр класса объектов с экземпляром типа атрибута. В объектной модели можно описывать не все атрибуты объекта, а только те, которые нужны для понимания роли объекта и его обязательств в бизнесе. Например, объект заказ может иметь атрибуты, указывающие какие блюда и напитки заказаны. Если понятие «блюдо» и «напиток» нужны только для заказа, то этот вариант предпочтительнее, чем вводить отношения «заказ состоит из блюд, напитков». При разработке БД учитываются состояния объектов. Объект может получать различные стимулы в зависимости от значения атрибутов и от предварительно выполненных операций, т.е. объект имеет различные состояния (см рис 5.8.). Если повар имеет много заказов, он находится в состоянии полностью занят. В остальных случаях повар находится в состоянии не полностью занят. Взаимодействие объектов в прецеденте изображено на рис 5.9. Взаимодействие объекта в прецеденте отображает динамику объектной модели. Содержит объекты и отношения между объектами для выполнения прецедента (отношения коммуникации). Модель дает возможность определить потоки событий и необходимую информацию, дает ответственность, дает возможность напоминать что делать.

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

06.11.2007.

Моделирование существующего и нового бизнеса.

1.Модель существующего бизнеса.

2.Модель нового бизнеса.

1.Модель существующего бизнеса.

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

Этапы обратного инжиниринга:

1.Моделирование на основе прецедентов (П-модель). Моделирование используется для создания о описания модели существующего бизнеса в терминах субъектов и прецедентов. Эта модель будет внешним представлением предприятия в дипломе. На основании модели определяются приоритетные процессы – прецеденты. Описываются потоки событий в этих процессах. Для каждого потока строится метрика.

2.Объектное моделирование О-модель. (Модели, реализуемые внутри предприятия – модели существующего бизнеса.).  На этом этапе следует моделировать только функциональную иерархию компании и как модели распределяются через функциональную структуру. Цель обратного инжиниринга не только вскрыть узкие места в работе предприятия, но и во время его проведения привлечь персонал на его сторону.

Обратный инжиниринг позволяет:

-членам комиссии по реинжинирингу понять недостатки существующего бизнеса;

-понять как изменять бизнес (процессы за которые никто не отвечает, процессы лишние, процессы недостающие);

-сотрудникам пояснить чем плохи прежние процедуры работы и почему должны перейти на новые;

-измерить новые прецеденты (измерить стоимость наших изменений). На основании материалов обследования троится П-модель, включающая приоритетные прецеденты.

Процесс построения модели включает в себя:

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

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

Определение приоритетных прецедентов.

Приоритетные прецеденты имеют следующие характеристики:

1.Оказывает наибольшее влияние на клиентов бизнеса.

2.Характеристиа по которой большей с большей вероятностью приведет к улучшению.

3.Определение проблем существующего бизнеса.

4.Определяются проблемные прецеденты.

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

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

При обсуждении ставятся следующие вопросы:

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

-на сколько детально описан ход событий и подходящие;

-является ли ход событий корректным и завершенным;

-все ли важные альтернативные потоки событий описаны.

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

19-22.06.08 – защита ГАК

Построение информационной системы в рамках реинжиниринга.

1.Наряду с проведением реинжиниринга на предприятии, сразу же определяют его влияние на будущую информационную систему.

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

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

1. все предложения, идеи, пожелания и требования клиентов.

2.анализ требований. На этом этапе производится анализ полноты и не противоречивости спецификации требований. На этом этапе строится П-модель ИС, а так же интерфейса пользователя.

3.реальное проектирование. Разрабатывается модель, служащая базисом для реализации ИС.

4. реализация. На этом этапе создается ПО.

5.тестирование. Проверяется соответствие ИС к предъявляемым к ней требованиям.

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

Прецеденты в ИС играют две важные роли:

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

2.Прецеденты структурируют каждую объектную модель. При этом полезно структурировать О-модель таким образом, чтобы каждая из них представляла некоторый отдельный аспект ее использования. Аспект соответствует одному прецеденту ИС. И его описание включает только те объекты, которые участвуют в этом прецеденте. Идеальная модель использует объекты 3 типов: интерфейсные, управляющие и объекты-сущности. Объекты-сущности – мало изменяемые сущности «живущие дольше, чем экземпляры прецедентов, в которых они участвуют». Используются для представления атрибутов, отношений и поведения тех или иных явлений, событий, персонала. Управляющие объекты используются для описания поведения системы, задаваемого прецедентами. Обычно они управляют другими объектами и выполняют роль координаторов модели. Объекты бизнес системы представлены в рис 8.2. Порядок сбора требования описан в 8.3. Анализ требований представлен на рис 8.4.

Страницы: 1, 2, 3