Основные элементы объектной модели

К основным элементам объектной модели относятся – объект, класс, атрибут, операция, интерфейс, компонент, связи.

Объект определяется как предмет или явление (процесс), имеющие четко определяемое пове­дение.Объект может представлять собой абстракцию некоторой сущности предметной области (объект реального мира) или прог­раммной системы (архитектурный объект). Любой объект обла­дает состоянием (state), поведением (behavior) и индивидуальностью (identity).

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

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

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

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

Рис. 1. Графическое представление класса

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

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

1. Public (общий, открытый). Атрибут будет виден всеми остальными классами. Лю­бой класс может просмотреть или изменить значение атрибута. В соответствии с нотацией UML обще­му атрибуту предшествует знак «+».

2. Private (закрытый, секретный). Атрибут не виден никаким другим классом. Если понадобит­ся, другой класс должен попросить класс-владелец просмотреть или изме­нить значение атрибута, что обычно делается с помощью общих операций. В соответствии с нотацией UML закрытый атрибут обозначается знаком «–».

3. Protected (защищенный). Атрибут доступен только само­му классу и его потомкам в иерархии наследования. Нотация UML для защищенного атрибута – это знак «#».

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

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

Операции реализуют связанное с классом поведение (обязанности класса).В широком смысле обязанности класса делятся на две категории.

1. Знание (определяется атрибутами класса):

· наличие информации о данных или вычисляемых величи­нах;

· наличие информации о связанных объектах.

2. Действие (определяется операциями класса):

· выполнение некоторых действий самим объектом;

· инициация действий других объектов;

· координация действий других объектов.

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

1. Операции реализации (implementor operations) реализуют некоторые функции (процедуры). Эти операции выявляются путем анализа диаграмм взаимодействия.

2. Операции управления (manager operations) управляют созданием и уничтожением объектов. В эту категорию попадают конструкторы и деструкторы классов.

3. Операции доступа (access operations) обеспечивают просмотр и изменение значений закрытых или защищенных атрибутов со стороны других классов.

4. Вспомогательные операции (helper operations) необходимы классу для выполнения его обязанностей, но другие классы не должны ничего знать о них. Это закрытые и защищенные операции класса.

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

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

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

· компонентом исходного кода;

· компонентом времени выполнения;

· исполняемым компонентом.

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

Ассоциация (association) – это семантическая связь между классами. Ее изображают на диаграмме классов в виде обыкновенной линии (рис. 2). Ассоциация отражает структурные связи между объектами различных классов.

Рис. 2. Ассоциация

Агрегация (aggregation) представляет собой форму ассоциации – более сильный тип связи между целым (составным) объектом и его частями (компонентными объектами). Сильная форма агрегации в UML называется композицией. В композиции составной объект может физически содержать компонентные объекты. Компонентный объект может принадлежать только одному составному объекту.

Слабая форма агрегации в UML называется просто агрегацией. При этом составной объект физически не содержит компонентный объект. Компонентный объект может обладать несколькими связями ассоциации или агрегации. Агрегация изображается линией между классами с ромбом на стороне целого объекта (рис. 3). Композицию представляет сплошной ромб.

Рис. 3. Агрегация

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

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

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

Рис. 4. Ролевые имена

Ролевые имена – это имена существительные или основанные на них фразы, их показывают на диаграмме рядом с классом, играющим соответствующую роль. Как правило, пользуются или ролевым именем, или именем связи, но не обоими сразу. Ролевые имена не обязательны, их дают, если смысл связи не очевиден.

Мощность (multiplicity) – это число объектов одного класса, связанных с одним объектом другого класса. Понятие мощности связи в объектной модели аналогично понятиям мощности в модели «сущность-связь». Для каждой связи можно обозначить два показателя мощности – по одному на каждом конце связи (рис. 5).

Рис. 5. Мощность связи

Частным случаем ассоциации является ассоциация-класс (Association class), которая обладает как свойствами класса, так и свойствами ассоциации. Ассоциация-класс – это место, где хранятся относящиеся к ассоциации атрибуты и операции. Экземплярами ассоциации-класса являются связи, у которых есть значения атрибутов. Ассоциация-класс подобна связи с атрибутами в модели «сущность-связь». Нотация UML для ассоциации-класса представлена на рис. 6.

Рис. 6. Ассоциация-класс

Допустим, имеются два класса Student (Студент) и Course (Курс) и возникла необходимость добавить атрибут Grade (Оценка). Возникает вопрос, в какой класс его добавить. Если поместить его в класс Student, то придется вводить его для каждого посещаемого студентом курса, что увеличит размер класса. Если поместить его в класс Course, то придется задавать его для каждого посещающего этот курс студента. Решить эту проблему можно, создав ассоциацию-класс. В этот класс следует поместить атрибут Grade, относящийся к связи между курсом и студентом.

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

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

Рис. 7. Зависимость

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

Обобщение (generalization) – связь «тип-подтип» реализует механизм наследования. Большинство объектно-ориентированных языков поддерживает концепцию наследования. Она позволяет одному классу наследовать все атрибуты, операции и связи другого. В языке UML связи наследования называют обобщениями и изображают в виде стрелок от класса-потомка к классу-предку (рис. 8).

Рис. 8. Обобщение

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

1.3. Общие сведения о языке UML

Унифицированный язык моделирования UML (Unified Modeling Language) представляет собой язык для определения, представления, проектирования и документирования программных, организационно-экономических, технических систем и других систем различной природы.Язык создан ведущими специалистами в области объектно-ориентированного анализа и проектирования Гради Бучем, Джеймсом Рамбо и Айваром Джекобсоном из корпорации Rational Software. Главными в разработке UML были следующие цели:

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

