Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (1158635), страница 75
Текст из файла (страница 75)
К немуподключаются несколько клиентов. Конкретный компьютер, на которомработает пользователь, не имеет для сервера никакого значения. Такимобразом, наше приложение должно работать на любом компьютере сети, ивнедрение новых аппаратных технологий будет оказывать минимальноевлияние на функционирование системы.Архитектура клиент-серверХотя данный раздел и не является подробным обзором архитектурыклиент-сервер, некоторые замечания по этой теме необходимо сделать, так какони напрямую относятся к выбору архитектурных решений для нашейсистемы.Что можно отнести к категории клиент-сервер, а что нет, до сих порявляется предметом жарких дискуссий.29 В нашем случае будет достаточноопределения решений на базе клиент-сервер как "децентрализованнойархитектуры, позволяющей конечным пользователям получатьгарантированный доступ к информации в разнородной аппаратной ипрограммной среде.
Приложения клиент-сервер сочетают пользовательскийграфический интерфейс клиента с реляционной базой данных, расположеннойна сервере" [2]. Структура таких приложений подразумевает возможностьсовместной работы пользователей; при этом ответственность за выполнениетех или иных функций ложится на различные, независимые друг от другаэлементы открытой распределенной среды. Берсон далее утверждает, чтоприложение клиент-сервер обычно можно разделить на четыре компонента:• Логика представленияЧасть приложения, обеспечивающаясвязь с инструментами конечного пользователя. Таким инструментом можетбыть терминал, считыватель штрих-кодов или переносной компьютер.Включает функции: формирование изображения, ввод и вывод информации,управление окнами, поддержка клавиатуры и мыши.• Бизнес-логикаЧасть приложения, использующаяинформацию, вводимую пользователем, и информацию, содержащуюся в базеданных, для выполнения транзакций, удовлетворяющих бизнес-правилам.• Логика базы данныхЧасть приложения, "манипулирующаяданными приложения...
В реляционной базе данных подобные действияобеспечиваются с помощью языка SQL" (SQL, Structured Query Language, языкструктурированных запросов).• Механизмы обращения"Непосредственная работа с базойданных, к базе данныхвыполняемая СУБД... В идеальном случаемеханизмы СУБД прозрачны для бизнес-логики приложения" [З].Один из основных вопросов при проектировании архитектурысистемы состоит в оптимальном распределении узлов обработки в сети.Принятие решений здесь усложняется тем, что инструменты и стандарты дляархитектур клиент-сервер обновляются с ошеломляющей быстротой.Архитектор должен разобраться, например, с POSIX (Portable Operating SystemInterface, интерфейс переносимых операционных систем), OSI (Open SystemsInterconnection, связь открытых систем), CORBA (Common Object RequestBroker, единый брокер объектных запросов), объектно-ориентированнымрасширением языка SQL (SQL3), и рядом специальных решений фирмпоставщиков типа OLE (Object Linking and Embedding, связывание ивнедрение объектов) фирмы Microsoft.30Но на архитектурные решения оказывает влияние не только обилиестандартов.
Имеют значение и такие вопросы, как защита данных,производительность системы и ее объем. Берсон предлагает архитекторунесколько основных правил проектирования приложении клиент-сервер:• Компонент логики представления обычно устанавливается там же,где и терминал ввода-вывода, то есть на компьютере конечного пользователя.• Учитывая возросшую мощность рабочих станций, а также тот факт,что логика представления установлена на машине клиента, имеет смысл тамже разместить и некоторую часть бизнес-логики.• Если механизмы обращения к базе данных связаны с бизнес-логикой,и если клиенты поддерживают некоторое взаимодействие низкого уровня иквазистатические данные, то механизмы обращения к базе данных можнотакже разместить на стороне клиента.• Принимая во внимание тот факт, что сетевые пользователи обычноорганизованы в рабочие группы, и что рабочая группа совместно используетбазу данных, фрагменты бизнес-логики и механизмов обращения к базеданных, которые являются общими, и сама СУБД должны находиться насервере [4].Если нам удастся выбрать верные архитектурные решения и успешнореализовать их тактические детали, модель клиент-сервер даст системе целыйряд преимуществ.
Берсон особо выделяет, что архитектура клиент-сервер:• Позволяет более эффективно использовать новые компьютерныетехнологии автоматизации.• Позволяет перенести обработку данных ближе к клиенту, чтоснижает загрузку сети и уменьшает продолжительность транзакций.• Облегчает использование графических интерфейсов пользователя,которые стали доступны на мощных современных рабочих станциях.• Облегчает переход к открытым системам [5]. Надо выделить, однако,следующие моменты риска:• Если значительная часть логики приложения окажется вынесенной насервер, то последний может стать узким местом системы, замедляющимработу пользователей (как это часто бывало при использовании мэйнфреймовв архитектуре хозяин-раб).• Распределенные приложения ...
сложнее нераспределенных [б].Мы уменьшим этот риск, используя объектно-ориентированныйподход к разработке.Сценарии работыСейчас, когда мы представили себе систему в целом, продолжим нашанализ и изучим несколько сценариев ее работы. Сначала перечислим рядосновных режимов использования:• Клиент звонит по телефону в удаленную телемаркетинговуюорганизацию, чтобы сделать заказ.• Клиент посылает заказ по почте.• Клиент звонит, чтобы узнать состояние дел по его заказу.• Клиент звонит, чтобы добавить или убрать некоторые позиции иззаказа.• Кладовщик получает указание отгрузить клиенту необходимоеколичество товара.• Служба доставки получает со склада заказанные клиентом товары иготовит их к отправке.• Бухгалтерия готовит счет для клиента.• Отдел закупок готовит заказ на новый товар.• Отдел закупок добавляет или удаляет имя поставщика из списка.• Отдел закупок запрашивает поставщика о состоянии заказа.• Отдел приема товара принимает груз от поставщика и проверяет егосоответствие заказу.• Кладовщик заносит новый товар в список.• Бухгалтерия отмечает прибытие нового товара.• Плановый отдел генерирует отчет о показателях продаж поразличным типам продуктов.• Плановый отдел генерирует отчет для налоговых органов суказанием количества товаров на складах.Каждый из основных сценариев может включать в себя рядвторичных:• Заказанного клиентом товара нет на складе.• Заказ клиента неверно оформлен, или в нем присутствуютнесуществующие или устаревшие идентификаторы товаров.• Клиент звонит, чтобы проверить состояние заказа, но не помнитточно что, кем и когда было заказано.• Кладовщик получил расходную накладную, но некоторыеперечисленные в ней товары не нашлись.• Служба доставки получает заказанные клиентом товары, но они несоответствуют заказу.• Клиент не заплатил по счету.• Отдел закупок делает новый заказ, но поставщик либо ушел избизнеса, либо больше не поставляет заказанный тип товара.•Отдел приема товара принимает груз, не полностью соответствующий заказу.•Кладовщик хочет разместить на складе новый товар, но обнаруживается, что длянего нет места.•Изменяются налоговые коды, что вынуждает плановый отдел составить новыйинвентаризационный список находящихся на складе товаров.Для системы такой сложности, наверно, будут выявлены десятки основныхсценариев и еще большее количество вторичных.
Этот этап анализа можетзанять несколько недель, пока не удастся добиться более или менееподробного уровня детализации.31 Поэтому мы настоятельно советуемприменять правило восьмидесяти процентов: не ждите, пока сформируетсяполный список всех сценариев (никакого времени на это не хватит), изучитеоколо 80% наиболее интересных из них и, если возможно, попытайтесь хотябы оценочно проверить правильность общей концепции. В этой главе мыподробно остановимся на двух основных сценариях.На рис. 10-2 представлен сценарий, в котором покупатель размещает свойзаказ в телемаркетинговой фирме. В выполнении этой системной функциизадействовано несколько различных объектов.
И хотя управлениеосуществляется взаимодействием клиента (aCustomer) с агентом (anAgent),есть и другие ключевые объекты, а именно: сведения о клиенте(aCustomerRecord), база данных о товарах (inventoryDatabase) и заявка накомплектование (aPackingOrder), являющиесяРис. 10-2. Сценарий заказаРис. 10-3.
Сценарий выполнения заказаабстракциями системы складского учета. Этот список абстракцийформируется как раз на этапе рассмотрения сценариев работы.Рис. 10-3 отражает продолжение данного сценария. На нем представленасхема взаимодействия кладовщика и расходной накладной. Мы видим, чтоздесь кладовщик является главной фигурой. Он взаимодействует с другимиобъектами, например с отгрузкой (shipping), которой не было в предыдущемсценарии. Однако большинство объектов, фигурирующих на рис. 10-3,присутствуют также и на рис. 10-2, хотя они играют в этих сценарияхразличные роли. Например, в сценарии взаимодействия с клиентом мысоздаем заказ (anOrder) как документ, в котором отражены требованияклиента.
В складском сценарии тот же самый заказ исполняется.При составлении каждого из таких сценариев мы должны постоянно задаватьсебе ряд вопросов. Какой объект будет нести ответственность за выполнениетого или иного действия? Как объект будет проводить ту или иную операцию:самостоятельно или используя свойства другого объекта? Не слишком лимного операций вменяется в круг обязанностей данного объекта? Чтопроизойдет при ошибке в ходе выполнения сценария (какие постусловиямогут нарушиться)? Что случится, если будут нарушены некоторыепредусловия?Занимаясь подобным антропоморфизмом для каждого функциональногосвойства системы, мы откроем в системе целый ряд интересных объектоввысокого уровня. Сначала перечислим лиц, взаимодействующих с системой:• Customerклиент• Supplierпоставщик• OrderAgentсотрудник отдела продаж• Accountantбухгалтер• ShippingAgentсотрудник отдела отгрузки• Stockpersonкладовщик• PurchasingAgentсотрудник отдела закупок• ReceivingAgentсотрудник отдела приема товаров• Plannerсотрудник планового отделаДля нас очень важно выявить эти категории лиц: каждой из них соответствуетсвоя отдельная роль в сценариях.
Если мы хотим отслеживать, когда и почемупроизошли определенные события внутри системы и кто стал их причиной, тонеобходимо формализовать роли всех пользователей. Например, прирассмотрении жалобы нам возможно придется выяснить, кто вел переговоры снедовольным клиентом. Кроме того, нам понадобится эта классификация приразработке механизма ограничения доступа к различным частям системы дляразличных групп пользователей. В открытой системе централизованныйконтроль вполне эффективен и неизбежен: он уменьшает риск случайного илицеленаправленного неправильного использования.В результате анализа был выделен ряд ключевых абстракций, каждая изкоторых представляет собой определенный тип информации в системе:• CustomerRecordинформация о клиенте• ProductRecordинформация о товаре• SupplierRecordинформация о поставщике• Orderзаказ от клиента• PurchaseOrderзаказ поставщику• Invoiceсчет• PackingOrderрасходная накладная• StockingOrderприходная накладная• ShippingLabelдокумент на отгрузкуКлассы CustomerRecord, ProductRecord И SupplierRecord связанысоответственно с абстракциями Customer, Product и Supplier.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
