И. Соммервилл - Инженерия программного обеспечения (1133538), страница 63
Текст из файла (страница 63)
ориентированные системы можно рассматривать как совокупность авто. номных и в определенной мере независимых объектов. Изменение реализации какого- нибудь объекта или добавление новых функций не влияет на другие объекты системы. Часто существует четкое соответствие между реальными объектами (например, аппарат. ными средствами) и управляющими нми объектами программной системы. Такой подход облегчает понимание и реализацию проекта.
Потенциально все объекты являются повторно используемыми компонентами, так как они независимо инкапсулируют данные о состоянии и операции. Архитектуру ПО можно разрабатывать на базе объелтов, уже соэдаиньщ в предыдущих проектах. Такой подход снижает стоимость проектирования, програимирования и тестирования ПО. Кроме того, появляется возможность использовать стандартныс объекты, что уменьшает риск, связанный с разработкой программного обеспечения.
Однако, как показано в главе 14. ино. гда повторное использование эффективнее всего реализовать с помощью коллекций объектов (компонентов или объектных структур), а не через отдельные объекты. В книгах [74, 29гб, 186, 54, 137, 13ь, 32*, 34ь1 предлагаются различныс методы объектно.ориентированного проектирования. В этих методах ца протяжении всего процесса просктированил используется единообразная нотация, принлтая в ОМ!. )304). В лэшюй главе не предлагаются какие-либо особые методы проектирования, а рассматриваются лишь общие концепции объелтноориентированного просктированпл.
В разделе 12.2 рассмотрены этапы процесса проектирования. По всей главе используетгя система обозначений, принятая в ()М(.. 12.1. Объекты и классы объектов В цастояп1се время широко используются понятия ойеюл и абмтаяооркгнэшрованкыкъ Эти термины применяются к различным типам объектов, методам цроелтнроваиил, гистемаи и языкам программирования.
Во всех сл)чаях применяется общее правило, согласно которому объект инкапсулирует данные о своем внутреннем строении. Это правило отражено в моем определении объекта и класса объектов. Обьект — это нечто, способное пребывать в различных состояниях и имсюгнсг определенное множество операций. Состояние определяется как набор атрибутов объекта. Операции, связанные с объектом, предоставляют сервисы (функцнопальныс возможно. стн) другим объектам (клиентам) для выполнения определенных вычислений.
Объекты создаются в соответствии с определением класса объектов, которое сл~" жит шаблоном для создания объектов. В него включены объявления всех атрнбугов и операций, связанных с объектом данного класса. Нотация, которая используется здесь для обозначения классов объектов, определена в ()М1.. Класс объектов прсдсгавляется как прямоугольник с названием класса, разлелеппый на две секции.
В верхней секции перечислены атрибуты объектов. Операции, связанные с данным объектом, расположены в нижней секции. Пример такой нотации представлен на рнс. 12.2, где показан класс объектов, моделирующий глужащсго некой организации. В ()М1. термин опфавил является спецификацией некоторого действия, э термин летод обычно относится к реализации данной операции. Класс Работник определяется рядом атрибутов, в которых содержатся данные о сл)- жащих, в том числе их имена и адрес, коды социального обеспечения, налоговые коды и т.д. Конечно, на самом деле атрибутов, ассоциированных с классом, больше, чем изображено на рисунке. Определены также операшзи, связанные с объектами: принять (выпол- 246 т4асть Ш.
Проектирование нлстся при поступлении на работу), уволить (выполняется при увольнении служащего из органижщии), пенсия (выполнястся, если служащий становится пенсионером организа. ции) и измеиитьДаиные (выполняется в случаях, если требуется внести изменения в нмеющисса данные о работнике). Ркг. 12.2, Обрекл~ Рябзтккк Взаимодействие между объектами осуществляется посредством запросов к сервисам (вызов методов) нз других объектов и при необходимости путем обмена данными, требующимися для поддержки сервиса. Копии данных. необходимых для работы сервиса, и результаты работы сервиса передаются как параметры.
Вот несколько примеров такого стиля взаимодействия. // Вызов метода, ассоциированного с объектом Виббег (Буфер), //который возвращает следующее значение в буфер ч = сбгси1агпиг"тех.бес (); // Вызов метода, связанного с объектом с)зекщовсас (термостат), //который поддерживает нужную температуру спегщозсас.вестещр (20)г В некоторых распределенных системах взаимодействие между объектамн реализовано непосредственно в виде текстовых сообщений, которыми обмениваются объекты.
Объ. ект, получивший сообщение, выполняет его грамматический разбор, идентифицирует сервис и связанные с иим данные и запускает запрашиваемый сервис. Однако, если объекты сосуществуют в олной программе, вызовы методов реализованы аналогично вызовам процедур или функций в языках программирования, например таких, как С или Аба. Если запросы к ссрвису реализованы именно таким образом, взаимодействие между объектами синхронно.
Это означает, что объект, отправивший запрос к сервису, ожидает окончшпш выполпсшгя запроса. Однако, если объекты реализованы как параллельные 12. Объектно. ориентированное проектирование 247 процессы или потоки, взаимодействие объектов может быть асинхронным. Отправив запрос к сервису, объект может продолжить работу и нс ждать, пока сервис выполнит его запрос. Ниже в этом разделе показано, каким образом можно реализовать объекты как па. рзллельныс процессы.
Как отмечалось в главе 7, в которой описан ряд объектных моделей, классы объектов можно упорядочить или в виде иерархии обобщения или в виде иерархии наследования, которые показывают отношения между основными и частными классами объектов. Эти частные классы объектов полностью совместимы с основными классамн. но содержат больше информации.
В системе обозначений ОМ1. направление обобщения указывается стрелками, направленными на родительский класс. В объектно-ориентированных языках программирования обобщение обычно реализуется через механизм наследования. Производный класс (класс-потомок) наследует атрибуты и операции от родительского класса.
Пример такой иерархии изображен па рис. 12.Я, где показаны различные классы работников. К~ассы, расположенные внизу иерархии, имеют те же атрибуты и операции. что и родительские классы, но могут содержать новые атрибуты и операции или же изме нять имеющиеся в ролительских классах. Вели в модели используется имя родительского класса, значит, объект в системе может быть определен либо самим классом, либо любым иэ его потомков. Ркс. 12З. 11е(епрхил обоБщения На рис.
12.Я видно, что класс Менеджер обладает всеми атрибутами и операциямн класса Работник и, кроме того, имеет два новых атрибута: ресурсы, которыми управляет менеджер (бюджет), и дата назначения его на должность менеджера (двтаНазначения). Также добавлены повыс атрибуты в класс Программист. Один нз них определяет проект, нзд которым работает программист, другой характеризует уровень его профессионализма при испольэовшщи определенного языка программирования (языкПрогр). Таким обра. зом, объекты класса Менеджер н Программист можно использовать вместо объектов класса Работник. х48 <1асть П1. Проектирование Объекты, являющиеся членами класса объектов, взаимодействуют с другими объектами. Эти вэаимоотношсния моделируются с помощью описания связей (ассоциаций) между классами объсктов.
В УМ(. связь обозначастся линией, которая соединяет классы объектов, причем линия может быль снабжена информацией о данной свлзи. На рис. 12.4 показаны связи между объектами классов Работник и Отдел и между объсатами классов Работники Менеджер. Рис. 12.4. Модель а>я>п)< Связи представляют самыс общнс атнашсния и часто используются в 1>М(.
там, гдс трсбустся указать, что какос-то свойсгво объекта являстся связанным с объектом или жс рсаэнзацня метода объскта полагается на связанный объект. Однако в принципе тип свлзи мажет быть каким >годно. Одним из наиболее распространенных типов связи, который служит длл создания новых объектов из >жс имсющихся, являстся агрегирование. Этот тип связи рассмотрен в главе 7. 12.1.1. Параллельные объекты В общсм случас обьскты запрашивают ссрвис от любого объекта посредством передачи сму сообщспия "запрос к сервису".
Обычно нот необходимости в паслсдоватслыюм выполпснни, при котором один объект ожидает завершения работы ссрвиса по сделанном> запросу. Общая модель взаимодсйствия объектов позволяст их одноврсисннос вы. полнспис в видо парзллсльных процессов. Такис объекты могут выл<>лаяться на одном компьютере или па разных машинах как распрсдслснпыс объекты.
На практикс в большинстве объектно ориснтнрова>шых языков программирования по умолчанию реализована модель послсдоватсльного выполнения, в которой запросы к сор. внсам объектов и вызовы функций реализованы однии и тсм жс способом. Напримср, па языка )ага, когда объект, вызвавший объскт й>е(.>в( (Список), создастся из обычного класса объектов, эта эапшпстся так: с»еь1зс.арреас>(17> Здесь вызывается мстод еррепб (добавить), связанный с объектом й>е(эв1, который добаэляст элемент 17 в список 1>>е0в1, а выполнснис объекта, сдславщсга вызов, приостанавливастся до тсх пор, пока нс эавсршится опсрацня добавления. Однако в )ага сущсствуст очспь простой механизм потоков (<1<газ<>з), который позволяет создавать параллсльно выполнлющнсся объскты. Поэтому объектно-ориснтироваииую архитектуру программ. ной систсмы можно преобразовать так, чтобы объекты стали параллсльными процессами. Сущсствуст два типа параллсль ныл объектов.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
