4966

51

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

Виртуальные функции(методы) объявляются со спецификацией virtual при первом объявление метода в базовом классе. Виртуальные функции(методы) переопределяются в одном или более произвольном классах. Сигнатуры виртуальных методов должны полностью совпадать, так как при компиляции создаётся таблица виртуальных методов, на основании которой и происходит позднее (динамическое) связывание места вызова функции(метода) с кодом требуемого виртуального функции(метода) из таблицы. С помощью такой таблицы при выполнении программы для каждого типа объекта осуществляется вызов именно своего метода(функции).

Пример: клерк банка принимает оплату. Метод «принимает» может быть интерпретирован по-разному для различных клерков и различных форм оплаты, однако наличие формальных параметров (размер оплаты и назначение платежа) остаются неизменными. Появление новой формы оплаты повлечёт за собой добавление нового класса с перегрузкой виртуального метода приёмки платежей, причём без перестройки и рекомпиляции ранее написанного кода. Таким образом, расширение функционала ранее написанного кода ядра программной системы может быть осуществлено посредством присоединения к ядру новых программных модулей на этапе компоновки обновленного проекта.

В языке С++ виртуальность может быть реализована посредством механизма указателей. Пример применения виртуальности приведён на рисунке 12.

При использовании виртуальных функций имеют место следующие ограничения:

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

2)виртуальная функция должна быть компонентом класса;

3)конструктор не может быть виртуальной функцией (в то время как деструктор можно объявить со спецификатором virtual).

52

Примечания:

1)если функция не описана (пропущена) в производном классе, то используется версия базового класса;

2)объявить виртуальными следует функции, определения которых зависят от конкретных параметров объектов;

3)виртуальные функции расширяют наследуемые свойства базовых классов;

4)функция, объявленная виртуальной, сохраняет это свойство для любого производного класса иерархии классов.

Ещё одним вариантом применения виртуализации функций являются абстрактные классы. Абстрактным называется класс, который описывает абстрактные сущности предметной области, не имеющие своего реального отражения в виде конкретных экземпляров. Иными словами, создать объект абстрактного класса невозможно. Например, базовым абстрактным классом может являться «геометрическая фигура». Неопределённую фигуру создать невозможно, однако ничто не мешает инкапсулировать атрибуты толщины линии фигуры, цвет заливки и виртуальные методы прорисовки и перемещения такой фигуры. Как мы знаем, виртуальные операции должны быть определены в производных по отношению к абстрактному базовому классу. Например, в случае прототипа класса «окружность» такой класс будет являться производным от класса «фигура», при этом в классе «окружность» будут доступны (в зависимости от уровня доступа) атрибуты базового абстрактного класса. Виртуальные функции(методы) будут переопределены для частного случая геометрической фигуры (например, для фигуры в виде окружности).

Для описания виртуальных функций базовых абстрактных классов применяется принцип «чистого полиморфизма»:

class Figure

{public: int wideline, backcolor;

virtual void drawFigure()=0; // «чистая» виртуальная функция virtual void removeFigure()=0; // «чистая» виртуальная функция

};

При попытке создать объект на базе класса «Figure» будет получена ошибка. С другой стороны не будет ошибкой создание указателя типа такого класса с целью реализации принципа виртуализации в объектах производных классах.

53

//в базовом классе объявлена и определена виртуальная функция

//tellabout():

class ABCD { public: virtual void tellabout() {cout<<"This is the class ABCD"<<endl;};};

//в производном классе переопределено действие виртуальной функции: class ABCDE: public ABCD

{void tellabout(){cout<<"This is the class ABCDE"<<endl;};};

//в производном классе переопределено действие виртуальной функции: class ABCDEF:public ABCDE

{void tellabout(){cout<<" This is the class ABCDEF "<<endl;};}; //****************************************************** void main(void)

