Дж. Рамбо, М. Блаха - UML 2.0 - Объектно-ориентированное моделирование и разработка (1158633), страница 71

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 71)

14.9.4. Внутреннее управление В процессе проектирования разработчик раскрывает операции на объектах в виде последовательностей операций более низкого уровня иа тех же самых или иных объектах. Внутренние взаимодействия объектов во многом схожи с внешними взаимодействиями, потому что для иих могут использоваться те же самые механизмы реализации. Однако существует и важное отличие: внешние взаимодействия всегда подразумевают ожидание событий, потому что объекты ие зависят друг от друга и не могут заставить друг друга отвечать именно в нужный момент. Внутренние операции объектов представляют собой часть алгоритма реализации, поэтому их отклик может быть предсказуем. Следовательно, внутренние взаимодействия часто можно рассматривать в виде вызовов процедур: вызывающий объект посылает запрос и ждет иа него ответа. Существуют алгоритмы параллельной 304 Глава 1ч ° Проектирование системы обработки, однако очень многие вычислительные задачи хорошо представляются последовательными алгоритмами и могут быть заключень» в единственный поток управления.

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

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

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

Завершение обычно оказывается проще инициализации, потому что большинство объектов можно просто уничтожить. Задача должна освободить все зарезервированные ею внешние ресурсы. В параллельной системе задача должна уведомлять о своем завершении все остальные задачи. ° Отказ. Отказ — это незапланированное завершение системы. Отказ может быть вызван ошибками пользователя, истощением системных ресурсов или 1«.11. Установка приоритетов 305 внешней поломкой. Проектировщик системы должен учитывать возможность ее отказа.

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

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

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

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

Установка приоритетов для принятия решений чаще всего дает достаточно туманные результаты. Не следует ожидать точных чисел, как то: скорость 53 г«, память 31 '», переносимость 15 Ж, стоимость 1 7«. Приоритеты редко оказываются абсолютными. Если скорость выполнения важнее, чем память, это не означает, что любой прирост скорости, даже самый небольшой, может оправдать неограниченное увеличение расходуемой памяти. Нельзя даже составить полный список 306 Глава 14 ° Проектирование системы критериев принятия решений. Приоритеты — это утверждение философии проекта. Реальное принятие решений на последующих этапах все равно потребует оценок и интерпретации поставленных целей.

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

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

В любом случае архитектурный стиль может послужить, по крайней мере, отправной точкой. Некоторые разновидности стилей перечислены ниже. ° Пакетное преобразование (ЬагсЬ ггапЫогшавоп) — однократное преобразование всех входных данных (раздел 14.12.1). ° Непрерывное преобразование (сопгпшопв ггапз1огшагюп) — преобразование изменяющегося входного сигнала, выполняемое непрерывно (раздел 14.12.2). ° интерактивный интерфейс (1пгегасггее тгег(асе) — система, в которой доминируют внешние взаимодействия (раздел 14.12.3). ° Динамическое моделирование (дупаппс з(пш!агюп) — система, моделирующая развивающиеся объекты реального мира (раздел 14.12.4).

° Система реального времени (геа1-11ше зузсеш) — система, отвечающая жестким временным ограничениям (раздел 14.12.5). ° Администратор транзакций (сгапзасгюп шапаяег) — система, занимающаяся хранением и обновлением данных, часто с поддержкой параллельного доступа из разных физических точек (раздел 14.12.6). Конечно, это не полный список известных систем и архитектур, однако мы постарались перечислить все наиболее распространенные стили. Для некоторых задач вам придется придумывать абсолютно новую архитектуру, но в большинстве случаев можно обойтись существующим стилем или какой-либо из его модификаций.

Характеристики

Список файлов книги