· предусмотреть механизмы расширяемости и специализации концепций;

· обеспечить независимость от конкретных языков программирования;

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

· стимулировать рост рынка объектно-ориентированных средств;

· интегрировать лучший практический опыт.

Язык UML признан в качестве стандарта независимым консорциумом OMG (Object Management Group), занимающимся стандартизацией объектных технологий. Его реализовали в своих продуктах многие фирмы-производители CASE -средств (Rational Rose, Natural Engineering Workbench, ARIS Toolset). Язык UML используется в ходе разработки программ разной сложности сотнями круп­нейших и тысячами средних и мелких компаний во всем мире. На основе языка выпускаются продукты, позволяющие переводить UML -модели в программный код (Java, C++, Visual Basic, Ada 95, Object Pascal), в таблицы реляционной базы данных.

Система UML -моделей включает структурные модели и модели поведения.

Структурные модели включают:

q диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними;

q диаграммы реализации (implementation diagrams):

· диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы;

· диаграммы размещения (deployment diagrams) – для моделирования физической архитектуры системы.

Модели поведения включают:

q диаграммы вариантов использования (use case diagrams) – для моделирования бизнес-процессов и функциональных требований;

q диаграммы взаимодействия (interaction diagrams):

· диаграммы последовательностей (sequence diagrams) – для моделирования процесса обмена сообщениями между объектами;

· кооперативные диаграммы (collaboration diagrams) – для той же цели;

· диаграммы состояний (statechart diagrams) – для моделирования поведения объектов системы при переходе из одного состояния в другое;

· диаграммы деятельностей (activity diagrams) – для моделирования поведения системы в рамках различных вариантов использования.

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

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

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

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

Действующее лицо (actor) – это роль, которую пользователь играет по отношению к системе. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. Показывать на диаграмме действующих лиц следует только в том случае, когда им действительно необходимы некоторые варианты использования. Действующие лица делятся на три основных типа:

· пользователи системы;

· внешние системы, взаимодействующие с данной системой;

· время (если от него зависит запуск каких-либо событий в системе).

Для наглядного представления вариантов использования применяются диаграммы вариантов использования (рис. 9).

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

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

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

· связи между действующими лицами не моделируются (действующие лица находятся вне сферы действия системы);

· не следует соединять стрелками варианты использования (диаграммы описывают только, какие варианты использования доступны системе, а не порядок их выполнения);

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

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

Конкретные детали описываются в документе, называемом «сценарий варианта использования»или «поток событий» (flow of events). Целью является подробное документирование процесса, реализуемого в рамках варианта использования. Этот документ описывает, что будут делать пользователи и что – сама система. Поток событий также не должен зависеть от реализации. Цель – описать то, что будет делать система, а не как она будет делать это.

Поток событий включает следующие пункты.

1. Краткое описание. Каждый вариант использования должен иметь краткое описание того, что в нем происходит.

2. Предусловия (pre-conditions). Предусловия варианта использования – это условия, которые должны быть выполнены, прежде чем вариант использования начнет выполняться сам. Таким условием может быть выполнение другого варианта использования или наличие у пользователя требуемых прав доступа. Предусловия бывают не у всех вариантов использования. С их помощью можно документировать порядок выполнения вариантов использования. Так, предусловием одного варианта использования может быть то, что в это время должен выполняться другой.

3. Основной и альтернативные потоки событий. Конкретные детали вариантов использования поэтапно описываются восновном и альтернативных потоках событий. Поток событий уделяет внимание тому, что будет делать система, причем описывает это с точки зрения пользователя. Основной поток описывает нормальный ход событий (при отсутствии ошибок) и может разветвляться на подчиненные потоки (subflow). Альтернативные потоки описывают отклонения от нормального хода событий (ошибочные ситуации) и их обработку.

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

· некорректные действия пользователя (например, ввод неверного пароля);

· бездействие действующего лица (например, истечением времени ожидания);

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

· критически важные недостатки в производительности системы (например, время реакции не укладывается в 5 секунд).

4. Постусловия (post-conditions). Постусловиями называются условия, которые всегда должны быть выполнены после завершения варианта использования. Например, в конце варианта использования можно пометить флажком какой-нибудь переключатель. С помощью постусловий также можно вводить информацию о порядке выполнения вариантов использования системы. Если после одного из вариантов использования должен всегда выполняться другой, это можно описать как постусловие. Постусловия имеются не у каждого варианта использования.

5. Расширения (extensions). Этот пункт присутствует, если в основном потоке событий происходят редко встречающиеся ситуации (частные случаи).

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

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

· явно указывать, кто выполняет действие – действующее лицо или система;

· не показывать незначительные действия;

· не показывать детальные действия пользователя в процессе работы с пользовательским интерфейсом;

· не рассматривать возможные ошибочные ситуации (использовать действия «подтвердить», а не «проверить»).

В языке UML между вариантами использования и действующими ли­цами поддерживается несколько типов связей.

Связь коммуникации (communication) – это связь между вариантом использования и действующим лицом. На языке UML связи коммуника­ции показывают с помощью однонаправленной ассоциации (линии со стрелкой). Направление стрелки позволяет понять, кто инициирует коммуникацию.

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

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

На языке UML связи включения и расширения показывают в виде зависимостей с соответствующими стереотипами.

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

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

Достоинства модели вариантов использования заключаются в том, что она:

· определяет пользователей и границы системы;

· определяет системный интерфейс;

· удобна для общения пользователей с разработчиками;

· используется для написания тестов;

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

· хорошо вписывается в любые методы проектирования (как объектно-ориентированные, так и структурные).