{

Рисунок 12 − Пример применения виртуальных функций

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

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

1.Объясните назначение инкапсуляции класса.

2.С какой целью применяется разделение доступа к элементам класса?

54

3.Какие способы разделения доступа к элементам класса Вы знаете?

4.Какие способы доступа к закрытым элементам класса Вы знаете?

5.Что такое конструкторы класса и каково их назначение?

6.Чем сопровождается создание объекта данного класса?

7.Что определяет перечень параметров при создании объекта?

8.Чем объясняется разнообразность поведения экземпляров одного класса?

9.Чем отличаются функции и методы классов?

10.Какие типы конструкторов класса Вы знаете?

11.Что такое деструкторы класса и каково их назначение?

12.Дайте определение понятию «наследование».

13.Перечислите виды наследования.

14.Каков порядок последовательности работы конструкторов в иерархии классов?

15.Каков порядок последовательности работы деструкторов при наследовании в иерархии классов?

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

17.Перечислите способы доступа к наследуемым элементам класса.

18.Дайте определение понятию «позднее связывание».

19.Каким образом может быть обеспечено расширение возможностей программной системы при объектном подходе?

20.Дайте определение понятию «виртуальная функция».

21.В чём заключается назначение виртуальности?

22.Что такое абстрактный класс?

23.Дайте определение видам виртуальности с точки зрения полиморфизма.

2.3. Объектно-ориентированное проектирование

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

Иными словами, созданная в результате объектно-ориентированного анализа модель предметной области в виде иерархии классов, отражающая статическое состояние системы, дополняется искусственными объектами и классами, которые позволяют описать динамику системы. Такие искусственные элементы

55

предназначены для отражения взаимодействия сущностей предметной области при достижении поставленной цели (например, осуществления продажи товара, приёмки товара на склад, получения наличных в банкомате, регистрации документа и т.д.). Например, своеобразными «двигателями процессов» в программной системе могут служить так называемые менеджеры сообщений, которые, безусловно, являются искусственными по отношению к инфологической модели, но позволяют организовать взаимодействие с пользователями и другими подсистемами вычислительной среды. Описание таких дополнительных элементов системы также выполняется по методу объектной декомпозиции на уровне деклараций в классах, т.е. в виде описания того, что будут делать те или иные функции или методы классов без описания их реализации. Таким образом, объектноориентированный проект можно считать своеобразным описанием постановки задачи на разработку программного кода. В случае применения автоматизированных средств для объектно-ориентированного проектирования результатом этого процесса может являться готовое описание прототипов классов (инкапсуляция) на языке программирования С++ в виде, приемлемом для экспортирования в инструментальную среду, например, MS Visual C++.

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

2.3.1. Язык UML как средство объектно-ориентированного анализа и проектирования

Как и при любом другом способе проектирования в объектноориентированном проектировании существуют свои средства, предназначенные

56

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

В качестве стандартного унифицированного языка моделирования систем, в том числе и программных, в 1997 г. консорциумом Object Managing Group (OMG) был принят язык UML (Unified Modeling Language). Первоначальная вер-

сия языка UML была опубликована в июне 1996 г. в результате совместных усилий авторов: Грейди Буч (компания Rational Software Corporation), Айвар Джекобсон (Objectory) и Джеймс Рамбо (General Electric). При создании языка UML преследовались следующие цели [1]:

1)моделировать системы целиком, от концепции до исполняемого артефакта

спомощью объектно-ориентированных методов;

2)решить проблему масштабируемости, которая присуща сложным системам, предназначенным для выполнения задач в распределённых системах;

3)создать такой язык моделирования, который может использоваться не только людьми, но и компьютерами.

Язык UML представляет собой универсальное средство для анализа и моделирования объектов, позволяющее документировать процесс проектирования объектно-ориентированных систем. На UML можно содержательно описывать сущности информационной системы и соответствующие им классы, объекты и компоненты программных систем. Язык UML, с одной стороны, позволяет документировать весь процесс анализа и разработки, с другой стороны, упрощает написание программного кода, так как вся нотация (способ изложения и описания моделей) в UML ведётся на языке, приближённом к объектноориентированному языку C++.

Визуализация, специфицирование, конструирование и документирование объектно-ориентированных систем – это и есть назначение языка UML [1]. В настоящем пособии будет использована нотация языка UML версии 1.3.

В качестве CASE-средств визуального проектирования, в которых применяется нотация UML, можно упомянуть такие, как AllFusion Component Modeler

(ранее: Paradigm Plus); Oracle Designer (входит в Oracle9i Developer Suite); IBM Rational Software Modeler и IBM Rational Software Architect.

AllFusion Component Modeler – программный комплекс для автоматизированного проектирования, визуализации, генерации исходного кода и поддержки информационных систем.

57

Oracle Designer – программный комплекс для автоматизированного проектирования программных систем и баз данных, реализующее технологию CASE и собственную методологию Oracle "CDM". Позволяет команде разработчиков полностью выполнить проект, начиная с анализа бизнес-процессов через моделирование до генерации кода и получения прототипа, а в дальнейшем и окончательного продукта.

