Компонентно-ориентированная разработка
Большинство систем, находящихся сегодня в эксплуатации, построены как изолированные, монолитные системы. Они требуют значительных затрат на переработку всякий раз, когда практика бизнеса, рынок или законодательство вынуждают предприятие вносить изменения в свою деятельность. При проектировании таких систем практически никто не думал о повторном использовании их компонентов. Повсюду в мире колесо постоянно изобретается заново. Мы видим, что даже в одной организации одна и та же проблема решается снова и снова.
Наш прогноз на будущее: в ближайшие несколько лет разработка приложений подвергнется значительным изменениям. Мы считаем, что усилится тенденция к созданию более компонентно-ориентированных систем. Вы не будете строить новую систему "с нуля", а будете искать готовые компоненты, которые помогут реализовать эту систему, создавать необходимые функциональные возможности на базе существующих компонентов (как собственной разработки, так и приобретенных) и выбирать "клей" для соединения их в прикладную систему.
Эта тенденция в некоторой степени уже проявилась, хотя до настоящего момента она распространяется, главным образом, на средства разработки клиентов. В Microsoft Visual Basic эта концепция используется уже в течение нескольких лет — вспомним VBX, OCX, а теперь и ActiveX. Потоку элементов управления разработки третьих фирм на сегодняшнем рынке нет конца и края. Менее распространены серверные компоненты. С помощью архитектуры сетевых вычислений (NCA) и картриджей Oracle побуждает разработчиков писать компоненты, чтобы накопить обширный портфель картриджей. Одно из главных преимуществ компонентно-ориентированного проекта состоит в уменьшении затрат на тестирование, потому что компоненты, из которых вы строите свою систему, уже проверены. (Как минимум, вы полагаете, что они проверены и протестированы, что не одно и то же.)
По мере распространения компонентов методы, применяемые в разработке, должны эволюционировать. На наш взгляд, анализ не только позволит определять потребности, но и находить нужное компонентное ПО и исследовать "пробелы". Путем такого анализа можно будет установить, насколько полно компонент (или компоненты) обеспечивает требуемые функциональные возможности.
Каждый компонент можно представить при помощи совокупности классов объектов. Одна из функций проектировщиков в этом храбром новом мире будет состоять в создании иерархии классов объектов. Предположим, мы собираемся развернуть низкоуровневый класс обработки изображений с такими методами, как "сканировать", "хранить", "индексировать" и т.д. Мы могли бы создать собственные классы, например класс "хранить документ", которые наследуют свойства базовых классов обработки изображений. Можно также вставить родовой набор классов, например "создать новый документ", между низкоуровневыми классами и нашим высокоуровневым классом.
26	Oracle 8