Задача п-уровневого подхода — добиться большей сбалансированности всей системы путем отделения логики представления от логики приложения, а логики приложения — от данных, на которых базируется программа. Термин п-уровневый (а не трехуровневый) отражает тот факт, что структура программного обеспечения не ограничена тремя уровнями и может быть разделена (фактически, это так и есть) на более мелкие уровни для выполнения определенных требований.
Следует заметить, что каждый уровень в n-уровневой структуре не обязательно подразумевает отдельную часть аппаратных средств, хотя это, конечно, возможно. Уровень — это прежде всего разделение обязанностей в пределах самой программы. Разные уровни логически разделены в программе, но могут физически сосуществовать на одной и той же машине или быть распределены по многим машинам.
На рис. 1.2 показано программное обеспечение предприятия, организованное по одноуровневой, двухуровневой и трехуровневой схемам.
Ниже приведены некоторые преимущества, даваемые n-уровневой организацией программного обеспечения.
· Более быстрая и потенциально более дешевая разработка. Новые приложения можно разрабатывать быстрее за счет повторного использования существующих проверенных компонентов логики приложения и доступа к данным.
· Изолированное влияние изменений. Пока интерфейсы между компонентами остаются неизменными, изменения на одном уровне не затрагивают компоненты на другом уровне.
· Изменения более управляемы. Например, одну версию делового компонента (логики приложения) заменить на новую легче, если он находится на деловом уровне (на одном или нескольких выделенных серверах), а не в сотнях или тысячах клиентских приложений по всему городу или по всему миру.
Программное обеспечение предприятия и компонентное программное обеспечение
Когда в области разработки программного обеспечения стремительно распространился объектно-ориентированный подход, многие ожидали, что переход к объектно-ориентированным методам разработки даст возможность использовать программный код повторно, но эта надежда осуществилась лишь частично. Одной из причин неполноты такого успеха была чрезмерная степень детализации объектов и неустранимая трудность крупномасштабного повторного использования на одном и том же уровне из-за строго заданного характера соединения мелких объектов.
Именно для решения этой проблемы были разработаны программные компоненты. В отличие от объекта, программный компонент разрабатывается на гораздо более высоком уровне абстракции и представляет законченную функцию или службу. Программные компоненты связаны менее тесно. С помощью интерфейсов, которые намеренно раскрываются компонентами, их можно быстро соединять, формируя большие приложения с меньшими затратами времени и средств.
Разумеется, для компонентного программного обеспечения необходимо, чтобы компоненты»^ разных источников были совместимы друг с другом. Иначе говоря, необходимы одинаковые базовые представления, если угодно — контракты, на основе которых будут разрабатываться компоненты.
Для формирования таких общих представлений за прошедшие годы были разработаны различные модели компонентов. К их числу относятся, например, ActiveX, позднее СОМ разработки Microsoft, аплеты и JavaBeans разработки Sun Microsystems.
Также были созданы распределенные модели компонентов, назначение которых — обеспечить работу компонентных программ в распределенном программном окружении предприятия и решить связанные с этим проблемы, описанные выше. Такие модели компонентов, по существу, предоставляют "операционную систему" для разработки распределенного и компонентного программного обеспечения. К этим моделям относятся DCOM, Microsoft DNA (теперь Microsoft.NET), а также Enterprise JavaBeans (EJB) разработки Sun Microsystems, которая входит в состав платформы Java 2 Enterprise Edition (J2EE).
Резюме
Программное обеспечение предприятия претерпело постепенную эволюцию в стремлении достичь максимальной эффективности. Перед программным обеспечением предприятия стоит несколько различных проблем. Сюда относятся, в частности, проблемы масштабируемости, распределенности, безопасности, а также необходимость работать с совокупностью технологий разных производителей. За последние годы для решения этих проблем испытаны различные эволюционные архитектурные подходы. Все более распространенным решением становится использование распределенных моделей компонентов. Такие распределенные модели компонентой очень перспективны но пока накопятся лишь начальной фазе своего развития.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.