Правильный UML

Правильный UML – хорошо форматированный в соответствии со спецификацией UML. Однако всё находится в реальном мире и всё не так просто. Каким языком считать UML? Предписывающим, как языки программирования, или описательным? Сложившееся понимание в ИТ индустрии на данный момент – рассматривать UML как описательный язык. И в этом случае, всё, что считается правильным в разрабатываемом конкретной группой программистов проекте, и есть правильный UML. Формально можно написать персональную метамодель, и тогда мы получим новый, абсолютно формально правильный UML. Нужны ли такие усилия?

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

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

• диаграмма классов;

• диаграмма последовательности действий;

• диаграмма объектов;

• диаграмма пакетов;

• диаграмма Use cases;

• диаграмма активностей.

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

Это главная диаграмма, с которой работает программист. Она описывает типы объектов в системе и различные виды статических отношений, которые существуют между ними. Также здесь показываются свойства и операторы класса
и ограничения, которые накладываются на способ, которым они связаны. UML использует термин «свойство» как общий термин для свойств и операторов (методов) класса. Следует различать свойства как поднабор операторов следующих контракту Java Beans – get<Имясвойства>, set<Имясвойства>.

clip_image002

Рис. 3. «Свойства» классов

Свойства

Свойства представляют собой структурные особенности класса. В первом приближении можно думать о свойствах как о полях в классе. Действительность подправит понимание, но это хорошая стартовая точка для начала.

Свойства отображаются двумя существенно отличающимися нотациями:
в виде атрибута и в виде ассоциации. Они выглядят отличными друг от друга на диаграмме, но в действительности они одно и то же.

Атрибут – нотация, описывающая свойство текстовой строкой внутри изображения класса.

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

Отношение – нотация, описывающая свойство линией, соединяющей классы между собой. В объектно-ориентированном проектировании особое значение имеют четыре типа отношений: зависимости, обобщения, реализации и ассоциации.

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

clip_image004

Рис. 4. Отношение зависимости

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

clip_image005

Например, понятия CashPayment, CreditPayment, CheckPayment очень похожи, и разумно организовать их в иерархию обобщения, чтобы подчеркнуть специализацию классов. Класс Payment представляет более общее понятие, а его подклассы – специализированные свойства.

Рис. 5. Отношение обобщения

Подкласс создается в случаях, если:

· имеет дополнительные атрибуты;

· имеет дополнительные ассоциации;

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

· представляет объекту поведение, которое отлично от поведе­ния, определяемого суперклассом или другими подклассами.

Отношение обобщения реализуется при наследовании классов.

clip_image006

Реализацией (Realization) называется отношение между классификаторами (классами, интерфейсами), при котором один описывает контракт (интерфейс сущности), а другой гарантирует его выполнение.

Рис. 6. Отношение реализации

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

clip_image008

Рис. 7. Отношение ассоциации

Одним из вариантов отношения ассоциации является агрегация.

clip_image009

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

clip_image011

Рис. 8. Отношения коллективной агрегации и композиции

Множественность
clip_image012

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

Рис. 9. Множественность

/* пример # 1: множественность отношений между классами :

EmployeeCustomer.java */

public class EmployeeCustomer {

private int ID = 0;

private PageBean pageBean = null;

public int getID() {

return this.ID;

}

public void setID(int newID) {

this.ID = newID;

}

public PageBean getPageBean() {

return this.pageBean;

}

}

clip_image013

Двунаправленная ассоциация

Рис. 11. Двунаправленная ассоциация

/* пример # 2: взаимная видимость классов : Wallet.java, CreditCard.java */

public class Wallet {

private List<CreditCard> creditCards = null;

public void addCreditCard(CreditCard newCreditCard) {

creditCards.add(newCreditCard);

}

}

public class CreditCard {

private Wallet wallet = null;

public void setWallet(Wallet newWallet) {

this.wallet = newWallet;

}

}

Операторы

Наиболее очевидный пример оператора – метод класса. То есть операторы можно рассматривать как действия, которые класс знает, как выполнить. Хотя getter и setter для свойства тоже являются методами, как правило, их не указывают на диаграммах, так как их наличие очевидно в соответствии с конкрактом Java Beans. Обычно их указывают на диаграммах в случае несимметричного использования, например, класс может иметь только getter-методы по каким-то специфическим причинам.

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

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

Вы можете следить за любыми ответами на эту запись через RSS 2.0 ленту. Вы можете оставить ответ, или trackback с вашего собственного сайта.

3 коммент. »

 
  • Это точно !!

  • Владислав says:

    Почему такие рисунки маленькие, неразборчиво?Или там конф. инф.?:-)

  • Владислав says:

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

 

Оставьте отзыв

XHTML: Вы можете использовать следующие теги: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

 
Rambler's Top100