Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (1158635), страница 80
Текст из файла (страница 80)
Ни один из перечисленных продуктов не родился за одну ночь.Все они постепенно развивались из самых простых систем, прошли путь проби ошибок. В результате эти системы вобрали в себя набор абстракций,достаточный для построения пользовательского интерфейса. Поскольку нетоднозначного ответа на вопрос о лучшем интерфейсе, то существуютнесколько вариантов оконной модели.В главе 9 мы уже упоминали о том, что при работе с большимибиблиотеками классов (каковыми являются и библиотеки графическогоинтерфейса) важно понять механизмы их построения. Для нашей задачиосновным механизмом является реакция GUI-приложений на события.
Берсонуказывал, что для клиентской части приложения существенны события,связанные со следующими объектами [24]:• мышь• клавиатура• меню• обновление окна• изменения размера окна• активизация/деактивация• начало/завершение.Мы добавим к этому перечню сетевые события.37 Для нашейархитектуры они очень существенны, поскольку клиентская часть приложениясвязана с другими компонентами и приложениями через сеть. Описаннаясемантика хорошо согласуется с нашим подходом к построению классаTransaction, который может рассматриваться как посредник, пересылающийсобытия от приложения к приложению.
С точки зрения построенияклиентской части, сетевые события являются разновидностью событий, чтопозволяет описать единый механизм реакции на события.Берсон обратил внимание на наличие нескольких альтернативныхмоделей обработки событий [25]:• Цикл обработки событий В цикле просматривается очередьсобытии и для каждого события вызывается соответствующая процедураобработки.• Обратный вызовПриложение регистрирует функциюобратного вызова для каждого элемента GUI; обратный вызов происходит,когда элемент зарегистрирует событие.• Гибридная модельСочетание циклического опроса и функцийобратного вызова.Изрядно упрощая, можно утверждать, что в интерфейсе MacAppиспользуется цикл, в Motif - функции обратного вызова, a Microsoft Windowsявляется примером гибридной модели.Кроме первичного механизма, нам необходимо реализовать ещемножество GUI-механизмов: рисование, прокрутка, работа с мытью, меню,сохранение и восстановление, печать, редактирование, обработка ошибок,распределение памяти.
Безусловно, подробное рассмотрение всех этихвопросов находится вне рамок нашего анализа, поскольку каждая конкретнаяGUI-среда имеет свои собственные реализации этих механизмов.Мы предлагаем разработчику клиентской части приложения выбратьподходящую GUI-среду разработки, изучить ее основные механизмы иправильно их применить.10.3. ЭволюцияУправление релизамиТеперь, полностью определив архитектурный каркас системыскладского учета, мы можем приступить к последовательному развитию.Выберем сначала наиболее важные транзакции в нашей системе (еевертикальный срез) и выпустим продукт, который по крайней мересимулирует выполнение транзакций.Для примера остановимся на трех простых транзакциях: занесение вбазу нового клиента, добавление товара и принятие заказа. При реализацииэтих транзакций мы в той или иной степени затронем практически всеархитектурные интерфейсы.
Если мы сможем успешно преодолеть этотключевой этап, то дальше будем выпускать релизы в следующем порядке:• Модификация или удаление данных о клиентах; модификация илиудаление данных о продуктах: модификация заказа; запросы о клиентах,заказах и продуктах.• Интеграция всех похожих транзакции, связанных с поставщиками:создание заказа и выписка счета.• Интеграция всех оставшихся транзакций, связанных со складом:составление отчетов и выписка расходных накладных.• Интеграция всех оставшихся транзакций, связанных с бухгалтерией:поступление оплаты.• Интеграция всех оставшихся транзакции, связанных с отгрузкой.• Интеграция всех оставшихся транзакций, связанных спланированием.При общем сроке проектирования системы в 12-18 месяцевнеобходимо каждые 3 месяца выпускать рабочий релиз программы.
Кокончанию срока все необходимые для работы системы транзакции будутохвачены.В главе 6 уже упоминалось, что ключевым моментом при такойстратегам является выявление риска, поэтому для каждого релиза мы находимсамое опасное место и активно прорабатываем его. Для приложенийклиент/сервер это связано, в первую очередь, с возможно более раннимтестированием вместимости и масшта-бируемости (чтобы как можно раньшенайти узкие места системы и сделать с ними что-нибудь). При этом в каждыйрелиз следует включать транзакции из разных функциональных элементовсистемы - тогда будет меньше шансов столкнуться с неожиданностями.Генераторы приложенийПри создании приложений типа системы складского учета необходимопроизвести множество экранных форм и отчетов.
Для больших систем этаработа не столько сложна, сколько велика по объему и однообразна. По этойпричине сегодня весьма популярны генераторы приложений на основе языковчетвертого поколения (4GL). Использование этих языков не противоречитидеям объектно-ориентированного проектирования. Напротив, 4GL-ЯЗЫКИпозволяют при правильном применении существенно упростить написаниекода.Языки четвертого поколения используются для генерации экранныхформ и отчетов. На основании спецификаций они создают исполняемый кодформ и отчетов.
Мы интегрируем этот код в нашу систему, "оборачивая" еговручную тонким объектно-ориентированным слоем. Таким образом код,сгенерированный 4GL, становится частью структуры классов, которуюостальные части приложения могут использовать, не обращая внимание на то,как она была создана.Такой подход позволяет нам воспользоваться преимуществами 4GL,сохраняя иллюзию полностью объектно-ориентированной архитектуры.Кроме того, языки четвертого поколения сами подвергаются сильномувлиянию технологии объект-но-ориентированного программирования ивключают в себя прикладные интер-фейсы (API) для объектноориентированных языков типа C++.Такую же стратегию можно использовать и при реализации диалогапользо-вателя с системой.
Написание программ для модального инемодального диалог скучно, поскольку мы должны охватить массу мелкихдеталей. Лучше не писать такой код вручную 38, а использовать GUIконструкторы, позволяющие "рисовать окна диалога. После полученияготового кода мы заворачиваем его в объектную оболочку, включаем в нашеприложение и получаем систему с четким разделением обязанностей.10.4. СопровождениеСистемы клиент/сервер редко бывают окончательно завершенными.Не то чтоб мы никогда не могли сказать про систему, что она уже стабильна.Просто систем должна развиваться вместе с бизнесом, чтобы оставатьсяполезной.Можно указать некоторые направления модернизации, которыевероятны для системы складского учета:• Предоставить возможность клиентам работать с системой по каналамсвязи.• Автоматически генерировать индивидуальные каталоги товаров дляпотре-бительских групп или даже отдельных клиентов.• Полностью автоматизировать все функции, устранив кладовщиков иболь-шую часть работающих на приеме и отгрузке.Анализ показывает, что все перечисленные модификации связаныскорее с со циалъным и политическим риском, чем с техническим.
Гибкаяобъектно-ориенти-рованная архитектура системы позволяет заказчикуиспользовать все степени сво-боды, чтобы адаптироваться к постоянноменяющемуся рынку.Дополнительная литератураОб архитектуре клиент/сервер написано больше, чем большинствосмертных способно прочесть за всю жизнь. Две наиболее полезные ссылки это Девайр (Dewire) [H 1992] и Берсон (Berson) [H 1992], которые предложилиисчерпывающие и хорошо читаемые обзоры по всему спектру проблемтехнологии клиент/сервер.
Блум (Bloom) [H 1993] дал короткое, но интересноеперечисление базовых понятий и проблем архитектуры клиент/сервер.Децентрализация - это не то же самое, что вычисления в архитектуреклиент/сервер, хотя она и предусматривает вычисления в архитектуреклиент/сервер в корпоративных информационно-управляющих системах. Всемотивировки за и против децентрализации можно найти в работе Гвенджерича(Guengerich) [H 1992].Исчерпывающее обсуждение технологии реляционных баз данныхможно найти у Дэйта (Date) [Е 1981,1983,1986].
Вдобавок к этому, Дэйт (Date)[E 1987] предложил описание стандарта SQL. Разные подходы к анализуданных могут быть найдены у Вериярда (Veryarcl) [В 1984], Хавришкевича(Hawryszkiewycz) [Е 1984) и Росса (Ross) [F 1987).Объектно-ориентированные базы данных представляют собой сплавобычной технологии баз данных и объектной модели. Отчеты о работе в этойобласти можно найти у Кэттла (Cattle) (Е 1991], Атвуда (Atwood) [Е 1991],Дэвиса и др. (Davis et al.) [H 1983], Кима и Ло-човского (Kim and Lochovsky)[H 1989], Здоника и Майера (Zdonik and Maier) [E 1990].В библиографии приведены несколько ссылок на различные оконныесистемы и объектно-ориентированные интерфейсы пользователя.Подробности о Microsoft Windows API можно найти в Windows [G 1992], аотносительно Apple МасАрр - в Масарр [G 1992].Глава 11Искусственныйинтеллект:криптоанализМыслящие существа способны проявлять очень сложные формы поведения, обладаясознанием, механизмы которого мы понимаем очень смутно.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
