Бусыгин Б.С., Коротенко Г.М., Коротенко Л.М. Введение в современную информатику

Подождите немного. Документ загружается.

140

процедур и триггеров баз данных (рис.6.18). В отличие от очень дорогостоящих

мэйнфреймов эта архитектура является хорошим решением для

распределённых вычислений в рабочих группах до 100 человек, которые

работают в LAN отделов и организаций одновременно.

Компоненты приложений в клиент/серверных вычисленнях, как правило,

распределены так, чтобы база данных постоянно находилась на сервере (UNIX

или мэйнфрейм), интерфейс пользователя на ПК-клиенте, а деловая (бизнес)

логика находится в обоих компонентах.

Трёхярусная архитектура (three tier

architectures), известная также как

многоярусная (multi-tier architecture),

разрабатывалась для снятия ограничений,

которые существовали в двухярусной. В ней

средний ярус был расположен между

системным интерфейсом среды клиента и

средой сервера, которая управляет базой

данных. Существует достаточно много

реализаций этого средного уровня, к к которым

можно отнести мониторы обработки

транзакций (transaction processing monitors),

сервера сообщений (message servers) и сервера

приложений (application servers). Трёхъярусная

архитектура позволяет одновременно работать

группам, насчитывающим несколько тысяч

пользователей. Гибкость в настройке

требуемой конфигурации здесь достигается

простым применением технологии "drag and drop" для фрагментов кодов

используемых приложений на разные компьютеры любого яруса из трёх

существующих. Ограничения трёхъярусной архитектуры связаны с тем, что

использование сред разработки приложений здесь значительно сложнее, чем

визуально-ориентированная разработка в двухъярусной архитектуре. В

последнее время в трёхъярусной архитектуре в качестве серверов начинают

активно применяться мэйнфреймы.

Трёхярусная архитектура с технологиями монитора обработки

транзакций (three tier architecture with transaction processing monitor technology)

является одной из наиболее распространённых и включает на среднем ярусе

монитор обработки транзакций (Transaction Processing, TP). В его задачи входит

организация очередей запросов, распределение транзакций и приоритетов

выполнения задач. Кроме того, он обеспечивает:

 возможность обновления многочисленных различных СУБД путём

однократно выполняемой транзакции;

 соединение и обработку многочисленных источников данных,

включая двумерные файлы (flat files), нереляционные БД и мэйнфреймы;

 возможность присваивания разных приоритетов транзакциям;;

 обеспечение робастной (устойчивой) безопасности.

141

Трёхярусная архитектура с сервером сообщений (three tier with message

server) представляет реализацию процесса асинхронного обмена сообщениями

(messaging) c разными приоритетами. Сообщения, как правило, содержат

заголовки, состоящие из данных об уровне приоритета, а также адреса и

идентификационного номера сообщения. Если в данной архитектуре

программируемая интеллектуальность сосредоточена в сообщениях, то в среде

мониторов транзакций непосредственно в мониторе, обрабатывающем

транзакции в виде неинтерпретируемых пакетов данных. Трёхъярусная

архитектура с сервером сообщений является лучшим решением для

беспроводных инфраструктур.

Трёхярусная архитектура с сервером приложений (three tier with an

application server) обеспечивает размещение основного кода приложения для

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

хосте, то есть компьютере узла сети. Сервер приложений не имеет и не

управляется GUI, а только исполнят бизнес-логику, вычисления и моделирует

машину поиска данных. Преимуществом такого подхода является уменьшение

компонентов пользовательского ПО на компьютере клиенте и повышение

безопасности функционирования решений в целом (рис.6.19).

Приложения становятся более масштабируемыми, а стоимость

развёртывания и поддержки программных продуктов и систем на одном

сервере значительно меньше, чем на многочисленных клиентах. Таким

образом, данная архитектура наиболее применима при условиях необходимости

выполнения требований безопасности, масштабируемости и снижения

стоимости работы системы.

Трёхярусная архитектура с ORB (three tier with an ORB architecture) для

распределённых вычислений активно развивается промышленными

консорциумами на уровне стандартов, повышающих интероперабельность и

кроссплатформенность приложений, разработанных изначально на разных

языках программирования для разных платформ. Основной проблемой для

обсуждаемых стандартов является определение механизмов и элементов

реализации общих для взаимодействующих систем объектных брокеров

запросов (Object Request Broker, ORB). На настоящем этапе разработка

