Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
130273_03FB1_shpory_po_obektno_orientirovannomu....doc
Скачиваний:
46
Добавлен:
24.12.2018
Размер:
650.24 Кб
Скачать
  1. Цели и задачи моделирования бизнес – процессов в руп

Цели моделирования бизнес-процессов обычно формулируются следующим образом:

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

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

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

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

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

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

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

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

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

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

Созданная модель является лучшим путеводителем по системе, ее изучение – лучший способ подключения в проект разработки или сопровождения ПС новых сотрудников.

Еще раз следует подчеркнуть, что главное достоинство моделей – представление информации в наглядной графической форме. Для одинакового понимания графического представления разными людьми графическая нотация должна быть унифицирована, то есть должен использоваться язык, определяющий такую нотацию и ее семантику. Именно таковым и является Unified Modeling Language (UML).

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]