Успешное прохождение Java сертификации, Часть 4: SCEA

Основные понятия

Введение

Моделирование программного обеспечения включает в себя этап проектирования, который предшествует непосредственному программированию приложений. Создание модели позволяет получить более точное понимание системы еще до ее разработки. Универсальный язык моделирования (UML) - как раз является одним из языков моделирования, который вы можете использовать для уточнения, визуализации и документирования моделей систем программного обеспечения, в том числе их структуры и схемы, в соответствии с требованиями. Однако необходимо помнить, что UML - это всего лишь язык моделирования, а не методология процесса. На практике, UML зачастую используется совместно с методологией процесса. Данный пример основан на UML версии 1.x.

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

UML: Строительные блоки

Существует три вида строительных блоков UML:

• Сущности (Elements)
• Отношения (Relationships)
• Диаграммы (Diagrams)

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

В начало

UML: Сущности

Выделяют всего четыре типа сущностей (Elements):

• Структурные
• Поведенческие
• Группирующие
• Аннотационные

Структурные

Эти сущности подобны существительным в языке.

Название	Определение	Обозначение
Класс	Совокупность объектов с общими атрибутами, операциями, отношениями и семантикой. Графически класс обозначается в виде прямоугольника с тремя полями: имя класса, атрибуты (свойства) класса и операции (методы) класса.
Интерфейс	Совокупность операций, которые определяют сервис класса или компонента. Графически интерфейс также обозначается в виде прямоугольника с тремя полями: имя интерфейса, его атрибуты и операции. Над именем интерфейса дополнительно указывается слово "интерфейс" ("interface").
Кооперация (Collaboration)	Определяет взаимодействие и представляет собой совокупность ролей и других элементов, которые работают совместно для обеспечения кооперативного поведения, большего, чем сумма всех элементов. Графически кооперация обозначается в виде пунктирного эллипса.
Прецедент (Use case)	Описание последовательности действий, выполняемых системой для получения наблюдаемого результата, значимого для актера. Графически прецедент обозначается в виде эллипса, внутри которого указано имя прецедента.
Активный класс	Класс, представители которого являются активными объектами и вовлечены в один или несколько процессов или потоков и могут инициировать деятельность по контролю.
Компонент	Физическая заменяемая часть системы, которая соответствует и обеспечивает реализацию набора интерфейсов.
Узел (Node)	Физический элемент, который существует во время выполнения программы и представляет собой вычислительный ресурс, обладающий некоторым объемом памяти и способностью обрабатывать данные.

Поведенческие

Определяют динамическую составляющую элементов UML.

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

Группирующие

Название	Определение	Обозначение
Пакет	Универсальный механизм организации элементов в группы.

Аннотационные

Название	Определение	Обозначение
Примечание	Просто символ для обозначения комментариев, закрепленных за другими элементами или совокупностями элементов.

В начало

UML: Отношения

Отношения

В языке UML определено четыре типа отношений:

• Зависимость
• Ассоциация
• Обобщение
• Реализация

Зависимость

Зависимость - это семантическое отношение между двумя сущностями, при котором изменение в одной сущности может оказать влияние на семантику другой сущности. Стрелка показывает направление зависимости. На диаграмме MyClass1 находится в зависимости от MyClass2. Изменения в MyClass2 оказывают влияние на MyClass1.

Ассоциация

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

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

Различают два типа ассоциаций:

• Агрегирование
• Композиция

Агрегирование отражает отношение между целым и частью. Агрегирование обозначается на одном конце ассоциации, в то время как второй конец остается немаркированным. На рисунке, Myclass2 является частью Myclass1.

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

Обобщение

Обобщение - это отношение типа "родитель-потомок". MyClass2 - суперкласс (родитель), а MyClass1 - подкласс (потомок). На языке программирования Java, обобщение реализуется посредством дочерних объектов с использованием зарезервированного слова extends.

Реализация

Реализация - это отношение между интерфейсом и реализованным классом. В языке Java реализация выполняется реализацией интерфейса с использованием зарезервированного слова implements.

