Вопрос 3. Представление проектных решений в виде UML-диаграмм

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

- перечень деловых объектов (подразделений, должностей, ре­сурсов, процессов, операций, информационных систем, носителей информации и т.д.) с их краткими характеристиками;

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

- перечень процессов и операций, подлежащих автоматизации н разрабатываемой информационной системе;

- предварительные требования к ИС.

UML обеспечивает поддержку всех фаз и этапов жизненного цик­ла ИС, обеспечивая представление результатов работ в виде цепочки графических моделей:

бизнес-модель -> модель требований -> модель проектирования -> модель реализации

Очень часто на процесс проектирования ИС распространяется терминология проектирования базы данных, поэтому говорят о кон­цептуальной, логической и физической моделях ИС.

Концептуальной моделью ИС называется бизнес-модель пред­приятия, для которого создается ИС (*). Некоторые разработ­чики дополняют указанный перечень какими-либо расширениями. Например, часто используется «физическая диаграмма», показы­вающая связи предприятия, для которого создается ИС, с другими предприятиями.

Логической моделью ИС называется модель требований к ИС (*). Более корректно называть логической моделью ИС совокупность графических моделей, сформированных в процесс эскизного проектирования. На этапе эскизного проектирования в структурном подходе создается логическая модель базы данных. В RUP логической моделью ИС можно назвать совокупность диаграмм, сформированных по завершении процесса «Анализ и проектирование» первой итерации фазы «Уточнение».

Модель проектирования образуют:

1) уточненная диаграмма прецедентов;

2) уточненная диаграмма классов;

3) уточненные диаграммы автомата и (или) диаграммы деятельности;

4) уточненные диаграммы коммуникации и (или) диаграммы последовательности;

5) факультативные дополнения, применяемые при тщательном выполнении работ этапа проектирования:

- диаграмма объектов – экземпляр диаграммы классов;

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

- диаграмма обзора взаимодействия – разновидность диаграммы деятельности с расширенным синтаксисом: в качестве элементов обзорной диаграммы взаимодействия могут выступать ссылки на взаимодействия (interaction use), определяемые диаграммами последовательности;

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

- диаграмма пакетов – средство управления сложностью конкретной модели;

6) диаграмма базы данных (database diagram) – дополнение стандартного набора диаграмм, компенсирующее недостаточность стандартных средств для моделирования данных ИС; представляет собой модель структуры базы данных, а точнее, ее физическую модель: таблицы, столбцы, ограничения и др.

Физической моделью ИС называется модель реализации, которую формируют:

- уточненная диаграмма классов;

- диаграммы компонентов (component diagram) – модель иерархии подсистем, отражающая физическое размещение баз данных, приложений и интерфейсов ИС;

- диаграмма развертывания (диаграммы размещения, deployment diagram) – модель физической архитектуры системы, отображающая аппаратную конфигурацию ИС.

Перечисленные ранее модели – это многократно уточняемые конструкции. Указанная последовательность их формирования по­вторяется практически на каждой фазе ЖЦ. При каждом повторении уточняется каждая из моделей. При переходе к новой фазе ЖЦ пере­мещается только «фокус внимания» – глубина проработки – от на­чальных уровней моделей к последующим.

На рисунке 3.1 показана типовая последовательность построения основных диаграмм UML, наиболее интенсивно используемых в ЖЦ ИС. Линии с обычными стрелками указывают направление передачи информации от диаграммы к диаграмме. В реальном процессе созда­нии ИС построение очередной диаграммы может явиться стимулом коррекции диаграммы-источника. Именно такие возможные возвраты означают пунктирные линии с треугольными стрелками.

Рисунок 3.1 – Типовая последовательность построения основных диаграмм UML

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

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

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

На рисунке 3.1 не отражен тот факт, что создание диаграмм деятельности и автомата не обязательно в реальном проекте. Они создаются при необходимости или по требованию заказчика. Многие проект создаются так: разрабатываются диаграмма прецедентов и ее подробная спецификация, затем сразу же синтезируются диаграммы последовательности, иллюстрирующие протоколы (сценарии) пре цедентов, а от них уже осуществляется переход к построению диаграмм классов.

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