Проектирование компонентов

Компоненты

Компонент по определению выражает практику многократного применения. Стра­тегия, таким образом, состоит в том, чтобы сформировать из компонентов биб­лиотеку, на основе которой можно будет быстро и без особого труда конструировать приложения, реализующие специализированные решения для конкретных заказ­чиков. В любой библиотеке содержатся базовые компоненты (core components), относящиеся к клиентскому и серверному каркасам; предметно-ориентированные компоненты (domain-specific components), отражающие специфику конкрет­ной предметной области (например, сопровождения, восстановления или пере­строения); и компоненты общих возмоясностей (generalized capability components; другое название — вспомогательные компоненты (utility components)), с помощью которых производится окончательная комплектация функциональности прило­жений (например, реализация авторизации и управление пользователями).

Стратегия Inmedius предусматривает развитие базовых, предметно-ориентированных компонентов и компонентов общих возможностей — как для каркаса архитектуры Luther, так и для конкретных предметных областей, в которых рабо­тают заказчики компании. Таким образом, разработка приложений превращается в процесс формирования бизнес-логики, которая обеспечивает объединение не­обходимого набора компонентов, выражающих разные возможности, в специали­зированные решения для заказчиков.

Отдельный и очень важный вопрос в конструировании линеек программных продуктов связан с созданием общих компонентов. Он выражает масштабное применение тактики реализации модифицируемости под названием «общие аб­страктные службы» — в данном случае в целях производства новых решений.

Согласно стратегии проектирования компонентов, интерфейсы прикладного про­граммирования и поведение компонентов должны при малейшей возможности разрабатываться на основе стандартов проектирования. К примеру, рассматрива­емый чуть позже компонент технологического управления являет собой конкре­тизацию спецификации, составленной группой по технологическому управлению (Workflow Management Coalition), которая определяет функциональность и по­ведение при организации технологических процессов. Такая стратегия проекти­рования позволяет Inmedius заменять собственные компоненты компонентами любых других производителей и придерживаться тех же, что и они, специфика­ций возможностей. Она способствует расширению библиотеки компонентов Inmedius.

Разделение возможностей

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

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

Дата добавления: 2015-04-25