Язык UML. Руководство пользователя

       

в UML всегда помните, что


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

    При моделировании отношений в UML соблюдайте следующие правила:
  • используйте зависимость, только если моделируемое отношение не является структурным;
  • используйте обобщение, только если имеет место отношение типа "является";
  • множественное наследование часто можно заменить агрегированием;
  • остерегайтесь циклических отношений обобщения;
  • поддерживайте баланс в отношениях обобщения: иерархия наследования не должна быть ни слишком глубокой (желательно не более пяти уровней), ни слишком широкой (лучше прибегнуть к промежуточным абстрактным классам);
  • применяйте ассоциации прежде всего там, где между объектами существуют структурные отношения.
    При изображении отношений в UML руководствуйтесь нижеследующими рекомендациями:
  • выбрав один из стилей оформления линий (прямые или наклонные), в дальнейшем старайтесь его придерживаться. Прямые линии подчеркивают, что соединения идут от родственных сущностей к одному общему родителю. Наклонные линии позволяют существенно сэкономить пространство в сложных диаграммах. Если вы хотите привлечь внимание к разным группам отношений, применяйте одновременно оба типа линий;
  • избегайте пересечения линий;
  • показывайте только такие отношения, которые необходимы для понимания особенностей группирования элементов модели; скрывайте несущественные (особенно избыточные) ассоциации.
    [Предыдущая глава]
    [Содержание]
    [Следующая глава]




    Включая в модель примечания в виде дополнений:
  • используйте примечания для описания только тех требований, наблюдений, обзоров и пояснений, которые нельзя выразить с помощью стандартных средств UML;
  • используйте примечания в качестве электронной памятки, отслеживая с их помощью ход работы.
    Изображая примечания, не перегружайте модель большими объемными комментариями. Если длинный комментарий действительно необходим, помещайте в примечания ссылку на документ, содержащий полный текст.
    Расширяя модель за счет новых стереотипов, помеченных значений и ограничений, руководствуйтесь следующими принципами:
  • определите небольшое число этих механизмов в качестве стандартных для проекта и не позволяйте разработчикам создавать ничего лишнего;
  • выбирайте короткие осмысленные названия для стереотипов и помеченных значений;
  • если точность описания не слишком важна, определяйте ограничения в свободной форме;
  • в противном случае используйте язык ОСL.
    Изображая стереотипы, помеченные значения и ограничения, действуйте согласно следующим правилам:
  • прибегайте к графическим стереотипам только в случае острой необходимости. С помощью стереотипов можно полностью изменить базовую нотацию UML, но тогда уже никто, кроме вас, не поймет модель;
  • подумайте, не стоит ли раскрасить или оттенить графические стереотипы и более сложные пиктограммы. Как правило, чем проще нотация, тем она лучше, и даже самых простых визуальных образов бывает вполне достаточно для передачи смысла.
    [Предыдущая глава]
    [Содержание]
    [Следующая глава]


    При разработке диаграмм руководствуйтесь следующими правилами:
  • помните, что цель создания диаграмм на языке UML - не рисование красивых картинок, а визуализация, специфицирование, конструирование и документирование. Диаграммы - это только одно из средств, помогающих привести разработку программной системы к успешному завершению;
  • не все диаграммы необходимо сохранять. Иногда стоит создавать их "на лету", путем опроса элементов модели, и использовать для анализа системы по мере ее построения. Многие диаграммы такого рода можно будет выбросить после того, как они выполнят свое назначение (хотя семантика, лежащая в их основе, останется частью модели);
  • избегайте избыточных диаграмм, они только загромождают модель;
  • каждая диаграмма должна содержать только необходимые для ее целей детали. Лишняя информация отвлечет внимание читателя от более важных элементов модели;
  • старайтесь не делать диаграммы слишком краткими, если только не хотите представить что-либо на очень высоком уровне абстракции. Чрезмерное упрощение может скрыть детали, важные для понимания модели;
  • поддерживайте баланс между структурными диаграммами и диаграммами поведения. Очень немногие системы являются только статическими или только динамическими;
  • не делайте диаграммы очень большими (если объем превышает несколько печатных страниц, это затрудняет навигацию) или очень маленькими (в последнем случае лучше объединить несколько простых диаграмм в одну);
  • y каждой диаграммы должно быть осмысленное имя, ясно отражающее ее назначение;
  • организуйте диаграммы, группируя их в пакеты в соответствии с представлением;
  • не обременяйте себя форматированием диаграммы - используйте для этого соответствующие инструменты.
    Хорошо структурированная диаграмма обладает следующими свойствами:
  • заостряет внимание на одном аспекте некоторого представления системы;
  • содержит только элементы, существенные для понимания этого аспекта;
  • содержит детали, соответствующие выбранному уровню абстракции (не обременена деталями, без которых можно обойтись);
  • не настолько лаконична, чтобы ввести читателя в заблуждение относительно важных аспектов семантики.
    Изображая диаграмму, воспользуйтесь нижеприведенными рекомендациями:
  • дайте диаграмме имя, соответствующее ее назначению;
  • расположите элементы так, чтобы свести к минимуму число пересечений;
  • пространственно организуйте элементы так, чтобы семантически близкие сущности располагались на диаграмме рядом;
  • используйте примечания и цвет, чтобы привлечь внимание читателя к важным особенностям диаграммы.
    [Предыдущая глава]
    [Содержание]
    [Следующая глава]


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


    Моделируя классификаторы в языке UML, помните, что в вашем распоряжении имеется множество строительных блоков - интерфейсы, классы, компоненты и т.д. Из них вы должны выбрать тот, который наилучшим образом соответствует вашей абстракции. Хорошо структурированный классификатор обладает следующими свойствами:
  • наделен как структурными, так и поведенческими аспектами;
  • внутренне согласован и слабо связан с другими классификаторами;
  • раскрывает только те особенности, которые необходимы для использующих класс клиентов, и скрывает остальные;
  • его семантика и назначение не допускают неоднозначного толкования;
  • не настолько формализован, чтобы лишить всякой свободы тех, кто будет его реализовывать;
  • специфицирован в достаточной степени, чтобы исключить неоднозначное толкование его назначения.
    Изображая классификатор в UML, примите во внимание следующие рекомендации:
  • показывайте только те его свойства, которые необходимы для понимания абстракции в контексте класса;
  • используйте такие стереотипы, которые наилучшим образом отражают назначение классификатора.
    [Предыдущая глава]
    [Содержание]
    [Следующая глава]


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


    Моделируя интерфейс на языке UML, помните, что он должен описывать некоторый стыковочный узел системы, отделяя спецификацию от реализации. Хорошо структурированный интерфейс характеризуется следующими свойствами:
  • одновременно обладает простотой и завершенностью, то есть содержит все операции, необходимые и достаточные для специфицирования конкретного сервиса;
  • понятен, то есть содержит информацию, достаточную для его применения, и не требует для этого обращения к его реализации и примерам использования;
  • содержит информацию, достаточную для понимания пользователем основных свойств, но не перегружен сведениями, касающимися деталей всех операций.
    Изображая интерфейс на языке UML, руководствуйтесь приведенными ниже правилами:
  • используйте сокращенную нотацию, если надо просто показать наличие стыковочного узла в системе. Чаще всего она применяется при работе с компонентами, а не с классами;
  • расширенную форму применяйте в случае, если надо визуализировать детали самого сервиса. Чаще всего это нужно делать при специфицировании стыковочных узлов в системе, содержащей пакеты или подсистемы.
    [Предыдущая глава]
    [Содержание]
    [Следующая глава]


    Моделируя пакеты в UML, помните, что они нужны только для организации элементов вашей модели. Если имеются абстракции, непосредственно материализуемые как объект в системе, не пользуйтесь пакетами. Вместо этого применяйте такие элементы моделирования, как классы или компоненты. Хорошо структурированный пакет характеризуется следующими свойствами:
  • он внутренне согласован и очерчивает четкую границу вокруг группы родственных элементов;
  • он слабо связан и экспортирует в другие пакеты только те элементы, которые они действительно должны "видеть", а импортирует лишь элементы, которые необходимы и достаточны для того, чтобы его собственные элементы могли работать;
  • глубина вложенности пакета невелика, поскольку человек не способен воспринимать слишком глубоко вложенные структуры;
  • владея сбалансированным набором элементов, пакет по отношению к другим пакетам в системе не должен быть ни слишком большим (если надо, расщепляйте его на более мелкие), ни слишком маленьким (объединяйте элементы, которыми можно манипулировать как единым целым).
    Изображая пакет в UML, руководствуйтесь следующими принципами:
  • применяйте простую форму пиктограммы пакета, если не требуется явно раскрыть его содержимое;
  • раскрывая содержимое пакета, показывайте только те элементы, которые абсолютно необходимы для понимания его назначения в данном контексте;
  • моделируя с помощью пакетов сущности, относящиеся к управлению конфигурацией, раскрывайте значения меток, связанных с номерами версий.
    [Предыдущая глава]
    [Содержание]
    [Следующая глава]


    Моделируя экземпляры на языке UML, помните, что каждый из них должен обозначать конкретную материализацию некоторой абстракции (обычно - класса, компонента, узла, прецедента или ассоциации). Хорошо структурированный экземпляр обладает следующими свойствами:
  • явно ассоциирован с конкретной абстракцией;
  • имеет уникальное имя, взятое из словаря предметной области или области решения.
    Изображая экземпляры в UML, руководствуйтесь следующими принципами:
  • всегда показывайте имя абстракции, которой принадлежит экземпляр, если это не очевидно из контекста;
  • показывайте стереотип, роль или состояние экземпляра, только если это необходимо для понимания объекта в данном контексте. В таких случаях организуйте длинные списки атрибутов экземпляра, группируя их вместе с их значениями в соответствии с категориями.
    [Предыдущая глава]
    [Содержание]
    [Следующая глава]


    Создавая диаграммы объектов на языке UML, помните, что каждая такая диаграмма - это всего лишь графическое представление статического вида системы с точки зрения проектирования или процессов. Это означает, что ни одна отдельно взятая диаграмма объектов не в состоянии передать всю заключенную в этих видах информацию. На самом деле во всех системах, кроме самых тривиальных, существуют сотни, а то и тысячи объектов, большая часть которых анонимна. Полностью специфицировать все объекты системы и все способы, которыми они могут быть ассоциированы, невозможно. Следовательно, диаграммы объектов должны отражать только некоторые конкретные объекты или прототипы, входящие в состав работающей системы.
    Хорошо структурированная диаграмма объектов характеризуется следующими свойствами:
  • акцентирует внимание на одном аспекте статического вида системы с точки зрения проектирования или процессов;
  • представляет лишь один из кадров динамического сценария, показанного на диаграмме взаимодействия;
  • содержит только существенные для понимания данного аспекта элементы;
  • уровень ее детализации соответствует; уровню абстракции системы. (Показывайте только те значения атрибутов и дополнения, которые существенны для понимания);
  • не настолько лаконична, чтобы ввести читателя в заблуждение относительно важной семантики.
    Изображая диаграмму объектов, придерживайтесь следующих правил:
  • давайте ей имя, соответствующее назначению;
  • располагайте элементы так, чтобы число пересечений было минимальным;
  • располагайте элементы так, чтобы семантически близкие сущности оказывались рядом;
  • используйте примечания и цвет для привлечения внимания к важным особенностям диаграммы;
  • включайте в описания каждого объекта значения, состояния и роли, если это необходимо для понимания ваших намерений.
    [Предыдущая глава]
    [Содержание]
    [Следующая глава]


    Моделируя взаимодействия на языке UML, помните, что они отражают динамические аспекты совокупности объектов. Хорошо структурированное взаимодействие обладает следующими свойствами:
  • является достаточно простым и охватывает только такие объекты, в результате совместной работы которых достигается поведение более значимое, чем сумма его составных частей;
  • обладает четко определенным контекстом. Это может быть контекст операции, класса или системы в целом;
  • является эффективным и реализует описываемое поведение при оптимальных затратах времени и ресурсов;
  • легко адаптируется для применения в различных задачах: элементы взаимодействия, которые с большой вероятностью могут изменяться, должны быть изолированы, что облегчит задачу модификации в будущем;
  • доступно, не грешит запутанностью, обходится без скрытых побочных эффектов или неочевидной семантики.
    При рисовании диаграммы взаимодействия в UML руководствуйтесь следующими принципами:
  • выберите аспект взаимодействия, на котором требуется акцентировать внимание. Это может быть либо временное упорядочение сообщений, либо их последовательность в контексте той или иной структурной организации объектов. Нельзя показать то и другое одновременно;
  • указывайте только такие свойства объектов (значения атрибутов, роли и состояния), которые важны для понимания взаимодействия в выбранном контексте;
  • отображайте только такие свойства сообщений (параметры, семантику параллелизма или возвращаемое значение), которые необходимы для понимания взаимодействия в выбранном контексте.
    [Предыдущая глава]
    [Содержание]
    [Следующая глава]


    Моделируя прецеденты в UML, помните, что каждый из них должен представ лять некоторое четко идентифицируемое поведение системы или ее части. Хоро шо структурированный прецедент обладает следующими свойствами:
  • именует простое, идентифицируемое и в некоторой степени атомарное пове дение системы или ее части;
  • выделяет общее поведение, извлекая его из всех прецедентов, которые его включают;
  • выделяет вариации, помещая некоторое поведение в другие прецеденты, которые его расширяют;
  • описывает поток событий в степени, достаточной для понимания посторонним читателем;
  • описывается с помощью минимального набора сценариев, специфицирующих его нормальную и дополнительную семантику.
    Изображая прецеденты в UML, пользуйтесь следующими правилами:
  • показывайте только такие прецеденты, которые важны для понимания поведения системы или ее части в данном контексте;
  • показывайте только те актеры, которые связаны с этими прецедентами.
    [Предыдущая глава]
    [Содержание]
    [Следующая глава]


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


    Создавая диаграммы взаимодействий в UML, помните, что и диаграммы последовательностей, и диаграммы кооперации являются проекциями динамических аспектов системы на одну и ту же модель. Ни одна диаграмма взаимодействий, взятая в отдельности, не может охватить все динамические аспекты. Для моделирования динамики системы в целом, равно как и ее подсистем, операций, классов, прецедентов и коопераций, лучше использовать сразу несколько диаграмм взаимодействий.
    Хорошо структурированная диаграмма взаимодействий обладает следующими свойствами:
  • акцентирует внимание только на одном аспекте динамики системы;
  • содержит только такие прецеденты и актеры, которые важны для понимания этого аспекта;
  • содержит только такие детали, которые соответствуют данному уровню абстракции, и только те дополнения, которые необходимы для понимания системы;
  • не настолько лаконична, чтобы ввести читателя в заблуждение относительно важных аспектов семантики.
    При изображении диаграммы взаимодействий следует пользоваться нижеприведенными рекомендациями:
  • дайте ей имя, соответствующее ее назначению;
  • используйте диаграмму последовательностей, если хотите подчеркнуть временную упорядоченность сообщений, и диаграмму кооперации - если хотите подчеркнуть структурную организацию участвующих во взаимодействии объектов;
  • расположите элементы так, чтобы свести к минимуму число пересечений;
  • пространственно организуйте элементы так, чтобы семантически близкие сущности на диаграмме располагались рядом;
  • используйте примечания и цвет, чтобы привлечь внимание читателя к важным особенностям диаграммы;
  • не злоупотребляйте ветвлениями. Сложные ветвления лучше показывать на диаграммах деятельности.
    [Предыдущая глава]
    [Содержание]
    [Следующая глава]


    Создавая в UML диаграммы деятельности, не забывайте, что они лишь моделируют срез некоторых динамических аспектов поведения системы. С помощью единственной диаграммы деятельности никогда не удастся охватить все динамические аспекты системы. Вместо этого следует использовать разные диаграммы деятельности для моделирования динамики рабочих процессов или отдельных операций.
    Диаграмму деятельности можно признать хорошо структурированной, если она:
  • сконцентрирована на описании одного аспекта динамики системы;
  • содержит только те элементы, которые существенны для понимания этого аспекта;
  • представляет лишь те детали, которые соответствуют своему уровню абстракции; не должно быть дополнений, которые не являются необходимыми для понимания;
  • не настолько кратка, чтобы читатель упустил из виду важные аспекты семантики.
    Рисуя диаграмму деятельности, руководствуйтесь следующими принципами:
  • дайте диаграмме имя, соответствующее ее назначению;
  • начинайте с моделирования главного потока. Ветвления, параллельность и траектории объектов являются второстепенными деталями, которые можно изобразить на отдельной диаграмме;
  • располагайте элементы так, чтобы число пересечений было минимальным;
  • используйте примечания и закраску, чтобы привлечь внимание к важным особенностям диаграммы.
    [Предыдущая глава]
    [Содержание]
    [Следующая глава]


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


    При моделировании автоматов в UML помните, что каждый автомат представляет динамические аспекты поведения отдельного объекта - как правило, экземпляра класса, прецедента или системы в целом. Хорошо структурированный автомат обладает следующими свойствами:
  • он прост и не содержит избыточных состояний или переходов;
  • имеет ясный контекст и потому может получить доступ ко всем объектам, видимым из объемлющего объекта (такие соседи должны использоваться только при необходимости обеспечить поведение, специфицированное автоматом);
  • эффективен и реализует моделируемое поведение с оптимальным балансом времени и ресурсов в соответствии с требованиями, которые накладывают выполняемые им действия;
  • легок для понимания, в частности потому, что имена всех состояний и пере- ходов взяты из словаря системы (см. главу 4);
  • его глубина вложенности не слишком велика (ограничивается одним-двумя уровнями для обработки наиболее сложных аспектов поведения);
  • использует параллельные состояния в умеренном количестве, поскольку ак-тивные объекты зачастую подходят лучше.
    Изображая автомат в UML, руководствуйтесь следующими принципами:
  • избегайте пересекающихся переходов;
  • раскрывайте составные состояния в месте расположения только в том случае, если это делает диаграмму более понятной.
    [Предыдущая глава]
    [Содержание]
    [Следующая глава]


    Хорошо структурированный активный класс и активный объект обладают следующими свойствами:
  • представляют независимый поток управления, который максимально использует потенциальные возможности истинного параллелизма в системе;
  • не настолько мелки, чтобы требовать наличия множества других активных элементов, которое может привести к переусложненной и нестабильной архитектуре процессов;
  • аккуратно управляют коммуникацией между активными элементами, выбирая наиболее подходящий случаю механизм - синхронный или асинхронный;
  • исходят из трактовки каждого объекта как критической области, используя подходящие синхронизирующие свойства для сохранения его семантики в присутствии нескольких потоков управления;
  • явно разграничивают семантику процесса и нити.
    Рисуя в UML активный класс или активный объект:
  • показывайте только те атрибуты, операции и сигналы, которые важны для понимания абстракции в соответствующем контексте;
  • явно показывайте все синхронизирующие свойства операции.
    [Предыдущая глава]
    [Содержание]
    [Следующая глава]


    Хорошо структурированная модель с пространственно-временными свойствами обладает следующими особенностями:
  • описывает только те пространственно-временные свойства, которые необходимы и достаточны для понимания желаемого поведения системы;
  • централизует использование этих свойств, так чтобы их легко было найти и модифицировать.
    Изображая в UML пространственное или временное свойство, руководствуйтесь следующими принципами:
  • давайте отметкам времени (то есть соответствующим сообщениям) осмысленные имена;
  • проводите явное различие между временными выражениями, значениями которых является абсолютное и относительное время;
  • пространственные свойства показывайте преимущественно с помощью помеченных значений. Вложенную форму применяйте только тогда, когда важно визуализировать местонахождение элементов в развернутой системе.
    [Предыдущая глава]
    [Содержание]
    [Следующая глава]


    При создании диаграммы состояний в UML не забывайте, что все диаграммы -это лишь проекции динамических аспектов одной и той же системы. Одна диаграмма состояний может описать семантику одного реактивного объекта, но никогда - семантику всей системы, за исключением самых тривиальных случаев.
    Хорошо структурированная диаграмма состояний обладает следующими свойствами:
  • сосредоточена на описании какого-либо одного аспекта динамики системы;
  • содержит только те элементы, которые существенны для понимания этого аспекта;
  • описывает лишь детали, которые соответствуют своему уровню абстракции;
  • сбалансированно использует стилистику машин Мили и Мура.
    При изображении диаграммы состояний пользуйтесь следующими рекомендациями:
  • дайте ей имя, соответствующее назначению;
  • начинайте с моделирования устойчивых состояний объекта, затем переходите к допустимым переходам состояний. Ветвления, параллельность и траектории объектов являются второстепенными деталями, которые можно изобразить на отдельной диаграмме;
  • располагайте элементы так, чтобы число пересечений было минимальным.
    [Предыдущая глава]
    [Содержание]
    [Следующая глава]


    Моделируя компоненты в UML, помните, что вы моделируете физические аспекты системы. Хорошо структурированный компонент обладает следующими свойствами:
  • предоставляет четкую абстракцию некоторой сущности, которая является частью физического аспекта системы;
  • предоставляет реализацию небольшого, хорошо определенного набора интерфейсов;
  • включает набор классов, которые, действуя совместно, реализуют семантику интерфейсов изящно и экономно;
  • слабо связан с другими компонентами; как правило, компоненты моделируются только совместно с отношениями зависимости и реализации.
    Изображая компонент в UML, руководствуйтесь следующими правилами:
  • применяйте свернутую форму интерфейса, если только не возникает острой необходимости раскрыть операции, предлагаемые этим интерфейсом;
  • показывайте только те интерфейсы, которые необходимы для понимания назначения компонента в данном контексте;
  • в тех случаях, когда вы используете компоненты для моделирования библиотек и исходного кода, указывайте помеченные значения, относящиеся к контролю версий.
    [Предыдущая глава]
    [Содержание]
    [Следующая глава]


    Хорошо структурированный узел обладает следующими свойствами:
  • представляет четкую абстракцию некоей сущности из словаря аппаратных средств области решения;
  • декомпозирован только до уровня, необходимого для того, чтобы донести ваши идеи до читателя;
  • раскрывает только те атрибуты и операции, которые относятся к моделируемой области;
  • явно показывает, какие компоненты на нем развернуты;
  • связан с другими узлами способом, отражающим топологию реальной системы.
    Изображая узел в UML, руководствуйтесь следующими принципами:
  • определите для своего проекта или организации в целом набор стереотипов с подходящими пиктограммами, которые несут очевидную для читателя смысловую нагрузку;
  • показывайте только те атрибуты и операции (если таковые существуют), которые необходимы для понимания назначения узла в данном контексте.
    [Предыдущая глава]
    [Содержание]
    [Следующая глава]


    При моделировании коопераций в UML помните, что каждая кооперация должна представлять реализацию прецедента или операции либо служить автономным механизмом на уровне всей системы. Хорошо структурированная кооперация обладает следующими свойствами:
  • включает структурную и поведенческую составляющие;
  • представляет собой четкую абстракцию некоторого взаимодействия в системе;
  • редко является полностью независимой - обычно перекрывается со структурными элементами других коопераций;
  • проста и легка для понимания.
    Изображая кооперацию в UML, пользуйтесь следующими правилами:
  • явно прорисовывайте кооперацию только тогда, когда это необходимо для понимания ее отношений с другими кооперациями, классификаторами, операциями или системой в целом. В остальных случаях используйте кооперации, но оставляйте их на заднем плане модели;
  • организуйте кооперации в соответствии с представляемыми ими классификаторами или операциями либо помещайте в пакеты, ассоциированные с системой в целом.
    [Предыдущая глава]
    [Содержание]
    [Следующая глава]


    При моделировании образцов в UML помните, что они работают на многих уровнях абстракции, начиная от отдельных классов и кончая системой в целом. Самые интересные виды образцов - это механизмы и каркасы. Хорошо структурированный образец обладает следующими свойствами:
  • решает типичную проблему типичным способом;
  • включает структурную и поведенческую составляющие;
  • раскрывает элементы управления и стыковки, с помощью которых его можно настроить на разные контексты;.
  • является атомарным, то есть не разбивается на меньшие образцы;
  • охватывает разные индивидуальные абстракции в системе.
    Изображая образец в UML, руководствуйтесь следующими правилами:
  • раскрывайте те его элементы, которые необходимо адаптировать для применения в конкретном контексте;
  • делайте образец доступным, приводя прецеденты его использования, а также способы настройки.
    [Предыдущая глава]
    [Содержание]
    [Следующая глава]


    Создавая в UML диаграммы компонентов, помните, что каждая такая диаграмма - это графическое представление статического вида системы с точки зрения реализации. Ни одна отдельно взятая диаграмма компонентов не должна показывать все, что известно о системе. Собранные вместе, диаграммы компонентов дают полное представление о системе с точки зрения реализации, по отдельности же каждая диаграмма описывает лишь один аспект.
    Хорошо структурированная диаграмма компонентов обладает следующими свойствами:
  • фокусирует внимание на каком-то одном аспекте статического представления системы с точки зрения реализации;
  • содержит только те элементы, которые существенны для понимания этого аспекта;
  • раскрывает только те детали, которые находятся на выбранном уровне абстракции;
  • не является настолько краткой, чтобы скрыть от читателя важную семантику.
    Изображая диаграмму компонентов, руководствуйтесь следующими правилами:
  • дайте ей имя, соответствующее назначению;
  • располагайте элементы так, чтобы число пересечений было минимальным;
  • располагайте элементы так, чтобы семантически близкие сущности оказывались рядом;
  • используйте примечания и цвет для привлечения внимания к важным особенностям диаграммы;
  • с осторожностью подходите к использованию стереотипных элементов. Выберите ряд общих для вашего проекта (или организации в целом) пиктограмм и последовательно их применяйте.
    [Предыдущая глава]
    [Содержание]
    [Следующая глава]


    При создании в UML диаграмм развертывания помните, что они являются всего лишь графическим представлением статического вида системы с точки зрения развертывания. Это значит, что ни одна диаграмма, взятая сама по себе, не может описать все, что относится к развертыванию системы. Собранные вместе, диаграммы развертывания дают полное представление о системе с соответствующей точки зрения, по отдельности же каждая диаграмма описывает лишь какой-то один аспект.
    Хорошо структурированная диаграмма развертывания обладает следующими свойствами:
  • сосредоточена на каком-то одном аспекте статического вида системы с точки зрения развертывания;
  • содержит только те элементы, которые существенны для понимания этогоаспекта;
  • раскрывает только те детали, которые присутствуют на выбранном уровне абстракции;
  • не является настолько краткой, чтобы скрыть от читателя важную семантику.
    Изображая диаграмму развертывания, пользуйтесь следующими правилами:
  • дайте диаграмме имя, соответствующее ее назначению;
  • располагайте элементы так, чтобы число пересечений было минимальным;
  • располагайте элементы так, чтобы семантически близкие сущности оказывались рядом;
  • используйте примечания и цвет, чтобы привлечь внимание к важным особенностям диаграммы;
  • с осторожностью подходите к использованию стереотипных элементов. Выберите ряд общих для вашего проекта или организации пиктограмм и применяйте их всюду единообразно.
    [Предыдущая глава]
    [Содержание]
    [Следующая глава]


    Важно выбрать правильное множество моделей для визуализации, специфицирования, конструирования и документирования системы. Хорошо структурированная модель:
  • дает упрощенное представление реальности с одной относительно независимой точки зрения;
  • самодостаточна, то есть не требует для понимания ее семантики никакой дополнительной информации;
  • слабо связана с другими моделями посредством отношений трассировки;
  • коллективно (совместно с другими смежными моделями) дает полное представление обо всех артефактах системы.
    Столь же важно бывает представить сложную систему в виде декомпозиции хорошо структурированных подсистем. Хорошо структурированная система:
  • функционально, логически и физически связна;
  • может быть разложена на почти независимые подсистемы, которые сами являются системами на более низком уровне абстракции;
  • может быть визуализирована, специфицирована, сконструирована и документирована в виде набора взаимосвязанных, неперекрывающихся моделей.
    Для моделей в UML не предусмотрено специального графического представления (за исключением пиктограмм стереотипных пакетов), хотя инструментальные средства обычно изображают в виде пакетов, каждому из которых соответствует разбиение элементов системы с определенной точки зрения.
    При изображении системы или подсистемы в UML:
  • используйте каждую из них как начальную точку для всех артефактов, ассоциированных с ней;
  • показывайте только основные виды агрегирования между системой и ее подсистемами; выносите детали связей между ними на диаграммы более низкого уровня.
    [Предыдущая глава]
    [Содержание]
    [Следующая глава]

    Содержание раздела