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

Глава 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: видеоконференции, дистанционное обучение, изучение фундаментальных процессов, научные исследования, имеющие дистанционный характер, высокопроизводительные вычисления.