Главные механизмы расширения UML

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

Язык UML содержит три механизма расширения своих возможностей: стереотипы, меченые значения и ограничения.

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

Стереотипный элемент представляется базовым модельным элементом, идентифицируемым строкой текста, заключенной в двойные кавычки или пары знаков «больше» и «меньше» (<< и >>).

Стереотипы весьма часто применяются в обычном моделировании на UML. Если это способствует ясности, очень желательно создавать стереотипы для понятий и конструкций модели. Кстати говоря, в самом UML отношения расширения и включения (extend и include) описываются через стереотипы <<extend>> и <<include>>.

Стереотип можно определять для использования с любым элементом — ассоциациями, классами, операциями и т.д. На рисунке приведен класс Control со стереотипом interface.

Обычно с модельными элементами UML связаны свойства. Например, у класса обычно есть имя. С помощью меченого значения (tagged value). Можно определить и связаться с модельным элементом новое свойство, чтобы добавить в элемент дополнительную информацию.

Меченое значение определяется как пара метки и значения в формате { метка = значение }. Скажем, у конструкции «класс» есть имя, но нет возможности указать автора класса. Чтобы присоединить к модельному элементу «класс» имя автора, можно воспользоваться меченым значением { author = Forjadores }.

Как следует из названия, ограничение (constraint) в UML позволяет определить ограничения и отношения, которые не могут быть выражены иначе. Они очень хорошо подходят для указания правил, как можно строить модель (или как нельзя ее строить).

Ограничение выражается в виде текста, заключенного в фигурные скобки, например { constraint }. Если, скажем, порядок ассоциаций в группе связанных классов важен, то можно наложить на каждую ассоциацию ограничение, чтобы ясно выделить ее порядок в отношении. Для класса Emlpoyee можно определить ограничение { m_Balance >= 0 }.

Итак, класс какого-либо.NET-языка может быть изображен в языке UML прямоугольником, разделенным на отсеки. Используются три горизонтальных отсека.

· Отсек имени, в котором отображается имя класса.

· Отсек атрибутов, в котором перечисляются переменные, определенные в классе, если они есть.

· Отсек операций, где показываются методы, определенные в классе, если они есть.

На рисунке приведен простой класс без атрибутов и операций.

Если класс абстрактный, то его имя выделяется курсивом.

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

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

Наиболее простой способ объявить переменную — показать ее в отсеке атрибутов класса. Если атрибут подчеркнут, это указывает на статический характер переменной. На видимость атрибута указывает знак перед ним: + — открытый, # — защищенный и - — закрытый. На рисунке показан класс с атрибутами.

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

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

Методы — это эквивалент операций над классом в UML. Они отображаются в третьем отсеке класса. Видимость операций UML определяется с применением того же соглашения, что и для атрибутов.

Подчеркивание имени указывает на статический метод. Курсив говорит, что метод — абстрактный. Естественно, не все детали классов обязательно показывать.

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

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

В некоторых.NET-языках присутствуют интерфейсы как разновидности классов. В UML интерфейс изображается как класс со стереотипом << interface >>. Стереотипные классы могут изображаться значками. На рисунке приведены оба способа изображения интерфейсов.

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

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

В UML пакет изображается папкой. К пакетам можно применять стереотипы, чтобы выразить их тип, например, обозначить подсистему с помощью стереотипа << subsystem >>. Подсистема — это группа элементов UML, которая представляет модуль поведения. Она может иметь интерфейсы и операции. Подсистемы обычно применяются при анализе и проектировании.

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

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

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

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

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

Зависимость имеет место в следующих ситуациях.

· Если класс содержит переменную другого класса.

· Если класс содержит прямую ссылку на объект.

· Если класс содержит косвенную ссылку на объект, например, через параметры какой-либо операции.

· Если класс использует статическую операцию другого класса.

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

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

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

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

Можно ли изобразить ассоциацию с простыми типами, такими как int или bool? Конечно, можно. И действительно, на стадии анализа можно начать изображать ассоциации со множеством объектов, но по мере продвижения к стадиям проектирования, реализации и уточнения значимости каждой ассоциации их число может значительно сократиться. На практике оказывается, что если это действительно не помогает прояснению сути, а лишь вносит дополнительную «визуальную неразбериху», то нет смысла изображать отношение визуально. Целесообразно показывать в виде ассоциаций только существенные и нетривиальные отношения.

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

Конечно, объекты могут иметь много ассоциаций с объектами другого класса. Например, корпорация обычно имеет много служащих, а один человек может иметь несколько мест работы в разных предприятиях. Эта ситуация моделируется кратностью роли. Кратность изображается как определенное значение (1, 2, 10) или как диапазон (1..10, 1..5, 1..*). Звездочка обозначает неограниченный диапазон. Одиночная «*» означает нуль или большее число, а «10..*» — 10 или более.

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

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

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

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

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

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

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

