Применение наследования при проектировании

Внутренние программные классы

Классы-обертки базы данных

Классы бизнес-логики

Классы интерфейса пользователя

Классы, скрывающие алгоритмы

Классы, зависящие от состояния

Классы интерфейса устройства

Классы абстрагирования данных

Проектирование операций классов

Проектирование классов, скрывающих информацию

Проектирование классов

На этом этапе проектируются скрывающие информацию классы, из которых со­здаются экземпляры пассивных объектов. Первоначально классы определяются на этапе построения аналитической модели в ходе разбиения системы на объек­ты и классы. Класс применяет сокрытие информации для решения различных вопросов, связанных со статической структурой, например сокрытия информации об устройстве или абстрагирования данных. Операции класса можно вывести как из статической, так и из динамической модели. Хотя статическая модель предназначена для отражения операций клас­сов, их проще выявить посредством анализа динамической модели – прежде все­го, диаграммы кооперации или последовательности. Ниже мы покажем, как опе­рации класса выводятся из модели кооперации, из описания конечного автомата и из статической модели, но основное внимание уделим модели кооперации.

Скрывающие информацию классы, проектируемые на этом этапе, подразде­ляются на категории в соответствии со стереотипом. Они документируются с по­мощью спецификаций интерфейсов.

. Кроме них существуют классы, зависящие от области решения; они проектируются позже по мере необходимости:

– сущностные классы, представленные в аналитической модели, служат для инкапсуляции данных. На диаграммах классов они помечаются стереоти­пом «сущность». Сущностные объекты – экземпляры сущностных клас­сов - обычно хранят в себе информацию и существуют в течение длительно­го времени.

– интерфейсные классы, реализующие интерфейс с внешней средой, можно разделить на следующие группы:

классы интерфейса устройства, взаимодействующие с устройствами вво­да/вывода;

классы интерфейса пользователя, осуществляющие человеко-машинный интерфейс;

классы интерфейса системы, общающиеся с внешней системой или под­системой;

– управляющие классы, координирующие совместную работу нескольких объектов, которые участвуют в прецеденте. Среди них можно выделить классы координации, классы, зависящие от состояния, и классы таймера.

– классы прикладной логики, инкапсулирующие особенности логики и алго­ритмов приложения, подразделяются на классы бизнес-логики и классы ал­горитмов;

– внутренние программные классы, скрывающие те решения проектировщи­ков, которые могут впоследствии измениться.

Опишем, как выявляются операции, предоставляемые классами. Хотя для отражения операций классов предназначена статическая модель, их про­ще выявить на основе анализа динамической модели, прежде всего из диаграммы кооперации. Это обусловлено тем, что в динамической модели отражен обмен со­общениями между объектами, а следовательно, и операции объекта-получателя. Передача сообщений между пассивными объектами – не что иное, как вызов опе­рации одного объекта из операции другого объекта.

Проектирование операций классов на основе модели взаимодействия. Операции классов определяются пу­тем рассмотрения того, как объект данного класса взаимодействует с другими объектами, поскольку взаимодействие двух объектов состоит в том, что один из них вызывает операцию другого. Рассматривая два взаимодействующих объекта, необходимо понять, чьи опе­рации вызываются. Следовательно, сообщению ставится в соответствие вызов операции. Имя сообщения отображается на имя операции, а параметры со­общения – на параметры операции.

Проектирование операций классов на основе конечного автомата.. Операции классов можно также вывести из диаграммы состояний. На ней пред­ставлены действия и деятельности, инициируемые в результате перехода состоя­ний. Действия, как правило, отображаются на операции класса. На диаграммах состояний показаны все зависящие от состояния действия и деятельности. Если действия выполняются пассивными классами, то они выводятся из диаграммы состояний.

Проектировать операции классов на основе диаграмм классов из статической модели тоже можно, особенно для сущностных классов. Стандартными являются операции создать, читать, обновить, удалить.

Каждый сущностный класс из аналитической модели, который инкапсулиру­ет данные, проектируется как класс абстрагирования данных. Сущностный класс хранит данные и предоставляет операции для доступа к ним – операции чтения и записи. Класс абстрагирования данных используется для инкапсуляции струк­туры данных, то есть сокрытия деталей ее внутреннего представления. Операции проектируются как процедуры иди функции доступа, внутреннее устройство ко­торых также скрыто.

Информация об атрибутах класса абстрагирования данных должна уже при­сутствовать в статической модели предметной области. Операции такого класса определяются путем рассмотрения тех сервисов, которые нужны клиентским объектам для опосредованного доступа к данным. Это можно сделать, проанализировав способы использования объекта абстрагирования данных в мо­дели кооперации.

Одной из важных целей при разработке программной системы является со­крытие от пользователей информации о модификациях реальных устройств ввода/вывода. Типичный пример такого изменения – это замена одного устрой­ства другим с той же функциональностью, но иным аппаратным интерфейсом. Ра­зумеется, крайне нежелательно, чтобы подобное изменение затронуло всех пользо­вателей. Решается проблема посредством классов интерфейса устройства, которые предоставляют виртуальный интерфейс, скрывающий детали общения с реаль­ным устройством.

С помощью класса интерфейса устройства концепция сокрытия информации применяется для инкапсуляции проектного решения о том, как осуществляется интерфейс с конкретным устройством ввода/вывода. С этой целью разрабатыва­ется класс виртуального интерфейса, в котором скрываются все детали реального интерфейса.

