Конспект по курсу. Объектно ориентированный анализ и проектирование (1133667), страница 10

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 10)

Модель бизнес-анализа – это объектная модель, элементами которой являются исполнитель (business worker) и бизнес-сущность (business entity). Эта модель описывает внутреннее устройство бизнес-процессов с точки зрения структуры и поведения. Но из этой модели нельзя понять деловое окружение предприятия (что описано моделью бизнес-процессов).

Business worker –исполнитель, действующий в рамках бизнес-системы. В отличие от делового действующего лица исполнитель работает на предприятии. Он имеет связи взаимодействия с другими исполнителями и манипулирует бизнес-сущностями, участвуя в реализациях бизнес-процессов. Представляется на диаграммах как класс со стереотипом «business worker».

Деловая сущность (Business entity) – это ресурс (информационный, материальный, финансовый и т. д.), не инициирующий никаких взаимодействий, он может участвовать во многих реализациях различных бизнес-процессов и является предметом различных манипуляций со стороны исполнителей. На диаграммах представлен классом со стереотипом «business entity».

Модель бизнес-анализа включает в себя диаграммы разных видов:

• д
  иаграммы классов, отражающих структурные соединения, из которых следует как взаимосвязаны исполнители и деловые сущности (из примера следует, что исполнители двух разных классов могут взаимодействовать между собой, что исполнитель первого класса имеет доступ к деловым сущностям багаж и Багажная бирка, а исполнитель второго класса – только к Багажу, что сущности связаны между собой.);

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

• д иаграммы состояний для моделирования жизненного цикла экземпляров того или иного исполнителя или экономического ресурса, т. е. деловой сущности, (в примере видно, что экземпляр деловой сущности Багаж меняет свои внутренние состояния, принимая сообщения от исполнителей, изображенные как события «Поставлен на весы», «Прикреплена бирка» и т. д.);

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

Х
од бизнес-моделирования в целом отображает следующая диаграмма деятельности:

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

• видение бизнеса;

• оценка организации.

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

Б
изнес правила представляют собой ограничения, которые должны обязательно выполняться в ходе деловых процессов. Формулировки бизнес-правил составляют специальный документ – Описание бизнес-правил. Каждое бизнес-правило должно так или иначе прослеживаться на диаграммах бизнес-модели. Например, бизнес-правило: Цена нетто = цена продукта * (1 + процент налога / 100) задает условие на структурные связи в модели бизнес-анализа, а именно: исполнитель, ответственный за расчет цены нетто должен иметь возможность получить все подставляемые в формулу значения. Соответствующая диаграмма классов из модели бизнес-анализа должна быть проверена, и при необходимости на нее должны быть добавлены дополнительные связи. На представленной диаграмме видны «маршруты» получения

• цены продукта (Заказ ->Продукт.цена продукта);

• процента налога (Профиль клиента -> Профиль региона. процент налога).

В связи с большим количеством типов возможных бизнес-правил вводят их классификацию:

• правила-ограничения:

  • управляющие воздействия и реакции на воздействия (например, бизнес-правило: «При отмене заказа, если он еще не доставлен, то его следует отметить как закрытый », здесь отмена заказа – управляющее воздействие, а закрытие отмененного заказа – реакция);

  • операционные ограничения или предусловия и постусловия (например, бизнес-правило: «Доставить заказ клиенту только при наличии адреса доставки » устанавливает предусловие для операции доставки заказа);

  • структурные ограничения (например, бизнес-правило «Заказ включает в себя по крайней мере одну позицию», устанавливает мощность связи между классами деловых сущностей Заказ и Позиция заказа, такое бизнес-правило дополнительно отображается на диаграмме классов из модели бизнес-анализа в виде показателей мощности на полюсах ассоциации, соединяющей упомянутые сущности);

• правила вывода и вычислительные правила (например, рассмотренная выше формула расчета цены).

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

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

Реализация бизнес-процесса – кооперация со стереотипом «business use case realization»). описывает структуру бизнес-классов (исполнителей и деловых сущностей) и взаимодействие их экземпляров (бизнес-объектов) при реализации конкретного бизнес-процесса. Другими словами, диаграммы классов, диаграммы взаимодействия, относящиеся к одному бизнес-процессу объединяются в одну реализацию бизнес-процесса.

Бизнес-система – пакет со стереотипом «business system» – объединяет относящиеся к одному подразделению организации исполнителей и экономические ресурсы (деловые сущности), относящиеся к ведению подразделения, а также связанные с ними диаграммы состояний. Если какая-либо реализация бизнес-процесса осуществляется целиком в рамках подразделения, в соответствующую бизнес-систему помещается реализация этого бизнес-процесса (кооперация). Большая бизнес-система может быть разделена на части – бизнес-системы подчиненных отделов подразделения.

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

Типовые решения в области бизнес-моделирования оформляются в виде бизнес-образцов (паттернов). Описание образца содержит имя, описание решаемой проблемы и ее контекста, решение (модель и ее описание), результаты (следствия применения образца). Образцы бизнес-моделирования представляются в виде коопераций со стереотипом «business pattern» и включают:

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

• динамическое представление – диаграммы деятельности или взаимодействия.

Пример. Бизнес-образец «Занятость».

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

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