Еще одна форма ассоциации — объединение. В какой-то мере она похожа на агрегацию, но более сплочена.

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

В реализации на некоторых языках программирования, например C++, агрегация и объединение выражаются в коде по-разному. Например, агрегация подразумевает передачу по ссылке, тогда как объединение — передачу по значению. В некоторых других языках, это различие не проявляется. Значит, агрегация и объединение будут выражаться в коде одинаково, даже несмотря на то, что в модели они могли выражать разные цели.

Объединение выражается так же, как агрегация, только ромбы изображаются зачерненными.

Класс может иметь ассоциацию с самим собой. Если, скажем, человек нанимает другого человека, то класс Person может иметь ассоциацию с самим собой, с ролями «наниматель» и «служащий». Такие отношения называются рефлексивными.

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

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

Анализ и реализация прецедентов (вариантов использования)

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

Разработка диаграммы вариантов использования преследует цели:

· Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы.

· Сформулировать общие требования к функциональному поведению проектируемой системы.

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

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

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

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

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

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

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

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

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

Граничные объекты (boundary objects) возникают на периферии системы, иначе говоря, через них идет взаимодействие с внешним миром.

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

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

Объекты-сущности (entity objects) изображают важную для системы информацию. Они обычно существуют длительное время. Их основное назначение — представлять информацию в системе и управлять ею.

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

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

Объекты управления (control objects) служат для моделирования поведения элемента в системе. Они не обязательно сами реализуют поведение варианта использования, но могут для этого взаимодействовать с другими объектами.

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

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

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

Бизнес-актер (business actor) – индивидуум, группа, организация, компания или система, которые взаимодействуют с моделируемой корпоративным приложением, но не входят в нее, не являясь таким образом частью моделируемой системы.

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

Сотрудник (business worker) – индивидуум, который действует внутри моделируемой системы, взаимодействует с другими сотрудниками и является участником бизнес-процесса моделируемой системы.

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

Бизнес-вариант использования (business use case) — вариант использования, определяющий последовательность действий моделируемой системы, направленных на выполнение отдельного бизнес-процесса.

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

Покажем бизнес-варианты использования на примере покупки телевизора.

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

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

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

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

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

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

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

Не существует каких-либо универсальных стандартов для описания потоков событий в прецедентах, есть лишь общие рекомендации (шаблоны).

Мы можем описывать потоки следующим образом.

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

· Х.1 предусловия;

· Х.2 главный поток;

· Х.3 под-потоки;

· Х.4 альтернативные потоки;

· Х.5 постусловия.

где Х – число от единицы до количества прецедентов.

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

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

Рассмотрим теперь, какие возможности должна предоставлять наша система:

· актер Менеджер по работе с клиентами использует систему для оформления, редактирования заказов и управления информацией о клиентах предприятия;

· актер Менеджер по снабжению использует систему для просмотра перечня необходимых для закупки комплектующих и ведения информации о снабжении;

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

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

· актер Инженер по тестированию использует систему для просмотра нарядов на тестирование собранной продукции и отметки о ходе выполнения работы;

· актер Завскладом использует систему для учета поступления и выдачи комплектующих.

На основании вышеизложенного можно выделить следующие прецеденты:

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

Созданная главная диаграмма прецедентов показана на следующем рисунке:

Рассмотрим теперь отношения между актерами и прецедентами. В языке UML возможен только один тип отношений между актером и прецедентом – отношение коммуникации. Поэтому всех актеров мы связали с прецедентами отношением Unidirectional Association. Поскольку другой тип отношений здесь мы задать не может, то стереотип <<communicate>> можно не указывать (он подразумевается неявно).

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

Отношение между прецедентами Работа с заказом и Управление информацией о клиенте – отношение расширения, поскольку когда актер Менеджер по работе с клиентами работает с заказом (оформляет, меняет и т.д.), то не всегда при этом он управляет информацией о клиентах.

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

Поток событий для прецедента «Работа с заказом».

1.1 Предусловия. Если заказ оформляется для нового клиента, то под-поток добавить нового клиента (Add a New Client) прецедента Управление информацией о клиенте должен быть выполнен перед его началом.

1.2 Главный поток. Прецедент начинает выполняться, когда менеджер подключается к системе и вводит свое имя и пароль. Система проверяет правильность пароля (Е-1) и выводит возможные варианты действий: добавить (Add), изменить (Change), удалить (Delete), просмотреть (View) или выйти (Exit).

Если выбрана операция добавить (Add), S-1: выполняется поток добавить новый заказ (Add a New Order).

Если выбрана операция изменить (Change), S-2: выполняется поток изменить заказ (Change Order).