IBM Rational Software Modeler − программный комплекс для автоматизированного визуального моделирования и проектирования, который позволяет пользователям документировать эти различные представления системы и доводить их до сведения заинтересованных лиц.

IBM Rational Software Architect − средство проектирования архитектурных и компонентных решений при разработке программного обеспечения.

2.3.2.Основные группы элементов языка UML

Косновным группам языка UML относятся:

1)описание составляющих единиц – словарь языка;

2)совокупность графических объектов в виде диаграмм;

3)описание дополнительных понятий, позволяющих расширить смысл основных понятий языка.

Словарь языка UML включает три вида строительных блоков:

1)сущности – абстракции, являющиеся основными элементами модели программной системы;

2)отношения – средства отображения связей между сущностями;

3)диаграммы – группируют представляющие интерес на конкретной стадии проектирования совокупности сущностей и отношений для описания статического и динамического состояний проектируемой системы.

Виды сущностей языка UML:

1)структурные сущности;

2)поведенческие сущности;

3)аннотационные сущности.

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

58

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

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

Классы являются статическими элементами системы; активными классами являются такие элементы системы, которые порождают изменения состояния других статических элементов.

Интерфейсом называется возможная реализация одной из форм поведения элементов системы (классов), для которых возможна полиморфная реакция. Сущность «интерфейс» отражает виртуальные компоненты классов (см. п. 2.2.6 настоящего пособия).

Вкачестве примера рассмотрим класс «Окно», определяющий способ и форму некоторого малого окна, появляющегося на фоне главного окна программы.

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

Компоненты и узлы

Структурные сущности компоненты и узлы соответствуют физическим сущностям системы (например, компонентами будут являться файлы исходного кода, компоненты DLL, СОМ+ или Java; узлы: сервер; рабочая станция и т.д.).

Поведенческие сущности – предназначены для описания взаимодействия и алгоритма поведения объектов. Под взаимодействием объектов следует понимать обмен сообщениями между объектами. Алгоритм поведения – описание последовательности смены состояний объекта (иначе «автомат»).

59

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

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

Посредством диаграмм язык UML позволяет отображать и статическую структуру, и динамическое состояние системы. В статической структуре задаются типы объектов, а также отношения между этими объектами. Динамическое состояние описывается рядом статических состояний объектов (траекторией системы), связанных правилами взаимодействия для достижения определённого результата.

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

Типы диаграмм в UML:

1)диаграмма вариантов использования ( use case diagram );

2)диаграмма классов (class diagram);

3)диаграмма объектов (object diagram);

4)диаграмма последовательности (sequence diagram);

5)диаграмма кооперации (collaboration diagram) ;

6)диаграмма состояний (statechart diagram);

7)диаграмма деятельности (activity diagram);

8)диаграмма компонентов (component diagram);

9)диаграмма развёртывания (deployment diagram).

Нумерация типов диаграмм в приведённом списке никоим образом не отражает очерёдность их разработки, так как перечисленные диаграммы являются

60

моделями с разных точек зрения. Какие именно модели могут потребоваться – выяснится в ходе проектирования системы, в зависимости от поставленной задачи. Язык UML является средством, но не методом проектирования.

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

2.3.3. Диаграммы вариантов использования

Варианты использования и их диаграммы применяются для визуализации функциональных возможностей системы (системы в целом, подсистемы или класса). С помощью диаграмм вариантов использования заказчики и менеджеры проекта получают общее представление о системе и смогут принять решение по данной стадии проекта (выяснении функциональных требований и соответствии модели данным требованиям). Диаграмма вариантов использования описывает функционирование системы с точки зрения внешнего наблюдателя. При этом описывается, что система делает, но без детализации того, как это происходит. Каждая такая диаграмма соответствует определённому, безальтернативному перечню действий в анализируемой предметной области при условии достижения конкретного результата. Диаграмма строится на основании словесного описания последовательности выполняемых действий сценария. Сценарий – это один из примеров того, что происходит в системе. Пример сценария приведён в Приложении А. Описание сценария должно соответствовать схеме: «роль–действие– результат». Сценарий является изложением последовательности действий, выполняемых исполнителями, описанием предварительных состояний исполнителей и условий выполнения таких действий, а также описанием результатов действий и состояний исполнителей после свершившихся действий. Такое изложение должно подчиняться правилу логической целостности и неразрывности происходящих событий. При этом, учитывая особенности итерационного, последовательно и постепенно уточняющего новые факты и операции, способа построения модели предметной области, совершенно нет никакой необходимости пытаться за один раз и в одном изложении описать всё происходящее. Самый пер-