– А : С = Е видимость, имя, тип и значение по умолчанию.
Строка свойств, указанная в фигурных скобках, описывает дополнительные свойства атрибута (примеры свойств приведены ниже).
Операции обычно изображаются внутри значка класса только своим именем. Можно также указывать дополнительные элементы в формате:
видимость имя (формальные_параметры) : тип_возвращаемого_значения {строка свойств}
Формальные параметры записываются в формате:
вид имя : тип = значение_по_умолчанию
Вид принимает одно из следующих значений:
in – входной параметр (значение по умолчанию);
out – выходной параметр;
inout – смешанный, т.е. и входной, и выходной.
Если параметр помечен как входной, то функция не может изменять его значения, но может его использовать (передача параметров по значению); если параметр помечен как выходной, то функция не может использовать его значение, но может присвоить ему некоторое значение; наконец, если параметр помечен как смешанный, то функция может и читать его значение, и изменять (передача параметров по ссылке).
Приведем примеры описания операций:
display( ) только имя;
display( ): bool имя и тип возвращаемого значения;
+set(n: Name, s: String) видимость, имя и формальные параметры.
Статические члены класса (атрибуты и операции) изображаются подчеркнутыми (см. рис. 5.2, соответствующий примеру в разд. 4.6).
Утилита изображается обычным значком класса со стереотипом «utility» (рис. 5.3). Добавление к стандартному элементу языка стереотипа (некоторого ключевого слова в скобках « ») позволяет приспособить данный элемент для решения специальной проблемы.
Интерфейс на диаграмме классов можно изобразить развернутым и сокращенным. В случае развернутого способа интерфейс изображается на диаграмме как класс со стереотипом «interface» и без секции атрибутов (рис. 5.4). Сокращенное изображение интерфейса представляет небольшой кружок с именем интерфейса возле него (рис. 5.5).
Рис. 5.4. Развернутое Рис. 5.5. Сокращенное
изображение интерфейса изображение интерфейса
Рассмотрим обозначения отношений между классами.
Значок ассоциации изображается в виде линии, соединяющей два класса (рис. 5.6). При изображении ассоциации ей можно поставить в соответствие текстовую пометку, документирующую имя этой связи или подсказывающую ее роль. Ассоциации часто отмечаются существительными, например «Место работы», описывающими природу связи. К полюсам ассоциации (концам линии) также можно добавить имена (роли, которые классы играют в ассоциации). Одна пара классов может иметь более одной ассоциативной связи.
Рис. 5.6. Ассоциация Рис. 5.7. Зависимость
Возле значка ассоциации можно указать ее кратность. Указывая кратность возле одного полюса, показывают, что на этом полюсе именно столько объектов должно соответствовать каждому объекту на другом полюсе. Если кратность явно не указана, то подразумевается, что она не определена.
На рис. 5.6 изображена ассоциация из примера в разд. 4.1 .
Отношение зависимости изображается пунктирной линией со стрелкой, направленной от клиента к серверу (рис. 5.7).
Значок наследования (обобщения) включает большую незакрашенную стрелку, которая указывает от подкласса к суперклассу (рис. 5.8). Место классов в наследственной иерархии можно уточнить следующим образом. Имена абстрактных классов указываются курсивом. К имени корневого класса добавляется свойство root, а к имени листового класса – свойство leaf. Аналогично имена чисто виртуальных функций-членов указываются курсивом, а к имени операции, которая не может быть виртуальной, добавляется свойство leaf.
Пример. На рис. 5.8 показана наследственная иерархия, связанная с геометрическими фигурами (см. разд. 4.4.1). Абстрактный класс Shape отмечен как корневой класс, имеющий чисто виртуальные функции draw, rotate и листовую функцию get_center. Функция draw в протоколе класса Circle является полиморфной. Класс SolidCircle объявлен как листовой.
Рис. 5.8. Обобщение
Значок агрегации – линия с добавлением незакрашенного ромба на конце, обозначающем агрегат (рис. 5.9). Экземпляры класса на другом конце стрелки будут частями экземпляров класса-агрегата. Отношение композиции обозначается линией с закрашенным ромбом на конце (рис. 5.10).
Рис. 5.9. Агрегация Рис. 5.10. Композиция
Параметризованный класс изображается значком обычного класса с пунктирным прямоугольником в правом верхнем углу, в котором указаны параметры (рис. 5.11). Моделировать инстанцирование можно двумя способами. Во-первых, можно явным образом определить отношение реализации (изображается в виде пунктирной линии с большой незакрашенной стрелкой) со стереотипом «bind», показывающее, что источник инстанцирует целевой шаблон. Фактические параметры, соответствующие формальным параметрам шаблона, указываются в виде
Во-вторых, моделировать можно неявно, для чего требуется объявить класс, имя которого включает имя шаблона и фактические параметры, указанные таким же способом, что и в первом случае.
Пример использования данных способов показан на рис. 5.11, 5.12 для стека целых значений, рассмотренного в разд. 4.5.
Рис. 5.11. Явный способ Рис. 5.12. Неявный способ
Пример. На рис. 5.13 представлена система классов, служащая для моделирования процесса обслуживания системы управления климатом в теплице. Класс Plan включает правила управления климатом и имеет операцию execute (выполнить). Имеется ассоциация между этим классом и классом Controller (контроллер, управляющий климатом): экземпляры класса Plan задают климат, который должны поддерживать экземпляры класса Controller.
Рис. 5.13. Классы для описания процесса обслуживания системы управления климатом
Эта диаграмма также показывает, что класс Controller является агрегатом: его экземпляры содержат в точности по одному экземпляру классов Heater (нагреватель) и Cooler (охлаждающее устройство) и любое число экземпляров класса Light (лампочка). Оба класса Heater и Cooler являются подклассами абстрактного запускающего процесс класса Actuator, который предоставляет протоколы startUp и shutDown (начать и прекратить соответственно) и использует класс Temperature.
Связь интерфейса с реализующим его элементом можно графически представить двумя способами. Простая форма позволяет изобразить отношения между интерфейсом и реализующим его классом в виде кружка с одной стороны класса (см. рис. 4.3). Если интерфейс представлен в расширенной форме, то отношение реализации изображается явно, как для инстанцирования, но без стереотипа (рис. 5.14). Зависимость между классом и интерфейсом показывается аналогично зависимости между классами.
Рис. 5.14. Отношения между классами Рис. 5.15. Вложение
и интерфейсом классов
Если некоторый класс описан внутри другого класса, то он называется вложенным и недоступен вне объемлющего его класса. Обозначение вложения классов приведено на рис. 5.15.
Пример.Список состоит из узлов, связанных между собой с помощью указателей. Если класс «Узел» используется только для определения класса «Список», то его описание целесообразно скрыть путем вложения.
class List{
class Node{ . . .};
Node *pbeg, *pend; // указатели на начало и конец списка
. . .
};
5.2. Диаграмма объектов
Диаграмма объектов показывает существующие объекты и связи между ними в некоторый момент времени.
Диаграмма объектов может рассматриваться как прототип: она представляет отношения, которые могут возникнуть среди элементов данного множества экземпляров классов.
Объект на диаграмме объектов изображается значком, показанным на рис. 5.16. Он совпадает со значком класса, но имя объекта подчеркивается, и отсутствуют горизонтальные линии, разделяющие текст внутри значка объекта на части.
Рис. 5.16. Значок объекта Рис. 5.17. Значок связи
Имя объекта может быть записано в одной из следующих форм:
А – только имя объекта;
: С – только класс объектов (анонимный экземпляр);
А : С – имя объекта и класса.
Если класс объекта никогда не указывается, то класс считается безымянным. Если указывается только имя класса, то объект считается безымянным. Каждый значок, не содержащий имени объекта, обозначает отдельный безымянный объект.
Объекты взаимодействуют с другими объектами через связи, которые изображаются на диаграмме прямыми линиями (см. рис 5.17).
На значках объектов бывает полезно указать несколько их атрибутов. Синтаксис атрибутов совпадает с синтаксисом атрибутов класса и позволяет указать их текущее значение (см. рис 5.18). Имена атрибутов объектов должны соответствовать атрибутам, определенным в классе объекта, или в любом из его суперклассов.
На рис. 5.18 приведен пример диаграммы объектов, соответствующий диаграмме классов на рис. 5.6.
Рис. 5.18. Диаграмма объектов
5.3. Диаграммы последовательностей и коммуникации
На диаграммах последовательностей и диаграммах коммуникацииотражаются множество объектов и отношения между ними, включая сообщения, которыми они обмениваются.
На диаграммах последовательностей внимание акцентируется прежде всего на временной упорядоченности сообщений. Преимущество диаграммы последовательностей в том, что на ней легче читается порядок посылки сообщений.
На диаграмме последовательностей объекты изображаются горизонтально вдоль верхней границы. Обычно инициирующий взаимодействие объект размещается слева, а остальные правее (тем дальше, чем более подчиненным является объект). Из значка каждого объекта выходит вертикальная пунктирная линия, называемая «линией жизни». Эта линия показывает пределы существования объекта.
Отправления сообщений (вызовы операций) показываются горизонтальными стрелками. Линия, обозначающая посылку сообщения, проводится от линии жизни клиента к линии жизни сервера. Первое сообщение показывается на самом высоком уровне, второе – ниже и т.д.
Вызов операции обозначается ее именем, кроме того, здесь могут быть приведены фактические параметры операции. Ответное сообщение (возвращаемое значение) указывается пунктирной стрелкой от сервера к клиенту.
Пример. Диаграмма последовательностей приведена на рис. 5.19. На диаграмме отражено взаимодействие трех объектов. Сценарий начинается с вызова объектом А операции f1 над объектом В. Это порождает вызов объектом В операции f2 над объектом С, что потребует вызова объектом С операции f3 над собой. Когда эта операция будет выполнена, объект В передаст возвращаемое значение r объекту А, который затем вызывает операцию f4 над объектом С.
Большая часть объектов, представленных на диаграмме последовательностей, существует на протяжении всего взаимодействия, поэтому их изображают в верхней части диаграммы, а их линии жизни прорисованы сверху донизу. Объекты могут создаваться и во время взаимодействий. Линии жизни таких объектов начинаются с получения сообщения со стереотипом «create». Объекты могут также уничтожаться во время взаимодействий; в таком случае их линии жизни заканчиваются получением сообщения со стереотипом «destroy», а в качестве визуального образа используется большая буква Х.
На диаграммах может быть изображен фокус управления. Он изображается в виде вытянутого прямоугольника, показывающего промежуток времени, в течение которого объект выполняет какое-либо действие непосредственно или с помощью подчиненной процедуры (рис. 5.20). Верхняя грань прямоугольника выравнивается по временной оси с моментом начала действия, нижняя – с моментом его завершения. Вложенность фокуса управления, вызванную рекурсией (т.е. обращением к собственной операции) или обратным вызовом со стороны другого объекта, можно показать, расположив другой фокус управления чуть правее своего родителя.
На рис. 5.20 показан пример, аналогичный предыдущему, в котором, однако, объект В создается и уничтожается во время взаимодействия.
Чаще всего приходится моделировать неветвящиеся последовательные потоки управления. Однако можно моделировать и более сложные потоки, содержащие циклы и ветвления.
Цикл изображается в виде рамки, в которую вписано ключевое слово loop (рис. 5.21). В квадратных скобках указывается условие выполнения цикла.
Ветвление также изображается в виде рамки, в которую вписано ключевое слово alt (рис. 5.22). Область оператора alt разделяется на части, каждая из которых имеет свое собственное условие. Если такое условие является истинным, то выполняются функции, предусмотренные в соответствующей части.
Рис. 5.21. Цикл Рис. 5.22. Ветвление
Диаграмма коммуникации акцентирует внимание на структурной организации объектов, принимающих и отправляющих сообщения.
На диаграмме изображаются объекты и связи между ними, как на диаграмме объектов. Рядом с соответствующей связью на диаграмме можно записать набор сообщений. Каждое сообщение состоит из следующих трех элементов: направление вызова, вызов операции, порядковый номер.
Направление сообщения показывается стрелкой, указывающей на объект-сервер.
Вызов операции обозначается так же, как и на диаграмме последовательностей.
Порядковый номер показывает относительный порядок посылки сообщений. Сообщение с меньшим порядковым номером посылается до сообщения с большим номером. Нумерация начинается с единицы и добавляется как префикс к вызову операции. Для отображения вложенных сообщений используется следующая нотация: 1 – первое сообщение; 1.1 – первое сообщение, вложенное в сообщение 1; 1.2 – второе сообщение, вложенное в сообщение 1, и т.д.
Пример. Диаграмма коммуникации, соответствующая диаграмме последовательностей с рис. 5.20, показана на рис. 5.23.
Рис. 5.23. Диаграмма коммуникации
Циклы моделируются вставкой после номера сообщения итерационного выражения (рис. 5.24). Итерационное выражение изображается в виде звездочки, за которой следует перечисление в квадратных скобках. Перечисление может быть опущено, если надо обозначить цикл без дальнейшей детализации.
Рис. 5.24. Циклы и условия
Для моделирования условия после порядкового номера сообщения ставится выражение в квадратных скобках (рис. 5.24). У всех альтернативных ветвей должен быть один и тот же порядковый номер, но условия на каждой ветви должны быть заданы так, чтобы два из них не выполнялись одновременно (не перекрывались).
6. МНОГОКРАТНОЕ ИСПОЛЬЗОВАНИЕ ПРОГРАММНЫХ СИСТЕМ.
ОСНОВЫ ВИЗУАЛЬНОГО И КОМПОНЕНТНОГО ПРОГРАММИРОВАНИЯ
Одним из главных преимуществ объектно-ориентированного программирования является возможность многократного использования разработанного программного обеспечения. Под этим понимается возможность использовать фрагмент кода, разработанный для одной системы, в других системах. Разумеется, этот фрагмент кода должен представлять собой логически более или менее законченную часть. Реальное ускорение процесса разработки программного обеспечения возможно только тогда, когда конкретная программная система разрабатывается не с нуля, а с использованием готовых составных частей.
Многократное использование кода – это идеальный вариант передачи знаний. Труд, знания и опыт разработчика, заложенные в готовом продукте – программном коде, – передаются без потерь.
Конечно, и раньше для процедурно-ориентированных языков программирования типа Фортран, Паскаль или Си создавались библиотеки функций, реализующих наиболее употребимые алгоритмы обработки данных.
В рамках объектно-ориентированного подхода разрабатываются библиотеки классов. Использование библиотек классов повышает скорость разработки программ и экономит значительные усилия разработчиков. Однако нельзя сказать, что у них нет недостатков.
Использование библиотек классов требует определенных усилий для их изучения и понимания того, как они устроены. Современные среды программирования используют различные графические средства построения программ, которые позволяют визуально манипулировать программой и упростить разработку классов, однако их возможности при работе с библиотеками классов ограниченны.
Библиотека классов должна быть написана на том же языке программирования, что и разрабатываемая программа.
Для того чтобы воспользоваться библиотекой, необходимо написать программу с вызовами нужных функций или порождением необходимых классов и оттранслировать эту программу.
Подобные соображения привели к появлению концепции компонента. Компонент – это программный модуль или объект, который готов для использования в качестве составного блока программы и которым можно визуально манипулировать во время разработки программ.
Чем отличается компонент от класса в библиотеке классов или функции в библиотеке функций?
Во-первых, компонент – это объект, т.е. компонент объединяет состояние и интерфейс. Состояние компонента может быть изменено только с помощью посылки сообщений (вызова операций).
Во-вторых, у компонента имеются два типа интерфейсов: интерфейс времени выполнения и интерфейс времени проектирования.
Интерфейс времени выполнения – это тот интерфейс, который управляет работой компонента.
Интерфейс времени проектирования – это интерфейс, который позволяет узнать, каков интерфейс времени выполнения. Интерфейс времени проектирования позволяет включать компоненты в современные среды программирования. Кроме того, интерфейс времени проектирования позволяет опрашивать компонент уже во время выполнения, динамически проверяя, какие методы и интерфейсы он реализует.
В-третьих, неважно, на каком языке программирования разработан компонент. Более того, совершенно не обязательно, чтобы компонент был реализован с помощью объектно-ориентированного языка программирования. Он должен удовлетворять определенным внешним характеристикам, но его реализация полностью закрыта. В идеале компонент должен быть нейтрален по отношению к языку программирования, т.е. его можно использовать в программе на любом языке, который поддерживает компонентную технологию.
Компонент может быть включен непосредственно в программу (локальный компонент) или существовать независимо, в том числе и на другом компьютере.
Отличительными признаками локального компонента является то, что он включается в программу на стадии разработки и существует только как часть вызывающей его программы. Физически копия компонента может быть одна для нескольких программ, либо каждая программа создает собственную копию. Однако логически они независимы, и вызывающая программа управляет созданием и уничтожением компонента.
Другой вид компонентов – это независимые компоненты, существующие вне использующей их программы. Чаще всего такие компоненты применяются в распределенных системах, состоящих из большого числа ЭВМ, соединенных между собой сетью.
Компонентное построение прежде всего используется для построения графического интерфейса программ. По мере того как графические возможности систем становятся все более изощренными, затраты на создание интерфейсов программ растут. При этом их программирование и отладка не только трудоемки, но и требуют высокой квалификации. Разнообразные библиотеки классов, хотя и упрощают в какой-то мере программирование, ограничивают гибкость. Для построения удобных в использовании графических программ достаточно часто нужно использовать весь арсенал средств, предоставляемых графической подсистемой операционной системы.
Средства проектирования пользовательских графических интерфейсов в большинстве случаев работают в режиме графических редакторов, при котором программист рисует на экране монитора диалоги, помещая разнообразные элементы (кнопки, списки, поля) простым движением манипулятора «мышь».
Компоненты легко вписываются в концепцию графического редактора, позволяя программисту манипулировать ими с той же легкостью, что и стандартными графическими элементами.
Но наличие графического интерфейса не является обязательным признаком компонента (в отличие от возможности визуального манипулирования). Компонент может реализовывать вычислительную задачу или связывать программу с другой подсистемой.
Компонент может реализовывать какой-либо графический элемент, например, в качестве компонента может выступать кнопка на экране, при нажатии которой происходит выполнение какого-либо действия, или более сложный элемент, например календарь с расписанием отправлений поездов.
7. ОСНОВЫ ТЕСТИРОВАНИЯ В ОБЪЕКТНО-ОРИЕНТИРОВАННЫХ СИСТЕМАХ
Без этапа тестирования программного обеспечения процесс разработки будет неполным.
Тестирование является достаточно независимым процессом, применимым к программному обеспечению, разработанному с помощью любого метода проектирования. Тем не менее, объектно-ориентированный подход привносит свои особенности.
Традиционно тестирование делится на тестирование элементов, интеграционное тестирование и системное тестирование.
На уровне элементов тестирование объектно-ориентированных программ отличается по следующим показателям:
– определение единиц тестирования;
– тестирование наследования;
– тестирование полиморфизма.
Естественной единицей тестирования является класс. Разбиение его на более мелкие элементы (методы) нецелесообразно, поскольку они не существуют отдельно от классов. Иногда за единицу тестирования принимается тесно связанная группа классов.
Тестирование наследования состоит в тестировании методов, унаследованных классом от своего суперкласса. Если суперкласс уже прошел тестирование, нужно ли повторять тестирование для унаследованных методов? Вопреки достаточно распространенным надеждам программистов перетестирование необходимо. Основная причина та, что методы выполняются в новом контексте.
Тестирование полиморфизма сходно с тестированием наследования в том, что в тестовых сценариях необходимо предусмотреть все варианты связывания, т.е. все варианты конкретной реализации полиморфизма.
Интеграционное тестирование представляет собой тестирование того, как отдельные элементы программы работают вместе. Свойства объектно-ориентированных языков исключают целый ряд возможных ошибок, прежде всего за счет строгого определения внешних интерфейсов классов и объектов. Однако это не означает, что интеграционное тестирование становится легче.
Системное тестирование проверяет всю программную систему целиком и строится в большинстве случаев по принципу «черного ящика», когда тестирующий знает только внешние характеристики системы, но не знает, как она работает.
ЛИТЕРАТУРА
1. Бадд Т. Объектно-ориентированное программирование в действии. – СПб.: «Питер», 1997.
2. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений на С++. – М.: «Издательство Бином», 2001.
3. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя. – М.: ДМК, 2006.
4. Иванова Г.С, Ничушкина Т.Н., Пугачев Е.К. Объектно-ориентированное программирование. – М.: Изд-во МГТУ им. Н.Э. Баумана, 2007.
5. Объектно-ориентированный анализ и проектирование с примерами приложений/ Г. Буч, Р.Α. Максимчук, М.У. Энгл, Б.Дж. Янг, Д. Коналлен, К.А. Хьюстон. – М.: «И.Д. Вильямс», 2010.
6. Павловская Т.А. C/C++. Программирование на языке высокого уровня.– СПб.: Питер, 2010.
7. Павловская Т. А., Щупак Ю. А. C++. Объектно-ориентированное программирование: Практикум. – СПб.: Питер, 2008.
8. Подбельский В.В. Язык С++: Учеб. пособие. – М.: Финансы и статистика, 2007.
9. Пол А. Объектно-ориентированное программирование на С++. – СПб.; М.: «Невский диалект» – «Издательство Бином», 1999.
10. Романовский К.Ю., Кузнецов С.В., Кознов Д.В. Объектно-ориентированный подход и диаграммы классов в UML // Объектно-ориентированное визуальное моделирование. – CПб: Изд-во С.-Петербургского ун-та, 1999. – С. 21–56.
11. Страуструп Б. Язык программирования С++. – СПб.; М.: «Невский диалект» – «Издательство Бином», 2008.
12. Пышкин Е.В. Основные концепции и механизмы объектно-ориентированного программирования. – СПб.: БХВ-Петербург, 2005.
13. Хабибуллин И.Ш. Программирование на языке высокого уровня. C/C++. – СПб.: БХВ-Петербург, 2006.
14. Фридман А.Л. Основы объектно-ориентированного программирования на языке С++. – М.: Горячая линия – Телеком, 2001.
15. Фридман А.Л. Основы объектно-ориентированной разработки программных систем. – М.: Финансы и статистика, 2000.