Если выбрана операция удалить (Delete), S-3: выполняется поток удалить заказ (Delete Order).

Если выбрана операция просмотреть (View), S-4: выполняется поток просмотреть заказ (View Order).

Если выбрана операция выйти (Exit) прецедент завершается.

1.3 Под-потоки.

S-1: добавить новый заказ (Add a New Order). Система отображает диалоговое окно, содержащее поле, в котором менеджер должен выбрать тип компьютера (настольный или ноутбук). Пользователь выбирает необходимый тип. Система отображает поле для выбора клиента и список возможных комплектующих для выбранного типа компьютера, в котором менеджер отмечает выбранные клиентом комплектующие. Менеджер заполняет поля (E-2). Система запоминает введенные данные и распечатывает счет для оплаты. Затем прецедент начинается сначала.

S-2: изменить заказ (Change Order)

Система отображает диалоговое окно, содержащее список заказов и поле для ввода номера заказа. Менеджер выбирает необходимый заказ из списка или вводит номер заказа в поле (Е-3). Система отображает информацию о данном заказе. Менеджер делает необходимые изменения (Е-2). Система запоминает введенные данные. Затем прецедент начинается сначала.

S-3: удалить заказ (Delete Order)

Система отображает диалоговое окно, содержащее список заказов и поле для ввода номера заказа. Менеджер выбирает необходимый заказ из списка или вводит номер заказа в поле (Е-3). Система удаляет выбранный заказ (Е-4). Затем прецедент начинается сначала.

S-4: просмотреть заказ (View Order)

Система отображает диалоговое окно, содержащее список заказов и поле для ввода номера заказа. Менеджер выбирает необходимый заказ из списка или вводит номер заказа в поле (Е-3). Система отображает информацию о выбранном заказе. Когда менеджер просмотрит информацию, прецедент начнется сначала.

1.4 Альтернативные потоки

Е-1: введено неправильное имя или пароль. Пользователь должен повторить ввод или завершить прецедент.

Е-2: выбраны не все комплектующие, необходимые для сборки компьютера или комплектующих нет в наличии. Менеджер должен изменить состав компьютера или завершить прецедент.

Е-3: введен неправильный номер заказа. Менеджер должен повторить ввод или завершить прецедент.

Е-4: система не может удалить заказ. Информация сохраняется, система удалит заказ позже. Выполнение прецедента продолжается.

Поток событий для прецедента «Управление информацией о клиенте».

2.1 Предусловия.

2.2 Главный поток.

Прецедент начинает выполняться, когда менеджер подключается к системе и вводит свое имя и пароль. Система проверяет правильность пароля (Е-1) и выводит возможные варианты действий: добавить (Add), изменить (Change), удалить (Delete), просмотреть (View) или выйти (Exit).

Если выбрана операция добавить (Add), S-1: выполняется поток добавить нового клиента (Add a New Client).

Если выбрана операция изменить (Change), S-2: выполняется поток изменить данные о клиенте (Change Client Data).

Если выбрана операция удалить (Delete), S-3: выполняется поток удалить клиента (Delete Client).

Если выбрана операция просмотреть (View), S-4: выполняется поток просмотреть данные о клиенте (View Client Data).

Если выбрана операция выйти (Exit) прецедент завершается.

2.3 Под-потоки.

S-1: добавить нового клиента (Add a New Client)

Система отображает диалоговое окно, содержащее поля для ввода данных о новом клиенте. Пользователь заполняет поля (Е-2). Система запоминает введенные данные. Затем прецедент начинается сначала.

S-2: изменить данные о клиенте (Change Client Data)

Система отображает диалоговое окно, содержащее список клиентов и поле для ввода номера клиента. Менеджер выбирает необходимого клиента из списка или вводит его номер в поле (Е-3). Система отображает информацию о данном клиенте. Менеджер делает необходимые изменения (Е-2). Система запоминает введенные данные. Затем прецедент начинается сначала.

S-3: удалить клиента (Delete Client)

Система отображает диалоговое окно, содержащее список клиентов и поле для ввода номера клиента. Менеджер выбирает необходимого клиента из списка или вводит его номер в поле (Е-2). Система удаляет выбранного клиента (Е-4). Затем прецедент начинается сначала.

S-4: просмотреть данные о клиенте (View Client Data)

Система отображает диалоговое окно, содержащее список клиентов и поле для ввода номера клиента. Менеджер выбирает необходимого клиента из списка или вводит его номер в поле (Е-3). Система отображает информацию о выбранном клиенте. Когда менеджер просмотрит информацию, прецедент начнется сначала.

2.4 Альтернативные потоки

Е-1: введено неправильное имя или пароль. Пользователь должен повторить ввод или завершить прецедент.

