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

assemble( order )

где order — это объект System:

System order = new System (

// Systeml задает параметр первого конструктора;

new Computer( 260, 64 ).

// System2 задает параметр второго конструктора;

new System( new Computer ( 400, 128 ). new Computer (260, 32) )

);

Команда assemble( order ) объекта Component возвращается к методу assemble() объекта System. Он создает строку 1 в выводе и вызывает assemble() для каждого из двух своих параметров (см. рис. 5.27). Для первого параметра, объекта Computer, assemble() выдает строку 2. Затем появляется и строка 3. При вызове assemble() с третьим параметром выполняются действия над объектом System, который, в свою очередь, передает управление двум объектам Computer, и т. д.

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

Проверка баланса / добавить сумму на счет + вычесть дефицит  из остатка;

Сохранить отчет / с:Reports + стандартные заголовки + заменить «Ed» на «А1»

Распечатать отчет / стандартные  заголовки 

Отправить отчет по адресу Jayne@xyz.net

Архитектура виртуальных  машин анализирует и интерпретирует такие сценарии.

Репозиторные архитектуры

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

Другие примеры репозиторных архитектур можно найти в области интерактивных сред разработки (IDE — Interactive Develompent Environment). Интерактивные среды разработки широко применяют такие процессы, как редактирование и компиляция в базу данных исходных кодов и объектных файлов.

Существует масса литературы, посвященной архитектурам баз данных, и в этой книге мы не будем пытаться охватить весь материал по данной теме. Многие приложения, к примеру, IDE, не затрагивают базы данных, пока последние не закончены. Проект игры Встреча в его простейшей форме не содержит базы данных. Однако если игра вырастет до размеров нескольких десятков персонажей, то может оказаться предпочтительней хранить персонажи в базе данных, а не в специальных файлах. И уж точно нам не обойтись без базы данных, если мы разрешим пользователю запрашивать статистику, например «количество персонажей с силой более 10». Для выражения подобных запросов используется язык ЅQL (Ѕtгuсtuгеd Query Language — язык структурированных запросов).

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

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

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

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

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

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

Инструментальные средства

Разработка программного обеспечения представляет собой  объемный рынок, на 
который также поставляются инструментальные средства в помощь инженерам, 
занимающимся производством программных приложений. Часто этот инструментарий называют инструментарием для автоматизированной разработки программ (CASE - Computer-aided Software Engineering). В течение многих лет обсуждается, что же относится к CASE-инструменту. В свое время разработчиками CASE-инструмснта было многое обещано, однако сделано было намного меньше. 
Компоненты CASE-ииструмента могут быть, например, такими.

♦ Для обеспечения управления проектом:

-  работа с расписанием;

- распределение работ.

♦ Для обеспечения управления конфигурациями.

♦ Для управления требованиями.

♦ Для проектирования:

- функциональные;

- объектно-ориентированные;

- основанные на вариантах использования.

♦ Инструменты отслеживания:

- перехода требований в проект;

- проекта в программный код.

♦ Для обеспечения тестирования.

♦ Для обеспечения технической поддержки.

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

32. Уровневые архитектуры. Смешанные  архитектуры.

Уровневые архитектуры.

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

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

Пример многоуровневой архитектуры  для банковского приложения печати Ajax представлен на рис. 5.30. В последнем случае имеется четыре уровня архитектуры. Зависимости между уровнями архитектуры показаны на рис. 5.31 в порядке, обратном используемому на рис. 5.30. Уровень приложения Ajax Bank Printing должен отвечать за печать и форматирование. Он построен на основе уровней Accounts и Ajax Bank Common Library. Последние построены на основе уровня, поддержку которого осуществляет продавец (на рис. 5.30 не показан). Этот уровень содержит общие утилиты, такие как средства сортировки и поиска. Обычно уровень реализуется в виде пакета классов. Например, Ajax Bank Common Library включает в себя классы, используемые в Ajax-приложениях. В качестве отношений может использоваться наследование, агрегация или объектная ссылка. Например, между уровнями допустима только агрегация.

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

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

Уровневые архитектуры имеют  множество преимуществ при повторном использовании. Библиотека классов Java является очень эффективной уровневой системой (пакет applet — уровень — основан на пакете awt, который в свою очередь основан на пакете lang, и т. д.).

Приложения со смешанной архитектурой

Приложения обычно используют несколько архитектур. Например, каркас для ролевых видеоигр может использовать несколько типов архитектур, приведенных Гарланом и Шоу (см. рис. 5.31). Это будет иметь смысл, например, если организовать пакет Артефакты как базу данных. Персонажи игры могут рассматриваться как параллельные взаимодействующие процессы; систему управления игрой мы можем организовать как систему обработки событий.

33. Прототипирование. Оценка необходимости покупки приложения или инструмента.

Прототипирование — быстрая «черновая» реализация базовой функциональности для анализа работы системы в целом.

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

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

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

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

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

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

♦ Предотвращение пустой траты  времени на предложенные требования, которые, как видно из прототипа, не нужны (то есть минимум три ненужных требования из 100; на этап требований выделено $300 000, сэкономлено $9000).

♦ Разработка программного проекта «примерка одежды», что уменьшает риски разработки (то есть оценка того, что это сэкономит минимум одну человеко-неделю времени проектирования = $2000).

♦ Переработка, которая может  возникнуть из-за изменения требований клиентом после того, как он увидит окончательный продукт (то есть переработка минимум трех требований по $3000 каждое = $9000).

Существует минимальная  экономия, эквивалентная $9000 + $2000 + $9000 = $20 000.

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

[максимальная оцененная  прибыль] - [минимальная оцененная  стоимость] = $80 000 - [(минимальная оцененная стоимость) х (процент неиспользования)] = $80 000 - [$10 000 х 50 %] = $75 000

Усреднение — это один из способов работы с разницей между  худшими и лучшими случаями. В результате получаем положительную выгоду для всех предложенных частей прототипа за исключением части «примерка одежды», которая оценена в -$4000: общий убыток $4000. Это приведет в дальнейшем к относительно низкой прибыли, высокой стоимости разработки и низкому вторичному использованию.

34. Документация по сопровождению  программных средств.