Это структурный бизнес-образец, в нем отсутствует динамическое представление. Классы-участники: Employee Profile – данные о служащем; Organization Profile – данные об организации; Employment – наем служащего (период занятости); Position – должность; Position Assignment – занимаемая служащим должность.

Литература к лекции 5

1. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. – М.: Финансы и статистика, 2005. – Глава 3.

2. Джонстон С. UML-профиль для моделирования бизнес-систем. 2004. – http://www.ibm.com/developerworks/ru/library/5167/ (обратите внимание, что некоторые пиктограммы перепутаны).

Лекция 6. ОПРЕДЕЛЕНИЕ ТРЕБОВАНИЙ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

Требование – это условие, которому должно удовлетворять программное обеспечение, или свойство, которым оно должно обладать, чтобы:

• удовлетворить потребность пользователя в решении некоторой задачи;

• удовлетворить требования контракта, спецификации или стандарта.

Спецификация требований к ПО является основным документом, определяющим план разработки ПО. Все требования, указанные в спецификации, делятся на функциональные и нефункциональные. Функциональные требования определяют действия, которые должна выполнять система, без учета ограничений, связанных с ее реализацией. Тем самым функциональные требования определяют поведение системы в процессе обработки информации. Нефункциональные требования не определяют поведение системы, но описывают атрибуты системы или атрибуты системного окружения. Можно выделить следующие типы нефункциональных требований:

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

• требования к производительности, которые накладывают ограничения на функциональные требования, задавая необходимую эффективность использования ресурсов, пропускную способность и время реакции;

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

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

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

Методы выявления требований:

• собеседование (интервьюирование);

• анкетирование;

• проведение совещаний;

• сессии по выявлению требований (мозговой штурм);

• раскадровка (storyboard);

• создание и демонстрация работающих прототипов;

• ролевые игры.

В ходе проекта работа с требованиями делится на следующие этапы:

• Определение типов требований и групп участников проекта, работающих с ними.

• Первичный сбор требований, их классификация и занесение в базу данных требований.

• Использование базы данных требований для управления проектом.

Любое требование в базе проекта имеет следующие атрибуты:

• Приоритет (высокий, средний, низкий).

• Статус (предложено, одобрено, реализовано, верифицировано).

• Стоимость реализации (высокая, средняя, низкая – или числовое значение).

• Сложность реализации (высокая, средняя, низкая).

• Стабильность (высокая, средняя, низкая).

• Ответственный исполнитель.

Хороший набор требований удовлетворяет следующим показателям качества (IEEE 830-1998 «Recommended Practice for Software Requirements Specifications»):

• Корректность или адекватность (соответствие реальным потребностям).

• Недвусмысленность (однозначность понимания).

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

• Непротиворечивость (согласованность между различными элементами).

• Упорядоченность по приоритету и стабильности.

• Проверяемость (выполнение каждого требования нужно должно проверяться достаточно эффективным способом – непроверяемые требования должны быть удалены из рассмотрения или сведены к проверяемым вариантам).

• Модифицируемость (оформление в удобных для внесения изменений структуре и стилях).

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

Выявленные требования к ПО оформляются в виде ряда документов и моделей. К основным документам, регламентируемым технологией Rational Unified Process, относятся:

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

• Словарь предметной области (глоссарий) – определяет общую терминологию для всех моделей и описаний требований к системе. Глоссарий предназначен для описания терминологии предметной области и может быть использован как словарь данных системы.

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

Функциональные требования к системе моделируются и документируются с помощью вариантов использования (use case). Вариант использования (use case) – связный элемент функциональности, предоставляемый системой при взаимодействии с действующими лицами. Действующее лицо (actor) – роль, обобщение элементов внешнего окружения системы, ведущих себя по отношению к системе одинаковым образом.

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

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

• Имя – цель в виде краткой активной глагольной фразы

• Контекст использования – более длинное описание цели

• Область действия

• Основное действующее лицо

• Участники и интересы

• Предусловие (определяет, выполнение какого условия гарантирует система перед тем, как разрешить запуск варианта использования)

• Минимальные гарантии (наименьшие обещания системы участникам, в частности, когда цель основного действующего лица не может быть достигнута)

• Гарантии успеха (или постусловие – postcondition – устанавливает, что интересы участников удовлетворяются по успешном завершении варианта использования в конце основного сценария)

• Триггер (событие, которое запускает вариант использования)

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

• Расширения (запускаются при возникновении определенного условия, содержат последовательность шагов, описывающих, что происходит при этом условии, и заканчивается достижением цели или отказом от неё)

• Список изменений в технологии и данных

• Вспомогательная информация

Существуют четыре уровня точности описания вариантов использования, расположенные по степени повышения точности:

• Действующие лица и цели (перечисляются действующие лица и все их цели, которые будет обеспечивать система). На этом уровне определяется границы системы, контекст в котором она работает. Действующее лицо может: быть активным, посылая запросы в систему; быть пассивным, получая данные от системы. Его роль может исполнять человек – пользователь, устройство, внешняя программная система, время (в случае если функциональность запускается по расписанию), температура или другое свойство состояния окружающей среды, играющее роль триггера.

• Краткое изложение варианта использования (в один абзац) или основной поток событий (без анализа возможных ошибок).

• Условия отказа (анализ мест возникновения возможных ошибок в основном потоке событий).

• Обработка отказа (написание всех альтернативных потоков событий).

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

Характеристики

Список файлов лекций