клиент/серверных систем с использованием технологий, поддерживающих

распределённые, объекты имеет громадные перспективы в условиях

повсеместного развития и применения сетевых, Интернет и WWW технологий

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

среди языков и платформ, данная архитектура существенно повышает

Рис. 6.19. Трёхъярусная архитектура с сервером приложений

142

эксплуатационную надёжность и удобство сопровождения (maintainability), а

также адаптируемость (adaptability) создаваемого ПО. К наиболее развитым и

используемым в настоящее время относятся следующие технологии:

 Брокер запросов общей объектной архитектуры (Common Object

Request Broker Architecture, CORBA);

 Компонентная объектная модель/Распределённая КОМ

(COM/DCOM, Component Object Model/Distributed Component Object Model).

Промышленные круги активно работают над стандартами, которые

обеспечили бы интероперабельность между CORBA and COM/DCOM.

Наиболее активным участником данного процесса является консорциум Object

Management Group (OMG), который разработал отображения соответствия

данных и процессов между CORBA и COM/DCOM на уровне нескольких

программных продуктов.

Распределённая/совместная промышленная архитектура

(distributed/collaborative enterprise architecture) была разработана в 1993 году. Эта

программная архитектура базируется на технологии применения объектных

брокеров запросов (Object Request Broker, ORB), являющихся продолжением

развития архитектуры CORBA, путём применения совместно (share) и повторно

(reusable) используемых бизнес-моделей (а не просто объектов!) в масштабе

распределённых предприятий (enterprise-wide scale). Преимущества данного

подхода заключаются в том, что стандартизированные бизнес-объектные

модели (business object models) и распределённые вычислительные объекты

(distributed object computing) комбинируются вместе для обеспечения

организационной гибкости для достижения операционной и технологической

эффективности в масштабах целых предприятий.

Глобальная XML архитектура Microsoft (Microsoft Global XML Architecture,

MS GXA) является структурой и базовой основой (framework) протокола,

спроектированного для обеспечения модели полной совместимости при

построении протоколов инфраструктурного уровня для Web-сервисов и

Web-приложений. Web – сервисы – это - прикладные сервисы, включающие

программы (приложения), программирование, данные и человеческие ресурсы,

которые сделаны доступными с Web-серверов для Web-пользователей или

других Web-присоединённых программ. В дополнение к этой основной

структуре протокола, GXA определяет семейство подключаемых протоколов

инфраструктуры, которые обеспечивают для функционирующих в GXA-среде

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

надёжность и поддержка многоуровневых и многосвязных служб согласования

их работы. GXA поддерживает принципы, объединяющие отдельные

протоколы GXA-инфраструктуры в единую связную платформу для

функционирования сервисов и приложений. Основополагающей предпосылкой

GXA является ликвидация необходимости для разработчиков приложений

перестраивать платформу целиком для каждого нового приложения. Эта

предпосылка доминирует в моделях разработки на однокомпьютерных рабочих

местах, где 95% программистов всего мира используют разные платформы

разработки. Традиционный мир однокомпьютерной разработки ПО

143

десятилетиями формализовал методы модуляризации программного кода и

данных, которые позволили осуществить разделение между приложением и

платформой. Мир коммуникационных протоколов также создал свои принципы

модуляризации, среди которых наиболее известен 7-и уровневый протокол OSI.

Основной целью GXA является:

 создание более общей модели для структурирования протокола;

 разработка семейства протоколов платформенного уровня для

разработчиков приложений, использующих Web-сервисы и Web-приложения.

Так же, как и операционная система обеспечивает средства совместной

работы программистов, программных систем и приложений, управляет

процессами и потоками, обеспечивает контроль доступа к ресурсам и их

распределение,управляет памятью так и GXA обеспечивает комплекс общих

средств, требуемых в широком спектре разработки и использования Web-

сервисов и Web-приложений. Язык XML используется для организации и

использования данных. SOAP служит для передачи данных в сетях, WSDL

применяется для описания доступных данных, а UDDI используется для

перечисления доступных сервисов (рис.6.20.).

Сам язык XML служит технологией и средством организации сложно

структурированных данных разной природы (программы, текстовые,

звуковые, графические, видео файлы и т.д.), которые размещены в разных

точках мирового пространства на разных ПК в единое целое (!!!).

Подводя итоги, следует добавить, что вышеуказанные архитектуры не

единственные и не последние. В настоящее время активно развивается

архитектура беспроводных коммуникаций (wireless architecture) на базе адресных

