Так мы это сделали в виде интересов ЗЛ
Может я и ошибаюсь, но предлагаю прочитать часть книги Унифицированный процесс, в которой рассказывается о бизнес-моделировании.
Стр. 144 русскоязычного издания
Несмотря на различие отправных точек, существуют шаги, которые можно сделать в большинстве случаев. Это позволяет нам предложить типовой рабочий процесс.
Такой рабочий процесс включает в себя следующие шаги, которые обычно не выполняются по отдельности
О Перечисление возможных требований.
О Осознание контекста системы.
О Определение функциональных требований.
О Определение нефункциональных требований.
....
Осознание контекста системы. Множество людей, вовлеченных в развитие программного обеспечения, являются специалистами в вопросах, имеющих отношение к программному обеспечению. Однако чтобы верно определить требования
и правильно сформировать систему, ключевые разработчики — в частности, архитектор и некоторые старшие аналитики — должны понимать контекст, в котором работает система.
Имеется по крайней мере два подхода к описанию контекста системы в форме, доступной для разработчиков программ: моделирование предметной области и бизнес-моделирование. Модель предметной области описывает важные понятия контекста как объекты предметной области. Предметная область при этом связывает эти объекты друг с другом. Идентификация и наименование этих объектов помогают нам разработать словарь терминов, который поможет каждому, кто работает над системой, лучше ее понимать. Впоследствии, когда мы будем проводить анализ и проектирование нашей системы, объекты предметной области помогут нам распознать некоторые классы. Как мы увидим далее, бизнес-модель может быть представлена как надмножество модели предметной области. Она содержит доменные объекты, и не только их.
Цель бизнес-моделирования состоит в описании процессов — существующих или воспринимаемых — для того, чтобы понять их. Бизнес-моделирование — единственная часть бизнес-инжиниринга, которую мы будем использовать в этой книге
[39]. Удовлетворимся замечанием, что бизнес-инжиниринг очень похож на бизнес-моделирование, но имеет своей целью также улучшение бизнес-процессов организации. Когда аналитики моделируют бизнес, они получают обширную информацию
о контексте программной системы и отражают ее в бизнес-модели. Бизнес-модель определяет, какие бизнес-процессы должна поддерживать система. Кроме идентификации вовлеченных в бизнес бизнес-объектов или объектов предметной области, бизнес-моделирование также устанавливает компетентности, необходимые для процессов: работников, их обязанности и действия, которые они должны выполнять.
Это знание является определяющим при идентификации вариантов использования.
Мы вскоре обсудим этот вопрос. Фактически подход бизнес-инжиниринга для определения требований при разработке бизнес-приложений является наиболее системным [39].
Архитектор и руководитель проекта совместно решают, ограничиться ли моделью предметной области или идти до конца и разрабатывать полную бизнес-модель, а может быть, не строить никакой модели вообще.
Понимание контекста системы с помощью бизнес-модели
Бизнес-моделирование — это способ разобраться в бизнес-процессах организации. Но что если вы работаете с системой, которая не имеет никакого отношения к тому, что большинство людей понимает под словом «бизнес»? Например, что мы
должны делать при разработке сердечного электростимулятора, антиблокировочной системы торможения для автомобиля, контроллера фотоаппарата или системы беспроводной связи? В этом случае мы по-прежнему можем создавать бизнес-
модели этих систем, определяющие программную систему, которую мы собираемся разрабатывать. Эта система (часть человеческого органа, часть автомобиля, фотоаппарата, переключатель) — будет «бизнес-системой» для встроенного программного обеспечения. Это будет заметно по высокоуровневым вариантам использования системы, которые мы кратко рассмотрим. Наша цель — выделение вариантов использования программного обеспечения и бизнес-сущностей, которые будут поддерживаться программным обеспечением. Для того чтобы сделать это, мы должны углубиться в моделирование ровно настолько, насколько нужно, чтобы разобраться в контексте. Результатом этой деятельности будет модель предметной области, порожденная нашим пониманием функционирования изученной «бизнес-системы».
Технически бизнес-моделирование поддерживается двумя типами моделей UML: моделью вариантов использования и объектной моделью [57]. Обе они определены в бизнес-расширении UML.
Как разработать бизнес-модель
Бизнес-модель разрабатывается в два приема. Это происходит следующим образом.
1. Разработчики бизнес-модели должны создать бизнес-модель вариантов использования, идентифицирующую актантов, и бизнес-варианты использования, в которых участвуют эти актанты. Эта бизнес-модель вариантов использования позволит разработчикам модели лучше понять, какой результат приносит бизнес его участникам.
2. Разработчики модели должны разработать объектную бизнес-модель, состоящую из сотрудников, бизнес-сущностей и рабочих модулей, которые совместно реализуют бизнес-варианты использования^ С этими объектами связываются бизнес-правила и другие нормы бизнеса. Цель этого шага состоит в том, чтобы создать сотрудников, бизнес-сущности и рабочие модули, которые реализуют бизнес-варианты использования настолько эффективно, насколько это возможно — то есть быстро, точно и недорого.
Бизнес-моделирование и моделирование предметной области похожи друг на друга. Фактически, мы можем считать моделирование предметной области упрощенным вариантом бизнес-моделирования, в котором мы сосредоточиваемся исключительно на «предметах», то есть классах предметной области или бизнес-объектах, с которыми работают сотрудники. Это означает, что классы предметной области и бизнес-объекты — очень близкие понятия, и мы будем использовать попеременно то один из этих терминов, то другой.
Однако между бизнес-моделированием и моделированием предметной области имеются серьезные различия, которые говорят в пользу выполнения более формальной процедуры бизнес-моделирования:
О Классы предметной области возникают из базы знаний, составленной несколькими специалистами по проблемной области, или просто из общих соображений (например, из знания о других классах предметной области, спецификации требований и т. п.), относящихся к похожим на нашу системам. Бизнес-объекты же выделяют путем опроса клиентов бизнеса, вычленения бизнес-вариантов использования и последующего выбора объектов. При подходе, используемом в бизнес-моделировании, включение сущности в бизнес-модель должно оправдываться использованием этой сущности в бизнес-варианте использования.
Эти различные подходы обычно приводят к разным наборам классов, ассоциаций, атрибутов и операций. При моделировании предметной области можно проследить путь от классов назад к опыту специалистов по проблемной области. При бизнес-моделировании можно проследить потребность в каждом элементе модели назад к клиентам.
О Классы предметной области содержат множество атрибутов, но обычно содержат мало операций или не содержат их вовсе. Для бизнес-объектов это не так. Бизнес-моделирование позволяет идентифицировать не только сущности, но и всех сотрудников, которые участвуют в реализации бизнес-варианта использования, используя эти сущности. Кроме того, при бизнес-моделировании мы определяем способы использования сотрудниками этих сущностей посредством операций,
которые должна позволять выполнять каждая сущность. Эти операции также будут получены из требований и могут быть отслежены до клиентов.
О Список сотрудников, обнаруженных при бизнес-моделировании, используется как исходная точка для определения первоначального набора актантов и вариантов использования для информационной системы, которую мы создаем. Это позволяет нам отслеживать каждый вариант использования в информационной системе через сотрудников и бизнес-варианты использования назад, до клиентов.
Мы займемся этим в главе 7. Кроме того, как было описано в главе 3, каждый вариант использования может быть прослежен до составляющих систему элементов. Итак, мы можем заключить, что комбинация бизнес-моделирования и подхода к разработке программного обеспечения, предлагаемого Унифицированным процессом, позволят нам непрерывно отслеживать потребности клиента—в бизнес-процессах, сотрудниках и вариантах использования и коде программы.
При использовании же одной модели предметной области нет никаких очевидных способов отследить требования в промежутке между моделью предметной области и вариантами использования системы.
Выполнение примера описания требований для ИС "Аттестации Студентов"