Сергей Зыков - Основы проектирования корпоративных систем

Вторая тема, которая будет рассмотрена, – это офисные приложения и их разработка на основе Visual Studio Tools for Microsoft Office, вернее, for Microsoft Office System, потому что Microsoft Office – это с недавних пор также платформа, некий базис, на основе которого можно строить свои приложения. И это достаточно важный аспект корпоративных систем, поскольку современные версии Microsoft Office позволяют вести коллективную работу над документом, визировать документ, вести распределенную работу с общим репозиторием, публиковать изменения в Интернете и т. д. На уровне Microsoft Office 2005 будет рассмотрено, до каких технологий и возможностей развилась эта платформа и какие у нее появились возможности. Следует еще раз подчеркнуть, что рассматриваемые офисные приложения понимаются как надстройка над стандартом Microsoft Office, вернее, даже корпоративной версией Microsoft, который сам по себе уже является платформой для корпоративной работы с документами и создания корпоративных приложений.

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

Будет описано, насколько связаны понятия компонента и сборки, каким образом происходит формирование сборки, как обеспечивается взаимодействие сборок между собой, как обеспечивается безопасность приложений при построении их на основе компонентного подхода в рамках идеологии Microsoft.NET. Будет обсуждаться, каким образом происходит развертывание приложений, построенных из компонентов, как строятся интерфейсы, и, кроме того, будет говориться о различных компонентных моделях, прежде всего о моделях на основе подхода. NET, и моделях, связанных с развитием компонентно-объектной модели, COM-модели. Кроме того, будут обсуждены возможности других компонентных подходов, достаточно раннего подхода CORBA, связанного с брокерами объектных запросов, универсальной шины для взаимодействия между объектами. Будет говориться о подходе, разработанном корпорацией Sun Microsystems, который называется Java Beans, или Enterprise Java Beans, и тоже позволяет строить корпоративные приложения на основе компонентов.

Итак, компонент – это структурная единица прикладной программной системы с четко определенным интерфейсом и способом взаимодействия с другими элементами приложения. При этом компонент, несмотря на то что изолирован, во многом выполняет задачу, характерную только для него, работает в среде и использует ряд ее механизмов. Если говорить о. NET, то среда называется Common Language Runtime – среда времени выполнения. И все зависимости и взаимосвязи компонента с программной средой должны быть полно, четко и недвусмысленно описаны в рамках интерфейса. В целях повторного и многократного применения разумного подхода вполне возможным является использование одного и того же компонента, с небольшими вариациями, в разных ролях, в разных соотношениях относительно других компонентов. Поэтому один компонент может иметь несколько различных интерфейсов, т. е. играть в системе разные роли. Ну скажем, сценарий входа в систему для различных пользователей внешне выглядит похоже, но с точки зрения процедур, действий, которые выполняются при входе в систему, и тех полномочий по доступу, которые открываются после корректного входа, конечно, следует соотносить это общую процедуру входа с ролями пользователей, будь то администратор, привилегированный пользователь, аудитор системы и т. д. Этот интерфейс, его описание, называется интерфейсным контрактом или программным контрактом для компонента. Ранее уже говорилось о контрактах, в частности о контрактах данных, когда обсуждалась технология Windows Communications Foundations, но на самом деле, если говорить о компонентах в принципе, взаимодействие организовано очень похожим образом.

Важно отметить, что для каждой операции компонента имеется набор условий, необходимых для корректного начала его работы и корректного ее завершения или, как говорят, предусловия и постусловия. По сути, компонент, или модуль, можно рассматривать как некоторую процедуру или с математической точки зрения – некоторую функцию, которая имеет, как и всякая функция, область определения, область значения, вход и выход, а также ограничения на диапазон входа и выхода. Здесь, в случае интерфейсного контракта, также имеются предусловия и постусловия, которые описывают возможности его операций. Предусловие операции должно быть выполнено при ее вызове, иначе сложно гарантировать корректность результатов выполнения этого компонента, операций в компоненте. Постусловие обеспечивает сам компонент. Если он корректно отрабатывает, то обеспечивается выполнение истинности постусловия. То есть ответственность за корректность состояния по завершении работы компонента возлагается прежде всего на разработчика этого компонента, конечно, при корректном понимании структуры программной системы. В случае корпоративной системы эта структура довольно сложна. Таким образом, постусловие определяет, какие из ее результатов можно считать корректными. В объектно-ориентированном подходе часто говорится о модулях, т. е. о некоторых самостоятельных единицах программного кода, нацеленного на выполнение одной специфичной операции. Но если говорить о корпоративных системах, модуль понимается более широко – как программная единица, которая решает целый ряд взаимосвязанных задач. Это может быть, например, модуль основных средств, модуль учета и управления и планирования основных средств в рамках корпоративной системы класса ERP, Oracle Business Suit.