Бизнес-моделирование в UML (диаграмма прецедентов).

Модуль анализа реализуемости.

Назначение модуля: определение ускоренной оценки возможности реализации проекта разрабатываемой ИС в соответствии с выбранными требованиями.

Для проекта ИС этот модуль является первым шагом перед детальным исследованием ОУ, подразумевающим требования, СТ и СЛС.

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

Входы модуля: - входные данные, определяющие цель;

- выбранный вариант ИС для анализа реализуемости;

- договор об объеме исследований;

- документы, инициирующие проект;

- ссылки: ОС, ФС, ОУ.

Определение действий:

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

- установление соответствия между планируемыми ресурсами и предполагаемыми расходами;

- оценка возможности создания логической и физической БД по исходным данным;

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

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

- отчет по анализу реализуемости;
- описание действий по анализу реализуемости.

Выходы: - анализ реализуемости (ТЭО ИС).

UML Назначение. Свойства

UML является унифицированным стандартом для создания чертежей ПО.

С помощью UML можно:

- визуализировать;

- специфировать;

- конструировать;

- документировать артефакты программных систем;

Артефакт- исскуственные технические объекты(документ).

UML пригоден для моделирования ИС, WEB-приложений, систем реального времени.

3-и основных элемента:

1.Базовые строительные блоки

2.правила определяющие как эти блоки могут взаимодействовать между собой.

3.Общие механизмы языка.

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

Свойства UML:

1. UML язык визуализации. Программист анализируя проблему выбирает короткий путь к написанию программы.

В этом случае подразумевается:

-получение концептуальной модели.

- учет аспектов программы, не выходящей за границы текстового языка программирования.

UML решает проблему облегчения взаимодействия различных Р т.к. UML –это графический язык с определенной семантикой. Это позволяет однозначно интерпретировать любую модель другим Р.

2. UML язык специфицирования. Специфицирования обеспечит разработку точных, понятных и полных моделей по анализу проектированию, реализация.

3. UML язык конструирования т.е. разработки (структуры, компонентов, элементов).

 UML позволяет преобразовать модель в программный код (прямое проектирование).

 UML может преобразоваться на стандартные языки: java, c++ и т.д.

4. UML язык документирования. Позволяет формализовать:

- требования к системе

- описывать архитектуру системы

- описывать проект

- разрабатывать программный код

- разрабатывать тесты, прототипы, версии.

Документирование осуществляется как текстовыми так и графическими описаниями.

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

SSADM-технологии.

SSADM (Structured System Analysis and Design Method) - британский cтандарт анализа и разработки автоматизированных систем.

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

В SSADM применяется нисходящий подход к построению интег­рированных функциональных, информационных и событийных моделей. При моделировании, функций используются классические DFD (вклю­чающие только базовые объекты: процесс, поток данных, хранилище дан­ных, внешнюю сущность) с миниспецификациями на структурированном естественном языке. Моделирование данных осуществляется с использо­ванием нотации LDS (Logical Data Structure), являющейся диалектом ER-модели. Для событийного моделирования используются диаграммы исто­рии жизни сущностей ELN (Entity Life History), поддерживающие индика­торы состояний, события с привязанными к ним действиями, возможность задавать последовательные, параллельные и итеративные конструкции, а также конструкции выбора.

Концептуальная модель UML.

Концептуальная модель UML состоит из 3-х основных элементов:

1. Строительные блоки.

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

3. Общие механизмы языка.

 

Сущность – это абстракция, которая является элементом модели.

Отношения связывают сущности.

Диаграммы обеспечивают представление взаимосвязей сущностей.

UML выделяет 4 типа сущностей:

1 – структурные

2 – поведенческие

3 – группирующие

4 – аннотационные

Структурные – это имена существительные в моделях на языке UML. Они представляют статические части модели.

Отношения бывают 4-х типов:

1 – зависимость

2 – ассоциация

3 – обобщение

4 – реализация

Зависимость – семантические отношения между двумя сущностями.

Ассоциация – структурное отношение, описывающее совокупность связей.

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

Реализация – семантические отношения между классификаторами, при котором 1-ый класс определяет контракт, а 2-ой гарантирует его выполнение.

Существуют разновидности этих отношений – вариации, устанавливающие уточнение, включение, расширение, трассировку…

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

Механизмы языка UML:

Спецификации

Дополнения

Принятое деление

Расширение.

Обобщенный модуль SSADM.

Разработчики SSADM для унификации ЖЦ ИС и процесса проектирования создали унифицированный модуль, определили его содержание, которое может быть адаптировано под каждый модуль.

.

Входы имеют 3 элемента: организационные полномочия, ссылки, входы.

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

Выходы: проектные решения; стандарты разработки; руководство; планы (проведения работ).

