Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (1158635), страница 79
Текст из файла (страница 79)
Однако,анализ частных случаев показывает, что есть продукты, для которых этихарактеристики недостаточны. С учетом того, что проектируемая системаявляется открытой, а виды товаров могут быть самыми различными, приведемнесколько примеров специфических товаров и их свойств:• Скоропортящиеся продукты, требующие определенного режимахранения.• Едкие и токсичные химические вещества, также требующиеспециального обращения.• Комплектные товары, которые поставляются в определенныхсочетаниях (например, радиопередатчики и приемники) и поэтомувзаимозависимы.• Высокотехнологичные компоненты, поставки которыхограничиваются за-конодательством стран-экспортеров.Перечисленные примеры наводят на мысль о необходимости созданиянекоторой иерархии классов товаров.
Однако, перечисленные свойстванастолько различны, что не образуют никакой иерархии. В данной ситуацииболее целесообразно воспользоваться примесями, что иллюстрирует и рис. 107. Обратим внимание на использование в этой диаграмме украшенийограничения, уточняющих семантику каждой абстракции.Каков смысл наследования для абстракций, отражающих сущностиреляционной базы данных? Очень большой: построение иерархиинаследования сопровождается вычленением общих признаков поведения иотображением их в структуре суперклассов. Эти суперклассы будутответственны за реализацию общегоРис. 10-7.
Классы товаровповедения для всех объектов, за исключением тех подклассов, которыеуточняют это поведение (через промежуточный суперкласс) или расширяютего (через суперкласс-примесь). Такой подход не только упрощает построениесистемы, но и повышает устойчивость к вносимым изменениям за счетсокращения избыточности и локализации общих структур и поведения.Механизм транзакцийАрхитектура клиент/сервер построена на взаимодействии клиентскойи серверной частей приложения, для реализации которого необходимопределенный механизм.
Берсон указал, что "существует три базовых видавзаимодействия между процессами в архитектуре клиент/сервер" [20]:• конвейеры (pipes)• удаленный вызов процедур (RPC)• взаимодействие клиент/сервер через SQL.В нашем примере мы воспользовались только третьим способом. Но, вобщем случае, могут использоваться все указанные виды взаимодействия всоответствии с требованиями производительности или в результате выборапрограммных средств конкретного поставщика. В любом случае наш выбордолжен быть скрыт, чтобы не оказывать влияния на абстракции высокогоуровня.Мы ранее уже упомянули о классе транзакции, но не остановилисьподробно на его семантике. Берсон определяет транзакцию как "единицуобмена и обработки информации между локальной и удаленной программами,которая отражает логически законченную операцию или результат" [21]. Это иесть определение нужной нам абстракции: объект-транзакция являетсяагентом, ответственным за выполнение некоторого удаленного действия, а,следовательно, отчетливо отделяет само действие от механизма егореализации.Действительно, транзакция является основным высокоуровневымвидом взаимодействия сервера и клиента, а также между клиентами.
Наоснове этого понятия можно выполнять конкретный анализ вариантовиспользования. Принципиально все основные функции в системе складскогоучета могут рассматриваться как транзакции. Например, размещение новогозаказа, подтверждение поступления товаров и изменения информации опоставщиках являются системными транзакциями.С внешней стороны можно выделить следующие операции,описывающие суть поведения в проектируемой системе:• attachOperation• dispatch• commit• rollback• statusДля каждой транзакции определяется полный перечень операций,которые она должна выполнить. Это означает, что для класса Transact ionнеобходимо определить функции-члены, такие как attachoperation, которыепредоставляют другим объектам возможность объединить набор SQLоператоров для исполнения в качестве единой транзакции.Интересно отметить, что такое объектно-ориентированное видениетранзакций полностью согласуется с принципами, принятыми в практикеработы с базами данных.
Дэйт определил, что "транзакция представляет собойпоследовательность операторов SQL (возможно, не только SQL), которыедолжны быть неразделимы в смысле произведения отката и управленияпараллельным доступом".36Концепция атомарности наиболее существенна в семантикетранзакций. Если в некоторой транзакции операция выполняется наднесколькими строками таблицы, то либо все действия должны бытьвыполнены, либо содержимое таблицы должно быть оставлено без изменении.Следовательно, когда мы посылаем транзакцию (dispatch), мы имеем в видувыполнение группы операций как единого целого.При благополучном завершении транзакции мы должнызафиксировать ее результаты (commit). Невыполнение транзакции можетпроизойти в силу ряда причин, в том числе из-за отказов сети или блокировкиинформации другими клиентами. В таких ситуациях выполняется откат висходное состояние (rollback).
Селектор status возвращает значение параметра,определяющего успешность транзакции.Выполнение транзакции несколько усложняется при работе сраспределенными базами данных. Как реализовать протокол завершениятранзакций при работе с локальной базой достаточно понятно, а чтонеобходимо сделать при работе с данными, размещенными на несколькихсерверах? Для этого используется так называемый двухфазный протоколзавершения транзакций [23].
В этом случае агент, то есть объект классаTransaction, разделяет транзакцию на несколько фрагментов и раздает их длявыполнения различным серверам. Это называется фазой подготовки. Когдавсе серверы сообщили о том, что готовы к завершению, центральный агенттранзакции передает им всем команду commit. Это называется фазойзавершения. Только при правильном завершении всех разделенных компоненттранзакции основная транзакция считается завершенной. Если хотя бы наодном сервере выполнение операций будет неполным, мы откатим всютранзакцию. Это возможно потому, что каждый экземпляр Transaction знает,как откатить свою транзакцию.Рис.
10-8. ТранзакцииИзложенное выше представление о классе транзакций показано на рис.10-8. Мы видим здесь иерархию транзакций. Класс Transaction являетсябазовым для всех транзакций и содержит в себе все ключевые аспектыповедения. Производные специализированные классы вносят в общееповедение свои особенности. Мы различаем, например, классыUpdateTransaction и QueryTransaccion, потому что их семантика оченьразлична: первый из них модифицирует данные на сервере баз данных, авторой - нет.
Различая эти и другие типы транзакций, мы собираем в базовомклассе наиболее общие характеристики, и пополняем при этом наш словарь.В процессе дальнейшего проектирования мы, возможно, обнаружим идругие разновидности транзакций, которые будут представленысобственными подклассами. Например, если мы убедимся, что операциидобавления и удаления данных из конкретной базы имеют общую семантику,то введем операции AddTransaction и DeleteTransaction, чтобы отразить этуобщность поведения.Во всяком случае, существование базового класса Transactionпозволяет выполнять нам любое атомарное действие.
Например, на C++ онмог бы выглядеть так:public:Transaction(};virtual ~Transact ion ();virtual void set0peration(constUnboundedCollection<SQLStatement>&);virtual int dispatch();virtual void commit();virtual void rollbackO;virtual int status{) const;protected:...};Обратим внимание, что для построения этого класса мы использовалибазовые классы, определенные нами в главе 9. В данном случае мы построилитранзакцию в форме индексированной коллекции операторов.
Дляманипулирования этой коллекцией использован параметризованный классUnboundedCollection.Принятое архитектурное решение позволяет сложномупользовательскому приложению выполнять наборы SQL-операторов. Вседетали реализации механизма управления транзакциями оказываютсяскрытыми для простых клиентов, которым достаточно выполнять некоторыеобщие типы транзакции.Создание клиентской части приложенияСоздание клиентской части в значительной степени сводится кпостроению графического прикладного интерфейса. В свою очередь,построение удобного интуитивного и дружественного пользователюинтерфейса - скорее искусство, чем наука.
В приложениях, построенных врамках архитектуры клиент/сервер, именно качество интерфейса определяет(в большинстве случаев) популярность тех или иных программ. При созданииинтерфейса пользователя необходимо учитывать множество различныхфакторов: технические ограничения, особенности психологии, традиции,вкусы персонала.При создании нашей системы складского учета мы можем столкнутьсяс двумя препятствиями. Во-первых, нужно выяснить, каким должен быть"правильный" интерфейс пользователя. Во-вторых, желательно определить,какие общепринятые подходы мы можем использовать при созданииинтерфейса.Ответ на первый вопрос можно получить достаточно просто, но дляэтого нужно прототипировать, прототипировать и прототипировать. Нужнокак можно раньше получить действующую модель системы, чтобы показать еепользователям и получить от них квалифицированные замечания.
Объектноориентированный подход существенно поможет нам в этом смысле, посколькуон основан на итерационном развитии проекта. На самых ранних стадияхпроекта мы уже сможем показать пользователям прототип системы.Второй вопрос находится в сфере стратегии проекта, но для егоуспешного разрешения у нас имеется множество хороших примеров.Существуют коммерческие продукты, например, Х Window System от MIT,Open Look, Windows от Microsoft, MacApp от Apple, NextStep от Next,Presentation Manager от IBM. Все эти продукты существенно различаются:некоторые основываются на сети, а некоторые опираются на концепцию ядра,некоторые позволяют действовать на уровне пикселей, а другие считаютпримитивами более сложные геометрические фигуры. В любом случае все онипозволяют существенно упростить создание графического интерфейсапользователя.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
