Диаграммы классов UML. Логическое моделирование

Отношение включения, помечаемое стереотипом <>, означает, что для полного осуществления основного (базового) ВИ необходимо выполнение и включаемого варианта. В общем случае выделение включаемых ВИ будет целесообразным в тех случаях, когда такой вариант включается в несколько базовых. Об отношении включения “знает” только базовый вариант использования, но не включаемый. Включение показывается пунктирной стрелкой, направленной от базового ВИ к включаемому (см. рис.2б).

Если ВИ имеет  фрагменты, которые по характеру  являются необязательными или представляют собой исключения и при этом не способствуют лучшему пониманию  основного назначения ВИ, вы можете вынести за скобки такие фрагменты, создав новый, расширяющий ВИ. Начальный  вариант становится базовым, который  связывается с новым вариантом  отношением расширения. Расширение показывается пунктирной стрелкой, направленной к расширяемому ВИ (см. рис.2а, 2б).

  
Рис. 2а. Пример диаграммы ВИ  
Актер «Оператор» активизирует выполнение ВИ «Открыть счет». В соответствии с заданным оператором типом счета выполняется либо ВИ «Открыть счет физического лица» либо «Открыть счет юридического лица», являющиеся расширениями первого. Открытие счета включает его контроль и при обнаружении ошибки – выдачу сообщения Оператору.   
Рис. 2б. Пример диаграммы ВИ  
Аналог рис. 2а. У актера «Оператор» есть два режима работы. Он активизирует «Открыть счет физического лица» либо «Открыть счет юридического лица». Открытие каждого счета включает выполнение работ, предусматриваемых в ВИ «Открыть счет», содержащим общее поведение для двух исходных ВИ.

Назначение  диаграмм вариантов использования

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

Моделирование поведения

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

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

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

Диаграммы последовательностей (Sequence diagrams)

На диаграммах последовательностей, иногда называемых сценариями, показываются объекты и сообщения, которыми они обмениваются. Каждый объект изображается в виде вертикальной линии («линии жизни» объекта). По вертикали сверху вниз направлена временная ось. Сообщение, показываемое в виде стрелки от объекта к объекту, соответствует вызову операции соответствующего класса (см. рис.1). Таким образом, на диаграмме можно показать поток сообщений во времени (сценарий). С помощью диаграмм этого вида можно описать как основной, так и альтернативные потоки событий для ВИ.

Диаграммы кооперации (Collaboration Diagrams)

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

  
Рис.1 Диаграмма последовательности действий при вводе документа

 

  
Рис.2 Результат преобразования диаграммы  последовательностей в диаграмму  кооперации. Нумерация сообщений  определяет их временной порядок.

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

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

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

  
Рис.3 Диаграмма деятельностей при  проектировании и разработке ПС.

Дополнительно показывая  на диаграмме деятельностей порождаемые  и используемые объекты, можно построить  диаграммы потоков данных (DFD), которые  широко используются при структурном  проектировании ПС и при бизнес-анализе (см. рис. 3).

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

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

Состояния на диаграмме  показываются в виде прямоугольников  со скругленными углами, а события  – стрелками. Диаграмма состояний  обычно связывается с классом, поскольку  все объекты класса имеют одинаковое поведение. При функциональном моделировании  диаграммы состояний создаются  для объектов, имеющих сложное  поведение, показывая логику их работы. В примере на рис.4 показана диаграмма  состояний для объектов класса «Товар»  в модели складской системы управления.

  
Рис.4. Диаграмма состояний для  класса «Товар» Из диаграммы видно, например, что зарезервированный под заказ товар не может быть зарезервирован под другой заказ, так как есть только два события, вызывающие переход из этого состояния – «отмена резервирования» и «отбор».

Компонентно-базированная разработка

Принципы  компонентно-базированного подхода  к разработке ПС

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

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

КБ подход базируется на трех основных принципах:

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

Отделение спецификации от реализации

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

Инкапсуляция  данных и процессов

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

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

Абстракция  и автоматизация

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

Чем компонент  отличается от класса?

Компоненты во многих отношениях подобны классам но имеют  и существенные отличия от последних.

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

Библиотеки  компонентов

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

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