|
Читайте также: |
Объект обладает состоянием, поведением и идентичностью; структура и поведение схожих объектов определяет общий для них класс; термины «экземпляр класса» и «объект» взаимозаменяемы.
Состояние объекта характеризуется перечнем всех свойств данного объекта и текущими значениями каждого из этих свойств.
Поведение – это то, как объект действует и реагирует; поведение выражается в терминах состояния объекта и передачи сообщений.
В объектно-ориентированных языках операции, выполняемые над данным объектом, называются методами и входят в определение класса объекта. (В C++ они называются функциями-членами.)
Операции.
Операция – это услуга, которую класс может предоставить своим клиентам.
На практике типичный клиент совершает над объектами операции пяти видов:
Две последние операции являются универсальными; они обеспечивают инфраструктуру, необходимую для создания и уничтожения экземпляров класса.
Идентичность – это такое свойство объекта, которое отличает его от всех других объектов
Класс – это некое множество объектов, имеющих общую структуру и общее поведение.
По своей природе, класс – это генеральный контракт между абстракцией и всеми ее клиентами. Выразителем обязательств класса служит его интерфейс, причем в языках с сильной типизацией потенциальные нарушения контракта можно обнаружить уже на стадии компиляции.
Измерение качества абстракции
Для построения системы должен использоваться минимальный набор неизменяемых компонент; сами компоненты должны быть по возможности стандартизованы и рассматриваться в рамках единой модели. Применительно к объектно-ориентированному проектированию такими компонентами являются классы и объекты, отражающие ключевые абстракции системы, а единство обеспечивается соответствующими механизмами реализации.
Опыт показывает, что процесс выделения классов и объектов является последовательным, итеративным. За исключением самых простых задач с первого раза не удается окончательно выделить и описать классы. Очевидно, такой процесс связан с дополнительными затратами на перекомпиляцию, согласование и внесение изменений в проект системы. Очень важно, следовательно, с самого начала по возможности приблизиться к правильным решениям, чтобы сократить число последующих шагов приближения к истине. Для оценки качества классов и объектов, выделяемых в системе, можно предложить следующие пять критериев:
Зацепление – это степень глубины связей между отдельными модулями.
Систему с сильной зависимостью между модулями гораздо сложнее воспринимать и модифицировать. Сложность системы может быть уменьшена путем уменьшения зацепления между отдельными модулями.
Кроме зацепления между модулями в объектно-ориентированном анализе, существенно зацепление между классами и объектами. Существует определенное противоречие между явлениями зацепления и наследования. С одной стороны, желательно избегать сильного зацепления классов; с другой стороны, механизм наследования, тесно связывающий подклассы с суперклассами, помогает выгодно использовать сходство абстракций.
Связность – это степень взаимодействия между элементами отдельного модуля (класса или объекта), характеристика его насыщенности.
Наименее желательной является связность по случайному принципу, когда в одном классе или модуле собираются совершенно независимые абстракции. Наиболее желательной является функциональная связность, при которой все элементы класса или модуля тесно взаимодействуют в достижении определенной цели.
К идеям зацепления и связности тесно примыкают понятия достаточности, полноты и примитивности.
Под достаточностью подразумевается наличие в классе или модуле всего необходимого для реализации логичного и эффективного поведения. Иначе говоря, компоненты должны быть полностью пригодны к использованию.
Для примера рассмотрим класс set (множество). Операция удаления элемента из множества в этом классе, очевидно, необходима, но будет ошибкой не включить в этот класс и операцию добавления элемента. Нарушение требования достаточности обнаруживается очень быстро, как только создается клиент, использующий абстракцию.
Полнота – это наличие в интерфейсной части класса всех характеристик абстракции.
Идея достаточности предъявляет к интерфейсу минимальные требования, а идея полноты охватывает все аспекты абстракции.
Полнотой характеризуется такой класс или модуль, интерфейс которого гарантирует все для взаимодействия с пользователями.
Полнота является субъективным фактором, и разработчики часто ею злоупотребляют, вынося на верх такие операции, которые можно реализовать на более низком уровне. Из этого вытекает требование примитивности.
Примитивными являются только такие операции, которые требуют доступа к внутренней реализации абстракции.
Так, в примере с классом set операция Add (добавление к множеству элемента) примитивна, а операция добавления четырех элементов не будет примитивной, так как вполне эффективно реализуется через операцию добавления одного элемента. Конечно, эффективность тоже вещь субъективная. Операция, которая требует прямого доступа к структуре данных, примитивна по определению. Операция, которая может быть описана в терминах существующих примитивных операций, но ценой значительно больших вычислительных затрат, также является кандидатом на включение в разряд примитивных [Примером может служить операция добавления к множеству произвольного числа элементов (а не обязательно четырех). – Примеч. Ред.].
Выводы
3. Лекция 3. Распределённое взаимодействие. Распределённые системы. Распределённые объекты.
3.1. Основные определения и положения распределённых систем
Распределённая система – это система, составные части которой могут быть пространственно или логически распределены.
Примером пространственно распределённых систем является системы типа клиент-сервер, где приложение клиент и сервер СУБД выполняются на физически разных компьютерах, объединённых локальной сетью.
Примером логически распределённых систем может быть та же система клиент-сервер, но в которой оба приложения (и клиентская часть и сервер СУБД) выполняются на одном и том же физическом компьютере.
Существует ряд задач, для решения которых традиционным считается целесообразным построение распределённых систем:
Последнее время внимание акцентируется на понятие виртуализации вычислительных ресурсов и системной конвергенции – подхода, при котором система предоставляет пользователям некий, оговоренный соглашением набор ресурсов или услуг, при этом пользователь (а это может быть и другая система) как можно больше абстрагируется от механизма их реализации, местонахождения и т.п.
Вышеперечисленные задачи решаются уже на протяжении длительного периода. Существует широкий спектр различных подходов для их решения, в той или иной мере подходящий для конкретного случая. К сожалению, до сих пор принципиально не существует универсального метода, удовлетворяющего всем критериям и задачам, откуда следует что системному архитектору требуется выбрать хотя и не идеальное, но наиболее подходящее для каждого конкретного случая решение.
Причиной этого является взаимоисключающая природа ограничений, накладываемых при реализации того или иного решения. Например, обеспечение максимальной прозрачности практически всегда приводит к усложнению системы и значительному падению производительности.
Вообще степень прозрачности можно определить как степень сокрытия от пользователя деталей обеспечения доступа к ресурсу (например, сокрытие факта географической распределённости).
Обеспечение многопользовательского доступа, особенно в географически распределённых системах ставит целый ряд задач, основной из которых является поиск компромисса между степенью параллелизма доступа к данным и вероятностью нахождения или приведения системы или данных в нецелостное состояние. Сюда же добавляется и проблема масштабируемости. Так, одним из механизмов обеспечения совместной работы над неким подмножеством данных является механизм блокировок. Различают:
Разделяемая блокировка может удерживаться сразу несколькими активными субъектами, при этом ни один субъект не имеет право повысить уровень блокировки до монопольной.
Монопольная блокировка на доступ к объекту может удерживаться лишь одним субъектом в каждый момент времени.
Примерами разделяемой и монопольной блокировок служат одновременное открытие файла несколькими пользователями только для чтения и открытие файла только одним пользователем для изменения.
Для обеспечения целостности состояния систем используется механизм транзакций. В общем случае транзакция – это факт перевода системы из одного целостного и корректного с т. Зрения бизнес-логики состояния в другое. При этом в процессе выполнения транзакции система может временно оказываться в нецелостном состоянии, однако это никак не должно сказываться на параллельно работающих пользователях. Для этих целей транзакции выполняются изолированно друг от друга.
Для обеспечения распределённой работы широко применяются следующие подходы:
Каждый из перечисленных подходов обладает своими достоинствами и недостатками. Так, например, сокеты, как правило, способны обеспечить наилучшую производительность с т.з. времени отклика, и не требуют дополнительной инфраструктуры, однако их использование оказывается трудоёмким (крайне низкая степень прозрачности), и к тому же плохо масштабируемым; удалённые процедуры способны создать некую иллюзию локальности (обладают высокой степенью прозрачности), однако сильная связь по интерфейсам делает систему малоустойчивой относительно изменений, тем самым резко ограничивая гибкость системы; системы распределённых объектов, обладая, пожалуй, максимальной прозрачностью, требуют значительной инфраструктуры для своей работы, как то – сервисы обнаружения, безопасности, перенаправления и т.п.; системы передачи сообщений набирают всё большую популярность ввиду максимальной гибкости и масштабируемости, однако их природа принципиально ограничивает взаимодействие асинхронным способом, хотя, разумеется, можно эмулировать синхронное взаимодействие – такая эмуляция оказывается зачастую низко производительной.
Из рассмотренных примеров видно, что не существует «серебряной пули» - способа обладающего наилучшими показателями для всех случаев.
В данном случае полезно рассматривать понятие связанности системы, т.е. насколько тесной оказывается связь между отдельными компонентами системы. Связанность можно оценивать интенсивностью взаимодействия, например объемом пересылаемых данных между компонентами или частотой связи, или же максимально допустимым временем запаздывания обновления. Если эти показатели оказываются незначительными – имеет смысл рассмотреть асинхронные способы взаимодейстия, обеспечивающие наибольшую гибкость и масштабируемость, как например обмен сообщениями. Если же связь между компонентами оказывается достаточно сильной – имеет смысл рассмотреть более тесные способы взаимодействия – сокеты, распределённые объекты и удалённый вызов процедур.
Для передачи данных и структур, находящихся в оперативной памяти через вычислительную сеть, эти данные и структуры (графы объектов) должны быть преобразованы в поток байт. А для работы с такими данными на принимающем конце они должны быть преобразованы обратно в структуры данных и объекты. Эты две процедуры называются маршалинг и демаршалинг соответственно.
Маршалинг – преобразование данных из структуры памяти в поток байт.
Демаршалинг (или анмаршалинг) – обратное преобразование потока байт в структуру данных в памяти.
В ООП и в языке Java (и.технологии.Net) эти процедуры, применительно к объектам называются сериализация и десериализация соответственно [1].
Лекция 4
Программное обеспечение промежуточного слоя (middleware)
Для повышения степени прозрачности взаимодействия между различными частями распределённой системы вводят понятие программного обеспечения промежуточного слоя (middleware). В общем, ПО промежуточного слоя можно определить как набор компонент предоставляющих типичный набор сервисов для компонент системы реализующих бизнес-логику. Как правило, типичный набор служб промежуточного слоя состоит из [7]:
Программное обеспечение промежуточного слоя работает, как правило, поверх гетерогенных компьютерных сетей состоящих из нескольких ЭВМ каждая из которых независимо управляется сетевой операционной системой. При таком подходе ПО промежуточного уровня интенсивно использует службы сетевой ОС для того чтобы реализовать вышеуказанные службы своим клиентам, но уже на более высоком уровне абстракции.
В то время как службы сохранения (persistence), распределённых транзакций и безопасности присутствуют не во всех ПО промежуточного слоя, абсолютно все включают службы связи и почти все включают службы именования и обнаружения.
В качестве реализации служб связи чаще всего используются механизмы обмена сообщениями. Это обуславливается относительной их простотой и широкими возможностями. Так обмен сообщениями может быть:
Дополнительно к этому, службы обмена сообщениями могут поддерживать маршрутизацию сообщений и групповую рассылку. По своей природе службы обмена сообщений очень похожи на службы обмена e-mail по протоколу SMTP. При этом, в теле сообщения может находиться описание вызова метода, результат вызова метода, параметры вызова метода, некий документ, требующий какой либо обработки и т.п. Как правило службы обмена сообщениями не делают предположений о содержании сообщений.
Взаимодействие построенное на основе обмена сообщениями обладает по мимо неоспоримых достоинств и рядом существенных недостатков. К ним относятся:
Исходя из этого, выбирая в качестве механизма взаимодействия механизм сообщений следует максимально чётко представлять себе его недостатки, и, там где это возможно попытаться отказаться от таких тяжеловесных решений как гарантированная доставка, формат XML и т.п. В то же время, если производительность и масштабируемость системы (или конкретной подсистемы) не является критичным фактором, следует всё таки склоняться в сторону более открытых решений, имея ввиду использование форматов сообщений основанных на XML в противовес закрытым бинарным форматам, хоть и обеспечивающим максимальную производительность, оставляющих мало шансов на взаимодействие с другими системами и службами связи и обработки.
В технологии Java службой, предоставляющей связь на основе передачи сообщений является JMS (Java Message Service)[8]. Это специфицированный набор API определяющий сервисы по предоставлению услуг обмена сообщениями в двух моделях:
Модель Publish-Subscribe предполагает наличие нескольких потребителей, привязанных к одной очереди сообщений и одного или более производителей, публикующих сообщения в эту очередь. При этом КАЖДЫЙ потребитель получит копию сообщения.
Модель peer-to-peer предполагает наличие очереди, из которой сообщение доставляется ЛЮБОМУ готовому подписчику (их может быть больше одного), при этом сообщение получит только ОДИН из подписчиков.
Реализация служб именования и обнаружения как правило представляется в виде распределённых или централизованных каталогов. Наиболее известным примером такой службы является DNS (Domain Naming System) [9,10]. Основной задачей такой службы является выработка и поддержание справочника глобальных имей и их соответствия ресурсам. Дополнительно может поддерживаться поиск по различным атрибутам, специфичным для доменной области. (Например, поиск людей не только по первичному и уникальному ключу, которым в пределах государства является номер и серия паспорта, но в дополнение к этому поиск по имени и фамилии, которые вообще говоря не уникальны).
Наиболее широко применяемой службой каталога являются службы, построенные на основе протокола LDAP (Lightweight Directory Access Protocol) [11].
Кроме этого, в среде Windows широко используется служба Active Directory (которая так же может предоставлять свои услуги по протоколу LDAP). Другим примером может являться Novell NDS.
В среде Java используется служба JNDI (Java Naming and Directory Interface). Это набор интерфейсов, аналогичных LDAP позволяющих регистрировать и искать сервисы и компоненты в едином глобальном (в масштабе сервера JNDI) справочнике. Служба JNDI широко используется в повседневной практике программирования на J2EE при работе с такими ресурсами как Database Connection, DataSource, EJB. Например настроенный DataSource может быть зарегистрирован в службе JNDI сервера приложений, после чего он становиться доступным всем приложениям (в соответствии с заданной политикой безопасности) развёрнутым в контексте этого сервера через стандартный интерфейс JNDI. Этим достигается низкая привязанность к конкретной реализации DataSource.
Лекция 5
5.1. Типичные архитектуры распределённых систем
Client-Server (2-tier – двухзвенная архитектура)
Двухзвенная архитектура клиент-сервер является наиболее простой и понятной распределённой архитектурой. Её основной характеристикой является чёткое разделение ролей между компонентами, принимающими участие во взаимодействии на активных объектов (или субъектов) и пассивных (или целевых) объектов. Субъекты-клиенты могут инициировать взаимодействие с целевыми объектами-серверами. При этом, сервера могут так же выступать в роли клиентов по отношению к другим серверам. Например сервер приложений выступает клиентом по отношению к серверу баз данных.
Основным отличием двухзвенной архитектуры клиент сервер является выделение только двух чётко отделённых архитектурных слоёв. Как правило это бывает слой хранения данных (СУБД) и слой приложения клиента содержащего бизнес логику и логику отображения и взаимодействия с оператором, иными словами – пользовательский интерфейс.
Построение систем по принципу клиент-сервер принесло большие преимущества по сравнению с предшествующими на тот момент монолитными подходами. Главным из преимуществ является как правило чёткое отделение СУБД от кода клиентского приложения, тем самым позволяя использовать промышленные СУБД в многопользовательском режиме, совместно обрабатывать данные. Двухзвенные системы до сих пор широко применяются и показывают очень хорошие показатели в плане производительности системы а так же простоте проектирования, создания и развёртывания для небольшого числа пользователей. Существует широкий спектр интегрированных средств разработки двухзвенных приложений значительно удешевляющих разработку и создание ПО. Это такие средства как Borland Delphi/C++ Builder, MS Visual Studio, Sybase Power Builder и т.п.
Принципиальным недостатком двухзвенных систем является их ограниченная масштабируемость по количеству пользователей, по территориальной распределённости, а так же по сложности администрирования и защищённости. Так с увеличением количества рабочих мест пользователей резко возрастают затраты на их администрирование, так как при обновлении версии клиентского ПО приходиться обновлять копию ПО на каждом рабочем месте, а это при большом их числе и при относительно высокой частоте обновлений может оказаться неприемлемо дорого. Другой проблемой является проблема защищённости, так как каждый пользователь теоретически может получить доступ к БД в обход логики приложения, то возникает угроза компрометации данных в БД, что может оказаться решающим фактором.
Определённым шагом в направлении к полной многозвенной архитектуре можно назвать выделение и перенос части (иногда значительной) бизнес логики приложения на сервер БД в виде хранимых процедур. Такой подход позволяет более полно задействовать механизмы безопасности предоставляемы СУБД, позволяет упростить код клиентов и тем самым упростить их администрирование, однако всё же не решает вышеуказанных проблем полностью.
Дата добавления: 2015-10-24; просмотров: 115 | Нарушение авторских прав
| <== предыдущая страница | | | следующая страница ==> |
| Введение в UML. Краткая историческая справка. Диаграммы классов, диаграммы последовательностей. | | | Мобильные агенты (Applets and other mobile code) |