2. Язык UML. Руководство пользователя. Буч_ Рамбо_ Якобсон (2-е издание) (2006) (1185732), страница 34
Текст из файла (страница 34)
А это потребуетпонимания интерфейсов, предоставляемых и требуемых каждымкомпонентом.Идентификация соединений в системе включает в себя идентификацию четких линий разделения архитектуры. С каждой стороныот этих линий вы найдете компоненты, которые могут изменятьсянезависимо, не оказывая влияния на противоположный компонент(до тех пор пока компоненты на обеих сторонах придерживаютсятребований контракта, специфицированного интерфейсом).ОбразцыКогда вы используете компонент из другой системы или покуи каркасыпаете его, то, вероятно, находите в нем ряд операций с какимFто миобсуждают- нимумом документации, где описывается суть каждой из них.
Этося в главе 29. удобно, но, к сожалению, недостаточно. Гораздо важнее для вас понимать порядок, в котором следует вызывать операции, и механизм,который они заключают в себе. Имея малодокументированныйКомпонентыобсуждаются в главе 15,системы – вглаве 32.174Интерфейсы, типы и ролиТипичные приемы моделированиякомпонент, лучшее, что вы можете сделать, – путем проб и ошибокпостроить концептуальную модель работы его интерфейса. Затемвы вправе изложить свое понимание предмета, моделируя соединение в системе с помощью интерфейсов на UML, с тем чтобывпоследствии вы и другие пользователи без труда в нем разбирались. Точно так же, когда вы создаете свой собственный компонент,то должны обеспечить понимание контекста, в котором он долженприменяться, – иными словами, специфицировать интерфейсы,на которые он опирается при выполнении своей работы, а также интерфейсы, которые он предоставляет окружающей среде.175управления финансами.
Этот компонент предоставляет (реализует) три интерфейса: Iunknown (IНеизвестный), ILedger (IГроссбух)и Ireports (IОтчеты). На данной диаграмме IUnknown показан в своей расширенной форме, другие два интерфейса – в упрощенной,как «леденцы» (lollipops). Все три интерфейса и экспортированы для использования другими компонентами.«interface»На заметку. Большинство компонентных систем наподобиеEclipse, .NET и Enterprise Java Beans открыто для компонентной интроспекции, то есть вы можете программно опросить интерфейс, чтобы узнать его операции. Это первый шагк пониманию природы любого малодокументированного компонента.«interface»LedgerЧтобы смоделировать соединения в системе, выполните следующие действия:Кооперацииобсуждаются в главе 28.
Проведите границы между теми классами и компонентамивашей системы, которые более тесно взаимодействуют другс другом, чем другие наборы классов и компонентов. Проверьте правильность объединения элементов в группы,рассмотрев последствия возможных изменений. Классы иликомпоненты, которые изменяются совместно, объединитев кооперации. Рассмотрите операции и сигналы, которые пересекают границы, проведенные на этапе 1, от экземпляров из одногонабора классов или компонентов к экземплярам из другогонабора. Объедините логически связанные наборы операций и сигналов в интерфейсы. Для каждой кооперации в системе определите интерфейсы,которые ей требуются (импортируемые), и те, которые онапредоставляет (экспортирует) другим кооперациям. Импортинтерфейсов моделируйте связями зависимости, а экспорт –связями реализации.
Для каждого такого интерфейса документируйте его динамику, используя предF и постусловия каждой операции, а такжеварианты использования и автоматы для интерфейса в целом.Моделирование поведенияобсуждаетсяв частях IVВ качестве примера рассмотрим рис. 11.5, где показаны соединеи V.ния, окружающие компонент Ledger (Гроссбух), взятый из системыРис. 11.5. Моделирование соединений в системеВариантыиспользования обсуждаютсяв главе 17.Также на диаграмме показано, что Ledger требует (использует) дваинтерфейса: IStreaming (IПоток) и Itransaction (IТранзакция), причемвторой показан в расширенной форме.
Эти два интерфейса необходимы компоненту Ledger для правильной работы. Таким образом,в работающей системе вы должны подставить компоненты, которыереализуют оба этих интерфейса. Идентифицируя такие интерфейсы, как ITransaction, вы получаете эффективно разъединенные компоненты, лежащие по разные стороны интерфейса, что позволяет«нанимать» любой компонент, который соответствует интерфейсу.Такие интерфейсы, как Itransaction, представляют собой нечтобольшее, чем пул операций. Указанный интерфейс делает определенные предположения о порядке вызова его операций.
Хотя этоздесь и не продемонстрировано, вы должны сопроводить его вариантами использования и перечислить общие способы его применения.Моделирование статическихи динамических типовЭкземплярыобсуждаются в главе 13.Большинство объектноFориентированных языков программирования статически типизировано. Это означает, что с объектом в момент его создания связывается определенный тип (даже несмотряИнтерфейсы, типы и роли176Диаграммыклассовобсуждаютсяв главе 8.Ассоциациии обобщенияобсуждаются в главах5 и 10,диаграммывзаимодействий –в главе 19,зависимости – в главах 5 и 10.на то, что объект, вероятно, будет впоследствии играть различныероли). Следовательно, клиенты, использующие объект, взаимодействуют с ним через разные наборы интерфейсов, которые представляют интересующие их множества операций (возможно, перекрывающиеся).Моделирование статической природы объекта может быть показано на диаграмме классов.
Однако когда вы моделируете, скажем, бизнесFобъекты, которые обычно изменяют свой тип в потокеработ, иногда целесообразно подчеркнуть динамическую природуих типа, задав ее явным образом. При таких обстоятельствах в течение своего жизненного цикла объект может принимать и терятьтипы. Смоделировать жизненный цикл объекта можно при помощимашины состояний (конечного автомата).Чтобы смоделировать динамический тип, необходимо: Специфицировать возможные типы данного объекта, представляя каждый из них в виде класса (если абстракция требует структуры и поведения) или же интерфейса (если абстракция требует только поведения). Смоделировать все роли, которые может играть класс объекта в любой момент времени.
Вы можете пометить их стереотипом <dynamic> (он не предусмотрен в UML изначально – высоздаете его сами). На диаграмме взаимодействия правильно изобразить каждый экземпляр динамически типизированного класса. Отобразить тип экземпляра как состояние, – в фигурных скобках прямо под именем объекта.
(Мы используем синтаксисUML новым способом, который, на наш взгляд, согласуетсяс выражением состояний.)«dynamic»«dynamic»«dynamic»Рис. 11.6. Моделирование динамических типовНа рис. 11.6 показано, какие роли исполняют экземпляры класса Person (Человек) в системе управления персоналом.По диаграмме видно, что экземпляры класса Person могут бытьодного из следующих типов: Candidate (Кандидат), Employee (Работник) или Retiree (Пенсионер).Советы и подсказки177Советы и подсказкиКогда вы моделируете интерфейсы в UML, помните, что каждый из них должен представлять соединение в системе, отделяющее спецификацию от реализации.
Хорошо структурированный интерфейс обладает следующими свойствами: прост, но полон – представляет все необходимые операции для описанияотдельного сервиса; понятен – дает достаточно информации как для использования, так и для реализации, чтобы не нужно было исследовать имеющиеся случаи использования и реализации; доступен – представляет информацию пользователю по ключевым свойствам, без перегрузки деталями множества операций.Изображая интерфейс в UML, учитывайте следующее: используйте нотацию «леденца» или сокета (socket) всякий раз, когда нужно показать наличие соединения в системе.
В основном это понадобитсядля компонентов, а не для классов; используйте расширенную форму, когда необходимо представить деталисамого сервиса. В большинстве случаев это понадобится для описания соединений между пакетами и подсистемами.ВведениеГлава 12. ПакетыВ этой главе:Пакеты, видимость, импорт и экспортМоделирование групп элементовМоделирование архитектурных представленийМасштабирование больших системВизуализация, специфицирование, конструирование и документирование больших систем предполагают работу с множеством классов, интерфейсов, узлов, компонентов, диаграмм и других элементов.
Масштабируя такие системы, вы столкнетесь с необходимостьюорганизовывать эти сущности в крупные блоки. В языке UML дляорганизации элементов модели в группы применяются пакеты.Пакет – это способ организации элементов модели в блоки, которыми можно распоряжаться как единым целым. Можно управлять видимостью элементов пакета, так что некоторые будут видныпользователю, а другие – скрыты. Кроме того, с помощью пакетовизображаются различные представления архитектуры системы.Хорошо структурированный пакет объединяет семантически близкие элементы, которые имеют тенденцию изменяться совместно. Такиепакеты характеризуются слабой связанностью и высокой согласованностью, причем доступ к содержимому пакета строго контролируется.Программная архитектураобсуждается в главе 2,моделирование архитектурысистемы –в главе 32.179с другом, чтобы удобнее было говорить о предполагаемом использовании домашнего пространства.Небоскребы устроены еще сложнее.
Там вы найдете помимопростейших конструкций (стен, полов, потолков) более крупныеобразования – места, открытые для общего доступа, сдаваемыев аренду квартиры и офисы. Эти блоки, вероятно, сгруппированыв еще более крупные, такие как арендуемая площадь и инфраструктура обслуживания здания.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
