Архитектура. Что такое программная архитектура. Зачем нужна архитектура, страница 3

Компоненты могут разрабатываться и поставляться независимо от других компонентов; иначе говоря, они модульны по своей природе, но могут приносить пользу только в составе модели компонентов. Модель компонентов предоставляет базовую инфраструктуру для объединения компонентов, их взаимодействия и т.д. К моделям компонентов относятся EJB, JavaBeans и СОМ.

Компонент имеет четко выраженные интерфейсы, которые позволяют ему взаимодействовать с другими компонентами. Компоненты, которые соответствуют одной и той же модели компонентов и имеют одинаковые интерфейсы, являются взаимозаменяемыми. Собственно говоря, интерфейсы компонента представляют собой соглашения между компонентом и приложением.

Компонент может иметь в своем составе другие компоненты.

Ниже приведено несколько причин, по которым целесообразно применять компоненты.

·  В сравнении с традиционным построением программного обеспечения компоненты проще в сопровождении и их легче изменять для будущих потребностей.

·  Компоненты имеют потенциал повышения производительности при разработке ПО, так как можно быстро собрать и подготовить приложение из заранее подготовленных компонентов.

·  Приложения, построенные из компонентов, потенциально более гибки. Например, их проще адаптировать к более высокой нагрузке и т.д.

·  Компоненты, которые выполняют определенные задачи, можно покупать и продавать. Из таких компонентов можно строить большие приложения. Таким образом уменьшается срок выхода на рынок1, снижаются общие требования к ресурсам, необходимому для разработки опыту и т.д.

·  Компоненты облегчают естественное разбиение программной системы на связные модули.

Крупные компоненты довольно точно соответствуют подсистемам высокого уровня, образуемым при функциональной декомпозиции системы. Так как они находятся на более высоком уровне абстракции, крупные компоненты могут иметь меньшее количество четко определенных зависимостей. Целесообразно, чтобы крупные компоненты охватывали целые деловые функции и поставлялись отдельно. В контексте платформы J2EE реализовать крупный компонент можно с помощью одного или нескольких компонентов EJB и связанных классов Java. К примерам крупных компонентов относятся модуль склада, который отслеживает все аспекты поступления и распределения товаров, модуль обработки страховых полисов, модуль управления контактами и т.д.

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

Компоненты EJB можно смоделировать как подсистемы UML. На рис. 6.2 показано одно из возможных представлений компонента EJB в UML.

Учитывая важность интерфейсов для компонентов и их взаимоотношений, полезно явно моделировать такие интерфейсы. Для этого можно использовать диаграмму состояний; также в ней моделируется допустимая последовательность операций, поддерживаемых компонентом.

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

Более подробно эти аспекты моделирования рассматриваются в главе 12.

Контуры

В самой простой своей форме контур (framework) может означать любой фрагмент разработанного и проверенного программного обеспечения, который повторно используется в нескольких проектах разработки ПО.

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