Е-2: заполнены не все поля. Менеджер должен заполнить незаполненные поля или завершить прецедент.

Е-3: введен неправильный номер клиента. Менеджер должен повторить ввод или завершить прецедент.

Е-4: система не может удалить клиента. Информация сохраняется, система удалит клиента позже. Выполнение прецедента продолжается.

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

3.1 Предусловия.

3.2 Главный поток.

Прецедент начинает выполняться, когда завскладом подключается к системе и вводит свое имя и пароль. Система проверяет правильность пароля (Е-1) и выводит возможные варианты действий: добавить (Add), отметить (Mark) или выйти (Exit).

Если выбрана операция добавить (Add), S-1: выполняется поток внести поступившие комплектующие (Add a New Components).

Если выбрана операция отметить (Mark), S-2: выполняется поток сделать отметку о выдаче комплектующих (Mark Components).

Если выбрана операция выйти (Exit) прецедент завершается.

3.3 Под-потоки.

S-1: внести поступившие комплектующие (Add a New Components)

Система отображает диалоговое окно, содержащее поля для ввода наименования комплектующих, их количества, поставщика. Завскладом заполняет указанные поля (Е-2). Система запоминает введенные данные. Затем прецедент начинается сначала.

S-2: сделать отметку о выдаче комплектующих (Change Order)

Система отображает список комплектующих, находящихся на складе. Завскладом напротив нужных комплектующих вводит количество выданных (Е-3). Система запоминает введенные данные. Затем прецедент начинается сначала.

3.4 Альтернативные потоки

Е-1: введено неправильное имя или пароль. Пользователь должен повторить ввод или завершить прецедент.

Е-2: заполнены не все поля. Пользователь должен заполнить пропущенные поля или завершить прецедент.

Е-3: указано количество выданных комплектующих, превышающее их количество на складе. Пользователь должен повторить ввод или завершить прецедент.

Поток событий для прецедента «Сборка компьютеров».

4.1 Предусловия.

4.2 Главный поток.

Прецедент начинает выполняться, когда инженер по сборке подключается к системе и вводит свое имя и пароль. Система проверяет правильность пароля (Е-1) и выводит возможные варианты действий: просмотреть (View), отметить (Mark) или выйти (Exit).

Если выбрана операция просмотреть (View), S-1: выполняется поток Просмотреть наряд на сборку компьютера (View an Make Computer Order).

Если выбрана операция отметить (Mark), S-2: выполняется поток сделать отметку о статусе собираемого компьютера по наряду (Mark Computer).

Если выбрана операция выйти (Exit) прецедент завершается.

4.3 Под-потоки.

S-1: Просмотреть наряд на сборку компьютера (View an Make Computer Order)

Система отображает диалоговое окно, содержащее список нарядов и поле для ввода номера наряда. Инженер выбирает необходимый наряд из списка или вводит его номер в поле (Е-2). Система отображает информацию о выбранном наряде. Когда инженер просмотрит информацию, прецедент начнется сначала.

S-2: сделать отметку о статусе собираемого компьютера (Mark Computer)

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

4.4 Альтернативные потоки

Е-1: введено неправильное имя или пароль. Пользователь должен повторить ввод или завершить прецедент.

Е-2: заполнены не все поля. Пользователь должен заполнить пропущенные поля или завершить прецедент.

Е-3: введен неправильный номер наряда. Инженер должен повторить ввод или завершить прецедент.

Поток событий для прецедента «Требование необходимых комплектующих.

5.1 Предусловия.

5.2 Главный поток.

Прецедент начинает выполняться, когда инженер по сборке подключается к системе и вводит свое имя и пароль. Система проверяет правильность пароля (Е-1) и выводит возможные варианты действий: просмотреть (View), затребовать (Order) или выйти (Exit).

Если выбрана операция просмотреть (View), S-1: выполняется поток просмотреть затребованные комплектующие на складе (View Ordered Components on Warehouse).

Если выбрана операция затребовать (Order), S-2: выполняется поток затребовать необходимые комплектующие на складе (Order Required Components on Warehouse).

Если выбрана операция выйти (Exit) прецедент завершается.

5.3 Под-потоки.

S-1: Просмотреть затребованные комплектующие на складе (View Ordered Components on Warehouse)

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

S-2: затребовать необходимые комплектующие на складе (Order Required Components on Warehouse)

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

5.4 Альтернативные потоки

Е-1: введено неправильное имя или пароль. Пользователь должен повторить ввод или завершить прецедент.

Описание потоков событий для прецедентов Управление информацией о поставщиках и Управление информацией о комплектующих аналогично описанию прецедента Управление информацией о клиенте; для прецедента Тестирование компьютеров – прецеденту Сборка компьютеров.

Дата добавления: 2014-01-11