Объектно-ориентированный подход и диаграммы классов в UML

<Имя класса> есть полное имя класса, представителем которого он является. Стереотип класса может быть показан текстуально (в кавычках, строчкой выше) или иконкой в верхнем правом углу, но стереотип объекта должен совпадать со стереотипом его класса.

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

На рис. 19 показаны различные способы изображения объекта:

а) развернутое изображение;

б) анонимный объект;

в) сокращенное изображение.

Можно также показать, что объект может принимать некоторые состояния:

< Имя объекта> : <имя класса> '['<список состояний>']'

<список состояний> - список состояний объекта, в которых он может находиться во время своей "жизни" в системе. Состояния объекта формируются на этапе анализа проектируемой системы, то есть выделяются некоторые основные фазы, в которых может находиться объект. Далее при проектировании системы эти состояния могут корректироваться.

Второе отделение в прямоугольнике объекта содержит атрибуты объекта и их конкретные значения:

<Имя атрибута> : <тип> = <значение>

Объекты могут быть простыми и составными.

Составной объект

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

Существует два вида представления составного объекта на диаграмме. Первый вариант (см. рис. 20): составной объект представляется так же, как и обычный, но нижнее отделение содержит части составного объекта (вместо списка значений атрибутов), соединенные связями (связь - аналог ассоциации для объектов). Второй вариант изображен на рис. 21.

Связи между объектами

Когда мы говорили о классах, мы ввели одно из ключевых понятий модели классов - понятие ассоциации. Для объектов существует аналогичное понятие - связь (link).

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

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

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

· "association" - экземпляр ассоциации. Этот вид означает, что данная связь является экземпляром ассоциации, соединяющей классы партнеров связи; Поскольку все связи - экземпляры ассоциации, то указывать этот вид не имеет особого смысла, он выставляется по умолчанию;

· "parameter" - этот вид связи означает, что объект является параметром операции другого объекта-партнера связи;

· "local" - показывает, что объект есть локальный параметр операции или метода другого объекта-партнера связи;

· "global" - аналогично предыдущему, только здесь - глобальный параметр;

· "self" - применяется для обозначения связи объекта с самим собой. Используется, например, для обозначения возможности посылки объектом сообщений самому себе.

Зависимость

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

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

Существуют следующие виды зависимостей:

· Trace - показывает историческую связь между двумя элементами, которые представляли одно и то же понятие на разных этапах;

· Refine - историческая связь между элементами, как правило, показывает, что один элемент как бы произошел от другого;

· Uses - использование - ситуация когда один элемент модели использует другой;

· Bind - привязка - устанавливается между шаблоном и экземпляром шаблона;

· Friend - аналог C++ friend.

Заключение

В заключение скажем несколько слов о применении модели классов UML.

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

Отметим, что модель классов может использоваться, начиная с анализа и кончая этапом реализацией. При анализе с ее помощью удобно моделировать объекты предметной области и связи между ними. При проектировании на ней изображаются основные элементы будущей системы. При реализации на модели классов определяются все классы системы и связи между ними. Предполагается, что вместе со средствами реинжиниринга модель классов должна служить эффективным средством визуальной разработки ПО. В [4] отмечается, что использование на разных этапах разработки системы одной нотации облегчает преемственность между этими этапами.

Наш коллектив широко использовал UML в своей работе - как в рамках Rational Rose, так и в рамках Real. Например, мы разработали большую базу данных с элементами объектно-ориентированного подхода [17]. Кроме того, мы многократно пользовались UML для описания уже написанных программ и, наоборот, при обсуждении проектируемого ПО.

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

Указатель литературы

[1] Yourdon E. Modern Structured Analysis. - Prentice-Hall, 1989.

[2] Booch G., Rumbaugh J. UML 1.1 Semantics. (http://www.rational.com/uml/) 1997.

[3] Долгов П., Иванов А., Кознов Д., Лебедев А., Мурашева Т., Парфенов В., Терехов А. Объектно-ориентированное расширение технологии RTST. // Записки семинара кафедры системного программирования "CASE-средства RTST++". Вып. 1. - CПб, Издательство С.-Петербургского университета, 1998. С. 17-36.

[4] Booch G. Object-oriented analysis and design with applications. Second edition. The Benjamin/Cummings Publishing Company, Inc. 1994. 589 p.// Русский перевод: Г.Буч. Объектно-ориентированный анализ и проектирование: с примерами приложений на C++. "Издательство Бином", "Невский диалект", 1998, 560 с., ил.

[5] Rumbaugh J., Blacha M. Premerlani W., Eddy F. Lorensen W. Object-Oriented Modeling and Design. Prentice-Hall, Inc., 1991

[6] Jacobson I. Object-Oriented Software Engineering. A Use Case Driven Approach. Addison-Wesley Publishing Company, 1993.

[7] Booch G., Rumbaugh J.UML 1.1 Notation Guide (http://www.rational.com/uml/) 1997.

[8] A Rational Approach to Software Development Using Rational Rose 4.0 http://www.rational.com/support/techpapers/roseapproach/. 1997

[9] OMG Unified Modeling Language Specification (draft). Version 1.3R9. (http://www.rational.com/uml/) 1999.

[10] G. Booch, Jim Rumbaugh, Ivar Jacobson The Unified Modeling Language User Guide: Addison-Wesley Publishing Co., 1999, 512 p.

[11] Ivar Jacobson, G. Booch, Jim Rumbaugh The Unified Software Development Process: Addison-Wesley Publishing Co., 1999, 512 p.

[12] Jim Rumbaugh, Ivar Jacobson, G. Booch Unified Modeling Language Reference Manual: Addison-Wesley Publishing Co., 1999, 576 p.

[13] B.P. Douglass Real-Time UML. Developing Efficient Objects for Embedded Systems: Addison-Wesley Publishing Co., 1998, 365 p.

[14] G. Booch The Visual Modeling of Software Architecture for the Enterprise. Rose Architect. October 1998, Vol. 1, No 1. p 18-25.

[15] Barker R. CASE Method. Entity-Relationship Modeling. Copyright Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990

[16] Горин С.В., Тандоев А.Ю. Применение CASE-средства ERWin 2.0 для информационного моделирования в системах обработки данных // СУБД. - 1995. - № 3.

[17] Кондратьев А.М. Объектные базы данных в CASE-средстве Real // см. наст. сб.

[18] Вендров А.М. Case-технологии. Современные методы и средства проектирования информационных систем. - М. Финансы и статистика, 1998. - 176 с.: ил.

[19] Патрик Нотон Java. Справочное руководство: Пер. С англ.- М.: Восточная Книжная Компания, 1996. - 448 с.: ил.