Найчастіше за допомогою інтерфейсів моделюють стикувальні вузли в системі, що складається з таких програмних компонентів (див. Розділ 25), як СОМ + або JavaBeans. Деякі компоненти ви створюєте самі з нуля, інші купуєте або заімствуете з інших систем (див. Розділ 31). У будь-якому випадку доведеться написати деякий код для "склеювання" цих компонентів, через що необхідно розуміти, які інтерфейси реалізуються і споживаються кожним з них.
Ідентифікація стикувальних вузлів в системі передбачає наявність чітких ліній демаркації в її архітектурі. По один бік від такої лінії знаходяться компоненти, які можуть змінюватися незалежно від компонентів з іншого боку, за умови, що обидві сторони виконують контракт, оголошений інтерфейсом.
Взявши готовий компонент з іншої системи або купивши його, ви, швидше за все, отримаєте набір операцій і мінімальну документацію про призначення кожної з них. Це корисно, але ще не досить. Набагато важливіше зрозуміти, в якому порядку повинні викликатися операції і які внутрішні механізми, втілені в інтерфейсі. На жаль, якщо компонент погано документований, вам доведеться самому методом проб і помилок будувати концептуальну модель роботи його інтерфейсу. Потім можна задокументувати те, що ви виявили, шляхом моделювання даного стикувального вузла за допомогою інтерфейсів UML, - так, щоб згодом вам і іншим людям було простіше працювати з цим компонентом. Розробляючи власний компонент, ви повинні відслідковувати його контекст, тобто уточняти інтерфейси, на наявність яких він розраховує для виконання своєї роботи, а також інтерфейси, які подаються нею самим для використання в інших компонентах.
Примітка: Більшість компонентних систем, таких як СОМ + або Enterprise JavaBeans, надають можливість інтроспекції, тобто програмного запиту у інтерфейсу інформації про його діяльність. Це перший крок до розуміння природи недостатньо документованого компонента.
Моделювання стикувальних вузлів системи проводиться таким чином (докладніше моделювання поведінки розглядається в частинах 4 і 5):
- Зобразивши набір класів і компонентів системи, проведіть лінії, що відокремлюють один від одного групи тісно пов'язаних класів і компонентів.
- Уточніть вбрання поділ з урахуванням змінності системи. Спільно змінювані класи або компоненти повинні бути згруповані в окремі кооперації (див. Розділ 27).
- Вивчіть операції і сигнали, які перетинають певні вами кордону.
- Об'єднайте логічно пов'язані набори операцій і сигналів, оформивши їх як інтерфейси.
- Для кожної виявленої в системі кооперації ідентифікуйте інтерфейси, на які вона покладається у своїй роботі (імпортує) і ті, які вона надає іншим (експортує). Імпорт інтерфейсів моделюється за допомогою відносин залежності, а експорт - за допомогою відносин реалізації.
- Документуйте динаміку інтерфейсів за допомогою передумовою та постусловіем для кожної операції, а також прецедентів і автоматів для інтерфейсу в цілому.
Наприклад, на рис. 11.6 зображені стикувальні вузли для бібліотеки ledger. dll - компонента, взятого з фінансової системи. Цей компонент реалізує три інтерфейсу - lUnknown, ILedger і IReports. На діаграмі перший з них показаний в розширеній формі, а решта два - у скороченій. Всі три інтерфейсу реалізуються компонентом ledger.dll і експортуються в інші компоненти, які використовують їх в своїй роботі.
Мал. 11.6 Моделювання стикувальних вузлів системи
Як видно з діаграми, компонент ledger.dll імпортує два інтерфейси, IStreaming і ITransaction, причому останній показаний в розширеній формі. Обидва вони потрібні компоненту ledger.dll для коректної роботи. Отже, в працюючу систему ви повинні будете включити також і реалізують їх компоненти. Виділивши інтерфейс, наприклад ITransaction, ви тим самим роз'єднали знаходяться по різні боки від нього компоненти. А це означає, що ви можете використовувати будь-який компонент, аби він відповідав специфікації інтерфейсу.
Такі інтерфейси, як ITransaction, - це не просто сукупність операцій. Даний інтерфейс містить певні припущення про те, в якому порядку повинні викликатися операції. Хоча на діаграмі це не показано, можна було б приєднати до інтерфейсу прецедент (див. Розділ 16) і перерахувати типові способи застосування інтерфейсу.