«Основы проектирования корпоративных систем»

Основы проектирования корпоративных систем (fb2) - Основы проектирования корпоративных систем 5614K скачать: (fb2) - (epub) - (mobi) - Сергей Викторович Зыков

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

© Зыков С.В., 2012

© Оформление. Издательский дом Высшей школы экономики, 2012

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

© Электронная версия книги подготовлена компанией ЛитРес ()

Предисловие

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

Современные корпоративные системы – это петабайты (тысячи терабайт) данных, как минимум, удвоение объема информации каждые пять лет, необходимость адаптации к требованиям бизнеса практически «на лету», архитектурная и структурная разнородность компонентов и, конечно, глобальная распределенность. В подобных условиях обобщения до уровня технологических схем и инструментальных средств, как правило, не приводят к адекватной интеграции гетерогенных приложений в унифицированные, крупномасштабные программные системы. Поэтому для управления жизненным циклом корпоративных программных комплексов необходимо прежде всего получить адекватное обобщение на уровне математических моделей с последующей конкретизацией представлений на уровне системной архитектуры, информационных технологий, а также конкретных инструментальных и программных средств и, наконец, практических внедрений.

Предлагаемое в настоящей работе методологическое обобщение включает весь спектр возможных (и, как оказывается, необходимых) уровней представления данных в корпоративных программных комплексах в ходе их разработки. К таковым следует отнести прежде всего уровни:

1) математического моделирования концептуального представления;

2) анализа и проектирования архитектурной схемы;

3) реализации, интеграции и адаптации/расширения программных систем.

Естественно, все перечисленные уровни необходимы, взаимозависимы и взаимосвязаны: математические модели адекватно поддержаны промышленными технологиями, инструментально-программными средствами и приводят к отраслевым внедрениям гетерогенных корпоративных программных комплексов с практически приемлемыми эксплуатационными характеристиками.

Для построения генерализации корпоративных программных комплексов на уровне моделей – как для представления данных, так и для манипулирования ими – потребовался творческий синтез основных положений целого ряда математических теорий, связанных с объектными моделями. В основе рассматриваемых моделей лежит так называемый аппликативный подход к вычислениям, при котором в фокусе внимания находится операция приложения функции к аргументу. Дальнейшее развитие созданной методологии разработки программных систем корпоративного типа – поддержка разработанных моделей программными технологиями, системными архитектурами и инструментальными средствами.

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

Автор выражает искреннюю благодарность ведущим экспертам университета Carnegie Mellon (G. Taran, N. Bier и др.), а также профессорам С.М. Авдошину (НИУ ВШЭ) и В.Э. Вольфенгагену (МИФИ, МФТИ) за методическую помощь при подготовке монографии.

Отдельно следует отметить целый ряд студентов НИУ ВШЭ и МФТИ (в первую очередь К. Лузгину, Е. Первушину, А. Ядройцева, а также многих других), ассистировавших при предварительном редактировании теста и активно способствовавших выходу в свет настоящей публикации.

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

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

Глава 1 Введение в разработку корпоративных систем

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

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

Предметом исследования выступают корпоративные информационные системы. Здесь значимо каждое слово. И корпоративная специфика – специфика крупных распределенных предприятий, и понятие системы, т. е. достаточно сложной совокупности различных компонентов, и, конечно, собственно информационной системы как вполне определенного подвида. Назначение данной книги состоит в том, чтобы: дать базовые, фундаментальные представления о предмете, продемонстрировать применение моделей к разработке корпоративных систем, правда, не совсем в математическом понимании этого слова; ввести основные понятия, обозначить их взаимосвязи и применение к корпоративной специфике, описать современную теорию и практику разработки корпоративных приложений.

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

Цель курса – формирование целостной концепции проектирования и реализации, иными словами, разработки, корпоративных приложений в современных условиях. Будет применяться подход Карнеги-Мелонского университета к дисциплине «Software engineering» (программная инженерия), в том смысле, что некоторые его математические модели будут далее упомянуты. В целом необходимо сосредоточиться на теории, которая адекватно поддерживает практику, и именно в том необходимом объеме, который поможет правильно составить систему понятий. А также придерживаться этой системы в соответствии с той многочисленной литературой, которая имеется по предмету, для того чтобы иметь возможность грамотно и с хорошим теоретическим обоснованием говорить о таком непростом и многообразном предмете, как корпоративные информационные системы.

Кроме того, речь пойдет о разработке хорошего стиля проектирования систем. Под хорошим стилем нужно понимать многофакторную оптимизацию, т. е. достаточно сложный процесс – совокупность процессов, которые сопровождают развитие информационных систем. В любом проекте по разработке корпоративных систем имеет место треугольник компромиссов: функциональность, стоимость, временные затраты. То есть существует ряд ограничений, которые необходимо учитывать, и для создания хорошего продукта следует уметь находить компромисс.

Кроме того, когда речь пойдет о жизненном цикле программных систем, этапах их развития, проектирования, реализации, внедрения и сопровождения, будут описаны практические примеры их внедрения, а также даны необходимые знания, которые требуются для получения основных навыков, характеризующих такого важного специалиста в разработке корпоративных информационных систем, как системный архитектор – человек, который отвечает за проектирование информационных систем с технологической точки зрения.

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

Необходимая основа – некоторое понимание моделей, на которых базируется объектный подход к проектированию и реализации программных систем. С математической точки зрения моделью объекта может являться функция. Часто речь будет идти о λ-исчислении и других моделях об исчислении функций, которые представляют собой фундамент моделирования, в том числе информационных систем, и вообще фундамент для объектных моделей. Что касается основ проектирования и программирования – желательны знания в области объектно-ориентированного подхода к проектированию и разработке приложений и основ технологий Microsoft, в частности Microsoft.NET.

В конце книги будут даны некоторые практические решения: на базе группы компаний «Итера» и на основе технологий Microsoft, в том числе программного обеспечения Microsoft Dynamics. Будет использована открытая информация, которая имеется на сайтах Microsoft, связанных с Dynamics, а также другие открытые источники информации.

Во введении говорится о корпорации как о большой распределенной группе компаний с общими задачами, о программных системах, приложениях как конкретизации этого понятия для решения тех или иных прикладных задач, о жизненном цикле этих систем – от анализа и проектирования до реализации, внедрения, сопровождения и вывода из эксплуатации. Также речь идет о документации, которая сопровождает этот жизненный цикл и без которой, собственно говоря, программный продукт, передаваемый заказчику, таковым не является. Рассказано, что такое методология, как можно ее понимать в узком и широком смысле. Обсуждены основные этапы жизненного цикла программных систем, в том числе соответствующие жизненному циклу корпоративных систем, и, кроме того, представлены основные методологии разработки прикладных программных систем.

Описание корпоративных информационных системах следует начать с понятия корпораций. Под корпорацией понимается крупная (от 1000 сотрудников), территориально распределенная (часто по всему земному шару) глобальная, трансконтинентальная производстенная структура, т. е. бизнес-структура, которая нацелена на производство продукции. Достаточно большие корпорации, например нефтегазовые, – Газпром, известная крупная и распределенная структура реального сектора экономики, TNK-BP, где объединены ресурсы как отечественных, так и зарубежных производителей нефти и газа, и нефтегазовая группа компаний «Итера», объединяющая порядка 150 компаний в 24 странах мира с общей численностью персонала 10 тыс. человек. Несмотря на распределенность структуры, у корпорации, как правило, есть единый центр управления и общие бизнес-цели и задачи.

Следует отметить, что корпорацию можно понимать и шире. Можно относить к корпорациям и не вполне производственные, но тем не менее распределенные и объединенные общими бизнес-целями структуры. С точки зрения корпоративных информационных систем это вполне допустимый угол зрения. Так, в качестве примера корпоративной структуры можно рассматривать Минпромэнерго, научно-исследовательские учреждения, такие как ИПУ РАН, который включают не менее 10 филиалов по России, университеты, такие как МИФИ, НИУ ВШЭ. ВШЭ имеет около 20 различных площадок только в Москве, МИФИ является также достаточно распределенной структурой с точки зрения как студенческого городка, так и распределенности по территории России. Все эти и другие аналогичные структуры вполне можно отнести к корпорациям.

Теперь остановимся на программных системах. Они представляют собой совокупность программ под общим управлением, т. е. примерно так же, как и корпорация как группа компаний – это совокупность взаимодействующих программ. При этом программная система предназначена для решения либо некой замкнутой задачи, либо целого ряда взаимосвязанных задач. И если мы говорим о корпоративной системе, там таких задач достаточно много: это учет, планирование и управление различного рода ресурсами, прежде всего людскими, финансовыми и специфическими производственными ресурсами, основными средствами, процессом производства и целым рядом других процессов.

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

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

В любой информационной системе, и корпоративной в том числе, каждое приложение, которое функционирует в рамках этой системы, проходит определенные этапы своего становления и развития. Как правило, последовательность этих этапов остается неизменной. Хотя в зависимости от методологий проектирования и разработки применяемых корпоративных систем эта последовательность может претерпевать незначительные изменения, существует ряд этапов и фазы, которые определяют жизненный цикл программных систем. Первым этапом является постановка задачи, т. е. определение характера и масштаба того программного решения, которое будет разработано. Следующий этап связан с анализом требований, которые выдвигает заказчик к программной системе, с анализом того, насколько эти требования адекватны, корректны, полны, непротиворечивы, насколько они соответствуют характеру и масштабу проблемы и полно и точно описывают ту предметную область и задачу, которую должно решать программное обеспечение. Исходя из анализа требований строятся проектные спецификации – это следующий этап жизненного цикла программных систем. На основе проектных спецификаций в форме диаграмм, сценариев использования, т. е. определенных достаточно формально изложенных текстовых данных и технического задания в том числе, происходит проектирование программной системы. Это следующий этап жизненного цикла – построение в некотором абстрактном виде, прежде всего в форме диаграмм, основных функций, которые эта система будет реализовывать. По сути, речь идет о поэтапной детализации от абстрактного представления к конкретному в ходе развития системы вдоль ее жизненного цикла.

После проектирования, т. е. после того, как все основные объекты, которые будут реализованы в рамках информационной системы, получили свои очертания и становится известно, какими характеристиками они будут обладать, как будут взаимодействовать друг с другом, начинается этап реализации. Это – программирование, кодирование отдельных частей программной системы, которая декомпозирована на них в ходе этапа проектирования. Реализацию сопровождает тестирование программного продукта, которое призвано ответить на вопрос, насколько это программное обеспечение корректно, нет ли в нем внутренних ошибок. Еще один важный вопрос, на который должно ответить тестирование, – в какой мере разработанное программное обеспечение соответствует тем проектным спецификациям и требованиям, которые были к нему сформулированы. Если тестирование не выявляет существенного количества критического уровня ошибок, то можно переходить к фазе передачи заказчику, когда на основе специально созданной серии приемочных тестов осуществляют приемку и передачу в эксплуатацию созданной программной системы или компонента корпоративной информационной системы.

После передачи заказчику наступает фаза сопровождения, которая собственно и является основной, наиболее важной, значимой и затратной частью жизненного цикла (ЖЦ) программной системы. Нужно понимать, что ЖЦ – это процесс прежде всего непрерывный, т. е. переход от стадии к стадии обязан происходить и происходит достаточно плавно, каждая предыдущая стадия является основой для последующей, в том числе и документация, которая выступает достаточно важной составляющей по программному продукту, во многих случаях является «сырьем» для начала и успешного завершения следующей стадии. Жизненный цикл – процесс замкнутый, потому как достаточно сложно переходить с одной стадии к другой, миновав промежуточную. Если говорить о корпоративных системах, то, как правило, это не вполне корректный переход. Кроме того, еще одна важная особенность жизненного цикла – его итеративность, т. е. то, что жизненный цикл происходит итерационно.

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

Если говорить о процессе разработки информационной системы, в том числе и корпоративной, то, по сути, в широком смысле речь идет о полном жизненном цикле. В разработке корпоративных информационных систем предполагается, что речь идет о жизненном цикле от начала до завершения в широком смысле. Однако если говорить более узко, то можно рассматривать лишь ту часть жизненного цикла, которая связана с кодированием и программированием, но в случае корпоративных систем это является слишком ограниченным подходом. Какие стадии связаны непосредственно с кодированием или программированием? Это проектирование системы, когда речь уже идет о построении скелета реализации, некоего наброска основы разрабатываемой программной системы, т. е., по сути, речь идет уже о работе с CASE-средствами, со средствами автоматизированного проектирования программного обеспечения, которые обладают возможностями кодогенерации для некоторых стандартных компонентов, составляющих основу программной системы. Затем происходит реализация системы – кодирование. После этого реализация ведется вместе с тестированием, и после реализации фрагментов программной системы происходит их интеграция, сборка, которая также связана с тестированием, и передача заказчику. Может быть также стадия сопровождения.

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

Еще одно важное определение – это методология разработки информационных систем – корпоративных и преимущественно ИС. Под методологией будем понимать подход, подразумевающий совокупность методов или практических приемов, нацеленный на завершение отдельно взятой фазы, или стадии, или ряда стадий, которые могут быть взаимосвязаны, жизненного цикла программного обеспечения.

Фазы ЖЦ ПО только что были перечислены – это анализ и спецификация требований, первичное детальное проектирование, реализация вместе с тестированием, интеграция или сборка, когда появляется сначала частичный, затем полный программный продукт, финальное тестирование продукта, приемочное тестирование и передача заказчику и, наконец, сопровождение и вывод из эксплуатации. В дальнейшем речь пойдет о практических приемах и более общих методах, которые необходимы для корректного завершения каждой из этих стадий в соответствии с различными подходами. При этом методология может включать применение моделей, методов и средств. Модели – более формальное представление элементов или этапов, необходимых для реализации действий по разработке ЖЦ программных систем. Это прежде всего математические или другие формальные модели, скажем, модель виртуальной машины, функционирующей в среде Microsoft.NET, во многом основана на абстрактной машине, разработанной Юрием Гуревичем (специалист Microsoft Research). Модель носит формальный характер – она является математической моделью, основанной на понятии «состояние».

Кроме того, методология может включать методы, т. е. техники, которые являются менее формализованными. Одним из примеров может являться подход Microsoft Solution Framework, который содержит так называемые вехи (milestones) и результаты (deliverables). Кроме того, методология может включать (и в случае корпоративных систем, как правило, включает) применение специфических инструментальных средств, которые поддерживают весь жизненный цикл ПО. Это и анализ и разработка требований, и проектирование, преимущественно в форме диаграммирования, составления различных UML-диаграмм, кодирование и тестирование, Microsoft использует целый ряд специальных средств тестирования при реализации подхода MSF – реализация, отладка. Одним из примеров является Microsoft Visual Studio.NET, также поддерживается командная работа на основе Teamsystem или Teamsuit. Примерами классов таких средств являются средства быстрого прототипирования (rapid application development), CASE-средства компьютерной поддержки и разработки программного обеспечения или автоматизированной поддержки разработки ПО. Системы управления корпоративным контентом и целый ряд классов других систем.

Продолжим описание методологий разработки информационных систем и попробуем сосредоточиться на их пригодности – пригодности рассматриваемых классов методологии разработки информационных систем в отношении корпоративных систем. Если говорить о международных стандартах или методологиях, то это прежде всего IDEF-диаграммы и подходы, связанные со стандартом ISO. Федеральные российские стандарты – это стандарты ГОСТ и ESPD. В НИУ ВШЭ есть внутренний стандарт для производства документации, он достаточно четко отслеживается, даже при создании студентами курсовых проектов документация готовится в этих форматах.

Существует также целый ряд корпоративных стандартов, которые используются иногда несколько шире, чем предполагают пределы этих корпораций, – Rational Unified Process (RUP), который используется в и за пределами IBM, MSF, используемый преимущественно в Microsoft. Есть подход, который используется внутри корпорации Oracle, – CDM (Custom Development Method), который тоже во многом является корпоративным и вне стен Oracle, как правило, не используется.

Перечисленные подходы RUP, MSF, CDM можно отнести к корпоративным: они достаточно всеобъемлющи, широки и действительно охватывают полный жизненный цикл программных систем корпоративного типа, вполне применимы и по качеству подготовки документации, и по характеру и масштабу процессов для получения полномасштабных корпоративных информационных систем. Другие подходы, такие как Agile, eXtreme Programming (XP), Scrum, являются в некотором смысле ограниченными, в частности потому, что не всегда поддерживают полномасштабную документацию, и выход по проекту в полном смысле этого слова не может быть назван корпоративным программным решением. Эти подходы хороши для проектов с большой неопределенностью, которые характеризуются высокими рисками, когда изначально традиционные методологии, перечисленные в разделе корпоративных, могут не вполне адекватно работать. На самом деле нет гарантии, что сработает и один из этих подходов, но все же они разрабатывались специально для того, чтобы вести такие высокорисковые, сложные и неопределенные проекты. Конечно, в полном смысле такие подходы, как Agile, X P, Scrum, нельзя назвать корпоративными. Они не приводят к решениям корпоративного типа[1].

Таким образом, существует целая иерархия подходов к разработке систем. При этом то, что называется моделями ЖЦ (каскадная, спиральная модель) и методологии (такие как RUP, XP) – это во многом параллельные направления разработки корпоративных информационных систем. То есть работая в рамках RUP или, скажем, MSF, можно вести проектирование ИС по спиральной или каскадной модели. Эти понятия не являются взаимоисключащими, скорее они дополняют друг друга. В этой связи модели и методологии являются понятиями ортогональными. Остановимся на тех методологиях, которые представляют основной интерес с точки зрения проектирования информационных систем и применимости для корпоративных ИС.

Первые подходы – это ГОСТ, ISO, т. е. стандарты. Это достаточно всеобъемлющий список документов, которые призваны поддерживать процессы проектирования и разработку программных продуктов корпоративного типа. Однако в практике проектирования часто это идет вразрез с интересами и требованиями заказчика, т. е. часто проектирование и подготовка полномасштабной документации по ГОСТ и ESPD являются избыточными, и западные стандарты ряд документов не поддерживает или поддерживает в ограниченном объеме.

В следующих главах будут более подробно рассмотрены RUP, MSF, CDM и гибкие методы Agile, X P, Scrum, которые в определенном смысле и в определенной степени могут применяться для корпоративных систем и при этом являются достаточно прагматичными. Если говорить о RUP, он может включать как каскадный, так и спиральный вариант проектирования с точки зрения модели жизненного цикла, но в целом он основан на итеративном подходе и включает быстрое прототипирование. Быстрое прототипирование, в принципе, можно выделить как модель жизненного цикла, но эта модель не является самостоятельной – она не поддерживает разработку боевого кода программной системы, т. е. не позволяет получить достаточно хорошо документированный и надежный код с точки зрения работоспособности и количества ошибок. Кроме того, этот код недостаточно масштабируем, он не рассчитан на большое количество одновременных пользователей и на те функциональные ограничения по количеству пользователей, по пропускной способности сети, по нагрузке на серверы программного обеспечения, по работе с базами данных, которые будут испытывать полномасштабные версии корпоративной информационной системы. Поэтому быстрое прототипирование достаточно хорошо как дополнительный подход, метод и модель жизненного цикла, который применяется в рамках RUP вместе с итеративным подходом. Этапы жизненного цикла здесь называются потоками. В явном виде выделяются роли. Ниже будет подробнее изложено об этом и о том, как производится документация, какие артефакты процессов, связанных с RUP, важны для ИС, корпоративных ИС.

Другой подход связан с синтезом каскадной и спиральной моделей – это MSF. Важные аспекты этого подхода – синхронизация и стабилизация. В основе проектирования программного обеспечения по этой схеме лежит процессный подход. Процессы, активности будут описаны подробнее в главе, которая будет посвящена этой тематике.

Еще один менее известный и используемый подход, более жесткий с точки зрения детерминированности и определенности этапов ЖЦ и связанный с каскадной моделью преимущественно – это Oracle CDM. Он используется для производства программных систем, в том числе и корпоративных программных систем, на основе продуктов Oracle – это Oracle Enterprise/Database Server, Oracle Business Suit, семейство модулей, которые предназначены для ERP, учета, планирования и управления корпоративными ресурсами: людскими, финансовыми и производственными ресурсами, прошлым документооборотом и целым рядом других ресурсов. При внедрении Oracle Applications сейчас вполне может использоваться этот подход. Также важно, что он включает прототипирование, это позволяет облегчить и удешевить процессы проектирования.

Гибкие методологии, о которых мы будем говорить отдельно, – Agile, X P, Scrum. Они основаны на итеративном подходе к ЖЦ, т. е. последовательном уточнении программного продукта по мере согласованием с пользователем требований к нему. Поскольку продукты, которые разрабатываются в рамках этих методологий, имеют изначально достаточно высокую степень неопределенности, в этой связи важно понятие рефакторинга, или последовательного улучшения кода. Также достаточно распространенное применение получили так называемые лучшие практики, или некоторые неформальные критерии и приемы разработки программного обеспечения. Неформальные потому, что сложно разработать количественные методы оценки этих критериев и в ряде подходов эти практики могут использоваться как в полном объеме, так и в некотором подмножестве. Эти подходы наиболее гибки.

Нужно заметить, что и MSF, и RUP имеют некий диапазон возможных вариаций для разработки программных систем того или иного класса и масштаба. То есть, в принципе, можно использовать MSF и RUP не только для корпоративных систем, но и с некоторыми ограничениями и упрощениями – для систем меньшего класса. Для этого также существуют специальные ограничения, специальные подходы – так сказать, урезанные, сокращенные методологии. Такие подходы позволяют сэкономить на жизненном цикле, на производственном процессе как по времени, так и по людским ресурсам, а в итоге – по стоимости.

Завершая рассказ о введении в корпоративные информационные системы, нужно сделать следующие основные выводы. Понятие системы возникает, когда речь идет о корпорации – большой, территориально распределенной производственной структуре с общими бизнес-задачами, но с различными направлениями деятельности, с различными языками реализации, т. е. требуется локализация для разных стран тех систем, которые внедряются. Вообще говоря, программное обеспечение, которое производится для корпорации, представляет собой комплекс систем, которые нацелены на анализ, учет, планирование и управление различными областями деятельности этой корпорации. При этом такой комплекс имеет достаточно сложную схему взаимодействия. Одним из возможных решений по объединению такого рода систем является корпоративный портал. Эти программные компоненты создаются на основе различных архитектурных подходов. Это могут быть мейнфреймы, системы на основе архитектуры файл – сервер, клиент – сервер, интернет-архитектуры, различных технологий баз данных, например Oracle, Microsoft и т. д. Это могут быть системы, которые хранят информацию различной степени структурированности: хорошо структурированные реляционные таблицы, слабо структурированные аудиовидеоданные, отсканированные документы с нечетко определенными полями и т. д. Поэтому схемы взаимодействия элементов этого комплекса достаточно сложны. И для того чтобы понимать важность этих задач, необходимо представлять себе сложность. Это терабайты информации, в ряде случаев – уже петабайт. Так, скажем, информационные системы корпорации Intel в своей совокупности представляют уже несколько петабайт, т. е. крайне большой объем информации. В этой связи корпоративные информационные системы представляют собой достаточно сложный объект для исследования. Такие системы достаточно быстро растут: за пять лет объемы данных примерно удваиваются. То есть можно говорить о быстром росте объемов данных, в этой связи еще сложнее становится управлять такими большими программными комплексами.

Это только некоторые аспекты. Вообще разработка информационных систем – это многоаспектный процесс. В течение разработки информационная система проходит целый ряд стадий, связанных с так называемым жизненным циклом. Это и анализ и спецификация требований, и проектирование – первичное и детальное, и реализация, тестирование, интеграция, передача заказчику в эксплуатацию, сопровождение. То есть это достаточно сложный процесс последовательно сменяющих друг друга стадий. Тем не менее этот процесс является замкнутым и итерационным: ряд стадий при отдельных подходах, скажем, при спиральной, эволюционной, инкрементной моделях, последовательно повторяется. Конечно, для того чтобы говорить о корпоративных системах, нужно достаточно детально и полно представлять себе все этапы этого жизненного цикла, взаимодействие этих этапов и ту документацию, которая производится на каждом этапе и является во многом основой такого (в том числе документального) взаимодействия. При каскадном подходе нельзя перейти к следующему этапу, если предыдущий этап документально не закрыт и на соответствующем документе, который подтверждает корректность и финализацию этого этапа, не появляется подпись ответственного лица. В этой связи нужно представлять себе всю схему ЖЦ, для того чтобы корректно выбрать модели, методы и средства, которые включают в себя те методологии проектирования КИС, о которых мы будем говорить дальше.

Остановися подробнее на жизненном цикле ПО (ЖЦ ПО). В начале главы уже были упомянуты его основные этапы. Фазы, которые связаны с разработкой программных систем, включают: анализ и спецификацию требований к программному продукту, проектирование программного продукта – первичное и детальное, уточненное, реализацию и тестирование элементов или модулей отдельного программного продукта, интеграцию или сборку этих модулей в частичный или полный программный продукт вместе с интеграционным тестированием, передачу заказчику после приемочных тестов, промышленную или опытную эксплуатацию, которая называется сопровождением и занимает по времени и средствам основную часть жизненного цикла, и, наконец, вывод из эксплуатации. Для реализации этого жизненного цикла применяются различные модели, методы и инструментальные средства. Подробнее рассмотрим основные этапы ЖЦ.

Прежде всего определим, что такое ЖЦ и в чем состоят его особенности для систем корпоративного типа. Ведь речь идет о действительно больших системах, которые включают терабайты данных разных степеней структурированности, географически распределены по земному шару и между которыми нужно наладить взаимодействие для получения консолидированной отчетной информации по основным видам корпоративных ресурсов. Будут рассмотрены основные этапы ЖЦ: анализ и спецификация требований, эскизное и детальное проектирование, реализация и тестирование, сопровождение и вывод из эксплуатации – и экономическая специфика этапов ЖЦ ПО. При этом будет упомянуто не только о стоимости затрат, но и об их структуре, на основе анализа большого количества проектов, который был произведен в частности компанией HP и другими компаниями, здесь будут приведены оценки, сделанные Карнеги-Мелонским университетом. И, что очень важно, будет рассмотрена связь этапов ЖЦ с различными моделями.

Модели, методы и инструментальные средства – это, так сказать, три кита, три основных составляющих, на которых стоит все проектирование, разработка корпоративных, в том числе информационных, систем. Эффективная разработка немыслима без использования средств автоматизированного проектирования, или CASE-средств. При описании производства как промышленного процесса необходимо упомянуть о тех метриках, которые позволяют определить и ограничить программный продукт и приходить к определенным выводам на основании анализа этих метрик. Это позволит ответить на вопросы: следует ли уже прекратить сборочное тестирование и начинать тестирование продукта, достаточно ли качественным является этот продукт, не превосходит ли существующее количество ошибок некое пороговое значение.

Как оценить сложность ПО? Достаточно ли, скажем, для этого ограничиться количеством строк кода? Или существуют другие метрики оценки? Например, количество операторов, операндов и т. д. Как пользоваться этими метриками и насколько они эффективны? Ведь процесс производства ПО должен быть конвейерным, таким, чтобы методологии и модели работали для большого количества программных продуктов и проектирование проводилось по единообразной схеме.

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

В разработке ПО существуют определенные сложности и проблемы, которые нужно решать со стороны как разработчика, так и системного архитектора и даже руководителя программного проекта. Необходимо достичь определенного уровня качества, которое связано с теми метриками, о которых уже было сказано: порог ошибок, интерфейс пользователя, эргономичность, масштабируемость, количество одновременных пользователей, количество транзакций, время реакции системы и объем БД. Программный продукт должен удовлетворять этим метрикам при определенном дефиците ресурсов, имеющем место в любом проекте и который в любом случае достаточно жестко контролируется в ходе программных проектов. Это возрастающая сложность программных систем. Корпоративные системы – это десятки взаимодействующих систем, каждая из которых объединяет зачастую сотни первичных сущностей и часто терабайты данных, т. е. это очень сложные программные системы, которые достаточно быстро растут и которым необходимо взаимодействовать друг с другом.

В ходе выполнения программных проектов приходится часто сталкиваться с нехваткой ресурсов: людских, временных, финансовых. Происходит постоянное взаимодействие с заказчиком, который часто изменяет требования, и в ряде случаев, эти изменения могут носить для разработчика достаточно сложный и плохо предсказуемый характер, иногда эволюционный, иногда революционный. При этом необходимо, в зависимости от пути или степени изменения этих сложностей и требований, корректировать модели ЖЦ и, соответствующим образом, очередность стадий ЖЦ программных продуктов.

Еще один важный аспект – это проектная команда, взаимодействие большого количества участников. Под участниками в ряде случаев понимаются представители не только разработчика, но и заказчика, которые входят в состав software quality assurance – группы контроля качества продукта. Если даже исключить их из рассмотрения, а в ряде методологий, в особенности гибких (Agile, X P, Scrum), эти представители присутствуют и играют достаточно активную роль, то в любом случае на стороне разработчика есть целая проектная команда (может быть не одна), работу которой нужно координировать. В больших программных системах это большой объем человеко-часов и большое количество исполнителей с разными мотивациями, целями и задачами. В этом смысле, при большом количестве участников, необходимо управлять процессом, привлекая к этому CASE-средства (автоматизированного проектирования) – это тоже достаточно сложно. При этом важной проблемой является моральное устаревание программного обеспечения.

В следующих главах будет подробнее изложено о понятии Software Engineering (программная инженерия), которое возникло в конце 1960-х гг. на конференции NATO, когда обсуждалась аналогия между любым процессом промышленного производства (в частности, строительством мостов) и строительством программного обеспечения, программной архитектурой. Вообще достаточно часто в литературе, связанной с ПО, возникают аналогии между архитектурным строительством сооружений, зданий, мостов и программными проектами. В отношении Software Engineering – тут не все так просто. Ряд методов, которые работают в первом случае, не подходят для программной инженерии. Программное обеспечение морально устаревает – и это происходит достаточно быстро. Посмотрим, например, на скорость смены ОС Windows – это происходит примерно раз в 5 лет, может и чаще. В то же время многие дома и мосты морально не устаревают гораздо дольше, в течение сотен лет. Таким образом, проблемы разработки ПО во многом более динамичны, чем проблемы целого ряда отраслей реального сектора экономики. Кроме того, разработка ПО растет высокими темпами. Для ряда компаний это направление является единственным, основным, определяющим. Необходимо успеть до того, как выйдут на рынок продукты конкурентов, опередить их и обеспечить высокое качество продукции, совместив его с достаточно быстрым вводом в эксплуатацию. Кроме того, это очень большое количество новых отраслей народного хозяйства. Достаточно сказать о такой новой отрасли, как нанотехнологии – это очень быстрая, конкурентная отрасль, которая затрагивает целый ряд промышленных технологий и направлений, требует оперативного знакомства предметных экспертов и системных аналитиков с совершенно новыми понятиями. Таким образом, получается достаточно большое количество взаимосвязанных и взаимодополняющих проблем, которые существенно осложняют разработку ПО, особенно в корпоративных системах.

Графическое представление ограничений на разработку приложений можно описать следующим образом. Это некоторая модификация традиционного проектного треугольника, который связан с затратами времени, средств и функционала. Приблизительно можно увидеть это как три оси. Где-то внутри этого треугольника находится оптимальное сочетание этих параметров, которое и удается обеспечить при адекватном сочетании моделей, методов и средств проектирования корпоративных информационных систем и программных приложений в целом.

Какие ограничения можно увидеть при разработке приложений, в том числе корпоративных? На процессы разработки воздействует целый ряд факторов. Это, конечно, объем кода, который можно измерить в тысячах строк. Корпоративные продукты – это десятки, сотни тысяч строк и более, в зависимости от характера и масштаба этих систем. Это, конечно, очень большая сложность. Каждый отдельно взятый модуль таких систем, как, например, Oracle Applications, представляет собой несколько сотен первичных сущностей. Для того чтобы охватить их взглядом, требуется очень серьезная фундаментальная предметная подготовка, аналитический взгляд, профессионализм и использование специализированных средств автоматизированного проектирования. Кроме того, существует целый ряд ограничений, которые связаны с людскими ресурсами. Естественно, человеку охватить такое количество сущностей и грамотно строить процессы проектирования, разработки, которые включают и тестирование, постановку задачи, анализ и спецификацию требований, естественно, очень сложно. Эти процессы нужно грамотно координировать, чтобы команда давала отдачу от того, что используется такой большой коллектив, и не появлялись чрезмерные затраты на обучение все новых и новых членов команды по мере того, как проект расширяется и в него вовлекаются новые силы и средства.

Кроме того, обучение тормозит процессы разработки. Нужно понимать, что в разработке новой системы в рамках существующего корпоративного программного комплекса заказчик зачастую не может остановить свои ключевые бизнес-процессы. И пусть ценой дополнительных затрат унаследованные системы, работающие на мейнфреймах или устаревших архитектурах, все же обеспечивают поддержку этих бизнес-процессов. И при интеграции новых систем в существующую программную среду заказчика необходимо обеспечить корректность и адекватность этой интеграции и функционирование расширенного комплекса новой системой. Это нужно сделать для того, чтобы этот новый комплекс позволял извлечь больше информации, консолидировать данные и в итоге давал возможность руководству получить аналог приборной панели, на которой оно сможет видеть результаты, достигнутые компанией по финансам, по кадрам, по материальным и производственным ресурсам. Результаты можно будет представить в виде срезов, проекций с детализацией до отдельных стран, компаний, подразделений и сотрудников, и это позволит плавно масштабировать и анализировать эти результаты, строить тренды, прогнозы перспектив развития.

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

В чем состоит современный подход к решению всех этих проблем? Проблемы, связанные с важностью, высокотехнологичностью и ограничениями, которые диктует рынок: конкурентная среда, время, которое жестко ограничивает регламенты проектирования корпоративных систем, и ряд других проблем, которые усугубляются корпоративным характером информационных систем, сложностью и большим объемом приложений. Конечно, можно прибегнуть к методам анализа и систематизации тех знаний, которые уже существуют, и которые были получены имперически при разработке первых подобных проектов, подобного класса и масштаба. И здесь на помощь приходит программная инженерия, то есть целый ряд дисциплин, которые связаны с процессами управления проектированием программных систем, построением архитектурных основ такого рода информационных систем и, конечно, разработки, проектированию и реализации, включая тестирование и сопровождение, то есть управление ЖЦ такого рода программных систем и их комплексов.

Глава 2 Обзор жизненного цикла корпоративных систем

Программная инженерия, или инженерия программного обеспечения, представляет собой область компьютерной науки, которая занимается построением программных систем, т. е. целого ряда взаимодействующих компонентов программного обеспечения, которые являются настолько большими или сложными, что для построения такого рода систем требуется участие команды или даже взаимодействующих команд разработчиков. Под разработчиками здесь понимаются не только программисты, но и аналитики, постановщики задач, тестировщики, системные архитекторы, документаторы, специалисты по контролю качества ПО и персонал сопровождения. То есть это достаточно большая команда, которая нацелена на производство того или иного программного продукта в уже существующей среде информационных систем заказчика. Поэтому очень важен подход к организации на всех уровнях и во всех перечисленных аспектах разработки программного обеспечения: анализ и спецификация требований, первичное и детальное проектирование, реализация и тестирование, интеграция, передача заказчику, сопровождение.

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

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

Процитируем В.А. Липаева – патриарха отечественной программной инженерии. В книге «Программная инженерия» он привел следующее определение: «Под программной инженерией понимается комплекс задач, методов, средств и технологий создания, то есть проектирования и реализации сложных, расширяемых, тиражируемых, высококачественных программных систем, возможно включающих базы данных»[2]. Каждое слово в этом определении в полной мере применимо к корпоративным системам.

Согласно определению Липаева эта отрасль науки как раз и направлена на создание корпоративных информационных систем. И ввиду того, что они являются сложными, т. е. содержат большое количество первичных сущностей, большими по объему (тера-, петабайты данных) и расширяемыми, как правило, речь не идет о том, что мы революционным образом сразу заменяем все системы, которые используются в корпоративном программном комплексе. Чаще всего производится доработка какой-то отдельной системы. Они являются высококачественными и часто тиражируемыми.

Некоторые из примеров таких решений – Microsoft Dynamics, Oracle Applications и т. д. Под высоким качеством понимается и масштабируемость – плавное снижение производительности при достаточно резком увеличении интенсивности нагрузки на систему. Кроме того, нужно сказать, что эти системы должны быть надежными, вести себя предсказуемо, быть эргономичными, сопровождаемыми, т. е. должны быть настроены на то, чтобы обеспечивать достаточно гибкое и относительно эволюционное взаимодействие с пользователем на этапе опытной и промышленной эксплуатации. В определении также речь идет о проектировании и реализации, т. е. уже о полном жизненном цикле ПО. Важным дополнением является то, что информационные системы включают в ряде случаев базы данных. Если мы говорим о корпоративных системах, базы данных, как правило, являются неотъемлемой, важной частью этих систем. Другое дело, что эти базы данных могут строиться на различных принципах, являться гетерогенными, включать объектные составляющие, т. е. быть не чисто реляционными. Последние версии СУБД Oracle называются объектно-реляционными. Есть СУБД нового поколения, такие как O2, Orion и др., которые используют не только реляционные, но и другие, более новые объектно-ориентированные модели.

В корпоративных информационных системах необходимо разделять понятия программного проекта и программного продукта. В настоящем издании речь пойдет в основном о программных продуктах, т. е. о взгляде на ЖЦ с точки зрения системного архитектора. А с точки зрения программного проекта – это взгляд менеджера проектов, когда речь идет об управлении проектной командой, проектами, взаимодействием людей в проекте, сроками, стоимостью. С другой стороны, если говорить о программной инженерии, то речь может идти о разработке продукта для конкретного заказчика, но преимущественно и предпочтительно планировать все процессы и технологии, связанные с разработкой таким образом, чтобы по возможности обеспечить производство продукта, нацеленного на более широкую аудиторию потребителей, а в идеале сделать его коробочным или тиражируемым. Целесообразно обеспечить высокий процент повторного многократного использования элементов проекта – это и код, и документация, и структура СУБД, и программная архитектура, с тем чтобы при доработке проекта для «похожего» заказчика было затрачено минимум времени, средств и людских ресурсов.

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

Чем характеризуется программный продукт? Во-первых, как правило, он имеет определенную коммерческую ценность. Это значит не то, что не существует условно бесплатных программных продуктов, а что этот продукт решает конкретную задачу конкретного класса пользователей, потребителей продукта. Таким образом, продукт может называться рыночным и быть предложен рынку для удовлетворения его определенных потребностей и решения конкретных бизнес-задач. Какие примеры программного продукта можно привести? Часто это физические объекты, скажем, информационные носители (DVD, CD и т. д.), но это могут быть и нематериальные соглашения, такие как лицензия, соглашение о партнерстве и пр. Еще одним примером может выступать услуга по внедрению, сопровождению, консалтингу и т. д.

Программные продукты можно классифицировать по разным основаниям. Один из видов классификации – масштаб использования: это и личное использование, и некоммерческое, и коммерческое как коробочный продукт для широкого класса организаций и предприятий. Другой способ классификации – цель использования. Это может быть специализированное ПО, нацеленное на решение достаточно узкой задачи, например расчетное ПО для решения астрономических задач, лазерной дальнометрии, или ПО более общего назначения, такое как операционная система, офисные продукты и т. п. Еще один вид классификации – степень открытости. При этом можно говорить о компонентной ориентированности, скажем, API, библиотеки, такие как, например, библиотека классов Enterprise Libraries, которая используется для надстройки над. NET для построения Microsoft-продуктов корпоративного типа, библиотека классов для построения офисных приложений и т. д. или готовые продукты.

Любая разработка ПО происходит согласно жизненному циклу и включает последовательное прохождение стадий ЖЦ, о которых мы уже упоминали и которые в широком смысле начинаются с концепции или базовой идеи и заканчиваются выводом из эксплуатации.

Вообще говоря, понятие ЖЦ можно использовать и применительно к другим классам систем, например, к таким системам, как архитектурные сооружения, однако ЖЦ программных систем (ПС) имеет свои особенности. ПС разрабатывается постепенно и развивается от концепции, абстрактной идеи и далее конкретизируется до программного продукта, который включает в себя не только код, но и большое количество документации – это диаграммы, документация к коду, документация для пользователей по работе с программным продуктом, для администраторов по настройке, установке и сопровождению и т. д. Программные системы заканчиваются на этапе вывода из эксплуатации, который завершает сопровождение.

Каждый этап ЖЦ завершается разработкой некоторой части системы – она может быть полнофункциональной или не совсем полнофункциональной. Это зависит от конкретной модели ЖЦ. Каждый этап завершается производством документации, которая включает более глобальные артефакты, такие как план проекта, план тестирования, план реализации, план сопровождения, или более узкие документы, такие как сценарии использования, руководство администратора, краткое руководство пользователя, основные требования к проекту или более детальные требования в форме технического задания. Объем, характер и масштаб документации зависят от характера и масштаба программного продукта. Конечно, для каждого этапа производства ПО должны быть четко определены начальные и конечные временные точки, а также известны элементы, которые должны быть переданы следующему этапу, с точки зрения кода, документации, базы знаний. На практике все обстоит сложнее, но в любом случае, если мы говорим о технологии проектирования ПО, то каждый этап ЖЦ с определенностью завершается производством некоторого нового продукта и новой документации к нему.

Изучение жизненного цикла корпоративных программных систем необходимо прежде всего для понимания организации разработки ПО, т. е. всех процессов, которые связаны с ЖЦ. Не поняв того, как устроен ЖЦ вообще, нельзя говорить о сколько-нибудь планомерной организации и управлении этими процессами. Конечно, из успешных проектов нужно делать выводы и тиражировать принципы, которые привели нас к успеху, практические шаги и методы, которые дают возможность эффективно и планомерно развивать проекты, совершенствовать программные продукты, взаимодействие с пользователями, производство документации и все процессы, которые лежат в основе жизненного цикла. Это необходимо делать на основе анализа результатов работы над предыдущими проектами, и тут может помочь и план проекта, и другие глобальные документы (план тестирования, интеграции, реализации, сопровождения), а также вся проектная документация, которая была создана, а кроме того, журналы ошибок и документы, создающиеся на этапе сопровождения программного продукта. В этом смысле изучение ЖЦ дает важную основу для анализа разработки ПО, которая позволяет более тщательно планировать и производить процессы, лежащие в основе ЖЦ, и тиражировать таким образом внутреннюю методологию, которая будет разработана и развита командой разработчиков. Так можно прийти к корректной и адекватной постановке и адаптации. Конечно, для каждого программного проекта, как правило, приходится иметь дело с некой стандартной методикой, методологией, в том числе с учетом всего предыдущего опыта, и с необходимостью адаптировать его с учетом характера и масштаба проекта к конкретному заказчику и конкретным условиям производства продукта. Важно помнить, что у заказчика имеется определенная и, как правило, уникальная комбинация программно-аппаратной среды, в которую предстоит интегрировать программный продукт. Это особенно важно применительно к корпоративным системам, поскольку обусловливает большое количество взаимосвязей и значительный объем и сложность этого программного окружения и в целом корпоративного программного комплекса. Таким образом, анализ ЖЦ – необходимая стадия для крупных и сложных программных проектов, каковым является КИС.

При разговоре о ЖЦ необходимо сделать ряд важных замечаний. Прежде всего, нужно сказать, что процесс ЖЦ как создания, так и смены стадий ПО включает целый ряд сторон. Как минимум, это представители заказчика, представители разработчика и руководство. При этом представители заказчика – те, кто будут принимать продукт, во многом технически грамотные люди. В итоге они входят в группу контроля качества программного продукта. Со стороны разработчика – это весьма широкий спектр специалистов: аналитики, оценщики рисков, проектировщики, системные архитекторы, документаторы, программисты, тестировщики, специалисты по созданию приемочных тестов, специалисты по сопровождению. И руководство, которое разделяется, например, как в MSF, на руководителя проекта и руководителя продукта. То есть у руководства тоже различные цели, не говоря уже о том, что у руководства заказчиков и руководства разработчика они во многом расходятся.

У этих разных сторон зачастую совершенно различные цели и ожидания от продукта, от того, какую функциональность он должен реализовывать, и от проектных ограничений и по срокам, и по стоимости, и по функциональности и даже различное понимание определенных терминов и особенностей. Ведь заказчик смотрит на процесс производства ПО, достаточно хорошо понимая свои производственные потребности, но он может не вполне владеть особенностями производства ПО, которые приняты у разработчиков. И в этой связи даже разумные взгляды, подходы и отношения к ЖЦ, к тем требованиям и ограничениям, которые имеются у заказчика и разработчика и различных представителей заказчика и разработчика на различных уровнях, могут приводить к значительному увеличению сроков и стоимости проекта. Большое значение имеет согласование этих подходов между разработчиком и заказчиком: нужно прийти к некоему общему пониманию, прежде всего ограничений проекта. И надо помнить, что заказчик тут стремится ограничить проект снизу, заявить о том, что количество пользователей не может быть меньше, чем некое число, и т. д. А разработчик должен прийти к соглашению с заказчиком (к юридическому документу, техническому заданию, списку-требованию или какому-то иному документу). Разработчик при этом стремится ограничить проект сверху (количество пользователей, пропускная способность), т. е. показать, что технологии, которые используются, и бюджет, который заложен в проект, не могут обеспечить производительность более установленного предела.

Выше были перечислены некоторые участники проекта: руководитель портфеля проекта, менеджер проекта, руководитель команды, эксперт в предметной области, предметный аналитик, другие классы аналитиков, системный архитектор, проектировщик подсистемы или модулей ПО, специалисты по пользовательскому интерфейсу, в том числе по его тестированию, созданию его эргономики, кодировщики, сборщики, тест-менеджеры (создатели юнит-тестов, модульных, приемочных, сборочных тестов), тестировщики, руководители групп тестирования, технические писатели и целый ряд других. Эти роли обозначают только классы участников проекта, а классы конкретизируются в крупных проектах большим количеством участников. Взаимодействие между ними – это достаточно сложная задача с точки зрения управления и проектом, и продуктом. В дальнейшем мы будем говорить преимущественно об управлении продуктом.

Какой же целью задаются разработчики? Главная цель – это создать хороший продукт. (Что такое «хороший», будет расшифрованно далее, а также какие именно факторы разработки ПО должны в первую очередь приниматься во внимание.)

Следует напомнить, что производство ПО представляет собой многофакторную оптимизацию, поскольку, по сути, разработчикам необходимо согласовывать с заказчиком некий взгляд и набор требований к проекту. Это будет основным сырьем, по которому будет создаваться программный продукт, включающий документацию. При этом выход по программному обеспечению может быть множественным, потому как очень часто приходится сталкиваться с ситуацией, когда существует огромное количество вариаций кода, которое решает поставленные перед разработчиком задачи. При этом, если говорить о ЖЦ ПО, следует нужным, предсказуемым и правильным образом с точки зрения сроков, стоимости и функциональности обеспечить выбор методологии этого ЖЦ. Необходимо показать, каким образом будут меняться фазы и сколько раз, сколько итераций нужно будет для того, чтобы получить продукт должной функциональности, сложности и качества. При этом производится многомерная, многофакторная оптимизация, которая учитывает прежде всего следующие параметры: сроки выполнения проекта, стоимость продукта, качество продукта как по документации, так и по коду. Качество документации можно отслеживать трассировкой документации, сопоставлением артефактов, или элементов документации, на внутреннюю корректность, на соответствие друг другу, на полноту, на непротиворечивость, на целостность и на соответствие исходной постановке задачи. Также важным фактором оптимизации является сопровождаемость – обеспечение сокращений затрат на самую ресурсоемкую часть ЖЦ продукта. Важно сказать, что приоритетность факторов не жестко детерминирована, а во многом определяется характером и масштабом программного проекта. О каких масштабах имеет смысл говорить в отношении корпоративных программных систем? Для малых систем масштаб условно можно ограничивать 10 человеко-годами, для средних систем – 10–100, для больших – 100–1000 человеко-лет. Несколько тысяч – это уже огромные системы. Корпоративные системы – скорее от 100 человеко-лет и выше. То есть это весьма большие затраты, но это не означает, что не нужно искать возможности для экономии. Конечно, это нужно делать, и в первую очередь можно сэкономить гораздо существеннее на внедрении корпоративного приложения.

Нужно сказать, что продукт и проект – это различные понятия и, вообще говоря, те стадии, которые учитывают ЖЦ продукта несколько шире и включают в себя оценку возможности создания этого проекта и концептуальную основу проекта, идею, с которой он начинается. ЖЦ проекта во многом завершается при передаче в эксплуатацию каждого конкретного релиза этого продукта. ЖЦ продукта включает и сопровождение, и эксплуатацию, и вывод из эксплуатации.

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

Можно рассмотреть более подробно экономику ЖЦ на основе сопоставления критериев развития, скорости роста бизнеса и доли рынка, которую занимает программный продукт. Здесь, в начале пути, нужны инвестиции, поскольку неизвестно о дальнейшей судьбе программного продукта. Затем программный продукт выходит на рынок, приносит доход и, наконец, прибыль, и это без существенных затрат на поддержку продаж. Через некоторое время наступает этап, когда доходы относительно невысоки и продажи влекут за собой существенные затраты.

Если вернуться к описанию стадий ЖЦ ПО, то в ходе анализа можно выделить, что существует целый ряд стадий, которые практически не зависят от применяемых методологий разработки программных систем. Эти стадии включают анализ требований к программному продукту, подготовку проектных спецификаций программного продукта, проектирование (эскизное, первичное, детальное, окончательное, рабочее), реализацию, тестирование (модульное, компонентов), интеграцию (вместе с тестированием), сопровождение, вывод из эксплуатации.

Важной составляющей продукта является не только код, но и документация. Достаточно распространено заблуждение, что документация не нужна или ею можно пренебречь. Документация – очень важный выход по программному продукту. Если вы является разработчиками или вам приходилось разрабатывать продукт, то достаточно вспомнить о вашем коде, который вы пытались читать спустя несколько лет после его создания. Наверное, вы помните, что это не очень легко без хорошей документации. На стадии сопровождения, когда приходится читать чужой код, что на самом деле не очень просто, и код читает человек, который имеет достаточно средний уровень знаний программирования, конечно, человеку сложно читать код, если он был вне этого проекта. Но, как правило, именно это и происходит. Становится понятно, что без документации читать такой код практически невозможно. Например, в корпорации Microsoft проектная команда собирается исключительно для создания программного продукта, и после этого, как правило, люди друг с другом больше не встречаются. Таким образом, поддержка кода осуществляется исключительно благодаря той документации, которая его сопровождает, поэтому роль документации очень велика, затраты на нее существенно окупаются, и только она обеспечивает гибкость и мягкость сопровождения. После сопровождения происходит снятие с эксплуатации. Еще очень важно: документация обеспечивает взаимосвязь этапов жизненного цикла. То есть те документы, которые производятся на этапе анализа требований, являются сырьем для подготовки проектных спецификаций, которые в свою очередь являются сырьем для проектирования. Документация по проектированию – это большое количество диаграмм, сценариев использования и пр., являющихся основой для реализации, и т. д. Таким образом, документирование является неотъемлемым атрибутом каждой стадии ЖЦ ПО.

Перечислим более подробно, что происходит на каждой стадии ЖЦ ПО. Первой стадией является анализ требований. При этом происходит встреча, как правило неоднократная, представителей разработчика и представителей заказчика. Целью является достижение общего понимания той самой задачи, на решение которой и будет направлено ПО, производящееся в интересах заказчика. Конечно, в ряде случаев заказчик может не обладать полнотой знаний о тех технологических особенностях ведения проекта, построения программного продукта, которые имеются у разработчика в том опыте проектной команды, тех технологиях, стандартах, которые применяются для проектирования, реализации и передачи заказчику. Очень часто заказчик может быть не вполне технически грамотным, но он имеет достаточно четкое представление о предметной области, в рамках которой должно быть произведено программное решение. С другой стороны, разработчик часто имеет ограниченное представление об особенностях той самой предметной области. Если говорить о нефтегазовой среде, например, то достаточно важным может быть представление результатов исследования сейсмической активности земной коры, в том числе в трехмерной динамике – трехмерное представление геологических данных о земной коре с учетом динамики. Это весьма специфический вид данных, который может не вполне адекватно восприниматься и анализироваться разработчиком, поскольку на стороне разработчика сложно найти специалистов в области геологии.

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

Следующая стадия – подготовка проектных спецификаций. Она происходит на основе описания требований, т. е. тех документов, которые получены на предыдущей стадии ЖЦ. Эта и следующие стадии являются в основном прерогативой разработчика. Хотя в ряде методологий проектирования и реализаций программных комплексов, таких гибких, как Agile, X P, Scrum, заказчик участвует на всех этапах ЖЦ ПО. Для больших корпоративных систем, как правило, разработка ведется по методологиям RUP или MSF, и там основным действующим лицом является разработчик. Проектные спецификации содержат описания всей функциональности проекта и всех основных ограничений, желательно выраженных количественно. Здесь уже можно ограничить и программное обеспечение, и технологии, которые будут использованы, и архитектуру (например, сделать выбор между платформами Java или. NET). Необходимо четко ограничить количество одновременных пользователей, количество подключений, транзакций и их интенсивность, пропускную способность канала и ряд других параметров. При этом методологию или модель разработки ПО – каскадную, эволюционную, спиральную или иную – следует выбрать как можно раньше, поскольку выбор методологии или модели ЖЦ определяющим образом сказывается на сроках, стоимости и успехах проекта. Проектные спецификации должны ограничивать сроки и стоимость проекта исходя из договоренностей, которые достигли разработчик и заказчик на предыдущем этапе.

Далее на основе проектных спецификаций производится детальное проектирование, которое описывает программную архитектуру с учетом всех компонентов проекта. В случае объектно-ориентированного подхода это модули и интерфейсы между ними, компоненты и средства их взаимодействия в условиях той программной среды, которой располагает заказчик. Однако в больших корпоративных системах всегда присутствует некоторое количество взаимодействующих систем, которые уже работают у заказчика, и, как правило, разработчики приходят к заказчику с предложениями, которые учитывают эти условия программной и аппаратной среды. У заказчика может быть множество серверов, например серверы баз данных, кэш-серверы, серверы безопасности, серверы, отвечающие за телекоммуникации, и пр. Детальное проектирование также выполняется разработчиком. Кроме написания программной архитектуры, детальное проектирование на выходе дает документы, которые описывают все программные модули корпоративного комплекса.

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

Код программного продукта создается помодульно исходя из компонентов, которые были определены на предыдущем шаге. Реализация производится разработчиком на основе документов детального проектирования с учетом общего плана проекта, поскольку необходимо принимать важные решения об ограничении тестирования, сроках реализации индивидуальных модулей и переходе к интеграции и последующим стадиям, которые определяют успех передачи заказчику, с одной стороны, и качество программного обеспечения, с другой. Поэтому общий план проекта, который включает глобальные ограничения на сроки и стоимость, а также на важнейшие функциональные параметры и ограничения программного продукта, должен быть принят во внимание на этой стадии для обеспечения корректности, предсказуемости и качества процесса реализации. Реализация – это стадия, за которую отвечает разработчик, т. е. кодировщики, тестировщики. Разрабатываются отдельные модули – небольшие подсистемы, которые решают замкнутые задачи и для которых на предыдущем этапе уже заданы основные параметры, такие как алгоритмы и структуры данных, переменные – локальные и глобальные, основные (в случае ООП) структуры классов – их основные атрибуты и методы. В результате мы получаем отдельные программные модули, каждый из которых является уже реализованным и протестированным прежде всего самим разработчиком на внутреннюю корректность и на соответствие проектным спецификациям по отдельности. После реализации и на самом этапе реализации важными документами являются документы, связанные с тестированием, такие как: юнит-тесты, проектная документация к каждому модулю, краткое описание модулей, их назначение и интерфейсы, взаимосвязь с другими модулями, основные характеристики, атрибуты, методы, алгоритмы и структуры данных модуля, документация к коду, которая позволит достаточно легко читать и анализировать даже без запуска кода и без разработчика.

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

В первый раз ПО разворачивается у заказчика на его реальном программном и аппаратном окружении и реальных данных в тех объемах, которые определяются условиями эксплуатации корпоративных программных комплексов заказчика. Если все приемочные тесты, которые производятся заказчиком, успешны, т. е. продукт ведет себя надежно, корректно, соответствует функциональным требованиям, вписывается в программно-аппаратное обеспечение заказчика, то происходит передача программного продукта вместе с документацией заказчику и наступает фаза эксплуатации. Эта фаза относительно ЖЦ называется фазой сопровождения.

С точки зрения экономики сопровождение – самый затратный этап ЖЦ (порядка 2/3 стоимости всего проекта) как по времени, так и по средствам. Нужно понимать, что сопровождение необходимо для любого ПО. Цель при разработке – не просто передача программного продукта заказчику, а продолжение продуктивных отношений с этим заказчиком. Задачами сопровождения программного продукта являются ликвидация ошибок, которые остались в программном продукте, коррекция проектных спецификаций, улучшение производительности и учет особенностей новой программной и аппаратной среды заказчика, если таковые имеются. Сопровождение включает следующие виды:

• корректирующее сопровождение (устранение существующих в продукте ошибок без изменения проектных спецификаций);

• обновляющее сопровождение (внесение изменений в спецификации, функциональная коррекция ПО, изготовление нового релиза, улучшающего ПО, с целью при сохранении функциональности увеличения производительности, пропускной способности, количества одновременных пользователей, количества транзакций и т. д.);

• адаптивное сопровождение (адаптация продукта к новой программно-аппаратной среде).

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

Рассмотрим подробнее, каким образом осуществляется этап эксплуатации ПО заказчиком, называемый сопровождением. Сопровождение начинается по завершении приемочного тестирования программного продукта, как только все приемочные тесты, которые созданы зачастую с участием или в присутствии закачика, проходят успешно в реальной среде заказчика, т. е. на его программно-аппаратном обеспечении, с реальными данными (как по объему, так и по содержанию), и заказчик удовлетворен результатами. Естественно, заказчику передается весь программный продукт, т. е. не только код, но и документация, которая включает в себя и сценарии использования, описывающие основную функциональность продукта при разном использовании, и диаграммы классов. Последние описывают основные модули и функции этих модулей в форме методов, взаимодействие между этими классами, а также предметную область, скелетные файлы классов или заготовки сигнатур классов с описанием функциональности этих классов или модулей, взаимодействий с соседними модулями, локальных и глобальных переменных, алгоритмов и структур данных, на основе которых будет работать данный программный продукт, диаграммы последовательности взаимодействия, которые характеризуют как архитектурные особенности программного решения, так и соотношения между различными его составляющими, диаграммы клиент – объект и др. Документация, включающая описание программного продукта с точки зрения пользователя, – это краткое описание основной функциональности, полнофункциональная инструкция пользователя с указанием возможных ошибок, которые могут возникать в работе ПО, описание работы всех его модулей с необходимыми скриншотами, определение терминов, которые могут встречаться в процессе описания программного обеспечения. При этом существует целый ряд видов сопровождения, которые нацелены на решение специфических задач.

Корректирующее сопровождение – необходимый вид. Оно заключается в устранении остаточных сбоев, т. е. существенных ошибок в реализации ПО, которые, несмотря на проведенное тестирование, все еще остаются в продукте и выявляются только расширенным тестированием заказчиком уже в ходе эксплуатации. Естественно, несмотря на то что количество ошибок при тестировании убывает экспоненциально, невозможно устранить все ошибки, и, конечно, большое количество пользователей в различных ситуациях работы одновременно с реальными данными дают возможность выявить достаточно существенное количество весьма серьезных ошибок. Речь идет не о незначительных ошибках, а о таких, которые приводят к остановке системы, критическим сбоям, потере данных, невозможности продолжения работы и т. д. При этом корректирующее сопровождение не включает в себя изменение функциональных требований: речь не идет о переработке продукта с добавлением новой функциональности, речь идет о коррекции.

Другой вид – обновляющее сопровождение, которое как раз нацелено на добавление новой функциональности. Заказчик в ходе эксплуатации ПО достаточно часто приходит к выводу, что некоторые функции, которые не были заложены в изначальных проектных спецификациях, было бы полезно реализовать. Это может происходить по разным причинам: возможно, возникали определенные сложности с бюджетом или сроками реализации, а в процессе эксплуатации возникла потребность добавления новой функциональности (на примере интернет-магазина: не хватает возможности оплаты по кредитным картам, это ведет за собой множество новых требований), что потребует новой итерации разработки, выпуска нового релиза или нового продукта. С точки зрения контракта речь пойдет о дополнительном соглашении к договору, которое предусматривает реализацию этой новой функциональности.

Еще один вид сопровождения – улучшающее, когда заказчик удовлетворен той функциональностью, которая реализована, но возникают дополнительные нефункциональные требования, связанные с тем, что нужно увеличить производительность. На примере интернет-магазина: может возникнуть проблема в пропускной способности интернет-канала из-за того, что количество пользователей существенно превышает запланированное. Ограничениям не удовлетворяет уже и тот сервер БД, который был использован, и та интенсивность транзакций (если они вообще используются) и общая производительность системы, которая для пользователя иногда уже является неудовлетворительной, при этом речь не идет об изменении функциональности.

И еще один вид сопровождения связан с миграцией существующего программного окружения в новую среду. Под программным окружением мы понимаем все множество информационных систем, имеющееся у заказчика, которое как раз и перемещается (например, под управлением новой ОС, нового сервера БД и т. д.). Здесь речь идет уже о том, что необходимо обеспечить интеграцию существующих программных продуктов у заказчика с теми новыми возможностями, которые дают новые программные или аппаратные системы, на которые переходит заказчик. Следует разрабатывать программные продукты таким образом, чтобы они были сопровождаемыми. Сопровождение – это необходимый этап ЖЦ любого проекта, каким бы малым он ни был и какие бы ни были отношения с заказчиком. Почему сопровождение так важно? Во-первых, оно позволяет выстроить продуктивные, долговременные отношения с заказчиком, поскольку именно этот этап, ради которого собственно и создается ПО, этап промышленной эксплуатации, как правило, является достаточно продолжительно (обычно несколько лет). Именно на этом этапе взаимодействие с заказчиком приносит дополнительные доходы за счет всех вышеописанных вариантов сопровождения. Вторым важным аспектом является то, что сопровождение дает возможность перейти к программному продукту, который можно использовать повторно. То есть тот программный продукт, который делался для конкретного заказчика, наверняка, если он хорошо сопровождается, может быть после небольших доработок предложен другому заказчику. Чем правильнее проходит этап сопровождения, тем больше вероятность того, что выпущенный продукт будет устраивать большое количество заказчиков, а в перспективе может быть реализован как коробочный продукт. В этой связи даже для небольших продуктов сопровождение важно. Следующей стадией является вывод из эксплуатации. Это не самая интересная, может быть, не самая радостная стадия, поскольку ПО верой и правдой служило заказчику достаточно долгое время, к нему уже привыкли, сложились внутренние регламенты, существуют документы, процедуры, пользователям понятно это ПО, они уже достаточно хорошо в нем ориентируются. Но в ряде случаев приходится заказчику сделать вывод о том, что снятие с эксплуатации необходимо. Почему это может быть так? Потому что ПО, в отличие, например, от архитектурных сооружений, морально устаревает достаточно быстро, так как стремительно меняются программные и аппаратные платформы, и в ряде случаев заказчику становится уже невыгодно осуществлять дорогостоящее сопровождение того решения, которое было разработано. Приходится переходить на новое ПО, поддерживающее совершенно новую функциональность, реализация которой слишком дорогостоящая для текущей эксплуатируемой версии. При этом если ряд функций ПО и данные являются еще необходимыми, то важно при миграции обеспечить экспорт данных в новое приложение. Этот процесс непрямолинейный и непростой. Но крайне нежелательно, особенно на уровне КИС с большим количеством важных данных и важностью динамики этих данных, терять эти данные и параметры. Вывод из эксплуатации возможен только на основе взвешенного решения, которое включает оценку стоимости. Стоимость замены ПО включает целый ряд факторов: стоимость смены технологий (стоимость нового ПО, стоимость лицензий), стоимость разработки и поддержки приложений на основе нового ПО, затраты на обучение персонала, потеря производительности труда персонала в переходный период, поскольку с новым ПО всегда достаточно сложно работать. В ряде случаев вывод из эксплуатации осуществляется вынужденно (например, при обнаружении существенной несовместимости).

Важный проектный документ – план проекта, который включает все стадии ЖЦ: анализ и спецификация требований, первичное и детальное проектирование, реализация, тестирование, интеграция, приемочное тестирование, передача заказчику и сопровождение, вывод из эксплуатации. План проекта также включает основные оценки таких важных измерений проекта, как сроки, стоимость, в том числе в виде общего расписания проекта, которое содержит основные виды деятельности и вехи (milestones, основные границы достижения некоторых результатов). В MSF также важно понятие deliverables – практические результаты, которые получены по достижении каждой вехи. Кроме того, план проекта включает некие более локальные планы: план управления рисками, план тестирования, план интеграции и другие глобальные документы, о которых мы будем говорить дальше.

ЖЦ ПО в зависимости от конкретных его моделей может иметь ряд особенностей. Скажем, проектная спецификация, или написание отдельных компонентов проекта, или особенности архитектуры могут быть не в полной мере детализированы или определены – это зависит от конкретной модели. В ряде моделей существует однопроходный ЖЦ, когда система полностью разрабатывается за один проход по всем стадиям ЖЦ. В других моделях осуществляется итеративное или циклическое повторение этапов ЖЦ с наращиванием или изменением функциональности.

Существует классический подход к разработке ПО на основе структурного анализа и проектирования (structural analysis and development), которое не учитывает ряд аспектов, в частности, в ряде случаев специфику компонентов или модулей кода и выбор языка программирования сложно осуществить до завершения проектных спецификаций (при объектном подходе, например, это можно сделать). Неструктурные аспекты, динамические аспекты проектирования здесь тоже не учитываются. Кроме того, достаточно сложно осуществить столь масштабное повторное использование кода, как это делается в объектно-ориентированной модели и в подходе, связанном с объектно-ориентированным анализом и проектированием. Нужно сказать, что повторное использование кода – это, пожалуй, важнейшая цель организации ЖЦ ПО. Проблема здесь в том, что ножницы между возможным повторным использованием не только кода, но и других артефактов проекта (документация) составляют до половины стоимости проекта. На этом можно существенно экономить во времени, средствах и людских ресурсах. Но это довольно сложно сделать, так как повторное использование требует хорошей дисциплины проекта, грамотного использования специфических средств. Мы должны к этому стремиться, ряд моделей ЖЦ учитывает это в достаточно большой степени. Кроме того, нужно понимать, что границы фаз ЖЦ могут изменяться и даже перекрываться, в том числе динамически по мере изменения требований в зависимости от модели ЖЦ (например, это имеет место в объектно-ориентированной модели).

В связи с тем что ЖЦ продукта проходит ряд стадий, очевидна необходимость проводить вывод из эксплуатации и переходить к новой версии.

Достаточно интересным является взгляд на вклад различных фаз ЖЦ программных проектов в сроки и стоимость. Анализ произведен на основе целого ряда проектов (порядка 1000), которые велись компанией HP и др. Очевидно, что сопровождение составляет львиную долю стоимости и сроков проекта. При этом такие стадии, как кодирование, даже вместе с тестированием, и анализ требований, даже вместе с изготовлением спецификаций, занимают относительно небольшую долю стоимости. Можно сделать ряд интересных выводов на основе анализа этой динамики. Основные затраты выделяются на сопровождение. Особенно это важно для корпоративных проектов, которые являются долгосрочными и включают большое количество компонентов, которые нужно объединять, интегрировать и поддерживать совместно, что вызывает дополнительные сложности. Кроме того, программные средства, которые увеличивают расширяемость применения ПО, более эффективны, чем все попытки рефакторинга улучшения кода. Еще один интересный вывод состоит в том, что фазы перед кодированием и после него составляют порядка 30 % затрат, а собственно кодирование при этом составляет всего 5 %. То есть то, что называется программированием, для больших проектов отнюдь не является затратной частью. Обрамляющие стадии (тестирование и коррекция спецификаций) обеспечивают существенное улучшение качества ПО и его соответствие требованиям. Нужно сказать, что правильная постановка обрамляющих стадий очень важна и ускоряет кодирование.

Большая часть серьезных ошибок, которые выявляются в программных проектах, происходит на стадиях проектирования и построения спецификаций. Поэтому эти ошибки очень дорогостоящи, поскольку приходится переделывать и код, и документацию, и нужны формальные методы их анализа (это и ревизия проекта, и более формальные логические технологии проверки корректности). Цена ошибки растет примерно экспоненциально по мере продвижения проекта по жизненному циклу. Если ошибка обнаруживается на стадии анализа требований, то ее исправление достаточно дешево. Если же она обнаружена на более поздних стадиях, особенно на стадии сопровождения, то ее цена во много раз выше, потому что приходится изменять всю версию ПО, документацию, диаграммы и целый ряд других программных продуктов. К счастью, есть специальные средства для поиска, выявления и устранения ошибок.

Каждая фаза ЖЦ ПО включает три важных составляющих – процессы, методы и средства. Под процессами понимают задачи, которые необходимо реализовать, они отличаются и, по сути, не зависят друг от друга. Методы – это относительно формальное описание каждой задачи процесса. Средства – автоматический инструментарий типа CASE-средств для поддержки процессов и методов.

Ниже перечислены основные виды моделей ЖЦ, которые будут подробнее рассмотрены в следующих главах: это прежде всего модель Build-and-fix – «кодируй и фиксируй», по сути, она близка к модели проб и ошибок; затем – водопадная модель, которая дает возможность за один проход ЖЦ построить полномасштабное программное обеспечение; модель быстрого прототипирования, которая, как правило, объединяется с другими моделями; инкрементальная модель с последовательным наращиванием функциональности; модель синхронизации и стабилизации, или модель Microsoft; спиральная модель, в которой очень важна оценка рисков и которая тоже подразумевает циклическую обработку продукта по мере его движения к пользователю; объектно-ориентированная модель с перекрытием ряда фаз и во многом циклическим или итерационным развитием.

Какие общие черты можно выделить в перечисленных моделях ЖЦ? Как правило, они включают все его стадии, за исключением модели Build-and-fix. Кроме того, предполагается несколько итераций по разработке продукта, за исключением каскадной модели. Как правило, стадии ЖЦ четко различимы, кроме объектно-ориентированной модели, где они могут объединяться. Некоторые отдельные модели, связанные с некоторыми методологиями проектирования, такие как модель синхронизации и стабилизации, связаны с методологией MSF. RUP поддерживает каскадные и спиральные сценарии жизненного цикла и т. д.

Грамотное применение модели ЖЦ требует высокой организационной зрелости команды и серьезной дисциплины проекта с точки зрения стандартов документирования, кодирования, использования специализированных CASE-средств и т. д. Если такие знания недостаточны, то объектно-ориентированная модель может выродиться в такую модель, как Build-and-fix, т. е. можно потерять все преимущества модели и увеличить затраты.

Таким образом, универсальной модели ЖЦ не существует, все определяется характером и масштабом проекта. Каждая модель имеет свои преимущества и свои недостатки. Об этом мы поговорим подробнее в следующей главе.

Что определяют модели ЖЦ программных продуктов? Во-первых, характер и масштаб проекта. В этой связи, как только при анализе и спецификации требований и ограничений определены основные границы проекта и продукта, в идеале следует определиться с совокупностью моделей, которые будут выбраны. Здесь критичны объем продукта, сроки и проектные риски. Скажем, спиральная модель существенно связана с использованием рисков, поэтому ее имеет смысл применять в случаях, когда необходим анализ рисков. Модели определяют экономику проекта, в том числе и скорость возврата инвестиций. В случае если нет острой необходимости применять модель полного ЖЦ, можно сэкономить на отдельных стадиях, например если не нужно разрабатывать документацию в полном объеме. Модель определяет степень сопровождаемости: в ряде моделей мы можем получить продукт, который будет более сопровождаемым. Модели ЖЦ определяют также перспективы развития – насколько можно будет удовлетворить будущие запросы клиента. Также модели ЖЦ определяют общую структуру проекта с точки зрения его эволюционного или революционного совершенствования: потребуются ли радикальные изменения или можно ограничиться архитектурой, в которой проект будет стабильно эволюционировать. Модели определяют скорость поиска и устранения ошибок, например, модель синхронизации и стабилизации нацелена на частое раннее тестирование. Некоторые модели, как уже отмечалось, способствуют хорошему управлению рисками проекта. Кроме того, отдельные модели подразумевают изготовление прототипов (модель быстрого прототипирования, инкрементальная модель), другие требуют изготовления готового продукта сразу же.

Какие особенности ЖЦ можно выделить уже в первом приближении для конкретных моделей? Модель Build-and-fix – это модель неполного ЖЦ, которая пригодна для малых проектов (≈1000 строк) и абсолютно непригодна для больших и сложных проектов с большим потенциалом развития. Водопадная, или каскадная, модель обеспечивает хорошую обратную связь с ранними стадиями ЖЦ, поскольку завершается подготовкой документов, которые позволяют перейти к следующей стадии. Без этих документов, без корректного закрытия предыдущей стадии невозможно начало следующей. Быстрое прототипирование – несамостоятельная модель, не приводящая к созданию надежного кода. Инкрементальная модель всегда дает возможность получить на каждом этапе готовый продукт, пусть и неполнофункциональный. Модель синхронизации и стабилизации, или модель Microsoft, нацелена на раннее выявление ошибок. Спиральная модель подразумевает несколько итераций и нацелена на анализ рисков. Объектно-ориентированная модель – это итеративное проектирование с перекрытием фаз и наложением их друг на друга.

Уже говорилось о том, что цена поиска ошибок экспоненциально растет по мере продвижения к завершению, поэтому ошибки нужно обнаруживать как можно раньше. Для этого существуют специальные методы, которые содержатся на всех стадиях жизненного цикла и включают процессы, методы и средства.

Кратко остановимся на преимуществах и недостатках различных моделей ЖЦ.

Модель Build-and-fix хороша для небольших проектов, которые не требуют сопровождения, но абсолютно непригодна для корпоративных или вообще нетривиальных проектов объемом более 1000 строк.

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

Модель быстрого прототипирования вызывает соблазн повторного использования кода, который не является достаточно протестированным, хорошо задокументированным и который, вообще говоря, следует заново реализовать как ненадежный. Но эта модель позволяет выявить соответствие ПО требованиям клиента, т. е. обеспечить анализ требований и выявление наиболее важных для клиента.

Инкрементальная модель способствует хорошей сопровождаемости за счет того, что получается достаточно плавный путь перехода от одной версии к другой. Эта модель способствует раннему возврату инвестиций, но требует открытой архитектуры, которая поддерживает такое эволюционное совершенствование программного продукта, и может выродиться в модель Build-and-fix.

Модель синхронизации и стабилизации удовлетворяет будущим потребностям клиента и обеспечивает высокую интеграцию компонентов, но достаточно сложна, поскольку требует интенсивного тестирования. Поэтому она не получила широкого применения вне Microsoft.

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

Объектно-ориентированная модель требует дисциплины, может выродиться в модель проб и ошибок и обеспечивает итеративную разработку и параллелизм взаимодействия между фазами.

На что влияет выбор модели ЖЦ? На скорость разработки, время выхода проекта на рынок, качество и стоимость продукта, стратегию управления изменениями и рисками, отношения с заказчиком на стадии сопровождения.

Окончательные выводы, которые можно сделать по моделям ЖЦ: выбор модели определяет основные критические параметры проекта – это успех проекта в целом, архитектура проекта, его бюджет, в каких случаях можно сэкономить. Модель должна быть адекватна опыту проектной команды с точки зрения знаний предметной области и знания конкретных технологий, CASE-средств, документирования, подходов к документированию и т. д. Серьезные модели, такие как спиральная или объектно-ориентированная, требуют определенной дисциплины и зрелости. В противном случае они вырождаются в модель проб и ошибок. Универсальной модели не существует. Выбор модели определяется исключительно характером и масштабом проекта. Ряд моделей можно комбинировать. У каждой модели есть свои преимущества и недостатки, которые обнаруживаются и имеют смысл только в контексте проекта, с учетом его особенностей.

Еще несколько слов о том, что помогает в программной инженерии, в изготовлении корпоративных решений. Это CASE-средства и CASE-технологии. ПО имеют целый ряд аспектов. ПО в малом можно рассматривать как искусство программирования или разработку отдельных модулей, отдельных фрагментов кода. ПО в большом можно понимать как software engineering, это технологии программирования, обеспечение жизненного цикла ПО с теми этапами и теми моделями, о которых было сказано выше. И еще один аспект – это командная работа ПО в массе, поддержка коллективной разработки, что очень важно для корпоративных информационных систем, в разработке которых участвуют целые коллективы разработчиков и тратят массу времени на взаимодействие, интеграцию, совместную разработку, командную работу.

Одним из важных CASE-средств, которое мы будем рассматривать, является Visual Studio.NET от Microsoft. О нем мы будем говорить в дальнейшем. Существует большое количество других CASE-средств: линейка Rational, которая поддерживает RUP. CASE-средства помогают во всех трех аспектах – и узко при кодировании, и при оптимизации ЖЦ, и при командной работе.

CASE-средства в первом приближении делятся на CASE-средства верхнего уровня (front-end), т. е. соответствуют первичным стадиям ЖЦ, и нижнего уровня (back-end), соответствующие стадиям ЖЦ, начиная с реализации. Важно отметить, что существуют конвейерные средства, такие как линейка Rational, Microsoft Visual Studio.NET, которые представляют собой среды, т. е. наборы определенного инструментария или своего рода конвейеры для выполнения связанных операций компиляции, тестирования, интеграции, редактирования кода, изготовления проектной документации, диаграммирования и т. д.

CASE-технологии дают неоспоримое преимущество при изготовлении больших программных систем. Но при своем применении они требуют определенных условий, таких как организационная зрелость команды, знание стандартов (UML, XML), знание самого средства. Кроме того, CASE-средства применимы для больших проектов корпоративных систем. Для небольших проектов стоимость CASE-средств и обучения им неоправданно высока. В результате успешного применения CASE-средств можно получить существенный рост производительности труда разработчиков и, в результате, если мы говорим о проекте в целом, существенное снижение сроков и стоимости программного проекта.

Какие метрики ПО применяются при контроле за ЖЦ программного проекта? Для проекта в целом это сроки, стоимость и функциональность – так называемый проектный треугольник компромиссов. В ряде случаев имеет смысл проводить анализ cost-benefit, т. е. анализ тех преимуществ, которые получает заказчик в зависимости от тех или иных вложений. Таким образом, этот треугольник имеет смысл рассматривать во взаимосвязи его основных характеристик и параметров. Наконец, для конкретных стадий ЖЦ (скажем, тестирования и сопровождения) можно выделить специфические метрики. Вообще говоря, для каждого этапа они свои. В случае тестирования можно использовать такие метрики, как сложность отдельного модуля, количество строк (обычно это тысячи строк), количество различных операторов или операндов, которые используются в том или ином модуле или фрагменте кода, относительное количество ошибок, которые выявлены на 1000 строк кода. Для стадии сопровождения это отслеживание и исправление допущенных ранее ошибок, поскольку не все ошибки проекта могут быть выявлены непосредственно на стадии реализации и до передачи заказчику. Нужно анализировать общее количество сбоев, коммуникацию или взаимодействие по ним. Здесь работают такие метрики, как состояние сбоев и отчетов. Кроме того, выявление источника и определенное состояние дискуссии, результаты (удалось устранить этот сбой, насколько он серьезный), а также метрики предыдущих стадий. Важные выводы, которые можно сделать, сводятся к тому, что решение принимается менеджером проекта: стоит ли прекратить тестирование, передать в эксплуатацию или нет? И, как правило, простые метрики являются достаточным.

Глава 3 Модели жизненного цикла корпоративных систем

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

В предыдущей главе был рассмотрен ряд моделей, используемых в разработке ПО, в частности модель Build-and-fix (модель неполного жизненного цикла, рис. 3.1), которая в силу своей простоты не пригодна для больших и сложных проектов, имеющих размеры более 1000 программных строк. Также была рассмотрена модель быстрого прототипирования, которая тоже несколько ограниченна, несмотря на то что включает в себя все необходимые стадии жизненного цикла: анализ и спецификацию требований, первичное и детальное проектирование, реализацию, модульное и сборочное тестирование, интеграцию, тестирование продукта, передачу его заказчику, вывод из эксплуатации. Несмотря на это, она несамостоятельна, потому что на самом деле этап тестирования (и индивидуальных модулей, и при сборке) недостаточен, документация неполная, и продукт, получаемый на выходе, лишь моделирует функциональность той «боевой» системы, разработка которой ведется.

Рис. 3.1. Модель Build-and-fx жизненного цикла ПО

Каскадная (водопадная) модель, представленная на рис. 3.2, является в полной мере применимой для корпоративных информационных систем, но имеет ряд ограничений. В частности, как и многие модели, которые применимы для КИС, она требует дисциплины и организованности, хорошего знания CASE-средств, так как нужно быстро и организованно создавать диаграммы, проводить сетевые совещания, конференции, достаточно быстро вести тестирование различными методами. Кроме того, нужно производить документацию в соответствии со стандартами, которые приняты по договоренности с заказчиком внутри компании как руководство к действию, как шаблоны для реализации документации, которая тоже является важной частью продукта. Продукт – это не только код, но и огромное количество документации, необходимое, чтобы обеспечить его грамотное и стабильное сопровождение. Документация тем более полезна для чтения чужого кода, поскольку персонал сопровождения как раз и работает с чужим кодом, ища в нем ошибки. Это будет рассмотрено более подробно далее, когда речь пойдет о стадии сопровождения. Пока следует отметить, что документация критически важна для каскадной модели, потому что, проверяя ее на адекватность и сопоставляя с ТЗ или другим вариантом требований к продукту, которые согласованы с заказчиком и утверждены как юридический документ, разработчики отчитываются по продукту и закрывают каждую стадию жизненного цикла.

Рис. 3.2. Каскадная модель жизненного цикла ПО

Осталось рассмотреть еще целый ряд моделей (рис. 3.3–3.5), которые достаточно важны для понимания того, каким образом можно организовывать жизненный цикл программных систем, в том числе и корпоративных, ведь эти модели существенным образом связаны именно с корпоративными информационными системами. Они ориентированы не на однократный проход по стадиям жизненного цикла, как это происходит в каскадной модели, а на последовательное уточнение функциональности продукта при движении по этим стадиям и, как правило, при неоднократном их прохождении.

Естественно, большую систему сложно реализовать за один проход, хотя при правильной постановке задачи и хорошем подходе к документированию и проектированию это оказывается возможным, например, в проектах, которые реализуются по каскадной модели большей частью для госструктур, таких как министерства обороны (и в США, и в России). Другие модели жизненного цикла, о которых речь пойдет далее, предусматривают либо итерации с возвратным уточнением функциональности продукта, либо другой способ циклического прохождения по стадиям жизненного цикла. Эти модели в определенном смысле более легки с точки зрения дисциплины проекта и в ряде случаев не требуют полной функциональности, производства полного продукта с документацией в полном объеме на каждую стадию.

Рис. 3.3. V-модель жизненного цикла ПО на базе каскадной модели

Рис. 3.4. Быстрое прототипирование – модель жизненного цикла ПО

Рис. 3.5. «Зубья акула» – модель жизненного цикла ПО на базе модели быстрого прототипирования

Одна из таких моделей – инкрементальная модель. В чем состоят ее важнейшие особенности? В ходе построения плана проекта ПО претерпевает разбивку на последовательные релизы. Весь жизненный цикл, связанный с производством до передачи в сопровождение, подразумевает производство последовательных релизов – циклов разработки, каждый из которых дает уже работоспособный продукт. Таким образом, в ряде случаев, особенно когда продукт не требует революционной перестройки от релиза к релизу (т. е. функциональность наращивается достаточно плавно), заказчику передается в сопровождение уже работоспособный продукт, пусть и с ограниченной функциональностью. Таким образом на каждой стадии происходит создание необходимой документации и тестирование, и продукт получается работоспособным, но реализует не всю функциональность, а каждый релиз уже дает продукт, который может применяться.

Если говорить об интернет-магазине, то можно упростить интерфейс, связанный с заказом продуктов, например: мы не можем выбрасывать из корзины продукты по одному, а можем только сразу чистить всю корзину; или у нас нет возможности выбора между доставкой по морю, по воздуху и по суше, а есть некий единый вид доставки с единым тарифом; или у нас нет возможности оплатить заказ кредитной картой, когда потребуется специальный сервер для аутентификации заказчиков, транзакций, связанных с электронными платежами. То есть на первом шаге реализуется достаточно упрощенный продукт, который тем не менее является полностью работоспособным.

Таким образом, в итоге каждого шага разработки, тестирования и интеграции имеется работающий продукт, который может устроить заказчика. В технических требованиях можно заранее оговорить, в какой последовательности и в какие сроки в плане проекта вводить ту или иную функциональность у заказчика, и далее вести последовательные релизы в соответствии с используемыми технологиями и функциональными ограничениями. При этом еще одним преимуществом является плавный ввод новой функциональности. Каждый функциональный блок содержит целый ряд модулей (классов, если мы говорим об объектно-ориентированном подходе к производству ПО). И, естественно, эти классы существуют не сами по себе, а в связи с другими классами. Они наследуют ряд свойств других классов, взаимодействуют с другими классами посредством методов, которые предоставляют доступ к полям семантически связанных классов. Таким образом, было бы желательно, чтобы при производстве каждого релиза связность модулей не только оставалась относительно небольшой, но и обеспечивала плавный ввод функциональности за счет относительно небольшого количества точек взаимодействия между этими модулями.

Естественно, при проектировании модулей нужно стараться обеспечить минимальную связность между ними, т. е. вся функциональность некой небольшой программной задачи, которую решает ПО, должна быть локализована в отдельном программном модуле. Но поскольку функциональность реализуется постепенно, новые модули будут взаимодействовать с уже существующими, поэтому нужно тестировать их взаимосвязи. Поэтому, если проект требует революционного ввода функциональности, которая во многом меняет старую, то возникнет целый ряд проблем. С чем они могут быть связаны? Во-первых, в объектно-ориентированном подходе к проектированию и реализации ПО возникает существенная проблема, связанная с наследованием. Может получиться так, что целый ряд классов в том релизе, который уже создан и внедрен заказчиком, претерпит существенные изменения. Изменится вся иерархия классов, и придется повторить этап проектирования и документирования для классов, которые уже были реализованы и функционируют. Это, конечно, придется делать в любом случае, но при революционных изменениях функциональности будет необходимо внести массу таких изменений, и это сведет на нет все усилия по производству первого релиза, фактически надо разрабатывать новый продукт. То есть функциональность, которая была разработана на предыдущем шаге, во многом будет переработана, и затраты, произведенные на создание этой функциональности, будут во многом потеряны. В этой связи инкрементальная модель не очень хороша для заказчиков или проектов, которые развиваются революционно.

С другой стороны, если продукт развивается эволюционно, модель во многом облегчает взаимодействие с заказчиком и отношения с ним, потому что основные модули, которые реализуют бизнес-логику приложения, будут меняться незначительно. К ним будет лишь добавляться некоторая функциональность (некоторые методы, если мы говорим на языке ООП). И в этой связи сопровождение продукта будет достаточно плавным, с небольшими затратами. В этом смысле рассматриваемый подход к разработке корпоративных информационных систем является достаточно хорошим для создания эволюционных продуктов. Естественно, обратная сторона медали – архитектурные решения. К сожалению, существуют программные архитектуры, которые не поддерживают такого рода масштабирование. Например, компонентная архитектура Microsoft с веб-сервисами достаточно хорошо поддерживает масштабирование, подключение новых элементов или расширение существующих. Существуют архитектуры, например файл-серверная, с масштабированием которых все гораздо сложнее. Поэтому уже на этапе выбора архитектуры, при первичном архитектурном проектировании, и отчасти при построении технических ограничений в проекте необходимо учитывать особенности той или иной модели. Вообще говоря, нужно выбрать модель жизненного цикла ПО и следовать этому выбору.

Еще нужно отметить как недостаток то обстоятельство, что ряд продуктов требует, к сожалению, сразу полнофункционального решения, причем это может быть связано во многом и с пожеланиями заказчика. Ряду заказчиков нужен сразу полнофункциональный интернет-магазин, который включает в себя и 3D-витрину, и возможность оплаты кредитной картой, и различные системы электронной оплаты. В некоторых случаях было бы полезно отслеживание доставки (оно реализовано, например, в таких службах, как DHL, это удобно и полезно). Но здесь все зависит от ТЗ и требований к продукту. Если продукт сразу требует полной функциональности, наверное, подойдет какая-то другая модель (может быть, каскадная), которая позволяет реализовать все за один проход. Конечно, и риски в этом случае будут выше, но о них речь пойдет далее, в связи со спиральной моделью, которая специфически их учитывает и призвана с ними бороться. Если же говорить об инкрементальной модели, то нужно отметить, что не для каждого продукта и корпоративной системы она годится.

Еще один недостаток: ПО должно предусматривать стабильный путь апгрейда (развития). То есть изменения, которые вносятся в каждый программный модуль при выпуске каждого релиза, не должны превышать паразитные, служебные изменения, которые очень сказываются на конфигурации. Они не должны существенным образом сказываться на производительности при создании очередного релиза программного продукта. Естественно, если путь развития ПО нестабильный, резкий, взрывной, эта модель опять-таки не подойдет: она не имеет механизмов оценки рисков.

Еще важное замечание: ряд продуктов (это может быть связано с заказчиками или конъюнктурой рынка, конкуренцией на рынке) требует революционного изменения самой концепции, основополагающих решений, которые закладываются в функциональные требования, план проекта и задание на релиз. Если заказчик меняет требования слишком часто, внезапно и значительно и нет возможности эти требования с ним согласовать и прийти к достаточно эволюционному их изменению, то получается, что каждый раз нужно не просто переработать значительную часть продукта, а, по сути, создать новый. Тем самым практически происходит переход к модели Build-and-fix. То есть нужно заново создать существенно отличающийся от предыдущего релиза продукт. При этом очень плохо, что в отличие от Build-and-fix, приходится заново осуществить полный жизненный цикл для каждого релиза: полностью описать требования в виде ТЗ, вести проектирование, т. е. создать огромное количество диаграмм прецедентов, диаграмм потоков данных, сценариев использования, которые их конкретизируют, диаграмм классов – сначала предварительных, а затем детальных, где заново оговариваются все начальные значения переменных, атрибуты и методы, взаимодействие между классами, методы-аксессоры, все существенные локальные и глобальные переменные, все алгоритмы, их реализация, структуры данных и т. д. Ведется тестирование: разрабатывается план тестирования – как продукт будет тестироваться, в каком порядке, какие тесты будут созданы для передачи продукта. Также можно сказать о пользовательской документации, документации для администраторов: продукт нужно будет по-другому устанавливать и настраивать, он будет иметь другой интерфейс, пользователи будут вынуждены работать с ним совершенно иначе, коды ошибок и вся остальная информация изменятся. И всю эту документацию также будет необходимо переделать. То есть речь идет о достаточно сложном варианте Build-and-fix, который подразумевает еще и полномасштабную документацию, отработку всех этапов жизненного цикла ПО. Поэтому такое производство, конечно, влечет огромное количество накладных расходов и является экономически нецелесообразным, и в условиях продукта, который быстро выходит за рамки исходной концепции, инкрементальная модель является недопустимой – будь то корпоративные или более простые системы.

Немного подробнее остановимся на том, каким образом идет разработка с точки зрения проектирования продукта, в том числе и корпоративного, если разработчик придерживается инкрементальной модели. Продукт делится на подсистемы, структура и функции каждой из них оговариваются в ТЗ или более простом документе со спецификацией требований и ограничений в системе, и продукт поставляется заказчику в полнофункциональном виде в релизах. При этом каждый релиз подразумевает возможность реальной работы заказчика (всех его видов пользователей и администраторов) с этой системой. Если речь идет о корпоративной системе, то существует достаточно большое количество различных типов пользователей: связанных с составлением отчетов (консолидацией данных), занятых вводом и анализом данных (бизнес-аналитики, извлекающие данные из системы и затем применяющие OLAP-системы для их анализа и выявления трендов), это руководители, которые анализируют консолидированные отчеты по ряду предприятий, производственному кластеру, персоналу, имеется также достаточно большое количество различных администраторов: администратор базы данных, администратор системы, администратор сети, администратор безопасности, все они имеют свои руководства и получают их на каждом релизе в обновленном виде с учетом всех изменений, которые внесены в систему.

Естественно, если путь развития системы предсказуем и соответствует варианту, согласованному с заказчиком, то новая подсистема естественным образом входит в предыдущий релиз. При этом выпускается специальный документ – заметки к релизу (документация к релизу), который включает список всех корректив, внесенных в прежний релиз. В ряде случаев это бывает полезным как важная дополнительная информация о программном продукте, чтобы заказчик или его представители, которые занимаются сопровождением ошибок, их выявлением, локализацией и ликвидацией, консультацией пользователей, смогли корректно перейти от предыдущего релиза к последующему.

На рис. 3.6 представлен вариант инкрементальной модели жизненного цикла, и видно, что каждый релиз включает в себя требования к предыдущему релизу, т. е. функциональность нарастает плавно и таким образом, что следующий релиз в смысле функциональности поглощает предыдущий, добавляя к нему новые возможности. Кроме того, каждый этап наращиваемой разработки продукта, производства нового релиза включает в себя все стадии жизненного цикла программного продукта: это и анализ и спецификация требований, и верификация (сопоставление документации и других элементов проекта с теми требованиями, которые изначально заявлены, проверка их внутренней корректности – полноты, непротиворечивости, ясности), и проектирование (первичное и детальное – детализация до диаграмм классов, атрибутов, переменных, методов, структур классов и, конечно, динамики проекта с помощью диаграмм переходов состояний UML или других нотаций – сетей Петри и т. д.).

Рис. 3.6. Инкрементальная модель жизненного цикла ПО

По завершении проектирования опять осуществляется верификация: происходит проверка и документации – произведенных диаграмм, и других артефактов проекта на соответствие требованиям, которые они должны реализовать на данном этапе этого релиза. Кроме того, производится проверка внутренней корректности документации: все классы, обозначенные на диаграммах первичного проектирования, должны появиться и на диаграммах детального проектирования либо должны существовать какие-то мотивированные изменения в проекте, которые необходимо соответствующим образом задокументировать. По сути, на этой стадии мы уже приходим к заданию на кодирование – стадии реализации. Она, естественно, также полномасштабно осуществляется для каждого релиза программного продукта при этом подходе. Она включает в себя план тестирования (это и модульное тестирование – проверка индивидуального модуля проекта на соответствие спецификациям, и тестирование модулей попарно и в совокупности; так мы приходим к тестированию продукта и, наконец, к той стадии, когда по количеству остаточных ошибок релиз становится достаточно чистым и в соответствии с установленными метриками мы можем передать его заказчику). Дальше производится интеграция, приемочное тестирование и передача на сопровождение. Интеграция производится, естественно, на стадии реализации. Перед передачей осуществляется финальная верификация. Если приемочные тесты заказчика не вполне устраивают, то нужно переработать продукт.

Таким образом, основные стадии жизненного цикла ПО здесь выдерживаются полностью для каждого релиза. Если говорить об эволюционном наращивании функциональности и заказчик требует в определенные сроки пусть и не полностью, но реализованный продукт, то инкрементальная модель – это то что нужно. При этом в ее рамках могут реализовываться продукты как среднего размера (для малых достаточно одного этапа Build-and-fix), так и большие для корпоративных информационных систем.

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

Рис. 3.7. Эволюционная модель жизненного цикла ПО

Еще один важный подход к проектированию программных систем, в том числе и корпоративных, связан с итерациями. Здесь хорошим примером является спиральная модель, разработанная Бари Боэмом (рис. 3.8). Каждый виток состоит из четырех фаз:

1) определить цели – продукт, деловые цели, понять ограничения, предложить альтернативы;

2) оценить альтернативы – анализ риска, прототипирование;

3) разработать продукт – детальный проект, код, unit test, интеграция;

4) спланировать следующий цикл – оценка клиентом, планирование проектирования, поставка клиенту, внедрение.

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

Рис. 3.8. Спиральная модель жизненного цикла ПО

Каждая фаза каскадной модели зацикливается – как правило, это три-четыре итерации, но это сильно зависит от «сходимости» проекта, в ряде случаев количество итераций сложно предсказать, более того, часто бывает так, что после оценки рисков проект продолжать невозможно. Это может повлечь дополнительные расходы, но в ряде случаев необходимо признать, что проектная команда не в состоянии в заявленные сроки и с требуемым уровнем качества реализовать проект должной функциональности. При этом, как уже отмечалось, каждый цикл модели включает при спиральном подходе четыре основных этапа: определение, оценка, реализация и планирование. На первой стадии определяются цели, возможные альтернативы достижения этих целей и ограничения, существующие для каждой из альтернатив. Далее ведется оценка альтернатив, главным образом оценка рисков. Это достаточно сложная дисциплина, которая требует фундаментальных знаний, и поэтому специалисты, часто вынужденные принимать решения в условиях неполной информации и существенной неопределенности, ценятся очень дорого. В этой связи модель требует дополнительных расходов, но хороша для тех проектов, которые могут требовать таких постоянных оценок рисков и являются достаточно рискованными сами по себе. Если удается идентифицировать риски, указать пути их снижения или найти возможность продолжать проект с теми рисками, которые существуют, начинается стадия реализации, верификации и тестирования текущего витка спирали. И после этого, с учетом того, каким образом, в какой мере и с какими затратами людских ресурсов, по срокам, качеству достигается поставленная цель, осуществляется планирование следующего цикла, следующего витка спирали.

Нужно заметить, что поскольку анализ рисков включает ряд существенных неопределенностей, которые заказчик для исполнителя обычно раскрывает далеко не в полной мере, спиральная модель достаточно хороша для внутренних проектов, когда разработчик и заказчик либо являются одним юридическим лицом, либо работают в рамках одной корпоративной структуры. Очень часто в больших корпорациях выделяется отдельная компания, занимающаяся ведением ИТ-проектов, например компания «Сибинтек» в составе ЮКОСа, компания «Итеранет» в группе компаний «Итера». Спиральная модель при такой организации взаимодействия, когда разработчик и заказчик находятся в рамках одной структуры корпоративного типа, – достаточно хорошее решение. В этом случае может осуществляться достаточно полная передача всей необходимой информации для оценки рисков, они могут оцениваться достаточно достоверно и поэтому грамотно и с минимальными затратами разрешаться.

Следующая модель, о которой хочется более подробно сказать, получила название «синхронизация и стабилизация», или модель синхростабилизации. Это связано с особенностью организации фаз жизненного цикла программного продукта. Другое название – модель Microsoft. Сегодня по информации из ряда источников она постепенно заменяется на Microsoft Solution Framework (MSF). По сути, эта модель была во многом похожа на MSF, но сегодня ею вытесняется. MSF – достаточно сложная и достаточно открытая модель. Она имеет интересные преимущества, которые основаны на определенном равноправии членов проектной команды. С другой стороны, эта модель достаточно сложна. Крайне ограниченно количество экспертов, владеющих тонкостями этой модели настолько, чтобы донести ее до широкой аудитории руководителей проектов, менеджеров продуктов, системных архитекторов. Поэтому, к сожалению, несмотря на свою привлекательность, модель не получила широкого распространения вне компании Microsoft. Сторонние компании, даже если они работают с инструментарием Microsoft и имеют хорошие знания о технологиях и стандартах Microsoft, редко пользуются ею из-за сложности ее реализации.

Синхронизация и стабилизация – важные процессы в жизни программного продукта в рамках этой модели. Результаты работы всех членов проектной команды на всех уровнях – достаточно сложная организация. Существует матрица проектных обязанностей: некоторые обязанности в команде проекта могут перекрываться. Например, существуют понятия менеджера проекта и менеджера продукта. Как правило, для крупных проектов это разные люди, но для небольших проектов их обязанности могут объединяться. Подобным образом могут объединяться роли различных исполнителей. Результаты работы членов проектной команды достаточно часто синхронизируются. При этом основные фазы производства программного продукта включают планирование, разработку и стабилизацию.

Достаточно интересным является понятие видения (концепции) продукта, с этого вообще и начинается разговор о нем. Сначала должна появиться некоторая неформальная идея того, чем этот продукт будет принципиально отличаться от существующих, какие преимущества он принесет при реализации. При этом в ходе работы по этой модели, как и всегда, производится последовательная детализация программного продукта, и, естественно, видение является наиболее абстрактным представлением о нем. До того как начать разрабатывать продукт на основе этого представления, пусть даже неформализованного, готовится более точный документ, который описывает проектные спецификации. После этого происходит формирование проектной команды, готовится график работ: какие виды деятельности какой из ролей будут реализованы, на какой стадии, сколько это займет времени, какие будут вехи, результаты на каждом этапе изготовления продукта. Нужно заметить, что очень часто при разработке продуктов Microsoft проектная команда набирается именно под данный проект. И люди, которые участвуют в проекте на различных ролях – разработчиков, проектировщиков, документаторов, тестировщиков, встречаются только в тот период, когда изготавливают продукт. После этого часто бывает, что далее продукт существует независимо от них. Поэтому еще раз хочется подчеркнуть важность программной документации для обеспечения преемственности продуктов внутри линейки продуктов. У Microsoft, например, это линейки ОС Windows, приложений MS Office и др.

После фазы планирования наступает фаза разработки. При этом достаточно важно выделить функции разработки, которые лежат на критическом пути в смысле ресурсов проекта – людских, временных, функциональности и качества продуктов. Кроме того, важно обратить внимание на совместно используемые (разделяемые) компоненты проекта. Также выделяются средние по уровню критичности и наименее критичные функции. В этом порядке происходит реализация. На фазе стабилизации все ошибки, которые выявляются в частях проекта, тестируются, готовится релиз продукта, подразумевающий достаточно полнофункциональный его срез. Более подробно можно сказать так: каждый релиз представляет собой работающий срез программного обеспечения. При этом здесь тоже речь идет о последовательном наращивании функциональности. Если проектирование идет корректно, для передачи финального продукта заказчику требуется три – четыре инкрементальных версии программного обеспечения.

При этом синхронизация и стабилизация, естественно, присутствуют при производстве каждого релиза. Синхронизация включает проверку спецификаций, т. е. описание функциональности, ограничений, концептуальной схемы программного продукта. Далее происходит сборка: индивидуальные модули, разработанные программистами, объединяются в частичный или полный продукт, осуществляется достаточно частое и интенсивное тестирование, поскольку релизы выпускаются довольно быстро. Кроме того, происходит второй важный процесс – стабилизация: все ошибки, которые найдены тестами, должны быть устранены. При этом заметим, что есть два основных способа устранения ошибок: локализация ошибки и исправление ее непосредственно в том месте, где она допущена (внутри модуля или на стыке модулей), и «обход» ошибки – внесение изменений в другую, не связанную непосредственно с ошибочной часть продукта, призванный «компенсировать» ошибку в данной части продукта.

Итак, синхронизация и стабилизация – два взаимосвязанных процесса, которые необходимо последовательно выполнять при изготовлении релиза программного продукта. При этом финальным этапом для каждого релиза является заморозка – сохранение всей метаинформации (конфигурации) данного релиза в форме файлов, версий этих файлов, даты, времени, ответственного, т. е. всей конфигурации, описывающей финальный срез, работоспособный в соответствии с предъявляемыми к нему требованиями. По сути, это тоже можно рассматривать как продукт, готовый к передаче, но не являющийся полнофункциональным.

Рассмотрим преимущества, которые связаны с моделью Microsoft. Это, во-первых, частое и раннее тестирование. Чем это полезно? Уже говорилось о том, что ошибки в продукте нужно выявлять как можно раньше. Чем позже выявляется ошибка, тем большую работу по ее устранению придется провести, поскольку может случиться так, что ошибка, даже будучи локализованной в одном из модулей, все же влияет на работу соседних модулей, на определенные компоненты проекта, на продукт в целом. Кроме того, она влияет на документацию проекта: придется дорабатывать не только код, но и документацию, причем документацию не только на этот код, но и к проекту, которая описывает модуль, его работу, взаимодействие с другими модулями – диаграммы классов, возможно, диаграммы взаимодействия. Ведь ошибку в логике работы модуля верхнего уровня, который отвечает за общую бизнес-логику работы системы, можно локализовать, но после этого ее устранение потребует достаточно радикальной перестройки значительной части структуры программного обеспечения, большого количества классов и документации к ним. Поэтому, конечно, частое и максимально раннее тестирование – весьма позитивный подход и потенциальное преимущество модели Microsoft.

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

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

Кроме того, важное преимущество – существование работающей версии ПО сразу после первого релиза. Можно сказать, что это прототип, но уже достаточно надежный и хорошо оттестированный в ходе первого релиза. С точки зрения архитектурного проектирования уже видны его недочеты на уровне декомпозиции на модули. Например, может быть, что какие-то из частей прототипа явно непропорционально большие, а другие, наоборот, непропорционально мелкие. Тогда нужно перегруппировать функционал внутри этих частей. С другой стороны, можно увидеть, что некоторые элементы проекта недостаточно глубоко декомпозированы или имеют слишком много взаимосвязей. Такие элементы нужно дополнительно декомпозировать, упростив структуру элементарных модулей. Это поможет при производстве дальнейших релизов, потому как даст возможность до полномасштабной реализации учесть все недостатки проекта с точки зрения архитектурного проектирования. Кроме того, можно выявить несоответствия, возникшие еще при постановке задачи, и попробовать урегулировать их с заказчиком на этом этапе, до того, как полномасштабная реализация готова. В противном случае возможен провал с сопровождением: необходимо будет устранить массу функциональных недочетов, которые были получены в том числе и по вине заказчика. Это большая работа, которая потребует долгого времени и затрат средств. При данном подходе можно уже исходя из начальных релизов существенно уменьшить стоимость редизайна, повторного проектирования, которое неизбежно присутствует при каждом следующем релизе, особенно если заказчик проходит стадии тестирования вместе с разработчиками на предварительных релизах, как это делает Microsoft.

Таким образом, потенциально эта модель жизненного цикла перспективна, однако сложна и поэтому достаточно редко применяется для реализации больших корпоративных систем вне Microsoft. Ее важный недостаток – это то, что нужно уделять много времени синхронизации и стабилизации, т. е. тестированию и устранению тех ошибок, которые найдены тестами, особенно при не совсем хорошей дисциплине проекта или неполном представлении о процессах MSF. По сути, здесь имеется паразитный процесс. После известных событий 11 сентября компания Microsoft поставила безопасность приоритетом № 1 при производстве ПО. И любое ПО, которое производится сейчас, должно соответствовать внутренней модели жизненного цикла, принятой в Microsoft, которая называется SDL (security development lifecycle). При этом декларируется и поддерживается принцип «secure by design» – безопасность уже исходя из подхода к проектированию: сама модель проектирования строится таким образом, чтобы ПО было безопасным. Таким образом, паразитные процессы могут влечь положительные эффекты: увеличение стабильности, надежности, предсказуемости, масштабируемости создаваемого ПО, а для корпоративных систем это критически важные аспекты.

Циклы сборки и тестирования при этом подходе должны происходить достаточно часто, в ряде случаев – еженедельно. Это говорит о том, что нужно успевать не только добавлять новую функциональность, но и строить промежуточные сборки к релизам достаточно часто, не только вносить новую функциональность и проектировать в соответствии с новой функциональностью программный продукт, внося изменения в диаграммы, документацию, программный код, но и успевать тщательным образом по соответствующей методике специальными средствами всеобъемлюще тестировать продукт, находить ошибки и исправлять их. Поэтому при коротких промежутках между сборками нужно успевать за счет высокой производительности труда и точного знания методологии Microsoft производить эти циклы тестирования. Иначе можно не успеть добавить новую функциональность в каждую сборку, а в итоге – в релиз и непроизводительно терять время на тестирование. Ввиду этого достаточно редко можно говорить о том, что большие корпоративные системы производятся по методологиям синхроста-билизации и MSF вне стен корпорации Microsoft. К сожалению, сегодня преимущества этой методики достаточно сложно воплотить в жизнь, потому что они требуют высокой специализированной подготовки и, как следствие, дорогих кадров.

Вернемся к спиральной модели, которая представляется в виде четырех стадий (определить – оценить – разработать – спланировать), а графически – чаще всего в виде спирали. Следует обратить внимание, что эта модель во многом схожа с эволюционной моделью, с моделями, которые включают итерации (например, инкрементальной), но, что очень важно, и принципиально отлична от других моделей тем, что на каждой стадии появляется операция, принципиально отличная от других моделей, – оценка рисков. При этом важно отметить, что для ряда моделей возможно комбинирование. Комбинирование оправдано прежде всего с той моделью жизненного цикла, которая не является самостоятельной, это модель быстрого прототипирования. И здесь видно, что на втором этапе происходит анализ и оценка рисков и прототипирование. Когда вы будете заниматься разработкой ПО, нужно помнить, что быстрое прототипирование приходит на помощь не только когда нужно быстро обсудить альтернативы продукта с заказчиком, но и как средство относительно дешевого и простого изготовления продукта, который ведет себя в достаточной мере похоже на готовый продукт с точки зрения функциональности, но ограничен по надежности, устойчивости, безопасности, документации и работать как полноценная корпоративная система не может. Поэтому достаточно интересным является подход, когда на ряде этапов объединяют серьезные большие корпоративные модели жизненного цикла ПО (спиральную, эволюционную) с быстрым прототипированием. Это удобно, потому как в достаточно короткие сроки и с небольшими трудозатратами можно ликвидировать проектные риски, которые возникают, можно проверить и уточнить с заказчиком те или иные возможности программного продукта и те или иные функции, которые более или менее критичны для их включения в последующие релизы или даже версии программного продукта и потребуют отдельного проектирования, договора с заказчиком, ТЗ и т. д. В результате быстрый прототип дает возможность разрешить отдельные риски и вместо директивного прекращения производства программного продукта (как могло бы произойти при разработке по спиральной модели) все же завершить его, пусть и с ограниченной функциональностью.

Еще более детально остановимся на преимуществах и недостатках спиральной модели. В основе спиральной модели лежит тот самый классический жизненный цикл из каскадной модели, к которому добавлен анализ рисков. Риски проекта следует классифицировать, т. е. разделить их на наиболее критичные (которые могут привести к невозможности продолжать проект), наименее критичные (которые можно не учитывать на определенных витках спиральной модели) и промежуточные. Нужно разрешить самые серьезные риски проекта, т. е. найти способ эти риски уменьшить, сделать их приемлемыми для тех рамок проекта (по срокам, стоимости, функциональности), которые заданы заказчиком и разработчиками (у разработчиков тоже существуют ограничения на проектные команды, некоторые представители команд могут быть заняты в разных проектах). При этом существенно, что невозможность устранить риски на каком-то этапе проекта вынуждает этот проект завершить. Быстрое прототипирование – возможно, в несколько шагов – может прийти на помощь в этой модели для снижения как рисков, так и стоимости. Более того, оно может даже дать возможность завершить проект тогда, когда в иных условиях такой возможности бы не было. Вообще говоря, спиральная модель, в отличие от модели Microsoft, может включать и достаточно большое количество итераций (не обязательно три-четыре).

Чем хороша спиральная модель? Прежде всего, если ПО производится на основе этой модели, то за счет прототипирования, если оно применяется, за счет анализа и оценки рисков возможно повторное использование продукта. То есть сам подход к жизненному циклу обеспечивает плавное движение продукта по этому жизненному циклу, плавный переход к его сдаче заказчику. Таким образом обеспечивается возможность повторного использования продукта, даже в условиях изначально высоких проектных рисков. Поскольку анализ рисков происходит изначально, можно ограничиться в ряде случаев упрощенной схемой тестирования. С другой стороны, можно достаточно корректно обосновать, в каких случаях и в какой мере это тестирование проводить, когда завершится тестирование и продукт перейдет к заказчику – исходя из применяемой технологии анализа рисков. На основе анализа рисков получается еще целый ряд метрик, которые дают возможность оценить продукт с точки зрения его качества, надежности, полноты документации, чтобы его можно было передать заказчику. Кроме того, можно относительно гладко перейти к сопровождению продукта за счет того, что продукт последовательно приближается к «боевому» решению в ходе достаточно большого количества витков спирали, каждый из которых подтверждается и уточняется очередной итерацией оценки рисков. То есть имеет место цикличность. В этой связи, несмотря на большие затраты из-за оценки рисков, обеспечивается относительно недорогое сопровождение, а оно является наиболее затратной частью жизненного цикла, принимая на себя около 2/3 всех затрат. Таким образом, на полном жизненном цикле – с учетом сопровождения – может быть получена экономия. По сути, все недостатки, присущие этой модели, вытекают из того, что требуются большие затраты на оценку риска. Во-первых, она применима преимущественно для внутренних проектов – таких, которые ведутся в пределах одного подразделения, разными структурами одной корпорации или структурами, которые имеют давнюю историю партнерских отношений и тесные взаимосвязи. Это происходит потому, что требуется предварительная оценка рисков и представителям разработчика часто необходима полная информация о производственных процессах заказчика, которые могут эти риски повлечь. Эта информация часто относится к категории коммерческой тайны и далеко не всегда может быть в достаточной мере передана разработчику. Поэтому если проект внутренний, эта проблема снимается. Конечно, спиральная модель может быть принципиально применима и для относительно небольших проектов, но, учитывая существенную затратность оценки рисков, она в первую очередь используется для больших корпоративных проектов. Что еще очень важно: она требует опыта оценки рисков. То есть либо в команде разработчика должны быть опытные специалисты по оценке рисков (с умением приоретизировать сложную структуру рисков по целому ряду критериев, особенно в корпоративных системах), либо этих специалистов следует привлекать извне.

Еще одна модель – наиболее интересная и динамичная – это объектно-ориентированная модель. Речь пойдет о той ее разновидности, которую называют фонтанной. Это название будет понятно, если посмотреть на схему взаимодействия фаз этой модели.

В чем ее особенности? Если все предыдущие модели содержат изолированные, четко отделенные стадии жизненного цикла (анализ требований, спецификация требований, предварительное и первичное проектирование, детальное и окончательное проектирование, реализация и тестирование, сборка и интеграционное тестирование, тестирование продукта, приемочное тестирование и передача заказчику, сопровождение, вывод из эксплуатации), особенно четко это представлено в водопадной модели (пока нет подписи на документе, что предыдущая стадия завершена в соответствии с принятыми стандартами качества, следующая стадия не может быть начата), то в объектно-ориентированной модели принято достаточно интенсивное взаимодействие между различными фазами жизненного цикла. Более того, имеет место перекрытие фаз: перекрываются объектно-ориентированный анализ и спецификация требований, иногда – объектно-ориентированный анализ и проектирование (вместе это называется «object-oriented analysis and design», что, вообще говоря, в других моделях является разными фазами). В отличие от других моделей она не разделяет данные и действия: внутри класса атрибуты и методы равноправно взаимодействуют внутри класса. Во многом именно поэтому взаимодействие фаз и является важной особенностью объектно-ориентированного подхода.

Еще важной особенностью выступает итеративная смена фаз. Изготовление продукта – процесс циклический, который может требовать и в ряде случаев требует возврата на предыдущие фазы. То есть фазы объектно-ориентированного проектирования часто включают в себя фазы объектно-ориентированного анализа. Скажем, анализ сценариев использования связан с объектным моделированием и производится на основе диаграмм прецедентов, которые являются продуктом проектирования.

На рис. 3.9 достаточно хорошо видно, что снизу вверх происходит проектирование, анализ и спецификация требований (они тесно связаны), последующие два этапа – проектирование и реализация (они тоже достаточно тесно связаны), возможен возврат к предыдущим фазам.

Рис. 3.9. Объектно-ориентированная модель жизненного цикла ПО

Чем хороша объектно-ориентированная модель? Она хорошо ложится в доминирующий сегодня подход – ООП, который разработан для многих языков, начиная со Smalltalk и Simula-67, которые привели к созданию таких современных языков, как C++, Java, C# – родной язык. NET, основной для разработки корпоративных приложений. Таких языков достаточно много, и они весьма распространены. Поэтому объектно-ориентированная модель находит весьма широкое применение при производстве корпоративных систем. Чем это обусловлено? Тем, что объектно-ориентированный подход позволяет строить сколь угодно сложные системы за счет наследования и абстракции, того, что можно детализировать предметную область сколь угодно плавно. На основе примитивных классов небольшого размера можно представить грубую модель предметной области любой сложности.

С другой стороны, существует целый ряд особенностей объектно-ориентированного подхода, обусловленных его понятиями «наследование» и «полиморфизм», которые приводят к достаточно серьезным сложностям при проектировании крупномасштабных программных систем. В частности, если говорить о применении наследования, то большая и сложная иерархия классов может приводить к тому, что при перепроектировании (например, из-за неточной начальной постановки задачи) приходится перекраивать всю иерархию классов. Возникает проблема так называемых хрупких базовых классов, когда необходимо корректировать код классов, которые находятся выше всего в иерархии, т. е. первичных, базовых классов, содержащих основную логику работы ПО и специфику предметной области. Может выясниться, что предметная область является значительно более сложной, что приведет к перепроектированию всей иерархии и значительным трудозатратам, потерям в сроках, стоимости, людских ресурсах. В этом смысле объектно-ориентированная модель предоставляет как потенциальные преимущества, так и существенные сложности при реализации.

Другой сложностью, возникающей при реализации такого рода систем, является динамическая конкретизация методов, содержащая в своей основе концепцию полиморфизма. К сожалению, механизм создания полиморфных функций, потенциально дающий большую мощь и экономию трудозатрат при создании методов, которые могут обрабатывать объекты гетерогенной природы за счет того, что тела функций конкретизируются только в момент выполнения программы, приводит к тому, что на стадии тестирования программы нельзя в полной мере обработать все возможные сценарии конкретизации полиморфных методов. За счет этого во время выполнения получаются непредсказуемые ошибки, которые могут сводить на нет всю работоспособность системы – приводить к зависаниям, потерям данных, непредсказуемости поведения программы и т. д. Естественно, это отрицательно сказывается на корпоративных бизнес-процессах.

Таким образом, объектно-ориентированная модель, разработанная на основе концепций объектно-ориентированного программирования, таит в себе большие опасности при производстве сложного, крупномасштабного программного обеспечения и в связи с концепцией полиморфизма. Нужно еще раз напомнить, что применение этой модели связано с существенными ограничениями, поскольку при отсутствии дисциплины, стандартов реализации кодирования, тестирования и документирования архитектура проекта получается некорректной и приходится постоянно ее менять. В этом случае паразитный процесс коррекции преобладает над основными процессами – проектированием и анализом. Таким образом, объектно-ориентированная модель, основанная на целом ряде интересных концепций – абстракции, наследования, полиморфизма, в больших проектах может приводить к вырождению этой модели в Build-and-fix.

Другие подходы к жизненному циклу включают в себя гибкие методологии, такие как Agile (рис. 3.10), Scrum (рис. 3.11), eXtreme Programming (рис. 3.12). Следует отметить, что направление этих подходов ортогонально моделям жизненного цикла. Они, в отличие от IBM Rational и MSF, применимы к проектам с большими неопределенностями, возможно, большими рисками, но меньшего масштаба, чем корпоративные информационные системы. С другой стороны, методологии – это параллельное направление проектирования систем, которое связано скорее с задачей проектного менеджмента, чем с задачей построения системной архитектуры.

Рис. 3.10. Жизненный цикл ПО, гибкие методологии, Agile

В заключение стоит еще раз отметить, что был рассмотрен ряд моделей – Build-and-fix, водопадная, быстрого прототипирования, инкрементальная, синхростабилизации, объектно-ориентированная, упоминалась эволюционная модель. Build-and-fix пригодна не для корпоративных проектов, а для небольших проектов с предсказуемым циклом развития и объемом порядка 1000 строк. Водопадная модель применима для корпоративных систем, обеспечивает четкую дисциплину проекта и хорошую управляемость, так как основана на большом количестве документов, которые производятся в ходе жизненного цикла, но в итоге из-за только одного прохода получившееся ПО может не соответствовать потребностям заказчика. Быстрое прототипирование несамостоятельно, в ряде случаев вызывает у разработчиков соблазн повторного использования быстро разработанного ненадежного, недокументированного кода. Способствует сопровождаемости и обеспечивает максимально ранний возврат инвестиций, так как приводит к консенсусу по поводу требований заказчика. Инкрементальная модель требует открытой архитектуры и может выродиться в Build-and-fix, но в целом удовлетворяет потребностям клиента из-за эволюционного процесса разработки продукта. Модель синхростабилизации обладает рядом преимуществ, но не получила широкого применения вне Microsoft. Спиральная модель пригодна в первую очередь для внутренних проектов, так как требует специфических знаний по оценке рисков. Объектно-ориентированная модель обеспечивает итерации и паралеллизм, но опять же при слабой дисциплине проекта может выродиться в модель Build-and-fix.

Рис. 3.11. Жизненный цикл ПО, гибкие методологии, Scrum

Рис. 3.12. Жизненный цикл ПО, гибкие методологии, eXtreme Programming (XP)

Глава 4 Выбор модели жизненного цикла корпоративных систем

В предыдущей главе были рассмотрены преимущества и недостатки основных моделей ЖЦ – Build-and-fix, водопадной (каскадной) модели, где проектирование корпоративных информационных систем происходит в один проход, модели быстрого прототипирования (несамостоятельной, так же как и Build-and-fix), инкрементальной, модели синхронизации и стабилизации Microsoft, которая в настоящее время смещается в сторону MSF, спиральной и объектно-ориентированной модели. Также были рассмотрены основные характеристики и особенности моделей, их основные достоинства и недостатки.

Сначала обсудим выбор модели жизненного цикла для интернет-магазина, например магазина музыкальных инструментов, этнических редкостей из Африки, книжного магазина. С точки зрения продуктовой линейки особой специфики здесь нет, потому рассмотрим пример выбора модели жизненного цикла при разработке интернет-магазина вообще.

Итак, пусть требуется создать ПО, которое реализует программный проект построения многокомпонентной информационной системы, которая программно поддерживает интернет-магазин, осуществляющий торговлю этническими редкостями из Африки. Требуется оценить с точки зрения usability (удобства использования) сайт для торговли через Интернет этническими редкостями и сделать его более удобным в использовании. Обсудим этапы жизненного цикла проекта в связи с требованиями, которые возникли предварительно в ходе обсуждений с заказчиком. Этот выбор нужно сделать как можно раньше, потому что неверный выбор подхода к реализации системы может привести к неверному проектному решению, программной архитерктуре, в результате – к достаточно серьезным накладным расходам при проектировании, реализации и, что очень важно, сопровождении продукта.

В качестве исходных данных есть некий набор знаний о продукте в форме первоначального представления заказчика, который предполагается неглубоко технологически эрудированным, но являющимся собственником небольшого бизнеса и понимающим, что торговлю лучше вести в том числе и при помощи интернет-площадки. При этом у заказчика имеется некое первоначальное представление о том, какими характеристиками должен обладать интернет-магазин, исходя из пусть и дилетантского анализа сайтов конкурентов. Заказчик понимает, что основные задачи, которые решают интернет-магазины конкурентов, его сайт должен решать. И он исходит при этом во многом из того представления о визуальном интерфейсе, которое он имеет. Результат работы должен быть выдан в виде списка требований. Неформально это можно представить как эссе – перечень характеристик и ограничений, в том числе и количественных, это принципиально для разработчиков, которые будут обеспечивать функциональность продукта на основе требований и ограничений к нему. Эссе потому, что каждый пункт выбора (та или иная технология, платформа) должен быть обоснован. Естественно, речь должна идти о достаточно небольшом программном решении, но в принципе расширяемом и до системы корпоративного типа.

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

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

Исходя из этих предпосылок перечислим модели. Build-and-fix – модель неполного жизненного цикла, которая содержит краткое описание стадий ЖЦ: первичное проектирование и анализ упрощены, документация присутствует не в полном объеме. Водопадная (каскадная) модель – один проход по всем стадиям жизненного цикла, жесткое документальное согласование каждого этапа с возможностью продолжения или прекращения работы. Модель быстрого прототипирования – несамостоятельная, может применяться как вспомогательная для уточнения технических характеристик. Инкрементальная модель, модель Microsoft (синхростабилизации); объектно-ориентированная модель, где есть взаимодействие и даже перекрытие этапов.

Какие модели можно исключить и почему? Модель Build-and-fix имеет смысл исключить сразу, если решение будет расширяться, а проект необходимо сопровождать. Конечно, этот проект может выйти за рамки 1000 строк, что является пределом для этой модели. Кроме того, программный продукт – законченное решение, включающее помимо кода множество документации: техническое задание (или другой документ со спецификацией требований), большое количество сценариев использования (десятки, сотни страниц), диаграмм, описывающих динамику поведения системы (переходов состояния, потоков данных, последовательности, взаимодействия, классов). Таким образом, модель Build-and-fix существенно ограничена и для данного проекта неприменима.

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

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

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

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

Какие модели могут быть использованы вполне, но с некоторыми замечаниями? Модель быстрого прототипирования будет в это случае вполне уместна. Естественно, не как самостоятельная, а как сопровождающая некоторую более серьезную модель. Она применима, потому что у заказчика нет в полной мере четкого представления о функционале и недостает технических знаний, чтобы очертить требования и оговорить функциональность, которая должна быть реализована. Поэтому очень сложно организовать диалог разработчика с заказчиком: они фактически говорят на разных языках. В этом случае на помощь приходит прототип, который как раз и проявит ту функциональность, о которой, возможно, мечтал заказчик, но не формулировал ее явно в силу ограниченности своих технических знаний. С другой стороны, она даст основания разработчику для того, чтобы корректно проектировать и реализовывать программный продукт, избавит разработчика и заказчика от непроизводительных потерь времени, людских ресурсов и средств. Для создания быстрых прототипов подходят технологии Microsoft (Visual Studio). Там существуют хорошие конструкторы визуальных форм и отчетов. Возможно достаточно быстро представить заказчику вариант интерфейса, включая командные кнопки, меню в стиле Windows, привычном заказчику, и обсудить с ним детали будущей реализации, на основе которых можно четче сформулировать технические требования и, что очень важно, определить окончательный выбор модели, поскольку все еще есть различные варианты.

Теперь о моделях, которые в большей мере пригодны для решения этой задачи. Прежде всего это объектно-ориентированная модель. Понятно, что в интернет-магазине речь пойдет скорее всего об объектно-ориентированном приложении, которое реализует некоторые сценарии: взаимодействие пользователя с интерфейсом, взаимодействие компонентов системы. Понятия предметной области – корзина, заказ, товары – вполне хорошо могут быть реализованы на основе иерархии наследования. Потребуется большое количество атрибутов, соответствующих каждому артикулу товара: краткое словесное описание, полное описание, изображение, потому что если говорить об африканских редкостях, пользователю сложно оценить по словесному описанию, что же именно он хочет приобрести. Точно так же есть определенные атрибуты у корзины, заказа и т. д. При этом, конечно, объектно-ориентированную модель имеет смысл объединять с быстрым прототипированием, которое быстро реализуется и поможет при первом обсуждении проекта. При реализации полномасштабного продукта код, созданный при быстром прототипировании, необходимо будет начисто переписать.

Если планируется, что разрабатываемый продукт будет развиваться, можно будет применить инкрементальную модель, хотя и не совсем подходящую, или спиральную модель. Ее преимущества в том, что она подходит для реализации постоянно развивающегося программного средства. А в нашем случае заказчик, вероятно, потом захочет добавить дополнительную функциональность: например, подключение систем электронных платежей (WebMoney, Яндекс. Деньги и т. д.), кредитных карт (нужен будет сервер приложений, осуществляющий верификацию данных пользователей, проверку наличия достаточных средств на карте и т. д.), отслеживание пути движения заказа, sms-информирование клиента и т. д. Однако спиральная модель может не очень хорошо подходить, если этап анализа рисков очень дорог. Но для нашего проекта можем обойтись упрощенным анализом рисков – спиральная модель будет приемлемым решением.

С другой стороны, спиральная модель может быть непригодна и по другой причине: она хороша для проектов, которые выполняются в рамках одной корпорации, когда между заказчиком и исполнителем существует высокий уровень доверия и могут быть раскрыты критические бизнес-ограничения этой системы. Поскольку в нашем случае речь идет о простой системе и можно предположить, что объем критической бизнес-информации не так велик и заказчик поделится им с разработчиком, можно считать, что для данного проекта спиральная модель может быть использована. Конечно, ее тоже имеет смысл объединять с быстрым прототипированием, чтобы не накручивать лишние витки спирали и не терять времени, средств и людских ресурсов.

Таким образом, были перечислены основные подходы к решению для интернет-магазина африканских редкостей. Попробуем обсудить ограничения и составить список требований, т. е. приступить к началу реализации. Предположим, что заказчик подглядел типичный интерфейс, представленный на рис. 4.1, у одного из своих конкурентов, и никакой особой функциональности ему не нужно.

Рис. 4.1. Интерфейс интернет-магазина

Итак, имеется экранная форма с каталогом продукции и списком продуктов. Например, выбран там-там. Имеется его фотоизображение, у него есть некое описание, более подробное, чем название, цена, указанная в условных единицах, вес в килограммах. Существует корзина, куда можно добавлять элементы из каталога. В корзине уже лежат два там-тама и дудочки в количестве трех штук. С помощью командных кнопок пользователь может выбрать вид доставки, осуществить удаление одного элемента из корзины или очистить ее целиком, может перейти к оформлению заказа, т. е. получить некий отчет о поступлении заказа в производство. Заказ получает номер, имеет общую стоимость и общий вес. Отдельно оплачивается стоимость доставки в зависимости от ее способа. Кроме того, есть кнопка «история заказов», которая говорит о том, что есть некая база данных или файл, где хранятся сведения о заказах, которые пользователи осуществляли ранее. Возможно, в зависимости от истории заказов пользователям будут предоставлены некоторые преимущества, например скидки или льготы по доставке. Далее происходит вычисление общей стоимости заказа. Есть кнопки, связанные со служебными функциями: кнопки регистрации, входа, помощи. Есть форма регистрации пользователя в системе. По логину система получает информацию о предыдущих заказах пользователя и может отслеживать свои взаимоотношения с клиентом.

Даже по этой форме можно сказать о возможностях программного продукта, которые следует реализовать. С другой стороны, целый ряд вопросов, особенно касающихся технических ограничений, остается за кадром. Например, неясно количество одновременно работающих пользователей, объем базы данных (о нем заказчик судить вообще не может).

Дальнейшие шаги сводятся к составлению списка требований и ограничений. Нужно кратко описать основную функциональность, которую будет реализовывать наш продукт. После этого будут проходить стадии жизненного цикла продукта, которые детализируют это начальное описание сценариями использования, рядом других диаграмм, а в итоге – кодом и документацией. Для начала необходимо составить список основных требований и ограничений. При этом при разговоре с заказчиком следует выразить ему в виде вопросов свои сомнения по поводу предметной области или технических характеристик продукта. Например, должна ли система функционировать 24 часа в сутки или достаточно какого-то фиксированного времени, аналогичного часам работы обычных магазинов? Должна ли система представлять всю продукцию, которая есть у заказчика, или это должны быть только малогабаритные предметы? Нужны ли резервные копии базы данных, да и нужна ли в системе вообще база данных? Может, достаточно хранить информацию в виде файлов. Это определяется количеством пользователей. Если история заказов все-таки должна где-то храниться, то правильнее будет включить базу данных в системную архитектуру.

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

Вот как можно представить список требований исходя из программного интерфейса, представленного на рис. 4.1. Система должна иметь механизм авторизации, который включает имя и пароль для каждого пользователя; должны предоставляться возможности входа в систему, смены пароля, должен обрабатываться как нормальный сценарий входа в систему, так и неуспешная попытка входа в систему (из-за нарушения связи, некорректного ввода имени и пароля и т. д.); должна предоставляться возможность просмотра информации о той продукции, которая есть в каталоге. Необходимо, чтобы пользователь мог выбрать те элементы, которые ему нужны. При этом поддерживается список кратких имен каждого продукта, описаний, расширяющих краткие имена. Возникает вопрос, вся ли продуктовая линейка обычного настоящего магазина должна перейти в интернет-магазин. Это нужно обсудить с заказчиком. Для хранения информации о товарах имеет смысл использовать базу данных. Еще одной возможностью, которую должен предоставлять магазин, является просмотр каталога продукции. Важными ограничениями являются параметры каталога, потому что его изготовление повлечет некие затраты: расходы на фотографирование товаров, сканирование их описаний, перевод, консультации со специалистами. Мы должны ограничить количество единиц в каталоге продукции.

Наименование продукта должно описываться текстовым полем ограниченной длины (например, 50 символов). Описание должно быть текстовым полем большей длины, по которому пользователь может понять, подходит ему товар или нет. Также должно быть изображение – обычное, цветное, статическое, объема порядка сотен килобайт. Возможно, одной фотографии будет недостаточно (это тоже можно обсудить с заказчиком). Поскольку в требованиях также говорится о доставке заказа, нужно определить такое понятие, как вес, потому что он выступает определяющим условием для типа и стоимости доставки. И, конечно, у продукта должна присутствовать цена. Это атрибут не конкретного экземпляра, а всего типа продуктов. Еще нужен некий внутренний код (артикул) для идентификации продукта (это тоже наводит на мысль об использовании СУБД).

Еще одним важным требованием будет работа с корзиной. У корзины тоже должны присутствовать атрибуты. Это количество товаров в корзине (общее и каждого вида), способ доставки, возможно, еще некоторые связанные атрибуты – способ оплаты и т. д. Также важны функции – способы, которыми пользователь будет оперировать с объектами в корзине. Здесь существует ряд функций, связанных с добавлением и удалением товаров (по одному, группой). Имеет смысл предусмотреть полную очистку корзины и удаление товаров по одному. И, наконец, оформление заказа. История заказов – вероятнее всего, таблица базы данных с полями: реквизиты заказчика (ФИО, логин), адрес доставки, дата заказа, номер заказа (первое, что спрашивает оператор в интернет-магазине).

Существуют вычисляемые поля: стоимость заказа, общее количество товаров, вес. Их не следует делать хранимыми, а имеет смысл вычислять.

Также необходимо определить технологии, которые будут присутствовать в списке требований. При этом мы должны детализировать несколько глобальных параметров. Это прежде всего вид интерфейса. Скорее всего он будет графическим. Интерфейс содержит окна, выпадающие списки, меню, командные кнопки (вход в систему, оформление заказа, дополнительные возможности). Таким образом, интерфейс должен делиться на графическую и логическую части. То есть это определенные классы элементов управления (будут ли это предопределенные классы. NET или разработанные вручную) и логическая часть (сценарии работы пользователя). При этом понятно, что работа осуществляется реализацией некоторых сценариев (например, вход – заказ – выход) и ряд сценариев вариативен.

В общей архитектуре системы имеется клиентская часть, которая уже была описана, и логика, а также есть некая часть, связанная с СУБД, где хранится каталог товаров и история заказов, плюс есть механизм, определяющий серверную часть реализации. Он работает с базой данных, извлекая из нее необходимую информацию, он передает эту информацию в интерфейс пользователя и содержит логику работы. Таким образом, это трехзвенная архитектура вида клиент – сервер. Далее нужно детализировать такие параметры, как тип СУБД (Oracle, Microsoft SQL Server и т. д. исходя из сроков реализации, объемов данных, используемой модели, интенсивности транзакций), язык и среда реализации (платформы Java или. NET, язык Java или C# исходя из опыта разработчиков и пожеланий заказчика; Java-решение может быть менее затратным), CASE-средства для создания, развития и поддержки продукта.

Следующее, на что следует обратить внимание, – ограничения, накладываемые на программный продукт. Именно они во многом будут определять трудозатраты при производстве конечного продукта, скажутся на качестве проекта и его функциональности. Есть ряд параметров, которые следует учесть прежде всего: это в первую очередь время непрерывной работы – время, которое сервер должен работать до отказа; время восстановления работы, которое должно быть отражено в документации (нужно понимать, какие действия входят в восстановление работоспособности после сбоя); количество и типы пользователей – существуют менеджеры магазина, заполняющие каталог, пользователи, отвечающие за финансовую часть, рядовые покупатели (если система будет расширяться, могут появиться администратор сети, администратор безопасности и т. д.); возможно, будут разные типы пользователей: обычные, привилегированные (имеющие дополнительные возможности). Нужно также оговорить количество одновременных пользователей, ограничив его сверху, и исходя из этого строить программные решения: механизмы взаимодействия с СУБД, откаты транзакций и т. д.

Порядок объема базы данных – сотни мегабайт. Если предусмотреть дополнительные или более высококачественные фотографии размером порядка мегабайта и если товаров порядка сотни, то размер БД будет порядка гигабайта. Сейчас это предварительные соображения, но в документ с требованиями необходимо внести данные о том, какого рода ограничение должно быть на объем данных сверху. Для определения интенсивности транзакций нужно сделать предположение, насколько сложные запросы к базе данных возможны, какова интенсивность транзакций, каков их механизм, какова пропускная способность интернет-канала, который будет узким местом в системе. Поэтому имеет смысл предусмотреть различные механизмы представления информации. Ряд пользователей будет заинтересован в более качественных фотоизображениях, поэтому необходимо оговорить тот порог, который предусматривается для пропускной способности, просто чтобы обезопасить себя от изменения факторов, за которые мы не можем отвечать. Если пропускная способность сети падает ниже возможностей модема, можно говорить о том, что система не сможет работать стабильно. Можно обсуждать с заказчиками скорость порядка десятков мегабит. В любом случае нужно четко описать и это количественное ограничение.

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

Еще одним параметром списка требований является эргономика: какое количество форм, параметров и кнопок необходимо, как будет выглядеть цветовая гамма, каким образом будут расположены элементы управления, чтобы пользователю было удобно. Ключевые характеристики эргономических особенностей тоже должны быть отражены в этом списке.

Теперь посмотрим, каким образом можно сделать набросок первичных требований к системе в форме списка требований (requirements checklist). Он, конечно, не будет настолько всеобъемлющим, как техническое задание, но для относительно простого и небольшого интернет-магазина с этого документа вполне можно начать.

Особенности механизма авторизации. Система должна иметь возможность авторизации пользователей. Для простоты: пока есть один тип пользователей – покупатели. Каждый пользователь характеризуется именем пользователя и паролем. Пользователь может задать свое имя и свой пароль (возможно, полезна будет автогенерация паролей), сменить пароль в любое время сеанса работы с системой. Формулируются понятия авторизованного и неавторизованного пользователя: если пользователь не пытался войти в систему или ввел при входе некорректные имя и пароль, пользователь получает статус неавторизованного. В противном случае пользователь становится авторизованным. Это важные понятия, потому что в зависимости от состояния пользователя система предоставляет ему различные сервисы. Можно оговорить еще и количество попыток ввода имени и пароля. Также система должна выдавать адекватное сообщение об ошибке. Авторизованный пользователь должен иметь возможность выйти из авторизованного режима. Сохранять ли состояние корзины, нужно обсуждать с заказчиком.

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

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

Просмотр каталога продукции. Допустим, что пользователь может просмотреть информацию о каждом наименовании продукции отдельно (например, по щелчку мыши). При этом каждое наименование позиций в каталоге должно содержать наименование товара, краткую текстовую информацию о нем, более полное описание (200–300 символов), изображения (количество, размер, глубина цвета), вес товара, цена.

Работа с корзиной. Корзина – промежуточное хранилище товаров в системе. При выборе продукции пользователь должен указать количество экземпляров данного наименования продукции (должно быть ограничение на него), способ доставки (явно перечисляем типы доставки, определенные в системе). Как только выбирается способ доставки, в корзине появляются данные о стоимости доставки (оговаривается алгоритм ее расчета). При этом авторизованный пользователь, в отличие от неавторизованного, должен иметь возможность работы с корзиной: добавление товаров, просмотр корзины, удаление товаров. В данном случае он имеет возможность как полностью очистить корзину, так и удалить товары поэлементно. Это тоже важно указать, чтобы при реализации системы у заказчика не возникло разночтений. При работе с корзиной авторизованный пользователь должен иметь возможность просмотра следующей информации: общая стоимость всей продукции (это вычисляемое поле, а не хранимое), общая стоимость доставки (также вычисляем ее как сумму стоимости доставки всех товаров), общий вес продукции (конечно, с учетом выбранного количества продукции), общая стоимость заказа. Здесь можно оговорить различные скидки (например, в зависимости от стоимости заказа или возраста пользователя). Естественно, пользователь не может изменить стоимость заказа.

Важным является понятие сессии: продукция в корзине пользователя хранится только в ходе одной сессии. Началом сессии можно считать вход в систему, концом – закрытие браузера или нажатие кнопки «Выход». Между этими двумя событиями происходит сессия. После окончания сессии пользователь становится неавторизованным и из корзины все удаляется.

Другое важное функциональное требование – способ оформления заказа. Естественно, оформление заказа возможно только после того, как пользователь выбрал необходимое количество товаров в корзине и нажал на кнопку «Оформить заказ». Таким образом, оформление заказа также доступно только для авторизованных пользователей – это явно указывается в документе. Заказ включает в себя всю продукцию из корзины и свойства доставки – эти атрибуты автоматически переносятся из корзины в заказ. Если нажата кнопка «Оформить заказ», он автоматически попадает в БД и не может быть отменен. Также важно, что после оформления заказа сессия продолжается, но вся продукция из корзины удаляется автоматически. Это тоже нужно явно отметить.

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

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

• Интерфейс пользователя

Пользовательский интерфейс состоит из графического интерфейса пользователя и логической части

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

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

Пользовательский интерфейс реализован как Java-приложение (версия j2sdk 1.4.2). Графический интерфейс реализован с использованием Swing

Среда разработки – Idea 7.0.1

• База данных

Система хранит в базе данных всю статическую информацию: данные о каждой продукции (наименование, цена, вес, описание, указатель URL к графическому файлу), данные о цене доставки по земле и по воздуху, данные о заказах

В качестве СУБД используется PostgreSQL версии 8.2.4

• Обеспечение связи с базой данных

Для обеспечения связи с базой данных разработан модуль связи с БД. Модуль реализован на языке Java (версия j2sdk 1.4.2). Доступ к БД обеспечен с помощью JDBC (используется драйвер JDBC для PostgreSQL, postgresql-8.2-506.jdbc4.jar)

Следует обратить внимание на то, что в этих требованиях уже частично прописаны сценарии использования, их можно проследить. Кроме того, мы оговариваем функции авторизованного пользователя, например возможность просмотреть историю всех своих и только своих заказов (как информацию по каждому заказу в отдельности, так и совокупно по всем заказам; возможно, имеет смысл предусмотреть сортировку заказов). В любом случае необходимо полно и однозначно сформулировать информацию, содержащуюся в заказе (т. е., по сути, поля таблицы БД): ключ – уникальный идентификатор заказа, по нему будет проводиться поиск и сортировка; дата; стоимость; наименования товаров с указанием их количества.

Теперь нужно сказать об используемых программных технологиях. На слайдах приводится один из возможных примеров. Исходя из того что будет выбрана объектно-ориентированная модель, выбирается объектно-ориентированный инструментарий на основе того, что магазин нужен не очень большой, но расширяемый, нужно выбрать инструментарий Java. Тогда возникают основные компоненты: СУБД, язык (логика программной работы и графический интерфейс), серверная часть (ее для простоты можно опустить) и технология связи с базой данных (при данном инструментарии это JDBC). При использовании тех или иных технологий также необходимо рассматривать ограничения. Сразу нужно сказать, что хорошим тоном является упоминание не только названий, но и версий продуктов, которые будут применяться, потому что можно протестировать совместимость этой версии как со средствами, которые имеются у пользователя, так и с элементами программного комплекса, которые мы планируем реализовать.

Важно рассмотреть глобальные элементы интерфейса с точки зрения архитектуры. В интерфейсе пользователя выделяется часть, связанная с графикой (формами, отчетами, командными кнопками, выпадающими списками, окнами и т. д.), и логическая часть, обеспечивающая поддержку сценариев взаимодействия пользователя с системой (обе они будут писаться на языке Java). Забегая вперед, скажем, что удобнее проектировать систему на. NET с помощью Visual Studio и использовать ряд готовых графических примитивов, которые мы можем с помощью мыши объединить, поместив на форму. При реализации на основе Java это будет чуть сложнее.

Что включает в себя графический интерфейс, мы можем определить на основе рис. 4.1. Графический интерфейс позволяет просматривать каталог продукции, данные по каждой позиции отдельно (здесь можно прямо указать соответствующий раздел технических требований). Кроме того, пользователь должен при помощи графического интерфейса иметь возможность отслеживать хронологию заказов, работать с корзиной (например, просто перебрасывать элементы каталога в корзину с помощью механизма drag&drop и посредством мыши и клавиатуры изменять количество элементов продукции в своем заказе), удалять и добавлять элементы в корзину.

Теперь опишем функционал логической части интерфейса пользователя. Логическая часть формирует запросы к БД (например, на языке SQL), передает их и получает ответ (с помощью JDBC). Кроме того, логическая часть позволяет обновлять информацию в БД и формировать заказы. Необходимо ограничить пользовательский интерфейс с учетом той программной платформы, которая используется, а также явно указать спектр версий, с которыми совместимо разрабатываемое ПО, для того чтобы не нести ответственность за тот широкий спектр версий Java, который потенциально может использовать заказчик.

Следует отметить, что графический интерфейс, который является частью решения, должен быть реализован с использованием технологий и библиотек Swing (здесь тоже лучше указать версию). Кроме того, среда разработки и средства также должны быть указаны: используем ли мы NetBeans, Eclipse или что-то другое. Например, в данном случае будем использовать среду разработки Idea 7.0.1. Это нужно четко указать для возможности дальнейших модификаций продукта.

Еще ряд важных технологических требований касается других элементов магазина. Во-первых, требования к БД. Прежде всего необходимо явно описать способ хранения данных. Так как объем хранимых данных достаточно велик, следует использовать СУБД, а не файлы. Программная система хранит в БД всю статическую информацию: каталог продуктов, заказы, служебная информация (имена и пароли пользователей, их адреса, ФИО). Что касается единиц продукции, нужно перечислить все атрибуты таблицы, где хранится каталог продукции: наименование, цена, вес, описание, указатель (URL) на изображение данного товара, цена доставки (по земле и по воздуху). Можно сослаться здесь на структуру данных о товаре из списка требований. Естественно, впоследствии при детализации требований необходимо в документации описать ER-диаграммы, которые будут описывать все структуры данных, поля и их типы, включая индексируемые, ключевые и т. д. Еще очень важно оговорить тип СУБД, ее название и версию: мы будем использовать реляционную СУБД PostgreSQL версии 8.2.4, и тогда у нас не возникнет сложностей с сопровождением и дополнительных конфликтов с заказчиков. Естественно, нужно обсудить с заказчиком используемый спектр программного обеспечения.

Третьей составляющей программной системы является обеспечение связи с БД. В данном случае, поскольку мы работаем с технологией Java, будем использовать JDBC. Мы четко указываем, что будем разрабатывать модуль связи с базой данных (отдельный класс). Отдельно указываем версию JDBC – 1.4.2 (как и версия Java). Далее указываем тот самый драйвер JDBC, который мы будем использовать. Естественно, он связан с PostgreSQL. Впоследствии у нас возникнет ряд документации по установке баз данных, да и всей программной среды. Будут указаны все каталоги, переменные окружения и т. д.

На этом завершим рассказ о том, каким образом происходит первичное проектирование и, главное, выбор модели жизненного цикла ПО. Обратим внимание на то, каким образом и с какой степенью детализации производится описание системных требований, как описывается системная архитектура, и далее в ходе дальнейшего проектирования, реализации, тестирования и передачи на сопровождение продукт будет дополняться большим количеством документации (а не только кода), которая будет все более детализировать предметную область и программные решения. Появятся диаграммы сценариев использования (диаграммы прецедентов), большой текст, который будет описывать сценарии использования, ключевые понятия, извлекаемые из сценариев тем или иным образом (например, при помощи CASE-средств), которые в итоге станут кандидатами в первичные классы. Появятся диаграммы классов, которые будут детализированы атрибутами, методами, локальными и глобальными переменными, алгоритмами и структурами данных, появится целый ряд диаграмм, которые описывают динамику системы (диаграммы переходов состояний, диаграммы взаимодействия, диаграммы последовательностей), целый ряд диаграмм структуры БД (ER-диаграммы), различные фрагменты кода классов программных модулей, классов с построчной документацией, тест-кейсы, юнит-кейсы, которые будут использоваться при передаче продукта заказчику, целый ряд документов для конечных пользователей системы: администраторов (пути, программные средства, установка и настройка системы), персонала сопровождения (сценарии использования), пользователей (краткая справка и полное описание продукта). Полное описание должно включать в себя определение всех терминов, связанных с продуктом (сервер БД, веб-сервер, пользователи, их виды), сценарии работы, скриншоты с учетом всех ошибок, которые могут возникать в системе, небольшое средство для обучения пользователей, порядок работы с пользовательской документацией, целый ряд других документов, которые будут переданы пользователю вместе с программным кодом в составе программного продукта.

Глава 5 Методологии разработки корпоративных систем

В предыдущих главах были описаны модели жизненного цикла корпоративных систем, основные этапы их существования, начиная от концептуальной идеи, формализации требований, проектирования, реализации, передачи в эксплуатацию или на стадию сопровождения (собственно то, ради чего весь этот жизненный цикл строится) и вывод из эксплуатации. Было описано, каким образом перечисленные этапы отражаются в различных подходах или моделях жизненного цикла. Некоторые модели включают все стадии (объектно-ориентированная модель), другие – (Build-and-fix) не все стадии жизненного цикла. Существуют модели, которые основаны на линейной смене фаз (каскадная или водопадная), другие поддерживают определенную итеративность или цикличность (объектно-ориентированная или спиральная модели). Ряд моделей позволяет рассматривать некоторые этапы жизненного цикла параллельно или во взаимодействии, это прежде всего объектно-ориентированная модель, в которой сочетаются анализ и проектирование. Существуют несамостоятельные модели, такие как модель быстрого прототипирования. Отсюда следует вывод, что ряд моделей можно комбинировать. Комбинировать следует прежде всего некоторые из моделей полного жизненного цикла (спиральная, каскадная) с моделью быстрого прототипирования. Это дает возможность существенно экономить сроки и стоимость внедрения, избежать существенных проектных ошибок, так как позволяет проявить функциональность программного продукта уже на ранних стадиях (анализ и спецификация требований, начальный этап проектирования), а также благодаря быстрому прототипу вместе с заказчиком определить, в том ли направлении мы двигаемся и правильно ли понимаем друг друга.

Теперь рассмотрим параллельное направление, которое тоже связанно с подходами к разработке корпоративных информационных систем и называется методологией. Здесь возникает терминологическая нестыковка. Методология – набор приемов, методов и моделей, инструментальных средств. Здесь методология – это набор практических приемов. Тут нет математических моделей, экономического обоснования. В ряде подходов (методологии), особенно в гибких методологиях (Scrum, Agile), речь идет о гибко настраиваемой системе лучших практик или просто практических приемов разработки информационных систем. Поэтому в научном смысле о методологии здесь говорить не совсем верно. И в этой связи то, что было сказано о моделях жизненного цикла информационных систем, будет больше похоже на методологию, если к этому присовокупить еще и практические приемы. Также рассмотрим определенные классы инструментальных средств.

Методология – это параллельное направление (или ортогональное, еще одна ось, вдоль которой можно рассматривать жизненный цикл). Ранее уже упоминалось, что можно рассматривать программные проекты и программные продукты (их жизненный цикл отличается). В этой главе речь пойдет о программных продуктах, и акцент ставится больше на моделях, чем на методологиях. Но методологии полезны как набор практических приемов для достаточно эффективной реализации, в том числе и корпоративных приложений. Методологии, которые будут рассматриваться, могут включать различные модели. Например, методология Rational Unified Process может иметь в основе модель как каскадного жизненного цикла, так и спирального. То же можно сказать о методологии Microsoft Solution Framework (MSF). Методология с точки зрения жизненного цикла и точки зрения детализации этапов разработки информационных систем – это не столь формальный подход, как модели. В ряде случаев в зависимости от характера и масштаба проектов могут быть существенные коррективы. Rational Unified Process может становиться большим или малым (применяется более или менее развернутая схема разработки). В Microsoft Solution Framework также могут рассматриваться варианты более гибкого подхода (Agile) или подхода Formal (более полного). Желательно иметь в виду соотношение методологий и моделей.

Достаточно важно замечание по поводу характера и масштаба методологий. Существуют методологии, которые в полной мере подходят для проектирования корпоративных систем, и их можно назвать корпоративными (или тяжелыми). Они по аналогии с моделями описывают весь жизненный цикл, позволяют подготовить достаточно полную проектную документацию, хотя каждая из них является просто набором хороших приемов и в ряде случаев допускает упрощенный подход к проектированию и реализации информационных систем. И существуют более легкие (гибкие) методологии, которые не идеально подходят для больших корпоративных систем и могут использоваться при определенных условиях: при высоких рисках, высоких степенях неопределенности в проекте. Такие большие (тяжелые) методологии – это аналоги каскадной, спиральной моделей, не в том смысле, что эти модели там используются, а в том, что это достаточно полное представление жизненного цикла. Такими тяжелыми методологиями являются: Rational Unified Process и Microsoft Solution Framework. Rational Unified Process на сегодняшний день является методологией, которая представляется корпорацией IBM, Microsoft Solution Framework – корпорацией Microsoft. Интересно, что методология MSF возникла из модели синхронизации и стабилизации, и здесь имеются аналогии. Но если говорить о MSF как о методологии, речь пойдет скорее не о жизненном цикле программной системы, а о тех приемах и методах, которые нужны для поддержания этого цикла, для разработки, не только о программном продукте, но и о программном проекте (о ролях в проекте, их особенностях, взаимодействии персонала, проектной документации, которая поддерживает выполнение определенных видов деятельности).

Что касается легких или гибких методологий, будут рассмотрены в разной степени детализации Scrum, Agile, eXtreme Programming. Они являются наборами лучших практик, т. е. наборами рекомендаций о том, каким образом при высоких проектных неопределенностях и рисках вести разработку программных систем для того, чтобы обеспечить определенные качества результирующего программного продукта, если это вообще возможно, или прекратить разработку, если это невозможно, при этом уложившись в определенный бюджет и сроки.

Также будут описаны преимущества и недостатки этих методологий, но общее преимущество сводится к тому, что это практически ориентированные подходы, которые изначально нацелены на оптимизацию затрат. С другой стороны, недостаток можно увидеть в том, что это неформализованные, не имеющие под собой математических моделей, не предназначенные для оптимизации, хотя, конечно, здесь есть метрики. Если нет четкого математического способа для описания модели разработки программных систем в рамках этих методологий, то говорить о том, что с их помощью можно получить оптимальное решение, не совсем правильно. Можно получить достаточно хорошее, прагматичное решение, но не то, о котором можно сказать, что оно оптимально в математическом смысле этого слова.

Поговорим о методологии Rational Unified Process, которую кратко называют RUP. Она была разработана компанией Rational, затем унаследована корпорацией IBM и сегодня поддерживается достаточно большим количеством инструментальных средств линейки Rational, которые закрывают весь жизненный цикл программного обеспечения. Это и средства проектирования, и средства управления проектами, и целый ряд средств, которые нацелены на фазы разработки, тестирования, внедрения и сопровождения. В линейке более 10 средств, которые взаимодействуют друг с другом, призваны вести проектирование на основе RUP и поддерживают практически весь жизненный цикл программного обеспечения. Самое главное, что нужно отметить о подходе Rational Unified Process, – это то, что есть несколько важных направлений, которых он придерживается. Это прежде всего итеративность (последовательная доработка, примерно, по спиральной или инкрементальной модели). Оценка рисков является важной составляющей RUP (на самом деле всех методологий, особенно гибких). Кроме того, подход имеет в своей основе архитектурную центричность (основан на том, что в центре всего проекта находится архитектура и этап архитектурного проектирования), также применяются сценарии использования. Тут нет ничего удивительного. Сценарии использования применяются широко в языке UML, который поддерживает большинство CASE-средств. Прецеденты – это один из первых видов диаграмм UML, которые встречаются по пути жизненного цикла программных систем. На стадии первичного проектирования возникают прецеденты, и диаграммы прецедентов детализируются в ходе проектирования на сценарии использования. Сценарий использования, по сути, являет собой конкретизацию прецедента. То есть если имеется прецедент, который объединяет такие роли, как пользователь и система, и представляет собой вход в систему (регистрацию), то сценариев использования здесь может быть, как минимум, два – это успешная и неудачная регистрация. То есть сценарий использования детализирует возможные варианты прецедентов.

Кроме того, Rational Unified Process – это достаточно четко определенный и структурированый процесс, последовательные стадии, через которые проходит программное обеспечение по мере своего создания, и важно провести взаимосвязь с дисциплиной программной инженерии. Действительно, RUP вместе с MSF – это та методология, которая предназначена для производства больших, сложных систем, состоящих из ряда взаимодействующих компонентов, возможно включающих базы данных (т. е. корпоративных систем). Rational Unified Process имеет четкую структуру и как методология является достаточно жестким подходом.

Еще одна методология, о которой упоминалось раньше и которая тоже является достаточно жесткой, – это Oracle CDM, но сегодня она применяется нечасто. Она основана на вариации каскадной модели и вполне может быть использована для производства корпоративных приложений. Rational Unified Process – это технология разработки корпоративных информационных систем, которая основана во многом на процессах, она так же, как и жизненный цикл программного продукта, включает четыре стадии.

Очень важно, что RUP, MSF и методологии меньшего калибра основаны на процессах и описывают взаимодействия ролей тех людей, функциональных групп, которые участвуют в этих процессах. При этом процессы разбиваются на активность.

Поскольку речь идет об итерации, каждая стадия может повторяться большое количество раз (как минимум, три – четыре раза для серьезных программных продуктов). Эти стадии называются: начало, проектирование, построение, внедрение (рис. 5.1). Информация не является закрытой, она доступна на соответствующих интернет-ресурсах, т. е. это открытая, общедоступная методология. Более того, корпорации IBM и Microsoft стараются их популяризировать, давать возможность и сторонним разработчикам, и другим компаниям разрабатывать информационные системы.

Рис. 5.1. RUP: основные вехи

Первая фаза называется началом и совмещает стадию первичной выработки концепции и требований высокого уровня к системе и экономического обоснования (сроки и стоимость). Естественно, говорить о спецификациях детального проектирования здесь еще рано, речь идет о документе, который приблизительно соответствует списку требований и в общем виде описывает функциональные требования и ограничения, которые предъявляются к продукту. Кроме того, речь идет о документе, который представляет собой первоначальный эскиз плана проекта (список основных ограничений по проекту, прежде всего экономического характера). Нужно отметить, что в методологиях существует важное понятие вех (основных этапов), каждая из них характеризуется документами, которые должны быть получены по завершении ключевых активностей, предусмотренных той или иной вехой. Как только документы, связанные с построением общей концепции требований к проекту, и скелет плана проекта построены, можно сказать, что на этой итерации мы завершаем первую фазу и переходим к детальному проектированию.

Очень важно подчеркнуть, что если первичное проектирование отвечает на вопрос «Что мы делаем?», то вторая фаза – на вопрос «Как?». Здесь речь идет об архитектурной составляющей проекта, из каких компонентов он будет состоять, как они будут взаимодействовать. С точки зрения программной архитектуры принимаем решение: будет ли это двух– или трехзвенная система, будут ли использоваться базы данных и т. д. Кроме того, происходит детализация требований. В моделях жизненного цикла, например объектно-ориентированной, очевидно, что детализация требований представляет собой полный перечень всех классов с описанием их сигнатур (имен, типов) атрибутов и методов, локальных и глобальных переменных, методов, которые будут взаимодействовать с соседними классами, и детализацией алгоритмов и структур данных, которые будут использоваться.

После того как детальное проектирование осуществлено, начинается третья фаза – фаза построения. Она соответствует реализации и модульному тестированию, интеграции и сборочному тестированию, тестированию. После этого осуществляется приемка и передачи продукта заказчику. Завершает стадию построения ревизия проекта, которая показывает, что продукт отвечает заявленным требованиям и способен пройти все приемочные тесты на реальном программном обеспечение заказчика.

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

Выше уже упоминалось, что при подходе Rational Unified Process можно пользоваться как моделью, связанной с итерациями, так и каскадной моделью. Последнюю можно использовать в подходе, похожем на инкрементальную модель. Предположим, что имеется программный продукт на определенной стадии развития (корпоративная информационная система), которая предполагает стабильный путь апгрейда и позволяет плавно наращивать функциональность. При доработке и развитии системы можно пользоваться подходом, напоминающим каскадную модель. Существует первоначальная стадия концептуального проектирования, которая связана с прототипированием. Затем стадия, связанная с детальным проектированием, приводит к стабилизации архитектурного проекта и основных требований, связанных с функциональностью продукта, детализированных требований. На стадии построения создается фактически новый продукт, который соответствует уже расширенной функциональности. И в результате здесь может потребоваться несколько взаимосвязанных шагов. Есть возможность осуществить передачу заказчику. Здесь объединяется основной подход, связанный с каскадным жизненным циклом, с тем подходом, который предполагает итеративную разработку. Ограничения в данном случае – предсказуемый путь развития программного обеспечения, достаточно четкая определенность функциональных требований, которые нужно реализовать для нового релиза информационной системы, и хорошее владение особенностями предметной области, технологиями проектирования и программирования той проектной командой, которая осуществляет производство программного продукта.

Другим подходом, который в большей степени основан на инкрементальном жизненном цикле, является диаграмма, где на первой стадии концептуального проектирования производится предварительный прототип, который проверяет основную функциональность продукта. На второй стадии происходит конструирование архитектуры, архитектурного проекта. Здесь как стадия разработки, так и стадия передачи может включать (и, как правило, включает) несколько итераций, поскольку речь идет о производстве ПО в соответствии с инкрементальной моделью. В этом подходе, как и в каскадной модели, должно быть хорошее представление о конечной функциональности продукта. Каскадная модель идет в один проход, и в ходе реализации уже нет возможности производить серьезные функциональные изменения. Здесь нужно четко определить, сколько будет шагов по наращиванию программного продукта, сколько релизов будет производиться, какая функциональность будет добавляться в ходе каждого релиза. Должна быть открытая архитектура и предсказуемая последовательность движения программного продукта от релиза к релизу. В таком случае можно будет аккуратно сконструировать программный продукт, последовательно улучшая его функциональность.

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

Rational Unified Process может быть адаптирована для целого ряда моделей жизненного цикла (каскадной, инкрементальной, спиральной, эволюционной). Общее между этими моделями, если абстрагироваться от конкретной модели и пытаться рассказать об RUP, – это итеративность и некоторый перечень того, что называется лучшими практиками. Часто бывает так, что необдуманный выбор определенного подмножества этих лучших практик приводит к тому, что не удается осуществить корректную разработку, даже если разработчики тешат себя иллюзиями, что они работают в рамках этой методологии. Лучше использовать эти практики в совокупности. О лучших практиках RUP можно сказать то, что это итеративная разработка. Не стоит стремиться к тому, чтобы сразу (за один проход) разработать весь проект полностью. Уточнение архитектурного плана проекта и реализация, разработка, тестирование, сборка, подготовка к передаче заказчику происходят последовательными приближениями. Продукт последовательно уточняется. В этой связи актуально второе замечание, связанное с управлением требованиями. Изменение требований происходит последовательно, на каждой итерации они просматриваются и корректируются. Очень важны требования, связанные с архитектурой, которые заключаются в том, что следует использовать архитектуру на основе компонентов. Это достаточно важное замечание для корпоративных информационных систем, так как они представляют совокупность взаимодействующих модулей, каждый из которых призван решать относительно замкнутую задачу, связанную с анализом, планированием, управлением определенной отраслью деятельности корпорации (кадры, финансы, специфические ресурсы, основные средства, другие аспекты). В этой связи компонентный подход достаточно важен, потому что дает возможность вести разработку систем таким образом, чтобы можно было посредством минимального взаимодействия компонентов обеспечить высокую взаимозаменяемость и хорошую сопровождаемость. В этом случае можно было бы вносить коррективы в отдельный компонент, и при этом в целом корпоративная система будет оставаться функциональной и достаточно эффективной.

Еще одно важное замечание, которое нужно реализовать при внедрении методологии Rational Unified Process: необходимо использовать программно-инструментальные средства, предназначенные для визуального моделирования и проектирования. Визуального, потому что Rational Unified Process существенно связана с UML, и, конечно, поэтому сложные продукты и их документация содержат огромное количество UML-диаграмм и графических примитивов (классы, прецеденты, состоянии и т. д.), чтобы управлять проектом и проектировать продукт (если мы работаем итеративно, то у нас существует кроме большого количества диаграмм еще большое количество итераций). Грамотно отслеживать, говорить на одном и том же языке важно для упрощения рабочих навыков общения с кейс-средствами, которые поддерживают проектирование на языке UML и обеспечивают сопряжение со средствами тестирования, кодогенерации, создания баз данных и т. д. Кроме того, важными требованиями являются постоянный мониторинг качества программного продукта и управление изменениями (управление потоками работ, которые происходят при реализации программных продуктов по этой методологии).

Структура методологии RUP включает роли, это важно, так как используются прецеденты и задачи, связанные со сценариями использования, и артефакты – проектные документы, которые производятся на каждой стадии (рис. 5.2). При этом используется целый ряд руководств, шаблонов и инструкций, которые указывают, каким образом следует вести проектирование и реализацию корпоративных приложений в рамках подхода Rational Unified Process. Для всех продуктов Rational существуют инструкции, руководства по проектированию, где описаны шаблоны, на основе которых нужно разрабатывать сценарии использования, анализировать и проектировать.

Под этим находятся рабочие процессы и их детализации, которые тоже описываются целым рядом диаграмм, такими как диаграмма состояния и специальные инструкции (рис. 5.3). Следует сказать о важных акцентах в идеологическом плане: это постоянный мониторинг рисков и постоянная обратная связь, учет критических рисков, обеспечение выполнений требований заказчиков, управление изменениями в ходе всего проекта, в основе проекта должна лежать архитектура, которая приводит к хорошей реализации проекта, компонентное проектирование, командная работа, управление качеством.

По сути, идеология связана с лучшими практиками, которые были перечислены ранее. Основные из них сводятся к удовлетворению принципов итеративного подхода: архитектурная центричность, компонентное проектирование, управление изменениями и качеством. Rational Unified Process можно адаптировать для различных моделей жизненного цикла, т. е. применять как каскадный подход, так и как подход, связанный с итерациями (может быть эволюционная модель жизненного цикла или инкрементальные, спиральные модели), и, кроме того, RUP может включать более или менее широкий набор артефактов, активностей и ролей и быть более или менее формализованной (рис. 5.4). Поэтому можно говорить о том, что Rational Unified Process может быть легкой или тяжелой, большой, формализованной, более применимой к корпоративным приложениям. Тем не менее говорить о том, что RUP имеет смысл применять для небольших проектов или изготовления небольших продуктов, не совсем правильно, потому как это достаточно серьезная методология, которая предусматривает существенные трудозатраты и весомый инструментарий. И, конечно, пользоваться ею для создания небольших продуктов экономически нецелесообразно: слишком много дополнительных расходов, связанных с проектной документацией, обучением сотрудников, привлечением специалистов по рискам. Для небольших проектов это неоправданно, а вот для корпоративных проектов важно, что Rational Unified Process является достаточно формальным подходом, его артефакты достаточно четко определены, процессы формальны описаны, существует большое количество руководств, хороший опыт, накопленный в разных коллективах, по производству серьезных программных продуктов. Это свидетельствует о том, что этим подходом можно пользоваться для производства и сопровождения больших корпоративных приложений. При этом можно применять достаточно широкий спектр моделей жизненного цикла.

Рис. 5.2. Структура RUP: роли, задачи, артефакты

Рис. 5.3. Структура RUP: руководства, шаблоны, инструкции

Рис. 5.4. RUP: настройка процесса

Следующим подходом, который также ориентирован на большие корпоративные системы является Microsoft Solution Framework (MSF). Этот подход вырос из моделей синхронизации и стабилизации, но в данной интерпретации это набор лучших практик, набор рекомендаций о том, каким образом следует вести разработку корпоративных информационных систем, какие роли выделяются при проектировании и реализации систем, какие этапы выделяются. То есть очень важно понимать, что это не модель жизненного цикла, это методология, технология проектирования, просто набор рекомендаций. Можно сказать, что Framework – достаточно гибкая и абстрактная система рекомендаций, на основе которой происходит построение. Она не связанна непосредственно с моделью синхронизации и стабилизации, может подразумевать другие модели, например спиральную как возможный вариант поддержки жизненного цикла.

Конечно, Microsoft Solution Framework возникла внутри Microsoft и основана на большом опыте этой компании по созданию серьезных корпоративных систем, корпоративных в смысле масштаба, распределенности, количества заказчиков. Это прежде всего операционные системы Windows, офисные приложения, которые являются корпоративными. Существуют специальные классы, которые позволяют строить офисные расширения, настраивать продукты офиса, создавать новые возможности, управление проектами посредством Microsoft Project Server, Microsoft Visual Studio, порталов. И это нашло отражение в данной методологии. То есть MSF предназначена для производства больших корпоративных приложений, но является достаточно гибким подходом и может быть адаптирована для небольших систем.

В описании модели стабилизации и синхронизации было упомянуто, что эта модель до сегодняшнего дня не нашла широкого применения вне Microsoft. На самом деле есть достаточно много серьезных организационных сложностей, связанных с использованием специфических средств тестирования (тестирование является важным атрибутом). Далее будут показаны некоторые примеры, которые получены на основе Microsoft Solution Framework не в Microsoft, но они не так уж многочисленны.

Еще одна особенность MSF сводится к тому, что это достаточно адаптивная методология. И как Rational Unified Process, она может быть как большой, так и маленькой, претендует на использование не только для корпоративных, но и для относительно маленьких проектов. Для небольших проектов она называется Agile. Это версия MSF и может быть более формальной, пригодной для больших корпоративных систем. Надо отметить, что принципы, которые заложены в MSF, могут быть использованы не только при проектировании программного обеспечения, а просто при проектировании.

MSF дополняется методологией Microsoft Operation Framework, которая нацелена на работу с существующими программными решениями. Сегодня достаточно актуальной является версия 4.0 Microsoft Solution Framework, но уже больше 10 лет существует MSF и накоплен большой опыт программных проектов (негативный и позитивный). Также, как в Rational Unified Process, существует целый ряд инструментов: визуальных, проектирования, реализации, тестирования и сопровождения, у Microsoft существует средства, которые ориентированы на MSF и поддерживают жизненный цикл программного обеспечения. Это прежде всего Visual Studio, поддерживающий репозиторий проектов на разных языках, визуальное проектирование, описание метаданных проекта, компонентное проектирование (поддержание механизма сборок), безопасное проектирование (каждая сборка идентифицируется цифровой подписью автора), производство программного обеспечения, средства, основанные на веб-сервисах. Эти средства поддерживают командную работу. Уже было сказано о программировании в малом, т. е. об искусстве программирования, и также о программировании в большом, о программной инженерии, технологии производства большого программного обеспечения. Также речь шла о программировании в массе, о командной разработке, где каждый разработчик обладает какой-то ролью, все они должны координироваться в проекте, и необходимо отслеживать соответствие версий. Весь этот сложный функционал берет на себя CASE-средство, в нашем случае Visual Studio.

Нужно сказать, что в основе проектирования как в MSF, так и RUP лежат процессы. И существуют две готовые модели, которые называются Agile и Formal. Они призваны поддерживать построение как небольших программных продуктов, так и больших.

Рассмотрим основные элементы, которые включает MSF. Прежде всего существуют базовые принципы и лучшие практики, которые во многом похожи, но имеют свои особенности. Внутри формируются модели, поддерживающие разработку в команде. Технологии разработки корпоративных информационных систем неосуществимы без грамотной координации и постановки процессов. Microsoft обладает огромным опытом сопровождения программных проектов (существуют средства онлайного сопровождения, большое количество центров и т. д.). У Microsoft также самая большая база знаний по взаимодействию с пользователями. Естественно, существует целый ряд документов, которые описывают дисциплины управления проектами, поскольку в рамках MSF существуют ключевые понятия проекта, менеджера проекта, менеджера продуктов, процедуры управления рисками, разрешения рисков (для этого используется матрица противоречий). Кроме того, существуют наборы практических рекомендаций для той или иной модели, которая применяется для решения задач, связанных с проектированием информационных систем. Если говорить о моделях Agile или Formal, здесь своя специфика, но каждая из них ориентирована на командную разработку, четкое разделение ролей и тесное взаимодействие. Очень важно, что в отличие от RUP и целого ряда других методологий MSF предполагает относительное равенство прав для ролей в проекте. Голос рядового разработчика может быть услышан наряду с голосом менеджера проекта. Учет мнения каждого участника проекта принимается во внимание. Организация потоков работ и активностей, которые составляют эти потоки, похожа на ту, что обсуждалась при разговоре о RUP. Своя специфика связана с отчетами о выполнении рабочих заданий, которые составляют активности. Эти задания включают целый ряд состояний и достаточно обширные отчеты, которые объединяют большое количество различных полей, чтобы сформировать представление о том, в какой степени задание завершено. Более формальная реализация Microsoft Solution Framework Formal включает большее число артефактов, расширенный набор документации и ролей. Эта модель в большой степени подходит для разработки корпоративных приложений.

На рис. 5.5 представлено, каким образом связаны элементы в Microsoft Solution Framework, и те принципы, которые лежат в основе этого подхода. Основными моделями, используемыми в этом подходе, являются проектные модели, а ключевым принципом методологии – управление рисками. При этом определение и мониторинг ключевых факторов риска выступают важной практической особенностью MSF. Существуют рекомендации построения базы данных, которые отслеживают результаты оценки рисков. Кроме того, важен учет знаний, накапливающихся во время выполнения проектов. Обзоры по завершении каждого этапа процессов ложатся в базу данных, которая учитывается при выполнении последующих проектов.

Рис. 5.5. Связь между элементами MSF

Перечислим основные принципы, которые лежат в основе Microsoft Solution Framework. Здесь есть реализации общих принципов, которые связаны с командной работой, получением и анализом знаний, оценкой рисков, определенной гибкостью. Это партнерство с клиентом, открытая коммуникация. Коммуникация очень важна в ходе проекта: слабая коммуникация приводит к тому, что информация интерпретируется неверно. В проекте необходимо взаимодействовать, чтобы вместе понять концептуальные основы, видение, осознание задачи программного продукта. Также важно обеспечение качества, гибкости и адаптации к изменениям (требований, ограничение стоимости и т. д.), создание ценностей или постоянная ориентация на результат. В MSF существует ключевое понятие deliverable, т. е. некая ценность, которая может быть измерена и должна завершать каждую активность проекта. В модели команды Microsoft Solution Framework есть целый ряд основных ролей или частей команды, которые могут перекрываться. В зависимости от модели области знания могут перекрываться с точки зрения участия в проекте конкретных людей, например роль менеджера проекта может совпадать с ролью менеджера продукта. Но в целом некоторые из совмещений являются возможными, а некоторые – нежелательными. На этот счет есть рекомендация в форме матрицы совместимости ролей.

Как видно из рис. 5.6, в модели команды Microsoft Solution Framework можно выделить несколько областей знаний. Это управление программой, управление продуктом, область, связанная с пользовательским опытом, разработка или реализация, тестирование (тестирование должно происходить в сжатые сроки, достаточно часто и обеспечивать качество каждого релиза, поэтому предполагается использование программных средств и высококвалифицированных специалистов в этой области), опыт, который связан с изготовлением релизов и эксплуатацией, архитектурное проектирование.

Рис. 5.6. Модель команды MSF

Основные принципы организации проектной команды в рамках подхода MSF состоят в том, что прежде всего команда является равноправной в определенном смысле, т. е. каждая роль имеет достаточно жестко ограниченную область ответственности и в рамках этой области имеет определенные полномочия. Но если речь идет о качестве продукта в целом, то поощряется открытое взаимодействие всей проектной команды, и о качестве проекта может высказываться каждый, команда несет ответственность за результат. Поощряется открытая коммуникация, для каждой роли существуют четкие метрики контроля качества с учетом той области, которую она занимает в проекте. По сути, продвижение по проекту представляет собой учет и сбалансированный анализ вклада каждого участника в результирующее решение. Для того чтобы обеспечить аккуратный, взвешенный жизненный цикл реализации, предотвратить и скомпенсировать негативные последствия возникающих ошибок или несоответствий, необходимо учитывать все аспекты проектирования и реализации. Поэтому каждый член команды имеет равное право голоса, особенно в той области, за которую отвечает. Очень важным принципом является адаптивность, т. е. Microsoft Solution Framework не является жестко фиксированной и предполагает адаптацию команды к проекту по количеству людей, функциональным ролям, ограничениям, сферам взаимодействия и артефактам. Таким образом, проектная команда оказывается масштабируемой и может подразделяться на более мелкие проектные команды, динамически изменяя размеры. Это позволяет наладить эффективную коммуникацию при работе над программными продуктами.

Центральным понятием в схеме MSF является роль. Некоторые роли уже были описаны, когда речь шла о модели процессов. Каждая из ролей выполняет те или иные активности, которые организуются в последовательности действий, – рабочие потоки. При этом активность включает несколько задач: небольшие фрагменты, которые могут быть выполнены за определенные сроки и которые предполагают четко измеримые результаты на выходе. Каждая из активностей в итоге может вести к созданию продукта и требовать на вход частичный продукт для того, чтобы на выходе привести к созданию нового частичного продукта. Это похоже на объектно-ориентированный подход, когда осуществляется интеграция продукта, т. е. из небольших файлов собираются частичные крупные продукты и агрегируются в полномасштабный продукт. В ходе выполнения активностей создается большое количество документации. Она представляется в самых разных видах: таблицы, графики, диаграммы, инструкции в текстовом виде. Основные области знаний, исходя из которых создаются проектные роли, сводятся к архитектуре продукта, управлению продуктом и активностям, связанным с разработкой, тестированием, общением с пользователем, эксплуатацией.

На рис. 5.7 представлена матрица совместимости групп ролей, которая во многом отражает возможности масштабирования подхода Microsoft Solution Framework по программным продуктам с учетом их размера. Ряд ролей можно совмещать. Управление продуктом и управление проектом возможно совмещать, но не рекомендуется. Таким образом, в группе, которая ведет проект по подходу MSF, может быть небольшое количество людей, при этом ряд ролей может совмещаться. С другой стороны, если это крупный проект, то роли разделяются. Так же, как и RUP, подход MSF имеет в своей основе процессы, и их фазы достаточно близки. Если в RUP говорилось о стадии создания концепции, то здесь – о создании видения, абстрактного представления о том, каким должен быть продукт, какого рода задачу он должен решать, при этом процессная модель основана на итеративном уточнении функционала проекта с построением нескольких релизов, которые являются полномасштабными с точки зрения функционала продукта, артефактов (на каждом этапе, релизе мы продуцируем практически готовый продукт с точки зрения всех его артефактов, функциональность не является завершенной).

Рис. 5.7. Матрица совместимости ролей в подходе MSF

Итак, видение завершается определением границ, т. е. концептуальных проектных ограничений, которые описывают базовую функциональность программного продукта: какие задачи он должен решать и на какие он не должен распространяться, какие будут решены тактически в ходе дальнейших релизов, какие стоит стратегически оставить за рамками данного проекта в целом. После этого происходит планирование проекта и разработка. Между стадиями осуществляется контроль достижения целей по истечении каждой вехи и сопоставление документально полученных результатов с целями и требованиями. Как только завершено планирование, начинается разработка. И затем существует специфическая стадия для каждого релиза, которая отсутствует в RUP, – это стабилизация (рис. 5.8), так как Microsoft Solution Framework основана на модели синхронизации и стабилизации, т. е. существенной составляющей является стабилизация каждого релиза, и для достижения его устойчивой и надежной работы необходимо обеспечивать качество релиза согласно проектным метрикам.

Рис. 5.8. Процессная модель MSF

Только после стабилизации возможны передача заказчику и стадия развертывания. Стадия стабилизации при неудовлетворительной дисциплине проекта или неполном владении инструментарием может приводить к большим потерям времени и людских ресурсов. За счет наличия этой стадии подход Microsoft Solution Framework достаточно сложен, и вне Microsoft редко удается реализовать удовлетворительные решения для больших информационных систем. Тем не менее общая схема во многом близка к RUP и основана на процессах, производстве последовательных релизов, и основные стадии во многом совпадают.

Особенность MSF заключается прежде всего в том, что проект делится на этапы, стадии, восстанавливаются вехи и четко определяются результаты по каждой контрольной точке. Используются проектные метрики, которые приводят к пониманию, достигнут ли результат. Центральным является понятие итерации, т. е. последовательного уточнения функциональности проектного продукта на каждом витке спирали. Кроме того, существует интеграция взаимодействий между построением и развертыванием решений, что во многом считается сходством с объектно-ориентированной моделью, и возможно использование проверенных практических приемов, которые отшлифованы большим количеством удачных проектов. Это относительно небольшие команды, которые объединяются в более крупные коллективы и позволяют масштабировать взаимодействия при производстве программного обеспечения корпоративного типа. Каждый аспект проекта есть функция, над которой работает небольшая команда. Команда достаточно сплоченная, и все ее участники в совокупности, имея равные права, принимают участие в совместном проектировании. Матрица управления противоречиями определяет проектный треугольник – людские, финансовые, временные ресурсы, функциональные возможности, адаптируется исходя из рисков и текущего состояния проекта. Следует отметить, что вне Microsoft этот подход применяется достаточно редко.

Глава 6 Программные архитектуры корпоративных систем

Ранее были рассмотрены основные понятия корпорации и корпоративной системы, затем – основные подходы к разработке этих систем с точки зрения их жизненного цикла на уровне моделей (более формальный, общий подход), после этого – основные методологии проектирования. Напомним, это тоже не вполне строгий подход с математической точки зрения, по сути, это набор правил хорошего тона, полезных советов, рекомендаций для реализации и сопровождения информационных систем. Поэтому имеет смысл ограничиться констатацией тех подходов, которые приемлемы для корпоративных приложений. Это MSF, RUP и те, которые приемлемы лишь отчасти, – Scrum, Agile. Знать ЖЦ нужно, чтобы иметь представление о создании и функционировании систем. Направление методологий и моделей жизненного цикла – это во многом ортогональные направления. Например, в RUP можно использовать спиральную или каскадную модель, а в MSF – эволюционные или инкрементальные подходы.

Ранее мы рассматривали разработку КИС с концептуальной точки зрения, теперь начнем более предметный разговор и спустимся на технологический уровень.

Первое, с чего следует начать описание, – это программная архитектура. Во время эскизного или архитектурного проектирования вместе с базовыми функциональными требованиями разрабатывается общая архитектура системы: количество компонентов и их взаимодействие. На этом этапе стоит определиться с технологией – будет ли приложение файл-серверным, клиент-серверным, двух– или трехзвенным и каким образом будут эти звенья взаимодействовать, будет ли оно иметь на нижнем уровне БД и насколько сложными будут структуры данных (рис. 6.1).

Следующее, о чем следует рассказать перед технологическими средствами и приемами, которые используются в Microsoft и его инструментальных средствах проектирования, – это CASE-средства, которые поддерживают все этапы разработки КИС. Это тяжелые и дорогие инструменты, поэтому стоит говорить об их масштабном применении, прежде всего в КИС.

Рис. 6.1. Обработка данных СуБД: локальный компьютер

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

Прежде всего речь пойдет о сетевых архитектурах, так как корпорация – распределенная структура. Будут рассмотрены устройство сетевых архитектур и принципы их функционирования. Второе ограничение – архитектуры, основанные на БД. В определении программной инженерии по Липаеву было сказано, что в КИС, как правило, используются БД. Корпоративные БД – это отдельная большая тема.

Корпоративные информационные системы можно назвать открытыми лишь в определенном смысле этого слова. Корпорации не хотят открывать свои конфиденциальные данные внешним заказчикам. Корпорация не может доверить оценку рисков внешнему разработчику, и разработчик, и заказчик должны быть внутри системы. Но принципы объединения ИС должны базироваться на открытых стандартах. Далее речь пойдет о них.

БД в корпорациях содержат тера– или даже петабайты данных. Уже в 2005–2006 гг. объемы данных в корпорации Intel превысили 3 петабайта. Объемы данных растут экспоненциально, приблизительно в 2 раза за пять лет. Таким образом, к настоящему времени этот показатель удвоился. Управление такими БД – масштабная проблема, но останавливаться на ней мы сейчас не будем.

Говоря о корпоративных системах, их стоит разделять на две части – клиентскую и серверную. Клиент запрашивает информацию, сервер ее обрабатывает и предоставляет. Другое дело, как именно они взаимодействуют. Простой случай – файл – сервер. Более сложный подход – клиент-серверная архитектура. Отдельно выделяется сервер БД – в ряде случаев это оправданно, причем серверы нас интересуют с логической, а не аппаратной стороны.

Как происходит разделение функций между клиентом и сервером? Здесь, как в любой сложной промышленной системе, речь идет о специализации и кооперировании. Мы выделяем функциональные роли все более и более тонкие, точные. Детализируя понятие «сервер», сначала происходит классификация клиент и сервер. Далее происходит уточнение: есть серверы баз данных, серверы шифрования, телекоммуникационные серверы. На этой основе происходит классификация системных архитектур.

Существуют разные организации клиент-серверного взаимодействия. Далее подробно будет рассмотрено, как осуществляется обработка информации в БД, какой существует CASE-инструментарий для работы с БД, что такое реинжиниринг БД и SQL-запросы. Потом будут описаны более сложные структуры на основе клиент-серверного подхода.

Рассмотрим двух– и трехуровневый клиент-сервер, где сервер приложений явно выделяется как отдельный операционный слой. Чем большая производительность необходима, тем большая нужна специализация. По сути, речь идет о программном обеспечении. То, как операционный слой распределяется по аппаратному обеспечению, зависит от топологии сети, от задач, администраторов БД и сетевых администраторов корпорации, здесь возможен достаточно широкий спектр решений. Далее будет рассмотрено, какие расширения серверной части программной реализации имеются в современных сетевых архитектурах, какие существуют распределенные БД различных уровней.

Под корпорацией в широком смысле мы понимаем не только производственную, но и разветвленную структуру, например госструктуру, которая также решает какие-то общие задачи. Можно говорить о федеративных БД, о БД масштаба государства, об интегрированных БД, которые объединяют различные системы и подходы к организации данных.

Еще один интересный пример крупномасштабных систем – это GRID-системы. Он не очень часто используется в корпорациях. Это системы, в которых взаимодействуют большое количество необязательно мощных компьютеров, но обеспечивается масштабирование и в короткие сроки обрабатываются терабайты данных.

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

Появлению семейств клиент-серверной архитектуры мы обязаны последовательной реализации концепции открытых систем. На основе открытых стандартных протоколов взаимодействия можно, как на заводе, собирать комплексные системы высокой сложности, причем дешево осуществлять сборку этих систем, даже если компоненты реализуются в разных странах. Один из подходов к такому проектированию – это компонентный подход, который реализован Microsoft. Сборка осуществляется из компонентов с открытым интерфейсом. Подобный подход предлагает Sun в Enterprise JavaBeans.

Корпорация – организация с большим количеством информационных систем, возможно относящихся к разным поколениям, например, во многих банках работают мейнфреймы и существует множество систем, написанных на языке Cobol. Идея открытых систем в том, чтобы объединить информационные системы. Телекоммуникационные системы существовали и ранее, но распространение, миниатюризация и удешевление ЭВМ привели к изменению ситуации. В последнее время появились не только ЛВС, но и Интернет.

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

Сейчас сотрудникам корпораций необходим круглосуточный доступ к данным из любой точки планеты. Нужно обеспечить независимость от программно-аппаратного обеспечения и серьезную стандартизацию, возможно выше уровня операционной системы. Таким образом возникли открытые системы. Они обладают рядом важных свойств, которые позволяют наращивать комплексы без потери работоспособности. Во-первых, это мобильность, которая обеспечивает легкость миграции приложений в аппаратно-программной среде. Когда мы заказываем билет через Интернет, мы не отдаем себе отчет в том, с каким именно сервером мы работаем. Это возможно, так как разработчики обеспечивают соответствие стандартам. Еще одно свойство – интероперабельность обеспечивает легкость построения новых приложений на основе готовых компонентов со стандартными интерфейсами. Приложения по известным описаниям компонентов могут строиться независимо друг от друга и с учетом взаимодействия по стандартным протоколам взаимодействовать.

Кроме того, имеется возможность обеспечить постепенное наращивание функциональности приложений, можно улучшать компоненты независимо. Это обеспечивает эволюционный путь развития системы и позволяет плавно вести сопровождение.

Основной принцип при проектировании корпоративных систем, если рассматривать разработку в интернет-аспекте, состоит в разделении ресурсов и функций между компьютерами, предназначенными для обслуживания и запроса информации, между клиентами и серверами. При этом развитие идеи ЛВС приводит к выделению функциональных компонентов. Выделяются компьютеры – рабочие станции для обеспечения прикладного интерфейса (пример – веб-браузер как тонкий клиент). Можно обеспечить легкий и недорогой набор функций, который позволяет получить доступ к корпоративным данным. С другой стороны, есть сервер с существенными объемами памяти и вычислительной мощностью. Часто это может быть кластер из нескольких машин. Сервер предоставляет средства обслуживания пользователя, он получает одно логическое имя на кластер, и мы не знаем, какой именно компьютер обрабатывает наш запрос, нам не важно, какой компьютер нам отвечает.

Дальнейшая спецификация функций приводит к выделению серверов телекоммуникационных, вычислительных и дисковых (файл-серверов), кэш-серверов. Также есть серверы БД, обрабатывающие множество запросов. Для этого выделяется кластер для обработки SQL-запросов. Здесь четко разделены роли сервера и клиента. Сервер предоставляет ресурсы клиентам, клиентами могут выступать и другие серверы.

Основные принципы архитектуры клиент – сервер: выделенный программный интерфейс, четко определенные протоколы взаимодействия (рис. 6.2). В физически разных местах присутствуют независимо взаимодействующие с одним сервером, не знающие друг о друге клиенты. При этом клиент никак не может определить, сколько еще клиентов взаимодействуют с сервером, протоколы, функции, количество параметров четко определены в описаниях компонентов. На этой основе мы можем независимо постепенно наращивать функциональность клиента и сервера.

Рис. 6.2. Обработка данных СуБД: клиент – сервер

В больших корпоративных сетях есть относительно старые части, которые используют свои средства кодировки шифрования и передачи. Одним из стандартных решений является применение Remote Procedure Call (RPC). Обращение к серверу сводится к вызову функции. Все детали реализации остаются для разработчика сервера неважными, поэтому приложения на основе RPC легко переносятся в среды с открытыми интерфейсами.

Далее речь пойдет о базах данных корпоративных систем, их особенностях и разновидностях. Корпоративные базы данных бывают достаточно разнородными. БД можно назвать приборной доской бизнеса – по ней видны бизнес-успехи, текучесть кадров, динамика движения средств.

Базы данных – неотъемлемая часть информационных систем. В корпорациях уже имеются петабайты данных, и эти объемы растут, удваиваясь каждые пять лет. В корпорациях необходимо распределенное управление БД. В основе подобных технологий лежат распределенные СУБД, основанные на концепции открытых систем. Стандарты взаимодействия в таких системах фиксированы, и имеется возможность масштабируемости и плавного наращивания функциональности. В основе архитектур, которые поддерживают корпоративные информационные системы с базами данных, лежит разделение систем по функциям на клиентскую и серверную части. В развитие этой идеи выделяются специализированные серверы для телекоммуникаций, баз данных, осуществления прикладной логики, шифрования. В связи с такой специализацией традиционная двухзвенная архитектура преобразуется в трехзвенную, в которой выделяются три уровня – презентационная логика, бизнес-логика и логика доступа к ресурсам. В зависимости от балансировки этих трех уровней логики осуществляется дальнейшая конкретизация трехзвенной архитектуры клиент – сервер до моделей с толстым клиентом, тонким клиентом и явным выделением сервера приложений.

Речь идет о больших и сложных БД, поэтому стоит рассмотреть особенности применения архитектуры клиент – сервер к БД. Важно, что явно выделяется приложение клиент – frontend и серверное приложение – backend. Для пользователя, работающего через веб-браузер, все происходит незаметно. Один из примеров графического интерфейса – это банкомат. Ограничения целостности достигаются тем, что БД находятся на сервере. В случае заказа билетов через терминал речь идет о возможности покупки билета на одно и то же место. Здесь есть достаточно важный ряд вопросов и ограничений. Эти ограничения стоит хранить как можно ближе к серверу, производящему общение с базой данных, при этом запросы будут обрабатываться существенно быстрее.

Преимущества лучших черт предыдущих архитектур обеспечивают централизованное администрирование, в том числе и баз данных, безопасность, надежность и отказоустойчивость и файл-серверов, обеспечивающих достаточно низкую стоимость реализации и распределение обработки данных с использованием клиентских компьютеров. Современные клиентские компьютеры, как правило, достаточно мощные. Вспомним, что Windows Vista налагает серьезные требования на вычислительную мощность и объемы памяти современных компьютеров (1Гб RAM). Ряд ресурсов клиента можно использовать.

Рассмотрим, как осуществляется обработка данных в различных архитектурах. Самый простой, исторически первый подход – персональный компьютер. Здесь все происходит локализованно и достаточно просто. Система управления БД и приложение клиент находятся на одном компьютере. В корпоративных системах такое невозможно, поскольку, во-первых, объемы данных исчисляются петабайтами, во-вторых, консолидированные отчеты требуют сбора данных из большего количества компаний из разных стран. Локальные приложения для корпоративных приложений неприменимы.

Самое простое, что можно применить, – это файл-сервер. Есть выделенный компьютер-клиент и другой выделенный компьютер (файл-сервер), возможно, в другом сегменте локальной сети. Файл-сервер хранит исключительно данные. Например, на нем могут храниться документы для коллективной работы с ними. У клиента есть приложение СУБД, текстовый редактор или редактор таблиц, с помощью которых он взаимодействует с этими данными. При этом клиентов может быть довольно много. Пересылка данных осуществляется по каналам локальной сети. Все остальное, кроме данных, нужно устанавливать на клиентские машины заново. Бизнес-логика, СУБД находятся у клиента. Это невыгодно для больших нагрузок и интенсивностей SQL-запросов. Возможно долгое ожидание сервера, если вычисления осуществляются на клиенте. Магистраль тоже может быть перегружена. Для разгрузки магистрали и нагрузки сервера используется клиент-серверная архитектура. Таким образом мы избавляемся от долгой и дорогостоящей настройки СУБД на каждом клиенте. СУБД находится на сервере и взаимодействует с данными на этом или другом сервере. Логически обращение происходит всегда к одному серверу. На клиенте находится только приложение (логика). Таким образом, сервер становится существенным звеном. Магистраль разгружается. Клиент становится более специализированным и дешевым. Обработка данных становится эффективнее, и количество пользователей можно увеличить. При этом в явном виде можно выделить сервер базы данных как особый уровень (рис. 6.3).

Рис. 6.3. Обработка данных СуБД: файл-сервер

Возможности, характерные для данной архитектуры таковы: во-первых, явно присутствуют клиентская и серверная части; во-вторых, сервер БД отвечает за хранение данных и предоставление доступа к БД. Общая база данных хранится на сервере и доступна всем пользователям ЛВС. Таким образом, клиент получает согласованные данные, доступные всем пользователям, хранение удешевляется, а доступ к БД становится распределенным. Отдельные фрагменты БД могут храниться на разных компьютерах в одном узле ЛВС.

Запрос на доступ к данным инициируется клиентской частью. Все клиент-серверное взаимодействие строится на стандартах. В данном случае используется язык SQL – язык структурных запросов к БД со стандартами от 1992 г. и более поздний стандарт ANSI. Они позволяют инкрементально наращивать функциональность и обеспечить взаимодействие БД, созданных разными производителями (Microsoft, Oracle). Под SQL-сервером понимается логическое имя, возможно группа компьютеров или кластер со стандартным интерфейсом в виде языка SQL. При этом в идеале любой SQL-клиент совместим с любым SQL-сервером. Если вернуться к схеме взаимодействия клиента и сервера БД, то можно видеть, что на сервер приходится большая нагрузка. В связи с этим SQL-сервер является не только центральным звеном системы БД, но и наиболее ответственным и важным звеном, узким местом всей системы, несмотря на то, что клиент сам по себе достаточно мощный. Если клиент может взять на себя часть функций прикладной логики, то он должен ее на себя взять. В этом и состоит перспектива систем управления БД – гибкая балансировка нагрузки между клиентом и сервером.

Исторически первым методом организации клиент-серверного взаимодействия была RPC. Эта архитектура значима и сегодня. На довольно низком уровне можно обеспечить распределение нагрузки. Некоторые компоненты могут располагаться на клиенте. Если ЛВС вычислительно неоднородна, то взаимодействие на уровне процедурных сервисов позволяет скрыть неоднородность сети. При этом снижается значимость аппаратной совместимости. Часть парка аппаратного обеспечения может быть заменена без критического влияния на важные системы. Принцип открытых систем сглаживает подобные неровности инкапсуляцией функциональности на прикладном уровне процедур приложений. Если говорить о SQL-сервере, то функциональное разделение производится следующим образом. СУБД работает на стороне сервера, на стороне клиента организуется лишь инициирование запросов к SQL-серверу. Вся работа по формированию запросов, обработке данных, организации транзакционного многопользовательского взаимодействия осуществляется на стороне сервера. Ряд запросов носит типовой характер. Результат этих запросов стоит кешировать в ОЗУ на сервере. Таким образом возникает возможность хранения кэша на выделенном сервере. Если клиент использует одни и те же запросы, стоит кешировать БД на локальной машине. Так можно моделировать работу сервера на клиенте и осуществлять ряд операций по обработке данных локально. В отличие от традиционной клиент-серверной архитектуры мы получаем распараллеливание и балансировку прикладных функций между клиентом и сервером. Прежде чем обсудить трехзвенную архитектуру, поговорим об особенности архитектуры сервера баз данных.

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

Рассмотрим основы многопроцессорной и многопоточной архитектуры. При каждом сеансе связи пользователя с сервером осуществляется создание нового экземпляра приложения (Oracle). При этом преимуществом является масштабируемость, что требует большого объема памяти. Многопоточный подход (Microsoft, Sybase) заключается в том, что на один экземпляр приложения запускается несколько потоков, это требует меньше ресурсов. При многопроцессорном подходе ОС ориентируется на разделение времени между экземплярами приложений, при каждом соединении создается новый процесс.

Вернемся к вопросу о балансировке нагрузки между клиентом и сервером. Речь идет о выделении третьего уровня прикладной логики. Верхний уровень, связанный с логикой работы приложения, расщепляется на два. Трехуровневая архитектура включает в себя презентационную логику (PL), бизнес-логику (BL) и логику доступа к ресурсам (AL). BL можно размещать как на сервере, так и на клиенте, а также выделить на отдельный сервер, тогда появляется понятие сервера приложений. Тонкий клиент – легкий клиент с презентационной логикой, например браузер. Толстый клиент (remote data access, RDA) объединяет бизнес-логику и презентационную логику. Сервер приложений можно выделить в отдельный программный уровень.

Под толстым клиентом (RDA) понимается объединение на клиентской части логики, связанной с презентацией, и бизнес-логики. Только логика доступа к ресурсам оставлена на сервере (рис. 6.4).

Рис. 6.4. Модель трехуровневой архитектуры клиент – сервер: толстый клиент

Другой вариант взаимодействия в трехуровневой модели – тонкий клиент (как правило это веб-браузер) (рис. 6.5). У клиента остается только презентационная логика, а бизнес-логика и логика доступа к ресурсам остаются на сервере. Дальнейшая балансировка загрузки дает возможность выделить еще один логический слой – сервер приложений, который не обязательно является отдельным физическим сервером.

Рис. 6.5. Модель трехуровневой архитектуры клиент – сервер: тонкий клиент

КИС активно взаимодействуют с более крупными системами, которые представляют собой конгломераты информационных систем федеративного интегрированного уровня. Преимущественно такое взаимодействие осуществляется в режиме частичного предоставления данных или организации специфического доступа к ним в форме мультибаз данных. Интегрированные федеративные системы являются глобальными системами, объединяющими различные модели данных, как реляционные, так и иерархические, сетевые в ряде случаев и объектные, и конгломераты различных СУБД (рис. 6.6).

Рис. 6.6. Модель трехуровневой архитектуры клиент – сервер: сервер приложений

Рассмотрим особенности тонкого и толстого клиентов. Тонкий клиент широко распространен в корпоративных системах. Клиент становится легче, а все, что связано с бизнес-логикой, выносится на сервер. Клиент требует только настройки соединения, и обновление его становится проще. Использование тонких клиентов делает возможным применение бездисковых станций. Администраторам становится легче обеспечивать безопасность. При необходимости миграции в новую среду можно организовать ее удаленно. Это дает экономию на десятках тысяч клиентов.

Толстые клиенты преимущественно распространены в системах, не требующих частой коррекции. Если часть бизнес-логики переносится на логический сервер, выделяется уровень приложений (Application Layer, AL). При этом на сервере БД работает только та часть бизнес-логики, которую можно вынести в бизнес-правила уровня предприятия или целой группы логически связанных прикладных программ. Тонкие клиенты работают на компьютерах пользователей, сервер БД освобождается от бизнес-логики и работает только на передачу данных серверу приложений и пользователям. Реализация сервера приложений может быть как в виде SQL-сервера, так и в виде персональной СУБД.

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

При использовании тонкого клиента вся бизнес-логика, которая была сосредоточена на каждом из сотен тысяч клиентов, переносится на сервер и централизованно управляется там. Она взаимодействует с данными и SQL-серверами. Клиент снабжается только пользовательским интерфейсом. Администрирование и централизованная миграция производятся на сервере, поэтому изменения с точки зрения сроков и стоимости происходят более эффективно. Бизнес-логика может быть расположена на одном и том же сервере с БД, а может быть перенесена на один или несколько серверов. Коррективы в таких системах можно вносить как на нижнем уровне, так и на более высоком. Например, в семействе Oracle Applications на нижнем уровне расположен сервер базы данных Oracle Server, а на более высоком уровне существует Application Server, на котором и располагаются все компоненты, выполняющие прикладные задачи. Это ERP-системы Oracle Applications или Oracle Business Suit, которые осуществляют прикладную логику: учет, планирование и управление основными видами корпоративных ресурсов.

Для производства корпоративных приложений нужно эффективно пользоваться специализированными инструментальными средствами, которые этот цикл поддерживают. Речь идет о средствах автоматизированного проектирования корпоративных приложений, или CASE-средствах. При этом если говорить о базах данных, необходимы специфические CASE-средства. В чем же заключаются эти особенности применительно к распределенным системам клиент-серверного типа? Эти средства являются достаточно универсальными, так как обеспечивают возможность соединения с различными серверами БД и позволяют разрабатывать графические интерфейсы (формы ввода данных, отчеты), чтобы пользователи могли взаимодействовать с данными в этих графических интерфейсах. Речь идет о том, что взаимодействие с базой данных может осуществлять не только программист, но и опытный пользователь, системный, бизнес-аналитик. Более того, если правильно построить цикл разработки корпоративной системы, можно обеспечить возможность взаимодействия этого бизнес-аналитика с существующей системой и развитие этой системы бизнес– аналитиком. Он сможет строить в терминах бизнес-логики, почти естественных языковых терминах, необходимые запросы и отчеты. При этом в почти автоматическом режиме происходит соединение с сервером БД, и графический интерфейс во многом набирается из тех примитивов, которые есть в распоряжении такого продвинутого пользователя.

Особенность систем проектирования взаимодействия корпоративных систем с базами данных – это в первую очередь объектная ориентированность. Речь идет о наборе компонентов для взаимодействия с серверами, основанных на технологиях ODBC (Object Database Connectivity), соединении с базами данных на основе объектных технологий либо более старой технологии OLE (Object Linking and Embedding). Кроме того, это визуализация, основанная на объектных библиотеках, средство командной разработки (например, Visual Studio Team System/Team Suit), а также языки четвертого поколения, которые поддерживают возможность написания программ в терминах скрипт-языков или во многом визуальной разработки.

К CASE-поддержке систем с базами данных можно отнести такие средства, как:

• Oracle Developer;

• Borland Delphi;

• MS Visual Studio (MSVS);

• Sybase PowerBuilder.

В Oracle Developer есть расширения для создания веб-приложений Oracle Web Developer, кроме того, также как и в MSVS, в нем может быть использовано подключение к другим базам данных на основе открытых интерфейсов (например, ODBC). Эти средства являются конвейерами для интеграции с различными SQL-серверами.

Средства, поддерживающие разработку персональных СУБД, с которых начинались небольшие системы, – это были, по сути, CASE-средства и серверы базы данных в миниатюре. Они также поддерживают SQL-запросы и разработку бизнес-логики, независимую работу клиентского приложения и в ряде случаев имеют специализированные форматы хранения данных, основанные на специфических СУБД (например, в семействе приложений Lotus на основе Lotus Domino сервера и персональной СУБД Lotus Approach речь может идти о нереляционной БД, многозначной структуре данных, когда речь идет о неатомарных атрибутах в БД). Рассмотрим основы того, из чего выросли современные средства. Атрибутами настольных систем были легкий удобный графический интерфейс, интеграция с пакетами офисных приложений (MS Office в том числе), визуальные средства, которые позволяют вести быстрое построение приложений и отчетов. В MS Access есть набор визардов для экспресс-построения отчетов, и среда реализации основана на объектном подходе (ODBC, COM, OLE). В MS Access можно встроить макросы на Visual Basic, который во многом является объектным. Эти средства хоть и в нестандартном виде используют язык SQL, с помощью которого осуществляется запрос к локальной БД.

Усовершенствование этих средств и выделение явного уровня клиента и сервера привели к появлению определенных особенностей в двух– и трехуровневой архитектурах клиент – сервер.

Если говорить о двухуровневой архитектуре клиент – сервер, можно выделить следующие особенности применительно к сетевым средам Интернет и интранет. Интернет важен для корпоративных сетей. В данном случае мы разделяем уровни веб-браузера и вебсервера. Речь идет о взаимодействии по протоколу HTTP. Сервер предоставляет клиенту HTML-страницу, а браузер отображает страницу, обрабатывая HTML-теги (рис. 6.7).

Рис. 6.7. Двухуровневая архитектура клиент – сервер в сетях Интернет/интранет

При переходе к трехуровневой системе возникает промежуточный слой, связанный с JSP (Java Server Pages) или ASP (Active Server Pages). Промежуточный слой в виде веб-сервера, сервер БД, осуществляющий SQL-взаимодействие с БД, и клиент в виде веб-браузера.

Основные протоколы – HTTP, или HTTPS. Преимуществами являются снижение трафика, большая взаимозаменяемость компонентов за счет стандартных интерфейсов и протоколов, а также увеличение безопасности. Недостаток связан с тем, что HTTP – это протокол без состояния (stateless). В связи с этим сложно организовать транзакционную обработку БД, что крайне важно для систем корпоративного размера, поскольку многопользовательская работа подразумевает транзакционность и изоляцию пользователя. Осуществляется псевдопараллельная работа со сложным управлением транзакциями.

При трехуровневой архитектуре обобщенное взаимодействие между клиентом и сервером выглядит следующим образом (рис. 6.8). Клиент в виде веб-браузера отсылает серверу запрос на доставку веб-страниц, данных в рамках протокола HTTP. Выполняется передача данных в определенном формате. После того как веб-сервер получает запрос на отображение веб-страницы от сервера БД, он передает после перекодирования HTML-страницы клиенту. Вебсервер – это промежуточное звено между клиентом и БД. Он получает от клиента в сыром виде запрос на получение информации и обращается к серверу БД по средствам запросов. Существуют программы расширения серверной части, которая получает от вебсервера запрос на получение данных и общается с сервером БД. Она принимает запрос, переформулирует его на языке SQL и передает его серверу БД. Сервер БД специализируется исключительно на выполнении SQL-запросов. Он выполняет запрос в форме определенного количества записей из БД программе-расширению. После чего происходит передача информации веб-серверу с преобразованием в формат веб-браузера. Затем происходит передача клиенту страницы с результатом. Таким образом, происходит двухуровневое взаимодействие.

В трехзвенном клиент-сервере взаимодействие происходит более сложным образом. Между веб-сервером и источником данных появляется еще один уровень, реализующий прикладную логику на основе программных расширений. Информация в формате HTML от веб-браузера преобразуется к виду, который может быть транслирован в SQL-запрос, который выполняет SQL-сервер. После этого происходит обратное преобразование в HTML и передача его клиенту. Используются программы-расширения CGI-скрипты, API. Основная цель для трехзвенной клиент-серверной архитектуры – за счет взаимодействия по стандартным протоколам осуществить специализацию деятельности компонентов. И за счет этой специализации ускоряется обработка запросов. Отдельно выделяется задача поддержания соединения с БД для минимизации сетевого трафика. Кроме того, для обеспечения масштабируемости необходимо поддерживать резерв в соединении с БД для того, чтобы в пиковый период увеличить нагрузку. Стандартизация компонентов дает возможность инкрементально наращивать функциональность отдельных систем.

Рис. 6.8. Трехуровневая архитектура клиент – сервер в сетях Интернет/интранет

Кроме традиционных корпоративных систем стоит рассмотреть системы, не являющиеся корпоративными с точки зрения решаемых бизнес-задач. Речь идет о системах, которые поддерживают на уровне государств функционирование достаточно важных информационных служб, например электронное правительство или система, объединяющая различные модели данных и построенные на их основе базы данных. В ряде случаев необходимо использовать не только реляционные базы данных, но и современные объектно-ориентированные модели данных, которые в чисто реляционные таблицы не вполне укладываются исходя из динамического характера объектов и ряда других факторов. Имеются как теоретические, так и удовлетворительные практические результаты в объединении неоднородных источников данных. При этом возможны различные подходы к интеграции неоднородных баз данных. Это можно осуществить путем разработки новых моделей данных, которые объединяют различные подходы к хранению данных (реляционный, сетевой, иерархический, объектно-ориентированный) на основе чисто объектных моделей. Другой подход основан на преобразовании языков манипулирования данными (аналогичных SQL) для взаимодействия с данными, которые хранятся в нереляционных форматах, создании адаптеров для такого рода нереляционных СУБД. При интеграции подобных систем в глобальную среду сетевых коммуникаций, в интернет-среду важной проблемой становится обработка достаточно сложных запросов. Важными аспектами такой интеграции является управление транзакциями на глобальном уровне. Это сложная и многоплановая задача. Сложность вызывает оптимизация запросов, если речь идет об использовании разного рода баз данных для ответов на запросы, а кроме того, администрирование этих данных, ведение журнала, аудит пользователей для получения консолидированных отчетов по безопасности.

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

Другим интересным направлением в развитии корпоративных систем с базами данных является их взаимодействие с GRID-системами, которые представляют собой глобальные высокопроизводительные сети для вычислений над большими объемами данных в короткие сроки. В ряде случаев такие объемы данных накапливались годами и измеряются терабайтами. Интеграция гетерогенных информационных систем в мультибазы данных и их взаимодействие с GRID являются перспективными направлениями исследований. При этом интерес представляет как построение моделей данных в основном на основе объектов для поддержки этих интегрированных систем, так и разработка средств реализации такого рода систем, в том числе специализированных адаптеров для известных систем, чтобы появилась возможность интегрировать вновь создаваемые системы в существующие среды.

GRID-системы – это системы распределенных вычислений, отличные от традиционных корпоративных СУБД. В ряде корпораций уже есть примеры использования таких систем. Под этим термином понимается глобально распределенная сеть, которая в отличие от корпоративных систем должна обеспечивать очень высокую производительность, дающую возможность обычным компьютерам соперничать в производительности с супер-ЭВМ. В ряде отраслей знания есть потребность хранения и обработки терабайтных объемов данных. Это нужно в биологии для анализа ДНК, в медицине для компьютерной томографии в реальном времени и анализа развития онкологических заболеваний, в геофизике для анализа спутниковых данных об атмосферных явлениях, в астрономии для анализа динамики космических тел, в физике элементарных частиц для анализа данных с ускорителей, в криптографии, вычислениях (константы пи). Характерные скорости поступления информации в таких системах – 100 Мб/с.

Необходима возможность подключения к одной сети множества компьютеров, соединенных оптоволоконными линиями. Для реализации GRID объединяются организации, обладающие высоким потенциалом с точки зрения количества единиц современной вычислительной техники. Примером могут служить ЦЕРН (Европейский центр ядерных исследований) или МИФИ (GRID-центр).

Помимо перечисленных задач есть отрасли, потенциально нуждающиеся в GRID: видеоконференции, дистанционное обучение, изучение фундаментальных процессов, научные исследования, имеющие дистанционный характер, высокопроизводительные вычисления.

Раздел II Средства, платформы и технологии разработки корпоративных систем

Глава 7 Средства автоматизации разработки корпоративных систем

От методологической и модельной части перейдем к части, которая в большей мере касается практики.

Обсудим более подробно CASE-средства.

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

Речь пойдет о попытках классификации CASE-средств. Их существует великое множество, и их число непрерывно растет. В последнее время популярна тема DSL (Domain Specific Languages) – предметно-ориентированных языков, которые нацелены на какие-то конкретные, узкие предметные области. Для них существуют как большие CASE-средства, такие как Microsoft Visual Studio, в который можно встроить такого рода языки и поддержку диаграмм, так и специальные средства, которые появляются достаточно часто. В любом случае причина появления подобных средств понятна (они будут рассмотрены более подробно), но прежде следует подвести некоторые итоги того, что было рассмотрено в предыдущей части курса моделей и методологий, а также сделать краткие выводы, чтобы перейти к практической части более естественным образом.

По поводу моделей и методологий нужно заметить, что это наиболее абстрактная формализация всего жизненного цикла ПО. Как правило, методологии включают все этапы ЖЦ, за редким исключением. Правильный выбор модели и методологии (если речь идет о жизненном цикле, то лучше употреблять термин «модели», методологии – это просто набор практических приемов реализации этого ПО того или иного программного проекта или программного продукта). Выбор модели критическим образом сказывается в целом на успехе проекта, поскольку он определяет архитектуру проекта, архитектуру решения, из какого количества компонентов будет состоять решение, какие технологии будут использоваться, как эти компоненты будут взаимодействовать. Во многом определяется экономика проекта, поскольку существует глобальный документ – план проекта, тесно связанный с той моделью и методологией, которая принимается для разработки. И в этом плане, естественно, трудозатраты будут указываться в соответствии с выбранной моделью. Некоторые модели, скажем каскадная, поддерживают проектирование в один проход, являются документоориентированными, другие – неполный жизненный цикл, например модель Build-and-fix (модель проб и ошибок), либо итеративную или эволюционную разработку, когда на каждом этапе после завершения каждого частичного цикла появляется в общем готовый с точки зрения надежности продукт, пусть и не полнофункциональный. Здесь тоже во многом можно вести речь о раннем начале сопровождения, т. е. тоже об экономике проекта. Конечно, модель, также как и методология, должна учитывать опыт проектной команды. Естественно, если вести речь о больших системах, команда должна иметь опыт работы с той или иной моделью, с теми или иными стандартами. Конечно, серьезные модели требуют определенной дисциплины при проектировании и зрелости проектной команды, нужно соблюдать стандарты и знать в том числе CASE-средства, используемые командой для всех этапов проектирования и реализации системы. Поэтому стоит обсудить CASE-средства более подробно.

Универсальной модели не существует так же, как и универсального CASE-средства, несмотря на то, что есть линейка Rational, которая поддерживает практически все этапы жизненного цикла, Microsoft Visual Studio – достаточно серьезное средство, в том числе и для командной работы. Поэтому в ряде случаев хорошим подходом является комбинирование. Конечно, у всех моделей, также как и у всех CASE-средств, есть свои определенные преимущества и недостатки, они ранее упоминались. Так, спиральная модель требует оценки рисков, что, с одной стороны, является преимуществом, а с другой – влечет достаточно серьезные затраты, поэтому ее лучше применять для внутренних проектов, где разработчик может получить от заказчика полную информацию о рисках и сложностях, с которыми можно столкнуться в проекте с точки зрения представления предметной области. Преимущества и недостатки имеют смысл только в контексте проекта, исходя из этого следует выбирать не только модель жизненного цикла и методологию разработки, но и те технологические средства и архитектурные особенности, которые будут лежать в основе поддержки этого проекта.

По поводу проектирования и управления базами данных необходимо напомнить, что в основе корпоративных систем лежат базы данных достаточно большого объема, измеряемые тера-, а в ряде случаев – петабайтами (1015 байт). Размер, которого они могут достигать, достаточно быстро возрастает, примерно в 2 раза за пять лет. Это можно считать экспоненциальным ростом при достаточно больших базовых объемах, поэтому достаточно важно рассмотреть базы данных как элемент корпоративных систем.

Когда речь идет о поддержке корпоративных систем базами данных, возникает та же проблема, что и при построении корпоративных систем. То есть сначала нужно выстроить общую архитектуру, в данном случае это ER-модель (структура отношений), а с другой стороны, нужно подумать о физической структуре хранения, о том, каким образом будет осуществляться резервирование для обеспечения надежности, восстановление базы данных, в каком режиме, при какого рода сбоях. Бывают сбои «мягкие», бывают «жесткие», которые вызываются отключением электропитания, более серьезными отказами оборудования, и в ряде случаев может помочь только относительно свежая резервная копия. При этом теряются данные, актуальность, и в этой связи нужно рассмотреть стратегию резервного копирования и восстановления данных, а также механизмы доступа к данным. При этом кроме проектирования, важным вопросом которого является формирование ограничения целостности и ряд других аспектов, нужно учитывать еще и семантическое моделирование, т. е. подходить к базе данных как к модели предметной области (декомпозиция предметной области должна адекватно отображаться структурой базы данных, с тем чтобы изменения, которые могут возникнуть в предметной области, вели к минимальной коррекции общей схемы отношений в базе данных и их взаимодействий).

Еще один важный аспект, который нужно отметить, – это многопользовательский характер работы с корпоративными системами. Здесь используются механизмы, связанные с транзакциями, с атомами функциональности при операциях на низком уровне с базой данных. Достаточно сложно обеспечить устойчивое манипулирование пользователей с данными при необходимости поддержки требований изоляции, т. е. каждый пользователь в идеале должен работать с данными таким образом, как будто кроме него никто с этими данными не работает. То есть ему должно казаться, что за исключением обстоятельств, вызванных временем реакции системы, на самом деле ничего экстраординарного с данными не происходит. Все изменения, которые вносит пользователь, отражаются на структуре данных, и пользователь не должен ощущать того, что одновременное присутствие сотен (а иногда тысяч и десятков тысяч) пользователей усложняет работу. Для этого необходимо обеспечить грамотную стратегию администрирования. Ранее речь шла о том, каким образом это следует делать.

При создании корпоративных систем и построении их при помощи CASE-средств необходимо принимать во внимание также и основы архитектуры. Надо понимать, что вслед за организационной структурой корпорации, которая является распределенной территориально (часто глобально распределенной), архитектура тоже является распределенной. При этом она следует концепции открытых систем, которые поддерживают стандартные интерфейсы, протоколы взаимодействия между компонентами корпоративного программного комплекса, и посредством концепции открытых систем можно обеспечивать плавное наращивание функций и (или) производительности на основе относительно недорогой замены отдельных компонентов или внесения изменений в эти компоненты.

В основе корпоративных архитектур программных систем лежит принцип специализации, т. е. разделения функций, и прежде всего выделения компьютеров или логических объектов, которые обеспечивают обслуживание пользователей и компонентов или программных объектов, производящих запросы на предоставление определенного рода ресурсов. Речь идет о клиентах и серверах. При этом возможна дальнейшая специализация: кроме файл-серверов или серверов приложений можно выделить телекоммуникационные серверы, серверы баз данных и т. д. При этом современные архитектуры клиент-серверного типа, как правило, для корпоративных приложений реализуются в трехзвенной версии, т. е. выделяются явным образом презентационная логика, бизнес-логика и логика доступа к ресурсам. В зависимости от организации распределения этих трех уровней по клиентам и серверам выделяется тонкий клиент и толстый. Тонкий клиент включает только презентационную логику, т. е. фактически веб-браузер на компьютере пользователя, все остальное – и бизнес-логика, и логика доступа к ресурсам – располагается на сервере или различных серверах. Толстый клиент оставляет на сервере только или в основном логику доступа к ресурсам. Тонкий клиент эффективнее с точки зрения возможности реконфигурирования обновлений, поскольку обновления приходится вносить фактически только в серверную часть, а клиентских мест в корпоративной системе, как правило, достаточно много (они измеряются сотнями, тысячами, иногда десятками тысяч), поэтому реконфигурацию производить достаточно накладно. Кроме того, специализация существует и в отношении сервера: иногда бизнес-логика выделяется в особый слой (физически это необязательно отдельно стоящий компьютер), это отдельное приложение со своими ресурсами, которое называется сервером приложения.

Перспективны для корпоративных архитектур подходы, связанные с интегрированными или федеративными базами данных достаточно большого уровня – масштаба государства, поскольку, например, министерство и другие крупные структуры могут также быть названы корпорациями распределенной структуры с общими бизнес-задачами или общими задачами, необязательно именно бизнеса или производственной деятельности. Кроме того, выделяются мультибазы данных, это ограниченное представление интегрированных баз данных, когда корпоративные системы внедрены туда лишь отчасти, поскольку некоторые критичные данные корпорация считает нецелесообразным открывать.

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

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

Конечно, перспективны компонентные корпоративные приложения, как в архитектуре. NET или Java Bins, масштабируемые, мобильные, естественно, существуют и мобильные версии приложений. Компонентный подход. NET предполагает и мобильную версию. Например, мобильный смартфон на платформе Windows Mobile 5.0 также имеет. NET Framework, семейство классов. NET, и на том же самом языке C#, о котором пойдет речь, можно вести проектирование так же, как и на большой системе. Корпоративные клиенты могут получать доступ к данным с таких устройств. Как на платформе. NET, так и на платформе Java возможны подобные решения. Речь идет о клиент-серверных решениях, причем, как правило, трехзвенных, с явным выделением прикладной логики в отдельный слой. Перспективные направления развития корпоративных систем – это кроссплатформенность, т. е. возможность миграции с платформы на платформу (здесь под платформой можно понимать операционную систему и более высокий прикладной уровень), также интероперабельность и безопасность, это достаточно важные тенденции. Интероперабельность связана с компонентным проектированием, т. е. с возможностью гибкого наращивания функциональности или производительности за счет небольшой локальной доработки отдельных компонентов.

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

Как уже было отмечено, важные составляющие корпоративных систем – это база данных и СУБД. Перечислим основные стандарты, которым имеет смысл следовать, определившись со стратегией и тактикой реализации корпоративного приложения. В частности, большое значение имеют стандарты UML, Rational Unified Process и Microsoft Solution Framework. Существуют корпоративные стандарты, ряд объектных стандартов, например COM, DCOM, COM+, объектные модели Microsoft, модель Java Bins, компонентная модель Java, модель брокеров объектных запросов CORBA и целый ряд других. Здесь, может быть, нет строгой математической интерпретации, но тем не менее это некая формализация и во многом официальный стандарт, которого следует придерживаться.

В сложных системах, как правило, возникает понятие объекта, как и в современных базах данных. И соответственно проектирование и реализацию этих систем нужно вести с учетом понимания природы этих объектных моделей, и, конечно, для корпоративных систем необходимо использовать достаточно строгие методологии, такие как RUP, MSF, которые дают возможность, с одной стороны, адаптироваться к требованиям заказчика, а с другой – обеспечить достаточно полный набор проектной документации и должной детализации выхода по проекту. Следует напомнить, что выход по проекту и программный продукт – это не только программный код, но и документация, техническое задание или список требований, функциональных и других проектных ограничений, целый ряд диаграмм, описывающих сценарии использования, прецеденты, классы, которые будут проектироваться, динамику взаимодействия (диаграммы переходов состояния, диаграммы последовательностей, взаимодействия, потоков данных, клиент – объект, которые ведут нас к ответственному проектированию, и др.), документация к коду, находящаяся внутри кода к каждому модулю, построчная документация к коду модуля, документация к модульным интерфейсам и общая документация, которая включает документацию для специалистов по установке программ, настройке, конфигурированию, и пользовательская документация, в том числе краткая и полная инструкции по эксплуатации программного обеспечения.

Теперь уже предметно рассмотрим CASE-средства, которые помогают автоматизировать проектирование корпоративных приложений. Попробуем выделить несколько направлений классификации CASE-средств, принципы их упорядочивания, организации, поскольку их действительно достаточно много и многие из них реализуют целый ряд полезных идей, которые было бы целесообразно использовать при производстве корпоративных приложений. Рассмотрим классификации по масштабам применения, видам моделирования (здесь речь идет не совсем о математических моделях, хотя есть CASE-средства, которые используют раскрашенные сети Петри и другие интересные математические формализации, но их не так много) и функциональному назначению. Дадим определение CASE-средств, рассмотрим их основные функции и состав, а также достаточно большое количество примеров с описанием функций основных CASE-средств, которые популярны прежде всего в нашей стране. На Западе традиционно используется немного иной набор CASE-средств. Например, в России достаточно популярно CASE-средство Borland Delphi, а в США оно практически не используется, т. е. срез распространенности, или популярности, CASE-средств в нашей стране и за рубежом выглядит иначе.

Что такое CASE, или Computer Aided Software Engineering? Software Engineering – это программная инженерия, та самая дисциплина, которая и ведет к построению качественных, надежных, производительных, масштабируемых, больших программных систем и комплексов, в том числе в масштабах корпорации. А CASE – это инструментальные средства, которые поддерживают создание таких систем, т. е., по сути, весь жизненный цикл корпоративных приложений. Рассмотрим основные этапы жизненного цикла и задачи, которые пользователи CASE-средств или разработчики решают в ходе создания корпоративных приложений. Во-первых, это анализ и спецификация требований к функционалу и других проектных ограничений к программному обеспечению, которое будет создаваться, проектирование прикладного программного обеспечения и баз данных, т. е. речь идет о диаграммировании и архитектурном проектировании. CASE-средства позволяют в отношении баз данных строить схему базы данных по ER-модели, по ER-диаграмме. Кодогенерация в определенной мере производится также автоматически, например, по диаграмме классов можно строить сигнатуры классов автоматизированно, а также вести трассировку проектных спецификаций.

Когда речь идет о модели Microsoft, или модели синхронизации и стабилизации, следует заметить, что эта модель достаточно сложна, поскольку она требует автоматизации тестирования. Также стоит отметить, что средства тестирования, такие как Rational Robot, достаточно широко распространены в мире CASE-средств. Есть похожее средство и у Microsoft.

Рассмотрим средства документирования. Когда речь идет о большом количестве билдов, большом количестве релизов ПО, нужно поддерживать каждый релиз своей версией документации, которая также имеет версии. Вести контроль этих версий и изменений, которые были внесены, достаточно сложно, особенно если документирование ведется вручную и документация имеет большой объем, вполне сопоставимый, а иногда и превосходящий объем кода. Скажем, документация только для пользователей по одному модулю Oracle Applications – это книга объемом примерно 700 страниц с большим количеством иллюстраций, перекрестными ссылками, глоссарием и целым рядом других вещей для быстрого поиска информации. Конечно, создавать такие документы вручную и отслеживать их взаимосвязи, что очень важно в проекте, в случае корпоративных систем без CASE-средств невозможно.

Далее речь пойдет о системах обеспечения качества, в том числе тестирования и трассировки спецификации. Рассмотрим управление конфигурацией. Как было отмечено ранее, проекты сложны, в них большое количество файлов (тысячи, может быть, десятки тысяч) и каждая версия характеризуется их уникальным набором. Если некорректно учитывать состав этой версии и собирать ее, ПО будет ненадежным или вообще неработоспособным. Когда речь идет о корпоративной системе, это, конечно, недопустимо. Поэтому управление конфигурацией, полный учет модулей и проектной документации, которая их сопровождает, – это тоже важная функция CASE-средств. Еще одной важной функцией является управление проектом, организация взаимодействия на основе, скажем, программного инструментального CASE-средства Microsoft Visual Studio Team System, и целый ряд других процессов.

На самом деле CASE-средства поддерживают весь жизненный цикл и все процессы, сопровождающие ЖЦ, которые приводят к построению надежного, устойчивого, масштабируемого, сопровождаемого, эргономичного ПО. Ведь CASE-средства поддерживают и тестирование, и пользовательский интерфейс, а это достаточно сложная задача, если решать ее вручную. В качестве примера можно привести проект создания системы учета, планирования, управления людскими ресурсами. В проекте достаточно гибкая цепочка ввода данных – порядка 20 форм, которые можно настраивать в зависимости от типа пользователя. То есть когда человек устраивается на работу, он должен заполнить анкету, состоящую на самом деле из последовательного ввода данных в формы. При этом в каждой форме существуют обязательные и необязательные поля, а также поля, которые подразумевают только выбор из уже существующих вариантов, т. е. самостоятельно заполнять эти поля нельзя, и т. д. Настраиваются эти поля достаточно гибко. Понятно, что при создании такого количества форм проверить вручную нажатие всех кнопок и выбор всех вариантов не представляется возможным, поскольку сценарий ввода данных гибко настраивается в зависимости от типа пользователя. Такого рода сложные интерфейсы и позволяют тестировать специализированные CASE-средства.

Какие компоненты входят в состав современных CASE-средств? Это прежде всего репозиторий (единое хранилище метаданных), здесь поддерживается средство хранения версий. Как уже упоминалось, существуют основные или базовые версии, к которым пристраиваются «ветви», или определенные направления, ветвления попыток совершенствования системы. В определенный момент их замораживают или закрывают на замок (lock), делают операцию замыкания и некий стабильный релиз, который полностью обособлен и может быть использован, скажем, на этапе приемки работ или этапе завершения какой-то определенной фазы жизненного цикла ПО. Очень важно при этом поддерживать синхронизацию. Например, если кто-то из разработчиков откомпилировал и сохранил новую версию файла, то нужно добиться, чтобы эта локальная версия файла переходила в глобальный билд как компонент, когда он уже готов и протестирован вместе с соседними модулями. Контроль целостности – тоже важный аспект в случае баз данных. Скажем, если удалить последнего сотрудника из отдела, что должно происходить с отделом? Кроме того, ведется контроль целостности не только на уровне структур данных, но и на уровне проектных спецификаций. Нужно убедиться в том, что они полны, непротиворечивы и те диаграммы, которые разрабатываются, в том числе с помощью CASE-средств, действительно являются адекватным отображением ранних шагов моделирования жизненного цикла ПО.

CASE-средства включают также графические средства как для анализа и проектирования, так и для последующих шагов жизненного цикла. Это возможность создания и редактирования целого ряда диаграмм, например Microsoft Visual Studio, которая поддерживает большое количество диаграмм на основе интеграции со средством Visio. Линейка Rational поддерживает практически все виды UML-диаграмм, поскольку изначально ориентирована на этот язык и стандарт моделирования. Другой стандарт – это IDEF, диаграмма потоков данных, ER-диаграммы и ряд других диаграмм относятся к этому стандарту.

Другими компонентами CASE-средств являются средства, поддерживающие разработку прикладного ПО, т. е. создание программного кода. Здесь сразу следует отметить такие интересные возможности, как IntelliSense с цветовой подсветкой синтаксиса, выделением метаинформации, например, членов данных классов при вводе имени класса и т. д., которые существуют в Microsoft Visual Studio.NET.

Средства управления конфигурацией – это средства документирования, тестирования, управления проектами и реинжиниринга, т. е. средства, которые позволяют вести повторное проектирование, перепроектирование отдельных компонентов программного продукта.

Какого рода критерии классификации можно выделить, если вести речь о CASE-средствах? Их достаточно много. Первые CASE-средства появились в 1990-х гг. В журнале «Byte» от марта 1993 г., который был полностью посвящен CASE-средствам, были описаны методологии проектирования и поддерживающие их CASE-средства. Существовала методология Буч известного автора Гради Буча, сотрудничество которого с Якобсоном и Рамбо привело к созданию языка UML с целым рядом диаграмм. Ивар Якобсон тоже работал в те времена, когда происходило становление CASE-средств. Первые CASE-средства были основаны в том числе на диаграммах потоков данных, так как объектных моделей в полной мере тогда, наверное, не было или они были в начальном состоянии. Также широко использовались ER-диаграммы.

Итак, к основным критериям можно отнести степень интегрируемости, т. е. то, какую долю этапов жизненного цикла поддерживает это CASE-средство, предназначено ли оно только для анализа и проектирования или только для тестирования или для реализации и интеграции, или для документирования, или это CASE-средство или комплекс CASE-средств, которые поддерживают целый ряд этапов жизненного цикла (например комплекс CASE-средств от Rational поддерживает практически весь жизненный цикл). Существуют локальные, частично или полностью интегрированные CASE-средства, т. е. некоторые CASE-средства предназначены исключительно для работы в настольном режиме, однопользовательском, другие – преимущественно для командной работы, разработки больших корпоративных систем. Существуют полностью интегрированные средства, имеющие общий репозиторий, в котором все метаданные проекта хранятся вместе: это и общение по проекту, и конфигурация продукта, и документация. Фактически все эти артефакты хранятся вместе в общей базе метаданных и позволяют получить общий доступ с учетом ролей к тем или иным компонентам проекта.

Естественно, хорошим критерием классификации может явиться стандарт. Скажем, поддерживают ли CASE-средства UML-диаграммирование, или IDEF-диаграммы, или XML как формат хранения и т. д. Методологии проектирования тоже очень важны. Поддерживает ли это средство MSF или Rational Unified Process и в каком объеме, в каких аспектах? Какие модели корпоративных информационных систем, в частности баз данных, поддерживаются? Поддерживаются ли ER-модели и вообще реляционные модели данных или, может быть, поддерживается сетевая иерархическая модель данных, объектная модель определенного рода?

С какого рода СУБД эти CASE-средства интегрированы – еще один критерий. Может быть, эти средства рассчитаны только на кодогенерации, ведь структуры данных могут быть снабжены также ограничением целостности и триггерами и хранимыми процедурами на определенных языках. Скажем, существует язык PL/SQL, который предназначен специально для СУБД Oracle, и какие-то CASE-средства поддерживают только базы данных Oracle или ориентированы преимущественно на Oracle, другие ориентированы преимущественно на Microsoft SQL Server. Эти базы данных и SQL-серверы более подробно будут рассмотрены в дальнейшем.

Начнем по порядку рассматривать CASE-средства и отмечать те их аспекты, которые полезны и укладываются в ту или иную классификацию. Одним из первых CASE-средств, достаточно серьезных и хорошо известных в нашей стране, является BPwin. Как правило, оно используется в комплексе с Erwin, которое генерирует ER-диаграммы и по ER-диаграммам – схемы базы данных. Автором является Computer Associates. Здесь поддерживается методология IDEF0, DFD-диаграмма потоков данных, и основным назначением является функциональное моделирование и анализ деятельности предприятия. То есть речь идет об анализе и спецификации требований. Эта часть жизненного цикла в основном и реализуется CASE-средством BPwin.

В качестве модели данных используется не объектная модель данных, а диаграмма процессов, это очень похоже на DFD и является некоторым развитием. Это более ранняя технология, структурный анализ и проектирование (Structured Analysis and Development Technology, SADT), современный подход называется объектно-ориентированным (Object Oriented Analysis and Development, OOAD). При этом учитываются этапность, стоимость, длительность и периодичность процессов, т. е. в основе лежат диаграммы процессов, и с помощью этого средства возможно проанализировать бизнес-процессы на предприятии, их формальное описание и построение определенных диаграмм, которые позволят оценить стоимость затрат на внедрение системы, узкие места технологических цепочек и затратные центры – другими словами, точки, которые потребуют наибольших затрат.

Полезна интеграция с Erwin, которая поддерживает ER-модель как направление, и генерация отчетов в достаточно распространенных форматах офисных приложений MS Word, MS Excel. Связанным с этим CASE-средством является CASE-средство Erwin той же компании изначально. Это CASE-средство для проектирования и реализации баз данных, т. е. работа идет с IDEF1X-диаграммами, с ER-диаграммами стандартного вида. Здесь достаточно полный набор возможностей: можно строить, настраивать, проектировать в графическом виде ER-диаграммы с атрибутами сущностей, связей, поддерживать индексы и ограничение целостности на основе бизнес-правил.

При этом поддерживается достаточно большое количество SQL-серверов или серверов баз данных – это и Oraсle, и Microsoft, и целый ряд других (Informix, Sybase, Progress, DB2 от IBM) СУБД корпоративного типа. И кроме того, поддерживаются достаточно легкие настольные системы, большинство из них, конечно, уже устарело, но Microsoft Access, например, достаточно современная система, Clipper до сих пор используется, также как и СУБД Paradox, в свое время созданная корпорацией Borland, и целый ряд других систем. При этом важно, что по ER-диаграммам автоматически производится генерация SQL-кода и триггеров, т. е. процедуры, которые поддерживают ограничение целостности. Возможен реинжиниринг базы данных, т. е. по SQL-коду можно восстановить структуру базы. Поддерживает кроме большого количества серверов баз данных достаточно большое количество CASE-средств, и осуществляется возможность коллективной разработки баз данных. Здесь поддерживаются форматы Oracle, Sybase, Microsoft SQL Server.

Что интересно, кроме BPwin, возможна интеграция и с другими CASE-средствами от сторонних производителей, в том числе Delphi – достаточно популярным и распространенным в России CASE-средством.

Достаточно интересно CASE-средство, которое называется CASE 4.0. Оно работает по методологии Уорда Мелора, это тоже структурный подход к анализу и проектированию, дообъектный. По сути, речь идет о расширении подходов Йордена, это одна из первых CASE-методологий, появившаяся в начале 1990-х, и Де Марка (тоже достаточно известный подход для информационных систем, которые функционируют в реальном времени). Это важно и для корпоративных приложений, поскольку очень часто нужно обеспечить быстрое построение консолидированных отчетов. Здесь функционирование в реальном времени или с достаточно быстрой обратной связью и небольшим временем реакции является важным требованием.

Поддерживаются следующие этапы жизненного цикла: системный анализ, проектирование, реализация. Естественно, системный анализ, или анализ требований, производится тоже на основе структурного подхода. В структурном подходе преимущественно учитывается какой-то один из аспектов – либо динамический, либо статический. В объектно-ориентированном подходе равное внимание уделяется и данным, и действиям, и динамике, и статике. То есть если мы посмотрим на класс, основное понятие объектно-ориентированного программирования, то увидим, что он содержит как атрибуты, так и методы, т. е. как некоторые статические числовые характеристики, так и методы, которые позволяют динамически изменять значения этих характеристик. Существует свой репозиторий, который позволяет этому CASE-средству поддерживать жизненный цикл, т. е. существует некое хранилище метаданных, ведется контроль целостности схем информационной системы и базы данных, поддерживается коллективная разработка, поэтому фактически речь идет о средстве создания корпоративных приложений. Кроме того, поддерживается целый ряд диаграмм: это устаревшие структурные карты Джексона и достаточно широко используемые ER-диаграммы, диаграммы переходов состояния (State Transition Diagram, STD) и диаграммы потоков данных (Data Flow Diagrams, DFD). В состав этого средства входят следующие компоненты: репозиторий; хранилище метаданных; визуальные редакторы диаграмм, которые позволяют вести визуальное проектирование, в том числе и командное; средства разработки диалоговых интерфейсов; средство кодирования, редактирования кода и производства документации; клиентская часть. Здесь стоит отметить общий репозиторий, который хранится на сервере, скажем, локальной сети, и серверную часть, которая является кроссплатформенной. Клиентская часть поддерживает только Windows, серверная – как Windows, так и целый ряд Unix-совместимых и других систем.

Еще одно CASE-средство, которое будет рассмотренно, – это Design/IDEF производства компании Meta Software. Здесь поддерживаются методологии, связанные с DFD и ER. То есть во многом очень похожи на предыдущие средства, но интересным является моделирование динамики бизнес-процессов на основе раскрашенных, или цветных, сетей Петри (Colored Petri Networks, CPN). Это достаточно интересная математическая модель, которая широко используется в моделировании – не только математическом, но и инженерном, в моделировании ПО. Какие этапы жизненного цикла поддерживаются? Это формализация требований, разработка и проверка проектных спецификаций, определение компонентов и связей, т. е. программных модулей и их интерфейсов, а также средство документирования. Кроме того, поддерживается имитационное моделирование бизнес-процессов корпорации. Какие функции поддерживаются? Это словари данных, т. е. фактически аналог диаграмм классов, если не подразумевать связи, по сути, речь идет о структуре данных, описании типов, которые входят в эту структуру, коллективная разработка, генерация отчетов, иерархическая декомпозиция, это производится на основе DFD. Кроме того, можно осуществлять генерацию кода на различных языках и дописывать свои языки. Подход, который позволяет дорабатывать, дописывать языки, создавая свой язык, – это подход, который близок к DSL (Domain Specific Languages), которые сейчас активно внедряются в Microsoft Visual Studio. Совместимость достаточно широка – это и MacOS, и целый ряд Unix-систем, и Windows. Существует интеграция с аналитическими пакетами, динамического анализа и анализа Cost Benefits (функционально-стоимостной анализ).

Следующим CASE-средством является комплекс из двух продуктов – Designer 2000 и Developer 2000 от Oracle. Сейчас есть Web Developer и целый ряд других средств от Oracle, которые продолжают эту линейку, но тем не менее это достаточно известное средство, связанное с автоматизацией проектирования корпоративных приложений, корпоративных систем. Oracle Designer предназначен как раз для проектирования корпоративных информационных систем, а Developer – в большей мере для реализации. При этом Oracle Developer ориентирован на корпоративную методологию Oracle CDM (Custom Development Methods). В его основе лежит каскадная модель, подход основан на структурном анализе и проектировании, т. е. достаточно жесткий дообъектный подход, возможно, не самый удачный. Поэтому эта методология существенно менее популярна, чем MSF. Плюсом MSF является наличие тренингов, книг. Рассматриваемая же технология локализована в корпорации Oracle и за ее пределы выходит достаточно редко.

Что включает в себя это средство? Репозиторий, т. е. хранилище метаинформации, поддержка коллективной, командной разработки и централизованное администрирование. Методология CDM поддерживает визуальный анализ бизнес-процессов предприятия и выявление источников их оптимизации, т. е. выявление узких мест, с одной стороны, и дублирование определенных или противоречивых бизнес-процессов, с другой. Детализация происходит на основе иерархических диаграмм. Здесь, конечно же, используется диаграмма потоков данных, которая как раз и является основой для моделирования бизнес-процессов, это классический структурный подход, дообъектный. С другой стороны, широко используются ER-диаграммы как средство проектирования структуры базы данных.

Поскольку речь идет о продукте корпорации Oracle, очевидно, что в основе лежит СУБД Oracle, и, кроме того, рядом находится сервер приложений Oracle Applications семейства прикладных систем корпоративного типа Oracle Applications. Естественно, поддерживается автоматическая генерация структуры данных на основе ER-диаграмм, по ним генерируются таблицы Oracle, поддерживаются диаграммы взаимодействия и ряд других диаграмм. При этом осуществляется поддержка распределения функционала, управляющего базой данных, на клиентскую и серверную часть. Клиентская часть содержит генерацию форм и отчетов (известный продукт Oracle Forms, Oracle Reports). Серверная часть содержит SQL-код с процедурным расширением на языке PL/SQL. Система ориентирована преимущественно на Windows и подразумевает возможность коррекции кода. Естественно, весь комплекс ориентирован на СУБД Oracle, что является существенным ограничением инструментальных средств автоматизированного проектирования ПО, Developer и Designer 2000. Oracle Developer Suite интегрируется с Oracle Designer и поддерживает кроссплатформенность – здесь операционные системы, как Windows, так и Unix, в частности Solaris и Linux, поддерживаются.

Конечно, речь идет о проектировании корпоративных приложений, т. е. поддерживается командная работа в распределенной среде и достаточно большое внимание уделяется интернет-технологиям. Oracle является одним из первых создателей ПО для проектирования корпоративных порталов, которое так и называется – Oracle Portal. В этой связи поддерживаются открытые стандарты на основе API-интерфейса, интерфейсов прикладных программных систем. Поддерживается средство быстрого прототипирования и быстрой реализации Oracle Application Development (OAD), процедурный язык запросов PL/SQL, о котором мы упоминали и который является специфическим для СУБД Oracle, в других СУБД он не используется. Используется стандарт UML для моделирования классов и бизнес-процессов. Также имеется сетевой репозиторий с возможностью контроля версий или релизов программных систем. На основе стандарта XML производится интеграция данных со сторонними CASE-средствами, и нестрого структурированные данные хранятся тоже в формате XML. Поскольку Oracle декларирует тот факт, что СУБД Oracle Enterprise Server является объектно-реляционной СУБД начиная с 8-й версии (сейчас уже существуют 11-я и 12-я версии), описание объектов и их характеристик является ключевым звеном этого продукта и здесь используется стандарт XML для этих описаний. И естественно, присутствует управление командной разработкой, в том числе централизация этого управления, администрирования, и достаточно широкая совместимость как с Unix-, так и с Windows-системами.

Еще одно достаточно известное CASE-средство – Vantage TeamBuilder использует методологии Йордена и структурных карт Константена. Того самого Лари Константена, который явился одним из пионеров CASE-средств и CASE-технологий. Поддерживается целый ряд диаграмм, но в основном опять-таки структурное проектирование, DFD, ER-диаграммы. При этом возможно двунаправленное построение диаграмм – как восходящее, так и нисходящее. Следует напомнить, что при проектировании систем на основе диаграмм потоков данных фактически производится структурная декомпозиция – разбиение относительно общих процессов на более детальные, конкретные составляющие. Здесь это возможно как снизу вверх, так и сверху вниз. Вообще при проектировании систем гибридная интеграция, гибридное проектирование как снизу вверх, так и сверху вниз является предпочтительным, поскольку позволяет достаточно хорошо протестировать проекты, обеспечить качество как модулей верхнего уровня, которые отвечают за основы бизнес-логики, так и модулей нижнего уровня, отвечающих за конкретные функциональные особенности программного кода программного продукта. Существует возможность проверки целостности моделей и диаграмм, которые используются, возможность кодогенерации, включая использование языков четвертого поколения, основанных фактически на скриптах, т. е. на некоторых небольших фрагментах кода, небольших программах, которые активизируются в зависимости от тех или иных пользовательских или системных событий и управляют системой. Естественно, проектирование ведется в визуальном интерфейсе. Поддерживается генерация схемы базы данных и SQL-запросов. То есть речь идет о проектировании как информационной системы, в том числе корпоративного типа, так и базы данных. Возможна настройка представления диаграмм в соответствии с различными стандартами, принятыми как организациями – законодателями этих стандартов, так и конкретными коллективами разработчиков. Возможно настраивать также интерфейсы, атрибуты и шаблоны кодогенерации. Платформа Microsoft поддерживается здесь в меньшей степени, поддерживаются Unix-системы и другие ОС, достаточно хорошая степень интеграции со сторонними CASE-средствами. В частности, поддерживается интеграция с языками программирования четвертого поколения, в том числе с языком C, а также с рядом СУБД – Informix, Oracle, Sybase. Видно, что платформа Microsoft здесь в меньшей степени присутствует как с точки зрения операционной системы, так и сточки зрения СУБД.

Еще одна связка CASE-средств – S-Designer и PowerBuilder производства компании Sybase, которая является также автором SQL-сервера, т. е. сервера баз данных. Эта связка нацелена на проектирование информационных систем и баз данных, в том числе корпоративного типа, клиент-серверных приложений. Основным назначением S-Designer является проектирование баз данных, и здесь используются ER-диаграммы, логические/физические модели данных и также ODBC (Object Data Base Connectivity) драйверы – средства взаимодействия с различными СУБД. Таким образом, интеграция с СУБД достаточно гибкая, большое количество поставщиков баз данных и основные производители здесь представлены: это Oracle, Informix, Sybase, Microsoft, причем как SQL Server, который предназначен для разработки корпоративных приложений с базами данных, так и настольная система Microsoft Access, и целый ряд CASE-средств. Обратим внимание, что используются CASE-средства производства как той же компании Sybase (PowerBuilder, предназначенное для реализации приложений), так и сторонних систем. Работа осуществляется под управлением операционной системы Windows. PowerBuilder работает в связке с S-Designer и также имеет язык четвертого поколения, который позволяет осуществлять написание управляющих процедур в терминах реакции на те или иные события пользователя или системы, и, естественно, существует визуальный интерфейс для реализации процедур на этом языке. Язык похож во многом на C++, это язык объектно-ориентированный.

Следующим CASE-средством, которое будет рассмотрено, является Silver Run. Оно поддерживает практически полный цикл программного обеспечения: это моделирование бизнес-процессов, архитектурное проектирование, детальное проектирование, реализация и сборка или интеграция модулей в полный программный продукт. Используется целый ряд методологий, достаточно ранних. Что интересно, могут использоваться сторонние методологии пользователей, это достаточно открытая система на основе экспертной системы с языковым интерфейсом, т. е. пользователи могут работать в привычных для них терминах той области, в которой они работают, системной аналитики, кадров, финансов, иных корпоративных ресурсов. При этом происходит автогенерация структуры реляционной СУБД. Поддерживается целый ряд систем управления базами данных – Oracle, Microsoft SQL Server, IBM DB2 и другие СУБД. В основе лежат диаграммы, которые нацелены на структурный подход (более ранний, чем объектно-ориентированный) к анализу и проектированию SIDT, т. е. ER-модель и диаграмма потоков данных, которые представляют собой средства описания и декомпозиции бизнес-процессов. Поддерживается целый ряд языков четвертого поколения, в том числе язык PowerBuilder и ряд других. Достаточно хорошая совместимость с большим количеством операционных систем программных платформ – как Windows, так и Unix-систем и MacOS.

Еще одно CASE-средство – это Visible Analyst от Visible Systems. Здесь используется коллективная разработка больших систем, и особенностью является Forward and Reverse Engineering, т. е. проектирование – как прямое, так и обратное. Интересно, что ряд CASE-средств позволяет восстановить модели данных на уровне диаграмм по коду или по схеме базы данных ER-модель. Примерно такого рода операции можно осуществить при помощи этого CASE-средства, которое поддерживает ER-диаграммы или IDEF1X, IDEF0, DFD и некоторые более старые нотации. В основном речь идет о структурном анализе, т. е. о статическом моделировании, в том числе с использованием структурных карт Константена. Поддерживается распределенное командное проектирование с общим сетевым репозиторием, применяются средства верификации – определения корректности переходов от одного этапа жизненного цикла к другому, можно осуществить трассировку требований к ПО и переход от этих требования (предположим, от сценариев использования к диаграммам). Поддерживается некоторое количество СУБД – Oracle и Informix (Microsoft SQL Server не поддерживается), а также достаточно большой спектр языков программирования четвертого поколения, включая PowerBuilder, о котором мы упоминали.

Еще одним достаточно мощным CASE-средством является ARIS производства IDS Scheer AG. Это очень большое и сложное CASE-средство, поддерживается более 80 типов диаграмм, достаточно сложная методология производства больших корпоративных систем, нацеленная на производство систем по учету планирования и управления корпоративными ресурсами (ERP-систем). Здесь можно осуществлять детальный анализ требований, поддерживается весь жизненный цикл – моделирование бизнес-процессов, функций и данных оргструктуры. Достаточно гибким является подход к детализации, написанию спецификаций. Используется целый ряд специфических аспектов, таких как функционально-стоимостной анализ, имитационное моделирование, поэтому это достаточно большое, тяжелое средство и для использования, и для обучения, и для производства больших мощных систем, одной из которых является SAP ERP. Конечно, используются и UML-диаграммы, и целый ряд специфических диаграмм, общее представление которых, если изобразить их графически, называется «домиком ARIS» и представляет собой пирамидальную структуру.

Еще одно мощное средство, которое будет рассмотрено, – это Microsoft Visual Studio.NET, которое предназначено для коллективной разработки больших систем распределенных приложений на основе компонентных интероперабельных приложений. При этом используется визуальный интерфейс. Какие основные функции можно обозначить при описании этого средства? Это построение быстрых прототипов, т. е. достаточно быстро можно осуществить визуальное проектирование, создать формы, элементы управления, командные кнопки, выпадающие меню и т. д., все это будет хорошо соответствовать современному интерфейсу Windows, оформить эти элементы управления соответствующими скриптами, скажем, на языке C#, короткими фрагментами кода, которые будут по тем или иным событиям наступать и выполняться, и таким образом осуществить быстрое прототипирование ПО. Кроме того, это разработка, тестирование, сопровождение крупных приложений корпоративного типа, прежде всего связанных с интернет-средой, потому что Visual Studio.NET основано на технологии веб-сервисов и использует ряд других технологий распределенной работы и обработки данных, включая remoting, технологии ASP.NET, Windows Forms, Web Forms и целый ряд других технологий Microsoft. Еще одна важная функция инструментальных средств – анализ и генерация структур информационных систем и баз данных. Под базой данных понимается преимущественно Microsoft SQL Server, управление бизнес-требованиями и т. д. Используется единая среда вычислений, внутри которой на основе общей виртуальной машины можно создавать гетерогенные проекты на различных языках программирования (поддерживается несколько десятков языков) и, более того, разрабатывать собственные языки программирования. При этом удается обеспечить достаточно высокий процент повторного использования компонентов, шаблонов архитектуры приложения корпоративного уровня, есть специальные библиотеки классов для корпоративных приложений (об этом речь пойдет позднее). Другое важное направление – средства создания требований к ПО, кодогенерации. В основе лежат протоколы или стандарты XML, SOA для сервисно-ориентированной архитектуры, абстрактная машина. NET, технология ADO (активных объектов данных) и целый ряд других технологий.

Еще одним важным стандартом, на который ориентируется Microsoft, является UML. Существенным недостатком (но на сегодня уже не столь значимым, поскольку Internet Explorer является достаточно распространенным браузером) является ориентация на платформу Microsoft, но основной недостаток по-прежнему остается в том, что это не только браузер, но и вся платформа, операционная система. К сожалению, интеграция с другими операционными системами и СУБД не слишком хороша, это является существенным ограничением.

В отличие от данного продукта средства, предлагаемые корпорацией IBM, линейка Rational, которая в свое время была приобретена у компании Rational, являются кроссплатформенными, т. е. поддерживают как Windows, так и Unix-диалекты, достаточно большое количество операционных систем. По сути, здесь также поддерживается весь жизненный цикл ПО, в том числе создание, анализ, коррекция, верификация архитектуры информационных систем. Все это происходит на основе открытых стандартов того же самого SOA, UML, SQL стандарта ANSI и ER-диаграмм или IDE-F1X и фактически поддерживается весь жизненный цикл ПО. Это и моделирование предметной области в терминах бизнес-процессов или инжиниринг, проектирование схемы БД, в том числе на основе визуальных технологий, разделение интерфейса и бизнес-логики, визуальный анализ и спецификация требований, поддержка различных языков программирования, в частности интеграция с C, C++, Java, Smalltalk, ADA (это язык, который поддерживает большие корпоративные системы для реального времени, язык, разработанный Пентагоном, используется во многом для военных систем) и целым рядом других языков. Поддерживается большое количество СУБД, прежде всего IBM DB2, Microsoft SQL Server, Oracle. Также существует большое количество шаблонов. Порядка 15 средств, которые отвечают за реализацию жизненного цикла ПО, используются в этом пакете: анализ и формализация требований – Requisite Pro, тестирование – Test Manager, контроль версий – Clear Case, формирование отчетов и целый ряд других процедур. Это семейство программных продуктов является интегрированным, и поддерживается сквозная унифицированная визуальная модель, в том числе для встроенных систем и мобильных устройств на основе открытой сервисно-ориентированной архитектуры SOA (Service Oriented Architecture). Преимущества таковы, что поддерживается кроссплатформенность, фактическая независимость от операционной системы и во многом от среды реализации, т. е. различные языки программирования, большой процент повторного использования, автоматическая генерация и оптимизация кода различных языков программирования. Система ориентирована на производство кроссплатформенных динамических интернет-приложений для различных устройств, как больших машин, так и мобильных устройств – смартфонов, коммуникаторов и т. д.

Обсудив основные CASE-средства (основные в том смысле, что они часто используются в нашей стране и на их основе реализован целый ряд больших и крупных корпоративных информационных систем), перейдем к классификации этих систем. Можно выделить три основные направления классификации – по масштабам применения, функциональному использованию (назначению) и видам моделирования, т. е. какого рода модели (стандарты) используются этими CASE-средствами. Естественно, все эти деления достаточно условные, это только один из вариантов возможных классификаций.

По масштабам применения CASE-средства можно разделить на локальные закрытые, средние открытые комплексные и крупные открытые комплексные.

Локальные закрытые – однопользовательские настольные системы с простыми нотациями для локальных информационных систем и небольших систем – до 100 одновременных пользователей. Это такие системы, как Design/IDEF, отечественное средство CASE-аналитик и ряд других.

Средние открытые – это ERwin, BPwin. Здесь подразумеваются интеграция со средствами быстрой разработки приложений и расширенные графические нотации, т. е. определенная открытость с точки зрения интерфейса уже присутствует.

Крупные открытые – комплексные системы, которые поддерживают комплексные графические нотации, встроенные средства прототипирования и быстрой разработки приложений (Rapid Application Development). Одним из примеров является S-Designer и PowerBuilder, т. е. речь идет о конвейерном производстве систем, о некоторых конвейерах, которые поддерживают достаточно большую долю жизненного цикла (итераций, связанных с ЖЦ программных систем). Большие системы для производства корпоративных приложений, крупные открытые комплексы поддерживают целый ряд графических нотаций, хорошо стыкуются с известными корпоративными методологиями и ориентированы на производство больших программных систем, т. е. имеют средства командной разработки, быстрого прототипирования и поддерживают весь жизненный цикл ПО. Это линейка Rational, которая была рассмотрена ранее, это конвейер Designer-Developer, который ориентирован преимущественно на Oracle, но тем не менее и на большие корпоративные СУБД и корпоративные приложения класса ERP, системы учета и планирования корпоративных ресурсов, ну и, конечно, Visual Studio.NET от Microsoft.

По функциональному назначению можно выделить следующие виды CASE-средств.

Комплексно-технологические конвейеры. О них мы уже упоминали, это Oracle Designer-Developer, Microsoft Visual Studio и линейка IBM Rational, которые представляют собой действительно большие комплексы программных средств и достаточно сложные программные средства, такие как Microsoft Visual Studio Team Suite, и предназначены для создания больших и сложных корпоративных систем с высокой степенью масштабируемости, со средствами прототипирования и поддержкой основных этапов жизненного цикла.

Проектный инструментарий для решения исследовательских задач. Рассматривалось средство, которое было связано с раскрашенными сетями Петри, есть специальные средства, такие как Protégé, основанные на использовании онтологических моделей, т. е. средства, которые предназначены преимущественно для исследовательских задач. Какие области следует здесь выделить? Это реинжиниринг бизнес-процессов (Business-Process Reengineering, BPR), когда в корпорации имеет смысл решить задачу оптимизации, перепланирования критических бизнес-процессов, расшивки узких мест и оптимизации затрат, скорости и качества обслуживания, что достаточно актуально в кризисный период.

Системный анализ и проектирование. Речь идет о построении новых или перспективных моделей функционального и информационно-событийного моделирования приложений, которые уже эксплуатируются либо будут создаваться.

По видам моделирования: моделирование бизнес-процессов, функциональное и событийно-информационное моделирование. Здесь речь идет в основном о методологиях, стандартах, которые используются, – объектно-ориентированный анализ и проектирование, структурный анализ и проектирование.

Моделирование бизнес-процессов. Бизнес-процессы формализуются IDEF0– и DFD-диаграм мами (диаграммы потоков данных) на основе методологий структурного анализа. Используются здесь такие CASE-средства, как BPwin и Design/IDEF. Важным недостатком является то, что статическая модель IDEF0 или DFD и подход на основе структурного анализа и проектирования не вполне отвечают динамическим, быстро изменяющимся требованиям внутри корпорации, которые связаны с бизнес-процессами. Здесь могут использоваться специфические модели на основе цветных, или раскрашенных, сетей Петри – это Design/CPN и Design/IDEF, которые блокируются друг с другом, используются совместно CASE-средства. Другой вариант использования специфических моделей для бизнес-процессов, в том числе тоже на основе CPN (раскрашенных сетей Петри).

Функциональное моделирование. Как правило, в России используются CASE-средства, поддерживающие те же нотации DFD (диаграмм потоков данных) и структурный анализ и проектирование, событийное моделирование расширяется управляющими потоками и процессами, т. е. расширенные диаграммы потоков данных, и, кроме того, используются такие диаграммы, как State Transition Diagram (диаграммы переходов состояния), диаграммы последовательностей, взаимодействий и другие UML-диаграммы, здесь речь идет уже о применении UML-стандарта.

Информационное моделирование. Моделирование структур данных или баз данных с использованием IDEF1X или методологии ER-диаграмм (ER-методологии).

CASE-средства Designer-Developer от Oracle как комплексный пакет и Visual Studio.NET поддерживают моделирование и бизнес-процессов, и функций данных, и событий. И линейка Rational является всеобъемлющей с этой точки зрения, поддерживаются все четыре вида моделей. Другие средства содержат меньшее количество моделей, т. е. специализируются на каких-то отдельных видах моделирования.

По сферам применения можно отметить те же CASE-средства – Rational, Microsoft Visual Studio, Oracle Designer-Developer, которые поддерживают весь жизненный цикл программных продуктов. Другие поддерживают выборочно – либо анализ и проектирование, либо реализацию и тестирование, либо проектирование баз данных. Есть еще целый ряд специфических средств, которые нацелены на анализ бизнес-процесса с выявлением узких мест или выявления оценки рисков, бизнес-планирования и оценки трудоемкости.

По моделям данных или методологиям, которые поддерживаются, здесь можно выделить также несколько основных направлений. Самыми распространенными методологиями являются IDEF1X (ER-модель) и различные UML-диаграммы, они поддерживаются достаточно большим количеством средств. Можно заметить, что существует большое количество методологий, которые на самом деле практически никакие CASE-средства не поддерживают. Самыми хорошими примерами поддержки большого количества методологий являются линейка IBM Rational, где поддерживается весь спектр UML-диаграмм и ряд других, а также Microsoft Visual Studio.NET, который тоже поддерживает широкий спектр диаграмм стандарта UML.

Завершая обсуждение CASE-средств, средств автоматизации проектирования систем, в том числе корпоративных приложений, следует сделать некоторые выводы. Итак, современные CASE-средства представляют собой комплексные конвейеры, если говорить о больших корпоративных приложениях, которые позволяют вести быстрое прототипирование и разработку приложений, т. е. существует объединение или интеграция с Oracle Application Development средствами: Oracle Designer-Developer, Microsoft Visual Studio, линейка Rational и отчасти Sybase, которая представлена S-Designer – средством проектирования и PowerBuilder – средством быстрой реализации и прототипирования. Основной стандарт визуального проектирования сегодня – это UML, достаточно большое количество диаграмм, которые позволяют моделировать и динамические, и статические процессы, происходящие при проектировании ПО. При выборе CASE-средств для проектирования и реализации корпоративных приложений следует отдавать приоритет аппаратно и, желательно, программно независимым и с высокой совместимостью, преимущественно Java, интероперабельным (т. е. системам, которые позволяют гибко конфигурировать корпоративные приложения на основе большого количества интероперабельных компонентов, это. NET и Java-технологии), распределенным (в частности, сегодня это интернет-технологии, уже не локальные сети) и компонентно-ориентированным, портируемым, поддерживающим как большое количество операционных систем, так и различные устройства доступа – от небольших смартфонов и коммуникаторов до полномасштабных офисных машин.

Глава 8 Программная платформа Microsoft.NET

В данной главе будет более подробно рассмотрен подход Microsoft к созданию корпоративных систем. Прежде всего речь пойдет о Visual Studio.NET и вообще о. NET подходе. Не стоит ограничивать. NET чисто технологическим аспектом, так как. NET – это платформа в достаточно широком и глубоком смысле этого слова, т. е. это идеология проектирования программного обеспечения, которая имеет в основе такие принципы, как сервисная ориентированность, интернет-распределенность, командная работа, компонентная ориентированность (интероперабельность) и, что еще интереснее, языковая интероперабельность – создание гетерогенных проектов с компонентами, написанными на разных языках и разными людьми в разных точках земного шара. По сути, речь идет об идеологии производства систем корпоративного типа, при этом платформа является достаточно общей и имеет единую среду в форме виртуальной машины, которая предназначена для создания и поддержки таких систем. На основе математических моделей, разработанных Юрием Гуревичем, моделей абстрактных машин с состояниями, построена виртуальная машина, на основе которой происходит создание приложений Microsoft Visual Studio.NET, являющихся уже технологической надстройкой, т. е. NET – это во многом еще и идеология и модель. Рассмотрим ее более подробно.

Четыре основные аспекта

Хотелось бы выделить четыре аспекта в подходе. NET как платформы для разработки корпоративных приложений:

1) концепция, т. е. общий подход;

2) вычислительная модель – в ее основе лежит достаточно формальная математическая модель. Это некая более реальная реалистичная формализация, но тем не менее тоже фактически модель вычисления на компьютере достаточно общего вида. Так же, как в Java-подходе, имеется виртуальная Java-машина, которая работает на любой платформе, так и здесь есть виртуальная машина высокого уровня, в терминах которой компилируется код на различных языках программирования, но эта платформа ограничена множеством ОС Windows;

3) технологическая платформа;

4) инструментальная средства Visual Studio.NET.

Достаточно важным является подход к реализации системы управления этой виртуальной машиной, которая называется Common Language Runtime (CLR) и подразумевает выполнение компонентов программы, написанных на различных языках. Платформа включает среду реализации, среду вычисления с точки зрения абстрактных (виртуальных) машин и. NET Framework общей надстройки, которая представляет собой семейство базовых системных классов. При этом система типов также является достаточно универсальной, т. е. общей common type system (CTS). По сути, с одной стороны, это система типов, которая принята в C#, а с другой – в эту систему типов подгружается на самом деле система типов любого языка программирования, который написан для этой среды.

Одним из достаточно ранних курсов, реализованных в Санкт-Петербургском государственном университете для. NET, является курс создания компилятора для. NET. Он был написан для студентов второго курса, которые за один семестр могли создать компилятор некоего подмножества языка C# для. NET. То есть речь идет о том, что не только на тех языках, которые реализованы для. NET, но и вообще на этой платформе возможно реализовать произвольный язык, если правильно погрузить его в термины виртуальной машины, и, конечно, типы языка, каким бы он ни был, будут оттранслированы в семейство CTS.

Еще одним важным принципом реализации концепции. NET является предоставление ПО как сервиса. На самом деле эта идеология присуща не только Microsoft, но и Java или подходу IBM SOA, но в рамках подхода. NET есть множественные реализации, которые связаны с различным образом организованными сервисами: это веб-сервисы, технология Remoting, более поздняя технология WCF и др., скажем ASP, технологии, связанные с веб-формами, и целый ряд других технологий, которые предназначены для реализации ПО как сервиса и распространении SOA по сети Интернет.

Первое, что приходит на ум при словах «распространение по Интернету», – это вирусы. В этой связи нужно сказать, что важным акцентом после известных событий 11 сентября для Microsoft является безопасность. Платформа. NET во многом ориентирована на реализацию этого принципа безопасности, и компоненты, которые создаются в рамках платформы. NET, учитывают это.

Одним из направлений реализации и принципом подхода SDL (Secure Development Lifecycle) является Seсure by Design, т. е. собственно проектирование ПО ведется таким образом, что оно является изначально безопасным. Во многом на это нацелена идеология. NET и ее компонентная ориентированность механизма сборок assembler, т. е. самодостаточных компонентов для разворачивания ПО, который является основой идеологии. NET и защищен такими средствами, как цифровая подпись, имя автора и версии сборки и целый ряд других аспектов, позволяющих обеспечивать высокую безопасность создаваемого ПО как покомпонентно, так и в целом для корпоративных приложений, строящихся на основе интероперабельности – постоянно взаимодействующих и меняющихся объектов.

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

Прежде всего речь пойдет о технологии Windows Forms и Web Forms, достаточно важных технологиях создания, в том числе и корпоративных приложений, которые обеспечивают стандартизацию пользовательских интерфейсов и взаимодействие в среде Интернет на основе этих интерфейсов. Конечно, мы посмотрим на. NET. Отчасти в сравнении с Java весь San Microsystems тоже имеет достаточно древний и апробированный подход, который называется EJB, по сути, компонентное проектирование тоже на основе виртуальной машины, и даже в различных ОС, не только Windows. Но с языковой точки зрения интероперабельность – подход немного беднее. Мы обсудим некоторые параллели, преимущества и недостатки. NET, которые выявлены и существуют, в том числе и в аспекте проектирования корпоративных приложений.

Что такое Microsoft.NET

Не совсем верно рассматривать. NET как исключительно технологическое средство, платформу. По сути, это достаточно комплексная идеология проектирования ПО, в том числе и корпоративного типа.

NET включает следующие основные аспекты (послойно, от более абстрактного уровня к более конкретному):

1) идеология проектирования и реализации программного обеспечения;

2) модель эффективной поддержки жизненного цикла прикладных систем;

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

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

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

Кроме того, это модель, в том числе и математическая, достаточно эффективной поддержки ЖЦ программных систем – от концептуальной постановки задачи проектирования до реализации, внедрения, разворачивания по сети Интернет одним кликом приложения и сопровождения. Это технология, обеспечивающая унифицированное проектирование с точки зрения использования открытых протоколов и средств взаимодействия SOA, HTTP, XML, UDDI, WSDL, других стандартов и, наконец, это современный, удобный в использовании и безопасный инструментарий командной разработки больших систем, который поддерживает все этапы ЖЦ – создания, разворачивания, размещения и сопровождения поддержки ПО.

Итак, рассмотрим более подробно основные аспекты. NET.

В чем состоит видение Microsoft этой идеологии?

По сути, речь идет действительно об идеологии, которая появилась на рубеже тысячелетий в 2000 г., может чуть раньше, и явилась программой развития корпораций, как минимум, десятилетия. Эта идеология доминирует до сих пор и претерпевает небольшие изменения, но концептуально остается в целом постоянно верной своим принципам.

Идеология и основные принципы. NET

NET как идеология (vision) – это:

1) легкость развертывания приложений в глобальной среде Интернет;

2) экономичная разработка программного обеспечения;

3) бесшовная, гибкая интеграция программных продуктов и аппаратных ресурсов;

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

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

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

2. Еще один аспект идеологии. NET – экономичная разработка ПО. Здесь речь идет и об экономии средств людских, временных ресурсов при командной работе, которую обеспечивает Visual Studio.NET как инструмент технологический, и собственно о том, что идеологически проектирование представляет собой создание компонентов, неких молекул функциональности, из которых и строится то самое вещество программного продукта корпоративного типа, который благодаря открытым интерфейсам может достаточно гибко и в относительно сжатые сроки с небольшими трудозатратами трансформироваться согласно требованиям программной среды и большого количества различных типов пользователей.

3. Также важным идеологическим аспектом. NET является интеграция программных продуктов и аппаратных ресурсов, которую можно охарактеризовать как бесшовную, гибкую. Вообще, если рассматривать производство ПО как задачу, то можно заметить, что изначально это было искусство, т. е. фактически ручное изготовление штучного товара. Позже наступил период, когда кустарей-одиночек сменили программные проектные команды, создающие ПО с использованием более серьезного инструментария. В настоящее время существующие сборочные конвейеры, такие как Visual Studio.NET и др., позволяют во многом стандартизировать режим и на основе стандартных компонентов вести сборку очень сложных систем, включающих сотни тысяч индивидуальных программных моделей, достаточно сложно взаимодействующих друг с другом. Сегодня все, что строится в мире ПО, во многом связано с интеграцией, т. е. в идеале новое ПО не производится, принципиально новая функциональность даже при создании нового продукта составляет от силы 10–15 %, все остальное – это уже ранее использованное решение, которое просто повторно применяется, и интеграция новых функциональных моделей компонентов с уже реализованными частями, фрагментами программ продуктов.

4. Еще один важный элемент идеологии – предоставление программного обеспечения как сервисов. То есть, с точки зрения пользователей, это фактически может выглядеть как некий сайт со средствами, которые предоставляют достаточно гибкие возможности для выполнения запросов в стандартном интерфейсе, и, по сути, функция ПО может быть реализована как сервис, распределена по интернет-сети и доступна по правилам доступа большому количеству пользователей.

5. Еще два важных аспекта идеологии. NET – новый уровень безопасности и удобства использования.

По поводу удобства: Microsoft удалось завоевать достаточно большое количество пользователей во многом потому, что ОС, которые она предоставляет, являются достаточно удобными с точки зрения удобства пользования (usability) – это хорошие средства, позволяющие достаточно быстро решать сложные или типовые задачи одним щелчком или с помощью мастеров для решения типовых задач. В Microsoft одна из самых сильных команд специалистов по usability. И многие пользователи уже привыкли к интерфейсу Microsoft.

Безопасность – это стратегический приоритет корпорации, и, конечно, NET как идеология не может не отмечать важность этого приоритета и широко его применять.

NET как вычислительная модель

1. Компонентный подход как развитие объектно-ориентированной модели.

2. Универсальная система типизации: «всякая сущность есть объект»; унификация данных и метаданных.

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

4. Универсальный интерфейс. NET Framework (включая поддержку различных подходов к программированию).

5. Высокая вариативность экземпляров реализации (в частности, на основе веб-сервисов).

Рассмотрим особенности вычислительной модели работы. NET, как подхода к созданию, в том числе больших корпоративных систем.

Прежде всего платформа. NET использует компонентный подход. По сути дела, это развитие объектно-ориентированной модели, компонент – это несколько большее понятие, чем объект, и достаточно важное, по сути дела, это некий программный модуль, на основе которого строятся приложения, взаимозаменяемый, стандартного рода модуль, который представляет собой молекулу функциональности.

Еще одним важным аспектом вычислительной модели является универсальная или обобщенная система типизации Common Type System. Здесь реализуется достаточно инновационный подход Microsoft, который сводится к декларации, что каждая сущность есть объект. То есть речь идет о чисто объектно-ориентированном подходе и попытке реализовать эту идею, а также об унификации данных и метаданных. Во всяком случае появляется достаточно хорошее средство использования метаданных. Репозиторий метаданных реализован достаточно эффективно, в частности, следует отметить средство Reflection, которое позволяет восстановить код по метаданным класса. Сборка или представление компонента включают в себя все метаданные, которые необходимы для разворачивания этого компонента как части программного продукта.

Кроме того, существует строго иерархическая организация кода. Поскольку речь идет о создании больших корпоративных систем, необходимо очень четкое определение местонахождения кода и управление этим кодом. Существует понятие «пространство имен и классов», в рамках которого на иерархической основе осуществляются хранение, поиск и управление кодом, из которого строятся большие программные проекты.

Обобщенный интерфейс. NET Framework базовых, системных классов является надстройкой над OC Windows и позволяет, кроме всего прочего, осуществить интеграцию различных подходов к программированию, таких как ООП, функциональный, логический и др.

Для. NET реализован целый ряд языков программирования, которые транслируются во внутреннюю среду абстрактной или виртуальной машины. NET. Это прежде всего родной язык. NET Си#; это F#, который, по сути, является развитием языка SML, т. е., с одной стороны, он во многом является функциональным языком, но с другой – реализует и некоторые аспекты ООП, поскольку функция является объектом модели и язык моделирует объектный подход; ряд языков Cobol, Fortran, которые использовались в большом количестве унаследованных проектов, и. NET, позволяет портировать проекты унаследованных приложений, в том числе корпоративных, которых очень много.

Языки логического программирования, такие как Prolog, поддерживаются в. NET, и любой новый или известный язык в виде компилятора для. NET можно реализовать самостоятельно.

Кроме того, важным является использование вариативности, т. е. возможность адаптировать различные экземпляры реализации применительно к требованиям пользователей, в том числе на основе веб-сервисов, гибко конфигурировать и вносить изменения в небольшие фрагменты кода.

Перечислим основные особенности технологической платформы. NET.

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

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

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

Независимо от языка программирования и программной модели поддерживается унификация доступа к библиотекам за счет общего интерфейса с виртуальной машиной. NET. Здесь используется аналог API-интерфейса, т. е. открытого интерфейса на основе классов, который можно достаточно гибко настраивать.

Также важно отметить, что. NET во многом соответствует современным технологическим стандартам. Язык C# сейчас фактически стандартизован европейской ассоциацией стандартов, и во многом используются стандартные протоколы обмена и стандарты таких данных, как HTTP, XML, UML, SOAP, протоколы взаимодействия.

Как инструментальное средство, NET является достаточно универсальным, поскольку поддерживает многоязыковую среду Common Language Runtime (CLR), которая, как упоминалось ранее, поддерживает разработку компонентов на различных языках. При этом важной особенностью является возможность построения фрагментов проекта на наиболее подходящих для этого языках.

При реализации бизнес-логики и интерфейса их, конечно, необходимо разделять. Бизнес-логику лучше реализовать на Прологе как набор условий и логических альтернатив, другой подход – сделать это на функциональном языке, таком как F#, а интерфейс можно достаточно легко реализовать на C#, который включает все механизмы взаимодействия с Windows и библиотеками. NET Framework наиболее быстрым и прозрачным способом, т. е. различные компоненты достаточно быстро реализуются.

И в этом смысле у. NET практически нет альтернатив, такого большого спектра языков и разнообразия подходов больше не найти. Причем сервисные средства. NET, такие как отладка, анализ кода и т. д., поддерживаются для всех без исключения языков, реализованных в рамках Visual Studio. То есть на каком бы языке ни велась разработка, программист получает все сервисные возможности, интегрированные в среду разработки. Как было сказано ранее, можно разрабатывать собственные языки программирования, это достаточно интересно и актуально. Одним из современных направлений развития программной инженерии является создание программного обеспечения на основе DSL – предметно-ориентированных языков, т. е. языков для приложений того или иного рода, той или иной предметной области.

Можно заметить, что одни языки разработаны Microsoft, другие – сторонними организациями и т. д. То есть существует бесконечное их разнообразие, поскольку есть возможность создать любой язык, погрузить его в. NET и экспериментировать.

Посмотрим на архитектурную схему: сбоку, интегрируя все доступные сервисы (рис. 8.1), начиная с уровня естественного языка, с уровня исходного кода на языке программирования, находится Visual Studio.NET – как средство разработки, оно интегрирует все особенности платформы. Основой для программирования являются различные языки программирования. Работа происходит в исходном тексте, в стандартном редакторе Visual Studio.NET, при этом на любом языке. Типы этого языка, какими бы своеобразными они ни были, транслируются автоматически при трансляции кода в стандартные системные типы. NET, т. е. имеют место трансляции в типы Common Language Specification (CLS). Далее используются на уровне пользовательского интерфейса различные веб-формы, веб-сервисы, скажем, средства SP.NET Windows Forms, технологии, связанные с. NET Remoting, и т. д. На уровне взаимодействия с данными используются технологии ADO.NET и т. д., слабоструктурированные данные могут преобразовываться по средствам форматов в стандарты XML. Естественно, все взаимодействие со средой выполнения строится на основе базовых классов. NET Framework, которые едины для любого языка программирования, строятся на основе компонентов, берущих свое начало в базовых классах. И все трансляции осуществляются в термины ассемблера высокого уровня – это ассемблер Common Language Runtime (CLR), т. е. виртуальной машины. NET (рис. 8.2).

Рис. 8.1. Архитектурная схема. NET Framework и Visual Studio.NET

Рис. 8.2. Схема компиляции в Common Language Runtime

При компиляции некоторого модуля программного текста, который написан на том или ином языке, запускается компилятор, зависящий от языка программирования, но среда у них общая, и в итоге получается сборка в форме DLL или EXE, который содержит все необходимые метаданные, чтобы развернуть и запустить эту сборку в составе корпоративного приложения.

Естественно, трансляция осуществляется в терминал языка MSIL – это ассемблер высокого уровня, который в 3–5 раз плотнее, чем обычный ассемблер, если рассматривать, например, процессор Intel 8086 или ассемблер Z80.

Рис. 8.3. Схема выполнения CLR

При этом в ряде случаев не представляется возможным осуществить безопасную компиляцию в управляемый код. К сожалению, работа с некоторыми механизмами, например с памятью, небезопасна, и в этом случае программист обязан пометить этот фрагмент кода как неуправляемый код. Он транслируется по другому пути, без MSIL, и объединяется с родным кодом уже как неуправляемый объект – и в этом случае ответственность за безопасность лежит на программисте. В любом другом случае компилятор преобразует сборку в исходный текст. После чего осуществляется сборка с использованием JIT-компилятора на платформе CLR, и, по сути, идет работа в терминах операционной системы, т. е. взаимодействие со средой Windows уже скомпилированного и собранного приложения.

Основные возможности, которые предоставляет среда CLR:

• поддержка стандартных типов и правил создания новых типов;

• межъязыковая интеграция:

– включение в код на одном ЯП классов на другом ЯП;

– обработка исключений из программы на одном ЯП программой на другом ЯП;

– и т. д.

• единый набор библиотек классов для всех поддерживаемых ЯП;

• самоописываемые компоненты – не требуют дополнительных файлов (IDL, TLB, Proxy/Stub и т. п.); компонент является самодостаточным, имеет всю необходимую информацию для встраивания его в программный продукт и разворачивания;

• поддержка версий компонентов и сборок кода;

• сервисы безопасности (запрет неавторизованного доступа к ресурсам для пользователей – Role-Based Security, доступ на основе безопасности кода – Code-Based Security и автор кода, версия сборки и др.).

Рассмотрим работу универсальной системы типизации (рис. 8.4).

В основе лежит понятие базисного типа, который в. NET называется System.Object (это очень похоже на Java). Он делится на две категории – типы-ссылки и типы-значения, при этом типы-значения и типы-ссылки различным образом хранятся и используются. Типы-значения при создании экземпляра класса каждый раз вводятся в память и т. д.

Типы-ссылки – это классы, интерфейсы, массивы, делегаты и т. д.

Типы-значения – это перечислимые типы структуры и простые типы, такие как целочисленный, логический и т. д. Все типы, определяемые пользователями, фактически являются типами-ссылками. Таким образом, имеет место строгая иерархия классов.

Рис. 8.4. Универсальная система типизации (UTS)

В основе архитектуры. NET лежит понятие «сборка».

Сборка кода (assembly) – группа ресурсов, типов и метаданные, описывающие эти ресурсы и типы, необходимые для функционирования компонентов. Сборка реализуется как единое целое. Сборка – это самодостаточная единица кода.

К особенностям сборок кода прежде всего относятся следующие:

• сборка распространяется и реализуется как единое целое;

• метаданные сборки содержат информацию о зависимостях между ресурсами, версиях и т. п.;

• сборка характеризуется номером версии (последняя, специфичная и т. п.).

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

• принцип. NET – «ПО как сервис»;

• следующий уровень архитектуры – уровень сервисов (рис. 8.5);

• сервисы доступны на уровне классов любого ЯП для. NET.

На нижнем уровне архитектуры существуют системные сервисы Microsoft Windows. На более высоких уровнях – различные надстройки, сервисы для работы с данными, сервисы интерфейсные и т. д. Сервисы. NET находятся на более высоком уровне, чем сервисы для Windows.

Рис. 8.5. Архитектура. NET – уровень сервисов

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

Абстрактная машина. NET. CLR располагается над уровнем сервисов ОС (Windows CE, Windows ME, Windows 2000, Windows.NET).

Системные сервисы располагаются над CLR (доступ – через библиотеки классов): доступ к функциям ОС, управление данными, отладка, другие сервисы и т. п.; еще выше – компоненты и сервисы для разработки веб-узлов, веб-сервисов, пользовательских интерфейсов (GUI).

Веб-приложения – архитектура клиент – сервер с доступом пользователей к данным через веб-браузер (технология ASP.NET).

Распределенные приложения на основе иных механизмов удаленного взаимодействия компонентов XML Web Services – на основе открытых стандартов, NET Remoting – на основе внутренних протоколов Microsoft и целый ряд других подходов.

По сути, NET представляет собой виды базовых классов для сервисов:

• доступ к сервисам ОС (Windows CE, ME, 2000, NET);

• доступ к графическим функциям (двумерная графика, обработка изображений, шрифты, в том числе технология ClearType, интеграция с GDI и DirectX);

• сетевые функции;

• управление потоками;

• глобализация;

• криптография;

• доступ к данным (библиотека классов ADO+ и OLE DB-драйверы);

• классы для средств разработки (отладка, трассировка, управление ресурсами, компиляция, установка ПО, протоколирование событий и т. д.);

• другие классы (в том числе поддержка протокола SOAP).

Назначение Windows Forms – обеспечение разработки традиционных Windows-приложений на основе сервисов Microsoft.NET и соответствующих библиотек классов.

Особенности разработки – унификация доступа:

• к библиотекам классов;

• механизмам распространения сервисов;

• механизмам поддержки версий;

• сервисам безопасности.

Вывод: создание Windows-приложений в архитектуре Microsoft.NET дает разработчикам существенные преимущества, поскольку огромное количество классов уже реализовано, и остается заполнить пробелы только с реализацией бизнес-логики по сравнению с традиционным API-ориентированным подходом.

Назначение Web Forms — основа веб-сервисов и веб-приложений в архитектуре Microsoft.NET.

Особенность – программная модель основана на ASP+ – новом поколении активных серверных страниц (эволюция технологии ASP – более 1 млн разработчиков).

Идея веб-форм (из Visual Basic 6): отделение логики веб-приложения от интерфейса (за счет объединения в рамках формы ASP– и HTML-кода).

Преимущества:

• более строгая структурированность приложений;

• широкий спектр (серверных) интерфейсных элементов;

• простая и мощная объектная модель;

• легкость разработки (и масштабирования) веб-приложений.

Основное средство для разработки приложений и сервисов в архитектуре. NET – Microsoft Visual Studio.NET (современная версия Microsoft Visual Studio).

Вот какого рода веб-сервисы можно создавать в. NET, так выглядит общая архитектура (рис. 8.6).

Рис. 8.6. Веб-сервисы в. NET

Веб-сервисы в. NET:

1) программируемые компоненты приложений, доступные посредством стандартных интернет-протоколов;

2) центральная часть архитектуры. NET;

3) распределяют функциональность по глобальной сети;

4) строятся на существующих и развивающихся стандартах: HTTP, XML, SOAP, UDDI, WSDL.

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

Поддерживаемые форматы: HTTP, XML, SOAP, UDDI, WSDL и др.

Компонентное программирование в. NET. Компоненты – это:

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

• в целом более крупные, чем объект (объекты – конструкции уровня ЯП);

• могут содержать множественные классы, которые реализуют большое количество объектов;

• независимы от языка реализации.

В общем случае разработчик и пользователь компонента территориально разделены и пользуются разными языками программирования в единой среде. NET.

Компонентная объектная модель (COM):

• основной стандарт Microsoft для компонентов;

• содержит протокол для инициализации и использования компонентов внутри одного процесса, между процессами или между компьютерами;

• основа для ActiveX, OLE и многих других технологий взаимодействия;

• поддерживается в Visual Basic, C++, NET и др.

Модель Java Beans:

• основной стандарт Sun Microsystems для компонентов;

• зависима от языка реализации.

Сравнение компонентно– и объектно-ориентированного программирования.

Основные понятия объектно-ориентированного программирования:

• класс (class);

• интерфейс (interface).

Основные понятия компонентно-ориентированного программирования:

• свойство (property);

• событие (event);

• сборка (assembly).

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

Наиболее существенные недостатки. NET:

1) высокие требования к аппаратному обеспечению (минимум 256M RAM, 10G HDD для работы с Microsoft Visual Studio.NET);

2) сложности работы с некоммерческими релизами программного обеспечения (некоторая неустойчивость, отсутствие полномасштабной документации); сервис – это не всегда надежно и предсказуемо. Не всегда имеется документация. Некоторые языки не до конца стандартизованы, а некоторые не до конца реализованы как продукты;

3) поддержка ряда теоретически интересных и практически полезных языков программирвоания не в полном объеме (SML для Visual Studio.NET – в процессе реализации);

4) инструментарий. NET и компиляторы для языков программирования не ратифицированы по международным стандартам.

Платформа. NET – выводы.

1. Стратегическая идеология – это и технологическая платформа, и подход, который определяет стратегию Microsoft на ближайшее десятилетие.

2. Несомненное качественное превосходство над аналогами (Borland Delphi, Microsoft Visual Studio и др.) за счет:

• интероперабельности и межъязыкового взаимодействия;

• многоуровневой безопасности, SDL, безопасности на уровне компонентов;

• интеграции с веб-сервисами;

• облегчения разворачивания и использования.

3. Завершенность решения для широкого коммерческого использования в силу концептуальной новизны и грандиозности проекта.

4. NET – развитие платформы Windows, которое позволяет осуществлять компонентное проектирование.

5. NET – фундамент для создания корпоративных приложений нового поколения.

6. Основа. NET – принцип компонентной интеграция приложений на уровне сервисов, взаимодействующих посредством языка XML и протокола SOAP.

7. Стратегическая цель. NET – создание программной инфраструктуры для разработки и функционирования распределенных приложений на базе интернет-стандартов.

Глава 9 Разработка интерфейсов корпоративных систем по технологии Windows Forms

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

Когда говорят о корпорации, речь идет о территориально распределенной структуре, которая решает общие бизнес-задачи. Компании этой структуры отстоят далеко (территориально), но тем не менее необходимо обеспечить функционирование приложений корпоративных систем. Для этого используются разные технологии, в частности Remoting, также Windows Communication Foundation, технологии, связанные с веб-сервисами, которые реализуют решение как сервис, последовательно предлагаемые и реализуемые Microsoft в подходе. NET.

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

Прежде всего следует обсудить технологии построения интерфейсов на основе специализированных библиотек ввода данных. Задача ввода данных является нетривиальной, поскольку сотрудники корпорации должны интуитивно достаточно хорошо представлять себе, каким образом происходит ввод данных, и осуществлять его без коррекций, противоречий и дублирования. Интерфейсы должны быть эргономичны. В Microsoft сейчас работает, пожалуй, лучшая команда по usability. Большое количество пользователей во всем мире общается с ОС семейства Windows, офисными приложениями семейства Office, и эти интерфейсы им близки и естественны.

Рассматривая технологии Microsoft для ввода данных, представления данных и отчетов, следует сосредоточиться на технологии Windows Forms, которая служит не только для ввода данных, но и для построения отчетов. Одной из целей корпоративных систем является подготовка консолидированной отчетности, которая дает руководству возможность эффективно управлять корпорацией на основе динамики людских и финансовых ресурсов, основных средств, специализированных ресурсов (нефть, газ) и т. д. Здесь очень важны интерфейсы, их элементы, способы построения – все то, что дает возможность в интуитивно-явном режиме получать, интегрировать, консолидировать информацию и производить те самые формы вывода (отчеты) из интегрированных и гетерогенных систем, которые и учитывают различные корпоративные ресурсы. Информация об этих ресурсах в ряде случаев представляет собой не только хорошо структурированные данные, но и аудио-, видео-, отсканированные документы. Да и в случае структурированных документов они могут быть представлены в виде других приложений, и нам нужно объединять информацию из интернет-браузера (как тонкого клиента), из офисных приложений Word, Excel и строить достаточно сложные отчетные формы. Некоторые из них будут рассмотрены в данной главе.

Итак, технология Windows Forms. Что она включает? Какие инструменты важны? Постараемся сосредоточиться на инструментах для корпоративных приложений, в частности на примере построения элементарной формы. Пример будет включать фрагменты кода, что позволит нам понять, как корпоративные системы реагируют на события, происходящие в программной среде. Они могут быть инициированы как пользователем, так и ОС Windows и, естественно, корпоративными приложениями.

Прежде всего рассмотрению подлежат основные понятия, связанные с технологией Windows Forms. Это определение, что такое формы как программные объекты, каким образом осуществляется взаимодействие с ними, технология умных клиентов Smart Clients и др. Следует отметить, что Windows Forms дает возможность взаимодействовать с клиентами в интерактивном режиме, что предполагает свободу и высокую степень вовлеченности пользователя в систему и взаимодействие с элементами интерфейса, знакомыми нам по офисным приложениям, такими как командные кнопки, контекстное меню и др.

Речь идет о том, что в одном из пространств имен, надстроенном на. NET Framework, над базовыми классами. NET существует серьезная и большая по объему коллекция классов, которые представляют собой элементы интерактивных элементов Windows Forms, некоторые из них были перечислены выше. Рассмотрим более подробно, как выглядит интерфейс CASE-средства Visual Studio и как осуществляется визуальное проектирование интерфейсов с использованием этого средства. Далее будет описано понятие «событие» в среде Windows применительно к корпоративным приложениями, обсудим, каким образом осуществляется обработка событий, т. е. создание программного кода на языке C# на платформе. NET, которая осуществляет реакцию на действия пользователя в направлении элементов управления, т. е. тех элементов, которые составляют элементы формы и отчетные формы, – библиотеку классов Windows Forms. Рассмотрим классификацию элементов управления Windows Forms и познакомимся с категориями, включая выпадающие списки, элементы, связанные с веб-интерфейсом, построением таблиц для отчетов баз данных и сложных отчетных форм, включающих гетерогенную информацию, например таблицы Excel. Пользователь имеет возможность не только использовать наперед определенные классы, библиотеки Windows Forms, но и создавать, в том числе на их основе с использованием концепции наследования в среде Visual Studio, собственные элементы управления. Зачем это необходимо пользователю? Заметим, что в Windows Forms существует достаточно большое количество предопределенных классов, с помощью которых можно создавать интерфейсы, и код событий уже предопределен. Но если существует необходимость создавать специализированные системы с расширенными возможностями, у пользователя также есть выбор и свобода это сделать. Также рассмотрим специализированный инструмент Windows Forms Designer, являющийся частью среды разработки Visual Studio.NET. Познакомимся с его возможностями и посмотрим, насколько удобно им пользоваться для создания Windows-приложений. Подводя итоги, мы рассмотрим важные аспекты, которые связаны с особенностями и преимуществами для таких сфер, как отображение данных и манипулирование данными, включая взаимодействия с СУБД SQL Server.

Другая особенность Windows Forms – это важность использования этой технологии для быстрого развертывания приложения. Microsoft последовательно применяет концепцию создания, тиражирования и развертывания корпоративных приложений, которые требуют поддерживать стратегию минимизации стоимости развертывания. Ведь если речь идет о развертывании, количество мест очень велико – десятки и сотни тысяч. Поэтому эффективное, быстрое, надежное, единообразное развертывание приложений, в идеале вообще без оператора, разработчика и администратора, является очень полезным решением, сокращающим стоимость системы. Microsoft реализует стратегию ClickOnce – одним щелчком быстро и надежно разворачивать приложения в корпоративной среде. Это тоже одно из преимуществ, реализованных на основе Windows Forms.

Итак, что такое Windows Forms? Это технология Microsoft, являющаяся надстройкой над. NET Framework – базовым семейством классов. NET и, по сути, это набор объектно-ориентированных библиотек – семейство классов, которые облегчают дизайн приложений и их интерфейсов. В первую очередь это ввод данных, вывод отчетов, использование файловой системы. То есть реализация интерактивных пользовательских интерфейсов. Каковы основные возможности приложений Windows Forms? Речь идет о создании компонентов на основе базовых классов, реализованных в этой библиотеке, т. е. о надстройках в приложении, о программной надстройке над. NET Framework. Какие возможности имеют эти приложения? Технология Windows Forms тесно интегрирована с Microsoft.NET. Более того, используется инструмент Form Designer, который позволяет нам быстро осуществлять построение программных интерфейсов. Прежде всего, пользователи получают возможность вывода данных и построения отчетов, обмена информацией с удаленными компьютерами по сети через Интернет или посредством сетевого соединения. При этом применяется технология Smart Client, строятся специальные приложения, использующие технологию обмена по сети этим специальным способом, не имея информации о пользователе, который запрашивает данные. Подробнее эта технология будет рассмотрена позже.

Итак, какие базовые элементы включает технология Windows Forms? Другими словами, какие интерфейсные элементы содержатся в этой библиотеке классов? Отметим важные особенности – все эти элементы являются интерактивными, т. е. дают возможность пользователю взаимодействовать с элементами управления, входящими в состав форм.

Определим понятие «форма». Форма – это поверхность, которая визуально доступна пользователю, где отображается информация, необходимая ему. Под пользователем подразумеваются различные классы бизнес-пользователей, топ-менеджеров, нуждающихся в консолидированной информации на уровне корпорации или отдельного региона об управлении людскими и финансовыми ресурсами. Рассматривая пользователей более низкого ранга, можно детализировать информацию до определенного уровня подразделения – департамента, отдела, вплоть до сотрудника. Кроме того, в корпорации существует большое количество администраторов сети, пользовательских приложений, баз данных, которые тоже являются пользователями и применяют эту технологию каждый день на своем рабочем месте.

Еще одним важным элементом Windows Forms является элемент управления, или Control. По сути, это некий атом функциональности пользовательского интерфейса. Скажем, элементарная командная кнопка, или переключатель, или флажок, или строка ввода данных, которая предназначена для ввода или отображения данных, является достаточно примитивным элементом библиотеки Windows Forms и надстраивается над. NET Framework. Windows Forms – это некий класс, который представляет собой с точки зрения программирования код на языке C# и во многом для удобства бизнес-пользователей строится визуально, поскольку речь идет о достаточно сложных манипуляциях графическими объектами, достаточно сложным и ресурсоемким по времени занятием является ручная настройка формы. Если мы будем выверять форму и ее размеры вплоть до пикселя, процесс проектирования займет огромное время (если вводить линейные размеры вручную, код каждого управления и т. д.). Конечно же, визуальное создание приложений, особенно с таким приятным и удобным интерфейсом, который предоставляет Visual Studio.Net, является предпочтительным. Таким образом, создание элемента Windows Forms происходит так: сначала рисуется форма – прямоугольный объект, после этого на форму (как бы поверх) набрасываются, добавляются с помощью drag&drop (как фишки на игровое поле) те или иные элементы управления. Они упорядочиваются, при этом все это тоже происходит визуально. И все необходимые атрибуты для управления формой производятся автоматизированно в средстве Visual Studio.Net. Кроме того, определены базовые сценарии действий для основных событий, которые может инициировать пользователь, такие как щелчок мыши, двойной щелчок, нажатие клавиши, drag&drop, горячие клавиши и др.

Теперь рассмотрим, как выглядит визуальный интерфейс в Visual Studio.Net в Windows Forms. Скриншот Visual Studio при создании формы представлен на рис. 9.1.

Рис. 9.1. Интерфейс Visual Studio.NET

Итак, сначала создали элементарную форму Form1.cs, т. е. код, который описывает все ее детали – линейные размеры, имя, ряд других аспектов. В частности, можно заметить, что на ней расположена командная кнопка button1. Все это задается автоматически при перемещении кнопки из репозитория основных элементов формы, доступных в Visual Studio. Как только создали форму, становятся доступными и стандартные кнопки, к которым мы привыкли в Windows, – минимизация формы, разворачивания на весь экран, закрытия. И, естественно, все коды, связанные с событиями, доступны автоматически, и этот код уже существует.

В окне Solution Explorer мы видим, что нами создан код Form1.cs – это код на C#. А в правом окне мы видим все метаданные. У этой формы есть файл designer, файл ресурсов – res, где описаны все метаданные, и есть окно свойств, где описаны основные параметры этой формы. В частности, видно, что размер линейный в самом нижней строчке скриншота, является 300 на 300 точек. Кроме того, программный код создан на C# и описывает все действия, которые будут производиться с этой формой. Рассмотрим, каким образом происходит управление событиями, связанными с формами, каким образом пользователь может осуществлять контакт с формой. Речь идет об обработке событий. При взаимодействии пользователя с формой, при визуальном ее изменении: щелчок на «свернуть», drag&drop, щелчок левой кнопкой мыши по кнопке Button1, и целым рядом других действий пользователя автоматически генерируется событие – Event. Приложение реагирует на событие с помощью кода. Существует некий код на C#, связанный с событиями. Он автоматически активизируется при обработке события.

В окне «Свойства» (Properties) на рис. 9.1 мы можем увидеть список событий, которые связаны с этой кнопкой. Интересно, что справа от имени кнопки button1 мы видим, что она расположена в пространстве имен System.Windows.Forms.Form1, т. е. в том классе, который описывает форму, и кнопка является ее атрибутом. Далее следует список событий. Например, событие click – однократный щелчок по Button1. Если мы откроем свойство, связанное с этим событием, мы можем просмотреть стандартный код и изменить его, если это необходимо.

В описании события «щелчок левой кнопкой мыши» по командной кнопке Button1 присутствует код, представленный на рис. 9.2.

Рис. 9.2. Код события «щелчок левой кнопкой мыши»

Возникает класс Form1, который является, по сути, подклассом стандартного класса Form, и внутри существует метод, также общедоступный, который называется Form1 – по сути конструктор. Он вызывает единственный метод InitializeComponent. Дальше отправляется событие, что форма начала существовать с некими аргументами, связанными с событиями этой формы (е). Это также фигурирует в окне свойств Button1.

Достаточно интересна полнота представления различных видов элементов управления для создания форм ввода данных и построения отчетов. Microsoft подходит к этому достаточно гибко и широко. На рис. 9.3 видно, что существует большое количество предопределенных элементов управления – Control, а в левом окне можно открыть панель управления – Toolbox. Это десятки предопределенных элементов Windows Forms. Таким образом, там содержится много элементов управления, которые перетаскиванием мыши можно разместить на форме. Это Poiner, командная кнопка, Checkbox-флажок и т. д. Различного рода метки – текст со ссылкой, выпадающий список и целый ряд других элементов. Скажем, существует командная кнопка, которую можно представить как изображение. Progress Bar, т. е. индикатор некоторого процесса, к примеру загрузки файла через Интернет. Radio кнопка – переключатель. Rich text box – мини-текстовый редактор, который также доступен изначально как готовый элемент управления. Интересно, что даже веб-страница существует как готовый элемент управления.

Рис. 9.3. Набор предопределенных элементов управления

Кроме тех элементов, которые были перечислены, пользователь может создать свои элементы. Для этого используется специальный класс user control. Естественно, можно использовать те классы, которые уже предопределены в. Net, конкретно в Windows Forms, в пространстве имен System.Windows.Forms и на основе классов – каждый элемент управления является классом – можно создавать собственные элементы управления, добавляя и убавляя свойства.

Для создания собственных форм и элементов управления и коррекции их в визуальном режиме используется средство Windows Forms Designer. Это компонент, встроенный в Visual Studio. Он позволяет создавать свои формы путем комбинирования элементов управления. Существует возможность выравнивания без особых затрат труда, поскольку это происходит визуально. В связи с этим есть возможность построения интерактивных интерфейсов, поскольку пользователь может взаимодействовать с ними посредством событий, и интеграция с Microsoft Office. Это интерфейс, который основан на знакомых нам приложениях и ОС Windows, и MS Office. Скажем, существуют элементы управления Tool strip и Menu strip, как в Word. Это может быть представлено как в форме меню, так и в форме инструментов – командных кнопок. По сути, они уже существуют в виде примитивов в пространстве имен и могут быть использованы в нужной конфигурации и автоматически собраны при просто визуальном перенесении пользователем их на форму. Таким образом можно быстро создавать меню, глубокую вложенность подменю, которые могут содержать и другие элементы управления.

Как упоминалось ранее, пользователь может создавать собственные элементы управления, для этого используются классы, содержащиеся в System.Drawing. Напомним, что структура. NET Framework достаточно четко разграничена. Прямо на форме можно осуществлять прорисовку или выполнение несложных иллюстраций, скажем, рисовать линии, прямоугольники, овалы и т. д. В Word тоже есть панель рисования. Очень важным является вопрос интеграции данных из гетерогенных источников. В части корпоративных приложений речь идет о гетерогенных системах, которые могут включать как хорошо структурированную информацию, так и плохо структурированную – видео, аудио, сканы. К каждому фотоизображению прилагается информация о том, когда была сделана фотография, каким фотоаппаратом, каков ее размер. При этом Windows Forms имеет специальный элемент управления DataGrid-View, чтобы из гетерогенных источников можно было извлекать данные и формировать отчеты. При этом могут быть использованы разные источники данных – БД: SQL Server, Access. Позже мы посмотрим, как выглядит отчет в DataGridView. Это представление среза данных, которое хешируется и хранится на клиентской части приложения и необязательно отражает актуальное состояние базы данных. Можно брать данные из специализированных данных формата XML, веб-сервисов и т. д. Какие возможности получает пользователь при работе с этим сложным элементом управления? Какие потери могут быть понесены, если попытаться создавать его самостоятельно? Мы можем динамически менять размер строк и столбцов, фиксировать их, настраивать представление, цвет фона, шрифта и т. д. Наконец, можно осуществлять отображение сложных объектов внутри каждой ячейки – не только текст, но и фото, видео. При этом внедрение на форму элемента управления DataGridView происходит стереотипно и так же легко для пользователя, как и размещение элементарной кнопки – drag&drop из репозитория на форму.

Очень важным при этом является свойство Entry Point – связь с гетерогенным источником данных – различной природы. Это могут быть хорошо структурированные реляционные данные, гетерогенно представленные в хранилище данных на основе xml метаданных.

Еще одной технологией, которая активно используется в связи с WinForms, является технология интеллектуальных клиентов SmartClients. С помощью этой технологии есть возможность взаимодействия с источником данных через сетевое соединение (через интернет-канал). Это крайне важно для корпоративных систем, так как дает возможность получения корпоративных данных через Интернет из любой точки земного шара. Для корпорации значение этой технологии трудно переоценить. На рис. 9.4 показан компонент BindingSource, мы видим его в Solution Explorer и в левом окне, которое представляет собой Design View, т. е. визуальное представление формы. Данный компонент дает возможность связать определенный элемент DataGridView с тем или иным источником данных, который позволяет нам извлечь гетерогенные данные той или иной природы (мы уже описывали виды источников данных, которые используются) и разместить их в форме.

Рис. 9.4. Компонент BindingNavigator

Компонент BindingSource является частью среды Microsoft.NET Framework и позволяет управлять целым рядом параметров взаимодействия корпоративного пользователя с источником данных. Это такие характеристики, как параметры соединения с источником данных, организация связи данных, которые извлекаются из того или иного источника с элементами управления (например, с ячейкой DataGridView), с определенными текстовыми элементами, скажем, многострочный вывод, однострочный и т. д., веб-страница, навигация между записями источника данных, если этот источник возможно представить в виде нескольких записей, например файл или таблицу в базе данных, редактирование записей источника данных – можно вносить через сетевое соединение изменения в данные на этом удаленном источнике и записывать изменения в источник данных.

Здесь есть достаточно серьезная проблема, связанная с управлением транзакциями, поскольку корпоративных пользователей, которые занимаются редактированием или просмотром объекта одновременно, достаточно много. Возникает вопрос: какие изменения и в какой последовательности записывать и как они будут отражены? Оптимально при правильном управлении транзакциями пользователь должен воспринимать информацию в параллельном режиме с другими пользователями, как будто он взаимодействует с базой только один. BindingSource и технология SmartClients во многом, естественно вкупе с другими технологиями, позволяют решить эти проблемы. Кроме того, существует элемент управления BindingNavigator, который дает возможность разработчикам использовать данный интерфейс для визуальной обработки записей данных из гетерогенных источников через сетевое соединение. На рис. 9.5 показан пример применения BindingNavigator и его размещение на Windows Form (на форме Form1 в данном случае) и организации визуального интерфейса с гетерогенным источником данных. При этом используется компонент BindingSource, построен конкретный пример объекта этого класса, который называется BindingSource1 и присутствует как в Solution Explorer, так и в Design View.

Рис. 9.5. Применение BindingNavigator

Другой способ связи основан на взаимодействии приложений и называется Application Settings. Это тоже подход SmartClients, использующий Windows Forms. Форматом хранения данных является XML. Файл описывает состояние приложения и фиксирует такие параметры, как линейные размеры формы на экране, персональные предпочтения пользователя, какие элементы и в каком положении он хочет видеть на форме, как, скажем, мы можем создать «мой Яндекс», упорядочить или определить свои предпочтения по тому, каким образом представлены элементы управления и в каком порядке они расположены на Яндекс-баре или других элементах интерфейса, можно изменить место хранения файлов по умолчанию и целый ряд других параметров. При этом во время выполнения приложения возможна автоматическая загрузка в память элементов данных и фактически осуществление кэширования информации на клиенте.

Теперь следует рассмотреть, каким образом это происходит визуально, как осуществляется работа с гетерогенными источниками данных на основе Application Settings. Сначала создается элемент управления Application Settings, в Solution Explorer – Properties появляется описание метаданных, которые связаны с Application Settings, здесь есть параметр PropertyBinging и ряд параметров, которые показывают связи с целым рядом атрибутов конкретного приложения. Есть параметры, описывающие линейные размеры, – Margin, Location, шрифт, местоположение файлов и т. д. Таким образом, на форме можно в динамическом режиме конкретизировать параметры источника данных, из которого извлекается информация. При извлечении данных из приложения необходимо использовать параметр Location, чтобы увидеть, как они отображаются в визуальном интерфейсе.

Важным аспектом корпоративных систем, который обеспечивает сокращение совокупной стоимости владения, является технология экономичного развертывания приложения. Ранее была рассмотрена технологии ClickOnce, которая позволяет быстро и в ряде случаев одним щелчком мыши и без участия специалистов по администрированию систем на уровне пользователя осуществить установку стандартных компонентов корпоративных приложений. Под развертыванием стоит понимать установку пользователем на клиентском компьютере – своей машине. Это может быть ноутбук, рабочая станция, смартфон или коммуникатор, т. е. некое клиентское устройство, для которого существует. NET Framework и соответствующие компоненты, объектные библиотеки и прикладные интерфейсы. Естественно, речь идет о том, что приложение может быть установлено после того, как оно разработано и для последующего использования. При реализации концепции быстрого развертывания приложения существуют проблемы. Это прежде всего массовая рассылка обновлений. Естественно, в корпорации функционирует далеко не одна информационная система. В каждом офисе существует большое количество гетерогенных информационных систем, при этом каждая система имеет некий номер версии, и отслеживание взаимосвязи этих версий – достаточно сложный процесс. Для этого используется специальное ПО – контроль версий: нужно отслеживать возможность согласованного использования компонентов этих приложений и, естественно, тех дополнений, доработок, которые разработаны для этих приложений с целью обеспечения их взаимной совместимости. Достаточно сложно – если речь идет о десятках тысяч пользователей – упростить рассылку обновлений и установку приложений. Если предположить, что каждый пользователь должен тратить 5 минут в день для установки приложений и их согласованной работы, получим тысячи человеко-часов. Чтобы этого избежать и повысить отдачу от использования приложений и снизить стоимость владения, Microsoft разработала ClickOnce – по сути, механизм сборок, описание кода, компонентов корпоративных систем с точки зрения как хранимых данных, так и метаданных, которые требуются этим сборкам, и, естественно, политики безопасности. Технология ClickOnce позволяет достаточно просто и быстро развертывать приложения при наличии Visual Studio и. NET одним или несколькими щелчками мыши, без ввода данных с клавиатуры, т. е. стандартным образом. Пользователь практически не может запутаться, повести себя двусмысленно – есть только один путь установки приложения, прямой и простой, и за короткое время без участия администратора пользователь может установить и настроить дополнение к приложению, как мы устанавливаем дополнения к приложению в Windows или Office.

Именно поэтому еще одним достоинством является интернет-ориентированность. Пользователю необязательно получать весь код, просто URL-ссылку на веб-сервер, на котором хранится код приложения в форме сборки. И после щелчка мыши по установке сборка сама, вместе с технологией ClickOnce, определяет возможность установки, программной среды, версии сборки, подлинность сборки, уровень безопасности, и в соответствии с политикой безопасности осуществляется установка дополнения на клиентский компьютер. Продолжим описание преимуществ технологии Click-Once. Поскольку вся информация о компоненте приложения локализована в сборке, осуществляется унификация управления как элементами данных, так и зависимостями. Для корпоративной системы сложно переоценить значение сборки как средства управления зависимостями между компонентами приложения. Автоматически осуществляется определение возможности установки, сборки в программную среду пользователя, притом что программное окружение пользователя является сложным и гетерогенным и производится или не производится установка. Осуществляется проверка корректности установки – удалось/не удалось и почему. Если установить продукт не удалось, пользователь может обратиться к администратору и четко передать то сообщение, которое на экране свидетельствует о том, что версия сборки не соответствует версии программной среды. Более того, возможно автоматическое обновление приложения на основе информации из Интернета. Также автоматическое обновление осуществляется практически без участия клиента, если клиент подтверждает возможность осуществления такого обновления в принципе. Кроме того, при обновлении приложения разработчику, который осуществляет коррекцию кода в терминах сборки, достаточно опубликовать новый манифест, т. е. метаданные сборки по указанному URL. Следовательно, не нужно тиражировать на все компьютеры пользователя и заботиться о совместимости программной среды того компонента, который вновь разработан, и того, что имеется у пользователя. Каким образом осуществляется публикация изменений или вновь разработанных корпоративных приложений иллюстрирует рис. 9.6. Здесь речь идет о размещении приложения на локальном компьютере, тем не менее это можно сделать и на FTP– и HTTP-сервере при наличии соответствующих прав доступа. Кроме того, если мы один раз указали местоположение, то именно по этому местоположению будет производиться размещение последующих апдейтов, сервис-паков, патчей и т. д. Именно этот интерфейс и использует Publish Wizard, т. е. средство упрощения развертывания приложений. Эта технология основана на подходе ClickOnce, при этом пользователю также достаточно выбрать автоматизированное обновление, и при помощи технологии ClickOnce осуществляется обновление приложений, пополнение, коррекция в автоматизированном режиме.

Рис. 9.6. Публикация разработанного приложения

Какие особенности имеет смысл отметить в Windows Forms в связи с перечисленными задачами по поддержке корпоративных приложений? Прежде всего это высокая степень интерактивности. Ранее описывалось, каким образом осуществляется интеграция приложений, каким образом поддерживаются такие сложные элементы управления, как DataGridView, каким образом пользователь может получить доступ к гетерогенным источникам информации для работы с базами данных, для работы со слабоструктурированной информацией (аудио, видео). Кроме того, поддерживаются окна, ведение диалога, возможен диалог пользователя системы, общение в интерактивном режиме, сценария взаимодействия пользователя с корпоративной системой. Windows Forms поддерживает элементы управления печати корпоративных интерфейсов с WYSIWYG интерфейсом, с помощью интеграции с офисными приложениями. Естественно, интерфейс при этом выглядит привычным пользователю образом, поскольку поддерживаются традиционные командные кнопки, пункты меню и т. д. Можно достаточно легко оснастить компоненты справочной информацией, т. е. онлайновой справочной системой с возможностью гипертекстовых ссылок, контекстного поиска и т. д., как мы видим в Windows и Office, можно добавлять документацию к формам и т. д., можно достаточно легко осуществлять локализацию приложения, перевод на другой язык – важно использование кодировки в Unicode. Кроме того, поддерживаются различные единицы измерения (метры, футы), различные валютные системы (рубли, доллары, евро и т. д.). И еще одна важная особенность Windows Forms: поскольку это надстройка на. Net Framework, можно использовать встроенную систему информационной безопасности, которая основана на реализации механизма сборок. Каждая сборка имеет метаданные, в которых описываются, в частности, автор, версия, цифровая подпись. То есть сборку достаточно сложно подделать или использовать вне контекста приложения, поскольку автор достаточно однозначно определяется сборкой, и сборка, если она подделана, не подойдет, не сможет быть установлена в корпоративную систему и каким-то образом повредить ее целостность, надежность и т. д.

Итак, подводя итоги обсуждения технологии Windows Forms, технологии, поддерживающей эргономичный интерфейс корпоративных приложений, можно сделать следующие выводы. Во-первых, эта технология поддерживает высокую интерактивность, сценарную обработку данных, т. е. обработку данных на основе событий с высокой вариативностью – сценарии эти могут быть достаточно гибкими и адекватно реагирующими на самые разные действия пользователя. Windows Forms имеет огромное количество различных элементов управления, которые позволяют строить достаточно сложные и одновременно привычные пользователю и понятные ему элементы интерфейса – это DataGridView, командные кнопки, элементы меню и т. д. Пользователь в связи с этим получает возможность работать с корпоративными системами предсказуемым образом, повышает свою производительность и, следовательно, производительность труда в корпорации. Кроме того, осуществляется возможность доступа к гетерогенным источникам информации, что важно для корпоративных пользователей, в первую очередь посредством удаленного доступа. Пользователи получают возможность доступа к гетерогенным источникам данных, а также к аудио– и видеоинформации на основе XML-представления. И что очень важно, они имеют возможность агрегировать эту информацию, получать ее в едином интерфейсе, т. е. в гетерогенном отчете может быть представлен как текст, извлечение из отчета базы данных на основе запроса, так и определенная фото– и видеоинформация, которая извлечена из хранилищ данных. Технология Windows Forms позволяет без особых затрат производить обновление, коррекцию, усовершенствование отдельных компонентов программных систем и программных систем в целом. Пользователь получает возможность автоматического обновления, если осуществляется подписка на это обновление, поскольку Windows Forms является надстройкой на. NET и поддерживает все политики, протоколы шифрования данных, протоколы взаимодействия, в том числе по Интернету, которые реализованы для. NET Framework.

Итак, была рассмотрена технология Windows Forms, которая предназначена для создания эргономичных пользовательских интерфейсов корпоративных систем. При этом упоминалось, что эта технология поддерживает распределенные взаимодействия пользователей с гетерогенными источниками данных на основе таких элементов, как BindingSourceNavigator, и подобных средств организации доступа к гетерогенным источникам корпоративной информации. Теперь обсудим, каким образом осуществляется создание и поддержка распределенных приложений на платформе. NET, какие технологии используются. Прежде всего, речь пойдет о веб-сервисах и о технологии Remoting. Последняя разработана Microsoft, является достаточно жесткой, но тем не менее обеспечивает высокую безопасность и надежность приложений, что весьма важно для корпоративных систем. Обсудим ее в связи с другими технологиями сетевого взаимодействия компонентов распределенных приложений в корпоративной интернет-среде.

Во-первых, рассмотрим общий принцип функционирования распределенных приложений, а также их основные особенности, в которых явно выделяются роли клиента и сервера. Клиент и сервер – это не обязательно аппаратное обеспечение, это не обязательно один и тот же компьютер. Сервер может быть распределен по нескольким компьютерам – это, скорее, логические объекты. Мы рассмотрим различия и основные особенности веб-сервисов по отношению к технологии Remoting. Далее речь пойдет об основных понятиях, которыми следует оперировать при определении распределенных приложений. Рассмотрим низкоуровневые средства для работы с сетевыми приложениями и еще раз вернемся к технологии клиент-серверного взаимодействия для построения распределенных приложений корпоративного типа. Очень важна, особенно в связи с Remoting, процедура удаленного вызова процедур (RPC). Это важная технология, которая исторически достаточно рано возникла и, по сути, реализует базовую схему взаимодействия распределенных приложений, в том числе в интернет-среде. Мы обсудим, каким образом осуществляется компонентное проектирование и программирование в среде. NET, центральным понятием идеологии. NET является компонент, синонимом компонента выступает сборка.

По сути, проектирование корпоративных приложений как раз и ведется в терминах компонентов. При этом пользователь или заказчик получает строго определенное корпоративное приложение, собранное по заказу именно из тех компонентов, которые нужны для получения пользователем требуемой им функциональности. Таким образом пользователь может гибко определять необходимую функциональность и экономить средства именно за счет выбора строго определенных компонентов корпоративных приложений. Мы рассмотрим технологию Web Forms в связи с Windows Forms, которые мы рассмотрели раньше, т. е. те формы ввода данных и получения отчетной информации, которые предназначены специально для интернет-взаимодействия, и посмотрим сходства и различия с Windows Forms.

Итак, перейдем к процедуре построения корпоративных распределенных приложений на основе технологии Remoting и других технологий, связанных с веб-сервисами и клиент-серверной архитектурой. Общий принцип построения подобных систем заключается в следующем: объекты или модули распределенного приложения в случае компонентного подхода к проектированию (компоненты или сборки) располагаются физически на нескольких компьютерах и логически – в нескольких процессорах ОС. За счет специализации выделяется слой бизнес-логики, который реализуется на клиентской части и на сервере. За счет этого оптимизируется производительность клиента и сервера и осуществляется взаимодействие элементов распределенного приложения в наиболее выгодном режиме для пользователей, по сути, оптимизируется производительность программной системы, время реакции, производительность пользователей.

Какие основные понятия характеризует веб-сервисы и технологии Remoting? Технология Remoting является достаточно жесткой по сравнению с общей методологией веб-сервисов. Microsoft продвигает принцип предоставления ПО как сервиса, поэтому понятие веб-сервиса не только не чуждо методологии. NET, но и является одним из ее основных компонентов. Веб-сервисы представляют собой слабосвязанную модель взаимодействия объектов на основе общедоступных мировых стандартов. Это в первую очередь протоколы взаимодействия HTTP, SMTP. Веб-сервисы независимы от языка программирования, в отличие от Remoting. Еще очень важно, что веб-сервисы поддерживают модель работы с объектами без сохранения внутреннего состояния. То есть объекты, по сути, не имеют памяти о своей истории. Подход. NET Remoting является более строгим, более жестким, нацеленным исключительно на среду. NET, т. е. прежде всего на ОС Windows. Конечно, NET поддерживается и для узкого круга Unix-систем, в рамках проекта mono, но в целом ориентация преимущественно на. NET и Windows. Кроме того, модель нацелена на более эффективное и безопасное выполнение объектов в. NET, так как содержит встроенную систему безопасности, она поддерживает сборки и подписи, алгоритмы шифрования, поддерживаемые средой. NET. Таким образом, реализуется сильно связанная модель, которая поддерживает память, т. е. состояние объектов, и обеспечивается более эффективное взаимодействие объектов в среде. NET. При этом объекты располагаются на разных компьютерах и в разных процессорах.

При исследовании слабо и сильно связанных (Loosely Coupled и Tightly Coupled) моделей распределенных приложений нужно отметить, что модель Loosely Coupled, также как и Tightly Coupled, предназначена для распределенных приложений. Различие состоит в более свободном выборе протоколов и отношении к сохранению состояния, которое используется в последнем подходе. Loosely Coupled модель подразумевает построение распределенных приложений на основе минимального набора приложений и взаимодействий. Tightly Coupled подход подразумевает более жесткую связь, более строгую однородность частей приложения и в отличие от Loosely Coupled основан на заранее согласованных более строгих протоколах и наборах данных. Loosely Coupled подход использует стандартные протоколы XML и HTTP. Что касается модели взаимодействия объектов, то здесь распределенные объекты взаимодействуют без сохранения памяти о своей истории. Таким образом, с точки зрения ООП можно конкретизировать подход взаимодействия клиента и сервера без сохранения состояния тем, что каждый вызов метода обрабатывает новый экземпляр объекта, который создается заново. В отличие от похода, связанного с наличием состояния, не меняется состояние объекта со старого на новое, а просто создается новый экземпляр объекта.

Что касается работы с сетью, позднее мы увидим, каким образом это связано с пространством имен Remoting. Напомним, что существует пространство имен System, внутри которого находится пространство. NET, а потом —.Sockets (рис. 9.7). Первое подпространство определяет основные параметры источников взаимодействия, т. е. таких точек взаимодействия на клиенте и сервере, как пространство доменных имен, характеристики точек взаимодействия и т. д. И пространство имен Sockets определяет более детально характеристики клиента и сервера, которые связаны с конкретным протоколом, скажем TCP/IP, и построением потока данных для обмена сетевой информацией.

Рис. 9.7. Иерархия пространств имен

Глава 10 Технологии сетевого взаимодействия корпоративных систем

Рассмотрим эволюцию технологий сетевого взаимодействия распределенных приложений и построение такого рода приложений. Одной из наиболее ранних технологий является удаленный вызов процедур – Remote Procedure Call. Во многом эта технология реализуется в Remoting при маршеринге, который будет рассмотрен несколько позднее. Еще одним подходом была передача сообщений, т. е. взаимодействие между распределенным приложением, между объектами. В одном из первых вариантов она называлась DCE – Distributed Computing Environment. Если рассматривать взаимодействие клиента и сервера, концепция открытых систем предполагает явное распределение ролей на клиент и сервер. При этом клиент – это компьютер, который осуществляет преимущественно запрос информации, в данном случае это вызов функции, которая на самом деле обращается к серверу, хотя это очевидно только из ее названия. Сервер осуществляет поиск, получение и предоставление отчетной информации для клиента в соответствии с его запросом. Кроме того, вспоминая главу об архитектуре, заметим, что помимо двух слоев клиент-серверной архитектуры (клиента и сервера), существует еще промежуточный слой, который предназначен для локализации взаимодействия. Но пока рассмотрим уровни клиента и уровни сервера.

Идея взаимодействия состоит в том, что функция, которая в данном случае называется Server Func, формально при чтении кода не должна вызывать ассоциации с сервером. С точки зрения клиента, осуществляется как бы выполнение этой функции. Функция имеет два параметра – символьный Hello и целочисленный 123. И результат должен быть присвоен некоему объекту J. На самом деле на клиенте функционирует специальный слой, который называется промежуточным и транслирует при переводе этой программы в промежуточный код из так называемого верхнего слоя (Top Layer), представляющего собой исходный текст на том или ином языке программирования (в данном случае это язык С), который транслирует этот вызов в некий внутренний вызов и упаковывает его нужным образом. Этот специализированный механизм называется Proxy-клиент. Он осуществляет трансляцию и упаковку этого вызова процедуры в обращение к другому компьютеру (серверу) с нужными параметрами, которые переупаковываются, меняют свои имена. Происходит передача некоего указателя на область памяти (*str) и некоего целочисленного значения v, с кодом, который у нас имеется на клиенте, осуществляется передача его после соответствующей упаковки серверу, Stub серверу, т. е. специальный функциональный компонент сервера осуществляет преобразование этого запроса во внутренний запрос сервера, организацию процедуры, заданной клиентом, и активизацию этой процедуры на сервере с заданными параметрами. Вычисление значений с переданными аргументами происходит путем подстановки вместо параметров их значений. Вычисление связано с работой процедуры на сервере. После этого осуществляется обратная упаковка и передача клиенту в ответ на его запрос. На нижнем уровне (Bottom Layer) осуществляется передача данных по сети на соответствующем уровне. Ниже находятся все последующие протоколы сетевого стека.

В ходе обсуждения взаимодействия RPC – это один из весьма важных механизмов взаимодействия по сети, который принципиально важен для понимания технологии Remoting. Осуществляется взаимодействие между Proxy и Stub. Proxy – это подпрограмма, которую может вызывать клиент на сервере. Поэтому технология называется процедурой удаленного вызова. Proxy передает серверу запрос на вызов подпрограммы, которая работает на сервере, с заданными параметрами, и ждет ответа от сервера. После выполнения процедуры результат возвращается клиенту. При этом вызов Proxy с точки зрения кода клиента не отличается от вызова внутренней подпрограммы или метода. Фактически эта логика взаимодействия удаленного вызова инкапсулируется внутри Proxy. Аналогично, но только на сервере, работает технология, связанная со Stub. Это тот код, который выполняется на сервере. Он получает от клиента запрос на вызов заданной подпрограммы. Осуществляется вызов подпрограммы, которая работает на сервере, а не на клиенте, как кажется клиенту. И результат, который записывается в переменную Result, автоматически после упаковки отправляется по сети на клиент. При этом Proxy и Stub создаются автоматически. Для этого, конечно же, требуется определенного рода описание открытых интерфейсов, т. е. сред взаимодействия между клиентом и сервером. Одним из примеров такого языка является IDL–Interface Definition Language, который используется в технологии брокеров объектных запросов (COBRA).

Итак, мы можем видеть три слоя взаимодействия, если абстрагироваться от сетевого уровня, где все просто описано с точки зрения кода, на уровне исходного текста программ – процедура на клиенте и процедура на сервере. На уровне Middle Layer происходит упаковка Proxy Stub клиента и упаковка параметров, выполнение процедуры на сервере после распаковки и передача упакованного результата через Middle Layer на клиент. Собственно, данные передаются на уровне Bottom Layer по протоколу передачи данных. Естественно, существует стек сетевых протоколов с целым рядом протоколов, которые лежат ниже перечисленных нами уровней процедурного взаимодействия.

Посмотрим, как осуществлялась революция объектных методов RPC в 1990-е гг. При этом объекты могут быть реализованы разными средами разработки и написаны на разных языках программирования.

Объектное RPC скрывает различия между объектами, которые разработаны в разных интегрированных средах и, возможно, на разных языках. В связи с этим сделан большой шаг вперед по сравнению с предыдущим подходом, который на самом деле достаточно жестко завязан на язык программирования. И, конечно же, по сути, объектного взаимодействия в 1980-е гг. в полной мере еще не было. При этом наиболее распространенными подходами следует считать подходы, основанные на компонентной модели COM c динамическим расширением Decom и COM+. И второй важный подход – CORBA. Это альтернативный подход, связанный с брокерами объектных запросов и использующий язык IDL, который описывает интерфейсы взаимодействия между различными объектами. Подход CORBA связан с Object Request Broker, которые реализуют функции, несколько похожие на Proxy и Stub, описанные ранее.

Принципиальной разницей между ранним RPC и объектным RPC является тот факт, что объекты инкапсулируют не только местонахождение, но и язык реализации, среду реализации. То есть в рамках подхода брокеров объектных запросов сервер получает указания о вызове заданного метода для заданного объекта. Брокер находит, получив указания о вызове метода, первый свободный сервер, изначально неизвестный, и тот объект, который может реализовать этот вызов, осуществляет вызов указанного метода посредством использования интерфейса этого объекта и возвращает результат клиенту. При этом важно, что клиент не представляет себе ни языка, ни платформы (т. е. операционной системы), что очень важно для подхода CORBA, этот подход нейтрален относительно операционной системы. Клиент не знает ни языка, ни платформы, где расположены запрашиваемые объекты. По сути, отвечает первый свободный сервер, т. е. CORBA является универсальной шиной, по которой передаются ответы на сервер и обратно. Более концентрированно взаимодействие по схеме CORBA брокеров объектных запросов как развитие объектного RPC представлено на рис. 9.8. Вызов методов осуществляется для сервера, и размещение информации на клиенте происходит посредством брокера объектных запросов, который представляет собой универсальную шину взаимодействия и инкапсулирует логику работы по поиску свободного сервера и передаче параметров от клиента серверу и результата от сервера к клиенту.

Рис. 9.8. Клиент-серверное взаимодействие по схеме COBRA

Итак, какие особенности можно выявить в объектных RPC, объектном подходе к удаленному вызову процедур, с точки зрения взаимодействии Proxy и Stub по сравнению с ранним подходом? Речь идет об объектном взаимодействии. Proxy и Stub выглядят как обычные объекты. Для клиента функция на С выглядит как локальная. Так же и объект при вызове будет выглядеть как локальный объект на клиенте. Но на самом деле этот объект осуществляет упаковку параметров и передачу их серверу. Этот процесс упаковки параметров и их передачи называется маршаллинг и является весьма существенным для. NET и Remoting, так как по сути означает передачу объекта через границу процесса.

Маршаллинг включает упаковку параметра вызова и его передачу в упакованном формате от клиента к серверу. Анмаршаллинг соответственно включает распаковку параметра вызова и передачу распакованной функции или метода серверу, который и выполняет запрос. Затем осуществляются обратный процесс упаковки ответа, передача клиенту брокером этого ответа от сервера, и клиент осуществляет распаковку результата и приложение его вызывающей процедуре. Таким образом, процедуры маршаллинга и анмаршаллинга реализованы тоже полностью в объектном виде и, в частности, включают передачу параметра вызова, ряда других параметров и позволяют осуществить нейтральное взаимодействие относительно характеристик клиента и сервера. То есть клиент ничего не знает о сервере, деталях реализации объекта на сервере. С его точки зрения, речь идет просто об обработке некоего объекта, который хранится как бы локально. А сервер ничего не знает о клиенте, просто выполняет свою функцию.

Теперь обсудим, каким образом осуществляется взаимодействие между клиентом и сервером в RPC по объектной схеме. Как Proxy, так и Stub являются объектами и реализуют в полной мере объектно-ориентированное взаимодействие параметров Operation передачи от клиента серверу и параметров Reply возвращаемого значения от сервера клиенту. При этом взаимодействие между клиентом и сервером, кроме упаковки параметров и ответов, включает, что очень важно, передачу этих параметров через границу различных процессов (1 и 2), которые выполняются, возможно, в различных ОС или на различных машинах. Напомним, что процесс упаковки называется маршаллингом, процесс распаковки – анмаршаллингом. Если перейти от традиционной схемы объектно-ориентированного взаимодействия при реализации технологии удаленного вызова процедур RPC к той технологии, которая реализуется в среде Microsoft.NET и называется. NET Remoting, станет понятно, что взаимодействие организуется очень похоже.

Каким же образом осуществляется взаимодействие между клиентом и сервером через границы процессов и как при этом используются так называемые домены приложений? Рассмотрим это более подробно. При выполнении некоторой программы, написанной для. NET, естественно, следуя главе, в которой речь шла о среде. NET, выполнение это происходит в среде CLR. По сути, компоненты программ, которые реализуются и выполняются в этой среде, оттранслированы в код виртуальной машины. Microsoft Intermediate Language, зависящая от платформы, функционирует в терминах этого языка на той самой виртуальной машине, которая называется CLR машина. При этом загрузчик программы сначала создает хост CLR, по сути, экземпляр виртуальной машины и приложение машины, в которую по умолчанию загружаются сборки, необходимые для выполнения этой программы, и затем осуществляется передача управления этому процессу. В некоторых случаях в одном процессе может сосуществовать несколько различных доменов приложений. Среда CLR – виртуальная машина. NET может поддерживать независимое выполнение программ одного процесса в рамках нескольких доменов приложений. На рис. 9.9 представлен процесс, который на уровне операционной системы реализован в архитектуре приложений 32-разрядной машины Windows. При этом на уровне. NET осуществляется создание хоста CLR, в рамках которого могут функционировать в одном процессе несколько доменов приложений. Далее соотношение между процессами и доменами приложений выглядит следующим образом. В рамках одного и того же компьютера, скажем CLR, могут функционировать несколько процессов в архитектуре той же Windows 32. В каждом из них может быть также не один домен приложения, а несколько. Другой компьютер – это может быть сервер или другой клиент – также может иметь один или несколько процессов Windows 32, внутри которых также может быть несколько (в данном случае три) домена приложений.

Рассмотрим, каким образом осуществляется работа с удаленными объектами, расположенными на сервере? Со стороны клиента это выглядит точно так же, как и в среде. NET. Существует четкое разделение на взаимодействие по имени и взаимодействие по ссылке (Value и Reference). Если мы вспомним систему CPS, систему типизации, которая реализована для. NET, то увидим, что в рамках этой системы типизации существует изначальное четкое разграничение на две большие категории типов – Reference и Value. И обращение с объектами, обработка объектов этих больших категорий происходит различными способами. Напомним, что объекты классов категории Value, например, хранятся в стеке, при копировании создается физическая копия объекта, создается еще один объект стандартного размера, скажем, 4 или 2 байта, в зависимости от типа объекта. Он имеет фиксированный размер, и осуществляется физическое копирование значения. Если рассматривать объекты типа Reference, то осуществляется копирование ссылки, а не самого значения. Размер объекта, который имеет тип ссылку, изначально не определен, и на самом деле речь идем о том, что есть указатель на некую область памяти. Хранится в динамической памяти объект этого типа, т. е. взаимодействие между такого рода объектами, или маршаллинг, также происходит различными способами. То есть в. NET существует подход, который называется Marshal by Value и Marshal by Reference. Рассмотрим основные различия между этими подходами, а также их реализацию.

Рис. 9.9. Домены приложений в Windows

Примерно различие в обработке объектов такое же, как и различие между объектами-ссылками и объектами-значениями и их обработкой средой CLR. Если речь идет о маршаллинге по значению, то реализация процесса происходит следующим образом: от сервера клиенту необходимо передать объект целиком. Точно так же, как осуществляется физическое копирование объекта при присваивании, скажем, целочисленного значения (физическую копию объекта). Напомним, что несмотря на то, что существуют типы-ссылки и типы-значения, на верхнем уровне иерархии типов каждый тип является объектом и относится к пространству имен System.Object. И в связи с этим существует определенное единообразие. Но на уровне обработки существует фундаментальное различие между типами-ссылками и типами-значениями.

Итак, маршаллинг по значению разумен, целесообразен в тех случаях, когда, так же как и в случае объектов типа значения, речь идет о достаточно простых объектах – целочисленных, булевых или о тех объектах, которые редко претерпевают изменения во времени. Маршаллинг по ссылке предполагает передачу от сервера к клиенту параметров вызываемого метода, а не самого объекта. И методы объекта вызываются на стороне сервера. В случае маршаллинга по значению вызываются на стороне клиента, в случае маршаллинга по ссылке – на стороне сервера. В отношении маршаллинга по ссылке и по значению можно отметить следующую специфику: объект содержит ссылки на системные ресурсы, которые специфичны либо для процессора, либо для компьютера. Также объект содержит ссылки на большое количество других объектов на стороне сервера либо часто изменяет свое состояние. Если речь идет о маршаллинге по ссылке, то этот подход предпочтителен для сложных специфичных объектов конкретного процесса или компьютера, для объектов с большим количеством ссылок или для объектов, которые часто изменяют свое состояние. При работе с корпоративными системами также целесообразен маршаллинг по ссылке.

Рассмотрим явное создание объекта как вариант клиент-серверного взаимодействия по технологии Remoting. Здесь мы уже видим в примере кода, что явно используется метод маршаллинга объекта класса Remoting Services. То есть в пространстве имен. NET существует класс Remoting Services, который имеет ряд методов, связанных с реализацией объектов и передачей параметров от клиента серверу различными способами. Итак, при явном создании объекта осуществляется прежде всего создание некоего объекта, вызов конструктора, оператор NEW для объекта Obj класса Server Object. Осуществляется вызов конструктора без параметра, и создается новый объект. После чего осуществляется маршаллинг с явной передачей именно этого объекта путем вызова метода Marshal класса Remoting Services с параметром Obj. Таким образом, объект на сервере создается явно. Он будет иметь имя srv_obj. И объект на сервере существует до тех пор, пока на него имеются ссылки. Реализация уничтожения ссылок явным образом осуществляется посредством вызова специального метода, того же класса Remoting Services, который называется Disconnect. При этом необходимо явно указывать, что речь идет об объекте Obj.

При явном создании объекта клиент может получить ссылку на этот серверный объект двумя способами – используя либо метод Get Object класса Activator (здесь необходимо преобразование к классу Server Object), либо оператор type of, который определяет объект по типу. Для этого явно указывается имя объекта, которое было ранее определено и его местоположение, – Localhost. Другой подход связан с определением типа объекта и явным указанием этого объекта таким же образом, как и в предыдущем методе, а затем созданием объекта явным образом посредством конструктора Server Object.

Далее следует рассмотреть вопрос явной активизации объектов на сервере. Момент создания объекта в этом случае определяется сервером. При этом речь идет уже о передаче не экземпляра объекта, а его типа. То есть имя присваивается не экземпляру, а типу. И для обработки каждого вызова удаленного метода может создаваться собственно новый экземпляр объекта. При этом используется метод Single Call. Здесь явно указывается имя объекта srv_obj и осуществляется вызов метода Register Service Type, т. е. определенный метод реализации сервиса на основе класса Remoting Configuration. Нужно сказать, что все вызовы удаленного метода могут обрабатываться одним и тем же объектом, сервером, при этом используется метод Single в отличие от предыдущего Single Call. Клиент работает с удаленным объектом полностью аналогично предыдущему случаю. Другая форма взаимодействия между клиентом и сервером основана на активизации объектов клиента. При этом момент создания объекта определяется уже не сервером, а клиентом, и на сервере в этом случае может быть создано много объектов. В этом случае сервер объекта уникально однозначно определяется явным указанием имени компьютера. Мы видим, что осуществляется передача параметра методу Register Activated Service Type, т. е. осуществляется регистрация указанного типа сервиса с параметром того самого объекта типа «сервер», к которому реализуется обращение. При этом, по сути, мы работаем в том же пространстве имен Remoting с тем же классом Remoting Configuration, но другим образом определяем конфигурацию взаимодействия между клиентом и сервером. При активизации объектов клиентом на сервере клиент должен вначале осуществить регистрацию типа объекта с учетом его расположения на сервере, а затем создать объекты, для каждого обращения создается объект (Proxy), который осуществляет инкапсуляцию методов на сервере. Итак, мы используем метод Register Activator Client Type класса Remoting Configuration с явным указанием, что тип объекта расположен на сервере, и явным указанием этой машины. После чего для каждого вызова создается свой объект класса Server Object. По сути, это не совсем объекты, это Proxy. Но для каждого из них осуществляется свой вызов оператора New.

Последнее, что будет обсуждаться касательно Remoting, – это процедура сборки мусора. Вообще, процедура сборки мусора крайне важна для больших объектных систем. Здесь речь идет о том, что существует большое количество объектов типа «ссылки». Следует напомнить, что в. NET, в CTS – системе типизации, существуют два больших подкласса объектов – ссылки и значения. Если рассматривать корпоративные системы, то очевидно, что для реализации распределенных приложений, которые используют большое количество сложных объектов, а вместе с тем эти объекты имеют сложную структуру и динамически взаимодействуют друг с другом, целесообразно использовать типы-ссылки. В связи с этим часто возникают ситуации, когда не вполне корректно уничтожается информация о значении самого типа-ссылки при уничтожении собственно объекта этого типа. То есть не всегда разрывается связь между именем и значением объекта, на которое указывает ссылка с этого имени. Для уничтожения такого рода висячих ссылок, т. е. ссылок, указывающих на некорректную область памяти, которая уже освобождена и не содержит значения типа «ссылки», существует стандартный процесс сборки мусора.

По сути, эта технология характерна для большого количества программных инструментов, программных сред и реализована впервые достаточно давно, в частности одни из первых реализаций были связаны с языками функционального программирования, которые также поддерживают динамические структуры данных (например, LISP). Естественно, в Microsoft.NET, среде, которая призвана поддерживать работу с большим количеством языков программирования, распределенных сложных корпоративных программных систем, актуальность сборки мусора существенно возрастает в связи с частой сменой состояния и значений объектов. Конечно, имеет смысл и для технологии Remoting, и для технологии, которая поддерживает определенное взаимодействие компонентов таких систем, осуществить грамотный оптимальный и достаточно эффективный подход к сборке мусора. И здесь существуют разные подходы: обычный подход к сборке мусора в целом в среде. NET и поход, который связан с реализацией механизмов на основе. NET Remoting.

Если рассматривать классический подход к распределенной сборке мусора между клиентом и сервером, ссылки через границы процессов, то нужно реализовать уничтожение объектов на сервере, на которые ссылки более не актуальны. Это происходит следующим образом: распределенный сборщик мусора подсчитывает количество ссылок на серверный объект, т. е. на тот объект, который находится на сервере, при этом, естественно, поскольку эти ссылки идут на сервер, осуществляется периодический опрос клиентов. Другой подход сводится к тому, что в. NET можно явным образом выполнить функцию сборки мусора, и программист может явно вызвать соответствующий метод, стандартно реализованный в. NET Framework.

Что касается подхода Remoting, то здесь используется механизм аренды. Существует определенный интервал времени, который определяется для каждого серверного объекта. Каждому серверному объекту ставится в соответствие объект специального вида, который имеет интерфейс лизинга. И выглядит следующим образом: существует для маршаллинга по ссылке класс, который определяется как класс Marshal by Ref Object и содержит виртуальный объект, собственно и реализующий инициализацию процедуры обслуживания сборщика мусора. При этом интерфейс лизинга внутри класса осуществляет вычисление времени аренды для каждого объекта, который поставлен в соответствие и для которого существует возможность определения и обновления срока аренды, если такая возможность предоставляется.

На этом рассмотрение реализации технологий распределенных вычислений в среде. NET завершается. Мы познакомились с общим принципом распределенных вычислений, обсудили различие между подходом с сохранением состояний и подходом без сохранения состояний, а также подходом, который связан с Loosely Coupled и Tightly Coupled моделями взаимодействия. Оценили эффективность сильно связанной и большую универсальность слабо связанной модели взаимодействия объектов. Рассмотрели эволюцию архитектур, которые связаны с объектным и дообъектным подходами обмена информацией между клиентом и сервером по технологии RPC. Общим для этих подходов является наличие Proxy и Stub как механизмов упаковки и передачи параметров между клиентом и сервером. При упаковке речь идет о маршеринге, при распаковке – об анмаршаллинге. В объектном подходе имеет место инкапсуляция объектов, т. е. изоляция технологий сред взаимодействия и конкретных языков программирования, на которых реализуются процедуры, методы или функции для клиентов и серверов.

При этом инкапсуляция осуществляется на основе модели объектного вида – это либо COM-модель, либо модель типа CORBA – брокеров объектных запросов, либо компонентная модель, в более позднем варианте представляющая собой динамическую COM-модель, на основе которой реализуется подход, связанный с Remoting. Этот подход основан на использовании жестких протоколов, которые обеспечивают большую безопасность и надежность взаимодействия между компонентами корпоративных систем и распределенных приложений. При более мягком подходе, связанном с веб-сервисами, осуществляется слабосвязанная модель взаимодействия, которая в меньшей степени связана с. NET Remoting.

Как Remoting, так и более поздние технологии, с нашей точки зрения, основаны на интерфейсе, связанном с веб-формами, и существенно его используют. Более поздние технологии – это технологии веб-сервисов, речь о которых пойдет более подробно в следующей главе, и технологии, которые связаны с подходом WCF – Windows Communications Foundations. Эти технологии призваны реализовать подходы, связанные с клиент-серверным взаимодействием на основе более открытых протоколов и объектного распределенного взаимодействия в архитектуре клиент – сервер. Речь идет о сервисно-ориентированной архитектуре и таких протоколах, как SOA, HTTP. Более подробно этот вопрос будет освещен позднее.

Глава 11 Разработка веб-сервисов для корпоративных систем

Данная глава включает в себя две важные темы. Это прежде всего веб-сервисы, основополагающая для. NET технология, на которой зиждется все сетевое взаимодействие в этой среде. Вторая тема продолжает рассказ об архитектурах распределенного взаимодействия и представляет собой описание технологии Windows Communication Foundation (WCF). Исторически одной из наиболее ранних технологий, не считая веб-сервисов как таковых, была технология Remoting, но на сегодняшний день эта технология не является доминирующей, хотя на ее основе до сих пор производится достаточно много полезных приложений серьезного уровня. Напомним, что технология Remoting подразумевает жесткие связи между клиентом и сервером, строгий протокол взаимодействия, в связи с чем на ее основе производится программное обеспечение безопасных информационных систем. Технология же WCF не является, также как сам подход, связанный с веб-сервисами, столь жестким и, возможно, столь безопасным.

Веб-сервисы представляют собой, в том варианте, в котором мы рассмотрим их, вариацию на тему более общего и, может быть, более известного подхода, носящего название сервисно-ориентированной архитектуры, и изначально, наверное, во многом вместе с Microsoft или даже раньше, разрабатывался корпорацией IBM. Те решения, которые созданы на его базе IBM, являются в определенном смысле более открытыми, поскольку не только базируются на платформе операционной системы Microsoft Windows, но и поддерживают целый ряд других платформ, в частности Unix-системы. Поэтому подход SOAP (сервисно-ориентированной архитектуры), которому следуют в том числе и веб-сервисы, является несколько более широким, но поскольку мы сосредоточиваемся преимущественно на технологиях Microsoft, речь пойдет в основном об этих технологиях. Конечно, центральным понятием для архитектуры Microsoft.NET являются веб-сервисы. Ранее уже шла речь о клиент-серверных архитектурах, и понятно, что для реализации корпоративных приложений имеет смысл, конечно же, разделять логику взаимодействия компонентов системы на клиентскую и серверную части, когда у нас одна из них запрашивает ресурс или доступ, а другая этот доступ организует, а ресурс предоставляет. В данной главе будут рассмотрены веб-сервисы, возникновение этой концепции, а также ее особенности для. NET и то, каким образом следует ее использовать, а именно, каковы основные принципы, основные подходы, связанные с реализацией веб-сервисов. Мы рассмотрим достаточно подробно небольшой пример весьма простого веб-сервиса, который создается на основе инструментального средства Microcoft Visual Studio.NET. Покажем, каким образом создаются и применяются веб-сервисы. Более подробно рассмотрим модель реализации веб-сервиса в архитектуре Microsoft.NET, на платформе Microsoft.NET. Вспомним общую схему архитектуры. NET. На самом нижнем уровне находится операционная система Windows и ее сервисы, далее идут. NET Framework, базовые классы, которые осуществляют взаимодействие как с операционной системой, так и с более высокими прикладными уровнями различных информационных систем. И где-то на промежуточном этапе между собственно прикладной логикой и семейством классов. NET Framework находятся в том числе и веб-сервисы, рядом с такими архитектурными компонентами, как, скажем, ADO.NET (Active Data Objects), XML.NET, ASP.NET и целым рядом других элементов.

Более подробно стоит рассмотреть, каким образом веб-сервисы вписываются в общую концепцию и архитектуру Microsoft.NET и, кроме того, обсудить, каким образом осуществляется обнаружение или поиск веб-сервисов. Ведь, по сути, веб-сервис – это некий компонент, который опубликован или, проще сказать, размещен на интернет-сервере. Существует специальный язык, который называется Web Service Definition Language (WSDL) и предназначен для описания веб-сервисов. Это интерфейсный язык, в определенном смысле это достаточно нейтральный стандарт, который можно использовать для описания веб-сервисов. Существует также средство поиска с названием Disco (от слова discovery).

И, конечно же, необходимо обсудить то, как концепция веб-сервисов вписывается в общую архитектуру, в более общую картину SOAP и, естественно, веб-сервисы как элемент этой концепции, сервисно-ориентированной, подчиняются протоколу SOAP, на основе которого функционируют не только веб-сервисы от Micfosoft, но и веб-сервисы от IBM, и большое количество других веб-сервисов. Таким образом этот протокол поддерживается в среде веб-сервисов от Microsoft. Существуют потенциально более безопасные технологии, связанные с сетевым взаимодействием. Это прежде всего Remoting, если рассматривать Microsoft-технологии построения распределенных приложений. Обсудим безопасность веб-сервисов и способы обеспечения этой безопасности, а каким образом ВС, эта центральная часть архитектуры. NET, используется для реализации приложений Microsoft.NET.

Перейдем непосредственно к рассказу о ВС: что такое ВС, что понимается под этим термином. Первое слово, которое мы встречаем, – это WEB, т. е. речь идет об Интернете, и поскольку речь идет о сервисе, то здесь мы имеем дело с клиент-серверным взаимодействием, и клиентом, конечно же, является веб-браузер, точно так же, как в случае тонкого клиента. Напомним, что в этом случае на клиенте размещена только презентационная логика, собственно прикладная логика вся размещается на сервере, в связи с чем клиент у нас получается достаточно легким, или, как говорят, тонким. Он ограничен исключительно веб-браузером, и – что имеет принципиальное значение для корпорации – таких клиентов достаточно легко тиражировать, настраивать. Скажем, если появится необходимость из соображений безопасности провести какие-то настройки на клиенте, то это произойдет единообразно для всех компьютеров пользователей, а их в корпорациях тысячи. Если нужно внести какое-то изменение в программную среду клиента, это опять-таки делается и тиражируется с учетом тех средств, которые разработаны, в том числе МС, достаточно легко. Но, надо сказать, что есть интересные средства и у H P, и у Compaq, которые позволяют достаточно эффективно распределять или распространять изменения по компьютерам. И в связи с этим администрирование становится централизованным и во многом упрощается. Итак, ВС – это не просто интернет-приложение, это некий специальный тип, особый вид веб-приложений, который на самом деле не просто создает ответный HTML, появляющийся в браузере пользователя, а характеризуется использованием так называемых веб-методов, т. е. специализированных функций, описанных в среде. NET, которые можно вызывать из браузера. При рассмотрении традиционного клиент-серверного взаимодействия, когда клиент является веб-браузером, понятно, что он читает и воспринимает только статический HTML, в этой связи существует некоторое обобщение.

Если рассматривать ВС, что можно отметить, что мы имеем уже компонентное взаимодействие, когда существуют некоторые обособленные, компонентного вида структуры, которые называются методами и, по сути, являются функциями, позволяющими организовать сценарно-ориентированное взаимодействие. В зависимости от того, как ведет себя пользователь, взаимодействуя с браузером, осуществляется выбор, во-первых, той или иной функции, во-вторых, той или иной стратегии поведения приложения, может быть корпоративного, с которым взаимодействует клиент.

В чем состоят основные особенности реализации и применения ВС? Во-первых, ВС выполняются, конечно же, на сервере, потому что клиент является легким, тонким, по сути это веб-браузер, который имеет только презентационную логику, скажем, определенные формы, которые нужно заполнять, и он обращается к ВС, которые расположены, конечно же, не на клиенте, не в веб-браузере, не на компьютере пользователя, а на сервере. При этом средой выполнения является ASP.NET, т. е. как раз серверная технология, которая предусмотрена для работы в архитектуре клиент– сервер. При этом веб-сервисы осуществляют публикацию, т. е. размещение в Интернете методов, по сути, функций, которые могут быть вызваны внешними клиентами, т. е. интернет-браузерами пользователей, которые эти методы обнаруживают на том или ином сервере в Интернете. То есть сервер, выполняющий запрос пользователя и применяющий при этом ASP.NET, необязательно совпадает с сервером, который хранит и осуществляет взаимодействие пользователя с публикуемыми методами. Взаимодействие при этом, естественно, организуется на основе открытого протокола, стандартного протокола, который поддерживает веб-браузер, это, естественно, HTTP. Существенным минусом или существенной особенностью его является невозможность сохранения состояния, но важно, что это достаточно открытый, стандартный протокол, который поддерживает любой веб-браузер, даже необязательно Microsoft Internet Explorer. Из любого веб-браузера можно осуществить вызов веб-сервиса. Веб-сервисы, те их компоненты, которые отвечают за выполнение этих методов, выполняют запросы, которые могут носить достаточно сложный, гетерогенный, многокомпонентный характер, и возвращают веб-браузеру ответы от сервиса – результаты выполнения этих методов, естественно, с использованием протокола HTTP.

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

Если вести речь о корпоративных приложениях, корпоративных системах, то имеет смысл остановиться на корпоративном контенте – к нему относят реляционные данные, которые хранятся и обрабатываются реляционными СУБД, в случае Microsoft это Microsoft SQL Server. Что касается данных, нужно еще отметить, что это не только реляционные данные, но и, скажем, данные мультимедийные, которые поддаются анализу и обработке зачастую не так хорошо и хранятся они иначе, это могут быть отсканированные документы, аудио– и видеозаписи и т. д., но в любом случае над ними есть при корпоративном подходе некоторая надстройка из метаданных. Будем считать, что это XML-описание полей определенного рода и указания на те области, в которых можно хранить значения этих полей. То есть мы определенным образом индексируем видеоинформацию, информацию звуковую, фотоизображения, после чего можем осуществлять в том числе семантический, т. е. осмысленный, поиск по ним или, по крайней мере, по тем метаданным, которые у нас в итоге, скажем в формате XML, представляются. В результате мы получаем возможность посредством веб-сервисов по стандартному HTTP-протоколу со стандартными языками описания, скажем WSDL и др. в рамках стандартной архитектуры, ориентированной на сервисы, и в рамках протокола SOAP осуществить взаимодействие между этими достаточно разнородными системами. Нам открывается важная возможность построения решений принципиально еще более высокого уровня, чем корпоративные системы, которые называются B2B-решения (Business-to-Business), когда речь идет не об организации процессов внутри одной корпорации, а о взаимодействии нескольких корпораций или компаний между собой. Здесь веб-сервисы выступают своего рода каналом взаимодействия, неким gateway, можно сказать, шлюзом между разнородными и разноплановыми системами этих разных корпораций. Мы просто указываем правила этим ВС, по которым нужно осуществлять поставку информации из одних систем, а из других эту информацию консолидировать.

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

Одно интересное приложение веб-сервисов связано с технологией быстрой разработки приложений. Быстрая разработка достаточно важна для корпоративных систем, поскольку прототипирование, разработка быстрых прототипов позволяет экономить трудозатраты и создать рабочую модель программной системы на достаточно ранней стадии. Это стадия анализа и формирования требований к программному продукту, когда мы можем представить проект решения руководству заказчика. При этом речь может идти о заказчике, который находится внутри нашей корпорации и для которого мы (как другая компания этой корпорации) ведем разработку программных систем. Или же это может быть сторонний заказчик, для которого разрабатывается система. В случае корпоративной системы это достаточно большая, тяжелая, затратная система для реализации, мы можем в сжатые сроки, особенно если мы используем инструментарий от Microsoft Visual Studio.NET, представить прототип. То есть реализацию основных функций без уделения сколь-нибудь серьезного внимания надежности, документации, безопасности и т. д. Существует достаточно большая библиотека веб-форм и элементов управления этих веб-форм от Microsoft.NET – библиотека Windows Forms, для того чтобы эффективно строить классы элементов и эффективно прототипировать программное обеспечение до реализации.

Если рассматривать программное обеспечение, которое должно кроме предоставления локальных решений на технологии Web Form быть распределено по Интернету и обеспечивать доступ для пользователей из Интернета к этим функциям, то технология веб-сервисов совместно с таким мощным средством, как Visual Studio.NET, и таким большим количеством библиотек для реализации стандартных веб-сервисов, как в. NET, является достаточно хорошим решением. То есть быстрая разработка или, лучше сказать, быстрое прототипирование, построение вот таких решений позволяют нам обеспечить продуктивный диалог с заказчиком на ранней стадии проектирования и подготовить представление функциональных особенностей нашего программного обеспечения без существенных трудозатрат. И если речь здесь идет не о боевом продукте, который обладает достаточной надежностью, масштабируемостью, документацией, как это свойственно полномасштабным корпоративным приложениям, то веб-сервисы могут оказать существенную поддержку именно для прототипирования.

Каким же образом строятся веб-сервисы? Наверное, имеет смысл привести пример элементарного веб-сервиса, для того чтобы стало понятно, каким образом, используя инструментальные средства Microsoft Visual Studio.NET, осуществить построение более масштабных веб-сервисов и корпоративных информационных систем на их основе. Рассмотрим пример достаточно простого веб-сервиса, который будет вычислять квадратный корень числа, заданного пользователем в веб-браузере в соответствующей форме. Каким образом осуществляется создание такого рода веб-сервиса? Заметим, что мы работаем в рамках технологии ASP.NET, и поэтому, для того чтобы создать веб-сервис, мы должны создать веб-сервис именно этого класса. По сути, мы работаем в пространстве имен ASP.NET и строим веб-сервис на основе тех технологий, тех классов, которые изначально там имеются. В Microsoft Visual Studio.NET мы должны построить новый веб-сайт, мы выбираем в меню «new web site» и затем пункт подменю, который называется ASP.NET Web Service. После этого нужно задать его имя, предположим, мы его называем RootCalculateService. В соответствии с соглашением о наименовании это будет цепочка из трех слов, каждое из которых начинается с заглавной буквы, и между ними нет ни пробелов, ни подчеркиваний. Таким же образом у нас именуются классы в. NET Framework при реализации приложений на основе этой платформы. При этом у нас создается несколько файлов даже при том небольшом коде, который мы в этот веб-сервис внедряем. У нас существуют определенного рода конфигурационные файлы, Web Config, файл, который будет назван service.smx (подробнее структуру и назначение этих файлов рассмотрим далее) и, собственно, код веб-сервиса, который будет называться service.cs, т. е. на языке C# создается исходный код этого веб-сервиса и мы можем его видоизменять.

Такого рода интерфейс предоставляет нам Microsoft Visual Studio.NET, т. е. используются пространство имен, в частности System. Web, и подпространство имен в нем System.Web.Services, в котором у Microsoft Visual Studio.NET имеется достаточно большое количество классов, стандартным образом описывающих веб-сервисы. Здесь мы видим код, тот самый файл service.cs, С# код этого веб-сервиса. Веб-сервис представляет собой не что иное, как класс Microsoft.NET, общедоступный, который называется Public Class Service и включает некий метод, который тоже называется Service по умолчанию и который мы можем соответствующим способом изменять. Он может включать некоторые компоненты и методы для обработки этих компонентов. В рамках этого сервиса существует некий метод, который мы сейчас создали, он называется CalculateRoot, является общедоступным, имеет модификатор доступа Public и тип возвращаемого значения Double – число с плавающей точкой двойной точности. Точно так же и на вход он получает некий элемент Value типа Double, от которого будет вычислять квадратный корень. В итоге он должен выполнить стандартную функцию, которая находится в пространстве имен Math, математическую функцию, которая называется sqrt, и именно этот метод и вызывается с входным параметром Value, который передается веб-сервису. На основе выполнения этого метода он должен будет вернуть результат, что обозначается служебным словом Return.

По сути, весь наш код уместился в две строчки: это сигнатура метода – название метода, тип возвращаемого значения, тип входного значения, и одна строчка – вызов стандартной функции, которая должна вычислить значение и вернуть его сервису, для того чтобы сервис, отработав, передал его в виде HTML по HTTP-протоколу клиенту, т. е. веб-браузеру. Вот такого стандартного рода окно мы получаем при попытке открытия этого веб-сервиса из нашего клиента. Но сервис у нас хранится локально, и в адресе, в URL, у нас записано HTTP, и затем Localhost и нечто дальше. То есть наш сервис еще не размещен на сервере, и сервер мы эмулируем той же самой машиной, на которой размещен код веб-сервиса. Тем не менее в адресной строке мы вызываем тот самый сервис, который называется Service и имеет точный путь RootCalculateService, это в пути указано. В упрощенном варианте в этом примере мы видим, как осуществляется вызов веб-сервиса. При описании этого веб-сервиса мы видим ссылку под словом Service, которая стандартным образом, как это в веб-браузере и отображается, представляется текстом синего цвета с подчеркиванием: CalculateRoot, если мы по ней щелкаем, то осуществляется вызов веб-сервиса. Ниже, под чертой, осуществляется описание пространства имен, в котором выполняется вызов этого сервиса. Здесь указано, каким образом осуществлять вызов из. NET, используя язык C#, Visual Basic, C++. Возможно, существуют и другие интерфейсы. Кроме того, если мы хотим получить описание работы нашего веб-сервиса, мы можем щелкнуть по ссылке Service Description, которая расположена на строчку выше в описании нашего сервиса, и получить подробное описание этого сервиса.

На самом деле, если мы хотим увидеть, как представлен веб-сервис, так сказать, его внутреннее представление, мы можем обратиться к XML-версии и увидеть, что используются стандартный протокол SOAP, язык описания веб-сервисов WSDL и на этом языке (как мы видим, вариант XML версии 1.0) задается описание веб-сервиса. Здесь указывается, где у нас хранится этот веб-сервис, как называется, указано, что есть элемент, который называется CalculateRoot, и какого рода значения он получает на вход: это входной параметр с именем Value и типом Double. Если мы более внимательно просмотрим XML-структуру этого представления, а именно таким образом выглядит веб-сервис в XML-представлении, мы увидим ряд других параметров: параметры, которые он принимает на вход, параметры, которые он возвращает, и то, что взаимодействие осуществляется посредством передачи сообщений на языке WSDL от клиента к серверу и обратно. На самом деле, если посмотреть на скриншот (рис. 11.1), видно, что здесь представлена небольшая часть описания этого веб-сервиса. На самом деле описание даже такого небольшого веб-сервиса на языке XML занимает достаточно много места, поскольку используется большое количество стандартных функций, стандартных методов, которые применяются для. NET веб-сервисов.

Рис. 11.1. Описание веб-сервиса на языке WSDL

Далее при выполнении этого веб-сервиса пользователь в веб-браузере открывает ссылку на сервис, и под строчкой Service, где была ссылка на его имя CalculateRoot, на имя этого веб-сервиса, при щелчке левой кнопкой мыши получает новое окошко с описанием веб-сервиса CalculateRoot на языке XML и окно ввода данных. Здесь он должен ввести параметр, который имеет имя Value. Пользователь вводит сюда некоторое число. Можно было бы посмотреть, как отработал стандартный сервис, если бы пользователь ввел сюда, скажем, отрицательное число или строку символов, каким образом произошла бы обработка исключения. Но в данном случае пользователь вводит корректное число 4, здесь оно представлено как целое, но это вещественное число с точки зрения реализации нашего веб-сервиса. После этого пользователь нажимает на кнопку Invoke, и происходит обращение к серверу, где хранится описание метода, код которого мы видели. Там вызывается стандартный метод из пространства имен Math, который выполняет вычисление корня квадратного из вещественного числа двойной точности. В итоге мы получаем XML-представление в браузере, где фигурирует то самое число 2, которое и возвращается пользователю. Можно было бы это более аккуратно оформить, в виде окна. Таким образом, веб-сервис корректно отработал и вернул именно в том интерфейсе, в интерфейсе веб-браузера, из которого был запрошен, в новом окне этого интерфейса корректное значение. При этом на компьютере пользователя, хотя в данном случае он совпадает с сервером, в общем случае никаких действий по вычислению не производилось бы, а эта вычислительная процедура в форме метода на C# была бы расположена и хранилась на сервере, который производил вычисления.

После того как мы рассмотрели общее представление некоторого примера, пусть достаточно простого, реализации веб-сервиса, мы можем сделать некоторые предварительные выводы и заключения. В частности, у нас веб-сервис был создан как файл с расширением asmx. Именно это расширение регистрируется в файле mashine.config и именно здесь может храниться тот код веб-сервиса, который будет выполнен, тот код на C#, который мы создавали. Кроме того, этот код может храниться и отдельно. Какова структура asmx файла? По сути, он хранит класс, который задает веб-сервис, в данном случае метод CalculateRoot в классе Service, который и был доступен по ссылке. Файл начинается с директивы @service, т. е. показывает, что внутри этого файла содержится описание веб-сервиса, и существует еще атрибут Class, который описывает наш веб-сервис. Классы веб-сервиса могут быть описаны посредством атрибута Web Service, как и XML-описании, но этот атрибут не является обязательным. Важно, что в описании присутствует определение веб-методов, которые определяются как атрибут класса сервиса с тем же самым именем Web Method. При этом такой атрибут может быть присвоен только общедоступным методам заданного класса. То есть методам, которые имеют модификатор доступа Public, как у метода CalculateRoot класса Service.

Нужно сказать, что у Web Method имеется целый ряд атрибутов, связанных с различными параметрами, характеристиками обработки информации, которая поступает от пользователя и выполняется на сервере. При этом веб-сервисы изначально направлены на создание масштабируемых и достаточно мощных распределенных систем. В этой связи существуют такие параметры у веб-методов, как кэширование результата и буферизация. То есть специальные области памяти отводятся под хранение промежуточных результатов или результатов наиболее частых запросов. Существуют также специальные параметры, такие как Transaction Option, которые поддерживают обработку транзакций, т. е. атомов взаимодействия пользователей с данными. Естественно, каждый метод имеет некоторое имя – Message Name и описание – Description.

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

При создании веб-сервиса существует достаточно общий и достаточно широкий класс, который так и называется – Web Service, на его основе можно создавать собственные веб-сервисы. Он находится в пространстве имен System.Web.Services. Public Class Service мы создали как раз на основе этого класса System.Web.Services.Web Service, а класс Web Service создали как дочерний на основе этого системного класса, он обладает всеми свойствами своего родителя и реализует все его методы, поскольку речь идет о традиционном объектно-ориентированном подходе. Кроме того, поскольку можно не только использовать существующие атрибуты и методы класса, но и создавать новые, расширять его, мы можем доработать, развить код этого класса, чтобы сделать на его основе свой. Подобно тому, как мы это сделали в примере, когда расширили код созданием дополнительного метода CalculateRoot, который вычислял квадратный корень из числа с плавающей точкой двойной точности, которая в результате и публиковалась на клиенте в веб-браузере.

Мы перечислили целый ряд атрибутов веб-методов. Все эти характеристики доступны из класса Web Service, и мы можем организовать непосредственный доступ к таким параметрам класса Web Service, как сессия, контекст, пользователь, сервер, приложение и т. д. Все они имеются в перечне атрибутов этого класса, управляются его методами, доступны, их описание можно найти в описании этого класса, это свойства Application, Context, User, Server и т. д. И если мы осуществляем наследование от этого класса, т. е. создаем собственные классы на основе данного, мы можем применить технологию. NET Remoting, т. е. использовать не только стандартные средства, связанные с веб-сервисом, но и Remoting для организации удаленного взаимодействия компонентов приложения.

Ранее указывалось, что технология Remoting имеет достаточно развитую библиотеку классов, которая позволяет организовать сессии такого рода взаимодействия. Уже упоминалось слово Disco – это такая странная аббревиатура, которая, к сожалению, явной расшифровки не имеет. Она происходит от слова Discovery – обнаружение, поиск. Это механизм на основе файлов, который служит для обнаружения и поиска локальных веб-сервисов. Кроме того, используются специальный язык WSDL и специальная служба UDDI – Universal Description Discovery and Integration, которая применяется для глобального поиска веб-сервисов. Именно благодаря этой службе становится возможным отыскать веб-сервисы, опубликованные на различных серверах, т. е. компьютерах, расположенных в Интернете. Эта задача на порядок проще, и взаимодействие существенно конструктивнее, чем то, что было сделано в предварительной версии Windows, которая появилась в сети Интернет. Для описания веб-сервисов используется язык WSDL. По сути, это подмножество языка XML, т. е. все, что пишется на WSDL, укладывается в XML-стандарт, но здесь есть специальные теги, подтеги WSDL, которые начинаются со слова WSDL. Здесь описываются type, scheme, element и т. д. То есть речь идет о тех объектах, тех атрибутах объектов и методах, которые используются для описания веб-сервисов. Кроме того, описаны сообщения – Message Name, которыми обмениваются объекты при взаимодействии в рамках веб-сервиса. Здесь используется традиционный протокол, предназначенный для обмена данными по сервисно-ориентированной архитектуре, и язык WSDL.

На самом деле достаточно полезно самостоятельно ознакомиться с описанием веб-сервиса, для того чтобы понять, какое значительное количество кода в нем содержится изначально, который мы не писали, но который автоматически наследуется из стандартного класса Web Service, и, конечно, для того, чтобы понять, какова структура веб-сервиса, какие поля и методы используются, как организуется взаимодействие: как организуются сессии, обмен сообщениями и т. д. Многое можно понять и почерпнуть для себя просто из этого описания, которое на самом деле представляет собой достаточно полное описание всей функциональности и всех атрибутов веб-сервиса. С другой стороны, это описание на достаточно универсальном языке, пусть и несколько громоздком в данном случае, по сути, это XML. Здесь нет в чистом виде C#, а есть основные параметры конфигурации этого веб-сервиса: какие атрибуты ему потребуются. Скажем, у нас есть элемент, который называется Value, имеет тип Double и связан с результатом, который выдает метод CalculateRoot. Выдает он его через объект, называемый CalculateRootResponse. Достаточно много можно почерпнуть из этого описания, если внимательно его просмотреть.

На рис. 11.1 представлена относительно небольшая часть этого описания. Итак, язык WSDL – это не что иное, как просто диалект XML, вариант или подмножество языка XML. Если мы будем стандартным средством разбора просматривать этот текст как XML, мы поймем, что это на самом деле XML. Но сюда включены специфические теги, которые позволяют описывать веб-сервисы. А веб-сервис – это не что иное, как класс, который наследует от стандартного класса Web Service свои свойства и имеет определенные атрибуты и методы. Возвращаясь к рисунку с примером веб-сервиса и его описанием на языке XML, можно заключить, что здесь имеется достаточно глубокая вложенность. То есть это описание имеет не один, а несколько уровней абстракции – имеется XML-схема, которая содержит элементы, скажем, атрибуты и методы. Приблизительно в таком виде выдержано описание веб-сервиса. Следовательно, речь идет об описании класса с достаточно большим уровнем вложенности по атрибутам и методам.

Кроме того, WSDL описывает веб-сервис как модуль, т. е. как некоторую замкнутую, самодостаточную единицу кода, который решает узкую специализированную задачу. В данном случае решается единственная задача – подсчет квадратного корня от того числа, которое будет передано пользователем через Internet Explorer, через веб-интерфейс, и возврат значения в том же интерфейсе. Описание WSDL включается между тегами базового элемента, который называется Definitions и имеет ряд разделов. Эти разделы описывают не только структуру веб-сервиса, но и его функции, не только в смысле его прямого назначения и тех расчетов, которые он осуществляет в данном случае, но и, конечно, в смысле интерфейса, взаимодействия с пользователем. Здесь есть раздел Messages – это сообщения, на основе которых будет строиться обмен с сервером, порты, виды портов, сервисы, которые он задействует, определенного рода Boundings, т. е. связи при осуществлении взаимодействия. Об это речь пойдет более подробно при рассмотрении технологии WCF. Здесь просто отметим, что Bounding – это достаточно важная составляющая. Types and Operations – это, по сути, атрибуты и методы, с которыми имеет дело наш веб-сервис. Нет смысла детализировать каждый из этих разделов, каждый может сделать это самостоятельно, используя XML-представление. Оно, с одной стороны, достаточно большое, с другой – вполне наглядное. Веб-сервисы взаимодействуют между собой на основе протокола SOAP. На самом деле это протокол, который функционирует поверх HTTP. Этот протокол достаточно общего вида, т. е. он никак не связан с Microsoft, с веб-сервисами от Microsoft, по сути, это международный стандарт, который существует для построения веб-сервисов или, лучше сказать, сервисов на основе сервисно-ориентированной архитектуры. Во многом его свойства унаследованы от удаленного вызова процедур. С точки зрения клиента, не существует различия между локальным описанием процедуры, т. е. описанием процедуры, которая будет выполнена локально, и описанием процедуры, которая будет выполнена где-то на удаленном сервере. Примерно таким же образом можно заключить, что нет разницы между описанием сервиса, который будет выполнен локально, так как только в URI разделе фигурирует Localhost. Только поэтому можно заметить, что веб-сервис будет выполнен на том же самом компьютере, с которого и осуществляется вызов. URI – универсальный идентификатор ресурса в Интернете, который, как и любой интернет-адрес, может физически описывать компьютер, находящийся где угодно в Интернете. Таким образом, вызов фактически инкапсулируется внутри самого сервиса. И, что немаловажно, взаимодействие осуществляется по общему протоколу, что позволяет в принципе связывать веб-сервисы, как созданные на основе продуктов Microsoft, так и другие. То есть позволяет строить шлюзы между различными веб-сервисами и вообще различными корпоративными системами. Это очень важно, поскольку корпоративные системы изначально являются гетерогенными. Такая ориентация на открытый протокол позволяет нам реализовывать разветвленные распределенные системы достаточно большого объема и их взаимодействие, независимо или в незначительной степени зависимо от тех технологий, на которых они построены. По сути, так же как в большом количестве других протоколов взаимодействия, речь идет об обмене сообщениями в рамках сессии между клиентом и сервером при таком взаимодействии. Это отчасти похоже и на RPC, скажем, на взаимодействие в связи с подходом CORBA, который был описан ранее, отчасти на COM-модель. По сути, у нас есть некоторый протокол обмена сообщениями, когда каждое сообщение включает в себя заголовок сообщения, некоторое тело, в котором, собственно, говорится о том, что же нужно выполнить, и конверт. Протокол SOAP основан на XML-технологии. То есть он не имеет ничего общего с Microsoft и с технологиями от Microsoft. Он точно так же используется и IBM, и другими. Это открытый протокол, международный стандарт, описание процедур удаленного вызова, описание сообщений в нем реализовано на стандартном XML. При этом среда. NET позволяет настраивать формат сообщений, которые отправляются при помощи веб-метода. Здесь используется протокол SAOP и целый ряд атрибутов, которые являются атрибутами класса Web Service. В частности, имеет смысл отметить пару атрибутов, которые называются SOAP Method Attribute и SOAP RPC Method Attribute. То есть взаимодействие по протоколу SOAP может осуществляться разными способами, в том числе и с явным использованием технологии RPC.

Теперь чуть более подробно о структуре заголовков SOAP, о структуре сообщений в этом протоколе для обмена данными. Существует атрибут SOAP Header Attribute, который как раз и призван осуществлять настройку заголовков. И здесь есть стандартный класс, который называется SOAPHeader и расположен в иерархии пространства имен следующим образом: System.Web.Services, т. е. находится внутри пространства имен веб-сервисов, дальше существует пространство имен Protocols, где есть ряд протоколов, в том числе и SOAPHeader. При этом в описании веб-сервиса для этого атрибута указывается имя переменной класса заголовка. После создания Public Class Service1, который является классом System. Webservices.Webservice, т. е. веб-сервисом, мы создаем некий заголовок Public, имеющий идентфикатор m_full и тип Header1. Затем мы его связываем с классом SOAPHeader и производим дальнейшее преобразование уже с осуществленной привязкой к тому типу заголовка, который мы задали. У протокола SOAP имеется достаточно большое количество расширений, которые мы можем использовать в рамках технологии Web Service от Microsoft для того, чтобы осуществлять обмен данными внутри пакетов в рамках сессий по взаимодействию между клиентом и сервером посредством сообщений. При этом можно осуществлять настройку и обработку этих данных достаточно гибким образом, на основе широких возможностей. Для этого существует класс SOAPExtension, и на его основе можно создать свой класс и использовать атрибут SOAP Extension Attribute для создания собственных расширений и регулирования взаимодействия между компонентами веб-сервиса в рамках этих расширений.

Ранее уже были рассмотрены Proxy и Stub. Proxy является инкапсуляцией сервера веб-сервиса в приложении. При этом Proxy в данном случае объявляется объектом класса, который создается в рамках стандартной библиотеки классов Microsoft.NET Framework и использует наше описание веб-сервиса на языке WSDL. При этом методы класса, который создается и инкапсулирует логику веб-сервиса, соответствуют методам веб-сервиса. Генерация этих классов уже автоматически предполагается в Microsoft.NET Visual Studio. Можно использовать и специальную утилиту, специальное приложение, которое называется WSDL.exe и может осуществлять генерацию такого рода классов, генерацию Proxy веб-сервиса. Интересно, что веб-сервисы могут осуществлять как синхронную, так и асинхронную обработку данных посредством вызова методов. При этом асинхронные методы веб-сервиса отмечаются префиксами begin и end. Каждый раз мы помечаем в квадратных скобках имя метода Method Name, что служит сигналом окончания выхода из процедуры, окончанием вызова метода веб-сервиса. Реализуется специальный интерфейс, который называется IAsyncResult, также можно подписаться на уведомление о завершении метода путем передачи делегата или указателя на событие. Похожего рода обработку информации мы обсуждали во время описания технологии Remoting, возможен вызов метода в асинхронном режиме по похожим схемам.

Последний аспект, который хотелось рассмотреть в связи с веб-сервисами, – это безопасность. Следует напомнить, что достаточно безопасным подходом, который довольно часто, в том числе и в последнее время, используется для производства распределенных приложений на основе технологии. NET, является Remoting. Нужно сказать, что ряд методов может быть использован и в стандартных веб-сервисах, которые работают на основе открытого протокола SOAP, взаимодействуют с клиентом по протоколу HTTP и используются широко в. NET Framework. Наверное, следует разделить эти методы, прежде всего на внутрикорпоративные, т. е. те сети, которые будут использованы для доступных лиц внутри корпорации и, естественно, распределенных приложений, и Интернет – открытую среду. В интранет реализуются технологии межсетевых экранов, firewalls, технологии, связанные с ограничением безопасности на основе протокола IP и IP-конфигурации во внутренних сетях. Создаются и используются технологии на основе VPN – виртуальных частных сетей, также аутентификация на основе протокола взаимодействия SP.net и специализированное расширение, связанное с безопасностью на основе протокола HTTP – это протокол HTTPS и другие варианты. В интернет-системах можно использовать цифровые подписи, применяемые в связи с протоколом SOAP, а также аутентификацию, основанную на использовании элементов конкретных прикладных систем.

На этом закончим обсуждение веб-сервисов. Это достаточно общий подход, который позволяет объединить возможности, которые реализованы Microsoft в платформе. NET, и распространить их на решения более общего вида, на гетерогенные системы, которые функционируют в существенно более гетерогенных средах и объединяют решения не только Microsoft, но и других производителей, поскольку речь идет о взаимодействии на основе протокола SOA и протокола HTTP, которые являются открытыми, и на основе сообщений, которые кодируются или задаются внутри при помощи языка WSDL, который на самом деле есть диалект XML.

Глава 12 Разработка корпоративной сервисно-ориентированной архитектуры по технологии WCF

Нужно отметить, что существуют и другие подходы к построению распределенных приложений. Ранее был рассмотрен подход, связанный с технологией Remoting, он может использоваться также как расширение веб-сервисов. Сейчас будет рассмотрен еще один подход, который называется Windows Communication Foundations (WCF) и является более открытым и более современным, чем Remoting. Он также предназначен для создания и использования распределенных приложений, т. е. продолжает и развивает концепцию программного обеспечения как сервисов. Рассмотрим особенности общего подхода сервисно-ориентированной архитектуры, которая независима от Microsoft или какого-то другого производителя, является международным стандартом, и реализации этой архитектуры от Microsoft. Это как раз SOAP версия Microsoft. Важными понятиями являются контракты, каналы, связывания. Далее эти элементы и их роль в технологии WCF будут рассмотрены более подробно.

Данная технология является технологией сценарного взаимодействия, когда в зависимости от поведения клиентов реализуются те или иные сценарии обработки данных с сервера. При этом преобразование данных при передаче с клиента серверу и обратно связано с сериализацией и десериализацией, т. е. определенным образом произведенной перекодировкой информации. В связи с этим стоит обсудить понимание терминов «хостинг» и «хост».

Рассмотрим достаточно простой, но важный пример реализации сервиса, по сути, тоже веб-сервиса, на основе технологии WCF. Итак, что такое сервисно-ориентированная архитектура, SOA? Речь идет о том, что это открытый протокол или открытая среда взаимодействия приложений, которая архитектурно основана на использовании сервисов, т. е. реализует концепцию программного обеспечения как сервиса. Естественно, приложения при этом представляют собой распределенные компоненты. Сервисно-ориентированная архитектура регламентирует протоколы и методы, т. е. способы и функции, по которым осуществляется взаимодействие. В концепцию сервисно-ориентированной архитектуры укладываются и веб-сервисы, и технология Remoting, и, конечно же, технология WCF, о которой пойдет речь позднее, и ряд других технологий. Очень важны идеология и подход, связанный с нейтральностью сервисов. То есть при реализации веб-сервисов они остаются независимыми друг от друга и взаимодействуют в независимом режиме. Кроме того, сервисы являются строительными блоками бизнес-процессов, на основе которых осуществляется взаимодействие корпоративных приложений. Каждый такой блок представляет собой либо бизнес-процесс в целом, либо часть этого бизнес-процесса.

Взаимодействие в рамках сервисно-ориентированной архитектуры основано на обмене сообщениями, и эта важная характеристика во многом отличает сервисно-ориентированную архитектуру от других подобных архитектур. Протоколы и технологии взаимодействия являются открытыми: SOAP, XML и т. д. По сути, технология WCF является вариантом реализации Microsoft общей стратегии SOA – сервисно-ориентированной архитектуры, которая была разработана в том числе и корпорацией IBM. Как и другие подходы распределенного взаимодействия на платформе. NET, этот подход связан с использованием библиотеки классов. В данном случае речь пойдет о. NET Framework 3.0 и WCF. Этот подход был разработан, чтобы решить ряд важных задач, в том числе таких, как унификация существующих технологий удаленного взаимодействия приложений, сервисно-ориентированная разработка приложений, т. е. разработка приложений, реализующих концепцию программного обеспечения как сервис, и, что очень важно, кросс-платформенное взаимодействие. То есть подход WCF дает возможность взаимодействия различных платформ. При этом устраняется целый ряд препятствий между корпоративными стандартами от Microsoft, IBM, Sun и других компаний, существует организация WSI Web Service Interability, которая реализует унификацию стандартов и спецификаций взаимодействия приложений, созданных в том числе этими разработчиками. Реализация этих стандартов делает возможным сервисно-ориентированное взаимодействие, в том числе и на основе технологий WCF. Набор стандартов не является монолитным, он реализован таким образом, чтобы давать возможность разработчикам его настраивать, развивать и осуществлять реализацию приложений в достаточно гибком режиме на этой основе. Кроссплатформенное взаимодействие основано на открытых протоколах и позволяет объединить решения от перечисленных производителей на основе целого ряда подходов, связанных с веб-сервисами от Microsoft, NET Remoting, службой распределенных транзакций Enterprise Services и др.

Рассмотрим обобщенную архитектуру WCF. Важными понятиями здесь являются контракты, среда исполнения сервисов, сообщения, хостинг. Контракты определяют целый ряд аспектов взаимодействия между сервисами. При этом существует несколько видов контрактов. Скажем, DataContract, ServiceContract и ряд других. DataContract описывает параметры взаимодействия между сообщениями. MessageContract задает части сообщений в стандартном протоколе SOAP, посредством которого взаимодействуют приложения или их компоненты. ServiceConctract определяет сигнатуру методов сервиса, Policy Bounding Contract – политику безопасности взаимодействия тех протоколов, которые будут использоваться в качестве транспортных, и ряд других аспектов. Среда исполнения определяет поведение сервисов и их обработку в то время, когда осуществляется выполнение кода этих сервисов: в каком режиме осуществляется обработка ошибок, как работает инспекция сообщений, как реализована фильтрация сообщений, как происходит диспетчеризация, т. е., по сути, управление сообщениями, как задаются метаданные, как осуществляется представление метаданных, какое количество экземпляров характеризует каждый сервис. Сообщения, слой сообщений определяет возможные форматы и шаблоны обмена сообщениями в общеархитектурной схеме. Наконец, активация и хостинг определяют последовательность запуска сервисов и контекст протоколов их взаимодействия.

Следующим важным понятием является понятие контракта. Прежде чем мы рассмотрим понятие контракта, представим общую схему, которая описывает модель взаимодействия компонентов приложения в рамках подхода WCF. Здесь следует выделить уровень клиента и уровень сервера. Как клиент, так и сервер взаимодействуют посредством контракта и реализуют определенные сценарии поведения, которые активируются в зависимости от тех особенностей контрактов, которые определяют их взаимодействие. По сути, речь идет о том или ином связывании, т. е. конкретизации особенностей протокола или особенностей вызова этих сценариев. Обмен данными между клиентом и сервером происходит на уровне сообщений. Здесь принципиальным является выбор канала взаимодействия, осуществляемого посредством адресов, между которыми осуществляется обмен сообщениями. Контракт описывает тип сообщений, которыми обмениваются участники взаимодействия, т. е. клиенты и серверы. Кроме того, контракт описывает формат сообщений и другие спецификации.

В WCF реализуются три вида контрактов: контракт сервиса (Service Contract), контракт данных (Data Conctract), контракт сообщения (Message Contract). Контракты сервисов используются для описания функциональности, которую поставляет сервис. Вместе с операционными контрактами они определяют те методы из. NET Framework, которые описывают операции, осуществляемые сервисами, и те конкретные порты, посредством которых осуществляется взаимодействие. Порты описываются на языке WSDL. Здесь мы видим, что технология WCF тесно связана с технологией веб-сервисов. Она использует тот же самый язык описания. Контракты данных описывают структуры данных, которые служат для взаимодействия сервисов. В частности, определяются типы CLR, среды выполнения Common Language Runtime и XSD, т. е. полностью описываются сериализация и десериализация – преобразование данных при передаче от клиента к серверу. Третьим типом контрактов, на основе которых осуществляется взаимодействие в рамках WCF, являются контракты сообщений. Контракты сообщений описывают, каким образом типы среды взаимодействия CLR будут преобразованы на уровне данных в сообщения протокола SOAP. При этом существует возможность гибких настроек этих сообщений в SOAP, как заголовков, так и тел сообщений. Более подробно сервисные контракты определяют интерфейсы конечных точек веб-сервиса. При этом для указания контрактов используются атрибуты Service Contract и Operation Contract, которые применяются соответственно для классов и интерфейсов и для методов веб-сервисов. Данные контракты используются в технологии WCF как при проектировании, так и при выполнении веб-сервисов. При этом на стадии проектирования определяются те классы, которые при описании веб-сервиса должны быть описаны на языке WSDL как конечные точки сервисов, указываются операции, которые будут задействованы в этих элементах.

На стадии выполнения осуществляются поиск и выполнение методов на сервере, которые связаны с активацией тех или иных сервисов. Если речь идет о Service Contract и Operation Contract, то эти атрибуты задают порядок взаимодействия. В том числе возможно как однонаправленное взаимодействие, так и дуплексное. При однонаправленном взаимодействии, которое кодируется свойствам и атрибута Is One Way, клиент получает только подтверждение взаимодействия с веб-сервисом. При дуплексном взаимодействии устанавливается полноценный двунаправленный обмен сообщениями. При этом сообщения могут посылаться как от клиента серверу, так и от сервера клиенту. Сообщения для этого снабжаются соответствующими атрибутами, такими как адрес, способ связывания и контракт: Address, Binding and Contract. В WCF это основа взаимодействия, которая кодируется аббревиатурой ABC: Address, Binding, Contract. Это является важным порядком, по сути, описанием порядка взаимодействия. При таком взаимодействии используется один и тот же транспортный протокол, при необходимости создается новый канал. При этом в дуплексных контрактах используются контракты как клиента, так и сервера.

Обсудив контракты сервисов, переходим к рассмотрению контрактов данных. Данные сервиса представлены типами CLR, с другой стороны, это внутренние типы среды выполнения Common Language Runtime, извне они поступают как описание веб-сервиса на языке WSDL. Таким образом, контракты данных являются связующим звеном между внешним WSDL и внутренним CLR представлением. Для определения контрактов данных используются атрибуты Data Contract и Data Member. При этом Data Contract используется как атрибут класса, а атрибут Data Member используется как атрибут члена этого класса, семейства или как атрибут поля. Важно отметить, что оба эти атрибута – и Data Contract, и Data Member – используются как при проектировании класса, веб-сервиса, так и при его реализации. Контракт данных обеспечивает сериализацию данных, при этом используется атрибут Data Contract Serializer. Контракты сообщений – это третий тип контрактов, определяют собственно представление сообщений в формате SOAP, т. е. то, каким образом внутренние типы CLR будут представлены в формате взаимодействия. С помощью атрибутов контрактов сообщений – это Message Contract, Message Header, Message Body Member – осуществляется управление разработчиком над представлением данных в формате SOAP. Разработчик при этом получает достаточно мощное средство управления контрактами, представлением этих контрактов. Атрибут Message Contract определяет структуру SOAP сообщения, но не определяет их содержания. То есть он не определяет, скажем, нужно ли сворачивать, архивировать тело сообщения или не нужно. Другие атрибуты используются для настройки заголовка и тела сообщения SOAP. Данный вид контрактов не используется вместе с Data Contract. При этом при использовании с Message Contract необходимо наличие только одного входящего и одного исходящего параметра, поскольку осуществляется прямое преобразование в SOAP.

На рис. 12.1 представлен пример контрактов сервиса и контрактов данных. Следующим важным понятием, описывающим взаимодействие между клиентом и сервером, являются каналы обмена данными WCF. Каналы являются средством взаимодействия сообщениями между сервисами и их потребителями, при этом каналы используются как для подготовки сообщений, так и для их доставки. Для подготовки сообщений используются так называемые протокольные каналы, а для доставки – транспортные. В этом смысле существует разделение между каналами. Для транспортных протоколов по технологии WCF используются протоколы HTTP, TCP, WebSphere MQ и др. Также осуществляется взаимодействие в формате точка-точка и так называемые именованные каналы. Существуют и сторонние реализации, при этом используется ряд протоколов, скажем FTP, SMTP, на основе протокола, который используется для доставки почтовых сообщений, UDP и ряд других протоколов, скажем, WebSphere MQ, реализованный для поддержки продуктов корпорации IBM и основанный на передаче сообщений. По сути, речь идет о стеке каналов, т. е. в каналах существует несколько уровней: транспортный и протокольный. Протокольный уровень находится на более высокой позиции в стеке, чем транспортный. Протокольные каналы служат для осуществления транзакций, т. е. взаимодействия между клиентом и сервером посредством элементарных операций, и для шифрования. Таким образом, архитектура WCF дает достаточно высокую степень гибкости при настройке взаимодействия между сервисами и клиентами, которые запрашивают эти сервисы.

Рис. 12.1. Описание контракта сервиса и контракта данных

Для каналов WCF характерны три вида взаимодействия: 1) однонаправленное; 2) дуплексное или полноценное двунаправленное, когда и клиент, и сервер могут посылать друг другу сообщения; 3) взаимодействие по типу запрос – ответ. При рассмотрении контрактов достаточно подробно обсуждались эти виды взаимодействия, в частности однонаправленное и дуплексное. Для реализации этих шаблонов используется ряд интерфейсов, которые упоминались в примерах кода, в том числе такие как ISessionChannel, IInputSessionChannel, IDuplexSessionChannel, IRequestSessionChannel, IReplaySessionChannel, т. е. по сути интерфейсы реализуют каждое из этих конкретных видов взаимодействия. Кроме того, существует единый базовый интерфейс ICommunicationObject, который поддерживает взаимодействие всех классов объектов, участвующих в канальном взаимодействии. Этот общий интерфейс является неизменным для каналов, а также фабрик каналов и механизмов слушания запросов на сервере и используется для реализации всех механизмов взаимодействия. Таким образом, стек каналов представляет собой многоуровневый стек взаимодействия, включает транспортный и протокольный уровни, и может состоять как из одного канала, так и из нескольких. В этом смысле важным является определение «связанный» или Binding. Нужно сказать, что это понятие весьма важно для объектных систем вообще и в математических формализациях с объектными моделями имеет первостепенное значение, скажем, в теории конечных последовательностей в форме λ-исчисления, имеет реализацию в форме связывания переменной со значением. В данном случае под связыванием понимается заранее сконфигурированный стек каналов взаимодействия по технологии WCF. При этом с помощью связывания подход WCF инкапсулирует различные сценарии взаимодействия. Например, Basic HTTP Binding заранее сконфигурирован для взаимодействия со стандартными веб-сервисами по технологии SMX. WSHTTP Binding – для более сложного взаимодействия Web Service Addressing. Ряд других вариантов взаимодействия на основе связывания образует стек каналов, который использует также специализированные элементы, называемые элементами связывания. Всего в WCF определено и может быть использовано до девяти типов связывания. Это, по сути, предопределенные конфигурации, которые используют протоколы HTTP, TCP и др. Если ни одна из этих стандартных конфигураций не удовлетворяет разработчиков, есть возможность создания собственных конфигураций на основе существующих.

Взаимодействие между каналами с использованием механизмов связывания имеет достаточно сложную схему, которая логически представлена в форме следующего алгоритма. Прежде всего выявляется наличие необходимости интероперабельности или взаимодействия с другими платформами. Здесь оно представлено ромбом с надписью «Требуется интероперабельность?». При этом в случае позитивного ответа мы перемещаемся вниз, в случае негативного – вправо. Если интероперабельность требуется, то нужно уточнить, какой именно уровень интероперабельности будет использован: общий, на основе Basic HTTP Binding или более сложный, с поддержкой дуплексного взаимодействия, тогда используется WS Dual HTTP Binding. Если требуется повышенный уровень безопасности, будет использоваться еще один уровень связанности. Таким образом, все девять типов связывания присутствуют в схеме.

Локальное связывание использует подход NET Named Binding, а также очереди на основе MSNQ, с поддержкой расширений, в том числе на основе сервисно-ориентированных продуктов сторонних производителей. Могут быть также организованы сети по принципу точка-точка, и тогда используются механизмы, связанные с NET TCP Binding. Кроме того, может использоваться подход, связанный с NET Pear TCP Binding. То есть может быть использован целый ряд априори сконфигурированных сценариев взаимодействия в рамках этой технологии. Как упоминалось ранее, могут быть использованы дополнительные сценарии на основе существующих, полученные посредством их развития. Важным средством взаимодействия между клиентом и сервером является так называемый сценарий поведения. По сути, это класс, который реализован в рамках технологии WCF, существует в соответствующем пространстве имен и оказывает влияние на поведение системы во время выполнения приложения.

В WCF существуют следующие виды сценариев использования. Это сервисный сценарий или сценарий сервера. Он работает на уровне сервиса, реализован на сервере, имеет доступ ко всем конечным точкам сервера и влияет на поведение системы во время выполнения. Реализация этого сценария по принципу передачи сообщения от одной точки к другой. Кроме того, существует возможность создания пользовательских сценариев использования. Сценарии использования, которые отвечают за сервисы, поддерживают обработку транзакций, авторизацию пользователя на сервере, создания пользователями объектов и изменения этих объектов, а также аудит действий пользователя. Другим классом сценариев поведения является сценарий конечных точек или NetPoints. Здесь работа осуществляется на уровне конечных точек, реализуется инспекция, т. е. осмотр и обработка сообщений, которые поступают на сервер. Еще один сценарий – это Callback, сценарий обратного вызова, аналог сценария, который реализуется для сервера, сценария сервисного, и функционирует на клиенте в режиме дуплексного, т. е. полноценного, взаимодействия между клиентом и сервером. Следующий вид сценариев – сценарии операционные, они используются на уровне отдельных операций и управляют сериализацией, т. е. преобразованием форматов данных при передаче от клиента серверу, и наоборот, а также потоком транзакций, т. е. элементов взаимодействия между клиентом и сервером. Сценарии взаимодействия конечных точек отвечают за обработку данных до и после того, как они попадаются на обработку конечному методу. При этом на клиенте выделяются следующие три вида сценариев поведения: связанные с инспекцией параметров, сообщений и форматирования сообщений. При инспекции параметров данные исследуются, анализируются и преобразуются до их сериализации в XML-представление. При форматировании сообщений данные исследуются и преобразуются во время конвертации в XML в ходе преобразования. И, наконец, при инспекции сообщений представление данных в формате XML преобразуется при трансляции во внутреннее представление Microsoft.NET. При этом на сервере, кроме упомянутых сценариев, реализуются еще два вида специфических для серверной части сценариев. Это выбор операции, т. е. метода, и вызов этой операции. В первом случае рассматривается и анализируется входящее сообщение и происходит определение метода для обработки этого сообщения, того метода, который соответствует этой операции. Во втором случае осуществляется обслуживание этого вызова, т. е. обработка этой операции тем самым методом, который предназначен для нее на сервере.

Рассмотрим некоторые из сервисных сценариев поведения. Заметим, что они определяются соответствующими классами WCF, которые реализованы в. NET. Введем понятие меры параллельности. Это число задач, одновременно выполняемых тем или иным сервисом. То есть таких задач, которые можно понимать как отдельные задачи или отдельные работы. Под временем выполнения задачи будем понимать то время, которое сервис затрачивает на одну задачу. Производительностью будем считать число задач, которые сервис выполняет в единицу времени. Увеличить производительность можно одним из двух способов: либо уменьшить время выполнения, либо увеличить меру параллельности. При этом для задач существуют сценарии поведения, которые называются Instance Context Mode и Concurrency Mode и реализуют соответственно две эти стратегии, увеличивают количество экземпляров сервиса или количество потоков на экземпляр сервиса. Первый класс Instance Context Mode определяет, какое количество экземпляров сервиса будут обслуживать запросы. При этом возможны три режима выполнения: режим Single – единственный экземпляр сервиса для всех запросов, режим Percall – для каждого запроса создается свой отдельный экземпляр сервиса, режим Persession – для каждой сессии создается отдельный экземпляр сервиса. Другой подход связан с числом потоков на экземпляр сервиса и имеет возможные значения: Single, Reentrant, Multiple. Single определяет, что единственный поток имеет доступ к классу сервиса, он может покидать сервисный класс, но обязан вернуться и продолжить операцию. Режим Multiple реализует многопоточный доступ к одному и тому же сервису, а при режиме Reentrant только один поток имеет доступ к классу сервиса. Еще одним важным сценарием поведения является реализованный как класс WCF сценарий Service Meta Data Behaviour, который позволяет публиковать метаданные о сервисе, т. е. все параметры, которые его определяют. Достаточно сказать, что все описание в WSDL-формате может публиковаться этим классом. При этом метаданные предоставляются сервисом посредством конечной точки – Metadata Exchange. То есть существуют специальный формат данных и специальное средство предоставления метаинформации о сервисе.

Как упоминалось ранее, важным средством взаимодействия клиента и сервера при реализации технологии WCF являются транзакции. При этом сценарии поведения на основе этих транзакций могут быть реализованы различными способами. Транзакции бывают двух типов: многошаговые бизнес-процессы и так называемые короткие транзакции, которые, в отличие от первого типа, завершаются достаточно оперативно и затрагивают относительно небольшое количество объектов и связей, зависимостей или ограничений целостности. WCF поддерживает второй вид транзакций, короткие транзакции. Рассмотрим, для чего используется атрибут Operation Behaviour и его свойство Transactionscope Requirement. Это свойство определяет, будет ли операция выполняться в режиме так называемых транзакций, или будет ли транзакция завершаться автоматически (Transaction Scope Complete) при окончании работы метода, или же ее можно будет завершить. В таком случае потребуется поддержка механизма взаимодействия, который реализуется на основе сессий. Важным аспектом взаимодействия между клиентскими и серверными частями приложений по технологии WCF является сериализация и десериализация. Сериализация – это процесс преобразования графа объектов в поток байтов, т. е. в последовательный поток формата XML Info Set. Таким образом, сериализация является эффективным способом сохранения состояния объектов, которое может храниться в базе данных или файле. В WCF состояние объектов хранится исключительно в XML Info Set. Особенность в том, что здесь, в отличие от XML, не задается конкретного формата данных. Используется процесс кодировки, преобразования сообщения WCF в поток байт, во внутреннее представление процесса, и существуют различные виды кодировки, которые доступны в WCF. Всего таких представлений пять. Это двоичный формат, текстовый формат, формат Message Transmission Optimization Mechanism (MTOM), формат, связанный с Java Script, Java Script Object Notation, и формат POX, Plain Old XML, связанный с традиционным XML. При этом выбор кодировки зависит от конкретной ситуации, от конкретных требований ПО по надежности, производительности, интероперабельности, масштабируемости и т. д.

Рассмотрим методы сериализации WCF в сравнении. Произведем сравнение механизмов сериализации, которые реализуются процедурами Data Contract Serializer, Net Data Contract Serializer, XML Serializer и Data Contracts JSON Serializer. Стандартным сериализатором является первый из них, Data Contract Serializer. Он преобразует внутренние типы WCF во внешнее представление XSD, которое является платформенно-независимым. То есть, по сути, не несет связанных с. NET элементов и поэтому может использоваться для взаимодействия со сторонними приложениями, скажем, с приложения, реализованными на основе Java. Для того чтобы этот сериализатор работал с классом, класс необходимо снабдить атрибутом Data Contract, а свойство или поля, которые используются для сериализации, необходимо снабдить атрибутом Data Member. Следующий вид сериализации, Net Data Contract Serializer, близок к первому, но отличается возможностью добавления информации о внутренних типах CLR к тем возможностям, которые имеются у сериализатора по умолчанию. В отличие от первого вида, он используется для. NET приложений и при этом осуществляет взаимодействие между частями этого приложения, причем только одного. NET приложения. Третьим классом, который отвечает за сериализацию, является XML Serializer. Это стандартный сериализатор. NET, который появился еще на уровне Framework 2.0 и сохранился в Framework 3.0. Он позволяет реализовать стандартный механизм сериализации, т. е. работать со стандартными типами. NET, имеет возможность настройки XML-представления, позволяет настраивать выход XML, который генерирует сервис, и работает со стандартными сервисами формата ASP.NET. При этом существуют три основных подхода к использованию данного вида сериализации. Можно использовать стандартную сериализацию, а также атрибуты, связанные с XML: XML Attribute, XML Element. Кроме того, можно использовать интерфейс IXML Serializer, который позволяет организовать взаимодействие с XML-форматом. Еще один важный вид сериализации Data Contract JSON Serializer, который поддерживает стандартную нотацию объектов в формате Java Srcipt.

Важным понятием, характерным для технологии WCF, является понятие host или servicehost. По сути, данное понятие определяет процесс, который несет ответственность за обработку и контекст выполнения веб-сервиса. Это процесс операционной системы, который управляет выполнением сервиса и контекстом, отвечает за старт сервиса, остановку этого сервиса, а также предоставляет важные базовые функции управления сервисом. Хостом сервиса WCF может выступать любой процесс ОС. Такие приложения, как Internet Information Service, Windows Process Activation Service, имеют встроенную поддержку хостинга, т. е. внутреннюю инфраструктуру, которая этот хостинг реализует. Кроме этих подходов можно использовать другой сервис, любой Windows Service, а также любое приложение с пользовательским интерфейсом или консольное приложение для того, чтобы осуществить поддержку хостинга. В зависимости от того, что именно является хостом сервиса, его конфигурация и настройка осуществляются в целом единообразно. Выбор хостинга зависит от требований к приложению, его быстродействию, устойчивости, масштабируемости и т. д. Каждый хост WCF требует реализации трех функциональных элементов: это объект класса ServiceHost, конечная точка и запуск прослушивания сообщений на сервере или процедуры listen.

Перейдем к более подробному описанию среды хостинга Windows (Process) Activation Services или W(P)AS, которая является стандартной средой хостинга (рис. 12.2). Она встроена в новые операционные системы – Windows Vista и серверную ОС Windows Server 2008, поддерживает ряд возможностей, которые раньше были доступны только через Internet Information Service. W(P)AS позволяет размещать сервисы в гибкой среде, которая не требует обязательного использования протокола HTTP. Предположим, что есть однонаправленное взаимодействие с некоторым сервисом и конечный пользователь этого сервиса, который довольно часто находится в отсоединенном от сервиса состоянии. В данном случае в качестве транспортного уровня лучше использовать MSMQ, чем HTTP, который не сохраняет состояния. Или, допустим, у сервиса много клиентов, с которыми он часто обменивается небольшими по размеру сообщениями. В этом протокол HTTP также подходит в меньшей степени, и выгоднее использовать протокол TCP. При этом желательно поддерживать множественность протоколов. Такую возможность дает W(P)AS, эта среда многопротокольная, здесь не требуется обязательное использование протокола обмена HTTP, т. е. осуществляется возможность работы в гибкой среде. Эта возможность поддерживается за счет реализации шаблона Listener Adapter, который абстрагирует слушателей, осуществляющих взаимодействие с процессами, от клиента, от процессов управления.

Рис. 12.2. Схема реализации хостинга в среде W(P)AS

На рис. 12.2, где показана схема взаимодействия процессов различных протоколов с хостом процесса, т. е. с реализацией хостинга на основе технологии W(P)AS, видно, что могут использоваться различные протоколы взаимодействия, и с точки зрения хоста безразлично, каким образом, по какому конкретно протоколу организовано это взаимодействие. Возможно и взаимодействие точка-точка, и взаимодействие по протоколу, который не сохраняет состояние, HTTP, и взаимодействие по TCP-протоколу, и взаимодействие по протоколу, скажем, MSMQ. Рассмотрим небольшой пример веб-сервиса в рамках технологии WCF, который реализует функции калькулятора.

Рассмотренный в предыдущей главе (см. рис. 11.1) пример задействовал всего одну функцию – вычисление квадратного корня. В данном примере будет рассмотрен достаточно простой калькулятор, который осуществляет функции сложения, вычитания, умножения, деления (рис. 12.3). Он заимствован из стандартных примеров кода Microsoft (эти примеры расположены на Micfosoft.Servicemo del. Samples), реализован как интерфейс, который называется ICalculator.

Рис. 12.3. Описание сервиса WCF, реализующего функции калькулятора

На вход каждой операции, которая представляет собой контракт-интерфейс, снабженный атрибутом Service Contract, и в каждой операции мы используем атрибут Operation Contract. Каждая операция представляет собой метод, на вход которого поступают два значения типа Double – число с плавающей точкой двойной точности, выход тоже представляет собой число типа Double. Рассмотрим, каким образом реализуется класс, который выполняет этот контракт. Мы указываем, что это класс общедоступный Calculator Service и использует тот интерфейс, который был ранее определен, определенный нами интерфейсный контракт ICalulator. Контракт реализует соответствующий интерфейс и не требует никаких дополнительных атрибутов. Фактически реализуются те же операции, возвращаются значения суммы, разности, произведения или частного. При этом осуществление вычислений реализуется достаточно наивно, т. е. нет проверки, скажем, на нулевой делитель и других, возможно, важных проверок, которые потребовались бы. Здесь осуществляется просто обращение к стандартным функциям, и будет, видимо, задействовано стандартное исключение CLR, при ошибке, скажем, деления на ноль или другой арифметической ошибке, которая возникнет в случае исключения того или иного рода. Продолжим обсуждение примера – веб-сервиса, который реализует простейший калькулятор. Кроме того, что мы создали описание кода в форме интерфейса и контракта, мы должны реализовать конфигурационный файл, который будет расположен на сервере. Это, естественно, XML-подобное описание, и оно достаточно громоздкое.

В данном случае оно представлено на рис. 12.4. Что характерного в нашем описании сервиса с этой точки зрения можно заметить? Прежде всего, здесь описана конечная точка, через которую ведется взаимодействие. Связывание определено как WSHTTP Binding, т. е. мы используем тип связывания с учетом протокола HTTP. При описании веб-сервиса мы должны определить наше ABC. В рамках выбранной сервисной модели на основе пространства имен System должно быть описано определение, связанное с описанием Calculator Service, который определен ранее, реализует интерфейсный контракт и расположен внутри пространства имен Micfosoft.Servicemodel.Samples. При этом определяется конфигурация поведения Calculator Service Behaviour, а именно какой адрес интерфейса поставляется хостом, где хранится этот интерфейс. Далее указывается необходимый адрес, привязка ABC, которая имеет вид HTTPBinding, и, наконец, интерфейсный контракт, т. е. тот самый интерфейс ICalculator, который у нас описан. Особенности использования связывания типа wsHttpBinding состоят в том, что в качестве протокола взаимодействия используется протокол HTTP, который не сохраняет состояния, и используются стандартные протоколы веб-сервисов WS для организации взаимодействия между клиентом и сервером с точки зрения адресации, безопасности. Сервисы WCF не осуществляют экспорт своих метаданных по умолчанию при такого рода связывании. Для этого сервису необходимо явно указать точку обмена метаданных в виде Metadata Exchange, ее конфигурация явно присутствует в файле конфигурации: явно указаны ABC адрес, связывание и контракт. Вот такое небольшое описание кода завершает наш сервис.

По результатам реализации сервиса осуществляется автоматизированная генерация кода для клиента, которая выполняется при помощи утилиты SWSUtil.exe. Некоторые фрагменты реализации этого кода (рис. 12.5), представляющие собой основные элементы этого кода, выглядят следующим образом: в этом описании присутствуют интерфейсы, которые называются ICalculator и ICalculatorClient. Дано описание класса ICalculatorClient, все, что касается его конечных точек с точки зрения адресов и основных функций, которые он реализует. Функции add, substract, multiply, divide, которые реализованы для этого интерфейса.

Рис. 12.4. Файл конфигурации WCF-сервиса

Заканчивая описание технологий WCF, хочется отметить, что эта технология достаточно зрелая, связана во многом с ядром Indigo, с достаточно поздними реализацией ОС: это прежде всего Windows Vista, Windows Server 2008, и здесь реализуется достаточно открытое по сравнению, скажем, с технологией Remoting, взаимодействие между клиентом и сервером. Как мы видели, существует большое количество возможных протоколов взаимодействия, которые прозрачным образом инкапсулируются в технологии W(P)AS, возможны взаимодействия как по протоколу HTTP, так и по протоколу TCP, MSNQ и т. д. При этом поддерживается взаимодействие не только с приложениями, разработанными на основе технологии. NET, но и на основе целого ряда других технологий. Центральным понятием является понятие хостинга, это реализация процесса, которая отвечает за обработку контекста выполнения сервиса. Принципиально важны процессы преобразования графа объектов в формат XML и обратно, сериализация, десериализация. Существует большое количество сценариев для управления потоками данных как на клиенте, так и на сервере, при этом осуществляется выбор вида данных, которые взаимодействуют, это управление транзакциями, управление безопасностью и т. д. Существует большое количество видов связывания. Для того чтобы осуществить взаимодействие, используется схема ABC, адрес, связывание, контракт. Применяется девять типов связывания, которые зависят от необходимости обеспечить интероперабельное взаимодействие, степень безопасности, вид взаимодействия с учетом используемого протокола, с использованием вида сетевого взаимодействия в его конкретизации: требуется ли связь точка – точка или локальное соединение и т. д. Связь между клиентом и сервером осуществляется на основе каналов, которые представляют собой стек протоколов на основе единого интерфейса ICommunicationObject, каналы при этом делятся на транспортные и протокольные и подразумевают как однонаправленное взаимодействие, так и гибкое взаимодействие по двунаправленной дуплексной схеме. Контракты в WCF имеют троякое представление – для сервисов, для данных и для сообщений и являются важной частью обеспечения взаимодействия между клиентом и сервером по схеме ABC. WCF – это Microsoft-версия реализации стратегии сервисно-ориентированной архитектуры, реализации программного обеспечения как сервиса, она поддерживает все необходимые классы. NET Framework, т. е. большое количество базовых операций и атрибутов по взаимодействию клиента и сервиса, поддерживает технологию Remoting и другие технологии Microsoft, а также дает возможность взаимодействия по открытым протоколам SOAP и HTTP с программным обеспечением других производителей, в том числе на основе стандартизованного языка обмена сообщениями WSDL на основе протокола XML.

Рис. 12.5. Код клиентской части WCF-сервиса

Глава 13 Разработка компонентных корпоративных систем

Эта глава посвящена компонентному программированию, компонентной разработке программных систем, в том числе и корпоративных, и разработке офисных приложений. Как уже говорилось, одним из важных аспектов идеологии. NET является компонентно-ориентированная разработка, которая понимается как развитие объектно-ориентированной парадигмы. Когда обсуждались открытые системы, упоминалось, что компонентный подход достаточно важен при разработке больших открытых систем на основе стандартных протоколов обмена информацией, поскольку в этом случае достаточно легко открываются и используются возможности адаптации, коррекции, развития, расширения программных систем путем изменения относительно небольшой доли кода, заключенного в критически важных компонентах приложения. Компоненты могут разрабатываться в рамках подхода. NET, на разных языках, людьми в географически разных местах и в итоге стыковаться, собираться в приложение. При этом во многом, если говорить о подходе, связанном с. NET, понятие «компонент» близко понятию «сборка». Ниже будет рассмотрена структура сборки, процесс ее дизассемблирования, перевод из языка Microsoft Intermediate Language – промежуточного ассемблера высокого уровня – в язык программирования, например C#. Будет показано, насколько хорошо это делает. NET, а также как выглядят метаданные сборки – те объекты и системные ресурсы, которые требуются компоненту для существования. Все это находится внутри компонента. Необходимо напомнить еще раз, что компонент – это самодостаточная единица с точки зрения развертывания и встраивания в полномасштабное корпоративное приложение.

Вторая тема, которая будет рассмотрена, – это офисные приложения и их разработка на основе 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.

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

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

Например, в группе компаний «Итера» в свое время была реализована система хранения изображений, которая использовала те DLL, которые отвечали за распознавание текста и стандартное его сканирование.

И в этом смысле можно сказать, что были использованы возможности разработки открытых систем на основе компонентов. При этом графический интерфейс у той системы, которая была реализована в «Итере», совсем иной, и существует интеграция с рядом других корпоративных систем. Поскольку речь идет о документах, эта система встроена в систему документооборота.

В общем она имеет мало общего с системой собственно распознавания: там блок сканирования был наиболее важным. Таким образом, компонент – это еще не приложение, но он может быть включен в состав корпоративной системы, о чем свидетельствует приведенный выше пример. Существует система документооборота, а потому следует задаться вопросом, что делать с бумажными документами: каким образом их хранить, каталогизировать, учитывать и вводить в систему. Возможно, можно использовать какой-то компонент, который возьмет на себя значительную часть рутинной работы по осуществлению этих функций.

Конечно, в исходной системе необходимо соблюсти интерфейсы с этим компонентом, для этого существуют интерфейсные и программные контракты, а также определенного рода стандарты на изготовление интерфейсов. Уже упоминалось, что в подходе CORBA, связанном с брокерами объектных запросов, интерфейсы описывались на языке, который так и назывался Interface Definition Language (IDL). Это достаточно известный язык. К сожалению, может быть в силу того, что он является достаточно громоздким и не вполне удобным для описания, подход CORBA такого большого распространения не получил. Но в свое время, кстати, не так давно, лет десять назад, это был очень распространенный подход, на котором строились в том числе и корпоративные системы. При этом, что важно, он не зависел от программной платформы. Можно было объединять как решения на основе операционной системы Microsoft, компоненты, которые функционируют в Microsoft Windows, так и компоненты, которые работают под управлением UNIX-систем. Примерно то же можно сказать про Java Beans – этот подход также позволяет применять компонентные приложения, работающие на основе виртуальной Java-машины, которая погружается в среду операционной системы, т. е. реализуется принцип «написано раз – работает везде». Существует возможность портирования Java-кода или промежуточного кода из одной среды в другую благодаря различиям в реализации Java-машины и, наоборот, стандартам реализации языка Java.

Если говорить о модели, которую поддерживает Microsoft, то она называется компонентной или COM-моделью (Component-Object Model). Компоненто-объектной моделью с расширениями или дальнейшим развитием в форме DCOM является динамическая модель COM и COM+. Правила, по которым взаимодействуют компоненты, определяются самой моделью, при этом в компонентную модель входят правила, описывающие жизненный цикл компонента, т. е. последовательность состояний, через которые он проходит в рамках функционирования той или иной системы или той или иной процедуры в этой системе, когда он, например, активен, находится в кэше, т. е. области оперативной памяти, которая дает возможность быстрого обращения к нему при необходимости, или наоборот пассивен, загружен он или не загружен и т. д. И естественно, между этими состояниями существуют переходы, которые также описываются компонентной моделью. И как уже говорилось, компонент – более узкое понятие, чем программный модуль, если говорить о корпоративных системах, которые строятся по модульному принципу, где под модулем понимается блок, реализующий развитую функциональность и выполняющий большое количество элементарных функций, которые как раз и сводятся к классам, а на более высоком уровне – к компонентам. Интересно отметить, что если рассматривать компоненты, например, такие как DLL, единицы развертывания либо некоторые небольшие независимые модули – небольшие элементы, которые можно встраивать в программные системы, можно говорить о сборке программного обеспечения на заказ с включением в него только тех компонентов, которые нужны пользователю, которые для него принципиальны и которые он покупает. Таким образом, компонентную модель интересно рассматривать как модель распространения коммерческого программного обеспечения, когда поставка продукта осуществляется в виде того или иного набора взаимодействующих компонентов, выбранного пользователем.

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

Это, конечно, COM-модель, по сути, технологический стандарт компании Microsoft, на котором строятся и приложения. NET, и приложения, которые надстраиваются над. NET, в том числе офисные. Другим подходом является технологический стандарт Sun Microsystems – Java Beans или Enterprise Java Beans, в случае корпоративных реализаций. Важно отметить, что по большому счету, за некоторыми незначительными исключениями, Java Beans не является стандартом с языковой интероперабельностью, т. е. зависит от языка программирования. И, к сожалению, при разработке по этому стандарту в основном нужно полагаться на использование языка Java.

Позитивным элементом этой технологии является возможность работы на различных программно-аппаратных платформах, в том числе с точки зрения операционной системы. Поддерживаются не только операционные системы Microsoft Windows, но и ряд других. Но отсутствие языковой интероперабельности, отсутствие возможности создавать компоненты на разных языках программирования, которые идеологически близки, более удобны для разработчика или более соответствуют выбранной предметной области, выбранному классу задач.

Если говорить о классе, о компоненте, который реализует функцию, например логическую функцию управления верхнего уровня целым рядом более мелких классов системы, то, наверное, имело бы смысл использовать язык логического программирования типа Prolog или SmallTalk. Или использовать язык функционального программирования типа Lisp, SML и F#. И F# во многом используется в этом качестве. Если говорить о моделировании функций, о математическом моделировании, то вполне можно использовать функциональный язык типа F#. Если говорить, например, о построении графического интерфейса или интерфейса с операционной системой Windows, то, конечно, лучше использовать языки типа C#. То есть языки, с одной стороны, полностью объектно-ориентированные, а с другой – это родной язык. NЕT, он предельно тесно интегрирован с CLR, со средой выполнения и, собственно, с платформой. NET и ее виртуальной машиной. Поэтому языковая интероперабельность является достаточно важным преимуществом с точки зрения больших корпоративных систем и, конечно, с точки зрения учебного процесса, когда на единой программной платформе, на платформе. NET, можно показать, как строятся не только приложение на основе различных подходов к программированию (логического подхода, объектно-ориентированного подхода, функционального подхода и т. д.), но и гетерогенные предложения, которые представляют собой конгломераты или семейства компонентов, разработанных на различных языках программирования. И еще один подход – CORBA, который основан на построении обобщенной объектной шины для взаимодействия гетерогенных объектов на основе брокеров объектных запросов, т. е., по сути, механизма обмена сообщениями между объектами. К сожалению, он сейчас не так широко распространен в связи с достаточно громоздкими интерфейсами языка определения контрактов, средств взаимодействия между компонентами – IDL. И достаточно сложно представить отображение одного языка реализации в другой, поэтому сегодня не так популярен этот подход. Рассмотрим, каким образом строится приложение из компонентов. Существуют два основных уровня (рис. 13.1). Нижний уровень схематически представлен тремя блоками различной формы с отверстиями – это компонентная среда. По сути, речь идет о. NET и CLR, т. е. NET Framework большого количества классов, которые взаимодействуют друг с другом, и компонентах, построенных на основе этих классов, которые тоже имеют контракты, связаны друг с другом и позволяют разворачивать внешние компоненты – надстроечные компоненты прикладного уровня, которые расположены на уровень выше в виде двух больших блоков, подобных кубикам с различного рода шипами или, наоборот, пазами, схематически представляют собой интерфейсы и описываются контрактами. Каждый компонент имеет интерфейс, даже несколько интерфейсов того или иного рода, которые полностью описываются интерфейсными контрактами, программными контрактами и позволяют компонентам осуществлять взаимодействие на основе компонентной модели. То есть эти контракты в полной мере соответствуют компонентной модели, которая применяется.

Рис. 13.1. Основные элементы компонентных приложений

Нужно сказать, что компоненты, эти два кубика, не могут взаимодействовать только друг с другом, они должны взаимодействовать со средой. Без среды они не могут функционировать, поскольку используют большое количество стандартных ресурсов, например связанных с графическим интерфейсом, работой с памятью и другими стандартными механизмами, которые обеспечивает среда. NET. Компонентная модель, реализованная на нижнем уровне – в данном случае на уровне. NET Framework и схематически представленная тремя большими планками с отверстиями, с интерфейсами для взаимодействия с разного рода компонентами, определяет требования к компонентам, которые работают в рамках этой среды. И, конечно, определяет виды компонентов. Не каждый прикладной компонент, исходя из его интерфейса, может взаимодействовать с любыми системами, со строго определенным набором системных компонентов. Компонентная среда, как уже говорилось, представляет компонентную модель и набор базовых служб, связанных, скажем, с реализацией веб-сервисов, обмена компонентами, работы с памятью, графических интерфейсов, трансляции, компиляции программ, отладки и т. д. Базовые службы, которые представляют собой такие круглые шипы, торчащие из каждого большого системного компонента нижнего уровня, обеспечивают работоспособность набора компонентов, который включает как системные компоненты, так и прикладные или пользовательские, которые встраиваются и располагаются на более высоком уровне.

Уже говорилось об отличии компонента от модуля. Теперь обсудим взаимосвязь понятий «компонент» и «класс», если говорить об объектно-ориентированных языках. Класс не только определяет набор интерфейсов, которые он реализует, но и, как правило, описывает их реализацию, поскольку он явно содержит код методов, код функций, определяющих его возможности. Контракт компонента представляет собой прежде всего сигнатуру, т. е. описание интерфейсов, но не реализацию, не код на конкретном языке программирования, который выполняет те функции, для которых и создан компонент. То есть интерфейс отделен от реализации, если говорить о компоненте. Класс существует исключительно в связи с тем языком программирования, на котором он написан. Java-класс будет выглядеть одним образом, класс на C# – другим, если говорить об F#, то там тоже можно реализовать подобие класса, которое будет выглядеть иначе, и т. д.

Компонент, если это не ограничивается компонентной моделью, к языку не привязывается, т. е., по сути, компонентная модель является для компонента тем же, чем и язык для класса. И еще одно важное отличие, о котором уже упоминалось, – структурно компонент является более крупной единицей, чем класс. Как правило, при обсуждении компонента, представим себе, например, DLL из FineReader, понимается, что этот компонент реализует достаточно больше количество функций, а каждая функция связана с классом – как правило, одна функция при аккуратной реализации соответствует одному классу. Естественно, она может взаимодействовать с другими классами. Но компонент, как правило, является более крупной единицей, чем класс, и, как уже говорилось, более мелкой единицей, чем модуль.

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

Если говорить о платформе. NET, прежде всего необходимо упоминать операционную систему Windows. Существует проект Mono, который направлен на портирование. NET на UNIX-системы. Но этот проект не получил распространения, его результаты не так широко применимы с прикладной точки зрения, как среда. NET для Microsoft Windows. Под. NET Framework понимается не только библиотека классов Framework Class Library, но и CLR. По сути, это системная инфраструктура среды, в которой выполняются приложения. Она определяет особенности проектирования, функционирования, разработки и выполнения программного кода на платформе. Естественно, Microsoft.NET является платформой, т. е. не просто технология разработки программных систем, не просто совокупность средств разработки, таких как Microsoft Visual Studio, это нечто большее, это среда, в том числе и функционирования приложений, именно корпоративных.

Итак, NET Framework включает CLR и среду, которая определяет порядок взаимодействия классов FCL. При этом существует обобщенная спецификация языков программирования CLS – Common Language Specification, представляющая собой процедуру преобразования кода на каждом из языков программирования, который реализован для платформы. NET во внутренний ассемблер высокого уровня, в некий системный код. Ассемблер именно высокого уровня, потому что будут рассмотрены примеры MSIL-кода, и если читателю приходилось работать с ассемблером для какой-то другой классической платформы, например Intel 8080, 8086 или Z80 для компьютеров Sinclair, или Atari, или Yamaha, в прошлом это было достаточно популярно, то будет видно, что одна инструкция MSIL – это примерно 3–5 инструкций такого стандартного ассемблера.

И еще одно важное понятие – это. NET-приложение, прикладная система, разработанная для выполнения на платформе. NET. Важным ограничением здесь является то, что приложение реализуется, даже если это происходит в рамках компонентного подхода – в виде системы компонентов, только на тех языках программирования, которые поддерживает CLS. Следует заметить, что на самом деле можно разработать транслятор для нового языка программирования и встроить его в. NET. Более того, существует курс, достаточно давно (в начале 2000-х гг.) разработанный для студентов второго курса. Они могли в рамках этого курса за один семестр сделать транслятор для языка программирования для. NET и апробировать его. Это был небольшой язык программирования – подмножество языка C#. Но тем не менее этот пример показывает, что создание и реализация языка программирования для. NET – не такая сложная задача. Большое количество авторских коллективов работает над различными языками. Есть компилятор языка SML, который автор использовал для создания курсов введения в теорию программирования, точнее, той его части, которая посвящена функциональному подходу.

Теперь рассмотрим, какого рода функции выполняет среда CLR и как осуществляется работа библиотеки классов. NET. Естественно, CLR загружает и выполняет код, при этом существует понятие управляемого кода. В случае управляемого кода обеспечивается повышенный уровень безопасности, в частности контроль выхода за границы массива, управление динамической памятью, сборка мусора и т. д. CLR в любом случае следит за памятью при размещении объектов, но при безопасном коде ответственность за использование кода лежит на разработчике, а не на пользователе. Изолируются области памяти, в которых выполняются отдельные приложения или процессы приложения. Осуществляется проверка безопасности кода, в основном на основе механизмов сборок, а также подлинности сборки – на основе номера сборки, цифровой подписи автора и т. д. Кроме того, существует политика безопасности, которая определяет форму сборки.

Поговорим более подробно о том, какого рода окружение может функционировать и какого рода операции могут выполняться. Естественно, осуществляется преобразование промежуточного языка MSIL в машинный код. Поддерживается доступ к метаданным, это понятие будет рассмотрено чуть позже. Осуществляется поддержка обработки исключительных ситуаций, в том числе и межъязыковых. Существует иерархия исключений, которая находится в пространстве имен System.Exceptions. И все нестандартные ситуации, которые могут возникать в том или ином языке приложения, который реализован для среды. NET, отслеживаются CLR и обрабатываются стандартным образом. Можно также создавать и свои пользовательские исключения и обрабатывать их. CLR позволяет осуществить взаимодействие между как управляемым, так и неуправляемым кодом, включая COM-объекты (более подробно об этом будет говориться в разделе, который связан с офисными приложениями). Поддерживаются сервисные возможности для приложений, для разработки программных систем. При этом независимо от того языка, который реализован для платформы. NET, все сервисные возможности поддерживаются в полной мере. Это и отладка кода, и тестирование, и профилирование, и кодирование, и документирование и т. д.

Если говорить о другом аспекте платформы. NET – FCL, то это объектно-ориентированная библиотека, которая включает описание классов, интерфейсов и внутренней системы типов. NET – Common Type System (CTS). Важно, что интерфейсы этой библиотеки классов могут использовать абсолютно все приложения, написанные для платформы. NET, независимо от языка программирования и конкретики программной архитектуры этих приложений. Естественно, это касается и встроенных типов, таких как целый, булевский, вещественный, символьный и т. д., а также типов, которые представлены в виде классов. Если говорить о платформе. NET, то постулируется принцип – каждая сущность является объектом. Поэтому все стандартные типы являются классовыми структурами. Кроме того, классы FCL могут использовать все классы Windows Forms (ранее говорилось об этом подходе к построению интерактивного пользовательского интерфейса), классы, предназначенные для разработки веб-сервисов и других приложений, основанных, например, на ESP.NET, это веб-формы, в частности. Классы, которые базируются на стандартных протоколах, предназначены для приложений в сервисно-ориентированной архитектуре, например Windows Communication Foundation, которая основана на стандартных протоколах XML, FTP, HTTP, SML и Soid и, естественно, протоколе, который поддерживает сервисно-ориентированную архитектуру. Кроме того, со стандартным. NET Framework взаимодействуют все классы, предназначенные для разработки приложений, в том числе и офисных, приложений, которые работают с базами данных, в том числе на основе технологии. NET, и ряд других классов.

Еще одним важным аспектом, о котором необходимо говорить в связи с компонентными приложениями, являются сборки. Понятие «сборка» во многом аналогично понятию «компонент», если говорить о среде. NET. Для CLR-среды выполнения сборка является нейтральной, независимой от языка программирования, на котором она была написана, будь это родной язык. NET С#, или F#, или какой-то другой язык, важно чтобы обеспечивалось соответствие CLS и CTS, т. е. системе типизации, системе описания языка, которая погружает язык в виртуальную машину. NET. Сборка – это базовый строительный блок приложения на основе. NET Framework, это некая самодостаточная единица или логическая группа одного или нескольких модулей или файлов-ресурсов. При этом модули в составе сборок выполняются под управлением CLR, и сборка может быть самостоятельным приложением, скажем EXE-файлом или динамически подключаемым библиотечным модулем. О DLL-библиотеках уже говорилось, и это тоже формат представления сборки.

Важным понятием является также манифест, или декларация сборки, по сути, это совокупность всех метаданных сборки. То есть служебная информация, которая описывает все ресурсы, необходимые для того, чтобы сборка могла функционировать в среде. NET. Манифест включает все классы и ресурсы, т. е. внешние по отношению к сборке элементы, которые необходимо привлечь, а также те ресурсы, которые экспортируются из сборки наружу, перечисляет зависимости от других сборок, т. е. каким образом сборка функционирует в среде, указывает набор прав, необходимых для корректной работы сборки, цифровую подпись, имя и версию сборки. Приведенная ниже схема (рис. 13.2) иллюстрирует трансляцию и выполнение приложения или сборки, поскольку приложение строится на основе сборок и является совокупностью сборок в среде CLR.

Рис. 13.2. Схема выполнения. NET-приложения в среде CLR

Исходным пунктом является текст, код на одном из языков, который поддерживается CLS и, скажем так, сертифицирован для. NET. Используется стандартный компилятор. NET или внешний компилятор, разработанный для. NET. И происходит трансляция в сборку. Подобная схема уже была рассмотрена, в ней присутствовали фрагменты кода, фрагменты приложений на языках C#, SML, F#, Visual Basic и т. д. В итоге получаются сборки в формате либо DLL, либо EXE. Внутрь этих файлов включены фрагменты кода на MSIL и необходимые метаданные сборки: классы, ресурсы, цифровые подписи, автор, версия и т. д. Далее осуществляется взаимодействие этих метаданных. Загрузчик объединяет их вместе с требуемыми ресурсами из библиотек базовых классов стандартного. NET Framework. Затем JIT компилятор осуществляет финальную трансляцию и сборку этих элементов в среде выполнения и собственно выполнение приложения.

При этом важным понятием является домен приложения, ранее говорилось о доменах в связи с технологией Remoting и другими технологиями, которые осуществляют создание и поддержку распределенных приложений в среде. NET, в частности WCF, веб-сервисы. Речь идет о логическом контейнере сборок, который применяется для осуществления локализации или изоляции приложения внутри процесса. Какие важные свойства доменов нужно запомнить, говоря о компонентных приложениях? Во-первых, что домены изолированы друг от друга. CLR может осуществлять загрузку и выгрузку домена со всеми сборками, которые участвуют в этих доменах. Возможно осуществление дополнительных конфигурационных настроек и надстроек, связанных с обеспечением безопасности, применительно к каждому из доменов. Технологии маршаллинга, о которых уже упоминалось, – это передача данных между границами доменов или процессов. При этом такой обмен данными осуществляется в безопасном режиме. Известно, что существует маршаллинг по имени, по значению, по ссылке. Кроме того, доменная модель поддержана на уровне. NET Framework, существует компонентная модель, в которой основными элементами являются сборки. А если берется более широкая модель COM-объектов, в частности, как это, скажем, происходит при работе с офисными или другими приложениями, что используются внутренние механизмы, которые называются COM InterOP и обеспечивают интероперабельность, взаимодействие. NET-объектов с COM-объектами, по сути, NET-сборок с COM-объектами, и наоборот. При этом не требуется регистрации компонентов в реестре Windows, если речь идет о. NET-приложении.

Что касается видов сборок, выделяются частные и общие, Private и Shared или разделяемые сборки. Если речь идет о частной сборке, то тот набор типов, который в ней описан, может быть использован только приложениями, в состав которых входит эта сборка. Если речь идет о сборках общего доступа, что они могут использоваться любым количеством приложений, не обязательно ограниченным на клиентском компьютере. Ранее говорилось о взаимодействии. NET-компонентов, т. е. по сути – сборок и COM-объектов – более общего класса компонентов. Взаимодействие этих компонентов в среде CLR реализовано на основе механизма оберток или временных оболочек Runtime Callable Wrapper (RCW), который инкапсулирует различия между управляемым и неуправляемым кодом.

NET-сборка содержит управляемый код, COM-объект, вообще говоря, содержит код неуправляемый. Такого рода оболочки или обертки позволяют управлять жизненным циклом COM-объектов, передавать вызовы между управляемым и неуправляемым кодами и осуществлять преобразование параметров методов. Во многом этот подход схож с концепцией веб-сервисов и реализацией сервис-ориентированной архитектуры. То есть более общего расширения, когда можно строить взаимодействующие компоненты, не только созданные под управлением. NET для CLR, но и сторонние компоненты, взаимодействующие по стандартным протоколам типа SOAP и осуществляющие взаимодействие между компонентами корпоративных приложений, построенных на основе той или компонентной модели.

При вызове COM-клиента. NET-среда CLR создает всего одну оболочку, всего одну обертку, независимо от количества ссылок на объект. Это происходит для того, чтобы все обращения к объекту осуществлялись централизованно, единообразно, только посредством этой оболочки. Кроме того, на основе метаданных создаются вызываемый объект и оболочка или обертка для возврата данных, т. е. для передачи данных обратно от. NET-среды COM-клиенту.

Обертка осуществляет управление сборкой мусора на уровне среды CLR. При этом разработка существенно упрощается, поскольку от программиста не требуется слежение за динамической памятью и своевременное ее освобождение. Содержимое сборки можно посмотреть, запустив программу, которая называется ILDAsm.exe (Intermediate Language Dis Assembler). Это достаточно интересная программа с точки зрения ее функционирования, потому что она является очень мощной и восстанавливает код фактически с точностью до идентификаторов. Если говорить об обычном дизассмеблере, то, как правило, он вместо идентификаторов вставляет какие-то свои, системные переменные, и код достаточно тяжело читать. Если для примера рассмотреть простое консольное приложение на C#, которое выводит единственное сообщение на экран – «Hello World», то видно, что оно имеет очень много идентификаторов. Вот SimpleApp – пространство имен, класс у нас называется Class1 и никак иначе, и использует стандартную функцию WriteLine внутри стандартного метода Main.

Посмотрим, как работает ILDAsm, если его запустить применительно к сборке, которая получена из этого приложения. Восстанавливается весь вид сборки, при этом в MSIL-коде присутствуют все идентификаторы, которые были в C#. Идентификатор Class1: существует вызов стандартной процедуры WriteLine с использованием единственного параметра String, при этом используется пространство имен System, и внутри используется класс Console, его метод WriteLine. Несколько иначе выставляются обозначения, но этот текст очень легко читается, несмотря на то, что это ассемблер. Он загружает строчку в память, вызывает функцию и осуществляет возврат управления из этой процедуры.

На уровень выше используется частный метод, он сохраняет все атрибуты, связанные с доступом, все идентификаторы доступа и представленные в графическом виде метаданные сборки. Это манифест, т. е. метаданные сборки, которые получены из приложения SimpleApp.exe, т. е. из EXE-файла, который, казалось бы, не должен был содержать ничего указывающего на идентификаторы, но восстанавливаются название приложения, имя Class1 и абсолютно все метаданные, все ресурсы.

Кроме того, существует средство Reflection, которое позволяет восстановить по DLL или по EXE-файлу, т. е. по сборке, собственно код. И код, который видно на экране, – фактически наш исходный код, написанный на C#. Если использовать средство Reflection, можно восстановить код из exe-файла фактически в том виде, в котором он был написан автором. Это таит в себе неприятности и опасности, поскольку надо каким-то образом защищать авторское право и код от просмотра. Существует средство, которое называется Obfuscator, или запутыватель. Оно внедряет ряд переходов, разбивает процедуры на более мелкие, в общем меняет структуру кода таким образом, чтобы было сложно, глядя на него, сказать, какой именно метод и из какого именно места программы вызывается. Таким образом, Microsoft борется с возможностью восстановления прямого кода. Но нужно сказать, что Reflection – очень сильное средство, если не защищать код специальным образом.

Подводя итог, следует отметить, что компонентный подход является развитием объектно-ориентированного подхода к разработке программных систем и имеет ряд важных преимуществ. Во-первых, это снижение стоимости разработки программного обеспечения, прежде всего прикладного, в данном случае корпоративных систем. Во-вторых, появляется больше возможностей для повторного и многократного использования кода. Тот код, который создан в виде сборок, имеет стандартные интерфейсы, реализует стандартные функции, и если проектирование ведется целенаправленно, с целью обеспечить максимальную долю многократно используемого кода, то композиция компонентов будет произведена таким образом, что эти самые компоненты, эти самые сборки пригодятся разработчикам при использовании в новых проектах. При этом, естественно, если потребуется коррекция кода программных продуктов, которые были разработаны, во-первых, можно ограничиться крайне незначительным изменением, в идеале – одной сборки или небольшого количества сборок, которые взаимосвязаны или связаны с той функциональностью, которая меняется или дорабатывается в рамках нового технического задания или нового соглашения, разработанного с заказчиком. И во-вторых, концепция компонента является универсальной и не зависит от подхода к разработке программных систем. Неважно, создается ли код на объектно-ориентированном или на функциональном языке, в рамках. NET с точки зрения CLR то, что разработано, есть компонент. Будь это dll библиотека или exe-модуль. Важно, что этот компонент можно переработать, если нужно переработать только его или только несколько компонентов, а остальной продукт оставить без изменений. Используя стандартные интерфейсы, можно переработать эти компоненты на любых языках программирования, или просто выбросить одни компоненты и заменить их другими, используя те языки программирования, которые поддерживаются. NET, а прочие компоненты оставить без изменения и таким образом обеспечить экономичную разработку, высокий процент повторного использования и хорошую сопровождаемость. То есть вносить изменения быстро и в ограниченные фрагменты кода.

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

Глава 14 Разработка офисно-ориентированных систем по технологии VSTO

Перейдем к офисным приложениям, или библиотеке приложений на основе Microsoft Office System, которая поддержана Visual Studio Tools для. NET. Естественно, офисные приложения строятся на основе компонентной модели, при этом они могут включать как компоненты в форме сборок для. NET, так и сторонние объекты, например разработанные в рамках COM-модели. Но здесь над. NET как платформой появляется еще одна настройка, которую тоже можно назвать платформой, – Microsoft Office System. То есть появляется новая среда разработки и новая среда или новый уровень среды разработки и функционирования компонентов приложения. Будет обсуждено, какие преимущества имеются у Microsoft Office при использовании ее как платформы, какие средства интеграции используются для Microsoft Office System с известной и достаточно мощной средой разработки Microsoft Visual Studio.

Существует специальное средство, которое называется Microsoft Visual Tools for Microsoft Office System. Как применяется CLR, как среда CLR управляет приложениями, которые созданы на такой сложной, уже, наверное, трехступенчатой системе, где внизу находится Windows, далее – библиотека классов. NET Framework, затем, на уровень выше, – библиотека классов для офисных приложений Microsoft Office System. Более того, будет обсуждено, какие преимущества дает Visual Studio Tools for Microsoft Office, или VSTO. Будут рассмотрены элементы, которые содержатся в 2005 VSTO, в том числе по сравнению с предыдущей версией 2003, какие компоненты можно строить для расширения Office. Также будут затронуты панели действия, Smart Tag. Если написать в Microsoft Word некоторое слово, которое является, предположим, географическим названием, оно выделяется особым образом – при наведении мыши появляется буковка I, и слово подсвечивается, поясняется, что это Smart Tag и где это слово находится на карте. Каким образом осуществляется поддержка на уровне схем, что такое кэширование данных и их размещение в оперативной памяти и использование при частой потребности в них. Каким образом осуществляется связь приложений Microsoft Outlook с другими офисными приложениями. Как реализована модель безопасности, насколько тесно она интегрирована с общей моделью безопасности в среде. NET. Каким образом осуществляется модель развертывания приложений. Как работает технология ClickOnce, которая работает и для офисных приложений, не только для приложений. NET. И посмотрим на Actions Pane – модель команд, как реализовать код, который осуществляет создание меню, создание кнопок меню и обработку событий связанными с этими кнопками.

Следует сказать, что сейчас Microsoft Office System представляет собой единую среду взаимодействия большого количества офисных приложений. Это уже упомянутые нами Word, Outlook, Excel и другие приложения, в том числе в версии 2005 появилась поддержка Info Path – средств поиска. И в целом стратегия компании Microsoft сводится к тому, чтобы на основе обобщенной объектной модели, COM-модели, обеспечить взаимодействие всех продуктов Microsoft Office. И до того как рассмотреть расширения для Visual Studio for Microsoft Office System, нужно обсудить саму платформу.

Выясняется, что средства взаимодействия на основе, например, Object Linking and Embedding (OLE) существуют достаточно давно, и вообще интеграция офисных приложений ведется Microsoft уже более 10 лет. Существуют уже три модели интеграции бизнес-приложений с Microsoft Office. Это ручная интеграция, внешняя автоматизация и интеграция на уровне приложений. Кроме того, существует модель, которая поддерживает обмен данными на основе документов. Ручная интеграция представляет собой обмен информацией в режиме Cut&Paste, например, когда из одного приложения, из Excel или Access, вырезается диаграмма и вставляется в Word. Важные недостатки этой интеграции – низкая производительность, часто не вполне корректная работа, возможность внесения ручных ошибок. Поэтому предпочтительнее модель внешней автоматизации, использующая Office как сервер COM-объектов, который можно назвать внепроцессным. При этом наиболее частый сценарий для данной модели – генерация и редактирование офисных документов. К сожалению, нет возможности обеспечить 100 %-ю функциональную поддержку всех возможностей продуктов семейства Office, и в ряде случаев необходимо реализовывать собственный пользовательский интерфейс. Сервисные сценарии на основе, например ISP, не вполне реализуемы при этом подходе. Таким образом, модель внешней автоматизации также имеет ряд недостатков. Если говорить об интеграции на основе документов – это достаточно серьезное решение. Раньше такая интеграция, например между Word, Excel и Access, производилась на основе макросов, которые в основном писались на языке Visual Basic, теперь существует единая платформа – VSTO и можно создавать полноценные бизнес-приложения на различных языках платформы. NET.

Пожалуй, самый серьезный способ – это интеграция на уровне приложений. При этом создаются надстройки или расширения, которые называются AddIn для офисных приложений. Так же, как это происходит, например, с продуктами Adobe, когда документы Office можно конвертировать в файл формата PDF для Adobe Acrobat.

В VSTO используются два последних вида интеграции – интеграция на уровне документов и на уровне приложений. И в том и другом случае можно использовать достаточно большой спектр языков, которые предназначены для написания управляемого кода. В.NET, например, C# или Visual Basic. При этом VSTO дополняет VB for Applications, который пригоден для решения иных задач. В чем состоят преимущества использования Office System как платформы? Прежде всего, исчезает необходимость использования Cut&Paste, ручного переноса данных или актуализации данных. Теперь приложения могут извлекать данные, можно сказать, самостоятельно через документы, которые связаны с живыми бизнес-данными. Поэтому отпадает необходимость выполнения рутинных операций копирования данных. Кроме того, пользователям проще работать в единой среде, используя известные подходы к разработке, если это офисная среда, почти не требуется затрат на обучение пользователей. И наконец существенно снижается время разработки приложений, поскольку, если используется разработка на основе интеграции, на основе приложений, на основе AddIn, то, по сути, строятся некие надстройки над платформой Microsoft Office System, и в этом смысле трудозатраты минимизируются. Платформа VSTO (вернее, средство VSTO) возникла прежде всего потому, что появилась возможность объединить разработку приложений для. NET и для Microsoft Office. Используется полный доступ ко всем без исключения классам стандартной библиотеки классов. NET Framework, о которой говорилось ранее, в связи с компонентными приложениями.

При этом можно использовать не только классы. NET Framework, но и все объектно-ориентированные языковые конструкции, наследование, стандартные системные процедуры для обработки исключений, построение частичных классов, генерализацию или обобщение, вызов веб-сервисов. Более того, использование VSTO значительно расширяет тот спектр инструментальных возможностей и средств, которые были доступны в более ранних версиях среды. Совместное применение VSTO и Office дает возможность, как уже говорилось, объединить документы с живыми, постоянно меняющимися бизнес-данными, что особенно важно для корпораций, где данные могут обрабатываться большим количеством пользователей одновременно, часто претерпевают изменения и необходимы способы их актуализации в привычной для пользователя офисной среде.

Это реализовано на основе технологии интеллектуальных, или разумных, документов Smart Documents, которые имеют встроенные возможности соединения с данными, извлечения данных из гетерогенных источников, например на основе стандарта XML, из других документов и консолидации данных, подготовки отчетной информации. Интеллектуальные документы имеют знание о том, как связываться с данными. Как уже говорилось, одной из важных технологий создания интеллектуальных документов является XML-формат офисных документов. Можно создавать также расширенные XML-схемы и производить интеграцию интерфейсов на основе панели задач – Action Tasks Pane. Возможности технологий Smart Documents и Action Panes изображены на рис. 14.1.

Рис. 14.1. Возможности технологий Smart Documents и Action Panes

Что касается возможностей, которые предоставляет интеграция VSTO со средой. NET, это, прежде всего, расширенное использование средств CLR. При этом на различных языках программирования, например Visual Basic или Visual C#, можно создавать сборки, которые выполняются под управлением CLR. Код при этом становится управляемым и позволяет обеспечить высокий уровень безопасности. Если приложения созданы на основе языков, например Visual Basic for Applications, или код на основе использования COM-модели, тогда представлен неуправляемый код, который можно использовать, но с ограничениями по безопасности.

Важно, что теперь появляется возможность разработки и использования кода на основе. NET Framework и под управлением среды CLR. Общеязыковая среда управляет распределением памяти и следит за безопасностью кода, в том числе за корректностью областей памяти, которые используются, за сборкой мусора и т. д. Естественно, CLR обеспечивает взаимодействие с. NET Framework и использование, например, наследования от тех базовых классов, которые имеются в соответствующих библиотеках очень серьезного объема. При помощи этих инструментов можно создать, например, систему документооборота, которая осуществляет ряд проверок, связанных с визированием документов, юридической корректностью и т. д. Или можно создать решение для прогнозирования продаж, которое в качестве интерфейса пользователя использует Excel и при изменении тенденции или прогноза цен может вносить изменения в централизованную базу данных, что очень важно для корпоративных приложений и систем, которые используются в корпорациях, поскольку, во-первых, появляется централизация управления информацией, и, во-вторых, она реализуется для пользователей в стандартном интерфейсе Microsoft Office, к которому они привыкли и который не требует дообучения.

Несмотря на то что с помощью управляемого кода можно обеспечить автоматизацию операций в Excel и Word, требуется наличие внешнего приложения как надстройки, которое взаимодействует с теми или иными приложением Office и извлекает из него данные. Это то, что можно было видеть в предыдущих версиях. Теперь же можно говорить о сборках, которые разработаны на. NET Framework и под управлением VSTO и позволяют коду взаимодействовать с офисным приложением на более тонком уровне.

Большее количество ограничений связано с использованием COM-расширений. Здесь тоже можно применять управляемый код, но если нужна более тесная интеграция и ориентация на управляемый код и более высокую безопасность, имеет смысл использовать VSTO, которая работает с естественной средой приложения. NET Framework. Система VSTO позволяет создавать приложения офисного класса, которые не только основаны на управляемом коде, погружены в среду. NET, используют. NET Framework, но и могут выполняться изнутри документа. То есть похожи на макросы, которые встраиваются в документ. Но если говорить, например, о VBfA-приложениях, по сути макросах, то отличие кода, который был создан для VSTO, состоит в том, что этот код разработан для. NET, т. е. представляет собой сборку. Сборка хранится отдельно от документа, и можно, не затрагивая документ, произвести коррекцию сборки, ее функциональной направленности и ее обновление. Кроме того, в отличие от VBfA, предоставляющего собой интерпретируемый код, который нужно каждый раз выполнять при запуске документа, интерпретировать заново, сборка является уже откомпилированным кодом, ее выполнение происходит гораздо оперативнее и способствует повышению производительности, что крайне важно для корпоративных приложений.

Естественно, код, созданный с помощью VSTO, обладает всеми преимуществами приложений на платформе. NET, если говорить о VBfA коде. Конечно, макросы являются небезопасными: существует достаточно большое количество вирусов, которые распространяются вместе с этими макросами и достаточно быстро расходятся по корпорациям внутри соответствующих документов. Если говорить о сборках, то каждая сборка идентифицируется цифровой подписью, автором сборки, версией сборки и политикой безопасности, которая дает возможность ограничения тех документов, с которыми она будет использоваться, тех операций, которые она может выполнять. Это будет более подробно обсуждено дальше. Важно отметить возможность применения всех технологий, которые поддерживаются платформой. NET, и всем инструментарием, который реализован на этой платформе.

Что можно отметить нового в среде VSTO 2005 по сравнению с предыдущими версиями. По сути, речь идет о более тесном взаимодействии с. NET и более тесной интеграции офисных приложений, а также взаимодействии со сторонними приложениями на основе COM-модели. Итак, основными нововведениями можно считать: поддержку компонентов интерфейса, который создан на основе средств. NET, поддержку расширенных компонентов Office, панели действия, Action Pane и Smart Tag, возможность создания Smart Tag. Рассмотрим более подробно функции, которые появились в VSTO 2005. Очевидно, что кроме локальной работы и поддержки всех возможностей основных продуктов Microsoft Word и Excel возникает возможность создания панелей задач с использованием средств. NET, полной поддержкой веб-служб посредством. NET Framework, возможностью offline работы с документами, кэширования и использования кэш-сервера. Появилась возможность использовать все сервисные функции Visual Studio.NET, в том числе отладчик, при построении приложений на базе Office, использовать расширение Visual Studio для создания приложений на основе Office и расширить средства обеспечения безопасности с использованием стандартных политик безопасности, криптографической защиты информации, а также достаточно широкий спектр возможностей, связанных с интеграцией приложений на основе XML-технологии.

Наконец, последнее нововведение, которое следует отметить и которое будет проиллюстрировано далее более подробно, – это модель облегченного и ускоренного разворачивания приложения (в идеале – одним щелчком), которая называется ClickOnce. Такая возможность осуществима благодаря использованию погружения в среду CLR и теснейшей интеграции VSTO c библиотекой классов. NET Framework. Что касается объектов Word и Excel, объектов основных офисных приложений, то с ними взаимодействует большинство офисных пользователей и, наверное, все без исключения корпоративные, если они пользуются Microsoft Office. Расширения связаны с целым спектром компонентов, которые доступны через стандартную панель компонентов: можно наблюдать и изменять их свойства в Properties Explorer, т. е. стандартном средстве Visual Studio, можно менять свойства, исследовать и настраивать свойства офисных компонентов, прежде всего приложений Word и Excel. При этом возможны программный доступ через именованные поля, а также связь с данными, т. е. извлечение живых данных, коррекция и обновление данных, в том числе и расположенных на удаленных серверах, поддержка событийной модели.

Ранее, в главе о Windows Forms, было показано, каким образом осуществляется привязка скрипта или фрагмента кода к событию, определенному действию пользователя, например щелчку левой кнопкой мыши по полю формы. Практически таким же образом можно взаимодействовать с офисными приложениями Word и Excel стандартными средствами Visual Studio. Расширенные компоненты приложений либо представляют собой расширения функциональности, либо позволяют добавить функциональность, которая отсутствует на уровне традиционной объектной модели. Если в Excel объектная модель доступна через пространство имен, InterOp (Microsoft.Office.InterOp.Excel), то здесь поддерживается дополнительно целый ряд объектов, например стандартной объектной моделью Excel поддерживаются только события на уровне листа и книги, и в ней невозможна привязка данных таким образом, как это реализовано в Windows Forms, например, когда рассматривался навигатор, который позволяет извлекать данные. Несмотря на то что в управляемом коде некоторые объекты, например Name-ListObject недоступны напрямую, использование расширенных компонентов позволяет обратиться к этим объектам. Таким образом, в VSTO 2005 реализован ряд расширенных компонентов для Excel, таких как NameRange, XML markering, Chart, ListObject и др. Кроме того, применение расширенных компонентов в отношении текстового процессора Word открывает доступ к ранее недоступным в стандартной модели компонентам. Это связано с извлечением данных, с использованием формата XML, а также манипуляцией с закладками (bookmark). При этом поддерживаются события, которые связаны с обработкой закладок и отсутствуют в стандартной объектной модели. Компоненты XML-note и XML-notes реализуют работу с XML-документами стандартной панели задач и поддерживают реализацию целого ряда событий, включая проверку корректности документа.

Поговорим подробнее о панели задач. Собственно все дальнейшее обсуждение будет посвящено настройке панели задач, ее управлению программным путем. В итоге будет рассмотрена программа или фрагмент программы на C#, который осуществляет настройку этой панели задач, дополнение туда новых командных кнопок и средств обработки событий. Сначала рассмотрим, что такое Action Pane, или панель задач, чем панель задач в VSTO 2003 отличается от более поздней версии 2005 и какого рода возможности поддерживаются. По сути, речь идет о настройке функционирования документов и гибкого конфигурирования возможностей работы с ними. Впервые это было реализовано в продуктах Microsoft Word и Excel 2003 в версии Professional и с точки зрения VSTO было добавлено в версию 2005. Речь идет о программных объектах Word и Excel и возможности настройки их атрибутов и действий с ними посредством механизмов Visual Studio. Если говорить об Excel, то существует класс Exсel.Workbook – рабочая книга Excel, который доступен из VSTO 2005. Точно так же можно настраивать свойства документа Word (Word.Document). При этом та программная модель, которая поддерживается панелью задач, во многом похожа на модель Windows Forms, рассмотренную ранее. То есть можно создавать объекты стандартных классов, настраивать их свойства и устанавливать реакцию на определенные события, которые инициируются пользователем или системой. При этом, так же как и в Windows Forms, программная модель является достаточно простой, и не требуется реализация сложных интерфейсов для инициализации или создания панели задач, например такого интерфейса, как Smart Document, который описывает интеллектуальные документы.

Необходимо отметить, что и предыдущая технология, которая базировалась на интеллектуальных документах Smart Documents, обладала многими возможностями для настройки свойств документов Word и Excel, и практически программирование панели задач в том же объеме было возможно на основе этой технологии. Однако предыдущая модель Smart Documents была доступна посредством Smart Doc SDK – средства разработки приложений, и в основе этого SDK, как и в основе многих открытых средств, лежала COM-модель, а не. NET Framework. Поэтому данная технология имела целый ряд ограничений с точки зрения и управляемости, и безопасности. В частности, если в подходе Smart Documents требовалась явная реализация интерфейса Smart Document, то здесь она не требуется, VSTO 2005 автоматически поддерживает все необходимые свойства и настройка происходит в автоматизированном режиме. Если для работы с SDK на основе Smart Documents требовалась установка так называемого XML Expansion Pack – средства расширения для работы с документами формата XML, то здесь этого делать не нужно, это средство фактически встроено в VSTO. Документы Word, которые построены на основе XML, были необходимы для работы с технологией Smart Documents. В случае работы с панелью задач, с новой технологией, которая поддерживается в VSTO 2005, это также не нужно. По крайней мере необязательно. Это является опцией, при этом можно создавать приложения, которые не основаны на XML-стандарте. И наконец, компонентный подход с точки зрения Smart Doc SDK был основан на COM-модели и на ActiveX компонентах. Здесь, если говорить об Action Pane, речь идет о возможности поддержки компонентов Windows Forms, которые являются стандартным расширением технологии. NET Framework и классы которых, как известно, имеются в пространстве имен System, т. е. явным образом задаются в стандартных классах расширений для платформы. NET. Таким образом, ограничения, которые существовали в предыдущем подходе для работы с интеллектуальными документами, для интеллектуальной обработки документов в среде Microsoft Office на новой платформе в рамках VSTO 2005 были преодолены.

Еще один важный аспект технологии VSTO – это Smart Tag. Smart Tag (или интеллектуальные ярлыки) – это способ разметки документа, который на основе специализированной технологии связывает некие фрагменты документа, особым образом помеченные и распознанные, с тем или иным набором действий, т. е. с некоторым скриптом, с некоторым кодом, например на языке C#, который позволяет по возникновении тех или иных событий реагировать на них соответственно. По сути, документ Microsoft Office представляет собой некоторый набор специальных областей, к которым привязаны, как, например, к элементам управления Windows Forms, определенные действия, определенные фрагменты программного кода. При этом, естественно, открывается возможность реализации контекстно-зависимых действий на уровне документов. То есть в зависимости от контекста, от вида документа, можно предпринимать те или иные действия. В VSTO 2005 существует специальный класс для создания Smart Tag, применение которого дает возможность доступа к ряду коллекций классов, связанных со стандартными терминами и выражениями, а также ассоциативную связь с коллекцией Actions, т. е. с коллекцией стандартных действий.

Кроме того, для реализации событийной модели открывается возможность использования делегатов. NET. Делегаты – это специальный класс, аналог указателей на функции, которые стандартно существуют в. NET и применяются для обработки событий. Этот механизм возник в языке C# и поддерживается на всей платформе. NET как стандартное средство реализации событийной модели. Важно, что Smart Tag являются динамически настраиваемыми и интерактивными элементами. Они могут динамически распознавать и обрабатывать те или иные данные, которые находятся в документах, в специализированных их фрагментах на основании типа их содержимого. Таким образом, Smart Tag можно называть настраиваемыми.

И целый ряд приложений Office 2003 поддерживает эту технологию, технологию динамически настраиваемых Smart Tag. Это Word, Excel, PowerPoint, Outlook, Access и другие приложения семейства Office. При этом можно осуществлять ассоциативное связывание выбранных Smart Tag с выбранными элементами приложений Excel и Access, ячейками таблиц или полями баз данных. При таком подходе существуют также расширенные возможности Smart Tag, которые включают связывание с XML-элементами и автоматизированное выполнение действий при распознавании того или иного класса Smart Tag. То есть можно осуществлять динамическое взаимодействие пользователя, во многом автоматизированное, с определенными классами фрагментов офисных приложений в достаточно широком диапазоне. Это и текстовые редакторы, и электронные таблицы, и базы данных, и средства взаимодействия между пользователями, и почтовые клиенты, и т. д.

При осуществлении этих двух усовершенствований, динамического распознавания и обработки данных на основании типа их содержимого, и динамического связывания с определенными фрагментами, ячейками Excel или полями баз данных Access, существенно повышается эффективность технологии или концепции Smart Clients – умных клиентов в интегрированных корпоративных приложениях Microsoft Office. Например, при связывании действий Smart Tag с элементами XML или при автоматическом запуске тех или иных действий при распознавании определенных классов Smart Tag умные клиенты могут автоматически получать метаданные по мере их ввода или обновлять данные определенной части приложения или связанных приложений в реальном масштабе времени в зависимости от характера и типа информации, которая вводится в другую часть, т. е. с другой стороны, в другой элемент этих офисных приложений.

По сути, речь может идти о многофункциональных распределенных системах, которые содержат в качестве компонентов интегрированные документы, таблицы, базы данных, средства взаимодействия, в том числе по электронной почте, и в зависимости от тех или иных действий пользователя или вводимых данных автоматически обновляют содержимое в распределенных хранилищах данных. То есть осуществляют централизованное управление и коррекцию состояния этих хранилищ. Это достаточно важная возможность. При таком подходе открывается перспектива построения гетерогенных хранилищ данных с возможностью автоматического обновления. В частности, такого рода технологии могут быть основаны на применении стандарта XML и поддержке программирования на уровне схем данных. При этом разработчики имеют прямой программный доступ к XML-узлам каждого документа, для каждого элемента схемы создаются экземпляры полей и появляется возможность доступа к данным по отдельным полям, а не по элементам интерфейса. При этом XML-схемы поддерживают взаимодействие и связь с данными на основе механизма управления событиями, в том числе событиями, связанными со вставкой, редактированием, контекстным вводом или изменением контекста. На рис. 14.2 представлен шаблон дополнений к клиенту Microsoft Office Outlook 2003 с использованием средства VSTO 2005.

Рис. 14.2..Шаблон для дополнений к MS Office, Outlook 2003 в VSTO 2005

Фактически речь идет о внедрении большого количества разнообразных фрагментов офисных приложений в общий документ, в том числе таблицы Excel, и возможно оперативное онлайновое реагирование в реальном масштабе времени на действия пользователя, например коррекция или выбор той или иной ячейки в таблице. Например в ячейке с названием Seattle Home1 появляется полное описание полей извлеченных из базы данных, связанных с ипотечным кредитом для этого строения, справа – фотография этого строения, ссылки, связанные с возможностью заключения договора на ипотечный кредит, с данными о собственниках этого строения, о размере первоначального взноса, кредитной ставке и, естественно, с указанием текущей даты, финансового года и т. д. Таким образом открывается возможность построения гетерогенных приложений, интегрирующих данные из различных источников и объединяющих их на общей и привычной всем пользователям платформе Microsoft Office System. Более подробно об интеграции различного рода данных из гетерогенных источников, в том числе с разной степенью структурированности, преимущественно на основе XML-технологий, будет говориться в следующей главе, которая во многом будет посвящена СУБД, в том числе Microsoft SQL Server.

Важным условием, важной возможностью, которая обеспечивается VSTO 2005, является кэширование данных, оно необходимо для обработки данных пользователями, в данном случае речь идет о редактировании документов Word и таблиц Excel в режиме offline, в отсоединенном и автономном режимах. При этом данные из кэша, из временного хранилища данных на локальной машине пользователя, могут быть связаны с документами и отображаться в режиме выполнения приложений. Кроме того, в кэш-области памяти могут также храниться данные, не связанные непосредственно с элементами интерфейса. Данные из кэша доступны на сервере, и если говорить о модели взаимодействия, об архитектурной модели приложения, в VSTO 2005 используется так называемая асимметричная модель. Для указания полей, данные из которых должны извлекаться и храниться в кэше, разработчиками могут использоваться атрибуты кэша (cash attribute). Достаточно указать список полей, которым нужно установить этот атрибут, и кэширование полей, т. е. сохранение их содержания, будет происходить автоматически. Для доступа к кэшу из других приложений, проектов Visual Studio используется объект ServerDocument, который позволяет открывать документы, не создавая экземпляров приложения Word и Excel, т. е., по сути, на сервере не требуется наличия Office приложения.

Важными особенностями являются возможность извлечения и связи данных из кэша с документами и отображение их в режиме выполнения приложений. Что касается приложений, которые создаются на основе Outlook, на рис. 14.2 было показано такое приложение, где в платформе VSTO 2005 поддерживается клиент Microsoft Outlook 2003. При этом существует полная интеграция с объектной моделью продукта и с кодом на языках C# и Visual Basic. Фактически реализован AddIn – дополнение для VSTO 2005, т. е. появился новый шаблон проекта, наряду со стандартными шаблонами, которые существуют в Visual Studio, например для создания проекта на C#, с помощью которого можно создавать расширения для Microsoft Outlook. Интерфейс VSTO 2005 предоставляет всю необходимую инфраструктуру для создания и использования подобного рода приложений. В том числе специализированный компонент, который называется AddIn Loader, реализован в виде динамически присоединяемой библиотеки dll, т. е. фактически тоже в виде компонента, в виде сборки, и используется для загрузки расширений к Microsoft Outlook. Поддержка MS Office Outlооk в VSTO 2005 позволяет осуществлять стандартное обращение к объектной модели продукта и к модели кода с использованием основных языков платформы. NET: C# и Visual Basic, а также выполнять ряд стандартных операций, некоторые из них будут рассмотрены далее. Это создание расширенных меню, экспорт заданий и совместное использование MS Outlook и XML Expansion Pack. Последнее дает возможность интеграции с основными видами офисных приложений, документами Word и таблицами Excel и самими этими приложениями. При этом существует достаточно большое количество AddIn и удачных примеров их использования для MS Outlook.

Что касается модели безопасности, реализованной в VSTO 2005, то, поскольку речь идет о практически полном погружении новой среды и семейства офисных приложений в платформу. NET, используются все основные механизмы обеспечения безопасности, которые обсуждались ранее. И это дает возможность наиболее полной интеграции продуктов, которые разрабатываются, в платформу, в том числе с использованием механизма сборок. В связи с этим можно говорить о полной поддержке механизмов безопасности. NET Code Access Security. При этом модель безопасности не только распространяется на сборки, которые содержат код, позволяющий расширить стандартные функции традиционных документов Office, но и защищает сами эти документы. Например, перед загрузкой любого управляемого кода, допустим написанного на языке C# или Visual Basic, средства VSTO проверяют политику безопасности, в том числе локальную, чтобы установить статус доверия сборки, на которую ссылается связанный с ней документ. Необходимо при этом убедиться в том, что обеспечивается полное доверие сборке, т. е. установлен статус Full Trust для той сборки, на которую ссылается документ.

Естественно, для разработчиков, которые приняли решение интегрировать свои компоненты, свои надстройки над Office в стандартную среду Office System 2003, эта новая модель, в том числе и с точки зрения обеспечения безопасности, является весьма удобной. До выполнения кода необходимо убедиться в том, что код признан полностью доверенным. При этом на локальном компьютере каждого пользователя корпоративной системы содержится набор правил, который определяет, какого рода операции разрешены для данного кода и какого рода код может быть исполнен. При загрузке кода языковая среда CLR собирает сведения об этом коде. Основное количество сведений относится к сборке – это версия и автор сборки, цифровая подпись, в том числе зашифрованная, алгоритм шифрования, степень доверия и политика безопасности и т. д. Кроме того, необходимо собрать сведения, относящиеся к хосту, т. е. к источнику кода. После этого сведения по сборке и по источнику соотносятся с той или иной политикой безопасности.

При этом существует четыре уровня этой политики, или четыре различных среза для политики безопасности, – Machine, User, Enterprise и Host. То есть на уровне локальной машины, на уровне пользователя, на уровне предприятия в целом и на уровне источника, например того сервера, с которого эта сборка получена по Интернет каналу. Каждая из этих четырех политик может содержать несколько групп кода – от нуля до некоторого их ограниченного количества. При этом каждая группа кода на основе сведений устанавливает тот уникальный набор прав, который включает то или иное количество разрешений, т. е. операции, допустимые в данном случае, например чтение файла с диска, запись на диск, открытие файла, коррекция и т. д. В результате, используя все собранные сведения о хосте, сборке и политике, среда выполнения соотносит сборку с кодовой группой, которая соотносит ее с матрицей прав для всех политик, для каждой из четырех политик безопасности. При этом удается достаточно четко и в то же время гибко определить, во-первых, разрешается ли выполнять этот код и, во-вторых, если разрешается, то какие именно операции допустимы для этого кода и с какими объектами. Естественно, сборки, которые используются документами Word или таблицами Excel, требуют статуса «полное доверие» – Full Trust, независимо от выбранной модели развертывания. Как правило, право на исполнение выдается определенным локациям для сборок, и после этого выбранным сборкам или наборам сборок на основе строгого, т. е. полного, имени присваивается статус доверия.

Наконец, последнее – это модель развертывания, которая реализует технологию, близкую к ClickOnce, т. е. является достаточно экономичной. По сути, в основе модели, которая применяется в VSTO 2005, лежит структурное разделение на документ, на код и на сборку. Код является частью проекта Visual Studio, а сборка – единственное, что поставляется вместе с документом. При этом сборка связана с документом, а реализация привязки осуществляется различным образом: в VSTO 2003 это делалось на основе свойств документа, в более поздней версии – 2005 – используются специализированные средства, доступные при выполнении приложений. Основных моделей развертывания – три: локальная– локальная, локальная – сетевая и сетевая – сетевая (рис. 14.3).

Если речь идет о модели локальная – локальная, то доступ к сети не требуется, необходима явная установка каждым пользователем приложения на базе Office System, а если документ обновляется, требуется физическое копирование его на каждый компьютер. Все обновления требуют установки на каждом компьютере, и пользователи каждый раз работают с локальной копией документа. Если речь идет о модели развертывания локальная – сетевая, то, как правило, загрузка документа потребует доступа к сети. Тем не менее, как и в предыдущей модели, каждый пользователь работает с локальной копией документа, и обновление документа потребует физического копирования на каждый компьютер пользователя. Однако обновление можно производить из централизованного хранилища. Если речь идет о модели сетевая – сетевая, то для распределенной работы с документом пользователям требуется доступ к сети, и для загрузки документов в том числе. Документ хранится на сервере, обновление документа требует его публикации на сервере, и пользователи работают с этим документом в режиме разделения доступа.

Рис. 14.3. Модель развертывания

При этом для корректной установки полного спектра решения VSTO 2005 на машину клиента необходимо обеспечить наличие предварительных компонентов, таких как. NET Framework (поскольку на этой базе классов реализовано VSTO), а также собственной среды исполнения для VSTO, средств поддержки интерфейсов, связанных со сборками, и необходимых обновлений для корректного функционирования офисной среды. Кроме того, поскольку речь идет о распределенной работе и о работе с компонентами, необходимо предоставить пользователям соответствующие права доступа. В том числе пользователи должны получить права на выполнение кода в сборке. Это можно обеспечить путем модификации политик безопасности. NET. Но поскольку некоторые ограничения содержатся в собственно документах, возможно, потребуется модификации политики безопасности самого документа. Здесь, как известно, осуществляется достаточно гибкая настройка уровня безопасности, поэтому интегрированную настройку нужно делать достаточно аккуратно. Наконец, нужно проверить корректность пути к тому размещению сборки, который указан в манифесте, т. е. в метаданных сборки, соответствие ее реальному местоположению. В ряде случаев, например при попытке сохранения пользователем локального документа, открытого ранее на сервере, могут возникать некорректности. Таким образом, обеспечивается реализация модели развертывания.

Для того чтобы проиллюстрировать возможности работы с данными и элементами офисных приложений в рамках технологии VSTO 2005, попробуем рассмотреть пример фрагментов программы на C#, которая осуществляет настройку меню в приложении MS Excel. Нашей задачей является создание новой строки в меню и добавление в эту строку новых элементов, а затем определение конкретных действий, которые будет осуществлять система при возникновении тех или иных событий со стороны пользователя. Желательно осуществить привязку управляемого кода, т. е. кода на C#, при нажатии пользователем кнопки на панели инструментов. В MS Office панели инструментов называются панелями команд и представляют собой общее средство для всех приложений. В данном случае наблюдается пример, связанный с MS Excel. Иногда, например при построении AddIn, возможно, имеет смысл создать собственную панель команд с дополнительными кнопками. В других случаях можно просто добавить элементы управления к уже существующей панели команд или меню. При использовании инструментария VSTO 2005 можно сделать и то и другое. То есть можно как расширить существующее меню, так и создать новое.

Перед автором недавно стояла задача верстки документа в текстовом редакторе TeX для одной из научных конференций, поскольку это являлось необходимым требованием. К сожалению, с TeX автор работал очень давно и решил не вдаваться в подробности, а пойти по другому пути – взять MS Word и найти к нему расширение, которое реализует функции конвертации документа Word в текст формата TeX. Выяснилось, что такое расширение есть, что оно строится на основе. NET Framework, требует. NET Framework версии 1.0, написано на C# и работает вполне корректно. То есть оно позволяет задавать стили, делать корректным перенос формул, это высший пилотаж, это самое сложное, собственно это то, ради чего строился TeX, – создавать многоэтажные, сложные формулы, корректно переносить иллюстрации. Самое главное, что оно как раз внедряет в семейство панелей инструментов MS Word новую строку инструментов и позволяет осуществлять конвертацию посредством этой строки, а также изменяет меню – вводит новый пункт меню и может работать посредством подменю. При этом запуск посредством встроенного в MS Word сценария обеспечивает примерно десятикратное увеличение производительности по сравнению с традиционной работой без использования MS Word. То есть использование надстройки в этом случае существенно помогает.

Итак, в данном примере предлагается добавить новую строчку меню в Excel. Делается это посредством нескольких шагов, при этом каждый из них является достаточно простым. Во-первых, надо взять пространство имен, которое называется Microsoft.Office.Core, и задать ему более простой псевдоним. Для этого используется оператор Using, по сути, слово Office, которое здесь пишется, является Alias – псевдонимом более длинного Microsoft.Office.Core, и впоследствии можно писать не Microsoft.Office.Core, а просто Office, как здесь и делается. После этого в разделе объявлений класса Office.Core.Behind указываются соответствующие элементы, по сути – элементы управления в новом пространстве имен. Office. CommanBar – это, собственно, панель команд. Создаем панель меню, создаем элементы панели меню, это MainMenuBar в главном меню, MenuBarItem – элемент панели меню, MenuItem – элемент меню. Таким образом, используются три переменные уровня модуля. Одна из них, первая, дает ссылку на главную строку меню Excel, другая – на элемент строки меню MenuBarItem, и еще одна – MenuItem – нужна для того пункта меню, для которого и будет обрабатываться событие щелчка по этому пункту. Далее, как только описаны все три уровня, остается написать две функции: первая создает пункт строки меню, вторая – пункт меню, т. е. MenuBarItem и MenuItem. Рассмотрим пример: код первой процедуры, которая называется InitMenuBarItems (рис. 14.4).

Далее создаем новый пункт меню. При этом можно использовать специализированный, заранее определенный обработчик событий ThisWorkBookOpen, т. е., как только открывается книга Excel, автоматически выполняется это событие и фактически в нашем классе Office.Core.Behind создается код, который будет выполняться по этому действию (рис. 14.5).

Здесь командная кнопка создается посредством метода Cre-ateButton, и дальше используется стандартный интерфейс реализации исключений. Наконец можно привязать к скрипту события ThisWorkBookOpen – открытие текущей книги, создание тех элементов управления, о которых было сказано. Создается строка меню, пункт меню и обрабатывается событие – клик по объекту This.MenuItem, снова стандартным образом. При этом используются стандартные процедуры обработки событий, которые существуют в MS Office, точнее в MS Excel. И нужно добавить код, который создает отчет при нажатии кнопки OK или ничего не выполняет при нажатии кнопки Cancel в том окне, которое появляется при выборе пользователем созданного ранее пункта меню. Это происходит при помощи элемента WindowsForm, т. е. создается меню диалога, и можно пользоваться стандартными методами, стандартными результатами DialogResult.OK, DialogResult.Cancel. При этом происходит работа со стандартной формой, которую имеет тип FRMReport и называется FRM, и со стандартным методом ShowDialog, который как раз и генерирует стандартный диалог, стандартное окно с кнопками OK и Cancel.

Рис. 14.4. Создание строки меню

Рис. 14.5. Создание пункта меню и командной кнопки

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

Реализация принципа компонентно-ориентированного программирования осуществлена Microsoft и расширена с платформы. NET на надплатформу, которая называется MS Office System, тоже является своего рода платформой и позволяет строить на компонентой основе надстройки – AddIns для приложений уже офисного класса, которые используются в корпорациях для совместной обработки гетерогенных данных. Важно, что все механизмы. NET Framework и CLR внедрены в семейство приложений MS Office, таких как Word – текстовый процессор, Excel – электронные таблицы, Access – базы данных и Outlook – клиент электронной почты. Нужно сказать, что при этом обеспечивается повышенный уровень безопасности за счет интеграции с внутренними политиками безопасности. NET и Windows, реализации механизма сборок, электронной подписи, идентификации автора и версии сборки, за счет манифеста и т. д.

И последнее, что хотелось бы отметить. Сборка, которая для. NET является синонимом компонента, находится структурно посередине между понятием класса языка программирования и понятием модуля корпоративной системы, например модуля учета, планирования и управления основных средств в корпоративной системе Oracle Applications или Oracle Business Suit. Такой подход позволяет создавать интероперабельные, надеждные, масштабируемые и легко изменяемые приложения, и в отличие от конкурирующих подходов, таких как, например, Enterprise Java Beans, обеспечивает языковую интероперабельность, т. е. очень важную возможность реализации компонентов приложения на наиболее подходящих языках программирования.

Глава 15 Разработка корпоративных систем на основе библиотеки Enterprise Library

Корпоративные системы имеют очень большие базы данных: размеры хранимой информации в этих СУБД достигают 1015 байт. В хранилищах корпоративного контента хранится гетерогенная информация, это и видео-, и аудиоданные, и отсканированные документы, которые не всегда идеально распознаются и часто просто каталогизируются на основе определенных признаков: номера, даты создания и т. д. Нужно сказать, что корпоративные данные достаточно быстро увеличиваются, в среднем их объем удваивается за пятилетку, т. е. речь идет о лавинообразном росте, поскольку удвоение – это почти экспоненциальный рост. При таких изначально высоких базовых объемах этих данных управлять ими очень сложно, поскольку они обеспечивают бизнес-критичные приложения, необходимые для ведения и оперативного, и стратегического планирования развития корпорации. В связи с этим темой данной главы будут как СУБД, так и библиотеки создания корпоративных приложений, которые настроены на то, чтобы создавать из базовых блоков экономичным образом корпоративные приложения и объединять их в корпоративные информационные системы (КИС).

Библиотека классов для. NET, на основе которой производится построение такого рода приложений, называется Enterprise Library. Познакомимся с технологией построения этой библиотеки, с некоторыми из классов, которые входят в ее структуру, и, конечно, с примером создания, может быть, не корпоративного приложения, но некоторого его фрагмента на основе этой библиотеки.

Если говорить о корпоративных приложениях, о библиотеке Enterprise Library, то важно отметить, что она структурно включает в себя целый ряд блоков, каждый из которых предназначен для построения определенного рода приложений или определенной части этих приложений. Существует ядро в составе классов, которые представляют эту библиотеку, лучше сказать, эти библиотеки, и целый ряд функциональных блоков (по-английски – blocks), в названии которых указываются их специализация, т. е. функциональное назначение. Основные блоки предназначены для организации кэширования, уже достаточно много говорилось о том, что это за сервис, каким образом он обеспечивается, а также о кэш-серверах в связи с базами данных. Ряд функций обеспечивается блоком, который отвечает за безопасность, следует напомнить, что безопасность является, пожалуй, высшим стратегическим приоритетом Microsoft. После известных событий 11 сентября Microsoft разработала подход к созданию программных систем, который называется Security Development Lifecycle. Один из основных принципов разработки – Secure by Design, т. е процесс проектирования с самого начала предполагает получение на выходе безопасных приложений. Поэтому многоуровневые политики доступа к данным, методы криптографической защиты, использование шифров от различных крипто-провайдеров, возможности использования встроенных средств защиты, журналирование операций, системный аудит данных и программных компонентов корпоративных систем, средства авторизации/аутентификации различного рода, в том числе и на основе применения специальных средств аутентификации пользователей системы и биометрической аутентификации, ряд других методов и механизмов реализуют этот блок, связанный с доступом к данным. Об этом будет говориться более подробно, в том числе при рассмотрении практического примера, который будет связан с построением приложения, осуществляющего доступ к корпоративным данным. Еще один важный блок связан с проверкой корректности или валидации.

Неоднократно упоминалось о том, что корпоративные системы представляют собой конгломераты гетерогенных приложений с точки зрения как степени структурированности, так и архитектуры. Это могут быть и приложения, построенные на мейнфреймах, на файл-серверах, на клиент-серверных технологиях, на интернет-технологиях, на технологиях, связанных с сервисно-ориентированной архитектурой. И эти данные, как уже упоминалось, могут объединять как слабоструктурированную информацию, например аудио-, видеоданные, так и хорошо структурированную, которая хранится, например, в электронных СУБД в форме таблиц. В связи с этим неизбежно при развитии корпоративных систем возникают дублирования информации, противоречия и иные нарушения целостности данных, т. е. при попытке построения отчета можно столкнуться с неполнотой данных или некорректностью.

Скажем, в связи с учетом персонала и его управлением возникают вопросы о том, что происходит с отделом, когда из него удаляется последний сотрудник; ликвидируется он или сохраняется в измененном виде, или происходит что-то еще? На самом деле разные СУБД на уровне контроля ограничения целостности подходят по-разному к решению этой проблемы. А зависимости, которые позволяют определить степень нормализации базы данных и степень сложности обеспечения целостности, такие как зависимости между хранимыми атрибутами, между сущностями корпоративных систем, могут быть поддержаны на уровне системных библиотек, в частности библиотеки Enterprise Library. Блок, связанный с проверкой корректности, поддерживает отслеживание зависимостей, связей, взаимосвязей между элементами данных, элементами информации корпоративных систем и проверку и обработку специализированных исключительных случаев, связанных с корректировкой, обновлением, удалением и добавлением информации в корпоративные системы.

Итак, обсудим в данной главе основные понятия и функциональное назначение библиотеки Enterprise Library, состав, основные характеристики составляющих эту библиотеку компонентов, которые называются блоками, структуру и взаимодействие этих блоков, а также рассмотрим пример построения приложения, реализующего доступ к данным.

Итак, Enterprise Library – это коллекция компонентов, поскольку в идеологии. NET и Microsoft.NET все, что проектируется, любые приложения, которые создаются, разрабатываются, являются набором компонентов. И эти компоненты имеют вполне определенные характеристики. В данном случае, поскольку речь идет о системной библиотеке, эти характеристики должны быть в целом не хуже, а наверное, заметно лучше, чем у индивидуальных приложений, которые создаются на основе этой библиотеки. Для корпоративных приложений, особенно в условиях сложной экономической ситуации, сложной экономической среды, которая на сегодня, к сожалению, имеется, критически важна возможность многократного использования компонентов, т. е. возможность при создании новых корпоративных приложений в составе существующих систем или при создании новых корпоративных систем унаследовать и фактически без изменений использовать некоторые функциональные блоки, в данном случае – ряд компонентов, если работать по компонентной идеологии, компонентно-ориентированному подходу. Конечно, эти компоненты являются расширяемыми и модифицируемыми, т. е. при наличии исходного кода можно достаточно легко и без существенных затрат изменить функциональность этих компонентов и адаптировать их к новым бизнес-требованиям.

Очень важно, что Microsoft при создании такого рода библиотек решает достаточно важную, прежде всего для разработчиков, задачу, поскольку даже в корпоративных приложениях, которые представляют собой сложные гетерогенные конгломераты приложений, существует большое количество типовых задач, связанных с учетом, управлением. Например, документооборот, некоторый упрощенный цикл документооборота, наверное, существует почти без изменений в большом количестве корпораций, общая схема визирования документов или каких-то конкретных видов документов во многом повторяется от проекта к проекту. Существуют важные параметры, например кадрового или финансового учета, связанные, прежде всего, даже не со спецификой бизнес-корпораций, а с действующим законодательством, и в связи с этим некоторое ядро или некоторая совокупность важных компонентов, которые являются инвариантами относительно предметной области, конкретной бизнес-специфики, кочует из проекта в проект, повторяется от одного проекта к другому. Конечно, разработчикам важно выделить это ядро и постараться обеспечить максимум повторного использования при относительно легком сопряжении с другими компонентами проекта, которое обеспечит проекту жизнестойкость, относительно эффективное по срокам и стоимости взаимодействие с новыми заказчиками и гибкое сопровождение продукта у существующих заказчиков. Таким образом, это решение Microsoft представляет собой некий набор шаблонов для проектирования и реализации корпоративных приложений.

Поскольку речь идет о шаблонах, которые реализуют не только прикладные, но и системные задачи, логично разбить это решение на ряд блоков для того, чтобы разработчик мог выбрать необходимые ему блоки и уже в рамках этих блоков отобрать компоненты, а если понадобится, то конкретные классы и методы классов, которые необходимы ему для реализации конкретных корпоративных приложений. Блоки отвечают за конфигурацию. Конфигурация – по сути, управление метаданными, т. е. данными о данных, данными о той информации, которая хранится в системе: количество и размерность объектов, типы, взаимосвязи и ресурсы, связанные с этими объектами. Сейчас говорится об объектах, так как в идеологии. NET всякая сущность есть объект и, по сути, программирование или разработка программных систем, в том числе и корпоративных, ведутся в терминах объектов. Не случайно другим функциональным направлением, которое обеспечивают блоки Enterprise Library, является управление объектами и создание объектов для тех или иных функциональных блоков. Для этого существует средство, которое называется ObjectBuilder, далее будем говориться о нем несколько подробнее.

Важно отметить, что библиотека Enterprise Library не является абсолютно независимой, а, напротив, строится на фундаменте. NET и таким образом вбирает в себя все механизмы, которые присутствуют в системе базовых классов. NET в Microsoft.NET Framework, основной библиотеке классов. Начиная со второй версии, Enterprise Library полностью базируется на. NET Framework. Естественно, существуют специализированные инструменты, в том числе консольного типа, которые обеспечивают достаточно быстрое и легкое манипулирование свойствами корпоративных приложений, заложенными в базовых блоках. Прежде всего, это Configuration Console и Security Data-Based Console, т. е. средства манипулирования критически важными метаданными, связанными как с общей конфигурацией системы, так и с конфигурацией, связанной с настройками безопасности.

Если говорить о конфигурационной консоли, можно менять конфигурацию каждого приложения, добавляя к нему соответствующие блоки, можно менять конфигурацию каждого блока нашей библиотеки. Консоль, которая связана с безопасностью и обеспечивает управление безопасностью внутренней системной базы данных этих библиотек, позволяет создавать роли, профили и правила авторизации, которые поддерживает блок, связанный с безопасностью. Блоки, как правило, имеют названия, которые заканчиваются словами Application Block, в частности блок, связанный с безопасностью, называется Security Application Block. Далее будет показано, как происходит именование блоков, и основные функции, в чем состоят основные цели библиотеки Enterprise Library и какие возможности она предоставляет, какие задачи перед собой ставит.

Основных целей, судя по подходу Microsoft, четыре: последовательность (Consistency), расширяемость (Extensibility), простота использования (Ease-of-Use), можно понимать ее и как эргономику (Usability), и интеграция (Integration). Поскольку речь идет о корпоративных приложениях, здесь необходимо обеспечить как относительно дешевое и в то же время эффективное сопровождение развития, расширения, так и взаимодействие с уже существующими компонентами и теми новыми, которые будут реализованы. На чем основывается понятие Consistency? Естественно, это использование образцов, или шаблонов, паттернов проектирования совершенно определенного класса с определенным составом и взаимосвязями, которые позволяют обеспечить последовательный, прагматичный подход к реализации и внедрению программных систем, включающих блоки, связанные с корпоративными подсистемами. Расширяемость заключается в том, что все блоки включают явно определенные точки расширения, которые дают возможность разработчикам настраивать поведение этих блоков при добавлении в них своего собственного кода. Простота использования, по сути, связана с эргономикой, и здесь целый ряд усовершенствований в удобстве использования уже встроен в саму систему Enterprise Library. В частности, графические средства конфигурации, упрощенная процедура инсталляции, большое количество примеров использования и хорошая, тщательно подогнанная и собранная документация, которая описывает достаточно полно все возможности и пути применения классов и компонентов этих библиотек. Что касается интеграции, то она обеспечивается тщательным предварительным тестированием всех Application Block и грамотным и аккуратным проектированием этих блоков таким образом, чтобы они корректно взаимодействовали друг с другом и обеспечивали каркас для решения задач, связанных с разработкой корпоративных приложений. Тем не менее каждый из блоков может быть использован отдельно, вне связи с остальными, если этого требуют цели разработки.

Какие сценарии использования могут быть предусмотрены для корпоративных приложений, для библиотек Enterprise Library? Прежде всего, важный сценарий использования можно связать с разработкой нефункциональных требований к корпоративным приложениям, естественно, на платформе. NET, т. е. тех требований, которые связаны со стратегическими аспектами реализации приложений, вне связи с конкретной функциональной спецификой, которая описывает сферу приложения реализации. Важным сценарием использования можно считать также возможность создания библиотек классов для пользователя, т. е. в данном случае для разработчика, как следствие – для корпоративных пользователей. Как уже говорилось, у каждого функционального блока существуют стандартные точки расширения, которые особым образом помечены и подробно рассмотрены в документации, и разработчики, т. е. пользователи этой библиотеки, могут, расширяя функциональность с учетом требований, которые связаны с той спецификой разработки корпоративных приложений, которую необходимо обеспечить, осуществляют расширение этих блоков новой функциональностью, естественно, на платформе. NET, например работая на языке C# или одном из множества других языков, поддерживаемых платформой.

Важно отметить, что существуют как более новые разработки Microsoft для Enterprise Library, они, естественно, постоянно возникают, так и библиотеки или компоненты, расширяющие эти библиотеки, которые разработаны сторонними провайдерами. Enterprise Library поставляются пользователям, т. е. разработчикам корпоративных приложений, вместе с полными исходными текстами. Это очень ценно, поскольку речь идет о возможности использования большого опыта Microsoft, который вложен в этот код, ведь это код для создания наиболее эргономичных, наиболее устойчивых, наиболее интегрируемых, наиболее сопровождаемых, наиболее надежных, наиболее безопасных приложений – перечень прилагательных можно продолжать довольно долго. В связи с этим можно расширять функциональность блоков на низком уровне, прямо на уровне исходных текстов, т. е. создавать новые функциональные блоки на основе той инфраструктуры, которая уже реализована в библиотеках Enterprise Library.

Как уже было сказано, необязательно включать в код весь комплект компонентов, которые включаются в Enterprise Library, для того чтобы построить корпоративное приложение. Можно взять всего один Application Block, можно взять несколько, они достаточно хорошо интегрированы между собой и позволяют обеспечить взаимодействие практически вне зависимости от того набора блоков, который выбирают разработчики. Таким образом, в приложения можно включить прежде всего блоки, действительно необходимые для реализации тех программных решений, которые поставлены как техническое задание разработчикам.

С другой стороны, важной возможностью повторного использования является возможность включать исходный код библиотек, уже разработанный специалистами Microsoft, в те новые системные библиотеки, которые будут создаваться в рамках корпоративных приложений, естественно, соблюдая соглашение об авторских правах. Поскольку библиотека поставляется как корпоративное решение, та корпорация, которая его получила, имеет определенного рода лицензионное соглашение, и в рамках этого соглашения можно использовать ту функциональность, буквально копируя и вставляя нужные фрагменты исходного кода в приложения, которые будут развивать Enterprise Library и на этой основе расширять информационную инфраструктуру корпорации. Очень важно отметить, что ноу-хау, принципы и подходы к проектированию корпоративных приложений, которые имеются у корпорации Microsoft, воплощены в коде этих библиотек. Поэтому исходный текст библиотек и, естественно, средств взаимодействия между ними является важной основой для изучения тех принципов архитектурного, технологического построения и проектирования корпоративных приложений, которые имеются у Microsoft. Достаточно интересно эти принципы изучать и в дальнейшем применять практически, поскольку Microsoft, используя MSF, достаточно сложную методологию, разработала большое количество кода корпоративного качества и на основе изучения этого кода можно изучать и степень применимости, и технологию применения, например подхода Microsoft Solution Framework, при проектировании и реализации корпоративных приложений. Это достаточно важное замечание, которое нужно учесть при разработке и работе с этим кодом, с этими библиотеками.

Функциональные блоки, входящие в состав библиотеки Enterprise Library, называются Application Block и имеют некий префикс, который определяет их функциональное назначение. Это блок кэширования, блок криптографии, блок доступа к данным, блок обработки исключений, блок ведения системных журналов, блок, связанный с политикой безопасности, блок, связанный с обеспечением безопасности в целом, и важный блок, который отвечает за контроль целостности и проверку корректности элементов этой системной библиотеки.

Можно более подробно описать некоторые из этих блоков. По сути, блоки реализованы инвариантно по отношению к архитектуре конкретных приложений. Например, блок, который отвечает за ведение системных журналов, может быть использован как в веб-приложениях, так и в приложениях, ориентированных на сервисы и интеллектуальные клиенты, технология Smart Clients, которая уже обсуждалась. Блок кэширования позволяет разработчикам реализовать средства кэширования в приложениях, при этом можно использовать и плагины для сторонних провайдеров методов кэширования. Блок, связанный с криптографией, включает симметричные алгоритмы шифрования и технологии хеширования. Естественно, эти методы, как и все реализованные в составе Application Block, созданы как открытые компоненты, в том смысле, что их код и их интерфейсы открыты для разработчика. То есть разработчик может просто пользоваться теми методами, теми классами, которые реализованы в этих компонентах, создавая свои решения.

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

О блоке, который связан с ведением системных журналов, более подробно будем говорить далее. Понятно, что его функциональность – это ведение системного аудита и логирование, запись в журналы тех системных событий, которые происходят с компонентами корпоративных приложений. Блок, который называется Policy Injection, связан с реализацией таких важных и часто встречающихся возможностей ПО, как кэширование, ведение журнала системной информации, обработка исключений и поверка корректности системы во всей системе. То есть они распространяют эти правила на всю систему и дают возможность сквозным образом вести контроль над корпоративной системой, включающей, возможно, несколько приложений, построенных на основе технологии Enterprise Library.

Блок, связанный с безопасностью, поддерживает авторизацию и безопасное кэширование данных и дает возможность реализовать, как и прочие блоки, эту функциональность на уровне приложений. Блок, который связан с зависимостями, Unity Application Block, позволяет достаточно прозрачным и легким образом контролировать сложные и многоаспектные зависимости на уровне конструкторов, свойств и методов. И наконец, блок, связанный с проверкой корректности, осуществляет поддержку создания правил для автоматизированной проверки корректности на уровне объектов, которая существует в корпоративном приложении также на различных уровнях. Все это поддерживается блоками, отвечающими за соответствующую функциональность.

Взаимодействие основных функциональных блоков в библиотеке Enterprise Library представлено на рис. 15.1.

Рис. 15.1. Структурная схема библиотеки Enterprise Library

В центре находится ядро, включающее в том числе средство ObjectBuilder, средства настройки конфигурации и общих компонентов, которые поддерживают проектирование, а также взаимодействие с инструментальными средствами разработки. На периферии в прямоугольниках с закругленными углами расположены блоки, которые были перечислены. Основные потоки взаимодействия между блоками обозначены сплошными стрелками, а дополнительные возможности, которые могут обеспечиваться на уровне взаимодействия между блоками, – пунктирными. Далее рассмотрим более подробно ядро библиотеки корпоративных приложений Enterprise Library.

Нет ничего удивительного в том, что интерфейс погружается в среду. NET, в среду Visual Studio. На рис. 15.2 показаны метаданные, конфигурация того или иного приложения, которое в данный момент создается или настраивается.

Рис. 15.2. Директории в среде. NET

Из рисунка видно, что на диске C, в директории pub и т. д., существует некий конфигурационный файл, который описывает метаданные приложения, создаваемого на основе библиотеки, и все стандартные средства, которые поддерживаются. NET Framework, доступны. Можно сказать, что все функциональные блоки, которые рассматривались ранее, в том числе на рисунке, описывающем структуру Enterprise Library, поддерживают общие механизмы настройки, которые как раз и дают возможность осуществить интеграцию этих блоков и приложений на их основе, а на базе тех приложений, которые строятся, осуществить взаимодействие между компонентами этих блоков. Кроме того, на основе этого общего репозитория метаданных можно задавать механизмы расширения блоков, используя точки расширения, о которых уже говорилось.

Существуют механизмы конфигурации (см. рис. 15.2) в форме конфигурационного файла, который представляет собой описание метаданных, в том числе в формате XML, и показывает, каким образом может происходить визуализированное управление элементами этих метаданных. Механизмы конфигурации используют стандартное пространство имен System Configuration из библиотеки. NET Framework, т. е. библиотека Enterprise Library погружена в системную библиотеку. NET Framework.

Если говорить о специфике каждого функционального блока, то для него на базе стандартных классов. NET созданы вспомогательные классы, которые поддерживают на уровне конфигурации все необходимые изменения. В частности, некоторые из конфигурационных файлов называются abp.config, web.config. В них как раз и хранятся данные о данных, хранятся те метаданные, та метаинформация, которая дает возможность настраивать приложения и управлять их работой и взаимодействием. При этом поддерживаются все стандартные возможности классов в пространстве имен System Configuration из библиотеки классов. NET, включая, например, средства шифрования и использование внешних файлов.

Другие возможности предоставляются, например, на основе библиотеки классов. NET Framework 2.0, пространство имен System Configuration из библиотеки классов. NET 2.0 позволяет вести считывание и запись сложных конфигураций. Поскольку здесь говорится о корпоративных приложениях, конфигурации таких приложений имеют достаточно сложную иерархию. Иерархическое представление возможно преобразовывать в последовательное и обратно посредством механизмов сериализации и десериализации на основе стандарта XML. При этом используется класс Configuration Section.

Еще одним важным элементом ядра Enterprise Library является подсистема ObjectBuilder. ObjectBuilder имеет собственное пространство имен Microsoft.Practices (см. рис. 15.1) и позволяет осуществлять управление созданием и в целом жизненным циклом экземпляров классов, т. е. объектов. Это является критически важным для Microsoft.NET, поскольку постулируется принцип: «Каждая сущность есть объект».

На уровне библиотеки классов Enterprise Library подсистема ObjectBuilder используется для организации вставки данных о конфигурации блоков в соответствующие классы этих функциональных блоков, а также для организации связи управляющих классов с функциональными блоками, а ведь функциональные блоки взаимодействуют между собой. При этом, для того чтобы использовать возможности Enterprise Library, не требуются глубокое погружение в особенности работы ObjectBuilder, знание принципов работы этой подсистемы.

Другие функциональные блоки могут использовать существующие в ядре счетчики производительности, протоколы событий и средства Instrumentation. На рис. 15.1 были представлены три составляющие, которые включают ObjectBuilder, средства, связанные с настройкой конфигураций и проектированием компонентов, и средства, которые называются Instrumentation или Windows Management Instrumentation, средства управления механизмами Windows из корпоративных приложений. При этом можно использовать различные механизмы, которые описывают конфигурации и стиль управления информационной системой, возможностями информационной системы.

После обсуждения ядра будем последовательно двигаться по блокам, описывая специфическую функциональность, связанную с этими блоками. Конечно, если говорить о разработке корпоративных приложений, то это распределенные приложения достаточно сложной структуры, большого объема. Встречается много серьезных проблем как у разработчиков, так и у системных архитекторов. На решение этих проблем во многом и направлен блок, который связан с кэшированием. Кэширование дает возможность обеспечить оптимизацию производительности, масштабируемости и доступности. Если говорить о производительности, то кэширование позволяет увеличить производительность приложений посредством сохранения наиболее часто используемых, востребованных данных, как можно ближе к потребителю этих данных. Это дает возможность устранить последовательные, часто повторяющиеся создания/обработку/передачу данных. Что касается масштабируемости, то хранение информации в кэш-памяти обеспечивает экономию ресурсов и увеличивает масштабируемость по мере роста частоты и запросов пользователей приложений. Если говорить о доступности, то хранение данных в локальной кэш-памяти позволяет приложениям оказаться жизнеспособными в таких случаях, как временное пропадание или неустойчивая работа сети, сложности с работой веб-сервисов и сбои аппаратного обеспечения. Это наиболее сложная проблема, которая может приводить к потере данных. Блок кэширования, который служит для реализации локального кэша, может поддерживать кэш как в памяти, так и в удаленном хранилище данных, которое может поддерживаться посредством блока доступа к данным, Data Access Application Block, или изолированного хранилища, Isolated Storage. При этом обеспечивается извлечение/добавление/удаление данных из кэша. Время хранения может меняться в зависимости от тех настроек конфигурационных файлов, которые описывают метаданные для этого блока. Локальный кэш поддерживается для единственного домена приложения, поэтому Cashing Application Block не обеспечивает реализацию разделяемого между доменами кэша.

Следующий блок, который будет рассмотрен в рамках Enterprise Library, – это блок, который связан с криптографией. Криптография – достаточно большая и серьезная практическая область. Существует такая наука, как криптология. Это действительно особая, очень важная область, имеющая свою сложную математику и массу научных проблем, связанных со стойкостью шифров и надежностью. Но в данном случае речь идет о прикладных аспектах, о криптографических алгоритмах, алгоритмах шифрования информации, которые имеют принципиальное значение для корпоративных приложений.

Понятно, что в корпорациях тайны стоят очень дорого, однако не всегда эти тайны имеют такую направленность, которая изначально подозревается. Например, в Oracle, насколько известно автору, самой большой и важной тайной является не клиентская база, не технологии, а зарплата сотрудников. Вместе с тем технологии тоже являются важной составляющей коммерческой и корпоративной тайны в той же самой корпорации Oracle, и, естественно, их тоже нужно сохранять, защищать и открывать ровно тем людям и ровно в той мере, в которой они должны иметь к ним доступ. Именно поэтому информацию имеет смысл надежно хранить и защищать в самых разных корпоративных системах, может быть, даже не только в тех, которые на первый взгляд считаются достойными этого. В связи с этим блок, предназначенный для криптографической поддержки, шифрования информации, очень важен для корпоративных приложений. Эти задачи выделены в отдельный блок, что говорит об их важности, т. е. он не интегрирован в общий блок безопасности, а вынесен отдельно. Очень значимым принципом является абстрагирование кода приложения от криптопровайдеров, т. е. от разработчиков алгоритмов шифрования данных. Естественно, можно использовать стандартные протоколы, средства шифрования от Microsoft, а также внутрикорпоративные подходы, которые существуют в любой крупной корпорации и являются ноу-хау, собственными разработками этой корпорации. Другим важным аспектом является создание хэш-ключей на основе данных, т. е., по сути, свертки, которая дает возможность проверять целостность данных, а в ряде случаев – их подлинность.

Таким образом, при абстрагировании алгоритмов шифрования от кода приложения появляется возможность простой коррекцией конфигурационного файла обеспечить взаимодействие кода с новыми, специфическими алгоритмами шифрования. При этом даже нет необходимости в перекомпиляции проекта. Понятно, что корпоративные проекты достаточно большие, содержат огромное количество взаимодействующих компонентов, и не нужно менять код приложения, не нужно даже повторять компиляцию. Что касается алгоритмов шифрования на основе открытых и закрытых ключей, поддерживаются только симметричные алгоритмы и асимметричные алгоритмы только с использованием открытых ключей. Не поддерживаются в данной реализации закрытые ключи, ключи, которые используются исключительно для декодирования. Достаточно большое количество других функций поддерживает этот блок, например поддерживаются возможность создания хэш-кода для паролей, базы данных для хранения такого рода кодов, алгоритмы сравнения кода с тем кодом, который предоставляет пользователь, без непосредственного хранения пароля, шифрование данных без использования ключей, например, при хранении данных на одном компьютере. Существуют различные сценарии использования этого блока, некоторые из них были перечислены выше. Еще один сценарий связан с использованием шифрования с помощью симметричного ключа перед сохранением в базе данных и считыванием после извлечения. Принципиально важна возможность расширения алгоритмов шифрования за счет сторонних криптопровайдеров.

Следующий блок связан с доступом к данным. Здесь поддерживаются стандартные механизмы активных объектов данных Active Data Objects, ADO.NET 2.0, и в этом смысле удается абстрагироваться от провайдеров данных, используя стандартные объекты, стандартные классы, например дебикомманд, деби-Connection для того, чтобы получать параметры получения данных и параметры подключения к этим данным, а также параметры их преобразования. В связи с этим приложение можно переносить из одного хранилища в другое без изменения кода. Просто настройкой конфигурации можно добиться взаимодействия с новым местоположением, новыми особенностями хранения данных. Вообще этот блок поддерживает функции управления соединением с данными, извлечения/создания/коррекции данных, кэширования и создания хранимых процедур и т. д. Естественно, этот блок также построен на основе стандартных классов. NET, в данном случае ADO.NET 2.0. Важно, что поддерживается работа с большим диапазоном SQL-серверов, об одном из них, Microsoft SQL Server, будет говориться далее, но поддерживаются и Oracle-сервер, и различные варианты SQL-серверов от Microsoft, в частности Compact Edition для мобильных систем. Возможно упрощенное обращение к базе данных с использованием при передаче параметра строки соединения. При этом код приложения может создавать именованный экземпляр базы данных.

Известно, что при работе с СУБД Oracle каждый раз реализуется новый экземпляр базы данных и происходит стандартная передача параметров соединения метода CreateDatabase класса DatabaseFactoring в стандартном пространстве имен. NET. Каждая база данных, которая имеет имя и создается как экземпляр, имеет информацию о соединении, и эта информация сохраняется в файле конфигурации. Корректируя эту информацию, конфигурационный файл, по сути, метаданные, которые описывают сценарий взаимодействия с базами данных, разработчики корпоративных приложений могут использовать приложения с различными конфигурациями базы данных без перекомпиляции, т. е. опять-таки можно обеспечить существенное упрощение взаимодействия с данными на основе механизмов, поддерживаемых библиотеками Enterprise Library, в частности блоком, который связан с доступом к данным. Как и в случае с другими блоками, блок Data Access Application Block уменьшает необходимость написания стандартного кода для взаимодействия с данными, а также делает последовательной политику доступа к данным внутри как каждого приложения корпоративного типа, так и корпорации в целом, которая объединяет большое количество различных приложений. За счет универсализации интерфейсов между корпоративным приложением и различными базами данных удается обеспечить прозрачную интеграцию, в ряде случаев даже без перекомпиляции, с возможностью замены конкретного вида SQL-сервера, вида конкретной базы данных, с которой ведется работа. Разработчики могут обойтись без использования гетерогенных программных моделей для различных типов баз данных.

С любой базой данных можно вести диалог на платформе. NET посредством механизмов, предусмотренных ADO.NET, и классов, заложенных в составе данного блока. Существенно уменьшается при этом количество кода, которое было бы необходимо для взаимодействия с различными SQL-серверами, с различными видами баз данных. Блок применяется для решения следующего набора задач: это использование механизмов DataReader и DataSet для извлечения нескольких записей, выполнение команд и получение параметров после выполнения этих команд, получение значений, которые выполняют команды или хранимые процедуры. В рамках одной транзакции здесь поддерживается управление многопользовательской работой с базами данных. В режиме транзакций можно выполнять несколько элементарных операций, можно получать в результате обмена с SQL-сервером данные в формате XML и можно стандартным образом обмениваться данными посредством использования DataSet.

Следующий блок связан с обработкой исключений. Он называется Exception Handling Application Block. Известно, что на стандартной платформе. NET, в. NET Framework, существует специальное пространство имен, которое называется System Exception. Внутри этого пространства существуют различные классы для обработки разных видов исключений – арифметических ошибок, ошибок, связанных с доступом к данным, и т. д. Здесь этот принцип обобщается на уровень корпоративных приложений.

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

Что очень важно, обработка исключений становится политикой, можно задавать и конфигурировать на основе этого блока политики обработки исключений. По сути, существуют классы, которые отвечают за исключения, за обработку конкретного вида исключений и за действия, связанные с обработкой того или иного рода исключений. Здесь удается определить политики обработки исключений и обеспечить связь между определенным классом исключений, которые существуют в иерархии классов System Exception или в другой иерархии классов, связанной с библиотеками Enterprise Library, и определить стандартный сценарий действий по обработке этих исключений. Таким образом, обеспечивается последовательный интерфейс обработки исключений, создание политик обработки исключений, поддерживается стратегия обработки исключений на всех архитектурных уровнях корпоративных приложений, а не только на уровне интерфейса, который обеспечивают прикладные сервисы. При этом политики обработки исключений могут поддерживаться, создаваться на разных уровнях администрирования, как для администраторов, так и для разработчиков. Эти политики задаются в форме правил.

При этом нет необходимости править код приложения для того, чтобы политика начала работать и применилась к этому коду. Кроме того, политика обработки исключений подразумевает возникновение исключений и обработку исключений также последовательным образом. Обработчики исключений могут использоваться в разных местах приложения, а также отслеживать взаимосвязи между объектами различных приложений. Можно привести несколько примеров обработки исключений. Сценарий обработки исключения выглядит так: информация об исключениях заносится в протокол, исключения могут перехватываться/преобразовываться/повторно использоваться, может происходить замена исключений в зависимости от их типов.

Следующий блок связан с ведением системных журналов, протоколов. Он называется Login Application Block. Важно отметить, что существует стандартный журнал – Event Log, в который записываются все системные события ОС Windows, связанные как с предупреждениями, так и ошибками. Этот механизм позволяет осуществлять запись прямо на уровне системного журнала, а также передавать сведения о системных событиях, ошибках по электронной почте, записывать данные в базу данных, в очередь сообщений, в текстовый файл, создавать события, используя механизм из ядра, который называется Instrumentation, а также использовать точки расширения этого функционального блока, которые имеются у него, как у прочих функциональных блоков Enterprise Library.

Опять-таки настройки конфигурации независимы от кода и позволяют без перекомпиляции использовать изменения метаданных и применять их к корпоративным приложениям. По сути, речь идет об изменении сценариев ведения системной информации, без переписывания, без коррекции кода приложения. Какого рода преимущества обеспечивает этот блок? Прежде всего, это упрощение разработки приложений корпоративного типа по целому ряду направлений. Во-первых, используется последовательная политика ведения системных журналов на уровне как приложения в отдельности, так и предприятия, корпорации в целом. Упрощается обучение разработчиков практике ведения системных журналов, поскольку используется стандартная, общая для всей корпорации архитектурная модель, и она используется последовательно, модель протоколирования системных и прикладных событий. Общие или стандартные задачи по реализации, по отслеживанию прикладных и системных событий решаются на единообразной основе и могут быть обобщены для всех корпоративных приложений. Кроме того, поскольку проектирование ведется компонентным образом, можно осуществить доработку или расширение, развитие существующих компонентов журнала на основе описания ситуации обработки событий на уровне разработчиков.

Еще один важный блок связан с выполнением стандартных операций внутри приложения, он называется Policy Injection Application Block. Здесь можно задавать правила, предусловия, постусловия для каждой из стандартных операций. Это регистрация данных, кэширование, обработка ошибок, коррекция или проверка достоверности информации внутри приложения. При этом работа ведется на уровне объектов, и для каждого конкретного объекта приложения можно указать как предусловия, так и постусловия, характерные особенности, в том числе имя сборки, к которой принадлежит объект, имя пространства имен, имя, тип и атрибуты объекта. При этом взаимодействие между объектами приложений обеспечивается посредством традиционных клиент-серверных приложений с использованием клиента и прокси, о которых говорилось в предыдущих главах. Этот блок создает для каждого вновь сконфигурированного класса прокси, который инкапсулирует правила, применяемые к явно назначенным и используемым атрибутам. Существует возможность присоединения средств обмена данными и обработчиков таких средств каждому методу для каждого прокси. И для каждого экземпляра целевого объекта приложения можно создать соответствующие методы и свойства и управлять этими методами и свойствами. То есть политики регламентирования правил, управления пред– и постусловиями, выполнения операций для этих объектов могут осуществляться на разных уровнях, как на уровне приложения, так и на уровне корпорации в целом.

Нужно сказать, что средства обработки событий для каждого канала обмена данными являются повторно используемыми, вообще говоря, не зависят от объектов. Таким образом, каждый обработчик может реализовывать какое-то конкретное требование, например проверку корректности значения того или иного параметра объекта или проверку успешности некоторого события, допустим, авторизации пользователя в системе. При этом в ряде случаев возможна реализация элементарных сценариев, связанных с каждого рода блоком, которые были рассмотрены выше, с блоком обработки исключений, с блоком, который связан с контролем безопасности корпоративных приложений, с блоком, который связан с проверкой корректности, и с блоком ведения системного журнала.

Таким образом, осуществляется возможность интеграции и гибкого применения правил, регламентирующих выполнение различных операций на уровне всей библиотеки Enterprise Library. Существуют достаточно обширные предустановленные обработчики событий для каждого из этих блоков, которые существенно ускоряют разработку приложений на основе библиотеки Enterprise Library и позволяют успешно бороться с проблемами реализации различных приложений на основе большого количества взаимодействующих блоков. Естественно, разработчики могут создавать собственные обработчики событий и политики обработки событий и выполнения операций, которые осуществляют практически произвольные правила для взаимодействия между методами и свойствами каждого из объектов корпоративных приложений. Важно отметить, что реализация каждой прикладной системы создает автоматически прокси и средство обмена данными со своим обработчиком, которое следует аспектно-ориентированному подходу. При этом реализация методов, связанных с объектно-ориентированным подходом, не реализована на уровне блока Policy Injection по ряду причин, которые связаны со сложностью коррекции кода внутри методов отдельных приложений, а также взаимодействием конструкторов классов для различных блоков корпоративного приложения.

Что касается блока, который отвечает за безопасность корпоративных приложений, здесь реализуются механизмы авторизации, безопасного кэширования данных для авторизации и аутентификации пользователя. Важно отметить, что, как и для других блоков библиотеки Enterprise Library, основные функции получаются как надстройка над стандартной библиотекой классов. NET Framework. Основные требования к механизмам обеспечения безопасности при этом сводятся к следующим: требуется аутентификация пользователей, здесь можно использовать одну или несколько систем, механизмов безопасности. То же самое для авторизации пользователей. Если требуется определение тех ролей, в которых может выступать пользователь, тоже можно использовать одну или несколько систем обеспечения безопасности. Можно использовать различные механизмы обеспечения безопасности и для хранения/извлечения информации из профилей пользователей. В рамках одной системы можно использовать кэширование информации, которая описывает аутентификацию и авторизацию пользователя. Все политики безопасности делятся на пять базовых областей – это аутентификация, авторизация, поддержка безопасности на уровне ролей, на уровне профилей пользователей, а также кэширование информации, связанной с аутентификацией и авторизацией пользователей.

Наконец, блок, который называется Unity Application Block, представляет собой контейнер для добавления зависимостей, конструкторов, полей и методов. Этот блок отслеживает ограничения целостности и управляет зависимостями. Он основан на использовании технологии ASP.NET и во многом опирается на эти технологии.

Еще один блок, который связан с обеспечением корректности приложений, ассоциирован с ASP.NET, а также с рассмотренными нами ранее технологиями создания пользовательских интерфейсов Windows Forms и технологией взаимодействия распределенных приложений Windows Communication Foundation. Он позволяет встраивать в приложения на уровне как отдельных элементов корпоративных информационных систем, так и этих систем в целом стандартные и пользовательские механизмы, которые обеспечивают проверку достоверности данных. Например, проверяется корректность ввода на основе тех правил, которые будут указаны. То есть при обработке заказа необходимо проверить, что номер телефона заказчика содержит правильное количество цифр или что дата заказа попадает в тот или иной характерный диапазон. При этом при появлении ошибки, при сопоставлении с правилом проверки корректности возможна отправка стандартного или пользовательского сообщения, указывающего на некорректность операции и комментирующего эту некорректность.

Завершая разговор о библиотеке корпоративных систем, кратко проиллюстрируем примером использования блока Data Access. Используется стандартная сборка Microsoft.Practices.EnterpriseLibrary.Data, которую необходимо добавить в наш стандартный. NET проект и еще одну сборку, которая отвечает за конфигурацию, Microsoft.Practices.EnterpriseLibrary.Configuration. Для этого надо щелкнуть правой кнопкой мыши по свойству References, выбрать пункт меню Add Reference и выбрать место хранения этих сборок, добавить соответствующие файлы, сборки хранятся в формате DLL, и после этого директивой Import добавить классы из этих библиотек, которые понадобятся. По сути, речь идет об импорте классов из компонентов. Необходимо сделать две директивы: Import Microsoft.Practices. EnterpriseLibrary.Data и Import Microsoft.Practices. EnterpriseLibrary.Data.SQL. И далее стандартным образом использовать обработку событий, конкретно нужно взять функцию обработки событий PageLoad и добавить код, в данном случае на языке Visual Basic:

Код задает создание базы данных и подключение к этой базе данных. При этом нужно передать в стандартную процедуру подключения строку, задающую SQL-запрос, который должен выбрать из таблицы TableName те или иные данные. Детали можно вписать в зависимости от того конкретного запроса, который будет интересовать. При этом используется стандартная обертка для SQL-команды, стандартный обработчик связи с DataSource и средство связи с базой данных. Этот небольшой код дает возможность стандартным образом подключиться к базе данных и извлечь из нее информацию. При этом абстрагируемся от конкретного вида базы данных и целого ряда других особенностей, связанных с получением данных из этого источника. В результате получается компонент, который реагирует на системные события, запрашивая данные из базы данных.

Таким образом, были обсуждены основные возможности работы по созданию корпоративных приложений на основе библиотеки Enterprise Library, рассмотрено устройство и работа этой библиотеки. Она основана на стандартном наборе классов. NET Framework, является надстройкой над ним, включает ядро и механизмы, которые называются Application Block и представляют собой наборы сборок, наборы компонентов. NET, для реализации стандартных процедур, возникающих у разработчиков при работе с рядом стандартных задач для проектирования и реализации корпоративных приложений.

Глава 16 Разработка корпоративных систем, ориентированных на базы данных (Microsoft SQL Server)

Продолжим тему о системах управления данными, речь о которых уже шла в предыдущей главе, на примере СУБД Microsoft SQL Server 2008.

Это одна из последних версий, предоставляющая достаточно серьезные возможности по реализации корпоративных приложений с точки зрения управления данными, управления транзакциями, безопасностью, интеграцией с офисными приложениями и т. д. В данной главе прежде всего рассмотрим, каким образом эволюционировал Microsoft SQL Server: достаточно большое количество версий сервера баз данных было создано Microsoft, начиная от настольных приложений, однопользовательских и заканчивая распределенными, многопользовательскими, корпоративными, достаточно серьезными системами.

Рассмотрим основные возможности, основные службы, которые реализует этот сервер. Это службы анализа данных; служба обеспечения сетевой готовности; службы интеграции, управляемости, обеспечения производительности и масштабируемости; службы программируемости или обеспечения генерации отчетных данных; служба, обеспечивающая безопасность; службы, обеспечивающие обработку пространственных данных, в частности географических карт. Все знают, что такое Google Maps или Google Earth, у Microsoft тоже есть похожее средство для визуализации картографической информации. Кратко перечислим основные версии Microsoft SQL Server, которые были созданы:

• 1992 г. – SQL Server 4.2;

• 1993 г. – SQL Server 4.21 под Windows N T;

• 1995 г. – SQL Server 6.0, кодовое название SQL95;

• 1996 г. – SQL Server 6.5, кодовое название Hydra;

• 1999 г. – SQL Server 7.0, кодовое название Sphinx;

• 1999 г. – SQL Server 7.0 OLAP, кодовое название Plato;

• 2000 г. – SQL Server 2000 32-bit, кодовое название Shiloh (версия 8.0);

• 2003 г. – SQL Server 2000 64-bit, кодовое название Liberty;

• 2005 г. – SQL Server 2005, кодовое название Yukon (версия 9.0);

• 2008 г. – SQL Server 2008, кодовое название Katmai (версия 10.0).

Истоки современного SQL-сервера имеют достаточно продолжительную историю. Это порядка 15 лет, даже, наверное, больше и, пожалуй, где-то на версии 7.0 (1999 г.) с кодовым названием «Сфинкс» Microsoft удалось выйти на рынок корпоративных систем. До этого решения были для малых, настольных систем, и здесь достаточно серьезно был улучшен интерфейс, возможности. В итоге Microsoft удалось создать достаточно серьезную масштабируемую систему. Можно долго рассказывать о том, кто и как называл свои SQL-серверы из основных производителей, ведь Oracle-сервер называется Enterprise Server, и Microsoft одно время использовала это название, и слова SQL Server тоже были использованы многими производителями. Пожалуй, версия 7.0 была первой версией с серьезным графическим интерфейсом для администрирования, с хорошими, удобными средствами администрирования и существенной коррекцией исходного кода, по сути, полной переработкой исходного кода, для устранения претензий со стороны Sybase.

Версия 2005 появилась в ноябре 2005 г., вместе с Visual Studio 2005. Понятно, что это платформа. NET, и обеспечивалась интеграция не только с платформой, но и со средством разработки. Пожалуй, в SQL Server 2005 было наиболее серьезное развитие интегрированной среды разработки, и был создан и разработан ряд дополнительных подсистем. В частности, это система извлечения/ преобразования/загрузки данных ETL, а также компонентов интеграции SQL Server Integration Services, далее будем называть эту технологию SSIS, OLAP-сервер аналитической обработки или онлайн-обработки многомерных моделей данных и сбора релевантной информации. Эти службы находятся в составе Microsoft Analysis Services и ряда служб сообщений (Service Broker, Notification Services). По сути, на этой платформе с небольшими, но важными изменениями, направленными на интеграцию и на еще большую специализацию корпоративных приложений, и построен SQL Server 2008.

Концепция платформы данных Microsoft, на которой основан этот сервер, заключается в следующем: упрощается управление любыми данными, в любом месте и в любой момент времени. При этом поддерживается возможность хранения в базах данных информации, полученной как из структурированных, так и полу– или неструктурированных источников данных, т. е. из источников данных с различной степенью структурированности, например, изображения, видеофайлы, аудиофайлы, музыка и т. д. В SQL Server 2008 имеется большой набор интегрированных служб, которые расширяют возможности доступа, извлечения и использования данных. Можно составлять запросы, выполнять поиск, производить синхронизацию, делать отчеты, анализировать различного рода данные разной степени структурированности и получать к ним доступ как с настольных компьютеров, так и с мобильных устройств, осуществлять полное управление данными независимо от того, где они хранятся.

Как правило, данные хранятся на серверах, которые входят в состав центра обработки данных, Data Center. В этом заключается концепция данных корпорации Microsoft. При этом SQL Server 2008 позволяет осуществлять доступ к данным практически из любого корпоративного приложения, которое основано на технологии, на платформе. NET и на инструментальном средстве Visual Studio. С другой стороны, осуществляется возможность работы в рамках сервисно-ориентированной архитектуры при поддержке Microsoft BizTalk сервера, который обеспечивает интеграцию корпоративных приложений на основе SOA, а также бизнес-процессов этой архитектуры.

Таким образом, сотрудники, которые отвечают за сбор и анализ информации, могут работать как с данными в системе Microsoft Office, так и с другими корпоративными приложениями внутри корпорации. Фактически они работают в привычной офисной среде и пользуются механизмами Visual Studio.NET, платформой. NET и SQL Server 2008. При этом поддерживаются надежность, высокая производительность и достаточно интеллектуальная обработка, извлечение, коррекция, интеграция, составление отчетов и трансформация этих отчетов в офисные форматы, которые отвечают всем основным требованиям по работе с данными, представленными и реализованными в Microsoft Office, Microsoft.NET платформе. Как видно из рис. 16.1, который описывает SQL Server, этот сервер поддерживает обработку данных на основе концепции центра данных.

Рис. 16.1. SQL Server как центр данных

Все данные хранятся в едином центре и поддерживают различные виды хранения и использования сущностей как на основе стандартных баз данных реляционной структуры, реляционных СУБД, так и на основе стандарта XML, который позволяет описать гетерогенные данные, слабоструктурированные в том числе. Некоторые данные просто хранятся в виде файлов. Существуют возможности онлайнового анализа данных на основе OLAP-технологий, и реализованы службы, которые применимы ко всем этим видам сущностей. Можно создавать запросы, анализировать, генерировать отчеты, осуществлять интеграцию этих данных, синхронизацию и поиск данных, а также работу в облачной модели данных над хранилищами данных, которые объединяют данные различной степени структурированности. Доступ возможен как с настольных, так и с мобильных компьютеров в рамках различных профилей доступа.

Какого рода технологии поддерживаются Microsoft SQL Server? Прежде всего, службы аналитики, которые позволяют создавать комплексные корпоративные решения, вести анализ данных и фактически получать приборную панель, на основе которой руководство может судить о производственных показателях корпорации. При этом, с точки зрения пользователя, руководство, как правило, является не профессиональными разработчиками, а скорее квалифицированными пользователями. Можно вести работу в терминах Microsoft Office, привычных каждому пользователю.

Интеллектуальный анализ данных осуществляется на платформе Microsoft Business Intelligence (Microsoft BI) с возможностью реализации упреждающей аналитики, встроенной в SQL Server 2008. Здесь используются мощные средства анализа данных, которые позволяют осуществить интеграцию с произвольными офисными и корпоративными приложениями. Обеспечивается высокий уровень сетевой доступности и готовности, минимизирующей время простоя и поддерживающей должный уровень доступности приложения. Службы интеграции отличаются хорошей масштабируемостью и степенью извлечения, преобразования и загрузки данных, а также широкими возможностями интеграции гетерогенных источников данных различной степени структурированности. Система управляемости основана на принципе политик, который позволяет управлять одним или несколькими экземплярами серверов.

Кроме того, существуют средства контроля производительности тонкой настройки, поиска и устранения неполадок, которые позволяют администратору увеличить эффективность управления данными различных экземпляров SQL-серверов. Средства производительности и масштабируемости поддерживают как вертикальную масштабируемость для отдельных серверов, так и горизонтальную для больших баз данных, а также средства оптимизации производительности в форме консоли, которая достаточно удобна. Поддерживаются различные средства создания программных расширений при помощи платформы. NET Framework и Visual Studio Team System, поддерживающей командную разработку.

Служба отчетов – это комплексная серверная платформа, которая отвечает различным потребностям для создания отчетности и доставляет релевантную информацию на рабочее место, в том числе в офисном формате. Что касается безопасности, то поддерживается расширенное управление параметрами систем безопасности, строгая проверка подлинности, аутентичности, контроля доступа, шифрование и управление ключами и расширенный аудит данных. Кроме того, реализуется подсистема для управления пространственными данными, которая поддерживает комплексную работу, в том числе обработку данных о географическом положении и консолидации данных, выборки данных на основе информации о пространственных данных.

Продолжим обсуждение служб Microsoft SQL Server. Что касается служб, которые связаны с анализом данных, то прежде всего это OLAP-служба, для создания и развертывания новых систем разработчикам приходится осваивать и использовать много новых средств. При использовании служб Analysis Services можно использовать на платформе Visual Studio единую среду разработки, которая называется BIDS (Business Intelligence Development Studio). По сути, это надстройка над Visual Studio, которая также связана со средством командной разработки Team System: в связи с этим у разработчиков есть ресурсы для проектирования, разработки, совместной работы, оптимизации и тестирования. В результате появляется интегрированная среда с интуитивно ясным интерфейсом, где разработчики могут достаточно быстро и эффективно создавать приложения. Кроме того, повышается производительность труда при разработке за счет мастеров бизнес-аналитики, Business Wizards, которые дают возможность даже начинающим пользователям строить модели достаточно сложных задач бизнес-аналитики. Таким образом, разработка решений, в том числе многомерная, OLAP, использование механизмов KPI анализа ключевых показателей и других задач, связанных с OLAP-обработкой данных, становится доступной большому количеству аналитиков, а не профессионалов в области разработки.

Проверка корректности структуры данных в интерфейсе SQL Server (рис. 16.2) реализуется посредством иерархии Calendary и по отношению к измерению времени на основе оповещений. Это одно из новых дополнений, которое автоматически информирует о возможных недочетах на ранних стадиях процесса разработки, позволяет сократить потери времени, вызванные проектными ошибками, и ускорить разработку. Это просто пример оповещения. Как видно из рисунка, выделяются проблемные области, они подсвечиваются. При этом они не затрагивают функциональность системы, поскольку оповещения можно как игнорировать, так и отклонять либо по отдельности, либо глобально. Вообще же таким образом можно осуществлять контроль над относительно неэффективными решениями на ранних этапах разработки. Напомним, что методология Microsoft призвана как раз выявлять ошибки на ранних стадиях разработки и осуществлять в связи с этим оптимизацию производительности по затратам времени и средств. Кроме создания оповещений в реальном времени, возможно насквозь осуществлять сканирование проекта решения и затем выдавать текущее оповещение по проекту, как это показано на рис. 16.3, который демонстрирует набор правил для проверки корректности, в том числе на основе OLAP-анализа данных, многомерной оптимизации, анализа многомерных данных на основе куба в пространственном приложении и т. д.

Рис. 16.2. Проверка корректности структуры данных

Рис. 16.3. Набор правил для проверки корректности

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

Рис. 16.4. Проектирование связи между атрибутами

Рисунок 16.5 демонстрирует интеграцию с офисными приложениями, в том числе с Microsoft Excel.

Частично возможности подобной интеграции рассматривались при обсуждении офисных приложений. Нужно добавить, что приложение Excel 2007 является полнофункциональным клиентом служб Analysis Services, которые входят в состав SQL Server 2008. При этом возможности Excel 2007 поддерживаются в следующих областях: это доступ к данным, которые хранятся в OLAP-кубах служб Analysis Services. Excel позволяет создавать сводные таблицы с представлением многомерных данных, т. е. пользователи в рамках привычных им интерфейсов Microsoft Excel могут по-разному разбивать данные, обрабатываемые на сервере, результаты кэшируются на сервере и на клиенте и дают возможность повышения производительности вычислений. Доступ пользователей к функциям и аналитическим возможностям служб Analysis Services – это ключевой показатель эффективности KPI, вычисляемые элементы, именованные наборы данных, есть и переводы, также осуществляются централизованно.

Рис. 16.5. Интеграция с MS Excel

Надстройки над приложениями Office 2007, не только Excel, но и над другими приложениями, для извлечения и обработки данных, которые предоставляют в распоряжение конечных пользователей средства анализа и прогноза данных, реализованы в SQL Server 2008. Новой является функция автоматического анализа, например, определение исключений, в которых данные отличаются от шаблонов, которые заранее заданы или наблюдаются в других областях таблицы, а также специализированных диапазонов данных, которые можно выделить, функции предсказания будущих данных по текущим тенденциям, анализ сценариев моделирования по определенным условиям, определение изменений, необходимых для достижения какой-либо конкретной цели, также можно фиксировать и отслеживать. Создание отчетов по информации, которая предоставлена службами Analysis Services, при помощи служб отчетов Reporting Services и визуализация этих отчетов в виде таблиц Excel дают возможность обеспечить большую доступность для конечных пользователей.

Далее обсудим средства и пути анализа данных. Используются средство Data Mining Client для Excel 2007 и определенные шаблоны, которые поддерживают интеграцию Data Mining, добычу данных для Visual Studio 2007. В надстройке BIDS (Business Intelligence Development Studio) Visual Studio 2007, о которой уже говорилось, используется средство Data Mining Designer. Естественно, реализация средств анализа данных основана на концепции объектов, и используется подход Analysis Management Objects (AMO) и открытые интерфейсы API на его основе. Также возможно подключение сторонних алгоритмов для анализа данных.

Хотя распространение генерации отчетов в многомерной аналитике принесло существенные выгоды большому количеству корпораций, следующим шагом в повышении гибкости в бизнес-процессах и эффективности функционирования корпораций должен стать переход от ретроспективного анализа данных за прошедшие периоды к активным действиям, основанным на результатах прогноза бизнес-данных, и внедрению в бизнес-процессы рациональных процедур принятия решения. Ключом к решению такой задачи является использование мощных алгоритмов извлечения и обработки информации для анализа набора данных, сравнение новых данных с фактическими и прошлым ходом событий, классификации и выявления связей между хозяйствующими субъектами, атрибутами, а также составление точных прогнозов для всех систем и пользователей, которые принимают решение.

Как и в случае с OLAP-технологиями, извлечение и обработка данных ранее было прерогативой узких специалистов высокой квалификации и было поэтому дорогостоящим. Однако сейчас за счет комплексной реализации технологии извлечения и обработки данных в службах Analysis Services и тесной интеграции с приложениями Office 2007, в частности Excel, корпорации Microsoft удалось создать достаточно эффективные экономические решения, которые позволяют практически каждому пользователю, знакомому с Office, делать задачи по извлечению и анализу данных на основе использования служб Service Analysis платформы SQL Server.

Проиллюстрируем возможности извлечения данных, Data Mining, на основе стандартного клиента для Microsoft Excel 2007. Именно это средство облегчает извлечение и анализ данных для пользователей, поскольку основано на стандартной платформе Office. Этот набор средств дает возможность эффективного анализа и визуализации различных представлений данных (рис. 16.6) средствами офисных приложений, в данном случае электронные таблицы.

Рис. 16.6. Data Mining Client для Excel 2007

Таким образом, пользователи могут повысить эффективность принимаемых ими решений, оперативно получая практические рекомендации путем выполнения нескольких простых действий, для чего существует специализированная надстройка, которая называется Table Analysis Tools для Excel 2007. Сложность извлечения и обработки данных при этом инкапсулируется набором интуитивно понятных задач, которые дают возможность пользователям относительно прозрачно переходить от исследования к построению предметно-ориентированного решения на основе тех понятий, которыми они владеют, в бизнес-терминах и производить эффективное извлечение и анализ данных, проверять их корректность и осуществлять доступ к этим данным. Также существуют шаблоны, которые называются Data Mining Templates и позволяют извлекать и обрабатывать данные на основе приложения Visio. Хотелось бы напомнить, что Visio имеет средства интеграции с Microsoft Visual Studio и является на сегодня компонентом Microsoft Office, т. е. интегрирован и с. NET, и с SQL Server 2008. При этом возможно достаточно легкими средствами генерировать большое количество стандартного рода диаграмм и таким образом формировать широкую, интуитивно понятную и способствующую коллективной работе систему, которая открывает путь к повышению эффективности совместно принимаемых бизнес-решений по всей корпорации с учетом анализа и прогноза данных.

На рис. 16.7 представлен пример применения средства Data Mining Designer, который позволяет интегрировать средства извлечения данных и бизнес-аналитики в пакет Microsoft Office 2007.

Рис. 16.7. Пример применения средства Data Mining Designer

При этом используется средство интеграции с SQL Server, которое называется BIDS. Оно имеет проектно-ориентированную структуру и содержит все средства, которые позволяют отлаживать и управлять исходными текстами, как и в Visual Studio, для того чтобы бизнес-аналитики могли не только проектировать, но и создавать и корректировать собственные решения. Естественно, такой подход возможен только для достаточно квалифицированных пользователей, которые могут создавать собственные системы, и позволяет грамотно распределять функционал между пользователями разных уровней, декомпозировать задачи и получать их решения в сжатые сроки и с наивысшим качеством.

Business Intelligence Development Studio – это фрагмент SQL Server, который представляет собой комплексную среду разработки на основе Microsoft Visual Studio, это надстройка над Visual Studio. С помощью этой среды разработчики могут создавать структуру данных для их извлечения и обработки, могут настраивать доступ к данным по столбцам, к данным таблиц, добавлять множество моделей для извлечения и обработки данных, в том числе гетерогенных, слабоструктурированных, которые предусматривают различные алгоритмы извлечения данных и размещения их в этих таблицах. По сути, речь идет о применении технологии, схожей с DataGrid, т. е. достаточно гибкой технологии по извлечению и представлению данных, их форматированию для создания корпоративных консолидированных отчетов.

Шаблон приложения проекта служб Analysis Services BIDS, изображенный на рис. 16.8, включает в себя средства проектирования с интуитивно понятным интерфейсом для создания и просмотра моделей извлечения и обработки данных, а также обеспечивает перекрестную проверку корректности и построения диаграмм превышения и прибыли.

Рис. 16.8. Performance Point Server

Это позволяет перед развертыванием моделей сравнить их качества, причем используя средства визуального контроля, и по результирующим статистическим метрикам погрешности и точности обеспечивает корректный выбор процедуры дальнейшего развития корпоративных систем и корпоративной стратегии. Существует стандартное средство, встроенное в Microsoft SQL Server, которое называется Performance Points Server и создано для оценки и анализа KPI (Key Performance Indicators) – основных показателей бизнес-деятельности.

На рис. 16.8 представлено решение, которое используется на значительном количестве предприятий корпоративного типа для оценки соответствия различных плановых значений, прежде всего финансовых показателей, ключевым значениям. Это одна из основных бизнес-метрик. Служба Analysis Services SQL Server 2008 обеспечивает централизованную базу данных для учета KPI в масштабах всей корпорации. При этом существует приложение Microsoft Office Performance Point Server 2007, с которым поддерживается интеграция, что дает возможность топ-менеджерам и лицам, принимающим решения, создавать специализированные панели, Dashboard или аналоги приборной панели, где они могут отслеживать ключевые показатели компании и принимать решения на основе динамики анализа этих показателей. При этом ключевые показатели традиционно имеют ретроспективный характер. Можно отслеживать, например, динамику продаж с учетом изменения запасов за последний месяц, квартал, год и т. д., а располагая знаниями прогностического анализа, организация может формулировать ключевые показатели KPI на будущие периоды и планировать свою деятельность, выявлять и разрешать потенциальные проблемы и узкие места.

На рис. 16.8 изображен один из показателей эффективности KPI, а именно число заказов, которые относятся к будущему периоду и, как ожидается, будут размещены впоследствии. Рисунок 16.9 иллюстрирует Reporting Services.

Следует напомнить, что построение консолидированных отчетов является важной целью для каждой корпорации, для анализа результатов функционирования различных компаний, подразделений и видов деятельности. Для построения такого рода отчетов существуют службы Reporting Services на платформе SQL Server 2008, которые дают возможность генерации параметрических отчетов исходя из прогнозируемой вероятности. Например, рис. 16.9 иллюстрирует результаты запроса, который анализирует список потенциальных клиентов некоторой гипотетической компании Adventure Works, занимающейся продажей велосипедов, и оценивается вероятность покупки этими клиентами велосипедов. Запрос фильтруется таким образом, чтобы в результате возвращались только те потенциальные клиенты, для которых вероятность покупки превышает 50 %. Представлен полученный отчет, на основе которого корпорация может разработать маркетинговую кампанию, нацеленную только на ту аудиторию, которая с наибольшей вероятностью осуществит такую покупку велосипеда. Подобная процедура существенно повышает эффективность работы корпорации по направлениям и дает возможность обеспечить окупаемость инвестиций.

Рис. 16.9. Reporting Services

Следующая схема иллюстрирует обеспечение сетевой готовности в рамках SQL Server 2008:

• поврежденные страницы данных можно восстановить с зеркального сервера благодаря улучшенному зеркалированию баз данных;

• улучшения в создании отказоустойчивых кластеров в ОС Windows Server 2008;

• новые узлы в одноранговую репликацию можно добавлять во время работы, не отключая репликацию;

• сжатие резервных копий позволяет сократить время, требуемое на восстановление, а также уменьшить количество занимаемого резервными копиями пространства;

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

• возможность горячей замены процессора снижает время простоев из-за обслуживания оборудования;

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

Как указывалось ранее, хранение данных под управлением СУБД осуществляется в страницах памяти. Если происходит повреждение страниц данных, например в результате программного или аппаратного сбоя, то поврежденные страницы можно восстановить благодаря улучшенному зеркалированию баз данных, используя зеркальные серверы. Также реализован целый ряд механизмов по усовершенствованию отказоустойчивости кластеров на основе функционирования ОС Windows Server 2008, т. е. на уровне ОС. Новые узлы, т. е. новые машины, можно добавлять во время работы сервера, не отключая механизмы репликации, и при этом репликация продолжается. Резервные копии могут храниться в сжатом виде, что обеспечивает сокращение времени восстановления и позволяет существенно уменьшить количество пространства, которое отводится на хранение резервных копий. Изменения в механизме блокировок транзакций, улучшенная обработка блокировок транзакций (существуют взаимные блокировки транзакций и целый ряд проблем, связанных с разрешением этих блокировок) улучшают одновременную работу большого количества пользователей, что является крайне важным для корпоративных приложений. Кроме того, существует возможность горячей замены процессора сервера базы данных, что обеспечивает снижение времени простоя и, кроме того, может обеспечить динамическую приоретизацию с упреждающим контролем приоритетности нагрузки, т. е. улучшенное управление ресурсами.

Еще один важный аспект функционирования Enterprise Server 2008 связан с SSIS (SQL Server Integration Services) – службой интеграции, в данном случае он существенно улучшен по сравнению со стандартным ETL-подходом к интеграции, который лежит в основе большинства информационных хранилищ. ETL – это извлечение, преобразование и загрузка данных. Однако потребности в реализации совместного использования большого количества разнообразных источников данных, а также соседство глобальных онлайновых операций быстро меняют традиционные требования к интеграции данных. При этом для извлечения максимальной выгоды, достижения максимальной эффективности собранных и подлежащих анализу данных необходимо повышение эффективности интеграции этих данных для повышения эффективности принятия решений и обеспечения консолидированных отчетов. В связи с этим службы интеграции дают нам возможность построения достаточно гибкой и масштабируемой архитектуры, которая повышает эффективность интеграции гетерогенных данных различной степени структурированности, в различных корпоративных бизнес-средах. Для корпорации Enterprise Server является достаточно хорошим решением.

Рисунок 16.10 иллюстрирует традиционную схему извлечения, преобразования и загрузки данных. Без подходящей технологии система требует промежуточного хранения практически на каждом этапе процесса размещения данных в хранилище и их интеграции. Так как в процесс выборки, преобразования и загрузки данных ETL нужно включать разные, в том числе нестандартные, гетерогенные источники данных и выполнять над ними сложные операции преобразования, например просеивание данных, анализ текста, существенно возрастает потребность в хранении промежуточных данных. Как показано на рис. 16.10, с увеличением количества точек промежуточного хранения существенно возрастает время, которое затрачивается на закрытие цикла анализа, на выполнение действий над этими данными.

Рис. 16.10. Отсутствие промежуточного хранения данных

Поэтому традиционные ETL-архитектуры существенно ограничивают возможность системы реагировать на новые требования бизнеса. На рис. 16.10 представлена структура SSIS, которая реализована в SQL Server, минимизирует промежуточное хранение данных, совершенствуя ETL-процессы, и справляется с большинством технологических проблем, возникающих при интеграции и промежуточном хранении данных. Как показано на рисунке, SSIS минимизирует или вовсе исключает промежуточное хранение. При этом службы позволяют обеспечить возможность сложных манипуляций над данными на основе конвейерных операций и реагировать на изменение данных достаточно оперативно. Такого рода архитектура существенно отличается от традиционных и позволяет повысить эффективность манипулирования и совместного использования гетерогенных данных.

Рассмотрим структуру SSIS – Microsoft SQL Server Integration Services. В основе лежит разделение на потоки задач и потоки данных, без промежуточного хранения и без дублирования информации. SSIS содержат ядро поддержки потока задач, которое ориентировано на операции, а также масштабируемое быстрое ядро поддержки потока данных. Поток данных при этом существует в контексте общего потока задач. Первое ядро предоставляет ресурсы и поддержку операций для второго ядра. Такое сочетание потоков задач и потоков данных этих двух ядер обеспечивает эффективность подхода как для традиционных ETL-решений, так и для гетерогенных информационных хранилищ. При этом во многих более сложных ситуациях, например при поддержке центров обработки данных, использование подобного подхода оправданно и повышает эффективность.

Что касается потоков данных, попробуем рассмотреть некоторые примеры, в частности применение SSIS для поддержки процессов и работ, которые ориентированы на центры обработки данных. В основе лежит применение конвейерного подхода для преобразования данных. Архитектура конвейера поддерживает буферизацию, что позволяет конвейеру достаточно быстро осуществлять манипуляции над наборами данных после их загрузки в память. При этом суть похода заключается в выполнении всех этапов ETL-преобразований в рамках одной операции без промежуточного хранения. Хотя специфичные требования к преобразованию, операциям или оборудованию могут несколько осложнить реализацию этого подхода, тем не менее для повышения производительности архитектура позволяет в целом минимизировать объем промежуточного хранения данных. SSIS, по возможности, даже избегает копирования данных памяти, что принципиально отличается от традиционных ETL-средств, которые часто требуют промежуточного хранения данных практически на каждом этапе процесса преобразования, обработки, интеграции данных. Такого рода поддержка манипуляций над данными без промежуточного хранения позволяет существенно улучшить ETL-средства, а также дать возможность поддержки хранения и манипулирования с реляционными и плоскими данными. При этом гетерогенные данные, как структурированные, так и неструктурированные, хранящиеся в формате XML и т. д., перед загрузкой в буферы преобразуются в табличную структуру, т. е. разбиваются на строки и столбцы. И далее любую операцию с табличными данными можно выполнять на любой стадии функционирования конвейера поточной обработки данных. Это означает, что единственный конвейер способен интегрировать разнообразные источники данных и выполнять над этими источниками данных операции произвольной степени без промежуточного хранения. Конечно, если промежуточное хранение по эксплуатационным требованиям является необходимым, то SSIS дает возможность поддерживать и такого рода реализации. Эта архитектура позволяет применять SSIS в самых разных сценариях интеграции данных, от традиционных ETL-решений до нетрадиционных способов интеграции гетерогенной корпоративной информации.

SSIS судя по рис. 16.11 дает возможность комплексной полнофункциональной ETL-интеграции, обеспечивая возможности по функциональности, масштабируемости и производительности, существенно более высокие, чем у большинства конкурирующих аналогов, при значительно меньших затратах. Особенность решения составляет конвейерная архитектура, которая дает возможность получать данные из множества источников одновременно, выполнять целый ряд преобразований последовательно и передавать данные нескольким приемникам в параллельном режиме. Такого рода архитектура дает возможность применять SSIS-технологии не только для больших наборов данных, но и для множественных потоков данных. При перемещении данных из источника к приемнику или из нескольких источников к нескольким приемникам можно разделять, объединять, комбинировать потоки данных или иным образом манипулировать информацией. Рисунок 16.11 дает иллюстрацию примера манипулирования потоками данных при таком преобразовании. Рисунок 16.12 иллюстрирует процесс очистки данных.

Рис. 16.11. Схема интеграции данных

SSIS тесно интегрирована с функциональностью просеивания или очистки данных в службах анализа данных. Поддержка анализа данных обеспечивает абстрагирование от закономерностей в наборе данных, инкапсулирует их модели анализа. Можно применять эту модель анализа для того, чтобы предсказать, какие данные относятся к набору, а какие нет, т. е. просеять данные и отсечь так называемые аномальные. То есть можно использовать анализ данных как инструмент, который повышает качество данных в корпоративной системе и снимает противоречия или намеренные искажения данных сотрудниками. Поддержка сложного распределения данных в SSIS позволяет не только выявить аномальные данные, но и автоматически корректировать или заменять их. Это делает возможным варианты очистки по принципу замкнутого цикла.

Рис. 16.12. Очистка данных

Пример использования потока как источника данных, эта важная особенность SSIS, представлен на рис. 16.13.

Имеется возможность загрузки данных в компонент Data Reader ADO.NET. Этот компонент можно включить в конвейер потока данных, что дает возможность использовать Data Reader как источник данных, которые предоставляются собственно ADO.NET. При этом можно использовать SSIS не только как традиционные ETL-инструменты для загрузки, преобразования данных в хранилище, но и как источник данных, который может предоставлять доступ к интегрированным и синхронизированным в очищенные данные источник, причем по запросу пользователя, и делать это даже из офисных приложений. Например, эту функциональность можно задействовать для того, чтобы службы отчетов, Reporting Services, извлекали данные из множества разнообразных источников, в которых хранится информация для корпоративных приложений. При этом SSIS-пакеты используются как источник данных. Для управляемости корпоративных систем на основе SQL Server используются подходы, связанные с политиками, автоматизированным обслуживанием на основе задач, и оповещение операторов и графиков, средства Performance Data Collection, которые позволяют оптимизировать производительность графическим образом, и специальный инструмент для оптимизации индексов таблиц баз данных и разделов, который называется Data Base Engine Tuning Advisor. Осуществляются принципы упреждающего управления, которые обеспечивают: логическое представление конфигурации системы, что позволяет администраторам заблаговременно определять желаемую конфигурацию служб данных, а не вносить изменения после того, как возникнут проблемы; интеллектуальный мониторинг, который поддерживает на основе политик инфраструктуры управление, отслеживание и запрещение изменений, несовместимых с желаемыми конфигурациями; а также виртуализацию управления, которая позволяет масштабировать изменения по инфраструктуре, структуре корпорации, передавать или распределять их по большому количеству серверов, что облегчает применение унифицированных политик во всей организации.

Рис. 16.13. Использование потока как источника данных

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

На рис. 16.14 представлен механизм инструментария для создания политик. SQL Server 2008 поддерживает существенно расширенный набор элементов управления конфигурациями и правилами настройки сервера баз данных.

Приведем несколько примеров использования такого рода элементов для формирования политики на основе аспектов. Aspect-сервер позволяет принудительно применять выбранные параметры конфигурирования сервера, например определять режим проверки подлинности регистрационной информации при входе в систему.

Рис. 16.14. Создание политик

Aspect Surface Area позволяет управлять активными функциями и уменьшить потенциальную уязвимость сервера. Aspect Data Base управляет изменением определенных параметров баз данных, например параметров совместимости. Aspect Multipart Name обеспечивает соблюдение правил именования таблиц, представление других объектов баз данных, определенных в схеме. Ряд других аспектов позволяет реализовать приемы и методы работы, рекомендованные для конкретных решений или конфигураций баз данных, например хранение файлов с данными или файлов с журналом изменений на жестких дисках.

Еще один инструмент называется Performance Data Collection и позволяет осуществлять сравнение интегрированных отчетов о функционировании серверов в графическом виде. Он дает возможность быстро проанализировать собранные данные с использованием стабильно работающих системных наборов элементов сбора данных. Системный набор элементов данных сервера, Server Activity, является важной отправной точкой для большинства сценариев, осуществляющих мониторинг по устранению неполадок в системе. Группа отчетов, связанная с каждым из системных наборов данных сбора и набора элементов для сбора данных, публикуется в SQL Server Management Studio. На основе этих отчетов можно сделать приборную панель, которая информирует о производительности. Она так и называется – Performance Dashboard. При помощи этой приборной модели (рис. 16.15) можно анализировать производительность СУБД.

Кроме этих системных отчетов можно использовать другие отчеты Performance Studio о производительности, например, SQL Server Management Studio поддерживает другие отчеты, один из которых представлен на рис. 16.16 – стандартный отчет об использовании памяти. Важным средством работы системных администраторов с сервером в консольном виде на основе MMC (Microsoft Management Console) – стандартной оснастки, представлен на данном рисунке, это SQL Server Configuration Manager. В виде консоли можно осуществлять оптимизацию параметров сервера на основе целого ряда инструментов в жесткие сроки и в привычном интерфейсе. Средства конфигурирования SQL Server позволяют администратору управлять группами служб, ответственных за вверенные им функции. Это дает возможность администраторам сосредоточиться на управлении базами данных и оптимизации их производительности.

Рис. 16.15. Отчет о функционировании сервера

Что касается производительности и масштабируемости, то осуществляется как горизонтальное, так и вертикальное масштабирование. Это важно для крупных корпораций с большим количеством серверов. При горизонтальном масштабировании используется оптимизация мощностей сервера, возможно горячее переподключение или замена оборудования. При вертикальном масштабировании осуществляется обработка на основе использования резервных копий данных. Кроме того, поддерживается одноранговая репликация, маршрутизация данных, а также те возможности, о которых говорилось в связи с Performance Studio. Это крайне важно для больших корпораций с быстрым ростом объемов существенных данных, количества пользователей и для тех организаций, где масштабируемость приложений является бизнес-критичной. SQL Server 2008 предоставляет устойчивый обработчик баз данных, который может работать с большими реляционными базами данных и обеспечивает обработку сложных запросов.

Рис. 16.16. Отчеты SQL Management Studio

Что касается программируемости, то имеется целый ряд средств, которые поддерживают обработку на основе LINQ. Это средство формирования запросов на основе объектных технологий, а также используются все механизмы Visual Studio и SQL Server Compact Edition для работы с мобильными средствами связи. LINQ-ToSQL поддерживает оперативную разработку приложений с интеграцией программных объектов в SQL с элементами SQL, таблицами, представлениями, хранимыми процедурами и пользовательскими функциями. Существует также LINQToEntities, которым осуществляется поставление объектов реляционным таблицам, LINQToDataSet, поддерживаются также богатые возможности запросов на основе обычных и типизированных наборов данных, LINQToXML, это API для доступа к XML-объектам, хранимым в оперативной памяти, поддерживающей. NET языки и LINQToObject, обеспечивает взаимодействие с произвольными объектами данных в оперативной памяти, а также данными из сторонних источников.

Ряд средств осуществляет управление отчетами. Это управляемая система бизнес-отчетности, которая дает возможность автоматизированного создания отчетов по разным аспектам бизнеса и распространения их по всей инфраструктуре корпорации, обеспечивая в реальном времени доступ к информации каждому сотруднику. Автоматизированная система отчетности дает возможность пользователям создавать свои собственные отчеты с достаточно гибкими возможностями по извлечению, преобразованию информации. Также существует встроенная отчетность с интеграцией между бизнес-приложениями и веб-порталами на основе конкретных бизнес-процессов. При этом поддерживается тесная интеграция с SharePoint Server 2007, со средством создания веб-порталов, и централизованная библиотека отчетов на основе компонентов интегрирована с SharePoint.

Есть возможность создания панелей мониторинга, централизованного сбора структурированных и неструктурированных данных и контроля за доступом пользователей к информационной инфраструктуре корпорации в любой момент времени. Построитель отчетов дает возможность быстрого построения и разворачивания отчетов для большого количества пользователей в единообразной и строгой структуре. При этом отдельные бизнес-пользователи могут настраивать отчеты или создавать собственные отчеты в соответствии со своими конкретными требованиями. Конструктор отчетов является достаточно эргономичным, ориентированным на бизнес-потребности и дает возможность извлекать гетерогенные данные об аспектах деятельности предприятия. Это могут быть заказчики, объем продукции и т. д. На рис. 16.16, где изображен построитель отчетов, показана модель, ориентированная на использование данных для решения коммерческих задач. Построитель отчетов дает возможность пользователям создавать надежные отчеты, не обладая глубокими знаниями о том, как строятся SQL-запросы, каким образом данные представляются в системе и из каких источников они поступают. Диспетчер отчетов позволяет строить управление отчетами через Интернет, осуществлять интернет-доступ к этим отчетам. Администраторы могут при этом просматривать отчеты и управлять настройкой параметров обработки отчетов и безопасности с любого компьютера просто посредством браузера.

Настройка службы отчетов может выполняться как автоматически, исходя из базовой конфигурации, так и посредством использования конфигурации служб отчетов Reporting Services, диспетчер для которой представлен на рис. 16.17.

Рис. 16.17. SQL Server Confguration Manager

Это существенно упрощает для администраторов выполнение ряда задач, необходимых для развертывания служб отчетов, сокращает затраты рабочего времени и ускоряет получение отчетности. Безопасность включает различные виды аутентификации, расширенное управление авторизацией и использование передовых технологий шифрования. Основные виды аутентификации: базовая аутентификация, хеш-аутентификация, аутентификация посредством сетевого протокола NTLM, аутентификация посредством протокола Kerberos, стандартного протокола для Windows 2000 и выше, и встроенная аутентификация.

Базовая аутентификация описывается протоколом HTTP, хеш-аутентификация дополнительно использует алгоритм MD5 перед отправкой данных на сервер, с возможностью подключения удостоверений. Аутентификация по методу NTLM использует протокол запрос-ответ и дает возможность обеспечить безопасную аутентификацию с учетом указания допустимой доменной учетной записи. Аутентификация Kerberos использует специализированный протокол, и необходима регистрация в Kerberos Services Principle Name с помощью специальной утилиты Set SPN, которая входит в набор базового инструментария. Встроенная аутентификация, или Integrated Autentification, объединяет NTLM и Kerberos и по запросу пользователя осуществляет выбор того или иного механизма аутентификации, что обеспечивает наиболее гибкую и безопасную аутентификацию из поддерживаемых возможностей.

Наконец, последний аспект, о котором хотелось бы поговорить в связи с SQL Server, связан с пространственными данными. Это прежде всего данные, связанные с геодезией и картографией, представлением данных, которые могут быть использованы, например для веб-узла розничной торговли, когда можно найти ближайшую торговую точку по карте и проложить маршрут к ней, можно управлять движением менеджера по продажам, при привязке покупателей к продавцам и анализе эффективности продаж. Можно привязывать архитектурный проект нового здания к местоположению на карте, можно определять маршрут для водителя, осуществлять быстрый поиск объектов недвижимости по заданным адресам и вести поиск кафе или автозаправок по заданному адресу, с учетом заданного радиуса действия. Кроме того, можно поддерживать пространственный индекс (рис. 16.18) и импорт пространственных данных. Поддерживается как геодезическая, так и планарная модель и преобразование данных из одного формата в другой. Особенности форматов данных показаны на рис. 16.18.

Производительность запросов пространственных данных существенно повышается за счет поддержки пространственного индекса. Принцип работы – степень детализации. Из рис. 16.18 видно, как осуществляется детализация. Пространственные данные можно индексировать при помощи гибкого многоуровневого сетчатого индекса, интегрированного в ядро базы данных SQL Server. При этом пространственные индексы содержат сетчатую иерархию, в рамках которой каждый уровень индекса дает возможность доступа к сектору сетки, который определен на предыдущем уровне. Концептуальная модель показана на рис. 16.18.

Рис. 16.18. Пространственный индекс

На основе такого рода подхода можно задавать интеграцию с моделью Virtual Earth, это аналог Goolge Earth от Microsoft. На рис. 16.19 показаны районы, которые задаются почтовым индексом, и данные о населении и числе ресторанов на данном фрагменте географической карты.

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

Как видно, Microsoft SQL Server поддерживает действительно гибкую и надежную организацию различных механизмов доступа к данным и интеграцию гетерогенных корпоративных источников данных, а также работу пользователей с данными на основе различных офисных приложений в знакомой им среде.

Рис. 16.19. Интеграция с Virtual Earth

На этом следует закончить рассказ о корпоративных технологиях объектных библиотек данных, а также об управлении этими данными на уровне СУБД. Попробуем подвести промежуточные итоги второго раздела нашей книги.

Были рассмотрены вопросы, связанные с программными архитектурами, CASE-средствами, т. е. средствами автоматизации проектирования корпоративных приложений, и архитектурами взаимодействия этих приложений в распределенных средах. Естественно, для проектирования таких сложных и больших систем, как корпоративная, необходимы специализированные средства, поддерживающие весь их жизненный цикл, от анализа и проектирования до управления сопровождением и документированием. Для иллюстрации корпоративных приложений была использована платформа Microsoft.NET, которая поддерживает языковую интероперабельность, т. е. проектирование компонентных приложений на различных языках программирования, наиболее полно соответствующих требованиям, которые выдвигаются для этих приложений. Надстройкой над классами, поскольку речь идет об объектно-ориентированном проектировании, о компонентно-ориентированном проектировании, постулируется, что всякая сущность есть объект, является целый ряд библиотек, в частности поддерживающих формы доступа к данным, клиентские интерфейсы, например на основе технологии Windows Forms, и проектирование распределенных приложений на основе технологии Remoting, внутренней технологии Microsoft, и более-менее открытых технологий на основе сервисов, сервисно-ориентированной архитектуры, это SOA. Это веб-сервисы и приложения, реализованные на основе Windows Communication Foundation (WCF).

Развитием объектного подхода является компонентно-ориентированная технология, которая дает возможность проектирования и реализации корпоративных приложений на основе открытых интерфейсов и концепции сборок, когда приложения могут поставляться на основе DLL– или EXE-файлов, которые независимы и могут надежно и безопасно интегрироваться друг с другом по запросу, и пользователь оплачивает только стоимость тех компонентов, которые его интересуют. На основе этих компонентов осуществляется построение офисных приложений – была рассмотрена библиотека Visual Studio Tools for Office и корпоративных приложений – библиотека Enterprise Library, которая осуществляет извлечение, преобразование и загрузку данных и интеграцию гетерогенных источников, что позволяет осуществить эффективное, надежное, безопасное и эргономичное манипулирование данными в корпоративных системах.

Раздел III Примеры отраслевых внедрений корпоративных систем

Глава 17 Разработка корпоративных порталов для нефтегазового сектора

Данный раздел книги посвящен практическим аспектам применения корпоративных систем и корпоративных приложений, причем в фокусе внимания будут как технологии Microsoft, так и различные сферы применения. В начале книги были рассмотрены математические модели, которые являются достаточно общим фундаментом для построения корпоративных систем, гетерогенных систем, включающих большое количество разнородных приложений, которые сложно связать между собой. Затем речь шла о методологиях, методах, подходах к проектированию, технологиях, были рассмотрены походы, связанные с такими известными методологиями профессиональной разработки корпоративных систем, как Microsoft Solution Framework (MSF) и Rational Unified Process, и ряд более скромных методологий Agile класса: Scrum, XP и, собственно, Agile. Более подробно был рассмотрен уровень технологий: различные виды архитектур, которые, как например клиент-серверная архитектура, поддерживают разработку распределенных приложений. Корпоративные системы являются распределенными приложениями, поскольку корпорация – это по определению несколько компаний с общими бизнес-задачами, которые территориально распределены, часто глобально. Тогда имеет смысл говорить о транснациональных корпорациях.

Далее была рассмотрена платформа Microsoft.NET, было показано, что это идеология, и обсуждены основные ее возможности, нацеленность на производство интернет-систем, быстрое разворачивание приложений, экономичную разработку, повторное использование, безопасность, компонентно-ориентированный подход. Более подробно были описаны отдельные аспекты технологий проектирования, такие как веб-сервисы, веб-формы, интерфейс, были рассмотрены Windows Communication Foundation, технологии Remoting, направленные на проектирование распределенных интернет-приложений, в том числе и корпоративного типа, и, наконец, библиотеки для корпоративных приложений Enterprise Library, библиотеки для офисных приложений Visual Studio Tools for Office Extension. Последнее, о чем было подробно рассказано, это СУБД Microsoft SQL Server, в том числе механизмы управления, обеспечивающие масштабируемость, производительность, отказоустойчивость, репликацию и готовность.

В данной главе будут представлены корпоративные системы в том виде, как они могут быть использованы в нефтегазовой сфере. Начало главы будет посвящено рассказу о корпорации, корпоративной структуре, в которой происходило внедрение, это международная группа компаний «Итера», и о той структуре корпоративных систем, которая была на некоторый момент времени там реализована. Преимущественно эти системы основаны на технологии Oracle. Далее будут рассмотрены корпоративные порталы в том виде, как они были реализованы для нефтегазовой группы «Итера». Там Microsoft присутствует и как средство разработки, и как среда использования, поскольку и браузеры в основном используются от Microsoft, т. е. клиенты корпоративных систем и инструментальные средства, которые реализованы, во многом используют Visual Studio.NET как инструментарий.

Большинство из описанных здесь систем применимо сегодня практически к любой отрасли, но Oracle достаточно давно разработала решения, которые называются Upstream/Downstream и специально предназначены для производства и распределения именно топливных ресурсов, т. е. для добычи, транспортировки, переработки и последующего распределения именно нефтегазового сырья. И изначально планировалось эти решения реализовать в «Итере», но на сегодня это еще не в стадии эксплуатации. Тем не менее такие расширения существуют, и поэтому в определенной мере платформа Oracle как раз хороша тем, что может быть использована для нефтегазовой сферы со значительным успехом. Платформа Oracle была выбрана еще и потому, что когда в «Итере» происходило внедрение, к сожалению, СУБД Microsoft SQL Server не была настолько масштабируемой и пригодной для корпоративных систем, как можно было мечтать об этом.

Далее речь пойдет о предметной области: чем занимается нефтегазовая группа «Итера», какого рода компании она включает, какие существуют основные производственные показатели. Важный аспект рассмотрения – актуальность темы: почему важно внедрять интегрированные корпоративные системы, почему важно обеспечивать консолидацию данных, каким образом на основе этих консолидированных данных осуществляется управление информацией, управление, вообще говоря, и производственными процессами, и какие проблемы сформировались в корпорациях, в том числе в нефтегазовой отрасли.

К специфике нефтегазовой отрасли нужно отнести большое количество пространственных данных – это данные сейсмического анализа земной коры (так называемая сейсмика), которые представляются как в двумерном изображении, так и в трехмерном. Сейчас уже говорят о 4D сейсмике, это динамическое трехмерное представление земной коры, четвертым измерением является время. Если необходимо хранить, обрабатывать и анализировать, использовать большое количество информации именно в этом трех-, четырехмерном виде, то, конечно, не обойтись без средств интеграции корпоративных приложении, которые позволили бы строить консолидированные отчеты, в том числе и на основе этой слабоструктурированной информации. Также будет рассмотрена методология проектирования интегрированных систем корпоративного типа, ключевые элементы этой методологии, модели, инструментальные средства и программные решения на основе прототипирования и быстрой разработки. Там достаточно широко были использованы средства и технологии Microsoft, во многом для изготовления прототипов. Технологии Microsoft позволяют конструировать прототипы при помощи технологий Windows Forms, при помощи большого количества библиотек, которые находятся как на уровне. NET Framework, системном уровне. NET, и библиотек нижнего уровня, более низкого уровня операционной системы Windows, и, конечно, библиотек более высокого уровня, специализированных для производства корпоративных и офисных приложений Visual Studio Tools for Office и Enterprise Library.

Инструментальные средства, прототипы и программные реализации – это те этапы, которые следует пройти при создании корпоративных систем. Будет представлен достаточно новый подход, позволяющий объединять гетерогенные приложения как компоненты информационных систем корпоративного типа, и, более детально, конкретизацию этой методологии, с одной стороны, для корпорации «Итера», а с другой – для интернет-порталов, которые объединяют целый ряд гетерогенных систем. В данном случае используются системы унаследованные, это архив мультимедийных данных, слабоструктурированный, и унаследованная, вообще говоря, портированная с мейнфреймов система учета, планирования и управления людскими ресурсами, которая называется Unic. Это достаточно интересная система: она разработана в ЮАР, достаточно гибкая, т. е. включает большое количество настраиваемых форм ввода информации, которые позволяют гибко адаптироваться к различным процессам ввода информации о новых сотрудниках, сделать как полный цикла ввода, так и вполне экономный краткий цикл и содержит целый ряд предопределенных полей для ввода, степень обязательности которых можно менять. В этом случае используются как традиционные поля, связанные с обращением, скажем, мистер, миссис, доктор, профессор и т. д., так и достаточно редко применяемые поля, как скажем, вероисповедание или расовая принадлежность, которая в последнем случае является обязательным к вводу полем, поскольку система разработана в ЮАР.

Система предполагает достаточно большое количество форм и отчетов для планирования карьеры, тренингов, которые проходит персонал, стажировок и т. д. и вообще по возможностям является достаточно гибкой и всеобъемлющей, универсальной. Эти две системы, Multimedia Archive и система управления персоналом, были объединены в единую среду на портальной основе вместе с целым рядом систем, модулей производства корпорации Oracle, тогда эта система модулей называлась Oracle Applications, изначальная версия была 10.6, потом 11 и т. д., сейчас она называется Oracle Business Suite. Здесь будут показаны результаты внедрения и способы оценки экономической эффективности результатов в корпорации «Итера».

Перейдем к описанию предметной области. Нефтегазовая группа компаний «Итера» – это до недавнего времени крупнейшая, с некоторых пор вторая по величине независимая нефтегазовая компания в России. Она была создана в 1992 г., имеет свыше 150 филиалов, дочерних предприятий и свыше 5000 сотрудников, в пиковой период – до 10 000 сотрудников на территории более чем 20 государств. Работа этой структуры отмечается как достаточно эффективная, поскольку по сравнению с такими крупными госструктурами, как, скажем, Газпром, Роснефть и т. д., она более мобильна, динамична и легче адаптируется к меняющейся среде.

Общий объем поставок газа в Россию, страны СНГ и Балтии составил в совокупности более 400 млрд м3. Это достаточно внушительный объем. И общий объем инвестиций в газодобычу в России превысил 1,5 млрд долл. США.

Основное направление деятельности корпорации – нефтегазовое. Вместе с тем, как и во многих корпорациях, существуют и другие направления, которые тоже приносят прибыль. Они могут быть связаны с основным, могут помогать ему развиваться или балансируют структуру бизнеса. В «Итере» это такие направления, как недвижимость, страхование, лесная промышленность, торговля и др. Как и в любой корпорации, в этой группе компаний на определенный момент, как раз конец 1990-х, существовало достаточно большое количество разрозненных и слабоинтегрированных между собой информационных систем, которые тем не менее обеспечивали основные бизнес-потребности корпорации, в том числе построение консолидированных отчетов. Это одна из достаточно важных задач, поскольку такие отчеты дают возможность руководству следить за ключевыми показателями бизнеса, за их динамикой, причем в различных разрезах, скажем, они могут детализировать эти показатели до страны, до региона, до какого-то конкретного проекта, до подразделения, до компании, может быть даже до конкретного человека, если это необходимо. И очень важно, насколько быстро клиент будет получать эти отчеты, настолько быстро можно не просто построить эти данные, а получить бумажные представления этих отчетов и представить в соответствующие органы справки по нужным формам, поскольку консолидированная отчетность по методике GAAP представляется не только в России, но и международным аудиторам, службам, которые оценивают компании. Оперативная консолидированная отчетность нужна также для того, чтобы планировать и тактику, и стратегию развития бизнеса, обнаруживать узкие места, правильно понимать источники проблем и пытаться их ликвидировать или, по крайней мере, как-то нивелировать, снижать.

Конечно, это очень сложная задача, потому что в любой корпорации, как правило, эксплуатируется большое количество разнородных информационных систем, которые зачастую функционируют в различных архитектурных средах, на различных принципах. Скажем, там могут быть и унаследованные системы, которые работают на мейнфреймах, могут быть файл-серверные и более современные клиент-серверные системы, но с использованием уже достаточно давних и, может быть, не самых эффективных технологий, таких как CORBA, брокеры объектных запросов.

Могут быть специфические решения, как скажем, Remoting, если говорить о Microsoft, потому что подход Remoting с трудом интегрируется с другими подходами. Могут быть интернет-системы. Это один срез, который связан с архитектурными особенностями, о которых уже было сказано. Другой срез связан с данными. В предыдущих главах было рассказано о СУБД, но, преимущественно, о реляционных базах данных. На самом деле существуют новые подходы, новые парадигмы, которые связаны с объектными базами данных и позволяют хранить и обрабатывать информацию в объектах, не в таблицах. Это динамические сущности, с ними работать гораздо сложнее, но, к сожалению, если говорить о таких конгломератах, как международные корпорации, там существует и большое количество аудиовизуальной информации. Если говорить о системе учета, планирования, управления людскими ресурсами, это будут записи интервью с кандидатами на те или иные вакансии.

Хранится большое количество корпоративного видео – летописи, различные события. «Итера» недавно открыла новое Пырейное месторождение и ввела его в эксплуатацию. Существует большой фото– и видеоархив, где присутствуют упоминания и сюжеты о важных событиях в жизни корпорации, отдельных компаний, о юбилеях компании, юбилеях топ-менеджеров и о корпоративных праздниках, связанных с профессиональными праздниками, скажем Днем работника нефтяной и газовой промышленности. Кроме фото и видео существует большое количество отсканированных документов, в которых на самом деле тоже не всегда четко определяются поля, т. е. примерно понятно, какого рода поля там должны быть, но каких-то полей может не хватать, какие-то поля могут быть не заполнены по ряду причин, и в связи с этим информация также получается не совсем строго структурированной или не совсем полной. Это еще одна ось, которую нужно добавить к архитектурам.

Кроме этого, естественно, существует ось технологическая. В компаниях работают системы производства Microsoft, Oracle, других производителей, в частности было упомянуто о системе Unic, которая была внедрена. Поскольку она полностью соответствовала по функциональности тем требованиям, которые выдвигались руководством компании, с одной стороны, нельзя было ее игнорировать, а с другой – нужно было встроить в такой большой и разнообразный спектр систем, который уже эксплуатируется. И очень важным здесь является замечание о критичности приложений, Mission Critical Applications, когда существуют приложения или программные системы в рамках корпоративного программного комплекса, которые нельзя просто так приостановить, перекачать информацию куда-то еще и затем запустить заново, просто потому что в них постоянно заносятся производственные показатели, ведется мониторинг этих показателей и ключевые бизнес-процессы функционируют на основе данных из этих систем. Не говоря уже о том, что существуют автоматизированные системы, которые управляют, скажем, бурением, разведкой месторождений и т. п. Но это немного другой класс систем, и здесь о нем не будет подробного рассказа. Важно, что интегрировать корпоративные системы достаточно сложно, и для того, чтобы это сделать, нужен достаточно универсальный подход. Здесь помогают в том числе и математические модели или подход, который связан с концептуализацией предметной области. Это своего рода формальное описание того, что происходит, это и статика, и динамика, и процессы, и факты, и сущности, которые присутствуют и взаимодействуют в предметной области.

Следующий этап – проектирование архитектур и интерфейсов. Зачастую могут выстраиваться конгломераты из разных архитектур. Это могут быть и системы на основе мейнфреймов, которые сейчас переживают второе рождение в банках. На какое-то время мейнфреймы были забыты. Это, конечно же, клиент-серверные системы, опять-таки можно вспомнить клиент-банковские системы. Это системы, которые связаны с интернет-приложениями и тонкие клиенты которых – веб-браузер. Используются веб-сервисы, тонкие клиенты, причем корпоративные сотрудники могут использовать различные устройства доступа к данным. Это могут быть не только персональные компьютеры, не только сетевые рабочие станции, не только ноутбуки, но и мобильные устройства доступа к данным, которые тоже дают возможность получения информации в оперативном режиме практически из любой точки пространства при условии поддержки спутниковой связи. Естественно, все эти составляющие корпоративных информационных систем должны быть интегрированы в рамках различных архитектур, и поэтому используются как специфические, так и традиционные интерфейсы. И хорошим общим знаменателем, хорошим средством интеграции в этом смысле являются интернет-порталы, которые дают возможность доступа из любой точки к информации с учетом профиля пользователя. В профиль заложены как его личные предпочтения, так и особенности тех инструментальных средств и аппаратного обеспечения, которые он использует, и, конечно, заложен его уровень доступа с точки зрения безопасности. Например, вице-президент по персоналу имеет возможность отслеживать динамику персонала по любой компании корпорации, по корпорации в целом, но его доступ к финансовой информации, наверное, не так велик, как у вице-президента по финансам. С другой стороны, если говорить о линейном менеджере по кадрам, то, вероятно, он не может подняться на такой уровень, чтобы видеть динамику, скажем, текучесть кадров по корпорации и даже по компании, наверное, только по какому-то подразделению и только по своему направлению.

Естественно, следующим этапом является реализация, которая происходит при помощи CASE-средств, средств автоматизированного проектирования, средств разработки программного обеспечения. И существенную роль здесь играют средства быстрого прототипирования, в том числе достаточно эффективно можно использовать Visual Studio.NET. Мы уже говорили о том, что необходимо вести интеграцию программных систем. Если говорить о корпоративных программных комплексах, то интеграция производится на основе портальных технологий. Исходя из описания предметной области и общей задачи построения интегрированной системы с возможностью получения консолидированной отчетности нужно сформулировать основные требования к корпоративной информационной системе, к корпоративному программному комплексу, объединяющему ряд таких систем для нефтегазовой группы «Итера». Это прежде всего индустриальная масштабируемость, т. е. возможность относительно плавного снижения производительности при резком возрастании нагрузки на систему, что вызвано, как правило, возрастанием количества одновременно работающих пользователей или сложности запросов, которые одновременно генерируются этими пользователями. Нужно обеспечивать устойчивую работу, а производительность при этом должна падать плавно. То есть пользователь должен иметь возможность получать результаты в комфортном режиме, без каких-то продолжительных задержек, не говоря уже о критических сбоях, потерях данных и т. д.

Другое важное требование – интеграция элементов, или информационных систем, которые составляют корпоративный программный комплекс. Здесь важно отметить то, что эти элементы принципиально являются гетерогенными, т. е. функционируют в рамках различных архитектур, различных вендоров и различной степени структурированности данных. При этом хорошим для интеграции является компонентный подход, который был описан в главе о компонентном подходе от Microsoft, где было упомянуто, каким образом строить компоненты на основе сборок, что такое контракт, как он описывает сборку, что такое манифест, описание метаданных сборки. Таким образом, осуществляется взаимодействие программных систем, построенных на компонентной основе. Это может быть близким подходом, и имеет смысл ограничиться в рамках решаемой задачи построения корпоративного программного комплекса возможностью получения консолидированной отчетности.

Какие еще требования имеет смысл сформулировать для корпоративной системы? Ну, конечно, это расширяемость. Нужно понимать, что нельзя остановиться, создав какой-то комплекс, поскольку бизнес постоянно выдвигает новые задачи, новые требования не только к оперативности консолидации, но и к каким-то новым отраслям, которые могут возникать. «Итера», например, относительно недавно начала серьезную, масштабную работу на рынке недвижимости, была создана компания «Итера-Инвест-Строй», которая сегодня работает уже не только в России, но и в Туркменистане, Белоруссии и реализует достаточно серьезные масштабные проекты на больших территориях и строит целые микрорайоны городов, бизнес-центры, спортивные объекты, разные объекты другой направленности. То есть постоянно возникают новые бизнес-задачи, к которым нужно либо адаптировать существующую систему, тогда возникают требования адаптируемости, либо обеспечить расширяемость тех компонентов, которые уже построены, и самого комплекса. Если имеется необходимость встроить в этот комплекс новый элемент, новую информационную систему, то нужны определенные принципы, методологии, которые позволят это сделать.

Очень важным требованием является требование надежности, отказоустойчивости, а также обеспечение безопасности кода и данных. Если говорить о госструктуре, то здесь существует понятие государственной тайны, в отношении корпорации речь идет о коммерческой тайне. Само понятие корпоративной тайны многогранно и, по сути, охватывает все бизнес-процессы и соответственно все информационные системы, которые ведут учет, планирование и управление и бизнес-процессами и информацией о корпоративных ресурсах. По сути, все эти системы как раз и хранят информацию о ресурсах, не только нефтегазовых, но и людских, финансовых, материально-технических, об основных средствах, временных – планировании времени сотрудников и ряде других.

Конечно, системы должны быть отказоустойчивыми, они обеспечивают ключевые бизнес-процессы, и в ряде случаев простой или остановка сервера чреваты очень серьезными последствиями для бизнеса, потому что есть процессы, которые нельзя останавливать. Непростая ситуация сложилась с газовым транзитом на Украину. Российской стороне периодически приходится приостанавливать поставки газа, это на самом деле очень тяжелая проблема, которая даже переросла в политическую. И здесь надо понимать, что в ряде сфер есть технологические процессы, которые желательно не допускать, потому что они могут стать необратимыми и очень серьезно повлиять на ключевые показатели бизнеса. Поэтому отказоустойчивость системы, которая обеспечивает управление бизнесом, должна быть достаточно высокой.

Кроме того, должна быть обеспечена безопасность кода. Уже было сказано о подходе Microsoft, связанном с безопасностью, – Security Development Lifecycle, Secure by Design, принципе, когда проектирование само по себе ведется таким образом, чтобы система была достаточно безопасной. Многоуровневая безопасность – это политики безопасности, средства авторизации, аутенфикации, использования электронных средств, таких как eTokien, биометрическая аутенфикация по сетчатке глаза, по отпечаткам пальцев, даже по голосу, целый ряд механизмов обеспечения безопасности на этом уровне. Механизмы, связанные с криптографической защитой, использование стандартных протоколов, таких как Kerberos, использование различных средств шифрования от сторонних криптопровайдеров, которые можно встраивать в системы, делая их еще более надежными, многоуровневая безопасность, когда вход в систему защищен не только паролем, но и, скажем, особенностью доступа в зависимости от роли, особенностью доступа к таблицам, к отдельным столбцам, в ряде случаев – даже к отдельным строкам. То есть некоторые строки отчета могут быть видны только для какой-то конкретной роли, а внутри этой роли – при входе под каким-то конкретным паролем. Таким образом обеспечивается пер-сонализация доступа к данным. Все, наверное знают, как выглядит «мой Яндекс», что, скажем, можно настраивать «Яндекс бар», настраивать те сервисы, которые предоставляют порталы, точно так же можно настраивать и корпоративный портал и видеть там ту информацию, которая необходима для выполнения производственных функций каждому сотруднику, подразделению, более того, видеть ее в наиболее удобном представлении.

Портал должен обеспечивать требования единства входа и управления ресурсами. Это достаточно важно, поскольку количество, большие объемы данных и быстрый их рост приводят к тому, что неизбежно возникают дублирование, противоречие информации, при этом иногда сотрудники намеренно могут искажать информацию или уничтожать ее. В некоторых случаях это происходит непреднамеренно, скажем, в разных информационных системах информация о сотрудниках вводится различным образом. Ее можно ввести, с одной стороны, в системе учета кадров, с другой – в системе учета зарплаты, с третьей – это может быть система электронной почты, но на самом деле это все один и тот же сотрудник, который относится к одному и тому же подразделению. Но как определить, что он действительно один и тот же? Допустим, мы хотим отправить электронное письмо человеку по фамилии Иванов, но таких людей в корпорации может быть достаточно много. И вполне может быть, что мы с этим человеком никогда не встречались лично, так как он работает где-то в филиале. Прежде всего следует убедиться, что это именно тот человек, и мы не отправим ему информацию, которая находится вне рамок его служебных полномочий. А если системы разрозненные и имеют противоречия, может случиться так, что на самом деле мы отправим письмо другому человеку, проконсультировавшись, скажем, с ответственным не за систему электронной почты, а за систему документооборота или систему управления персоналом. Поэтому обеспечение единой точки входа управления ресурсами – очень важное требование. До того как вести внедрение любой системы, нужно провести анализ тех систем, которые функционируют в корпорации. Прежде всего имеет смысл оценить системы класса учета планирования и управления ресурсами – Enterprise Resource Planning Systems (ERP).

На рис. 17.1 представлены некоторые системы с точки зрения магического квадрата Gartner Group. Здесь две оси – прикладная технологичность и инструментальная технологичность. То есть насколько легко настроить информационную систему, поскольку большинство информационных систем корпоративного типа представляет собой некий набор из строительных блоков, которые можно объединить. Кроме того, насколько эта система является технологичной в прикладном плане, т. е. если изменились бизнес-задачи или бизнес-процессы, насколько сложно будет адаптировать систему к этим требованиям.

Рис. 17.1. Классификация корпоративных систем. «Магический» квадрат Gartner Group

Естественно, это срез корпоративных систем на некоторый момент времени. Здесь можно увидеть Axapta, но не увидеть Dynamics, так как это было раньше, до того, как Dinamics появился на рынке, но показано, что Oracle Applications является достаточно хорошим решением именно с точки зрения адаптируемости к изменениям бизнеса. В любом случае это хороший выбор. SAP на тот момент, когда проводился анализ, был слишком дорогим решением. Да, он обеспечивал технологичность, адаптируемость, но это решение в разы превосходило Oracle по стоимости. Сегодня ситуация уже иная, и они близки по стоимости, а по возможностям SAP, наверное, немного опережает Oracle. Представленная ситуация – это исторический слайд примерно десятилетней давности: ситуация была иной, и анализ был проведен именно тогда, т. е. это некоторая ретроспектива. В результате удалось выявить целый ряд преимуществ, которые связаны с подходом Oracle. Что еще важно по сравнению с SAP – это наличие собственной СУБД корпоративного типа, с которой проводится интеграция на уровне внутренних механизмов, и соответственно эффективное взаимодействие. Таким образом, объединяются СУБД, система класса ERP и CASE-средства, среди которых существуют средства Oracle Designer, Oracle Developer (или, на момент, когда шло внедрение, Oracle Developer 2000) и портальные решения Oracle Portal, т. е. все вместе дает возможность построить достаточно мощное корпоративное решение на единой платформе. На сегодня, кстати, в ряде случаев оправдано решение на основе технологий Microsoft.

Важные требования – это индустриальная масштабируемость, высокая отказоустойчивость и безопасность и, конечно, прикладная и инструментальная технологичность, а также наличие специализированных решений для нефтегазового комплекса. В составе Oracle Applications существовали модули, которые назывались Upstream и Downstream и были специально предназначены для учета, планирования и управления процессами производства и распределения нефтегазовых ресурсов. Поэтому Oracle – это достаточно хорошее решение. Далее происходило проектирование информационной инфраструктуры корпоративной системы, корпоративного программного комплекса. Естественно, проект был реализован, причем, что очень важно, решения такого рода, к сожалению, затрагивают не просто бизнес-процессы, но и оргструктуру, т. е., как правило, происходит существенная коррекция оргструктуры. По сути, происходит реструктуризация, какие-то подразделения могут упраздняться, какие-то сливаться, какие-то сменять функции, в общем, процесс достаточно болезненный, внедрение, как правило, осложняется этими фактами.

В дальнейшем с использованием OLAP-средств анализировались различные сценарии внедрения, их результаты и последствия проектирования бизнес-модели. Затем было осуществлено проектирование модели данных при помощи средств быстрого прототипирования и автоматизированного проектирования приложений. И наконец, были реализованы, уже на физическом уровне, базы данных и поддерживающие их информационные системы. При этом использованы, если говорить о платформе Oracle, следующие инструментальные средства.

Здесь надо смотреть примерно сверху вниз, это как раз и будут слои архитектуры или один из возможных взглядов на эти слои. В самом низу находится СУБД Oracle, начиналось все с 8i, 9i и затем 10g. В основе проекта был конструктор модульный, который назывался Oracle Application версии 11. Это ряд модулей, в первую очередь финансового учета, планирования и управления. Это «Основные средства», «Расчеты с поставщиками», «Расчеты с заказчиками» и ряд других модулей OLAP. Средство Oracle Express позволяет анализировать сценарии развития при внедрении той или иной модели, той или иной конфигурации. CASE– и RAD-связка инструментальных средств используется для проектирования и быстрого прототипирования Oracle Designer Developer 2000. На самом верху находился Oracle Portal, который давал возможность персонализированного доступа, причем, что важно, на любой платформе, это могли быть Unix-системы и системы Microsoft, использовалась технология Java сервлеты, вернее сказать, портлеты в случае портала, и достаточно хорошие возможности разграничения доступа, персонализации и поддержки различных профилей доступа пользователей.

Какие цели ставил перед собой проект? Это прежде всего консолидация отчетности, унификация хранения и обработки данных, которые до этого хранились в разных форматах, в разных системах, что-то в Excel, что-то в Access, что-то в Word, в разных филиалах по-разному. Несмотря на то что существовали инструкции, консолидацию приходилось вести вручную. Сейчас этот процесс во многом автоматизирован.

Важной целью для корпоративных пользователей является персонализация доступа к данным и пользовательским интерфейсам, а также глобальная доступность основных показателей. То есть Oracle Portal явился надстройкой, которая дает возможность осуществить как персонализацию доступа, так и глобальную доступность основных показателей. Некоторые из них можно при этом показать на верхнем уровне, на официальном сайте. Другие будут доступны партнерам компании через Extranet, третьи – через Intranet сотрудникам.

Ниже представлена временная диаграмма развития проекта:

• 1997 г. – начало проекта;

• 1998 г. – внедрение основных блоков КИС;

• 2000 г. – синхронизация КИС и бизнес-процессов;

• 2002 г. – проектирование расширений КИС на основе интернет-технологий;

• 2003 г. – веб-сайт и интранет-портал;

• 2004 г. – публикация консолидированных отчетов;

• 2005–2009 гг. – развитие проекта.

В качестве интернет-надстройки использовался Oracle Portal. При этом основным приложением было семейство Oracle Applications версии 11, а в качестве СУБД – Oracle (версии 8–10).

Подводя итоги, следует сказать о результатах, которые удалось получить при реализации корпоративного программного комплекса в нефтегазовой группе «Итера». Во-первых, накоплен позитивный опыт совместного использования целого ряда программного обеспечения. От Oracle это СУБД Oracle, ERP Oracle Applications, OLAP-система Oracle Express, Oracle Forms, Oracle Reports, CASE-средства Oracle Designer, Oracle Developer 2000, Oracle Portal и др. Решен ряд задач оперативного и аналитического финансового учета. Построен информационный интранет-сервер на основе технологии Oracle. В целом все эти задачи были успешно решены, было решено расширять направление Интернет-интранет-сервисов и подключать новые системы на этой основе. Был сделан вывод о том, что интернет-расширения будут способствовать сохранению инвестиций и снижению совокупной стоимости внедрения.

В отношении реализации такого рода систем, в том числе в нефтегазовой группе «Итера», видятся следующие перспективы. Это развитие интранет-портала, создание экстранет с возможностью подключения партнеров и получения дополнительной, расширенной информации о компании. Поддержка в перспективе выхода на фондовый рынок, первичное размещение акций IPO и реализация электронной площадки для газовых торгов, т. е. реализация полномасштабного B2B-приложения.

Продолжим обсуждение корпоративных систем, корпоративных приложений для нефтегазового комплекса и рассмотрим возможности построения интегрированных комплексов таких систем на основе архитектуры и технологии, связанной с использованием интернет-порталов. В нефтегазовой сфере присутствуют значительные объемы гетерогенных, слабоструктурированных данных. Лучше даже сказать, данных различной степени структурированности. Уже было упомянуто о данных сейсмических исследований – это большие объемы и анализировать эти данные достаточно сложно. Естественно, информационные технологии проникают во все сферы жизни и бизнес-деятельности корпорации. Какой бы деятельностью ни занималась компания в корпорации, она должна по стандартной форме отчитываться о своей деятельности, и руководству корпорации нужно понимать, на каких направлениях сосредоточивать усилия, финансы, другие активности, пиар, маркетинг и т. д. Кроме того, нужно строить консолидированные отчеты, но при этом те методики, модели, инструментальные средства, технологии, архитектурные платформы, на которых построены составляющие программный комплекс информационные системы, неоднородны. И если говорить о всем жизненном цикле, понимая это как изменение и поддержку систем от их концепции до реализации, внедрения, сопровождения, то проблема унификации, построения какой-то общей методологии, общего подхода к тому, что бы такие комплексы создавать и расширять, развивать, еще не решена.

Применяемые методологии во многом не адекватны различным стандартам. Существует большое количество разных протоколов взаимодействия, разных стандартов хранения данных, взаимодействия между этими данными, вспомним язык IDL, на котором описываются интерфейсы CORBA-систем. Есть более стандартизованные подходы, но они либо не всеми приняты, либо приняты в разной мере, скажем, подходы к сервис-ориентированной архитектуре, подходы к проектированию интерфейсов для баз данных, стандарт ANSI SQL, к сожалению, многими производителями СУБД воспринимается по-разному и нельзя еще говорить о том, что он в полной мере реализован.

И языки, в том числе языки запросов, например SQL, не вполне однородны и стандартизованы. Интерфейс между пользователями и информационными системами не совсем сбалансирован, потому что присутствуют различные архитектурные подходы, кто-то работает с мейнфреймами, кто-то – с тонкими клиентами, и достаточно сложно построить обобщенный подход. В связи с этим предлагается комплексная концепция разработки интегрированных систем, которые включают такие элементы, как: система математических моделей для представления и манипулирования объектами в предметной области и среды вычислений; концептуальная модель предметной области и абстрактная машина для управления контентом; математические модели – без этой формальной основы очень трудно построить унифицированную платформу, на которой можно надстроить уже и инструментальные средства, и средства интеграции, специфические и те портальные средства, которые будут осуществлять консолидированное управление корпоративным контентом, т. е. теми гетерогенными данными и метаданными разной степени структурированности, которые функционируют в корпорации.

Естественно, этот комплексный подход включает и методологию, которая поддерживает как проектирование, так и реализацию и сопровождение, т. е. весь жизненный цикл информационных систем. И модели, и методологии были бы полны, они бы висели в воздухе, если бы не были поддержаны инструментальными средствами уровня CASE и быстрой разработки, быстрого прототипирования. В данном случае это средство ConceptModeller и информационная система управления контентом, которая осуществляет соответственно интеграцию разнородных данных с получением концентрированного, консолидированного хранилища корпоративной информации на основе объектного подхода и возможности управления контентом этого хранилища на основе информационной системы управления контентом.

Таким образом, целью работы по построению интегрированного подхода к созданию такого гетерогенного программного модуля корпоративного типа являются исследование, обоснование и разработка методологии для построения крупномасштабных корпоративных информационных систем, предназначенных для сбора, анализа и генерации отчетно-статистической информации, которая практически апробирована построением быстрых прототипов, полномасштабных реализаций на основе интернет-порталов. Данная цель детализируется следующими задачами. Это: 1) разработка методологий, т. е. общего подхода, концептуальной схемы, методов и поддерживающей их математической модели для построения такого рода систем; 2) создание инструментальных средств, поддерживающих эти модели (чтобы не быть голословным и не говорить о проектировании только на уровне математики, только на уровне тех моделей объектов, которые используются); 3) практическая апробация построения быстрых прототипов и 4) полномасштабная реализация. При этом используются теоретические основания, прежде всего теория конечных последовательностей в форме λ-исчисления.

Итак, теория конечных последовательностей в форме лямбда-исчисления, теория категорий, теория переменных доменов и семантических сетей. Какие практические задачи возникают при этом? Это, конечно, создание единого информационного пространства с тем, чтобы каждый сотрудник корпорации из каждой точки земного шара мог получить доступ к тем данным, которые нужны ему для выполнения производственных функций в любой момент времени и с использованием различных устройств доступа. Должна быть осуществлена унификация доступа, сбор и анализ данных для построения консолидированных отчетов, генерация этих самых отчетов, естественно, на том уровне доступа, который имеет каждый сотрудник, и интеграция гетерогенных корпоративных информационных систем, составляющих программные комплексы. Кроме того, должны быть созданы инструментальные средства, которые поддерживают работу в этом пространстве. Системы управления контентом и средства интеграции данных – это те самые Concept-Modeller и информационная система для управления контентом. Должна быть спроектирована архитектура на основе портальных систем, интернет-порталов и, естественно, эта методология, этот подход должны быть апробированы с построением как быстрых прототипов, так и полномасштабных реализаций. В итоге получается корпоративная культура нового сетевого типа, т. е. в определенном смысле происходит виртуализация ресурсов и доступ к ним посредством единообразного интерфейса из любой точки земного шара в любое время, глобальная доступность. По сути, получается виртуальное рабочее место для каждого сотрудника, которому нужно получить доступ, вообще говоря, в достаточно разных условиях. Если говорить о нефтегазовой компании – это могут быть полевые условия. Люди, которые занимаются геологоразведкой, могут передавать данные, обобщать их, анализировать и смотреть перспективы продолжения разведки в том или ином регионе, в том или ином конкретном месте. Это может быть возможность получения консолидированных отчетов или отчетов на своем уровне для каждого типа, для каждой роли в корпорации, для каждой позиции, для сотрудников, которым нужны кадровые либо финансовые данные, и для топ-менеджеров, которые могут получить своего рода dashboard – приборную панель, на которой они могут видеть основные показатели развития корпорации и управлять ими, иметь обратную связь.

Общая схема методологии (рис. 17.2) включает шесть этапов, которые представлены шестью секторами на схеме. Это, начиная с 12 часов, сектор «предметная область», которая представлена на естественном языке, ее формализация в виде концептуальной модели, поддержка CASE-средств первого и второго уровня: первый уровень – это специфика рассматриваемого подхода, которая дает возможность объединить формальную математическую модель с традиционными CASE-средствами, второй уровень – это традиционное, привычное нам CASE-средство, и, наконец, стандартное построение быстрых прототипов в полномасштабной реализации в форме схемы баз данных и информационных систем при помощи CASE-средств. Каждый этап детализируется рядом уровней – это объекты, связи, события в среде и примеры средств управления этими объектами как на уровне модели, так и на уровне реализации в виде инструментальных средств и компонентов программных систем. Уровни поэтапно детализируются от периферии к центру.

Рис. 17.2. Схема методологии построения КИС в нефтегазовом секторе

Какие новые результаты были получены в связи с применением такого подхода? Это прежде всего методологии, которые поддерживают непрерывное предметно-ориентированное итеративное проектирование индустриальных интернет-систем на всем протяжении жизненного цикла. Непрерывное, потому что нет разрыва между моделью и реализацией. Прочие подходы либо имеют этот разрыв, либо, если они хорошо поддержаны моделями, скажем, на основе онтологий, семантических сетей, возможно, на другой основе, например теории категорий, не приводят к решениям с практически приемлемыми эксплуатационными характеристиками – масштабируемостью, отказоустойчивостью и т. д.

В работе удалось развить комплекс моделей данных как для предметной области, так и для среды вычислений. По сути, на основе двукратной концептуализации, или свертки, и на основе теорий переменных доменов. При этом модель для среды вычислений опирается на абстрактную машину для управления контентом, модель для предметной области, представление предметной области – на семантические сети. Этот комплекс моделей лучше, чем традиционные модели, на основе ER-диаграмм и т. д., UML-диаграмм в частности, учитывают особенности гетерогенных, слабоструктурированных сред. Эти модели в основном транслируются в UML-диаграммы, но имеют более прозрачную математическую семантику и более корректно транслируются в термины тех теорий, о которых мы упоминали: λ-исчисление, комбинаторная логика, теория категорий и теория переменных доменов и семантических сетей с визуализацией на основе фреймов.

В целом можно выделить следующие преимущества разработанных моделей и методологий. Прежде всего, с точки зрения моделей реализуется событийно-ориентированное управление гетерогенными высокодинамичными хранилищами объектов данных и метаданных, т. е. корпоративным контентом, который является, как мы уже говорили, гетерогенным и включает элементы с различной степенью структурированности. Поддерживаются разнородные архитектуры, т. е. гетерогенные архитектуры, как у унаследованных систем, так и у современных интернет-систем или систем клиент-серверного типа. В результате реализации внедрение ускоряется по срокам и улучшается по стоимости примерно на 30–40 %, естественно, если мы говорим о гетерогенных системах, которые объединяют различные поколения информационных систем, различную степень структурированности информации. В моновендорном решении от Oracle такой подход кроме утяжеления и дополнительных затрат ничего не даст. Но если говорить о действительно гетерогенной системе, то в итоге облегчается модернизация, адаптация, расширение, развитие информационной системы, возможен реинжиниринг, т. е. обратное проектирование от CASE-схемы данных информационных систем до уровня модели, и верификация на математически строгом языке. Мы можем доказывать корректность и соответствие спецификации программной системы просто математическим языком так же, как происходит доказательство теорем.

После рассмотрения всех возможных входов доказывается корректность выходов для тех функций, о которых пойдет речь на математическом уровне, в терминах, скажем, λ-исчислений или комбинаторной логики. Проектирование ведется в терминах предметной области, при этом бизнес-аналитики используют те термины, которые семантически близки, и, можно сказать, что они работают практически на естественном языке. Осуществляется интеграция с современными стандартами, XML и UML в частности. Методология дает возможность обеспечить ассоциативность, наглядность и интуитивную ясность проектирования.

Своеобразие этого подхода и полученных результатов состоит в следующем. Реализуется, как мы уже говорили, событийно-ориентированное управление гетерогенным, высокодинамичным хранилищем. Поддерживаются разнородные архитектуры, в том числе и унаследованные. Обе модели данных поддержаны инструментальными средствами как для представления интеграции данных, так и для манипулирования ими для управления контентом. В последнем случае используется оригинальная модель в форме абстрактной машины на состояние. Практическая значимость сводится к тому, что при корректном применении методологии для гетерогенных комплексов программных систем обеспечивается существенное ускорение и упорядочивание внедрения реализаций, которое в терминах совокупной стоимости владения и возврата на инвестиции обеспечивает по сравнению с существующими коммерческими аналогами преимущества порядка 30–40 %. Кроме того, обеспечиваются облегчение, расширение, модернизация, адаптация, оптимизация производительности информационных систем.

Кратко расскажем о тех вычислительных моделях, которые лежат в основе этой методологии. Прежде всего, каждый объект данных представляет собой тройку с последовательной конкретизацией по схеме класс – объект – значение. Под классом понимается совокупность объектов в интегрированной предметной области, объект – это частичная конкретизация с означиванием ряда метаданных до шаблона информационной системы управления контентом, значение – это полное означивание до веб-страницы, до страницы портала, которая автоматически генерируется в информационной системе управления контентом на основе того или иного шаблона. При этом обеспечиваются следующие преимущества: во-первых преемственность с традиционным подходом к объектно-ориентированному анализу и проектированию OOAD (Object Oriented Analysis and Design), во-вторых, известные ранее модели данных на основе концептуального проектирования, на основе переменных доменов, на основе теории категорий и других подходов обобщаются на случай интернет-порталов, интернет-среды. Возможно непрерывное, от модели до реализации, итеративное, с последовательным улучшением проектирование расширяемых и интероперабельных информационных систем, т. е. компонентно-взаимодействующих систем, которые могут изменяться и наращиваться на основе ряда стандартов и подходов, таких как CORBA, в частности. Поддерживается обработка данных с явным разделением на frontend и backend, т. е., по сути, пользовательский интерфейс и системный с применением событийно управляемых процедур и вычислительных систем на основе динамического SQL.

Концептуальная схема построения модели данных может быть проиллюстрирована примером (рис. 17.3), который показывает двухкратную свертку, класс UML, который описывает объект данных, фотоизображение конкретизируется при первом соотнесении а1 до слота в шаблоне, при этом означиваются такие параметры, как линейные размеры по вертикали/горизонтали и глубина цвета. Финальная конкретизация дает для данного объекта значение в форме фотоизображения, а для страницы в целом выдает веб-страницу, в данном случае биографию руководителя группы компаний «Итера» Игоря Викторовича Макарова.

Рис. 17.3. Концептуальная схем построения модели данных

Кратко остановимся на характеристике и методологии проектирования. Понятие предметной области трансформируется в сущности формальной (математической) модели на фреймах в графической интерпретации и затем переводится в схему объектно-реляционной базы данных и базы метаданных, по сути, хранилища контента, с абстрактной машиной, которая предусмотрена для манипулирования этим контентом. Разработан семантически ориентированный алгоритм, который осуществляет интеграцию новых компонентов в состав уже разработанных программных комплексов и поддерживает реинжиниринг, т. е. обратное проектирование от схемы информационных баз данных до уровня модели. В основе концептуальной модели лежит двухуровневая свертка, или концептуализация, т. е. абстракция в обратную сторону, речь идет о конкретизации с формализацией динамики индивидов на базе соотнесений. При этом семантика формализуется многосортными типизированными термами лямбда-исчисления категориальной комбинаторной логики, а также средствами ситуативного описания на основе семантических сетей и абстрактных машин на состояниях, близких к категориальной абстрактной машине. Поддерживается предметно-ориентированное проектирование программного обеспечения на всем жизненном цикле нашей программной системы, нашего корпоративного программного комплекса, который объединяет ряд информационных программных систем.

Рассмотрим более подробно схему реализации инструментального средства ConceptModeller, которое поддерживает интеграцию различных информационных систем, входящих в состав корпоративного программного комплекса, и обеспечивает двунаправленное предметно-ориентированное проектирование с возможностью трансляции бизнес-ситуации на фреймах в UML-диаграммы и в термины традиционных CASE-средств. Поддерживаются форматы IBM Rational, Oracle Developer и Microsoft Visual Studio. Нужно заметить, что двунаправленный характер стрелок свидетельствует о возможности применения этого средства, естественно, с ручной работой и в обратном направлении, которое дает нам возможность получить из UML-диаграмм модельное представление предметной области. Поддерживается визуально-ориентированное проектирование.

Итак, средство визуального предметно-ориентированного проектирования информационных систем ConceptModeller имеет следующую краткую характеристику: язык разработки – C#, некоторые элементы логики были реализованы на языке XML. При этом, наверное, было бы целесообразно говорить о замене этого языка или об обновлении его до F#. Естественно, реализация произведена на базе операционной системы Windows, среда реализации – Visual Studio.NET, объем кода исследовательского прототипа составляет порядка 4500 строк, срок реализации – примерно один год, количество сотрудников, занятых в проекте, – 4. На рис. 17.4 обведены линией те этапы проектирования, которые реализует ConceptModeller.

Рис. 17.4. Двунаправленная схема CASE-проектирования в ConceptModeller

Точно так же на общей схеме (см. рис. 17.2) из шести этапов и шести уровней выделенным волнистой линией сектором обозначена сфера применения этого средства, которое позволяет нам сделать замкнутой всю схему проектирования корпоративных программных комплексов. Исследовательский прототип ConceptModeller (рис. 17.5) позволяет перейти от скриншота слева к скриншоту справа, т. е. от ситуативных описаний на базе фреймов. Здесь представлен ситуативный фрейм, который описывает поставку кандидатов на вакансии рекрутерами работодателю. Этот фрейм можно трансформировать в UML-диаграмму класса, обеспечивая при этом следующие преимущества. Во-первых, это адекватность разработанной математической модели предметной области на семантических сетях, поскольку фреймы прозрачно транслируются в предиктаты и лямбда-термы. Во-вторых, ориентированность на предметную область – пользователь оперирует понятиями естественного языка. В данном случае это recruiter, employer, manager и т. д. В-третьих, наглядность, поскольку используется средство визуального проектирования: пользователь не пишет текст, а работает с графическими примитивами, как и положено в CASE-средстве с визуальным интерфейсом, поддерживает современные стандарты проектирования, в частности UML, и реализованы интерфейсы с индустриально апробированными CASE-средствами, такими как IBM Rational, Microsoft Visual Studio, Oracle Developer. Поддерживается двунаправленный характер проектирования корпоративных систем, как мы видели на схеме работы ConceptModeller. Возможно проектирование как в сторону от модели к реализации, так и в обратную сторону. Обратный процесс, конечно же, требует ручной работы и определенной коррекции, если говорить о программной системе, которая была реализована на вне данной методологии на основе UML-диаграмм.

Рис. 17.5. Исследовательский прототип ConceptModeller

Другим инструментальным средством, которое поддерживает модель управления объектами данных и метаданных корпоративных систем, управления контентом, является информационная система для управления контентом сетевых ресурсов корпоративных систем. Она реализована в портируемом варианте и может работать под управлением как операционной системы Windows, так и операционной системы Unix, на языках Java и Perl, с возможностью использования СУБД MySQL и Oracle в более серьезном варианте и MySQL – в более легком варианте. Объем кода порядка 5000 строк, срок реализации – один год, количество сотрудников, занятых в проекте, – 5.

Переходя к деталям реализации, рассмотрим интерфейс предметно-ориентированного инструментального средства управления контентом корпоративных информационных систем. Здесь мы видим возможности интерфейса с разграничением на frontend и backend. Срез для пользователей корпоративного сайта представлен справа, некий временной срез страницы, которая динамически формируется на основе шаблонов и персональных предпочтений пользователя, а также устройств доступа к данным, естественно, при доступе с мобильного устройства, интерфейс будет выглядеть иначе.

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

Рис. 17.6. Примеры интерфейсов управления системой

Какие преимущества предоставляет система управления контентом? Это прежде всего веб-интерфейс, проектирование ведется из Internet Explorer, из стандартного клиента и при этом используется стандартное средство DHTML Editor, которое поддерживает динамические объекты стандартных интерфейсов. На самом деле управлять контентом можно практически из произвольной точки земного шара в произвольный момент времени. Это достаточно важно, потому как позволяет разгрузить основных администраторов и дать возможность пользователям наполнять контентом хранилища данных в той мере, в которой у них есть на это права и возможности.

Кроме того, обеспечивается улучшенная по сравнению с аналогами обработка сложных гетерогенных объектов данных и метаданных, есть возможность внедрения элементов офисных приложений в результирующий контент на сайте. Используется средство визуального проектирования, поэтому пользователей не нужно долго учить работе с системой, интерфейс достаточно прозрачен. Применяются расширенные генераторы форм отчетов, при этом возможна реализация различных каналов взаимодействия, ряд систем обслуживается в строгом терминальном режиме с жестким доступом.

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

Детализация обобщенной концепции и архитектурной схемы проектирования корпоративных программных комплексов для интернет-среды в связи с внедрением в группе компаний «Итера» по направлению интернет-порталов велась следующим образом. Во-первых, была разработана обобщенная схема обработки гетерогенных хранилищ уже существующих в корпорации данных и метаданных, т. е. контента на основе скриптов соотнесений, по сути, фрагментов кода, которые управляют событиями и динамически настраиваются в связи с особенностями персонализации и профилей пользователей. Практическая значимость реализации определяется развитыми методами, моделями и инструментальными средствами. На основе построенного архитектурно-интерфейсного решения портального типа спроектированы быстрый прототип и выполнена реализация ряда систем, включая информационную систему учета и планирования управления человеческими ресурсами и портал, управляющий информационными ресурсами корпорации. Это позволило осуществить ускоренное внедрение и существенно снизить затраты на сопровождение и развитие программного обеспечения.

При этом в международной группе компаний «Итера», включающей около 10 000 человек в 150 компаниях 24 стран мира, были реализованы: корпоративная информационная система учета людских ресурсов UniQue, которая внедрена в среду уже существующих финансовых модулей Oracle Applications, о них говорилось немного ранее; информационная система для управления контентом, по сути, CASE-средство, официальный интернет-сайт и внутренний интранет-портал для получения доступа к корпоративным ресурсам в соответствии с персонализацией для сотрудников корпорации. Общая архитектурная схема построенного решения для корпорации «Итера» представлена на рис. 17.7.

Рис. 17.7. Общая архитектурная схема КИС для компании «Итера»

Подход позволил объединить ряд модулей, предназначенных для учета, планирования и управления, прежде всего финансовыми ресурсами. На рис. 17.7 это обозначено ERP-ИС. Речь идет о модулях Oracle Applications: Fixed Assets, Accounts Payable, Accounts Receivable – расчеты с поставщиками, расчеты с заказчиками и основные средства, а также информационная система документооборота на основе Oracle Interoffice и слабоструктурированного мультимедиа архива, который представляет собой не просто базу данных, а хранилище данных с такими объектами, как аудио– и видеоинформация. На основе методологии удалось построить портальную надстройку, которая обеспечивает доступ к данным как из корпоративной локально-вычислительной сети, так и для внешних пользователей с различных устройств доступа, включая мобильные телефоны, смартфоны или коммуникаторы и другие устройства. Это позволило сделать информационное управление контентом.

Другое средство, инструментальное, которое называется ConceptModeller, позволило построить единое хранилище контента на основе этих гетерогенных баз и хранилищ данных. Логическая структура информационной системы для управления контентом представлена на рис. 17.8. Здесь важно отметить, что на данной диаграмме, показывающей потоки данных между компонентами системы, ведется управление как информацией, так и метаинформацией, что представлено такими модулями, как «Управление конфигурацией» и «Администрирование». Достаточно большое количество параметров показано только как основные потоки данных.

Программный комплекс, реализованный для группы компаний «Итера», включает следующие компоненты. Это показанные большими прямоугольниками модули Oracle Applications: Fixed Assets, Accounts Payable, Accounts Receivable, а также информационная система для документооборота, информационная система для расчета заработной платы, которую удалось интегрировать с модулями унаследованной информационной системы, предназначенной для учета, планирования и управления персоналом корпорации. Основные потоки взаимодействия на уровне данных между модулями этих систем показаны на рис. 17.9.

Рис. 17.8. Структура информационной системы для управления контентом

Обобщенный и комплексный подход к проектированию корпоративных программных комплексов, состоящих из гетерогенных программных систем, который включает как достаточно унифицированное математическое обобщение, так и специализированные средства нижнего уровня CASE, позволяющие обеспечить сопряжение между математическими моделями и традиционными CASE-средствами, дал возможность обеспечить целый ряд преимуществ, которые показаны плюсами с восклицательными знаками перед существующими программными решениями для построения корпоративных порталов от ведущих поставщиков этого класса программного обеспечения программных систем (рис. 17.10). Кроме того, реализован целый ряд функциональных преимуществ по сравнению с ведущими коммерческими аналогами в части, касающейся прежде всего построения интегрированных отчетов на основе гетерогенных информационных систем, включающих унаследованные компоненты, а также внедрения в контент сложных объектов данных и метаданных.

Рис. 17.9. Основные потоки взаимодействия систем. Уровень данных

На рис. 17.11 представлена методика расчета TCO (Total Cost of Ownership) – совокупной стоимостью владения программной системой, которая включает четыре уровня показателей, здесь речь идет об интегральной оценке по двум методикам – Gartner Group и Radicati Group, и в итоге открывается возможность оценки систем в пересчете на одного пользователя, т. е. произведено определенное нормирование, которое дает возможность сравнить эффективность внедрения как для достаточно больших, так и для относительно небольших корпораций.

В итоге можно сделать вывод о значительном преимуществе по данному показателю в сравнении с корпоративными портальными системами от ведущих производителей, естественно, при реализации гетерогенного программного комплекса (рис. 17.12). Если говорить о моновендорном комплексе на основе, предположим, Microsoft Dynamics или Oracle Business Suite, нельзя достигнуть существенной эффективности, наоборот, будут потери при использовании этой методики. Если же корпоративный программный комплекс является гетерогенным как с точки зрения поставщиков компонентов, так и с точки зрения архитектуры, используются унаследованные приложения, современные приложения и с точки зрения степени структурированности данных, как слабо-, так и хорошо структурированные, скажем реляционные таблицы, выигрыш по стоимости владения достигает 30–40 %.

Рис. 17.10. Преимущества комплексного подхода к проектированию корпоративных программных систем

Методика расчета возврата на единицу вложенных средств (ROI) представлена на рис. 17.13. Здесь также агрегируется четыре уровня показателей, используется большое количество показателей. И в результате приходим к единственной цели, которая выдает возврат инвестиций. В сравнении с эффективностью, показанной на рис. 17.14, получается приблизительно такая же цифра, порядка 30–40 % экономии, если говорить о сравнении продукции ведущих производителей корпоративных систем с разработанным нами гетерогенным решением (по архитектуре и по степени структурированности данных).

Рис. 17.11. Методика расчета TCO

То же можно сказать и о рис. 17.15, где представлены результаты сравнения внедрения с теми же системами по функциональности и по компонентам, которые были бы реализованы на основе других подходов. Здесь рассматриваются оптимистический и пессимистический сценарии. В целом видно, что реализация в среднем также дает экономию по срокам внедрения порядка 30–40 %.

Подводя краткий итог внедрения портальных комплексов в нефтегазовой группе компаний, в нефтегазовом секторе и в смежных отраслях, таких как недвижимость, страхование, лесная промышленность, можно сделать следующие выводы. Отчасти удалось создать единую информационную инфраструктуру, единое информационное пространство при помощи реализации портала для нефтегазовой группы «Итера». В целом удалось достичь достаточно эффективного сбора и анализа данных при помощи OLAP-средств, а также генерации консолидированных отчетов. При этом пользователи во многом работают в терминах корпоративных приложений, офисных приложений, так же как и при использовании библиотек Enterprise Library и библиотек Visual Studio Tools for Microsoft Office. В достаточно полной степени осуществлена возможность интеграции гетерогенных информационных систем в корпоративные программные комплексы, в частности осуществлена интеграция стандартных систем, стандартных модулей семейства Oracle Applications с унаследованной системой учета планирования и управления людскими ресурсами. Отчасти удалось обеспечить унификацию доступа к данным, поскольку до сих пор не все проблемы решены в связи с жесткими ограничениями корпоративной безопасности, которые существуют.

Рис. 17.12. Диаграмма эффективности корпоративных портальных комплексов на основе TCO

Удалось создать ряд инструментальных средств и исследовательских прототипов этих средств, которые поддерживают проектирование корпоративных программных комплексов на основе интернет-порталов. Это средство управления контентом, т. е. гетерогенными данными и метаданными корпоративных систем для управления контентом, а также средства, предметно-ориентированные для визуализированной интеграции данных и метаданных корпоративного хранилища данных, средства ConceptModeller на семантических сетях.

Рис. 17.13. Методика расчета возврата на единицу вложенных средств (ROI)

Рис. 17.14. Диаграмма эффективности корпоративных портальных комплексов на основе ROI

Рис. 17.15. Усредненные сроки внедрения портального комплекса

Еще одной важной задачей было проектирование архитектуры программного комплекса с надстройкой в форме интернет-портала, который позволяет обеспечить единую точку входа, гибкое разграничение доступа к данным и надежное взаимодействие пользователей с достаточно эргономичным и интуитивно ясным интерфейсом в форме веб-браузера. Процедура апробации включила быстрое прототипирование и полномасштабную реализацию. В целом удалось обеспечить более высокий уровень сетецентричной (net-centered) корпоративной культуры нового типа.

Кроме того, был достигнут ряд, можно сказать, попутных результатов. Во-первых, те частные информационные ресурсы, которые были реализованы в рамках отдельных компаний или подразделений, удалось упорядочить и, снизив степень дублирования и противоречий, агрегировать с построением консолидированного программного комплекса семейства этих информационных систем. Удалось существенно повысить рейтинг тех подразделений, которые вносят вклад в создание корпоративной информации, ну и отчасти, тех подразделений, которые отвечают за информационные технологии. Удалось сплотить коллектив, поскольку создание интранет-портала выявило неформальных лидеров, которые создают контент, полезную для корпорации информацию и обмениваются этой информацией. Фактически попутным результатом явилось построение мини-социальной сети корпоративного типа, в которой ведется в том числе неформальное общение в свободное от основной работы время. Попутно удалось повысить квалификацию сотрудников. Нужно сказать, что нефтегазовый комплекс не является тесно интегрированным с информационными технологиями, в ряде случаев есть сотрудники, которые в силу возрастных причин, специфики образования не имеют стабильных навыков создания, редактирования контента и т. д., эффективного, регулярного сетевого взаимодействия; удалось существенно повысить квалификацию сотрудников и в этом направлении.

Была внедрена система безопасности качественно нового уровня. Здесь специфика корпоративной информации не позволяет вдаваться в детали, но нужно сказать, что был реализован многоуровневый механизм доступа к критическим данным с использованием целого ряда механизмов идентификации и аутенфикации пользователей, в том числе на основе биометрической информации.

Удалось устранить целый ряд узких мест из бизнес-процессов корпорации, дублирование, противоречия задач, подразделений, приложений. Удалось унифицировать скелет, или архитектуру IT-инфраструктуры, которая используется в корпорации, удалось существенно упорядочить, ускорить процедуры планирования и сформировать критерии, которые позволили более грамотно, правильно спланировать бюджет на информационные технологии.

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

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

Удалось обеспечить некоторую степень гетерогенности данных, но, естественно, высокая степень гетерогенности данных не позволила провести полномасштабную интеграцию, и, к сожалению, в ряде случаев до сих пор необходим ручной анализ, фрагментация и полуавтоматическая конвертация данных, если говорить о фото-, видеоинформации и отсканированных документах. Естественно, в полностью автоматическом режиме сделать это невозможно. Различные версии офисного и корпоративного программного обеспечения, которые существуют в разных корпорациях, также внесли определенные сложности в проект. Естественно, потребовалось унифицировать обязанности и регламенты на уровне подразделений, компаний и корпорации в целом, что тоже было непросто и не до конца решено.

Конечно, рабочие функции в компании группы дублировались, и возникали противоречия в обязанностях и определенные сложности, связанные с бизнес-процессами. Конечно, ряд бизнес-критичных корпоративных приложений, на которых основаны бизнес-процессы корпорации и которые были упомянуты в этой главе, внесли дополнительные сложности, поскольку новая методология требует освоения новых инструментальных средств и подходов, в частности информационной системой управления контентом ConceptModeller. При этом ими нужно было овладевать в сжатые сроки, несмотря на достаточно удобный интерфейс, конечно, это повлекло дополнительные затраты и принесло дополнительные сложности. В ряде подразделений и для ряда сотрудников оказалось сложным сходу соответствовать новым требованиям, критериям корпоративной культуры сетевого типа.

Какие все-таки позитивные итоги можно отметить по результатам внедрения этой методологии? Это существенное сокращение сроков и стоимости внедрения, если говорить о гетерогенных системах (30–40 %). Существенное расширение функциональных возможностей и актуальность, оригинальность и перспективность, продуктивность подхода, который объединяет модели, инструментальные средства и программную реализацию.

Результат исследования, а доклады обсуждались на целом ряде международных конференций, в том числе под эгидой ACM, IEEE, Microsoft в ряде стран, в России, США, Европе, опубликован целый ряд печатных работ, в том числе по ваковскому перечню, ряд монографий. И реализован ряд грантов, которые поддерживали исследовательскую сторону реализации, прежде всего это и Microsoft Research, и Российский фонд фундаментальных исследований. Реализован целый ряд учебных курсов не только в МИФИ и ИНТУИТ, но также в Softline, Текама, Ланит, МГУПИ, ФизТех, Высшей школе экономики, Казанском государственном технологическом университете им. Туполева и в целом ряде других организаций. Поставлено на поток интернет-обучение с элементами этих методологий, и сегодня количество слушателей измеряется уже тысячами.

Целый ряд проектов находится в стадии внедрения, это интернет-портал Минпромэнерго РФ (minprom.gov.ru), интернет-портал ИПУ РАН (ipu.ru), интернет-сайт международного экологического проекта «Полет надежды», интернет-сайт Ассоциации Ашихаракарате РФ, интернет-сайт Видновского благочиния РПЦ. Там используются элементы этой методологии.

Что касается компании «Итера», то на рис. 17.16 представлен скриншот официального сайта, который построен на основе этих технологий, и внутрикорпоративного портала. Также на этом рисунке представлен скриншот корпоративной газеты, общедоступный срез портала.

Рис. 17.16. Портал компании «Итера»

На этом следует подвести итог рассказа о корпоративных программных комплексах в нефтегазовой сфере. Были рассмотрены основы построения комплексов на базе продуктов и технологий Oracle, Oracle Applications, Oracle Database, Oracle Express OLAP-система, Oracle Portal, CASE-средств Oracle Designer и Oracle Developer и расширений этой методики на случай гетерогенных программных комплексов, которая позволяет интегрировать системы на базе различных архитектурных подходов, различных производителей и различной степени структурированности данных. В итоге вследствие унификации моделей, разработки поддерживающих их инструментальных средств, удается обеспечить для действительно гетерогенных систем существенную экономию по срокам и стоимости внедрения.

Глава 18 Разработка корпоративных решений на платформе Microsoft Dynamics (AX/NAV/CRM)

В каждой компании существуют контуры управления основными процессами и ресурсами, финансовые ресурсы, проекты, управление отношениями с клиентами, управление персоналом, а также другие виды производственных ресурсов, процесс дистрибуции, распределение продукции, процесс производства, такая важная вещь, как бизнес-анализ. Ранее говорилось о бизнес-анализе в связи с системами управления базами данных, прежде всего MSQL Server. Выясняется, что семейство систем Microsoft Dynamics интегрировано с SQL Server, и можно извлечь ряд преимуществ для бизнес-анализа ключевых показателей извлечения данных и построения консолидированных отчетов на их основе.

Далее будут рассмотрены преимущества, которые обусловлены прежде всего высокой степенью интеграции с технологиями продуктов Microsoft, это и корпоративные порталы, и средства семейства Microsoft Office – Excel, Outlook, Word и др., которые дают возможность построения консолидированных отчетов в удобной для пользователя форме. Это и эргономика, достаточно высокая, основанная на том, что в Microsoft работает очень хорошая, наверное, лучшая в мире команда по дизайну эргономичных интерфейсов. Конечно, пользователи привыкли к тому, что Microsoft Office – это достаточно удобная и знакомая среда, интуитивно понятная, имеющая массу способов выполнения однотипных действий. Существуют и контекстное меню, и горячие клавиши, и целый ряд других элементов интерфейса, с помощью которых можно сделать похожие операции.

Известно, что Office как корпоративный продукт во многом является надстройкой над. NET, и существуют специальные библиотеки на основе объектов, которые дают возможность построения приложений как надстройки над Microsoft.NET.

Важные преимущества связанны также с адаптируемостью, с легкостью реконфигурации настройки процессов бизнес-деятельности, настройки степени надежности, безопасности, и следует в очередной раз вспомнить принцип Secure by design, который заложен в основы ЖЦ программных продуктов Secure Development Life Cycle, т. е. подхода, который нацелен на то, чтобы обеспечить многоуровневую безопасность, начиная с этапа проектирования.

Если говорить о корпорации, очень важным аспектом является глобализация, т. е. распределение данных по глобальной сети, с одной стороны, и возможность доступа к ним в глобальной среде Интернет посредством веб-браузера как тонкого клиента, с другой, с получением согласно профилю пользователей консолидированных отчетов, если это необходимо.

Достаточно важным с точки зрения интернет-профилирования является также профилированный доступ с учетом как уровней доступа, так и характеристик устройств доступа к данным. Это могут быть и стационарные компьютеры, и ноутбуки, и смартфоны, и телефоны, и ряд устройств личных предпочтений пользователей и особенностей настройки профиля доступа к данным, которые разграничивают доступ для различных категорий корпоративных пользователей.

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

После краткого введения в Microsoft Dynamics сделаем некоторые предварительные выводы и затем обсудим более подробно Microsoft Dynamics CRM, которая дает возможность построить ряд контуров управления бизнесом с акцентом на взаимодействии с клиентами, управления цепочками поставок, с управлением финансами и вообще взаимоотношениями с клиентами.

Рассмотрим основные функции семейства систем Microsoft Dynamics, сначала просто перечислим их:

• управление производством;

• управление распределением (дистрибуцией);

• управление цепочками поставок;

• управление финансами;

• управление проектами;

• управление отношениями с клиентами;

• управление персоналом;

• бизнес-анализ;

• корпоративный портал (Microsoft SharePoint);

• сервисы отчетов на Microsoft SQL Server 2005;

• поддержка. NET (веб-сервисы Microsoft Visual Studio);

• интеграция приложений (Microsoft BizTalk Server 2006).

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

Другой важный аспект интеграции – это поддержка отчетных сервисов на основе Microsoft SQL Server, начиная с версии 2005. Заметим, что Microsoft Dynamics можно рассматривать как надстройку над платформой Microsoft.NET, и в связи с этим используются как веб-сервисы, так и инструментарий для построения корпоративных приложений на большом количестве языков программирования на основе Microsoft Visual Studio.

Если говорить об интеграции приложений, можно использовать BizTalk Server, на основе которого можно подключать гетерогенные источники данных, осуществлять интеграцию с ними в достаточно продуктивном режиме.

Microsoft Dynamics дает следующие преимущества: адаптируемость – гибкая возможность приспосабливать функциональность системы к быстро меняющимся требованиям в бизнесе; масштабируемость – плавное снижение производительности системы при резком возрастании нагрузки (например, при возрастании количества пользователей, сложности запросов и т. д.).

Свойства продукта, которые обеспечивают эти характеристики:

• управление производством;

• интеграционная среда разработки, обеспечивает объединение с инструментальными средствами, Microsoft Visual Studio в частности;

• объектно-ориентированный подход – компонентно-ориентированный подход к разработке. Все есть объект – основной постулат. NET, который во многом справедлив для Microsoft Dynamics;

• динамические бизнес-процессы. Управление всем жизненным циклом производства. Контуры кадровые, финансовые и т. д., которые объединяются в Microsoft Dynamics, и возможность построения отчетов фактически дают нам возможность получения некоторого аналога приборной панели для руководства, на которой видны основные показатели бизнеса предприятия и их связь с теми глобальными параметрами, на основе которого ведется управление не только производством, но и распределением продукции.

Здесь важно отметить, что бизнес-процессы при этом становятся динамическими, т. е. динамически корректируемыми, в зависимости от ситуации в бизнесе. Например, работа с недвижимостью во многом претерпевает негативные изменения, также сейчас есть сложности в реальном секторе экономики, в металлургии и нефтегазовом секторе, но, с другой стороны, существуют инновационные отрасли, которые, наоборот, находятся на подъеме. В связи с этим потенциальная возможность гибко изменять структуру бизнеса, бизнес-процессов и управления ими, которая изначально заложена в Microsoft Dynamics, является преимуществом;

• масштабируемые бизнес-процессы. Возможность детализации до различного уровня – уровня компании, подразделения, государства, региона, конкретного поставщика, производителя или клиента, с которым ведется взаимодействие, и, естественно, возможно агрегирование показателей до корпорации в целом;

• поддержка разработчиков разного уровня. Поддерживаются различные виды приложений, созданных как Microsoft, так и сторонними разработчиками. Некоторые приложения – Microsoft SQL Server, BizTalk Server и т. д. – предназначены для интеграции приложений и управления данными. Существует возможность встраивания продуктов и алгоритмов управления бизнес-процессами от сторонних производителей;

• «слоевая» архитектура хранения и исполнении прикладных объектов. Важно, что прикладные объекты и сервисы, которые на них основаны, во многом представляются и используются в виде слоев, т. е. существует несколько слоев логики, один из самых нижних – системный, Windows-механизмы, которые ограничены технологиями и продуктами Microsoft. Дальше имеется надстройка в виде стандартных компонентов и библиотеки объектов. NET Framework, над. NET надстраиваются различные сервисы прикладного уровня, это компоненты в виде DLL корпоративных приложений, это и Microsoft Dynamics, и, возможно, те компоненты, которые разрабатывались сторонними поставщиками. Таким образом осуществляется хранение и управление собственными корпоративными системами, которые являются гетерогенными;

• инкрементальное, безопасное наращивание функций системы. При таком подходе управление функционалом системы позволяет осуществлять достаточно безопасное и относительно эффективное с точки зрения сроков и стоимости наращивание функционала, которое производится инкрементально, т. е. в соответствии с требованиями бизнеса осуществляются доработка, развитие, наращивание именно тех функций, которые необходимы. При этом с точки зрения системы интересной функцией, которую можно обеспечить на основе Microsoft Dynamics, является коррекция бизнес-логики путем откатов, т. е. возвратов к более раннему состоянию изначальной бизнес-логики. Естественно, снижаются риски, связанные с управлением бизнесом, и с учетом снижения затрат на обновление ПО. Другим важным источником экономии является эффективное переобучение персонала, что довольно важно для корпораций с большим количеством сотрудников. Переобучение проходит эффективно за счет того, что персонал хорошо знаком с Microsoft и обучение ведется в привычных терминах продуктов Microsoft. Очень важно, что можно гибко управлять требованиями, поскольку бизнес-процессы хорошо адаптируются к требованиям. Кроме того, существует большое количество решений, которые реализованы некоторыми партнерами Microsoft и приложимы к конкретным отраслям;

• расширение функциональности «стандартными» отраслевыми решениями. Если говорить о преимуществах, которые реализуются в области надежности, безопасности и конфиденциальности данных, для корпоративной структуры это критически важные аспекты, то нужно подчеркнуть, что Microsoft Dynamics реализует корпоративный уровень надежности и безопасности. Существует стратегия Trustworthy Computing, которая связана с обеспечением необходимого уровня доверия пользователей к системе и компонентов системы друг к другу и обеспечивается Microsoft Dynamics. При этом поддерживаются как стандартные протоколы Windows, которые обеспечивают безопасность взаимодействия, так и подходы, связанные с использованием многоуровневой аутентификации, на основе Active Directory, и специальные средства защиты информации. Это и криптозащита на основе стандартных протоколов Microsoft и сторонних разработчиков. Кроме того, Microsoft достаточно жестко тестирует бизнес-критичные продукты по таким параметрам, как надежность и отказоустойчивость, в основном эти характеристики имеют высокий уровень и обеспечиваются Microsoft.

Относительно глобализации, т. е. соответствия глобальному характеру производства и распределения, реализуемому корпорациями, Microsoft Dynamics обеспечивает следующие преимущества:

• многоязычный интерфейс – готовые локализации для более чем 30 языков, на которых идет общение. Естественно, речь идет не просто о переводе интерфейса, локализация учитывает многие национальные особенности;

• мультивалютность – поддерживается мультивалютный учет;

• распределенные инсталляции;

• учет специфики законодательства и бухгалтерии. Учитывается специфика требований, связанных с законодательством, финансами, делопроизводством, кадровыми документами, и целый ряд других юридических требований, которые в разных странах имеют свои особенности;

• поддержка юникода в БД – многоязычные данные в одной компании/документе, поскольку в базах данных на основе Microsoft SQL Server поддерживается юникод, возможно использование консолидированных документов, которые производятся в разных странах и при этом могут быть многоязычные данные в одном и том же документе;

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

Если говорить о глобализации, уместно напомнить и о том, что используются стандартные средства на основе Microsoft SharePoint-портала, которые дают возможность осуществить глобальное управление данными фактически из любой точки земного шара.

Управление производством:

• планирование потребностей в материалах и производственных мощностях;

• ведение нормативно-справочной информации с учетом специфики законодательства и отчетности в различных странах;

• детальное планирование производственных заданий с высокой степенью детализации;

• управление ресурсами;

• внутрицеховое управление;

• калькуляция себестоимости;

• конфигурирование продукции;

• контроль версий выпускаемой продукции – как промышленной, так и ПО.

Управление дистрибуцией. Отдельно нужно отметить такой контур, как дистрибуция, т. е. распределение поставок продукции, которая уже произведена. В нефтегазовом секторе существует понятие up stream и down stream, т. е. производство и распределение, и есть специализированные модули, которые отвечают за каждый аспект.

В данном случае дистрибуция подразумевает следующие аспекты:

• управление распределенной структурой складов;

• управление запасами;

• торговые соглашения;

• работа с перспективными заказами;

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

Управление цепочками поставок. Корпоративный бизнес связан с большим количеством разных поставщиков, и если говорить о нефтегазовом секторе и сложной задаче обустройства месторождения, здесь существует необходимость работать с большим количеством подрядчиков, оборудования и в итоге нужно обеспечить запуск промыслов в срок и без потерь ресурсов. В связи с этим необходимо обеспечить цепочки поставок между различными производителями и контрагентами и после этого – стабильный спрос, стабильные поставки, поэтому в рамках данный задачи Microsoft Dynamics поддерживает модули, которые связаны:

• с прогнозированием спроса;

• внутрифирменными продажами;

• управлением поставками;

• работой с партнерами через Интернет;

• контролем эффективности.

Управление проектами:

• осуществляется управление различными типами проектов;

• существует иерархия проектов;

• существует процедура расчета финансовой составляющей проекта;

• поддержка работы через Интернет.

Управление финансами — поддерживается:

• управление финансовой аналитикой;

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

• полный аудит всех финансовых потоков;

• учет затрат на основе центров затрат;

• поддержка управления основными средствами.

Управление отношениями с клиентами очень важно. Существует специальный продукт Microsoft Dynamics CRM, который призван поддерживать задачу управления взаимоотношениями с клиентами, его основные задачи:

• управление продажами и автоматизация маркетинга;

• телемаркетинг и анкетирование;

• управление продажами;

• работа через Интернет;

• интеграция с телефонией;

• документооборот, стандартные процессы выставления счетов, коммерческих предложений и т. д.;

• синхронизация с Outlook.

Управление персоналом. Основные функции:

• оптимизация организационной структуры, оргструктура во многом является ноу-хау больших компаний. Молодые компании часто применяют заимствование организационной структуры, но это достаточно сложно, поскольку внутри корпорации есть локализованные знания, которые проблематично использовать механическим заимствованием;

• отслеживание качеств сотрудников, управление эффективностью;

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

• работа через Интернет;

• набор персонала;

• система оценки персонала.

Бизнес-анализ. Естественно, для большой компании бизнес-анализ стратегически важен, поскольку любой собственник бизнеса понимает, что существует целый ряд узких мест, где имеются потери средств, эффективности, времени и т. д., и, конечно, нужны средства эффективного анализа. Это очень важно во время кризиса, когда целые области и корпорации кардинально меняются, заменяются другими или вовсе закрываются.

В этой связи используются следующие функции:

• инструменты создания многомерных кубов;

• интеграция с Microsoft Analysis Services;

• анализ информации с использование встроенных Pivot таблиц;

• система сбалансированных показателей (BSC);

• ключевые индикаторы производительности (KPI), которые являются основой расчета эффективности производственных процессов в большинстве корпораций.

Только что упомянутые преимущества Microsoft Dynamics во многом основаны на использовании ключевых технологий Microsoft и интеграции этих технологий:

• интеграция с продуктами Microsoft (SQL Server, BizTalk Server, SharePoint, Visual Studio, Office), используется целый ряд продуктов на общей платформе Microsoft Windows и Microsoft.NET, в том числе Microsoft.NET Framework;

• SQL Server – система управления базами данных;

• BizTalk Server – средство интеграции приложений, как собственных, так и сторонних;

• SharePoint – средства построения порталов и организации гибкого поиска и доступа к данным;

• Visual Studio – средства поддержки практически полного цикла программного обеспечения на основе платформы. NET с использованием большого количества языков и подходов к программированию: логического, функционального, объектно-ориентированного и т. д. Все это происходит в объектах на основе компонентно-ориентированного подхода, при этом компоненты могут выпускаться различными компаниями на различных языках и встраиваться в общие программные модули;

• Office – средства построения отчетов и целый ряд других важных средств;

• унификация бизнес-логики с интернет-доступом (распределение функционала по интернет-среде);

• трехуровневая архитектура (масштабируемость) с тонким клиентом в виде веб-браузера дает возможность гибкой масштабируемости;

• встроенная ОО-среда разработки дает возможность высокой адаптируемости и поставки под заказ в том составе, который наиболее необходим и важен.

Итак, подводя итоги рассмотрения семейства продуктов Microsoft Dynamics, подчеркнем преимущества, которые реализованы благодаря тесной интеграции различных средств на общей платформе. NET и Windows:

• адаптируемость;

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

• инновационность;

• технологичность;

• лучшая в классе показателей ROI (возврат инвестиций), который характеризует корпоративные системы;

• поддержка передовых бизнес-практик и бизнес-процессов.

Microsoft Dynamics CRM

Microsoft Dynamics CRM – это система управления отношениями с клиентами (customer relations management), которая позволяет определить, настроить и поддерживать, динамично развивая, стратегию ведения бизнеса. Естественно, это система корпоративного типа, т. е. изначально заложена возможность мультивалютного учета, локализация, управление системой через Интернет, поддерживается возможность управления контуров ведения бизнеса.

Система включает более 10 модулей.

Структурная схема Microsoft Dynamics CRM представлена на рис. 18.1.

Рис. 18.1. Структурная схема Microsoft Dynamics CRM

Основные задачи этой системы – управление продажами, сервисом, т. е. обслуживание клиентов, автоматизация маркетинга.

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

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

Управление сервисами – это управление обращениями клиентов в сервисную службу заказчика, календарь сервиса, периодичность и время реакции на обращения, база контрактов, т. е. условий оказания тех или иных услуг заказчикам, и база знаний, что позволяет во многом сэкономить трудозатраты при поиске стандартных ответов.

При разграничении доступа и путей доступа к данным реализуются два подхода, которые связаны:

• с интернет-доступом через веб-браузер (MS Internet Explorer);

• интеграцией интерфейса с MS Outlook для автономной (off line) работы (например, в офисе клиента).

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

Рис. 18.2. Обобщенное представление интерфейса

И, кроме того, нужно заметить, что на рисунке явно написан IP-адрес и используется протокол HTTP для обмена информацией, т. е. работа ведется через Интернет, а это достаточно важно.

Как пример, показано средство планирования рабочего времени. Далее будет более подробно рассказываться о функциональных возможностях Microsoft Dynamics.

Программная платформа Microsoft Dynamics: улучшения и перспективы

Рассмотрим внедрение на базе семейства продуктов Microsoft Dynamics по отраслям. Попробуем оценить специфику некоторых отраслей и разобраться в том, каким образом имеет смысл настроить приложения на основе Dynamics так, чтобы они позволили корпоративным структурам, специализирующимся прежде всего в рассматриваемых областях, достаточно эффективно вести бизнес, учитывать его ключевые показатели и повышать значимость, увеличивать эффективность взаимодействия, повышать степень удовлетворенности клиентов, качество своей работы, надежность и эффективность по ряду других критериев. Следует напомнить, что ранее были представлены решения для нефтегазовой отрасли, преимущественно на основе продуктов Oracle, Oracle Applications. Далее будут рассмотрены основы MS Dynamics и использование этой платформы для корпоративных решений общего вида.

Попробуем сконцентрироваться на некоторых характерных отраслях внедрения для того, чтобы оценить специфику и понять следующее. Во-первых, насколько применимы в принципе технологии и платформа Dynamics к решению различных отраслевых проблем, отраслевой специфике. Во-вторых, насколько универсальна эта платформа, поскольку будут рассмотрены только три отрасли из достаточно большого спектра, по которому уже существует внедрение, у партнеров Microsoft их достаточно много. После этого постараемся сосредоточиться на итогах. Вначале была обсуждена самая абстрактная часть, моделирование, затем методология после моделей жизненного цикла, самого абстрактного из описания того, каким образом происходит проектирование и реализация корпоративных систем. Затем был рассмотрен уровень технологий и инструментальных средств. И сейчас начинается более глубокая и точная детализация – будут рассмотрены уже отраслевые внедрения.

В первую очередь рассмотрим перспективы развития Microsoft Dynamics и некоторые новые возможности, которые либо уже появились в этой платформе, либо появятся в скором времени, такие как:

• средства улучшенного взаимодействия с базами данных и хранилищами данных различного вида;

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

• организация серверов приложений и различных сетевых структур, в которых объединяются эти серверы;

• средства обновления данных;

• средства обновления кода;

• средства повышения производительности, в том числе достижение корпоративного уровня масштабируемости;

• применение портальных решений. Известно, что корпоративные решения на базе Microsoft Dynamics и те корпоративные решения, которые рассматривались раньше, на основе технологий Oracle, построены во многом на портальном подходе, который позволяет в единой архитектуре объединить гетерогенные информационные системы в общие программные комплексы. Здесь можно видеть, каким образом осуществляется интеграция с порталом Microsoft на основе технологии SharePoint и продукта Share-Point и каким образом унифицируется, с одной стороны, и персонализируется, с другой, пользовательский интерфейс так, чтобы пользователи получали возможность гибкого и надежного доступа к приложениям и данным с теми возможностями, которые для них определены;

• последовательность ключевых операций, которые предусмотрены в Microsoft Dynamics для тех или иных сценариев, и различные функциональные изменения и изменения в интерфейсе, которые, в частности, включают ленты (Ribbons), что напоминает нам интерфейс Windows Vista и поздние операционные системы, офисные решения Microsoft.

Как уже неоднократно отмечалось, корпоративные системы – это системы с большими, распределенными, гетерогенными базами данных, т. е. с базами данных, которые дают возможность получить достаточно хорошую картину бизнес-деятельности корпорации, эффективно проанализировать, построить прогноз развития корпорации и получить аналитические или оперативные срезы отчетов, консолидирующих эту корпоративную информацию на разных уровнях.

При взаимодействии с базой данных поддерживаются сложные структуры запросов, в частности вложенные запросы. Запрос может быть задан рекурсивно или как сложная функция, содержащая внутри себя другой запрос. Более того, в серьезных корпоративных системах, таких как Oracle Applications или Oracle Bussiness Suit, и в поддерживающих их СУБД, таких как Oracle Enterprise Server, реализованы расширения традиционного SQL до PL SQL, т. е. до языков, которые дают возможность разрабатывать процедуры. И здесь поддерживается целый ряд важных механизмов, кроме вложенных запросов, в частности режим курсоров, в том числе операция <fetch>, которая обеспечивает динамическую выборку и интерактивное взаимодействие с пользователем по результатам этой выборки. Поддерживаются расширенные операции объединения <union>, когда у нас объединяются результаты нескольких подзапросов с учетом различных условий. Поддерживаются при множественном обновлении записей соединения <join>, как внешние, так и внутренние. Кроме того, достаточно серьезный механизм реализован для обработки исключений, как это видно из примера.

В приведенном примере происходит дублирование ключа, т. е. того атрибута, который изначально должен быть уникальным для каждой таблицы. При этом видно, что используется язык, похожий на C#, с оператором <try> и альтернативами <catch>. Существует большое количество древовидных исключений, напоминающих пространство имен System Exception.NET, и в целом вся обработка похожа на то, что обсуждалось в связи с пространствами. NET и вообще идеологией. NET. Важно, что здесь эта идеология распространяется на случай не просто взаимодействия с базой данных, а некой надстройки над этими базами данных на уровне системы учета планирования и управления корпоративными ресурсами MS Dynamics.

Еще одно важное дополнение – это возможность поддержки большого количества часовых поясов. Это важно, потому что корпорация, будучи территориально распределенной структурой, функционирует в разных странах, на разных континентах. И по статистике «Итера», некоторые из топ-менеджеров проводят до трети своего рабочего времени в воздухе или командировках. Это достаточно много. Поэтому руководителю нужно иметь возможность получить срез оперативной информации по бизнес-деятельности корпорации, отдельных ее структур, компаний, регионов и т. д. применительно к различным часовым поясам и сделать это так, чтобы результирующие данные были актуальными.

В этой связи вводится новый тип данных – DateTime, который:

• имеет новый интерфейс;

• снабжен возможностью не ориентироваться на локальное время машины, на которой, собственно, работает база данных и Dynamics;

• использует UTC. Это французская аббревиатура, на английском она звучит как Coordinated Universal Time. При доступе к базе данных автоматически пересчитывать время на тот регион, из которого производится запрос.

Естественно, осуществляется преемственность с предыдущими версиями Dynamics, которые сохраняют местную семантику, если говорить о локальном времени, о предыдущих типах данных, которые учитывают единственный часовой пояс, то с ними обеспечивается преемственность. При миграции данных производится автоматическое обновление до UTC относительно текущего часового пояса. Что еще очень важно, в Dynamics существует встроенный язык, который называется X++. Это объектно-ориентированный язык. Можно сказать, что он больше похож на С++, чем на C#. Хотя определенное тяготение к. NET-идеологии также присутствует. Вот на этом языке можно осуществлять процедурные расширения и, в частности, использовать его для доступа к базам данных.

Еще одна важная особенность, которую нужно отметить в отношении корпоративных систем, это возможность учета для многих компаний. Надо понимать, что корпорация объединяет большое количество различных компаний, вообще говоря, с разными направлениями деятельности. И достаточно важна возможность консолидации данных компаний для того, чтобы получить эффективное средство подготовки отчетности как для внешнего и внутреннего аудита, так и для руководства корпорации. Последние версии Microsoft Dynamics обеспечивают унифицированный доступ к данным компании. То есть не важно, откуда производится доступ: это могут быть формы ввода, запросы или отчеты. Можно использовать код языка Х++, чтобы получить доступ к базам данных, как уже говорилось.

Что еще интересно, поддерживаются гетерогенные таблицы и таблицы, которые агрегируют информацию по различным компаниям. Для этого используется новое ключевое слово для работы с компаниями, которое называется <crosscompany>. Ниже представлен пример запроса, который как раз включает это слово.

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

Дальше можно производить выборку по многим компаниям с учетом содержимого этого контейнера.

Кроме того, существует ряд изменений в структуре запросов, которые также нацелены на использование множества компаний, т. е. видно, что в структуре запросов можно явно указывать, допустимо ли использовать учет по многим компаниям или нет в данном случае. На рис. 18.3 представлен вариант отчета или просмотра данных по различным компаниям. Видно, что в отчете представлены как различные компании (dm2, dmo), так и различные сотрудники этих компаний. При этом отчет агрегируется и представляется для просмотра пользователю в едином интерфейсе DataGre-at, который является частью Windows Forms, одним из стандартных классов, в котором производится выборка данных из гетерогенных источников в том числе.

Еще одним важным направлением развития Microsoft Dynamics является пакетная обработка заданий. Здесь, наверно, уместно вспомнить, что пакетная обработка заданий использовалась еще очень давно, когда применялись широко мейнфреймовые архитектуры, машины типа IBM 360, EC 1030, возможно, и несколько раньше. Здесь эти технологии поднимаются на новый уровень, используются серверы, которые обслуживают пакеты заданий. При этом они строятся на основе объектных серверов, которые называются Application Object Server. Существует возможность группового запуска задач на одном сервере, балансировки загрузки между разными серверами. Для каждого пакета задач формируются специализированные извещения по завершении, т. е. достаточно гибко осуществляется управление заданиями в пакетном режиме.

Рис. 18.3. Вариант отчета или просмотра данных по различным компаниям

Далее перечислено, что собственно добавлено в отношении пакетной обработки в Dynamics:

• создание и описание задач. Задачи, если говорить о корпорации, часто могут быть взаимозависимыми и взаимосвязанными. В ряде случаев между задачами, если рассмотреть, например, сетевой график их выполнения, возникают достаточно сложные зависимости;

• возможность запуска задач как в последовательном, так и параллельном режиме;

• анализ зависимости между задачами и принятие решения, каким образом имеет смысл эти задачи реализовывать;

• распараллеливание потоков выполняемых задач по серверам (Application Object Server);

• оптимизация потоков задач в зависимости от загрузки серверов, в том числе сервер может автоматически выполнять несколько потоков в зависимости от пропускной способности и своей загрузки;

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

• построение дерева зависимостей (создается X++-разработчиком), что дает возможность определить взаимодействие различных задач, пакетов задач в системе.

Еще одним важным направлением развития является архитектурное расширение Application Object Server до 64-бит. Здесь поддерживаются серверные компоненты в архитектуре 32 и 64 бита. Также 32– и 64-разрядная архитектура поддерживается для коннекторов на основе. NET для подключения сторонних приложений, для интеграции приложений. При этом возможна как балансировка нагрузки, так и поддержка распределенных систем на основе нескольких кластеров.

Еще один важный вопрос, который нужно рассмотреть для продолжения разговора о новых чертах Microsoft Dynamics, – это обновление данных. На самом деле применительно к корпоративным системам это достаточно сложная проблема обновления данных, приложений, потому что, естественно, это огромное количество взаимодействующих модулей, достаточно сложные взаимосвязи между ними и серьезные осложнения, если система собирается неправильно, т. е. какая-то версия модуля не вполне соответствует своему программному окружению. Для того чтобы облегчить обновление данных, существуют возможности, связанные с построением списков обновления, или Upgrade checklist. Процедура построения такого списка представлена на рис. 18.4.

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

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

Рис. 18.4..Список обновления, или Upgrade checklist

Еще один важный этап обновления системы, кроме обновления данных, – это обновление кода. Здесь тоже существует целый ряд этапов, которые последовательно реализуются при выполнении действий по обновлению. Формируется проект обновления, который поддерживает в ряде случаев автоматическое обнаружение и разрешение конфликтов. Отчасти о конфликтах говорилось в главе, которая была посвящена архитектурам данных, в частности проблемам, связанным с управлением данными при многопользовательской работе, при работе в больших распределенных системах. Кроме того, используется значительное количество визуальных индикаторов, в том числе характеризующих продолжительность процесса обновления, которые существенно упрощают для администраторов процесс управления обновлениями. Реализовано специальное средство, которое осуществляет послойное сравнение данных, и здесь учитывается возможность переименования, смены имени узлов системы. Кроме того, можно прогнозировать и динамически корректировать ожидаемые результаты от обновления кода.

На рис. 18.5 и 18.6 показано, каким образом происходит обновление кода.

На верхнем рисунке, там, где написано Detect upgrade conflicts (обнаружить конфликты обновления), осуществляется поиск по слоям (см. рис. 18.5). Проект обнаружения работает со слоями и осуществляет поиск проекта или ряда проектов, которые как раз и управляют обновлениями. При этом результирующий код будет соответствовать соглашению Trustworthy Computing, т. е. пройдет необходимые тесты Microsoft на внутреннюю безопасность.

Проект представлен на рис. 18.5 под названием AxUpgradeLay-erConflits_usr. Здесь видно, что достаточно большая степень вложенности, и можно видеть определенную метаинформацию, в частности описание методов, интерфейсных элементов, которые связаны с источниками данных и методами публикации этих данных, с методами, которые связывают эти данные с интерфейсом пользователя.

На рис. 18.6 сравнения производятся по двум вариантам кода. В ряде случаев присутствуют или могут присутствовать расхождения. Появляются специальные подсказки о том, где эти расхождения могут возникать. Кроме того, строится отчет, который прогнозирует продолжительность обновления в часах, минутах и разбивает процесс обновления на части, каждую из которых он оценивает по времени. Виден процесс проверки на уровень безопасности, который соответствует Trustworthy Computing. Это достаточно интенсивный и затратный по времени процесс, судя по общей продолжительности он составляет никак не менее 10 % от общей продолжительности Upgrade, обновления кода.

Еще один важный вопрос, который необходимо рассмотреть, – это поддержка клиентов, т. е. пользователей, которые приобрели продукт, по которым ведется определенный сбор и анализ данных. Естественно, информация, которая характеризует личность пользователей, т. е. критичная и персональная информация, не собирается и не используется. Используется прежде всего информация об аппаратном обеспечении: сервер, процессор и память, объем памяти, количество и тип процессоров, программная среда, которая учитывает название и версию операционной системы, версию системы управления базами данных, как правило, это Microsoft SQL Server, и индикаторы, которые связаны с балансировкой нагрузки. Кроме того, используется ряд счетчиков, которые описывают такие показатели, как масштабируемость, т. е. производительность системы и динамика роста системных и пользовательских таблиц.

Рис. 18.5. Поиск конфликтов в ходе обновления кода

Рис. 18.6. Оценка времени обновления кода

Механизм обеспечения производительности:

• уменьшение требований к пропускной способности канала;

• обеспечение параллельной синхронизации;

• ряд механизмов кэширования, когда наиболее частые запрашиваемые пользователями данные хранятся не на внешних устройствах сервера, а в оперативной памяти, и таким образом доступ к ним осуществляется значительно быстрее;

• средства нормализации структур данных, т. е. реструктуризация упорядочения структур данных и ужесточение ограничений, которые накладываются на зависимые атрибуты в таблицах;

• перевод на 64-разрядную архитектуру;

• наращивание ресурсов Application Object Server, кэширование уникальных индексов.

Интерфейс тоже претерпел некоторые изменения, в основном в сторону усовершенствования. Пользователи могут гибко настраивать свои домашние страницы, собирая на них нужные формы и отчеты. Таким образом каждый получает в персонализированном виде свою приборную панель, на которой видит основные показатели деятельности корпорации в динамике (рис. 18.7).

Рис. 18.7. Персонализированная приборная панель

Здесь используются и диаграммы, и графическая информация. И наглядная информация, которая в масштабируемом виде, как справа внизу (см. рис. 18.7), представляет собой доходы от потребителей, каким образом они растут. Существует порядка 30 предопределенных ролей пользователей, которые могут при этом конфигурироваться, настраиваться и усовершенствоваться.

Интерфейс напоминает ленты-риббоны, примерно как те, которые используются в Windows Vista. Широкий спектр информации теперь может выгружаться в MS Excel, т. е. интеграция с офисными приложениями, которые привычны для большинства пользователей, расширена. Обновлены меню и команды, и модули имеют свои области. На рисунке можно видеть несколько отчетов, которые строятся из разных модулей, и в левом нижнем углу существуют специальная область, которая как раз перечисляет модули: главная книга, расчеты с поставщиками и подрядчиками, управление производством, управление складом, средства администрирования и т. д. Для каждого пользователя этот набор свой, и набор тех отчетов, которые в итоге он увидит, также отличается.

Портал является, как уже говорилось, единой точкой входа, унифицированным интерфейсом пользователя MS Dynamics, во многом средства проектирования объединены со средствами, которые предоставляет Visual Studio.NET.

Что касается интерфейса и элементов управления, то в основном используются технологии ASP.NET и элементы, которые наследуются из SharePoint-портала. При этом технология ASP.NET может поддерживать элементы управления, которые разработаны не только Microsoft, но и сторонними производителями. Нужно заметить, что, естественно, как сторонние производители, так и пользователи системы могут создавать собственные элементы управления и настройки, т. е. персонализировать интерфейс примерно так, как это обсуждалось в главе, посвященной Windows Forms, когда на основе стандартной библиотеки можно использовать наследование, создавать собственные элементы управления, достаточно сложные и специфичные структуры.

Поддерживается автоматизированное проектирование интерфейса с использованием средств и технологий на базе Visual Studio.NET, и при применении технологии ASP.NET осуществляется управление на основе Common Original Time, ядра CLR.

В MS Dynamics AX 5.0 осуществляется целый ряд улучшений по сравнению с предыдущими версиями, в частности:

• новый механизм документооборота;

• усовершенствованные средства бизнес-анализа, целого ряда показателей в динамике;

• улучшенная интеграция с Microsoft Office;

• поддерживается электронная подпись, множественные сайты;

• концепция разработки и предоставление программного обеспечения как сервиса, в частности, на основе COA (сервисно-ориентированной архитектуры), веб-сервисов;

• поддерживается 64-разрядный сервер приложений – Application Object Server;

• различные часовые пояса.

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

Финансовое управление:

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

• сопоставление данных внутри холдинга, поддержка отчетов для внутреннего аудита предприятий;

• моделирование бизнес-процессов на предприятии;

• улучшенные инструменты финансового анализа, построение статистических отчетов;

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

• улучшенная поддержка работы с кредитными картами.

Взаимоотношения с заказчиками (CRM):

• поддерживается глобальная адресная книга;

• работа с потенциальными клиентами;

• иерархические шаблоны процессов, интеграция с Microsoft Exchange, с другими продуктами, которые позволяют организовать продуктивное взаимодействие с заказчиками. Это почтовые клиенты, Microsoft Internet Explorer для доступа к данным, возможность удаленного доступа к данным, возможность автономной работы с данными в офисе клиента;

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

Управление затратами:

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

• корпоративный портал обеспечивает унифицированный доступ к затратным центрам, расширяются возможности работы с аналитическими отчетами и бизнес-аналитикой;

• автоматизируется распределение затрат на командировочные и другие расходы;

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

Управление проектами:

• поддерживается интеграция с Microsoft Project Server. Это основное программное обеспечение от Microsoft для консолидированного, корпоративного, командного управления затратами;

• поддерживается экспорт данных в Microsoft Excel, и работа пользователей становится прозрачной, интуитивно яснее;

• расширенная возможность управления проектами.

Далее кратко рассмотрим преимущества и расширения, которые возникли в более поздних версиях Microsoft Dynamics.

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

Управление возвратом товаров и сервисным обслуживанием – более подробно будет рассмотрено при обсуждении телекоммуникационной сферы как одного из направлений внедрения Microsoft Dynamics.

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

Бережливое производство – поддерживается технология Kanban, которая возникла в Японии (это слово означает доску, на которой записываются определенные производственные показатели). Речь идет о технологии, близкой к технологии just-in-time планирования производства, при этом реализуется вытягивающий принцип планирования, когда целью является обеспечение максимально сжатых и точных сроков и точное прогнозирование количества единиц продукции, которое будет поставлено.

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

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

Таким образом, нужно сказать, что Microsoft Dynamics – достаточно хорошее решение с точки зрения универсальности и интегрированности. Поддерживается интеграция с платформой. NET, Microsoft SharePoint с портальными решениями, с решениями сторонних поставщиков на основе в том числе и веб-сервисов и сервисно-ориентированной архитектуры в целом. Естественно, поддерживается компонентное проектирование, т. е. заказчики могут приобрести именно те компоненты Microsoft Dynamics, которые нужны для решения их бизнес-задач и обеспечения бизнес-потребностей.

Глава 19 Обзор отраслевых корпоративных внедрений на платформе Microsoft Dynamics

Продолжим разговор о Microsoft Dynamics и рассмотрим области внедрения. Их достаточно много. Это, в частности:

1) ряд отраслей промышленности:

• пищевая;

• мебельная и деревообрабатывающая;

• легкая и текстильная;

• производство изделий из пластика, бумаги;

• машиностроение и приборостроение;

• добывающая;

• металлургия и металлообработка;

• нефтегазовая;

• химическая (в том числе фармацевтика, косметика);

2) а также:

• энергетика и коммунальные услуги;

• телекоммуникации;

• издательская и полиграфическая деятельность;

• строительство и недвижимость;

• торговля.

Говоря о промышленности, рассмотрим нефтегазовый и банковский сектора, а также телекоммуникации.

Нефтегазовые холдинги

В этой главе будем говорить скорее о нефтяной специфике, чем о газовой (о которой речь уже шла). Эти области связаны, поскольку при производстве нефти газ является побочным продуктом. Нужно отметить, что объем добычи газа крупными нефтяными компаниями примерно сравним с объемом добычи относительно небольших частных компаний, для которых газ является профильным направлением. Добыча и переработка нефти – достаточно сложный процесс, даже если не говорить об очистке и экологии, и, конечно, он в значительной степени ресурсоемкий. В этой связи возникают следующие задачи, в целом характерные для нефтегазового сектора:

• контроль производства в реальном времени, распределение мощностей;

• планирование закупок и поставок.

Контроль производства в реальном времени достаточно сложен. Например, когда идет геологоразведка, необходимо в реальном времени контролировать и упреждающе влиять на возможные ошибки процесса бурения. Бурение – также очень сложный процесс, он предполагает в ряде случаев большие глубины, при этом на пути могут возникать совершенно различные структуры, которые достаточно трудно проходить, необходимо использовать разные кислоты, специальные методы травления, анализировать большое количество параметров и управлять разными параметрами. При этом стоимость затрат на разведочное бурение только одной скважины составляет порядка 1 млн долл., и любая ошибка (а на последних метрах ее вероятность выше, чем в начале) приводит к тому, что бурить скважину приходится заново. То есть любая ошибка приводит к потери временных, людских ресурсов и т. д.

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

Для нефтегазового профиля Microsoft Dynamics предлагает следующий функционал:

• необходимость автоматизации специфических процессов. Если говорить о дистрибуции, то возникают такие проблемы, как учет товара, вплоть до номера вагона, работа с агентскими договорами, экспедиторская деятельность, учет переработки нефти;

• расчет себестоимости нефтепродуктов (на основе фактических и прогнозных цен);

• аналитический учет и балансировка расходов (по партиям товара, маршрутным поручениям, накладным).

Кроме того, в нефтегазовых холдингах существует большое количество специфичных процессов, которые надо настраивать отдельно, это, в частности, автоматизация уникальных процессов компаний холдинга:

• финансовые поручения, векселя, взаимозачеты и закупки;

• заемные отношения;

• цепочки движения товара внутри холдинга;

• автоматический перенос платежей внутри холдинга;

• сквозная финансовая аналитика.

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

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

• пятикратное ускорение расчета себестоимости нефтепродуктов (при повышении точности). Это важно, поскольку цены можно формировать, только понимая, каким образом строится себестоимость, естественно, себестоимость меняется в зависимости от партии товара, структуры и т. д.;

• двукратное ускорение выполнения операций;

• упорядочение учета товаров за счет снижения ошибок человеческого фактора. Если говорить о большом количестве поставок и сложных маршрутов движения товаров, возникает много ошибок, когда можно потерять товар. Если же учет автоматизируется и осуществляется сквозной учет, то можно обеспечить существенное упорядочение учета товаров и снизить ошибки. За счет этого во многом упрощается и стандартизуется учет накладных транспортных расходов, его можно производить в реальном времени и в итоге экономить значительные средства.

Сам программный продукт становится достаточно экономичным с точки зрения совокупной стоимости владении и возврата инвестиций, потому что он хорошо адаптирован к менталитету пользователя, поскольку пользователям достаточно близко офисное представление данных Microsoft Office. Здесь также близкая интеграция с Excel и SharePoint-порталом, поэтому пользователи получают отчетную информацию в настраиваемом и удобном им виде, с другой стороны, осуществляется разграничение доступа к данным. Известно, что большое количество угроз и финансовых потерь связано именно с вредом, который наносят сотрудники корпорации, поэтому здесь применение Microsoft Dynamics обеспечивает важные преимущества. Для нефтегазовой сферы это реальное время при учете планирования и распределения процессов производства.

Банковский сектор

Другой сферой практического применения Microsoft Dynamics являются банковские структуры как финансовые подразделения. Это достаточно интересная специфика, хотя в целом достаточно понятно, как функционирует банк и какие специфические бизнес-процессы в нем происходят.

Основная проблема банковской сферы – ее автоматизация, комбинирование индивидуального подхода с высокой надежностью. В идеале банк должен адаптироваться под клиента и предоставить именно те виды сервиса, в которых нуждается клиент и которые его персонально устроят. С другой стороны, банк обязан обеспечивать крайне высокую надежность своих решений, поскольку каждая ошибка чревата большими финансовыми потерями для него. Если, например, некие хакеры или группа лиц находят определенную брешь в системе защиты банка, то он может очень серьезно пострадать в финансовом плане и это перекроет все преимущества, которые банк предлагает пользователю с точки зрения персонализации услуг. Эта дилемма очень сложна для каждого банка, тем не менее она должна быть решена.

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

С помощью Microsoft Dynamics обеспечиваются возможности автоматизированного управления производственными процессами по следующим функциональным направлениям:

• консолидированное управление заявками, которые могут поступать из различных филиалов. При этом необходимо достаточно гибко и последовательно осуществлять политику консолидации;

• распределенное, «прозрачное» управление запасами. Необходимо обеспечить, с одной стороны, распределенность, а с другой – прозрачность, чтобы можно было построить консолидированный отчет и достаточно гибко получать отчеты и результаты с детализацией до конкретной страны и т. д.;

• гибкое управление основными средствами и активами (внутренний аудит, мониторинг). Необходимо иметь возможность постоянного мониторинга активов, с учетом того, что они территориально распределены;

• управление отношениями с клиентами, т. е. выстраивание определенной политики в отношении различных категорий клиентов (здесь речь идет и о корпоративных клиентах, кредитных, зарплатных проектах и т. д.);

• бюджетирование (включает стратегическое (оперативное) планирование, оценку эффективности бизнеса), это могут быть конкретные проекты или планы с кредитованием, зарплатными проектами корпорации, детализацией по регионам, по филиалам и т. д.

Управление заявками:

• управление всем ЖЦ – от формирования до утверждения заявок;

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

• консолидация заявок;

• унификация обработки заявок, соблюдение регламентов;

• сохранение строгих процедур и регламентов;

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

Управление запасами:

• обеспечение доступности, «прозрачности» распределенных данных внутри банка. Хорошим решение является SharePoint-портал с разграничением прав доступа;

• общий источник достоверной информации для сотрудников разных уровней;

• сокращение дублирования и логических противоречий данных либо искажения данных сотрудниками;

• снижение расходов средств, людских ресурсов и времени.

Управление основными средствами, активами:

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

• разнообразие трассировки основных средств или построение отчетной информации по разным критериям основных средств (склады, местонахождение и др.);

• упрощение внутреннего и внешнего аудита активов, поскольку существуют консолидированные отчеты. Постоянный мониторинг и достаточно точные данные по всем основным средствам;

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

• экономия средств, времени и трудозатрат.

Построение и управление отношениями с клиентами (партнерами, контрагентами и др.), как физическими, так и юридическими лицами:

• интеграция и консолидация клиентской базы;

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

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

• повышение скорости и качества обслуживания с учетом запросов клиентов;

• учет индивидуальности клиентов;

• повышение эффективности маркетинговых кампаний.

Бюджетирование:

• комплексная система стратегического управления;

• комплексная оценка эффективности бизнеса (качественные и количественные KPI);

• «балансировка» стратегии и тактики планирования и реализация различных инициатив на разных уровнях;

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

• стратегическая интеграция уровней управления;

• адаптивный мониторинг целевой динамики (многовариантные сценарии «что если», «масштабируемость» по оргструктуре банка с обратной связью, прогнозирование и коррекция).

Преимущества при внедрении Microsoft Dynamics:

• надежность платформы (тысячи внедрений), т. е. речь идет о достаточно стабильной и надежной платформе;

• интеграция со сторонними системами как на базе. NET, так и на базе сервисно-ориентированной архитектуры;

• эффективность расчетов, адаптивность системы к различным требованиям законодательства и специфике бизнеса в разных регионах;

• автономный режим, взаимодействие с филиалами;

• возможность продажи функционала Microsoft Dynamics покомпонентно. При этом заказчик получает ровно тот функционал, который ему необходим, при сохранении расширяемости на перспективу. Это дает возможность обеспечить достаточно гладкое сопровождение и оптимизировать совокупную стоимость владения. Гибкое лицензирование (оптимизация функционала при сохранении расширяемости);

• оптимизация ТСО;

• инкрементальное внедрение.

Телекоммуникации

Еще одна сфера, которая будет рассмотрена, – это телекоммуникации. Речь будет идти о программном обеспечении:

• КОРУС|Телеком на базе Dynamics NAV (средние и крупные предприятия связи);

• сертификат качества ISO 9001:2000;

• функционал, в частности:

– бюджетное управление;

– финансовая консолидация;

– международная отчетность;

– управление инвестициями;

– управление договорами и ОРД;

– управление бесперебойной работой сети;

– управление ремонтно-техническим обслуживанием.

Бюджетное управление:

• бюджетирование «сверху-вниз» и «снизу-вверх»;

• скользящее бюджетирование/прогнозирование;

• поддержка многоверсионного бюджета (сценарии, тарифы, курсы, динамический анализ, инвестиции, капвложения и др.);

• многовариантый анализ на основе сценариев («что если», «на лету»);

• регламенты бюджета и ввод фактических данных;

• различные варианты импорта внешних фактических данных;

• интеграция с БД на уровне внешних документов;

• территориально-распределенный бюджет;

• детализация «до договора» и «до документа».

Финансовая консолидация:

• для территориально-распределенных холдингов;

• многоуровневый сбор финансовой отчетности с автоматической обработкой данных;

• преднастроенный план счетов, типовые отчеты;

• контроль целостности и согласованности данных в целом по корпорации и по отдельным ее подразделениям;

• контроль и передача данных по оргструктуре;

• финансовая консолидация данных;

• учет/анализ движения инвестиций и заемных средств;

• анализ доходов и затрат за отчетный период.

Международная отчетность:

• поддержка соответствия стандартов РПБУ и МСФО;

• автоматическая коррекция отчетности c учетом различий в учете основных фондов и инвестиций;

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

Управление инвестициями:

• оценка инвестиционных проектов;

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

• консолидация гетерогенной информации по заявкам и по инвестиционным проектам (маркетинг, оборудование, финансирование и др.);

• возможность выбора наиболее эффективных инвестиционных проектов;

• формирование инвестиционных программ по проектам;

• интеграция с системой бюджетного планирования;

• вариативная оценка влияния инвестиционных программ на стратегические показатели холдинга.

Управление договорами и ОРД:

• унификация и оптимизация документоборота на основе создания новых и ввода существующих договоров;

• интернет-управление договорами в реальном времени;

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

• поддержка текстовых редакторов (Microsoft Word);

• возможность процедуры автозапуска утверждения договора;

• шаблоны основных документов, договоров, ОРД и др.;

• соблюдение юридических стандартов холдинга;

• отслеживание/планирование движения средств;

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

Документарное управление работой сети:

• поддержка сетевых операционных центров, реализующих техническое управление сетью;

• создание хранилищ, стандартизация технической и эксплуатационной документации;

• тонкий клиент для доступа и коррекции данных;

• централизация сервиса (журнал, workflow);

• быстрая окупаемость за счет снижения ТСО сетевых операционных центров.

Управление ремонтом и сервисом:

• мониторинг оборудования (линии, точки, таксофонные будки и др.);

• оптимизация ресурсов (финансовых, людских);

• перспективное/краткосрочное планирование и подготовка ремонтов;

• разработка и контроль сетевых графиков;

• управление событиями;

• материально-техническое обеспечение ремонтов;

• формирование отчетов, архивов и БД по ремонтам и оборудованию.

Преимущества, которые обеспечиваются как в сфере телекоммуникаций, так и в целом при решении проблем на основе Microsoft Dynamics:

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

• модули системы основаны на открытых технологиях, стандартах и интерфейсах, которые понятны и доступны достаточно большому количеству пользователей;

• поддерживаются сторонние системы, например механизмы интеграции с системами биллинга, другие виды систем, т. е. возможно встраивать компоненты от других разработчиков в систему Microsoft Dynamics.

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

Заключение

Подводя итоги, заметим, что прежде всего были рассмотрены модели максимально абстрактного вида, а также целый ряд моделей, связанных с математическими основами проектирования корпоративных систем. Далее были описаны модели ЖЦ и методологии, которые являются параллельными направлениями. Далее речь шла о технологиях и программных архитектурах распределенных систем, были рассмотрены системы, связанные с файл-серверной архитектурой, клиент-серверной архитектурой, двух– и трехзвенной системой, связанной с интернет-архитектурой, системы, связанные с серверами баз данных, системы, в которых явно выделяется прикладная логика, логика доступа к ресурсам, бизнес-логика. Далее был переход от архитектур к инструментальным средствам и программным решениям.

В качестве инструментального средства объектом рассмотрения была платформа Visual Studio.NET. Она была рассмотрена в общем, говорилось также о том, что такое программное обеспечение как сервис, что такое принцип, о том, что всякая сущность есть объект. Был обсужден компонентно-ориентированнй подход к построению программных решений, веб-сервисы и другие подходы, связанные с поддержкой сервисных решений (Windows communication foundation remoting). Далее повествовалось об интерфейсах (Windows forms), языковой интерперабельности. Очень важно, что можно разрабатывать компонентные приложения на тех языках, которые наиболее соответствуют специфики предметной области, логическое, функциональное программирование и т. д.

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

Таким образом, процесс проектирования и разработки корпоративных систем был рассмотрен в целом ряде аспектов: методологии, модели, технологии, архитектуры, программные средства, а также практические внедрения. При этом обсуждался целый ряд сфер деятельности корпораций, в которых реализованы такие внедрения, с точки зрения их специфики.

Литература

1. Аншина М., Цимбал А. Технология создания распределенных систем. СПб.: Питер, 2003.

2. Армстронг Т. ActivX: Создание Web-приложений. Киев: BHV, 1998.

3. Бабурин Д.Е., Бульонков М.А., Емельянов П.Г., Филаткина Н.Н. Средства визуализации при перепроектировании программ // Программирование. 2001. № 2. С. 21–33.

4. Барендрегт Х. Ламбда-исчисление. Его синтаксис и семантика: Пер. с англ. М.: Мир, 1985.

5. Берг А.И., Ляпунов А.А., Яблонский С.В. Теоретические и практические проблемы кибернетики // Морской сборник. 1960. № 2. С. 33–56.

6. Берестовая С.Н., Перевозчикова А.Л., Романов В.М., Ющенко Е.Л. Конструирование систем программирования обработки данных. М.: Статистика, 1979.

7. Биггс М. Перспективы интеграции корпоративных приложений // Computerworld Россия. 1999. № 32.

8. Брюхов Д.О. Конструирование информационных систем на основе интероперабельных сред информационных ресурсов: Дис… канд. техн. наук. М., 2003.

9. Бумфрэй Ф. и др. XML. Новые перспективы WWW. М.: ДМК, 2000.

10. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++: Пер. с англ. 2-е изд. М.: Бином, 1998.

11. Бэкус Дж. Алгебра функциональных программ: мышление функционального уровня, линейные уравнения и обобщенные определения // Математическая логика в программировании. М.: Мир, 1991. С. 58–118.

12. Ветошкин В.М. Постановка задачи синтеза оптимальной схемы реляционной базы информационных систем (ADBIS’93) // Перспективы развития систем баз данных и информационных систем (ADBIS’93): Тр. рабочего семинара Московской секции АСМ SIGMOD. М.: ИПИ РАН, 1993. С. 109–115.

13. Ветошкин В.М., Гузенко В.Г. Методология, технология и семейство инструментальных средств проектирования баз данных СИНТЕЗ+ // Перспективы развития систем баз данных и информационных систем (ADBIS’93): Тр. рабочего семинара Московской секции ACM SIGMOD. М.: ИПИ РАН, 1993. С. 100–108.

14. Вагин В.К., Кикнадзе В.Г. Дедуктивных вывод на семантических сетях в системах принятия решений // Изв. АН СССР. Техническая кибернетика. 1984. № 5.

15. Вагин В.Н., Федотов А.А., Фомина М.В. Метод извлечения и обобщения информации в больших базах данных // Изв. РАН. Теория и системы управления. 1999. № 5. С. 45–59.

16. Важенин А.П., Миренков Н.Н. Элементы системы визуального программирования VIM // Программирование. 2001. № 4. С. 68–80.

17. Вельбицкий И.В. Алгебра конструирования алгоритмов и программ // Управляющие системы и машины. 1987. № 6. С. 99–110.

18. Виттих В.А. Интеграция знания при исследованиях сложных систем // Изв. РАН. Теория и системы управления. 1998. № 5. С. 132–139.

19. Вольфенгаген В.Э., Кузин В.Т., Саркисян В.И. Реляционные методы проектирования банков данных. Киев: Вища школа, 1979.

20. Вольфенгаген В.Э., Яцук В.Я. Алгебра на фреймах для манипулирования знаниями // Изв. АН СССР. Техническая кибернетика. 1984. № 5. С. 4–14.

21. Вольфенгаген В.Э., Яцук В.Я. Аппликативные вычислительные системы и концептуальный метод проектирования систем знаний / Под ред. Л.А. Майбороды. М.: МО СССР, 1987.

22. Вольфман Б. Разработка корпоративных систем с использованием современных инструментальных средств // Корпоративные базы данных: Матер. II технической конференции. М., 1997.

23. Георгиев В.О. Модели представления знаний предметных областей диалоговых систем // Изв. АН СССР. Техническая кибернетитка. 1993. № 5. С. 24–44.

24. Горелова Е. Внутренний сбой // Ведомости. 2002. № 89 (652).

25. Глушков В.М., Цейтлин Г.Е., Ющенко Е.Л. Методы символьной мультиобработки. Киев: Наукова думка, 1980.

26. Гречко В.О., Перевозчикова О.Л., Тульчинский В.Г., Тульчинский П.Г. Инструментарий прототипирования прикладных систем по модели предметной области // Управляющие системы и машины. 1998. № 1. С. 78–92.

27. Грир Т. Сети Интранет. М.: Русская редакция, 2000.

28. Девитт Д., Грей Д. Параллельные системы баз данных: будущее высокоэффективных баз данных // СУБД. 1995. № 2.

29. Демин В. Интеграция людей и информации в бизнес-процессы на основе портальных решений и организации динамических рабочих мест // DOCFLOW 2004 ().

30. Джерк Н. Разработка приложений для электронной коммерции. СПб.: Питер, 2001.

31. Евсеев О.В., Попов Э.В. Роль интеллектуальных инструментальных средств в реинжиниринге бизнес-процессов предприятий // Изв. РАН. Теория и системы управления. 1999. № 5. С. 74–82.

32. Ершов А.П. Абстрактная вычислимость в функциональных системах // Тез. докл. V Всесоюзн. конф. по проблемам теоретической кибернетики. 19–20 июня 1980. Новосибирск, 1980. С. 5–6.

33. Ершов А.П. Денотационный подход к описанию трансформационной семантики: Слайды доклада на семинаре проекта CIP в Мюнхенском техническом университете, 1982.

34. Ершов А.П. Некоторые проблемы математической теории вычислений: Докл. на совещании по теме «Математическая логика» двустороннего научного сотрудничества академий наук СССР и Болгарии. Новосибирск, 1982.

35. Ершов А.П., Покровский С.Б., Сабельфельд В.К. Внутренний язык в многоязыковой системе программирования как средство формализации семантики входных языков: Препринт ВЦ СО АН СССР. Новосибирск, 1974.

36. Ефимова С.М. Об алгебраическом подходе к проблеме представления знаний // Вопросы кибернетики. Ситуационное управление и семиотическое моделирование. М.: Финансы и статистика, 1983. С. 54–72.

37. Жожикашвили А.В., Стефанюк В.Л. Теоретико-категорные образцы для задач искусственного интеллекта // Изв. РАН. Теория и системы управления. 1999. № 5. С. 5–16.

38. Закис А. Технология создания и кастомизации офисных информационных систем // Корпоративные базы данных: Матер. II технической конференции. М., 1997.

39. Заккар М. Разработка приложений для электронной коммерции на Oracle 8i и Java. Киев: Вильямс, 2000.

40. Зиглер К. Методы проектирования программных систем: Пер. с англ. М.: Мир, 1985.

41. Золотарев В.И., Галюк Ю.П., Бычков В.В. Web-интерфейс доступа к высокопроизводительным ресурсам // Научный сервис в сети Интернет: Тр. Всероссийской научной конференции. М.: МГУ, 2002. С. 273–274.

42. Зиндер Е.З. Новое системное проектирование: информационные технологии и бизнес-реинжиниринг. Методы нового системного проектирования // СУБД. 1996. № 2.

43. Зыков С.В. Управление персоналом с помощью интегрированных информационных систем. М.: Недра коммюникейшнс, 2001.

44. Зыков С.В. Введение в теорию программирования. М.: Интернет-университет информационных технологий, 2004.

45. Зыков С.В. Проектирование интернет-порталов. М.: МФТИ, 2005.

46. Зыков С.В. Посткризисное управление жизненным циклом разработки программных систем // Управление проектами. 2010. № 3(20). С. 42–47.

47. Зыков С.В. Основы современного программирования. Разработка гетерогенных систем в интернет-ориентированной среде. 2-е изд. М.: Горячая линия – Телеком, 2012.

48. Калиниченко Л.А., Рывкин В.М. Машины баз данных и знаний. М.: Наука, 1990.

49. Калянов Г.Н. CASE-технологии проектирования программного обеспечения // Кибернетика и системный анализ. 1993. № 5. С. 152–164.

50. Кирстен В., Инингер М. и др. СУБД Cache. Объектно-ориентированная разработка приложений. СПб.: Питер, 2001.

51. Клещев А.С. Представление знаний. Методология, формализм, организация вычислений и программная поддержка // Прикладная информатика. 1983. Вып. 1. С. 49–93.

52. Клыков Ю.И. Ситуационное управление большими системами. М.: Энергия, 1974.

53. Коваленко В., Корягин Д. Эволюция и проблемы GRID // Открытые системы. 2003. № 1. С. 27–33.

54. Когаловский М.Р. Энциклопедия технологий баз данных. Эволюция технологий, технологии и стандарты, инфраструктура, терминология. М.: Финансы и статистика, 2002.

55. Когаловский М.Р. Перспективные технологии информационных систем. М.: ДМК Пресс, 2003.

56. Колмогоров А.Н. Автоматы и жизнь // Кибернетика ожидаемая и кибернетика неожиданная. М.: Наука, 1968. С. 10–29.

57. Копелев А.Б., Косарев В.А., Прохоров В.В., Смирнов Д.В. Визуальные мультиязыковые средства для разработки распределенных сред // Управляющие системы и машины. 1999. № 5. С. 75–83.

58. Коржинский С. Настольная книга Web-мастера: эффективное применение HTML, CSS и JavaScript. 3-е изд., перераб. и доп. М.: КноРус, 2006.

59. Косарев В.А., Прохоров В.В. Комплекс Интернет-медиасредств // Проблемы теоретической и прикладной математики: Тр. региональной молодежной конференции. Екатеринбург: ИММ УрО РАН, 2003. С. 282–294.

60. Коутс Ф., Влейминк И. Интерфейс «человек – компьютер». М.: Мир, 1990.

61. Кояма Т., Уэно Х. Представление и использование знаний. М.: Мир, 1989.

62. Крейнак Дж., Хебрейкен Дж. Интернет-энциклопедия. СПб.: Питер, 1999.

63. Кузин Л.Т. Основы кибернетики: В 2 т. М.: Энергоатомиздат, 1994.

64. Кузин Л.Т., Вольфенгаген В.Э., Саркисян В.И. Реляционные методы проектирования банков данных. Киев: Вища школа, 1979.

65. Кузнецов С. Новые возможности и тенденции развития средств управления базами данных и разработки информационных систем // Корпоративные базы данных: Матер. II технической конференции. М., 1997.

66. Кульгин М. Технологии корпоративных сетей. СПб.: Питер, 1999.

67. Курочкин В.М. Семантика языков программирования. М.: Мир, 1980.

68. Лавров С.С. Программирование. Математические основы, средства, теория. СПб.: БХВ-Петербург, 2001.

69. Лавров С.С. Формализация, лингвистика, логика // Семиотика и информатика. Вып. 27. М.: ВИНИТИ, 1986.

70. Ланк К., Чоу Дж. Публикация баз данных в Интернете. СПб.: Символ-Плюс, 1997.

71. Липаев В.В. Системное проектирование сложных программных средств для информационных систем. М.: СИНТЕГ, 1999.

72. Лукин Н.В., Филиппов В.А., Щукин Б.А. и др. Основные подходы к разработке корпоративных WEB-приложений с использованием технологий многомерных СУБД. М.: АПП, 1999.

73. Лукин Н.В., Филиппов В.А., Щукин Б.А. Модель данных с многозначными атрибутами // Современные технологии в задачах управления, автоматики и обработки информации: Тез. докл. VIII международного научно-технического семинара. М.: МИФИ, 1999.

74. Лукин Н.В., Филиппов В.А., Щукин Б.А. Сравнительный анализ современных СУБД // Современные технологии в задачах управления, автоматики и обработки информации: Тез. докл. IX международного научно-технического семинара. М.: МИФИ, 2000.

75. Любарский Ю.Я. Интеллектуальные информационные системы. М.: Наука, 1990.

76. Ляпунов А.А., Янов Ю.И. О логических схемах программ // Проблемы кибернетики. 1958. Вып. 1. С. 46–74.

77. Маклаков С.В. BPwin и ERwin. CASE-средства разработки информационных систем. М.: ДИАЛОГ-МИФИ, 1999.

78. Марчук Г.И. Актуальные проблемы вычислительной математики и математического моделирования // Сб. ст. ВЦ СО АН СССР, ОВМ. Новосибирск: Наука, 1985.

79. Мизин И.А. Справочник. Протоколы информационно-вычислительных сетей. М.: Радио и связь, 1990.

80. Минский М. Фреймы для представления знаний. М.: Мир, 1979.

81. Нариньяни А.С., Кондрашина Е.Ю. Технологический комплекс построения баз знаний // Вычислительные системы и программное обеспечение. Новосибирск: ВЦ СО АН СССР, 1986. С. 100–118.

82. Нариньяни А.С., Липатов А.А. Визуализация данных в технологиях интервальных расчетов // Информационные технологии. 2001. № 8.

83. Нильсен Я. Веб-дизайн: книга Якоба Нильсена. СПб: Символ-плюс, 2001.

84. Нильсен Н. Принципы искусственного интеллекта. М.: Радио и связь, 1986.

85. Ноутон П., Шилдт Г. Java 2 в подлиннике. Наиболее полное руководство. СПб.: BHV, 2000.

86. Ойхман Е., Евсеев О., Паронжданов С. Методологические основы проектирования информационных систем крупных организаций на базе развивающихся статических и динамических интеллектуальных моделей // Корпоративные базы данных: Матер. II технической конференции. М., 1997.

87. Олифер В.Г., Олифер Н.А. Компьютерные сети. Принципы, технологии, протоколы. СПб.: Питер, 1999.

88. Омельченко В.В. Структурно-логический метод обобщения и анализа данных и знаний // Изв. РАН. Теория и системы управления. 1998. № 5. С. 95–105.

89. Осипов Г.С. Динамика в системах, основанных на знаниях // Изв. РАН. Теория и системы управления. 1998. № 5. С. 24–28.

90. Остераут Дж. Сценарии: высокоуровневое программирование для XXI века // Открытые системы. 1998. № 3.

91. Перевозчикова О.Л., Сикаренко В.А. Интеграция Web– и клиент-серверной архитектур для распределенных приложений // Управляющие системы и машины. 2001. № 5. С. 57–63.

92. Плесневич Г.С. Представление знаний в ассоциативных сетях // Изв. АН СССР. Техническая кибернетика. 1982. № 5.

93. Поспелов Д.А. Логико-лингвистические модели в системах управления. М.: Энергоатомиздат, 1981.

94. Поспелов Д.А. Введение в теорию вычислительных систем. М.: Советское радио, 1972.

95. Поспелов Д.А. Ситуационное управление: теория и практика. М.: Наука, 1986.

96. Постояннов А.В., Филиппов В.А., Щукин Б.А. и др. Электронные хранилища информации и WEB-технологии. М.: Эдиториал УРСС, 2001.

97. Прикладное программное обеспечение информационных сетей: Учеб. пособие / Под ред. Л.Н. Сумарокова. М.: МИФИ, 1985.

98. Ривкин М.Н. Платформа для коммерческих сред Grid // Открытые системы. 2003. № 12.

99. Роджерсон Д. Основы COM: Пер. с англ. М.: Русская редакция, 1997.

100. Романовский И.В. Синтаксически управляемая обработка данных / Под ред. Б.К. Мартыненко. СПб.: СПбГУ, 1997.

101. Сахаров А. Концепции построения и реализации информационных систем, ориентированных на анализ данных // Корпоративные базы данных: Матер. II технической конференции. М., 1997.

102. Старыгин А. Построение корпоративных информационных систем: технологии и решения // Корпоративные базы данных: Матер. II технической конференции. М., 1997.

103. Стогний А.А., Вольфенгаген В.Э., Кушниров В.А., Араксян В.В., Саркисян В.И., Шитиков А.В. Проектирование интегрированных баз данных. Киев: Техника, 1987.

104. Сумароков Л.Н. Информационное обеспечение управленческих решений и организация работы руководителя. М., 1982.

105. Талиа Д. OGSA: где GRID встречатcя с Web // Открытые системы. 2003. № 1. С. 47–50.

106. Торопов Д.А. О структурных отношениях в денотационной семантике // Проблемы теоретической и прикладной математики: Тез. докл. Екатеринбург: УрО РАН, 1998. С. 75–76.

107. Тульчинский В.Г. Алгебро-грамматический подход к проектированию интерфейса // Кибернетика и системный анализ. 1996. № 6.

108. Тыугу Э.Х. Интеграция знаний // Изв. АН СССР. Техническая кибернетика. 1989. № 5. С. 3–13.

109. Фролов А.В., Фролов Г.В. Сценарии JavaScript в активных страницах Web. М.: Диалог-МИФИ, 1998.

110. Хилайер С., Мизик Д. Программирование Active Server Pages. М.: Русская редакция, 1999.

111. Хорошевский В.Ф. Программные средства представления знаний: состояние исследований и проблемы // Искусственный интеллект. Т. 3: Программные и аппаратные средства. М.: Радио и связь, 1990. С. 72–82.

112. Ноумер А., Улмен К. Dynamic HTML: Справочник. СПб.: Питер, 1999.

113. Цейтлин Г.Е. Алгебра логики и конструирования программ. Элементы дискретной математики. Киев: Наукова думка, 1994.

114. Цикритзис Д., Лоховски Ф. Модели данных: Пер. с англ. М.: Финансы и статистика, 1985.

115. Циперман Г. Корпоративные информационные системы как ключ к успеху управления компанией // Нефть и капитал. 1998. № 3. С. 80–84.

116. Шехватов Д. Западные интегрированные системы управления предприятием // Read.Me. 1997. № 10.

117. Ющенко Е.Л., Цейтлин Г.Е., Грицай В.П., Терзян Т.К. Многоуровневое структурное проектирование программ. М.: Финансы и статистика, 1989.

118. Яргер Р. Дж. и др. MySQL и mSQL. Базы данных для небольших предприятий и Интернета. СПб.: Символ-Плюс, 2000.

Примечания

1

Более подробно см.: Зыков С.В. Проектирование интернет-порталов. М.: МФТИ, 2005.

(обратно)

2

Липаев В.В. Программная инженерия. М.: ТЕИС, 2006.

(обратно)

Оглавление

Предисловие

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

  Глава 1 Введение в разработку корпоративных систем

  Глава 2 Обзор жизненного цикла корпоративных систем

  Глава 3 Модели жизненного цикла корпоративных систем

  Глава 4 Выбор модели жизненного цикла корпоративных систем

  Глава 5 Методологии разработки корпоративных систем

  Глава 6 Программные архитектуры корпоративных систем

Раздел II Средства, платформы и технологии разработки корпоративных систем

  Глава 7 Средства автоматизации разработки корпоративных систем

  Глава 8 Программная платформа Microsoft.NET

  Глава 9 Разработка интерфейсов корпоративных систем по технологии Windows Forms

  Глава 10 Технологии сетевого взаимодействия корпоративных систем

  Глава 11 Разработка веб-сервисов для корпоративных систем

  Глава 12 Разработка корпоративной сервисно-ориентированной архитектуры по технологии WCF

  Глава 13 Разработка компонентных корпоративных систем

  Глава 14 Разработка офисно-ориентированных систем по технологии VSTO

  Глава 15 Разработка корпоративных систем на основе библиотеки Enterprise Library

  Глава 16 Разработка корпоративных систем, ориентированных на базы данных (Microsoft SQL Server)

Раздел III Примеры отраслевых внедрений корпоративных систем

  Глава 17 Разработка корпоративных порталов для нефтегазового сектора

  Глава 18 Разработка корпоративных решений на платформе Microsoft Dynamics (AX/NAV/CRM)

  Глава 19 Обзор отраслевых корпоративных внедрений на платформе Microsoft Dynamics

Заключение

Литература Fueled by Johannes Gensfleisch zur Laden zum Gutenberg