сервисов (location services). Эта и некоторые другие архитектуры

распределённых вычислений поддерживаются двумя мощными архитектурами

Серверы приложений

и XML-данных

Внешние системы

HTTP серверы

Базы данных

Наследуемые

системы

ERP-системы

Библиотеки приложений

Рис. 6.20. Типичная архитектура Web-сервисов

144

и соответствующими технологиями: Jini™ от Sun Microsystems и .NET™ от

Microsoft (см. подраздел 6.6).

Поэтому разработчику программного обеспечения необходимо постоянно

следить за развитием и взаимосвязью информационных архитектур, а также

компонентов и программных средств компьютерной техники. При этом следует

своевременно корректировать методологии разработки своих приложений

решений, с соответствующим освоением:

основ программной инженерии, новых технологий программирования,

языков программирования и инструментальных средств разработки ПО.

6.5 Как проектируются приложения и решения?

Информационные системы играют основополагающую роль в деле

определения успеха практически любого современного бизнеса и решения

многих прикладных проблем и задач. С появлением персональных

компьютеров такие системы и программные приложения прочно укрепились в

большинстве государственных и бизнес-организаций мира. Эти новые

системы вместе с существующими унаследованными системами (legacy systems)

предоставляют критичные для функционирования организаций средства

хранения, организации, получения и обработки информации, в том числе и на

правительственном уровне

. Потенциально, эти системы могут стать

источником детальной и разноплановой информации, которая способствует

принятию качественно лучших решений.

В большинстве своем современные информационные системы являются

распределенными, то есть состоящими из нескольких частей, обычно

взаимодействующих друг с другом по сети. Разбивать систему на части

приходится потому, что возможности автономной компьютерной системы не

способны покрыть потребности серьезной информационной системы в

вычислительных возможностях и хранении данных. К тому же разбиение на

части с внесением избыточности в эти части обеспечивает устойчивость

механизма восстановления системы после сбоев.

В софтверной индустрии с учётом большого объёма и сложности

выполняемых при реализации крупных приложений дополнительных

мероприятий часто последние именуют решениями

. Свой большой опыт в

разработке бизнес–решений специалисты корпорации Microsoft обобщили в

виде комплекса документов по описанию Дисциплины разработки решений

Microsoft (Microsoft Solution Framework, MSF

). MSF содержит в себе набор

моделей и четко определенных проектных вех (т.е. контрольных точек),

которые можно рассматривать как рекомендуемые отправные точки, равно как и

B2G, G2C, G2G. Эти аббревиатуры определяют новые сферы бизнеса, в которые, тем или иным образом,

вовлечено государство (Government). Они раскрываются как Business-to-Government, Government-to-Citizens,

Government-to-Government. Являются следствием включения Государства в процесс электронизации всехх

видов деятельности. Концепция Electronic Government была объявлена в США на самом высоком

государственном уровне первого июля 1997 года.

Брандт Д. Architectures. Экзамен – экстерном. (экзамен 70-100). СПБ.: Питер, 2001. – 432 с.

