Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (1158635), страница 73
Текст из файла (страница 73)
Для того, чтобы обосновать наш выбор, попробуем оценитьпреимущества и недостатки того и другого подхода.Как оказалось, для выбранного очень простого механизмасохраняемости примесь не совсем подходит (зато она очень хорошовписывается в архитектуру настоящей объектно-ориентированной базыданных). При использовании примеси пользователь должен сам добавить ее ксвоему классу, зачастую переопределив при этом некоторые служебныефункции класса-примеси.
В нашем случае, для такого простого механизма этоокажется неэффективным, так как пользователю будет легче разработать своисредства, чем дорабатывать библиотечные. Таким образом, мы склоняемся ковторому решению, которое потребует от пользователя лишь созданияэкземпляра уже существующего класса.Рис. 9-14 иллюстрирует работу такого механизма, продлевающегожизнь объектов за счет работы отдельного агента. Класс persist являетсядружественным классу Queue; мы определяем эту связь внутри описаниякласса Queue следующим образом:friend class Persist<ltem, Queue<Item>>;В этом случае классы становятся дружественными только в моментинстан-цирования класса Queue. Внедрив подобные описаниядружественности в каждый абстрактный базовый класс, мы обеспечиваемвозможность использования Persist с любой структурой библиотеки.Параметризованный класс persist содержит операции записи исчитывания put и get, а также функции для подключения потоков обменаданными.
Мы можем определить данную абстракцию следующим образом:template<class Item, class Structure> class Persist {Public:Persist();Persist(iostream& input, iostream& output);virtual ~Persist();virtual void setInputStream(iostream&);virtual void setOutputStream(iostream&);Рис. 9-14. Обеспечение сохраняемости с помощью агентаvirtual void put (Structure&);virtual void get (Structure&);protected:iostream* inStreain;iostream* outStream;};Реализация данного класса зависит от того, является ли ондружественным классу Structure, который фигурирует в качестве аргументашаблона.
В частности, Persist зависит от наличия в структуревспомогательных функций purge, cardinality, itemAt, lock, и unlock.Далее срабатывает однородность нашей библиотеки: поскольку каждыйбазовый класс Structure имеет подобные функции, то persist можно безовсяких изменений использовать для работы со всеми имеющимися вбиблиотеке структурами.Рассмотрим в качестве примера реализацию функции Persist::put:template<class Item, class Structure>void Persist<Item, Structure>:put(Structure& s){s.lock() ;unsigned int count = s.cardinality();(*outStream) " count " endl;for (unsigned int index = 0; index < count; index++)(*outStream)s.unlock() ;}" s.itemAt(index);Эта операция использует разработанный нами ранее механизмблокировки, поэтому она будет работать и для защищенных, и длясинхронизированных форм.
Алгоритм работы функции несложен: сначала впоток выводится количество элементов структуры, а затем, последовательно,все ее элементы. Реализация persist:: get аналогично выполняет обратноедействие:template<class Item, class Structure> void Persist<ltem,Structure>::get(Structure& s){s.lock() ;unsigned int count;Item item;if (! inStream->eof()) {(*inStream) " count;s.purge() ;for (unsigned int index = 0; (index < count) && (!inStream->eof()); index++) { (*inStream) " item;s.add(item);} } s.unlock () ;}Для того, чтобы использовать этот простой механизм сохраненияданных, клиенту надо всего лишь инстанцировать один дополнительный классдля каждой структуры.Задача построения среды разработки является довольно сложной.
Приконструировании основных иерархий классов необходимо учитыватьразличные, зачастую противоречивые требования к системе. Старайтесьсделать вашу библиотеку как можно более гибкой: никогда нельзяпредсказать, как именно попытается ее использовать разработчик. Такжеочень важно сделать ее как можно более независимой от программной среды так легче будет использовать ее совместно с другими библиотеками.Предлагаемые абстракции должны быть как можно более простыми,эффективными и понятными разработчику. Самые элегантные решенияникогда не будут использованы, если сроки их освоения превысят время,необходимое программисту для решения проблемы своими силами. Сказать,что эффект достигнут, можно будет только когда станет видно, что вашиабстракции используются повторно много раз. То есть, когда разработчикощутил преимущества их использования и не изобретает велосипед, асосредоточивает внимание на тех особенностях задачи, которые еще никем небыли решены.Дополнительная литератураБигерстафф и Перлис (Biggerstaffand Perlis) [H 1989] провелиисчерпывающий анализ повторного использования программногообеспечения.
Вирфс-Брок (Wirfs-Brock) [С 1988] предложил хорошее введениев объектно-ориентированные среды разработки. Джонсон (Johnson) [G 1992]изучал вопросы документирования архитектуры сред разработки и выявил рядобщих моментов.Библиотека МасАрр [G 1989] для Macintosh является хорошимпримером правильно сконструированной объектно-ориентированнойприкладной среды разработки. Введение в более раннюю версию этойбиблиотеки классов может быть найдено у Шмукера (Schmucker) [G 1986].
Внедавней работе Голдстейн и Алджер (Goldstein and Alger) [С 1992]обсуждают развитие объектно-ориентированного программного обеспечениядля Macintosh.Другие примеры сред разработки: гипермедиа (Мейровиц (Meirowitz)[С 1986]), распознавание образов (Йошида (Yoshida) [С 1988]), интерактивнаяграфика (Янг (Young) [С 1987]), настольные издательские системы (Феррел(Ferrel) [К 1989]). Среды разработки общего назначения: ЕТ++ (Вейнанд(Weinand) [К 1989]) и управляемые событиями MVC-архитектуры (Шэн (Shan)[G 1989]). Коггинс (Coggins) [С 1990] изучил, в частности, развитие библиотекдля C++.Эмпирическое изучение объектно-ориентированных архитектур и ихвлияния на повторное использование можно найти в работе Льюиса (Lewis) [С1992].Глава 10Архитектура клиентсервер: складской учетСоздание большинства бизнес-приложений требует решения целого комплекса задачпо хранению данных, обеспечению параллельного доступа к ним, их целостности изащиты.
Для этой цели обычно используются готовые системы управления базамиданных (СУБД).Конечно, любая СУБД требует адаптации к условиям конкретного предприятия,которую организации часто разбивают на две задачи: проектирование данныхпоручается специалистам по базам данных, а программная поддержка выполнениятранзакций - программистам. Реализация такого подхода, имеющего, конечно, своипреимущества, сопряжена с решением ряда серьезных проблем.
Надо откровеннопризнать, что в деятельности разработчиков баз данных и программистов существуютсерьезные различия, которые определяются различиями в технологии и в навыкахразработки. Проектировщики баз данных обычно описывают проблемную область втерминах "долгоживущих" монолитных таблиц с информацией, в то время какпрограммисты привыкли воспринимать мир в терминах потоков управления.Если эти два подхода не удастся совместить в рамках одного проекта, то добитьсяцелостности проектного решения для более или менее сложной системы будетпрактически невозможно.
Для системы, в которой главное -данные, мы должныдобиться равновесия между базой данных и приложением. База данных,разработанная без учета того, как она в дальнейшем будет использоваться,оказывается, как правило, неуклюжей и неэффективной. В свою очередьизолированное приложение может предъявить невыполнимые требования к базеданных, что приведет к серьезным проблемам с обеспечением целостностиинформации.Еще в недалеком прошлом бизнес-приложения выполнялись на больших ЭВМ, чтовоздвигало для обычного служащего почти непреодолимые барьеры на пути к нужнойему информации.
Однако с пришествием персонального компьютера ситуация резкопеременилась: доступные инструменты обработки и хранения данных вкупе скомпьютерными сетями позволили соединить компьютеры не только внутри офиса, нои между предприятиями, отделенными друг от друга тысячами километров. Одним изосновных факторов, способствовавших такому изменению, было внедрениеархитектуры клиент-сервер. Как отмечает Мимно, "Резкий переход к архитектурамклиент-сервер на базе персональных компьютеров был вызван прежде всеготребованиями бизнеса.
Перед лицом возросшей конкуренции и ускорившегося циклавыпуска новой продукции, возникла потребность в более быстром продвижениитоваров на рынок, увеличении объема услуг, предоставляемых клиентам, болееоперативном отслеживании тенденций развития рынка, общем уменьшении расходов"[1]. В этой главе мы рассмотрим пример информационно-управляющей системы (MIS,management information system) и покажем, как объектно-ориентированная технологияпредлагает единую концепцию организации базы данных и разработкисоответствующего приложения для архитектуры клиент-сервер.10.1. АнализОпределение границ задачиТребования к системе складского учета показаны на врезке. Этодостаточно сложная программная система, затрагивающая все аспекты,связанные с движением товара на склад и со склада.
Для хранения продукциислужит, естественно, реальный склад, однако именно программа является егодушой, без которой он потеряет свою функцию эффективного центрараспределения.При разработке такой системы заказчикам необходимо частичнопереосмыслить весь бизнес-процесс и учесть уже имеющиеся программы,чтобы не потерять вложенные средства (см. главу 7). И хотя некотороеулучшение производительности ведения дел в компании может бытьдостигнуто просто за счет автоматизации уже существующей системы учетатоваров "вручную", радикального улучшения можно добиться только прикардинальном пересмотре ведения бизнеса. Вопросы реинжениринга связаныс системным планированием и выходят за рамки нашей книги. Однако, так жекак архитектура системы определяет ее реализацию, общее видение бизнесаопределяет всю систему.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
