Представление физической реализации системы

Диаграммы компонентов. При выполнении учебных курсовыхпроектов для более полного отражения принятых проектных решений рекомендуется строить диаграммы компонентов для следующихпредставлений:

1) модель исходного программного кода системы;

2) модель исполняемого программного кода системы;

3) модель артефактов системы, поставляемой заказчику.

На первой диаграмме следует отобразить распределение классовпо файлам с исходным кодом; на второй – представить с помощьюстереотипов расширения «compile» и (или) «build» трансформациюисходного кода в исполняемый код, т. е. показать взаимосвязь междуодними и теми же артефактами, представленными в разных физических форматах; на третьей – представить связь указанных программных артефактов с информационными и сторонними артефактами, т. е. с базой данных и СУБД.

На рис. 19.5 представлены примеры перечисленных ранеевариантов диаграмм компонентов.

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

Рисунок 19.5. Диаграмма компонентов – модель исходного

программного кода

 

Если учесть, что в некоторых системах программирования с каждой формойсвязывается не один, а несколько файлов (например, в C# такихфайлов три), то для того, чтобы диаграмма не «потонула» в деталях, либо ограничиваются указанием основных ассоциированных файлов, либо не выносят вспомогательные классы на диаграммы.

Рисунок19.6. Диаграмма компонентов – модель исполняемого

Программногокода

 

 

Рисунок19.7. Диаграмма компонентов – модель артефактов системы,

поставляемой заказчику

 

Рисунок19.8. Диаграмма компонентов – модель артефактов системы с трехзвенной архитектурой

 

Из рис. 19.8 видно, что классы проекта «Клиенты», «Сотрудники», «Прокат», «Фильм», «Жанр», «Режиссер» реализуются в видеартефакта video.cs. Этот артефакт представляет собой исходный кодсоздаваемой программы. Рис. 19.8 иллюстрирует следующее: исполняемый код программыразмещается в файле (артефакте) video.exe и создается в результате

трансляции исходного кода, находящегося в файле video.cs

На рис. 19.9 представлено простейшее проектное решение, в котором интерфейс пользователя совмещен с бизнес-логикой и вместе ониреализованы в виде исполняемой программы, размещаемой в файлеvideo.exe.

Рисунок19.9. Диаграмма развертывания –

все артефакты размещаются в одномкомпьютере

 

Этот компонент (его принято называть толстым клиентом), взаимодействует с базой данных через интерфейсы СУБД – стороннего компонента, используемого в проектируемой системе.

Как правило, классы-формы пользовательского интерфейса отделяют от проблемных классов, создавая их в разных проектах приложения. При этом проект приложения с пользовательским интерфейсом транслируется в исполняемый файл, а проект приложения с прикладными классами – в динамическую библиотеку. При этом модель артефактов приложения принимает вид, показанныйна рис. 19.10. Артефакт VIDEOINT.exe реализует пользовательский интерфейс, называемый тонким клиентом. Бизнес-логика реализуетсяотдельным компонентом VIDEOBUS.dll, взаимодействующим с базойданных через интерфейсы СУБД.

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

Рис.19.10. Диаграмма развертывания – артефакты распределены

по тремкомпьютерам

 

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