ООАиП, 04 лекция (от 05 октября)
Материал из eSyr's wiki.
(Содержимое страницы заменено на «== From Ebaums Inc to MurkLoar. == We at EbaumsWorld consider you as disgrace of human race. Your faggotry level exceeded any imaginab...») |
(Отмена правки № 1363 участника 140.114.71.1 (обсуждение)) |
||
Строка 1: | Строка 1: | ||
- | == | + | [[ООАиП, 03 лекция (от 14 сентября)|Предыдущая лекция]] | [[ООАиП, 05 лекция (от 12 октября)|Следующая лекция]] |
- | + | ||
- | + | = Моделирование б.-м. Rational Unified Process = | |
- | + | ||
+ | Моделирование происходит в терминах | ||
+ | * исполнителей | ||
+ | * работ | ||
+ | * рабочие продукты | ||
+ | Исполнители при помощи инструментов выполн. работы, приводящие к раб. прод. | ||
+ | |||
+ | Моедли: | ||
+ | * Business Use-case model | ||
+ | * Business object(?) model | ||
+ | |||
+ | Аналитик является осн. дейст. лицом, он возглавляет и проводит бизнес-моделир. | ||
+ | |||
+ | * Видение бизнеса --- документ, в котором указывается, для чего мы проводим ..., какие цели | ||
+ | * Оценка организации | ||
+ | * Бизнес-правила --- условия, которые должны соблюдаться обязательно (напр, налогообложение) | ||
+ | * Бизнес-цели --- те задачи, которые ставит перед собой организация, напр., стать самым крупным продавцом бубликов в России | ||
+ | * Глоссарий деятельности, глоссарий бизнеса --- основные термины, исп. в бизнесе | ||
+ | * Моедль бизнес-процессов, модель бизнес-объектов | ||
+ | * Дополнительная спецификация. Цель дополнить остальные документвы, описать вещи, которые не были описаны всеми другими документами. Примером такого рода положений,Ю которые могут войти в доп. спецификацию может быть установление неокего стандарта. Например, если вы азрабатываете ПО для супермаркета, то будете готовы к тому, что вес будет в фунтах, а длина в футах, а в европе метрическая система. Также, другие вещи, связанные с локальным, региональным, национальным доказательством, отражаются там. | ||
+ | |||
+ | Бизнес-аналитик определчяет бизнес-цели. Его представляют в виде дерева. Фактически, это дерево указывает на цели и на цели, от которых зависит вышестоящая цель. Пример: | ||
+ | * Стать самым крупным поставщиком мебели в Европе. | ||
+ | ** Привлекать заказчиков | ||
+ | ** Делать так, чтобы те, кто купили, купили ещё | ||
+ | |||
+ | Таким образом,, равзбиваем цели на подцели, выстраиваем зависимости... | ||
+ | |||
+ | Атрибуты цели: | ||
+ | * У каждой цели должно быть имя. Чтобы было понятно, о чём цель. Например, «Цель №1» не является хорошим именем, лучше названия из примера. | ||
+ | * Караткое описание | ||
+ | * Требуемые значения, то есть значения показателей, которые являются макс., при достижении которых цель считается достигнутой. Например, цель «стать самым крупным пост. в Европе», то это равно иметь больше всех филиалов в Европе. | ||
+ | * Текущее значение --- что уже есть | ||
+ | * Единица измерение --- штуки заказчиков, штуки денег | ||
+ | * Срок реализации | ||
+ | * Приоритет | ||
+ | |||
+ | Каждая цель должна быть связана с неким бизнес-процессом, который обеспечивает дост. данной цели. В противном случае, никаких способов дост. цели иметь не будем. | ||
+ | |||
+ | Второе лицо в рамках модели разработки ---- бизнес-разработчик. Описывате б-п, ищет исп. и сущности, уточняет исп. и сущности. Результом его деятельности являются: | ||
+ | * Совокупность бизнес-акторов. Для каждого б-а составляется его описание | ||
+ | * Совок б-п | ||
+ | * Совок реализацийц б-п | ||
+ | * Совок бизнес-исполнителей | ||
+ | * Сущности | ||
+ | * Описнаие бизнес-систем | ||
+ | * Описание бизнес-событий | ||
+ | |||
+ | Что осущ. бизнес-разработчик. Если он ведёт процесс вцелом, то это может быть один человек, в большой компании это может быть отдельный человек, может быть отдельный человек для отдельных разделов. | ||
+ | |||
+ | Бизнес-разраб строит свой кусочен бизнес-модели, который после объекд бизнес-разщлделов в бизм-модель будет единым целым, созд. разными людьми. Кроме того, он должен промоделировать бизнес-usecase, ... | ||
+ | |||
+ | Бизнес-моделирование: возможные пути: | ||
+ | * Может осущ. в два приёма. Если орг. сложная, если рахрабю. не имею.т опыта работа в данной сфере, они могут произвести предв. итерацию, построить предв. модель. Может быть сделана предв. оценка бизнеса, сделано погр. в этот бизнес. Ели бролее опытные разраб могут не делать предв. итераиции. | ||
+ | * В нек. прилож нет необх. уделять внимание бизнес-проц., достаточно бывает выделить бизнес-объекты. В этом случае проходим по правой ветке и б-м заканчивается. | ||
+ | * Если решено провести полный б-анрализ, то параллельбно три ветки | ||
+ | ** Составление модели как есть | ||
+ | ** Составление модели как будет | ||
+ | ** Выявление тех мест, в которых наша будущая бизнес-система будет участвовать | ||
+ | |||
+ | Если посмотреть на как будет? | ||
+ | * Выделяются бизнесо-проц | ||
+ | * Происходит их уточнение | ||
+ | * Модель бизнес-объектов (проект, реализ бизнеесо-процессов) | ||
+ | * Критически смотрим на то, что получилось, структурируем, унифиц. те | ||
+ | лементы, может разные в один, удалить лишнее, добавить. Это заверш. пересмотр. получ. модели | ||
+ | |||
+ | Если посм., как связаны дейст. бизнес-аналитика и бизнес-проектировщика, можно сделать такую картинку: | ||
+ | * Бизнес-аналитик составляет ... бизн-процессы | ||
+ | * Потом б-проект готовит описание б-п это для того, чтобы потм разбить б-модель, перестроить | ||
+ | * Помимо опис, б-проект выделяет исп. и бизнес-сущности | ||
+ | * Появляется третье лицо, реценхент, он должен посмотреть на то, что ба и б-п наработали, и результатом его ревью явл. его либо какие-то изменения, либо подсчитанные характеристики. | ||
+ | |||
+ | Мы переходим к двум моделям, которые соть. вместе с документами разными б-м. | ||
+ | * Модель бизнес процессо. В терминал ролей (business-actor) и потребностей. | ||
+ | |||
+ | B-actor | ||
+ | * В UML business-actor изображается как человечек с гвоздём в голове | ||
+ | * Это некое дейст. лицо в нашей орг (поставщики, партнёры, органы власти) | ||
+ | * Если мы проводим некие границы орг., то внешщние подразделения также оформ. как b-actors и ... | ||
+ | * Орг. представляется как чёрноящик, а вокруг заинтересованные лица, кторые учавствуют и необх. для того, чтобы орг функционировала | ||
+ | |||
+ | Business-usecase | ||
+ | * Овал с вбитым в бок гвоздём | ||
+ | * Описание посл. действий, приносящих ощутимый результат конкретному дейст. лиц (b-actor'у) | ||
+ | |||
+ | Разница мезду actor и b-actor, и usecase. когда имеется в виду actor, то имеется в виду пользователь нашей прогр. системы или внеш. программа. Когда b-actor, то имеется в виду пользователь организации. Как рпавило, рамки организации шире рамок системы. | ||
+ | |||
+ | Business usecase для регистрации пасс. в аэропорту: | ||
+ | |||
+ | Помоимо рисования моделей, объёмное время занимает написание business-usecases. | ||
+ | * Наименование | ||
+ | * краткое описание | ||
+ | * Цели | ||
+ | * результаты | ||
+ | * Сценарии событий | ||
+ | ** Основной сценарий --- когда всё хорошо | ||
+ | ** Альтернативные сценарии --- когда есть ошибки или затруднения | ||
+ | * Специальные требование (сколько времени занимает, какова макс. стоимость, ресурсоёмкость) | ||
+ | * Расширения, в которых опис. искл. ситукации | ||
+ | * Связи данного б-процесса с другими б-просцессами и действ. лицами | ||
+ | * Также вкл. диаграмы деятельности | ||
+ | |||
+ | Пример: | ||
+ | фото_1 | ||
+ | |||
+ | Структуризация модели: указание связи межд. действ. лицами и б-проццессами: | ||
+ | ... | ||
+ | |||
+ | Если у двух б-процессов выявл. общая часть, то экономнее выделить её в абстрактный бизнес процесс, он же явл. подчинённым, и будет включён в юизнес-просессы, в которых он учавствует. | ||
+ | |||
+ | Пример: оформить багаж. | ||
+ | |||
+ | Другой тип связи --- расширение. Это значит, что некий другой процесс явл. более навороченным вариантом исходного. | ||
+ | |||
+ | Пример: оформить пассажира --- оформить пассажира на прямой рейс | ||
+ | |||
+ | Связи обобщения вариантов использования. | ||
+ | |||
+ | Пример: оформить багаж: оформить обычный багаж, оформить ручную кладь, оформить ... . Тогда описываются три, а в обобщённом только ссылаются. | ||
+ | |||
+ | Общая модель: фото_» | ||
+ | |||
+ | Диаграма деятельности. Это граф, эл-тами которого являются деятельности. Кроме того, есть псевдоузлы --- начальный и концевой. Можно рассм. диагр. деят. как блок-схему. | ||
+ | |||
+ | Здесь мы рассм. сразу три сценария регистрации пассажира на рейсе (см. фото_3). | ||
+ | |||
+ | Диаграмы хороши тем, что позв. взглянуть не на отдельный сценарий, а на совок. сценариев. | ||
+ | |||
+ | Модель бмизнес-анализа. МБА описывает реализацию БП. | ||
+ | |||
+ | Исполнитель (Business worker). Это некая абстракция какой-то должности, человека или программы, занятые в БП. Они осущ. какую-то активную деятельность. В ходе свей деялетльности BW оперируют бизнес-сущностями. Сама по себе БС действий не инициирует, а явл объектом действий со стороны исполнителя. | ||
+ | |||
+ | Примеры бизнес-сущностей: ... | ||
+ | |||
+ | |||
+ | Мезду бизнес-сущн. могут быть установлены связи обобщения. Для б-сущностей могут быть диаграмы сост, показывающие, как могут меняться сущности в процессе. | ||
+ | |||
+ | Типичный пример модели бизнес-объектов: диаграмма классов. | ||
+ | |||
+ | Другой способ реализации use-cases: диаграммы последовательности. | ||
+ | |||
+ | Действия, которые осущ. исп., являются его обязанностями. Они отображаются на диаграмме business object в виде операций. | ||
+ | |||
+ | Бизнес-разраб. также опред. бизнес-событие. Б-событие может быть чем-то таким, что может повлиять на процесс, и что может повлиять на реакцию. Например, какой-то товар закончился/осталось его мало на складе. В таком случае, он моделируется как класс со стереотипом бизнес-событие, и указывается, что собюытие связано с сущностью продукт. На диаграммах моделей бизнес-объектов могут быть указаны зависимости исполнителей от бизнес-событий. В частности, кто посылает, кто принимает. Напр., кладовщик может обнаружить, что товара мало осталось, и может обратиться к ответственному лицу с тем, чтобы пооплнить запасы продукта. | ||
+ | |||
+ | == Категории Бизнес-правил == | ||
+ | |||
+ | Всего выделяют два вида правил: | ||
+ | * Ограничения | ||
+ | ** Упр. воздействия и реакции на воздействия** Предусл. и постусл. | ||
+ | ** Структурные ограничения | ||
+ | * Правила вывода и вычисл. правила. Расск. о том, как устанавливается тот или иной факт. Напр, как определить, что клиент хороший --- если он выплачивает вовремя все свои счета. Вычислительные правила: цена_нетто = цена_продукта * (1 + процент_налога) | ||
+ | |||
+ | {{ООАиП}} | ||
+ | {{Lection-stub}} |
Текущая версия
Предыдущая лекция | Следующая лекция
[править] Моделирование б.-м. Rational Unified Process
Моделирование происходит в терминах
- исполнителей
- работ
- рабочие продукты
Исполнители при помощи инструментов выполн. работы, приводящие к раб. прод.
Моедли:
- Business Use-case model
- Business object(?) model
Аналитик является осн. дейст. лицом, он возглавляет и проводит бизнес-моделир.
- Видение бизнеса --- документ, в котором указывается, для чего мы проводим ..., какие цели
- Оценка организации
- Бизнес-правила --- условия, которые должны соблюдаться обязательно (напр, налогообложение)
- Бизнес-цели --- те задачи, которые ставит перед собой организация, напр., стать самым крупным продавцом бубликов в России
- Глоссарий деятельности, глоссарий бизнеса --- основные термины, исп. в бизнесе
- Моедль бизнес-процессов, модель бизнес-объектов
- Дополнительная спецификация. Цель дополнить остальные документвы, описать вещи, которые не были описаны всеми другими документами. Примером такого рода положений,Ю которые могут войти в доп. спецификацию может быть установление неокего стандарта. Например, если вы азрабатываете ПО для супермаркета, то будете готовы к тому, что вес будет в фунтах, а длина в футах, а в европе метрическая система. Также, другие вещи, связанные с локальным, региональным, национальным доказательством, отражаются там.
Бизнес-аналитик определчяет бизнес-цели. Его представляют в виде дерева. Фактически, это дерево указывает на цели и на цели, от которых зависит вышестоящая цель. Пример:
- Стать самым крупным поставщиком мебели в Европе.
- Привлекать заказчиков
- Делать так, чтобы те, кто купили, купили ещё
Таким образом,, равзбиваем цели на подцели, выстраиваем зависимости...
Атрибуты цели:
- У каждой цели должно быть имя. Чтобы было понятно, о чём цель. Например, «Цель №1» не является хорошим именем, лучше названия из примера.
- Караткое описание
- Требуемые значения, то есть значения показателей, которые являются макс., при достижении которых цель считается достигнутой. Например, цель «стать самым крупным пост. в Европе», то это равно иметь больше всех филиалов в Европе.
- Текущее значение --- что уже есть
- Единица измерение --- штуки заказчиков, штуки денег
- Срок реализации
- Приоритет
Каждая цель должна быть связана с неким бизнес-процессом, который обеспечивает дост. данной цели. В противном случае, никаких способов дост. цели иметь не будем.
Второе лицо в рамках модели разработки ---- бизнес-разработчик. Описывате б-п, ищет исп. и сущности, уточняет исп. и сущности. Результом его деятельности являются:
- Совокупность бизнес-акторов. Для каждого б-а составляется его описание
- Совок б-п
- Совок реализацийц б-п
- Совок бизнес-исполнителей
- Сущности
- Описнаие бизнес-систем
- Описание бизнес-событий
Что осущ. бизнес-разработчик. Если он ведёт процесс вцелом, то это может быть один человек, в большой компании это может быть отдельный человек, может быть отдельный человек для отдельных разделов.
Бизнес-разраб строит свой кусочен бизнес-модели, который после объекд бизнес-разщлделов в бизм-модель будет единым целым, созд. разными людьми. Кроме того, он должен промоделировать бизнес-usecase, ...
Бизнес-моделирование: возможные пути:
- Может осущ. в два приёма. Если орг. сложная, если рахрабю. не имею.т опыта работа в данной сфере, они могут произвести предв. итерацию, построить предв. модель. Может быть сделана предв. оценка бизнеса, сделано погр. в этот бизнес. Ели бролее опытные разраб могут не делать предв. итераиции.
- В нек. прилож нет необх. уделять внимание бизнес-проц., достаточно бывает выделить бизнес-объекты. В этом случае проходим по правой ветке и б-м заканчивается.
- Если решено провести полный б-анрализ, то параллельбно три ветки
- Составление модели как есть
- Составление модели как будет
- Выявление тех мест, в которых наша будущая бизнес-система будет участвовать
Если посмотреть на как будет?
- Выделяются бизнесо-проц
- Происходит их уточнение
- Модель бизнес-объектов (проект, реализ бизнеесо-процессов)
- Критически смотрим на то, что получилось, структурируем, унифиц. те
лементы, может разные в один, удалить лишнее, добавить. Это заверш. пересмотр. получ. модели
Если посм., как связаны дейст. бизнес-аналитика и бизнес-проектировщика, можно сделать такую картинку:
- Бизнес-аналитик составляет ... бизн-процессы
- Потом б-проект готовит описание б-п это для того, чтобы потм разбить б-модель, перестроить
- Помимо опис, б-проект выделяет исп. и бизнес-сущности
- Появляется третье лицо, реценхент, он должен посмотреть на то, что ба и б-п наработали, и результатом его ревью явл. его либо какие-то изменения, либо подсчитанные характеристики.
Мы переходим к двум моделям, которые соть. вместе с документами разными б-м.
- Модель бизнес процессо. В терминал ролей (business-actor) и потребностей.
B-actor
- В UML business-actor изображается как человечек с гвоздём в голове
- Это некое дейст. лицо в нашей орг (поставщики, партнёры, органы власти)
- Если мы проводим некие границы орг., то внешщние подразделения также оформ. как b-actors и ...
- Орг. представляется как чёрноящик, а вокруг заинтересованные лица, кторые учавствуют и необх. для того, чтобы орг функционировала
Business-usecase
- Овал с вбитым в бок гвоздём
- Описание посл. действий, приносящих ощутимый результат конкретному дейст. лиц (b-actor'у)
Разница мезду actor и b-actor, и usecase. когда имеется в виду actor, то имеется в виду пользователь нашей прогр. системы или внеш. программа. Когда b-actor, то имеется в виду пользователь организации. Как рпавило, рамки организации шире рамок системы.
Business usecase для регистрации пасс. в аэропорту:
Помоимо рисования моделей, объёмное время занимает написание business-usecases.
- Наименование
- краткое описание
- Цели
- результаты
- Сценарии событий
- Основной сценарий --- когда всё хорошо
- Альтернативные сценарии --- когда есть ошибки или затруднения
- Специальные требование (сколько времени занимает, какова макс. стоимость, ресурсоёмкость)
- Расширения, в которых опис. искл. ситукации
- Связи данного б-процесса с другими б-просцессами и действ. лицами
- Также вкл. диаграмы деятельности
Пример: фото_1
Структуризация модели: указание связи межд. действ. лицами и б-проццессами: ...
Если у двух б-процессов выявл. общая часть, то экономнее выделить её в абстрактный бизнес процесс, он же явл. подчинённым, и будет включён в юизнес-просессы, в которых он учавствует.
Пример: оформить багаж.
Другой тип связи --- расширение. Это значит, что некий другой процесс явл. более навороченным вариантом исходного.
Пример: оформить пассажира --- оформить пассажира на прямой рейс
Связи обобщения вариантов использования.
Пример: оформить багаж: оформить обычный багаж, оформить ручную кладь, оформить ... . Тогда описываются три, а в обобщённом только ссылаются.
Общая модель: фото_»
Диаграма деятельности. Это граф, эл-тами которого являются деятельности. Кроме того, есть псевдоузлы --- начальный и концевой. Можно рассм. диагр. деят. как блок-схему.
Здесь мы рассм. сразу три сценария регистрации пассажира на рейсе (см. фото_3).
Диаграмы хороши тем, что позв. взглянуть не на отдельный сценарий, а на совок. сценариев.
Модель бмизнес-анализа. МБА описывает реализацию БП.
Исполнитель (Business worker). Это некая абстракция какой-то должности, человека или программы, занятые в БП. Они осущ. какую-то активную деятельность. В ходе свей деялетльности BW оперируют бизнес-сущностями. Сама по себе БС действий не инициирует, а явл объектом действий со стороны исполнителя.
Примеры бизнес-сущностей: ...
Мезду бизнес-сущн. могут быть установлены связи обобщения. Для б-сущностей могут быть диаграмы сост, показывающие, как могут меняться сущности в процессе.
Типичный пример модели бизнес-объектов: диаграмма классов.
Другой способ реализации use-cases: диаграммы последовательности.
Действия, которые осущ. исп., являются его обязанностями. Они отображаются на диаграмме business object в виде операций.
Бизнес-разраб. также опред. бизнес-событие. Б-событие может быть чем-то таким, что может повлиять на процесс, и что может повлиять на реакцию. Например, какой-то товар закончился/осталось его мало на складе. В таком случае, он моделируется как класс со стереотипом бизнес-событие, и указывается, что собюытие связано с сущностью продукт. На диаграммах моделей бизнес-объектов могут быть указаны зависимости исполнителей от бизнес-событий. В частности, кто посылает, кто принимает. Напр., кладовщик может обнаружить, что товара мало осталось, и может обратиться к ответственному лицу с тем, чтобы пооплнить запасы продукта.
[править] Категории Бизнес-правил
Всего выделяют два вида правил:
- Ограничения
- Упр. воздействия и реакции на воздействия** Предусл. и постусл.
- Структурные ограничения
- Правила вывода и вычисл. правила. Расск. о том, как устанавливается тот или иной факт. Напр, как определить, что клиент хороший --- если он выплачивает вовремя все свои счета. Вычислительные правила: цена_нетто = цена_продукта * (1 + процент_налога)
Объектно-ориентированные анализ и проектирование
01 02 03 04 05 06 07 08 09 10 11 12 13 14 15
Календарь
Ноябрь
| 07 | 08 | 14 | ||
Октябрь
| 05 | 12 | 19 | 26 | |
Ноябрь
| 02 | 09 | 16 | 23 | 30 |
Декабрь
| 07 | 14 | 21 |