И. Соммервилл - Инженерия программного обеспечения (1133538), страница 62
Текст из файла (страница 62)
Служба имен является сервисом каталогов. который присваивает имена объектам. При необходимости объекты через эту службу могут находить идентификаторы 1ОК других объектов. 2. Служба регистрации, которая позволяет объектам регистрировать другие объекты после совершения некоторых событий. С помощью этой службы объекты можно регистрировать по их участию в определенном событии, а когда данное событие уже произошло, оно автоматически регистрируется сервисом. 3.
Служба транзакций, которая поддерживает элементарные транзакции и откат назад в случае ошибок или сбоев. Эта служба является отказоустойчивым средством (см. главу 18), обеспечивающим восстановление в случае ошибок во время операции обновления. Если действия по обновлению объекта приведуг к ошибкам или сбою системы, данный объект всегда можно вернуть назад к тому состоянию, которое было перед началом обновления.
Считается, что стандарты СОкВА должны содержать определения интерфейсов для широкого диапазона компонентов, которые мокнут использоваться при построении распределенных приложений. Эти компоненты могут быть вертикальными или горизонтальными. Вертикальные компоненты разрабатываются специально для конкретных прило. жсний. Как уже отмечалось, разработкой определений этих компонентов занято мцожс.
ство специалистов из различных сфер делтельности. Горизонтальные компоненты универсальны, например компоненты пользовательского интерфейса. Во время написания этой книги спецификации компонентов были уже разработаны, на еще не согласованы. С моей точки зрения, вероятна, именна здесь наиболее слабое место стаьщартов СОЕВА, и, возможно, потребуется несколько лет, чтобы достичь тога, чта в наличии будут и спецификации, и реализации компонентов. 242 Часть ТП. Проектирование КЛЮЧЕВЫЕ ПОНЯТИЯ .:,, - - 'х,",."чь?ььг~~?4Гл'.'4~!Ьлбкя,'Хчьеьяь ° ' Все современные больший системы в той или ийой стейенй являются' расчпределвшгыми,' в кото; ', рых программные компоненты выполняются на интегрированной в сеть группе процессоров.; .: ° Распределенным системам присущи следующие черты: совместное испольгэование.ресурсов, от- ' крыпють, параллельность, масштабируемость, устойчивость к ошибкам и прозрачность.
° Системы клиент/сервер являются распределенными. Такие системы моделируются как набор сервисов, предоставляемых сервером клиентским процессам'. ° В системе клиент/сервер,'-'интерфейсспользоватвля всегда 'запускается;йа""'стЬбоне клиейта,':,:а" управление данными всегда падпержйвается на разделяемом сервейер:фикции прилоляящя могут'" быть реализованы на клиентском?компьютере или на сераерв..-'-'" ~~'.'"«.'-:~!Фй;:,'Где~!,"-'-:.': ~'"'':г ",-:„'-'";-;: ° В архитектуре распределенньа обьектов нет различий между 'хгпиентамии-„'ИМервервхтй:.06ъемты предоставляют основные сервисы, которые могут вйзывзть другие обяектьь'*Такой,гкв подход. можно использовать в реализации систем клиент/сервер. ° В системах распределенных обьектов должно быть протшжуточное программное обеспечение, :" предназначенное для обработки взаимодействий между обьектамиг а также добавления или уда.
ленив обьектов из системы, Концептуалыю промежуточное ПО можно представить как программнуюшину,ккоторой'подключеныобъекты.:" '.',,',"'"",";, .';,"':"'::*':-'',"".:.т „" "":-":-" — "'4 .- ° ' ' СтаНдартЫ СОЙВА'ПрЕдотаВЛявт'Ссбей Набср"СтаНдартса'дыятя"ПбеывжухтГйаВ'ПО,'йечддЕржйщтш'-.Р щего архитектуру распределенных обьектов. К ним относятся определения'модели 'объектай гбргйч кера запросов к объектам и обще сервисов. В настоящее ерема существует несколькс реализа--; , ций стандартов СОВВ/ь Упражнения 11.1, Объясните, почему распределенные системы всегда более масштабируемы, чем централизованные.
Какой вероятный предел масштабируемости программных систем? 11.2. В чем основное отличие между моделями толстого и тонкого клиента в разработке систем клиент/сервер? Объясните, почему использование 4ача как языка реализации сглшкивает различия между этими моделями? 11.3. На основе модели приложения, изображенной на рис. 11.4, рассмотрите возможные проблемы, которые могут возникнуть прн преобразовании системы 1980-х годов, реализованной на мейнфрейме н предназначенной для работы в сфере здравоохранения, в систему архитектуры клиент/сервер. 11.4.
Распределенные системы, базирующиеся на модели клиент/сервер, разрабатывались с 1980-х го. дов, но только недавно такие системы, основанные на распределенных объектах, были реализованы, Приведите три причины, почему так получнлссь. 11.5. Объясните, почему использование распределенных объектов совместно с брокером запросов к объектам упрощает реализацию масштабируемых систем клиент/сервер. Проиллюстрируйте свой ответ примером. 11,6, Каким образом используется язык 1ОЕ для поддержки взаимодействия между объектами, реализо. ванными на разных языках программирования? Объясните, почему такой подход может вызвать проблемы, связанные с производительностью, если между языками, которые используются при реализации объектов, имеются радикальные различия.
11.7, Какие базовые средства должен предоставлять брокер запросов к обьектэм? 1!.8. Можно показать, что разработка стандартов СОВВА для горизонтальных и вертикальных компонен. тов ограничивает конкуренцию. Если они уже созданы и адаптированы, зто препятствует разработке лучших компонентов более мелкими компаниями. Обсудите роль стандартизации в поддержке или ограничении конкуренции нв рынке программного обеспечения. 1ы 'Ф~т ъч , '.!.'.ц1 ь* ' Объектноориентированное проектирование Цель настоящей главы — познакомить с подходом к проектированию программного обеспеченил, в ко тором система представляется в виде взаимодейст вующих объектов.
Прочитав зту главу, вы должны: знать, что структуру программы можно предста вить в виде совокупности взаимодействующих объектов, управляющих собственным состояни. ем и операциями; иметь представление об основных этапах процесса объектно.орие~п ированного проектирования; понимать различные модели, которые использу ются придокументировании объектно.ориентиро ванной структуры; познакомиться с представлением этих ьюдслей с помощью (5МЦ 12.1. Объекты н классы объектов 12.2. Процесс объекгно.ориентированного проекги рования 12.З. Модификация системной архитектуры 244 х1асть П1. Проектирование Объектно.ориентированное проектирование представляет собой стратегию, в рамках которой разработчики системы вместо операций и функций мыслят в понятиях пбггкшьь Программная система состоит из взаимодействуюгцих объектов, которые имеют собст венное локальное состояние и могут выполнять определенный набор операций, определяемый сосгояннем объекта (рис.
12.1). Объекты скрывают информацию о представлении состояний и, следовательно, ограничивают к ним доступ. Под процессом объектноориентированного проектирования подразумевается проектирование классов объектов и взаимоотношений между этими классами. Когда проект реализован в виде исполняемой программы, все необходимыс объекты создаются динамически с помощью определений классов. г".кс. 12.1. Сигэмма взпимодешэмуюггилобггхэкм Объектно.
ориентированное проектирование — только часть обаекжноо)имнэяграгпннпгп процесса рпгрпбомки пгспммьь где на протяжении всего процесса создания ПО используется объектно-ориентированный подход. Этот подход подразумевает выполнение трек этапов. ° Обмхжно~фкгпэгирогпннмк пнпгкг. Создание объектно. ориентированной модели предметной области приложения ПО. Здесь объекты отражают реальные объекты. сущности, также определяются операции, выполняемые объектами. ° Обыктнэпригптирпгпняог проектирование.
Разработка объектноориентированной модели системы ПО (системной архитектуры) с учетом системных требований. В объектно. ориентированной модели определение всех объектов подчинено решению конкретной задачи. ° Обммтпппригкпшровпняге программирование. Реализация архитекгуры (модели) системы с помощью объектно-ориентированного языка программирования. Такие языки, например )ага, непосредственно выполняют реализацию определенных объектов и предоставляют средства для определения классов объектов.
Данные этапы мойт "перетекать" друг в друга, т.е. но~ус не иметь четких рамок, причем иа каждом этапе обычно применяется одна и та же система нотации. Переход на еле. дующий этап приводит к усовершенствованию результатов предыдущего этапа путем более детального описанил определенных ранее классов объектов и определения новых классов.
Так как данные скрыты внутри объектов, детальные решения о предсгавлении данных можно отложить до этапа реализации системы. В некоторых случаях можно также не спешить с принятием решений о расположении объектов и о том, будут ли зти объекты последовательными нли параллельными. Все сказанное означает, что разработчики ПО нс стеснены деталями реализации системы. 12. Объектно ориентированное проектирование 245 Объектно.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