Организационные полномочия:

- договор на проведение исследований;

- документы, определяющие объем и содержание работ;

- исходные данные для выполнения работ.

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

- бизнес-процессы ОУ;

- бизнес-цели;

 - стратегия ОУ (в рамках ИС);

- рабочие документы по планированию стратегии;

- организационная структура ОУ;

- портфель проекта ИС (план).

Цель предусматривает получение конкретного результата проектирования по каждому модулю.

Краткое изложение цели подразумевает разработку структуры и функций ИС.

Участники: разработчик проекта, менеджеры, КП; определение их функций.

Продукты: проектные решения, документы.

Методы проектирования: 13 методов.

Действия участников – описываются действия каждого участника по проектированию.

Выходы описывают результат действий модуля и соответствующее руководство по его использованию.

RUP технология.

Rational Unified Process обеспечивает строгий подход к назначению задач и ответственности в пределах группы разработки.

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

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

Rational Unified Process - это управляемый процесс. Итерационный подход предполагает управление требованиями и управление изменениями.

Назначение Rational Unified Process состоит в создании и обслуживании моделей. Rational Unified Process фокусирует внимание не на создании большого количества бумажных документов, а на развитии и эксплуатации моделей - семантически богатых представлений программной системы при ее разработке.

Компоненты - это нетривиальные модули или подсистемы, которые выполняют конкретную функцию и могут быть смонтированы в строго очерченной архитектуре, типа Internet, CORBA, COM/DCOM, для которых появляется индустрия многократно используемых компонентов.

Rational Unified Process - это процесс с перестраиваемой конфигурацией. Никакой одиночный процесс не подходит для всех случаев разработки программного обеспечения.

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

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

Назначение прецендентов.

Прецеденты – это описание происходящих в ПрО процессов. Для формирования требований лучше всего определить прецеденты.

Прецедент (use case) - документ, описывающий последовательность событий. Они предоставляют описания и иллюстрируют требования.

 Различают прецеденты высоко уровня (high-level use case) (или бизнес-прецеденты) и развёрнутые прецеденты (expended use case).

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

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

Определим прецеденты для приложения терминала розничной торговли.

Покупатель	Покупка товара
	Возврат товара
Кассир	Выдача чека
	Работа с деньгами

Если такая взаимосвязь установл, то можно построить диагр прец-тов

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

Для формир прец-та необход иметь: 1.название прец-та; 2.исполнителей; 3.тип прец-та; 4.описан прец-та.

Выбор границы сис опред-ся целями исслед-ия

Если необход разраб-ть ПО, то устанавл связи субъектов во взаимодейств с аппаратно-программн обеспеч-ем

Если рассматр проблемы изменения стратегии ОУ (т.е. повышен конкурентоспособн-ти) то рассматр случ 2

После опред границ сис, осущ-ся ранжирование прец-тов

3 типа прец-та: 1.Основные – опис общ процессы (покупка тов). 2.Вторичные – опис уточняющие, редкие процессы (запрос на ассортимент тов). 3.Дополнительные- опис проц, не реализованные в сис

Бизнес-моделирование в UML (диаграмма прецедентов).

При моделир-ии использ-ся: -модель деловых прец-тов; -модель деловых объектов.

Модель дел прецедентов- опис процессы деловой сферы и их взаимодействия с внешн средой. Дан модель опис деловую сферу в 2х соотнош-иях: бизнес-прец-т; бизнес-субъект.

Бизнес-субъект представл роль, кот кто-то или что-то играет в дел сфере ОУ. Бизнес-субъект имеет имя. При этом необход устанавливать его взаимодействие с внешн средой.

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

Бизнес-прецедент – послед-ть действий, кот выполн в деловой сфере и привод к конечн рез-ту, имеющему значение для индивид-ного субъекта

Бизнес-прец-т моет опред то, что моет произойти в деловой сфере.

Бизнес-прец-т – строгая послед-ть действий

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

Для построен модели бизнес-прец-тов на осн обслед-ия объекта, необход осущ выявление фактов и данных ПрОбл

Для выявлен фактов примен 2 типа методов: -традиц; -современ.

К традиц относ: интервьюир-ие, анкетир-ие, наблюден, изучен док-ов.

К современ относ: прототипир-ие, приложение, быстрое приложение(RAD)

В моделир-ии использ:

Аналитик(работник) ведет и контролир поведение субъектов ОА при моделир-ии деловых проц-ов, устанавл границы моделир-ия (субъекты, деловые прецеденты)

---

Дата добавления: 2018-02-15; просмотров: 1517; Мы поможем в написании вашей работы!

Поделиться с друзьями:

---

---

Мы поможем в написании ваших работ!