Материалы Microsoft MSF: (http://www.microsoft.com/msf и http://www.microsoft.com/rus/msf )

145

руководство по планированию, ведению и управлению проектами в сфере

информационных технологий. Эти модели — результат интеграции в единую

систему наиболее успешных и многократно примененных практик, выявленных

в процессе анализа опыта по разработке программных продуктов,

накопленного не только Microsoft, но и ее заказчиками и партнерами.

Они не являются единствеными в своём роде, но в отличие от многих

других могут быть получены бесплатно на русском языке.

С точки зрения MSF, разработка решения бизнес–проблемы — это больше,

чем простое написание крутого приложения с применением новейших

технологий. Разработка приложения должна вестись, исходя из предварительно

подготовленных бизнес–требований. Будучи разработанным, приложение

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

помогать в решении повседневных проблем. Другими словами, приложение

должно быть написано под конкретный процесс и полностью

соответствовать его правилам.

После того, как будут подготовлены и уточнены все требования и

проявятся контуры будущего решения, эти высокоуровневые абстракции

смогут предоставить информацию, необходимую для создания детальных

разноуровневых проектов, которые лягут в основу реализации приложений

решения. Такие шаги, показаны на рис. 6.21.

6.5.1.Подготовительный этап: анализ требований. Разработка

решения начинается с анализа требований. Этот высокоуровневый процесс

сбора информации должен ответить на

вопрос: что необходимо сделать, почему это

необходимо сделать и какой ожидается

результат. После этого можно подвести

итоги и зафиксировать требования в

документации. Полный анализ требований

даёт информацию, которая описывает:

 границы проекта;

 суть проблемы (потребности

пользователей);

 требуемый уровень безопасности;

 производительность приложения;

 потребности в сопровождении;

 возможности расширяемости;

 доступность;

 масштабируемость;

 человеческий фактор;

 интеграцию с существующим

окружением;

 используемые методологии.

6.5.2.Определение технической архитектуры. После выяснения

1. Анализ требований

2. Определение технической

архитектуры

3. Разработка модели данных

4. Разработка приложений

5. Разворачивание

6. Сопровождение

Рис. 6.21. Процесс разработки

прикладной информационной

системы

146

требований нужно приступать к оценке возможностей и ограничений

технологий, позволяющих реализовать решение, и начинать формулировать

техническую архитектуру, подходящую для его реализации и развёртывания.

Здесь следует определиться с количеством обслуживаемых приложением

пользователей и соответственно объёмами и расположением источников

используемых в будущем данных (т.е. серверов, хранилищ данных и т.д.).

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

в будущем решений. И, наконец, техническая архитектура должна в общих

чертах давать представление о стратегии развертывания решения после его

реализации.

6.5.3.Разработка модели данных. Техническая архитектура дает

представление о требованиях к аппаратным и программным компонентам

хранения данных, однако она не дает никаких указаний о том, какими должны

быть элементы используемых решением данных и как их следует

организовывать. Это определяется моделью данных, которая, в свою очередь,

определяется метаданными (metadata), то есть данными о данных. Модель

данных определяет все элементы данных, то есть сущности (entities), а также

характеристики — атрибуты (attributes) — каждой из них и организацию этих

сущностей. Для организации данных существуют специальные правила

нормализации данных (data normalization rules). Помимо этого модель данных

определяет связи (relationships) между сущностями, а также специальные

правила, так называемые ограничения (constraints), используемые для

обеспечения целостности (integrity) накапливаемых в дальнейшем данных.

6.5.4.Разработка проектных частей приложений и решений.

Следующая задача, после того как были разработаны техническая

архитектура и модель данных, это разработка приложений решения. Разработка

приложения подразумевает три различных вида деятельности:

 разработку концептуального и логического проектов приложений;

 проектирование интерфейса и служб пользователя;

 разработку физического проекта.

Большинство людей считает, что основная деятельность при

разработке приложения заключается в написании и отладке кода (рис. 6.22).

Хотя процесс написания и отладки кода и представляет собой

неотъемлемую часть процесса разработки, эта деятельность не может

начаться до тех пор, пока не будут готовы концептуальный, логический

и физический проекты приложений.

Итак, проектирование приложения начинается с разработки

концептуального проекта, который основывается на бизнес-требованиях и

обычно содержит сценарии: модели последовательность действий/процесс

(workflow/process model) и модели задача/последовательность (task/ sequence

model).

Логический проект, получаемый далее из концептуального проекта, дает

абстрактное высокоуровневое описание приложения. Логическая модель

разбивает приложение на функциональные модули, соответствующие бизнес-

компонентам приложения. Центральной задачей логического проектирования

147

является вычленение и специфицирование бизнес-объектов, их свойств и

методов. В терминах модели приложения MSF эти бизнес-объекты называются

службами.

Логический проект определяет службы приложения (application services),

предоставляемые данным приложением. Использование моделей, полученных в

результате концептуального и логического проектирования, позволяет смотреть

на приложение в терминах бизнес-компонентов и программной архитектуры.

Как правило, оценка логического проекта производится по семи ключевым

факторам. Более точные критерии оценки определяются конкретным

решением, однако для логического проекта наиболее важны ограничения на:

 производительность (performance),

 сопровождаемостъ (maintainability),

 расширяемость (extensibility),

 доступность (availability),

 масштабируемость (scalability)

 безопасность (security),

 отказоустойчивость (failure-resistance).

К остальным, также существенно влияющим на логический проект

требованиям, относятся:

Рис. 6.22.

Окно Редактора кода VB с кодом

скриптового языка Visul Basic for Application

(VBA) MS Excel (справа)

и команды меню отладки (слева)

(Debug – дебаггер, отладчик)

148

 практичность (usability)

 гибкость (flexibility)

 интероперабельность (interoperability)

 кроссплатформенность (crossplatform)

 переносимость (мобильность, портабельность) (mobility)

 адаптируемость (adaptability)

6.5.5.Проектирование интерфейса и служб пользователя.

Интерфейс пользователя (UI) представляет службы для организации

полнофункциональной работы с приложением. Это означает, что он

предоставляет средства для выполнения следующих операций:

 перемещения компонентов;

 ввода данных;



представления данных;

 вывода данных;

 манипулирования с данными;



помощи пользователю (help).

В зависимости от конкретной реализации, интерфейс пользователя может

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

Кроме того, он может быть и набором сценариев в виде Web-страниц,

отображаемых в браузере. Под «пользователем» приложения обычно

понимается человек, использующий приложение, поэтому под интерфейсом

пользователя понимаются формы, элементы управления, отчеты и другие

объекты, предоставляемые конечному пользователю для взаимодействия с

приложением и данными. Однако «пользователь» приложения не обязательно

означает человека: другое приложение тоже можно считать пользователем. В

этом случае под интерфейсом пользователя подразумевается средство

взаимодействия программ, обеспечивающее совместную работу приложений.

6.5.6.Разработка физического проекта. После того, как была

спроектирована модель данных, созданы концептуальный и логический проекты,

спроектирован интерфейс пользователя и службы приложения, требуется

выполнить работы, касающиеся физического проекта решения. Это

подразумевает следующую деятельность:

 оценку физического проекта;

 проектирование компонентов;

 разработку стратегии доступа к базе данных.

Физический проект определяет реализацию приложения и используемые

для этого технологии. Как правило, есть несколько путей реализации, из

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

проекта используются те же самые семь ключевых факторов, что и для оценки

логического проекта. Как и для логического проекта, точные критерии оценки

физического проекта определяются конкретным решением, но, как правило, для

физического проекта наиболее существенными ограничениями являются

требования к достижению оптимальных характеристик показателей:

производительности, сопровождаемости, расширяемости, доступности,

масштабируемости и безопасности. Особого внимания требуют также и такие

области разработки, как проектирование компонентов (component design) и

организация доступа к базам данных (database access). Проектные решения в

этих областях могут сильно повлиять на многие характеристики

149

производительности функционирования приложения.

6.5.7.Разворачивание и сопровождение решения. После того как

приложения были реализованы и оттестированы, начинается разворачивание

системы. Когда система развёрнута и верифицирована, ее нужно

сопровождать. И развёртывание, и сопровождение чрезвычайно важны для

общего успеха приложения не только у настоящего, но и у будущих заказчиков.

6.6.Какие существуют приложения?

Как правило, разработка приложения состоит из проектирования,

моделирования, создания прототипа и в конечном итоге его реализации и

тестирования. На фазах проектирования и моделирования разрабатывается

архитектура приложения, которая частично зависит и от архитектуры

вычислительной среды. Почти все приложения содержат код представления,

код обработки данных и код обращения к хранилищам данных. Архитектура

приложения определяет то, как будет организован этот код. Анализ и

проектирование являются неотъемлемой частью процесса разработки

приложения. Разрабатывая архитектуру приложения, следует тщательно

обдумывать последствия, вытекающие из проектных решений. Перед тем как

начать проектирование, имеет смысл определиться с типом будущего

приложения. Для описания характеристик приложения или типа приложения

используется целый ряд терминов, в том числе (табл.. 6.2):

Таблица 6.2.

Тип приложения в зависимости от архитектуры, в которой оно выполняется

Названия приложения

 настольное;

 контейнер;

 распределённое;

 клиент-серверное;

 SDI;

 MDI;

 консольное;



диалоговое (мастер, Wizard);

 одноярусное;

 двухъярусное;

 многоярусное (N-уровневое);

 Web-приложение;

 совместно работающие приложения;

 компонент;

 сетевой сервис или

Web-сервис.

По смыслу эти термины перекрывают сферы действия друг

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

представляют собой комбинацию нескольких вышеуказанных типов.

Охарактеризуем кратко каждое из вышеуказанных приложений.

 Настольные (desktop) приложения — это приложения, которые выполня-

ются на одном компьютере и используются одним пользователем. Настольные

приложения размещаются на жёстком диске компьютера пользователя и

работают только с локальными ресурсами данного ПК. Настольные

приложения могут быть основаны на двухярусной архитектуре, которая

подразумевает обращение к сетевому серверу за данными.