В начало

Общие механизмы

В данной работе обсуждаются следующие общие механизмы:

• Спецификации
• Дополнения
• Принятые деления
• Механизмы расширения

Спецификации

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

Дополнения

Используйте дополнения для отображения дополнительных состояний, например, является ли класс абстрактным, или видимость (область действия) атрибутов или операций (+public, #protected, -private).

Принятые деления

Если в диаграмме классов имя элемента отмечено подчеркиванием, то он является экземпляром класса (класс есть экземпляр класса). :class обозначает анонимный экземпляр класса, а named:class обозначает именованный экземпляр класса.

Механизмы расширения

Механизмы расширения позволяют настраивать и расширять UML и включают стереотипы, помеченные значения и ограничения.

В начало

UML: Диаграммы

В данной работе обсуждаются следующие UML диаграммы:

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

Диаграмма прецедентов

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

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

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

Диаграмма классов

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

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

На диаграмме классов, приведенной ниже, статическая структура описана вокруг главной сущности - Customer (покупатель), который связан с набором других классов, например Address (адрес), Order (заказ), и интерфейсом Payment (платеж). У покупателя может быть несколько Addresses (адресов) - (адрес доставки, расчетный адрес, дополнительный адрес доставки, и так далее) смоделированных агрегированием. Также у покупателя может быть отношение ассоциации с интерфейсом Payment (платеж) и классом Order (заказ). Интерфейс Payment (платеж) может быть либо CreditCard (кредитной картой) либо DebitCard (дебетовой картой), которые являются двумя реализационными моделями интерфейса Payment (платеж). У каждого заказа может быть много присоединенных OrderItems (предметов заказа). Так как OrderItem (предмет заказа) не может существовать без Order (заказ), то отношение смоделировано как композиция. PrivilegedCustomer (привилегированный покупатель) это особый Customer (покупатель), у которого есть скидки на сделанные покупки, и который является продолжением Customer (покупатель) на основе отношения обобщения. Навигация указывает направление перемещения по ассоциации. Кратность описывает возможные сущности. .

В начало

UML: диаграммы, продолжение

Диаграмма пакетов

Диаграмма пакетов отражает организацию систем в группах и может рассматриваться как особый вид диаграммы классов. Классы группируются в пакеты и обозначаются в виде прямоугольника с "закладкой" с правой стороны. Пунктирные стрелки отражают зависимости. В нижеприведенном примере три пакета: Customer (покупатель), Order (заказ), и ShoppingUI (номер покупки). Изменения в классах пакета Customer (покупатель) окажут влияние на классы пакета Order (заказ), и поэтому они отображаются отношением зависимости.

Диаграмма взаимодействий

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

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

В приведенной ниже последовательности Administrator (администратор) инициирует последовательность, посылая сообщение createAccount(name,address) (создать счет(имя,адрес)) классу AccountManager (менеджер счетов) для создания нового счета покупателя. AccountManager (менеджер счетов) в свою очередь создает новый класс Account (счет) и, посылая сообщения, задает различные свойства класса, например setName(name) (задать имя(имя)) и setAddress(address) (задать адрес(адрес)). В конечном итоге, возвращается вновь созданный объект Account (счет).

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

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

На приведенной ниже диаграмме коопераций прямоугольники отображают объекты, а объекты обозначены следующим образом: "имя объекта: имя класса". У сообщений имеется порядковый номер. Первое инициирующее сообщение обозначено номером 1. Такие сообщения, как, например, create (создать) и setName() (задать имя()), снабжаются одинаковым десятичным префиксом для указания, что они являются частью одного запроса; а увеличивающийся суффикс указывает на очередность их появления.

В начало

UML: диаграммы, продолжение

Диаграмма состояний

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

В примере, приведенном ниже, всего три состояния: Login (регистрация), Getting product name (получение названия продукта), и Catalog page (страница каталога), обозначенные прямоугольниками с закруглёнными углами. Стрелки обозначают переходы. Исходное состояние, обозначенное черным кружочком - фиктивное состояние для начала действия. События или условия инициирующие транзакцию указаны метками на стрелках. Из состояния Login (регистрации) приложение переходит в состояние Getting product name (получения названия продукта). Если продукт обнаружен (отражается условием [item found] (пункт найден)), то приложение переходит к Catalog page (странице каталога). С другой стороны, если продукт не обнаружен, то происходит переход в то же самое состояние. Конечное состояние обозначается концентрическим бело-черным кружочком.

Диаграмма деятельности

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

В приведенном ниже примере процесс начинается с фиктивного состояния, которое обозначено черным кружочком. Деятельности обозначены прямоугольниками с закругленными углами, а поток между деятельностями - стрелками. После деятельности Place order (размещение заказа), в результате который получены все необходимые данные, например адрес доставки и номер кредитной карты, переход разветвляется на две параллельные деятельности Prepare for shipping (подготовка к доставке) и Process billing (процесс оформления счета). В конечном итоге, обе параллельные деятельности объединяются в один переход и заканчиваются в фиктивном состоянии, которое обозначено концентрическим бело/черным кружочком. Ветвление и объединение обозначаются сплошной линией.

При разветвлении перехода, защитные выражения (например [isUrgent=true] и [isUrgent=false]) отмечают переходы. Пустые ромбы обозначают разветвление на несколько переходов и объединение в один переход.

В начало

UML: диаграммы, продолжение

Диаграмма компонентов

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

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

Диаграмма развертывания

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

Куб обозначает узел, а ассоциативная связь отражает физическую связь между узлами. В приведенном ниже примере, узел DB2Server обозначает узел базы данных, в котором размещен компонент базы данных OrderDB. Доступ к данным происходит через IOrder интерфейс, обозначенный символом окружности. Компонент Web-контейнера находится в зависимости от IOrder, которая обозначена пунктирной линией со стрелкой.

В начало

Инкапсуляция, наследование и использование интерфейса

Инкапсуляция

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

Инкапсуляция важна для:

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

Наследование

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

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

На основании вышесказанного, группа GOF установила два принципа проектирования:

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

В начало

Заключение

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

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

В начало

Проверь себя

Вопрос 1:

Какие из двух типов приведенных диаграмм могут быть получены друг из друга?

Варианты ответа:

• A. Диаграмма последовательностей
• B. Диаграмма деятельности
• C. Диаграмма коопераций
• D. Диаграмма состояний

Правильный ответ:

A и C

Объяснение:

Ответы A и C являются правильными.

Диаграммы последовательностей и коопераций изоморфны (то есть, диаграмма одного типа может быть преобразована в диаграмму другого типа). Следовательно, правильный ответ: A и C.

Диаграммы деятельности и состояний не обладают такими взаимоотношениями, следовательно, эти ответы неправильны.

Вопрос 2:

Какое отношение между двумя классами отображено на рисунке?

Варианты ответа:

• A. Ассоциация
• B. Обобщение
• C. Композиция
• D. Сильная зависимость
• E. Агрегирование

Правильный ответ:

C

Объяснение:

Правильный ответ: C.

Композиция, более сильная форма агрегации, обозначается ромбом со сплошной закраской. Следовательно, правильный ответ: C.

Ответ A неверен, так как ассоциация обозначается просто линией.

Ответ B неверен, так как обобщение - это отношение наследования и обозначается линией с незакрашенной стрелкой на конце.

Ответ D неверен в силу того, что в UML нет термина "сильная зависимость".

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

2 из 15 | предыдущая | следующая

Комментарии

В начало

Содержание

• Введение
• Основные понятия
• Стандартные архитектуры
• Наследование связности
• Enterprise JavaBeans
• Модель контейнера Enterprise JavaBeans
• Протоколы
• Применение J2EE-технологии
• Шаблоны проектирования (Design patterns)
• Передача сообщений
• Интернационализация
• Безопасность
• Заключительная часть
• Ресурсы
• Об авторе

---

2 из 15 | предыдущая | следующая