Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (1158635), страница 76
Текст из файла (страница 76)
Мы, однакоразделили эти два типа абстракций, так как они будут играть несколькоразные роли.Заметим, что существуют два вида счетов: те, которые посылаются компаниейклиентам для оплаты заказанного товара, и те, которые компания получает отпоставщиков товаров. Не отличаясь ничем по своей структуре, они, тем неменее, играют совершенно разные роли в системе.По классам Packingorder и StockingOrder потребуются некоторыедополнительные разъяснения. В соответствии с первыми двумя сценариями,после того, как сотрудник отдела продаж (OrderAgent) принимает заказ (order)от клиента (Customer), он должен дать указание кладовщику (StockPerson) навыдачу заказанного товара.
В нашей системе соответствующая транзакциясвязана с объектом класса Packingorder (расходная накладная). Этот классответственен за сбор всей информации, касающейся выписки расходнойнакладной по данному заказу. На операционном уровне это означает, что нашасистема формирует, а затем передает заказ на переносной компьютер одногоиз свободных в данный момент кладовщиков. Такая информация должна, какминимум, включать в себя идентификационный номер заказа, наименование иколичество каждого из товаров. Нетрудно догадаться, как можно намногоулучшить данный сценарий: наша система в состоянии передать кладовщикуместоположение товаров, и, возможно, даже примерную последовательностьвывоза их со склада, обеспечивающую максимальную эффективРис. 10-4.
Ключевые классы при приеме и выполнении заказаность этой операции. 32 В нашей системе достаточно информации, чтобыобеспечить помощь недавно принятому на работу кладовщику - например,дать ему возможность вывести на экран своего переносного компьютераизображение внешнего вида того или иного товара. Такая поддержка можетпригодиться и опытному кладовщику на период смены ассортимента товаров.Рис. 10-4 содержит диаграмму классов, которая отражает нашепонимание процесса взаимодействия некоторых из перечисленных абстракцийв сценарии приема и выполнения заказа. Мы дополнили эту диаграммунекоторыми украшениями атрибутов, играющих важную роль вфункционировании каждого из классов.Основные мотивы введения именно такой структуры классов связаныс учетом перехода между экземплярами классов.
Получив заказ, мы быхотели, в частности, сформировать маркер, обозначающий клиента,сделавшего заказ; для этого необходимо перейти от экземпляра класса заказа(order) обратно к клиенту (customer). Получив расходную накладную, надовозвратиться к клиенту и к сотруднику отдела продаж для передачиинформации об отгрузке; это означает, что нам потребуется перейти отрасходной накладной к заказу, и затем от него - к клиенту и сотруднику отделапродаж.
Что касается клиента, то желательно знать, какие товары он чащевсего заказывает в то или иное время года. Для выполнении такого запросанеобходимо вернуться от клиента ко всем предыдущим его заказам.Стоит подробнее остановиться еще на некоторых деталях диаграммы.Почему между классом Order и классом PackingOrder существует отношение1:N (один ко многим)? По нашим бизнес-правилам каждая расходнаянакладная может соответствовать одному и только одному заказу. Однакообратное неверно. Предположим, например, что некоторые позиции,указанные в заказе, на данный момент отсутствуют на складе.
Тогда мыдолжны будем дополнительно отгрузить их по второй расходной накладной,когда товар появится в наличии.Отметим ограничение на связь между объектами StockPerson иPackingOrder:сохранение контроля за качеством работы требует, чтобы кладовщикодновременно обслуживал не более одного заказа.Завершая данный этап анализа, введем еще два ключевых класса:• Reportотчет• TransactionТранзакцияМы ввели абстракцию Report для обозначения базового класса,объединяющего все различные типы печатных документов ипользовательских запросов, При детальном анализе всех сценариев можетвыясниться много конкретных типов документов, но, ввиду открытости нашейсистемы, будет лучше выработать общий механизм генерации отчетов,позволяющий без труда добавлять новые типы отчетов. Действительно,выделив общие для всех отчетов свойства, мы сможем наделить их общимповедением и структурой, что позволит придать соответствующим элементамсистемы стандартизованный вид и облегчит для конечного пользователяработу с системой.Наш список далеко не полон, но у нас накопилось достаточноинформации для перехода к разработке архитектуры системы.
Однако, дотого, необходимо рассмотреть некоторые принципы, влияющие наорганизацию структур данных внутри программы.Модели баз данныхДэйт рассматривает базу данных как "вместилище хранимойинформации. Она, как правило, одновременно является и интегрированной, иобщедоступной. Под "интегрированностью" имеется в виду то, что базуданных можно представить как объединение нескольких отдельных файловданных, избыточность информации в которых частично или полностьюисключена... Под "общедоступностью" имеется в виду то, что информация,содержащаяся в базе, может одновременно использоваться сразу несколькимипользователями" [7].
При централизованном управлении базой данных можно"устранять несоответствия, устанавливать стандарты, накладыватьограничения на доступ к информации и поддерживать целостность базыданных" [8].Разработка эффективной базы данных является трудной задачей, таккак к ней предъявляется много взаимно противоречивых требований.Проектировщик должен учитывать не только функциональные требования кприложению, но также быстродействие и размер базы данных. Базы данных,неэффективные по быстродействию, оказываются, как правило,бесполезными. Системы, для реализации которых надо забить компьютерамивсе здание и нанять толпу администраторов для ее поддержки, неэффективныс точки зрения стоимости.Между разработкой базы данных и созданием объектноориентированного приложения существует много параллелей.Проектирование баз данных часто рассматривается как процесс итеративногоразвития, в ходе которого надо принимать решения, касающиеся какпрограммной логики, так и аппаратных аспектов [9].
Вёрковски и Кулуказывают на то, что "Объекты, описывающие базу данных в терминах,которыми оперируют пользователи и разработчики, называются логическими.Объекты, отображающие физическое расположение данных в системе,называются физическими" [10]. Разработчики баз данных в процессепроектирования, напоминающем объектно-ориентированное, постоянноперескакивают от рассмотрения логических объектов к обсуждениюфизических аспектов их реализации. Кроме того, описание элементов базыданных очень напоминает перечисление ключевых абстракций объектноориентированного приложения. Проектировщики баз данных частоиспользуют для анализа так называемые диаграммы "сущность-связь" (entityrelationship diagrams). Диаграммы классов, как мы видели, могут бытьорганизованы таким образом, что будут напрямую соответствоватьдиаграммам сущность-связь, но обладать при этом еще большейвыразительностью.Дэйт утверждает, что при проектировании любой базы данных нужнодать ответ на следующий вопрос: "Какие структуры данных исоответствующие им операторы должна поддерживать система?" [ 11 ].
Триразличные модели баз данных, перечисленные ниже, дают три различныхответа на этот вопрос:• иерархическая• сетевая• реляционная.Недавно появился четвертый тип, а именно объектноориентированные базы данных (ООСУБД). ООСУБД соединяюттрадиционную технологию проектирования баз данных с объектной моделью.Применение такого подхода оказалось достаточно полезным в таких областях,как компьютерное проектирование (САЕ) и разработка программ с помощьюкомпьютеров (CASE), где нам приходится манипулировать значительнымиобъемами данных с разнообразным семантическим содержанием.
Объектноориентированные базы данных могут дать для некоторых приложенийзначительный выигрыш в быстродействии по сравнению с традиционнымиреляционными базами данных. В частности, в случае наличия большогоколичества связей между таблицами, объектно-ориентированные базы данныхмогут работать значительно быстрее, чем реляционные. Более того, ООСУБДгарантируют согласованную "бесшовную" интеграцию данных и бизнесправил. Чтобы достичь той же семантики, в реляционных базах используютсложную систему триггеров, которые формируются с помощью языковпрограммирования третьего и четвертого поколений - модель, которую никакнельзя назвать ясной и понятной.Однако по ряду причин многие компании считают, что использованиереляционной базы данных в контексте объектно-ориентированнойархитектуры менее рискованно.
Технология реляционных баз данныхзначительно более зрелая, она реализована на широком спектре различныхплатформ и зачастую предлагает более полный набор средств защиты,контроля версий и поддержания целостности. Кроме того, компания, ужевложившая определенный капитал в кадры и в инструменты,поддерживающие реляционную модель, просто не может позволить себеизменить за одну ночь всю технологию работы.Реляционная модель весьма популярна. Принимая во внимание еебольшую распространенность, широкий набор программных продуктов, ееподдерживающих, а также тот факт, что она удовлетворяет функциональнымтребованиям к системе складского учета, мы выбрали именно ее.
Такимобразом, мы остановились на гибридном решении: построение объектноориентированной оболочки над традиционной реляционной базой ииспользование преимуществ обоих подходов. Рассмотрим вкратце некоторыеосновные принципы проектирования реляционных баз данных. Зная их, мылучше поймем, как создать объектно-ориентированную оболочку.Основными элементами реляционной базы данных являются"таблицы, в которых столбцы представляют собой предметы и их атрибуты, астроки описывают отдельные экземпляры предметов...
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
