Руководство для выполнения практических работ по дисциплине: «анализ и проектирование бизнес систем»

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

---

48 
средств программирования, использующих это понятия и по-
разному его трактующих. 
Самыми 
распространенными 
являются 
компонентные 
технологии - JavaBeans, EJB, CORBA, DCOM, .Net, web-сервисы 
и др. Они позволяют создавать распределенные системы, 
которые, в связи с распространением Интернета, оказываются 
одним 
из 
основных 
направлений 
современного 
программирования.
Информация, представленная на диаграмме с рис. 5.1., может 
со временем меняться: интерфейсы уточняются, добавляются 
новые компоненты, существующие разбиваются на более 
мелкие и т. д. Диаграммы компонент проекта целесообразно 
поддерживать в актуальном состоянии, (имея в виду 
итеративность разработки и внесение в проект всяких 
изменений), поскольку компонентное представление системы 
часто является ядром ее архитектуры. А иметь корректное и 
компактное описание архитектуры всегда полезно, с помощью 
такого описания легче следить за изменениями в проекте и 
удерживать всю картину целиком. 
Но поддержка актуальности каких-либо UML-диаграм, может 
оказаться непростым делом. Как правило, в начале все просто, 
концептуально, красиво. Потом - все разваливается на большое 

---

49 
число деталей, да и сроки "поджимают" - нужно, чтобы 
работало. Вследствие этого целостность архитектуры ПО 
"уходит" из фокуса внимания разработчиков, а поддержка 
соответствующих UML-диаграмм "забрасывается". Однако есть 
такое правило - если нельзя ясно и кратко выразить главное в 
какой-либо сложной деятельности, значит, либо мы делаем что-
то не то, либо то, но не так. В данном случае имеет смысл 
поддерживать актуальность именно этой диаграммы, поскольку 
она является одной из основных спецификаций архитектуры ПО 
телефонной службы приема заявок. 
Еще один важный аспект системы, изображенный на этой 
диаграмме - интерфейсы компонент. Их нужно прорабатывать 
особенно тщательно и вовремя, поскольку если приложение 
разрабатывается разными рабочими группами, распределенными 
географически, то запоздалое согласование интерфейсов может 
потребовать серьезных модификаций в уже написанном коде. 
На рис. 5.2. представлена диаграмма, показывающая, каким 
образом компоненты телефонной службы приема заявок 
распределяются по аппаратной части системы. 

---

50