Пользователи могут обратиться к устройству только с помощью виртуально­го интерфейса, состоящего из набора операций. В случае замены устройства и мо­дификации реального интерфейса пользователи виртуального интерфейса ниче­го не узнают, поскольку спецификация операций остается прежней. Надо лишь изменить реализацию этих операций. Таким образом, пользователи класса изоли­рованы от модификаций реальной аппаратуры.

Класс, зависящий от состояния, инкапсулирует информацию, которая пред­ставлена на диаграмме состояний. На этапе проектирования классов диаграмма состояний, исполняемая зависящим от состояния объектом, отображается на таб­лицу переходов состояний. Таким образом, зависящий от состояния класс скры­вает устройство этой таблицы и поддерживает текущее состояния объекта.

Зависящий от состояния класс предоставляет операции для доступа к табли­це переходов состояний и для ее изменения. В частности, проектируются опера­ции для обработки входных событий, вызывающих переходы состояний. Напри­мер, можно задать отдельную операцию для каждого такого события. Это означает, что зависящий от состояния класс проектируется специально для конкретной диаграммы состояний.

Такие классы скрывают алгоритмы, применяемые в предметной области; они типичны в системах реального времени, а также в научных и инженерных прило­жениях. Как правило, такой класс скрывает не только алгоритм, но и локальные данные, необходимые для его работы.

Класс интерфейса пользователя скрывает от других классов детали человеко-машинного интерфейса. В зависимости от приложения интерфейс пользователя может быть очень простым (например, в виде командной строки) или весьма сложным (графический интерфейс пользователя – ГИП). Чтобы реализовать ин­терфейс командной строки, достаточно одного класса, а для графического интер­фейса требуется, как правило, несколько. Низкоуровневые классы интерфейса пользователя – это элементы управления, находящиеся в библиотеках компонен­тов: окна, меню, кнопки и диалоги. Высокоуровневые классы пользовательского интерфейса часто составляются из таких классов.

В аналитической модели акцент делается на идентификации составных клас­сов пользовательского интерфейса и сборе информации о том, какие данные пользователь должен вводить, а какие ему надо показать. На этой же стадии мож­но проектировать выводимые формы.

Класс бизнес-логики определяет логику принятия решения при обработке за­проса клиента, специфичную для данного приложения. Он предназначен для ин­капсуляции бизнес-правил, которые способны изменяться независимо друг от друга. Обычно во время выполнения объект бизнес-логики обращается к различ­ным сущностным объектам.

В аналитической модели представлены сущностные классы, которые инкап­сулируют данные. В ходе проектирования нужно решить, должна ли информация храниться в самом сущностном классе или же в базе данных. В первом случае при­меняются классы абстрагирования данных, которые инкапсулируют структуры данных, а во втором – классы-обертки базы данных, скрываю­щие детали реализации доступа к базе.

На сегодняшний день наиболее широко распространены реляционные базы данных, так что класс-обертка предоставляет объектно-ориентированный интер­фейс к такой базе. При этом необходимо отобразить сущностные классы из стати­ческой модели на структуры базы данных.

Класс-обертка скрывает детали доступа к данным, хранящимся в таблицах базы, а значит, и все операторы языка SQL. Обычно один класс соотносится с од­ной таблицей, но возможны также классы-обертки и для представлений, то есть соединения двух или более таблиц.

Внутренние программные классы скрывают решения разработчика, которые могут со временем измениться. Обычно они создаются на поздних стадиях про­цесса проектирования. Определить их из аналитической модели, относящейся к предметной области, невозможно.

Внутренние программные классы инкапсулируют различные структуры данных (стеки, очереди, таблицы данных), выбранные проектировщиком. Примерами внут­ренних классов являются также классы-разъемы

Наследование полезно при проектировании двух похожих классов, то есть таких, у которых много общих черт. На этапе проектирования архитектуры его нужно иметь в виду, чтобы впоследствии на этапах детального проектирования и кодирования можно было повторно использовать тот же или слегка видоизме­ненный код. Наследование задействуют и с целью сделать проект более удобным для сопровождения – такое применение оченъ упрощает инкрементную модифи­кацию программы.

Иерархии классов (называемые также иерархиями обобщения/специализации или иерархиями наследования) допустимо разрабатывать сверху вниз, снизу вверх или в обоих направлениях. При разработке сверху вниз проектируется класс, кото­рый включает характеристики, общие для всех его наследников. В ходе специали­зации этого класса формируются подклассы со специфическими особенностями.

У абстрактного класса не может быть экземпляров, поэтому он используется как шаблон для создания классов, а не объектов. Иными словами, он способен выступать только в роли суперкласса, который определяет общий интерфейс для всех своих подклассов. Абстрактная операция – это операция, которая объявле­на, но не реализована в абстрактном классе. Абстрактный класс должен иметь хотя бы одну абстрактную операцию.

В объектно-ориентированном проектировании полиморфизм используется, ког­да в различных классах должна существовать операция с одним и тем же именем. Ее спецификация во всех классах одинакова, но реализация может быть различной: это дает возможность во время выполнения использовать вместо одного объекта другой с тем же интерфейсом.

Динамическое связывание применяется совместно с полиморфизмом для ас­социирования запроса с объектом и одной из его операций во время исполнения. При статическом связывании (типичный случай в процедурных языках) ассоциа­ция запроса с операцией устанавливается во время компиляции, ее нельзя впо­следствии изменить. При динамическом связывании, напротив, запрос может сна­чала выполняться операцией одного объекта, а потом операцией другого объекта.

Дата добавления: 2014-01-07