Шпоры по ТООМ

1-АБСЭБ- 17

1.Отношения обобщения, их стереотипы. Примеры отношений. Обобщением называется отношение между общей сущностью, которую называют суперклассом или родителем, и более специализированной ее разновидностью, называемой подклассом или потомком . Например, общий класс Window можно специализировать, создав класс-потомок MultlPaneWindow. Благодаря отношениям обобщения от потомка к родителю MultiPaneWindowу наследует структуру и поведение своего родителя - Window. У потомка могут появиться новые элементы структуры или поведения, унаследованные - модифицироваться. В отношениях обобщения экземпляры потомка везде могут использоваться вместо экземпляров родителя, - это значит, что потомок может замещать родителя. Как правило, достаточно одиночного наследования, когда у класса имеется всего один родитель. Но иногда используют и множественное наследование, которое тоже можно моделировать на языке UML. Как мы видим, класс Активы имеет трех потомков: БанковскийСчет, Недвижимость и ЦенныеВумаги. У первого и последнего из них имеются собственные потомки. Например, Акция и Облигация являются потомками класса ЦенныеБумаги. Два класса ( БанковскийСчети Недвижимость) наследуют от нескольких родителей. Класс Недвижимость, например, является потомком классов Активыи ОбъектСтрахования, а класс БанковскийСчет- потомком классов ОбъектНачисленияПроцентов, ОбъектСтрахованияи Активы. Классы-родители (в данном случае Объект НачисленияПроцентов и ОбъектСтрахования) называются смешивающими , поскольку порождают потомков не самостоятельно, а совместно с другими классами (Активы). С множественным наследованием следует обращаться осторожно. Если структура или поведение нескольких предков перекрываются, у вас могут возникнуть проблемы. Для большинства отношений наследования, которые вам встретятся, будет достаточно простых отношений обобщения без каких-либо дополнений. Но если мы хотим специфицировать смысловые нюансы, можно воспользоваться одним стереотипом и четырьмя ограничениями, определенными в языке UML для применения совместно с обобщениями Множественное наследование Во-первых, имеется один стереотип. implementation- показывает, что потомок наследует реализацию родителя, но не открывает и не поддерживает его интерфейсы, тем самым делая невозможным замещение. Кроме стереотипа, к отношениям обобщения применимы четыре стандартных ограничения: complete- показывает, что в модели определены все потомки в данном отношении обобщения (хотя некоторые могут быть скрыты на диаграмме) и наличие дополнительных потомков не допускается; incomplete- показывает, что определены не все потомки в данном отношении и допускается включение дополнительных. disjoint- показывает, что объекты класса родителя могут иметь не более одного потомка на правах типа ; overlapping- показывает, что объекты класса родителя могут иметь более одного потомка на правах типа. Чаще всего объект имеет один постоянный тип во время выполнения программы, - это называется статической классификацией. Если тип объекта может меняться, то имеет место динамическая классификация. Моделирование последней является непростой задачей, однако в UML можно использовать комбинацию множественного наследования с типами, чтобы показать потенциальные типы объекта, и взаимодействиями,чтобы показать изменение типа объекта во время работы программы.

2.Примеры использования UML для построения визуальных моделей. Модель системы электронной торговли [ смотри в приложении ]

1-АБСЭБ- 18

1.Средства нотации языка UML, используемые для описания поведения моделируемой системы. Унифицированный язык моделирования имеет хорошо определенные синтаксис и семантику; наиболее заметная часть синтаксиса этого языка - его графическая нотация. Поведенческие сущности Поведенческие сущности - это динамические части моделей UML. К ним относятся взаимодействия (Interactions) и автоматы (State machines). Диаграмма (Diagram) - это графическое представление множества элементов. Чаще всего она изображается в виде связного графа с вершинами (сущностями) и ребрами (отношениями): -диаграмма прецедентов (Use case diagram) - диаграмма поведения, на которой показано множество прецедентов и актеров, а также отношения между ними; -диаграмма последовательностей (Sequence diagram) - диаграмма поведения, на которой показано взаимодействие и подчеркнута временная последовательность событий; -диаграмма кооперации (Collaboration diagram) - диаграмма поведения, на которой показано взаимодействие и подчеркнута структурная организация объектов, посылающих и принимающих сообщения; -диаграмма состояний (Statechart diagram) - диаграмма поведения, на которой показан автомат и подчеркнуто поведение объектов с точки зрения порядка получения событий; -диаграмма деятельности (Activity diagram) - диаграмма поведения, на которой показан автомат и подчеркнуты переходы потока управления от одной деятельности к другой; - диаграмма компонентов (Component diagram) - диаграмма поведения, на которой показан автомат и подчеркнуто поведение объектов с точки зрения порядка получения событий;

2. Примеры использования UML для построения визуальных моделей. Модель гидропонной системы. Гидропоника - технология выращивания культур без использования почвы. Диаграмма состояний и переходов для контроллера тепличной среды Мы видим, что все объекты этого класса начинают свою жизнь в начальном состоянии Idle (ожидание); затем они изменяют свое состояние по событию Define climate, для которого не предполагается явных действий (считается, что это событие, то есть ввод климатического задания, происходит только в дневное время). Дальше динамическое поведение этого класса состоит в переключении между состояниями Daytime и Nighttime; оно определяется событиями Sunrise и Sunset (восход и закат) соответственно; с этими событиями связаны действия по изменению освещения. В обоих состояниях событие понижения или повышения температуры в теплице вызывает обратную реакцию (операция adjustTemperature(), которая является локальной в этом классе). Мы возвращаемся в состояние Idle, когда поступит событие Terminate climate, то есть будет отменено климатическое задание. На рисунке. показана диаграмма объектов Цель этой диаграммы - проиллюстрировать сценарий выполнения обычной функции системы, а именно, прогнозирование затрат на сбор урожая некоторого посева. Выполнение этой функции требует сотрудничества нескольких различных объектов. Сценарий начинается с вызова объектом PlanAnalyst (анализатор планов) операции timeToHarvest() (время собирать урожай) над утилитой класса PlanMetrics (параметры планов). При этом объект с передается как фактический параметр операции. Затем утилита PlanMetrics вызывает операцию status() (состояние) на некотором неименованном объекте класса GardeningPlan (план выращивания). В пояснении говорится: "Надо проверить, что этот план действительно выполняется". В свою очередь, объект GardeningPlan вызывает операцию maturationTime() (время созревания) на выбранном объекте класса GrainCrop (посев зерновых), запрашивающую ожидаемое время созревания посева. Когда эта операция-селектор будет выполнена, управление возвращается объекту класса PlanAnalyst, который затем непосредственно вызывает операцию C.yield(), унаследованную от суперкласса (операция Crop::yield()). Управление снова возвращается объекту класса PlanAnalyst, который продолжает сценарий, выполняя над собой операцию netCost(). Диаграмма модулей верхнего уровня для гидропонной системы.

1-АБСЭБ- 19

1.Диаграммы последовательности взаимодействия (Sequence diagram): описание временной последовательности посылки сообщений между диаграммами На диаграммах последовательностей внимание акцентируется прежде всего на временной упорядоченности сообщений. Для создания такой диаграммы надо прежде всего расположить объекты, участвующие во взаимодействии, в верхней ее части вдоль оси X. Обычно инициирующий взаимодействие объект размещают слева, а остальные - правее (тем дальше, чем более подчиненным является объект). Затем вдоль оси Y размещаются сообщения, которые объекты посылают и принимают, причем более поздние оказываются ниже. Это дает читателю наглядную картину, позволяющую понять развитие потока управления во времени. Диаграммы последовательностей характеризуются двумя особенностями, отличающими их от диаграмм кооперации. Во-первых, на них показана линия жизни объекта. Это вертикальная пунктирная линия, отражающая существование объекта во времени. Большая часть объектов, представленных на диаграмме взаимодействий, существует на протяжении всего взаимодействия, поэтому их изображают в верхней части диаграммы, а их линии жизни прорисованы сверху донизу. Объекты могут создаваться и во время взаимодействий. Линии жизни таких объектов начинаются с получения сообщения со стереотипом create. Объекты могут также уничтожаться во время взаимодействий; в таком случае их линии жизни заканчиваются получением сообщения со стереотипом destroy, а в качестве визуального образа используется большая буква X, обозначающая конец жизни объекта. Если объект на протяжении своей жизни изменяет значения атрибутов, состояние или роль, это можно показать, поместив копию его пиктограммы на линии жизни в точке изменения. Вторая особенность этих диаграмм - фокус управления. Он изображается в виде вытянутого прямоугольника, показывающего промежуток времени, в течение которого объект выполняет какое-либо действие, непосредственно или с помощью подчиненной процедуры. Верхняя грань прямоугольника выравнивается по временной оси с моментом начала действия, нижняя - с моментом его завершения (и может быть помечена сообщением о возврате). Вложенность фокуса управления, вызванную рекурсией (то есть обращением к собственной операции) или обратным вызовом со стороны другого объекта, можно показать, расположив другой фокус управления чуть правее своего родителя (допускается вложенность произвольной глубины). Если место расположения фокуса управления требуется указать с максимальной точностью, можно заштриховать область прямоугольника, соответствующую времени, в течение которого метод действительно работает и не передает управление другому объекту. Сообщения (message) связывают объекты между собой и передают информацию о выполняемом действии. Каждое сообщение представляется на диаграмме сплошной линией со стрелкой на конце, проведенной от линии жизни одного объекта к линии жизни другого объекта. Возможна посылка сообщения объектом самому себе - самоделегирование. В этом случае линия может начинаться и заканчиваться около символа объекта. Линия помечается именем сообщения (операция или сигнал) и значениями его аргументов. Сообщения могут быть помечены условием перехода, которое располагается в квадратных скобках. Сообщения могут быть следующих типов. Асинхронные:сообщения рисуются линией с половинкой стрелки на конце. Асинхронное сообщение не блокирует работу вызывающего объекта..Асинхронные сообщения можно использовать для создания нового объекта или для установления связи с уже выполняемой ветвью процесса. Вызов процедуры:рисуется как заполненная стрелка. Возвращение из процедуры подразумевается неявно и на диаграмме не отображается. Возврат ставиться явно в том случае, если это необходимо для большей ясности и представляется меткой (короткая поперечная линия), расположенной около адресата возврата. Обычно стрелка с сообщением рисуется горизонтально. Это символизирует, что сообщение передается мгновенно и ничего не может произойти в момент передачи. Если на передачу сообщения необходимо какое-то время, в течение которого может что-нибудь произойти, то линия со стрелкой может быть ломаной (конец стрелки располагается ниже ее начала).

2. Модель сценариев использования. Значение сущностей: Актер; Сценарий использования; Описание архитектуры; Глоссарий. Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой. Действующее лицо (actor) – это роль, которую пользователь играет по отношению к системе. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. Показывать на диаграмме действующих лиц следует только в том случае, когда им действительно необходимы некоторые варианты использования. Действующие лица делятся на три основных типа – пользователи системы, другие системы, взаимодействующие с данной, и время. Время становится действующим лицом, если от него зависит запуск каких-либо событий в системе. На рис. показан пример такой диаграммы для банкомата (Automated Teller Machine, ATM). На диаграмме вариантов использования показано взаимодействие между вариантами использования и действующими лицами. Она отражает требования к системе с точки зрения пользователя. Таким образом, варианты использования – это функции, выполняемые системой, а действующие лица – это заинтересованные лица по отношению к создаваемой системе. Конкретная цель диаграмм вариантов использования – это документирование вариантов использования (всё, входящее в сферу применения системы), действующих лиц (всё вне этой сферы) и связей между ними. Варианты использования начинают описывать, что должна будет делать система. Цель – описать, что будет делать система, а не как она будет делать это. Связи между вариантами использования и действующими лицами. В языке UML на диаграммах вариантов использования поддерживается несколько типов связей между элементами диаграммы. Это связи коммуникации (communication), включения (include), расширения (extend) и обобщения (generalization). Связь коммуникации – это связь между вариантом использования и действующим лицом. На языке UML связи коммуникации показывают с помощью однонаправленной ассоциации (сплошной линии со стрелкой). Направление стрелки позволяет понять, кто инициирует коммуникацию. Связь включения применяется в тех ситуациях, когда имеется какой-либо фрагмент поведения системы, который повторяется более чем в одном варианте использования. С помощью таких связей обычно моделируют многократно используемую функциональность. Связь расширения применяется при описании изменений в нормальном поведении системы. Она позволяет варианту использования только при необходимости использовать функциональные возможности другого. На языке UML связи включения и расширения показывают в виде зависимостей с соответствующими стереотипами. С помощью связи обобщения показывают, что у нескольких действующих лиц имеются общие черты. Например, клиенты могут быть двух типов: корпоративные и индивидуальные. Эту связь можно моделировать с помощью нотации, показанной на рис. Варианты использования являются необходимым средством на стадии формирования требований к ПО. Каждый вариант использования – это потенциальное требование к системе, и пока оно не выявлено, невозможно запланировать его реализацию

1-АБСЭБ- 20

1. Средства нотации языка UML для описания статической структуры модели системы. Структурирование модели системы на пакеты, модели и подсистемы. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов. – диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними. На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами. Стереотипы – это механизм, позволяющий разделять классы на категории. В языке UML определены три основных стереотипа классов: Boundary (граница), Entity (сущность) и Control (управление). Структурирование модели системы на пакеты Пакеты применяют, чтобы сгруппировать классы, обладающие некоторой общностью. Существует несколько наиболее распространенных подходов к группировке. Во-первых, можно группировать их по стереотипу. В таком случае получается один пакет с классами-сущностями, один с граничными классами, один с управляющими классами и т.д. Этот подход может быть полезен с точки зрения размещения готовой системы, поскольку все находящиеся на клиентских машинах пограничные классы уже оказываются в одном пакете. Другой подход заключается в объединении классов по их функциональности. Например, в пакете Security (безопасность) содержатся все классы, отвечающие за безопасность приложения. В таком случае другие пакеты могут называться Employee Maintenance (Работа с сотрудниками), Reporting (Подготовка отчетов) и Error Handling (Обработка ошибок). Преимущество этого подхода заключается в возможности повторного использования. Таким образом, диаграмма пакетов представляет собой диаграмму, содержащую пакеты классов и зависимости между ними. Строго говоря, пакеты и зависимости являются элементами диаграммы классов

2. Основы работы над проектом в среде Rational Rose. Rational Rose – семейство объектно-ориентированных CASE-средств фирмы Rational Software Corporation – предназначено для автоматизации процессов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует метод объектно-ориентированного анализа и проектирования, основанный на языке UML. Текущая версия Rational Rose реализует генерацию кодов программ для С++, Visual C++, Visual Basic, Java, PowerBuilder, CORBA Interface Definition Language (IDL), генерацию описаний баз данных для ANSI SQL, Oracle, MS SQL Server, IBM DB2, Sybase, а также позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций. Кроме того, Rational Rose содержит средства реверсного инжиниринга программ и баз данных, обеспечивающие повторное использование программных компонентов в новых проектах. Структура и функции. В основе работы Rational Rose лежит построение диаграмм и спецификаций UML, определяющих архитектуру системы, её статические и динамические аспекты. В составе Rational Rose можно выделить шесть основных структурных компонентов: репозиторий, графический интерфейс пользователя, средства просмотра проекта (браузер), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для С++, обеспечивающий реверсный инжиниринг. Репозиторий представляет собой базу данных проекта. Браузер обеспечивает “навигацию” по проекту, в том числе перемещение по иерархиям классов и подсистем, переключение от одного вида диаграмм к другому и т. д. Средства контроля и сбора статистики дают возможность находить и устранять ошибки по мере развития проекта, а не после завершения его описания. Генератор отчетов формирует тексты выходных документов на основе содержащейся в репозитории информации. Средства автоматической генерации кодов программ на языке С++, используя информацию, содержащуюся в диаграммах классов и компонентов, формируют файлы заголовков и файлы описаний классов и объектов. В процессе работы анализатор осуществляет контроль правильности исходных текстов и диагностику ошибок. Модель, полученная в результате его работы, может целиком или фрагментарно использоваться в различных проектах. В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы: – диаграммы UML, в совокупности представляющие собой модель разрабатываемой программной системы; – спецификации классов, объектов, атрибутов и операций; – заготовки текстов программ. Взаимодействие с другими средствами и организация групповой работы. Для поддержки командной работы над проектом на каждой стадии жизненного цикла ПО имеется интегрированный набор продуктов Rational Suite. Rational Suite существует в следующих вариантах: • Rational Suite AnalystStudio – предназначен для определения и управления полным набором требований к разрабатываемой системе; • Rational Suite DevelopmentStudio – предназначен для проектирования и реализации ПО; • Rational Suite TestStudio – представляет собой набор продуктов, предназначенных для автоматического тестирования приложений; • Rational Suite Enterprise – обеспечивает поддержку полного жизненного цикла ПО и предназначен как для менеджеров проекта, так и отдельных разработчиков, выполняющих несколько функциональных ролей в команде разработчиков. В состав Rational Suite, кроме Rational Rose, входят следующие компоненты: • Rational Requisite Pro – средство управления требованиями, предназначенное для организации совместной работы группы разработчиков. Оно позволяет команде разработчиков создавать, структурировать, устанавливать приоритеты, отслеживать, контролировать изменения требований, возникающих на любом этапе разработки компонентов приложения; • Rational ClearCase – средство управления конфигурацией ПО; • Rational SoDA – средство автоматической генерации проектной документации; • Rational ClearQuest – средство для управления изменениями и отслеживания дефектов в проекте на основе средств e-mail и Web; • Rational TeamTest – средство автоматического обнаружения ошибок во время выполнения программы и генерации сценариев для проведения регрессионного тестирования; • Rational Robot – средство для создания, модификации и автоматического запуска тестов; • Rational Purify – средство для локализации трудно обнаруживаемых ошибок времени выполнения программы; • Rational PureCoverage – средство идентификации участков кода, пропущенных при тестировании; • Rational Quantify – средство количественного определения узких мест, влияющих на общую эффективность работы программы; • Rational Suite PerformanceStudio – средство нагрузочного тестирования приложений «клиент-сервер» и Web-приложений. Для организации групповой работы в Rational Rose возможно разбиение модели на управляемые подмодели. Каждая из них независимо сохраняется на диске или загружается в модель. В качестве подмодели может выступать пакет или подсистема.

1-АБСЭБ- 21

2. Проектирование баз данных с использованием UML.

Обзор возможностей современных СУБД

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

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

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

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

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

В ООБД информация хранится в форме объектов. Полностью объектно-ориентированная СУБД должна обеспечивать также объектно-ориентированный интерфейс взаимодействия с пользователем.

В основе ООБД лежит понятие объекта. Объектно-ориентированные БД характеризуются свойствами инкапсуляции, наследования и полиморфизма.

Диаграммы вариантов использования

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

Диаграмма вариантов использования каталога

По мере продолжения системного анализа каждый вариант использования разбивается на несколько, создавая вложенную последовательность вариантов использования. Большинство вариантов использования высокого уровня – это транзакции основных запросов. Каждый из них – это транзакция, так как извлекает определенный набор данных с определенным началом и концом. Атомарные транзакции имеют связующие связи с акторами, а податомарные – расширяют другие варианты использования или используются ими. Некоторые ООDBMS поддерживают модель вложенных транзакций.

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

Модель сущность – связь. Сущность – это объект данных. Отношения. Множественность отношения «играет роль». Множественное наследование. Модель данных UML преобразуется в такую схему легко, хотя существуют проблемы, связанные с отсутствием стандартов OODBMS.

Поведение объектов

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

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

Преимущества: можно использовать объектно-ориентированные средства (наследование, методы, объектные ссылки)для создания схемы. Которая хорошо вписывается в объектно-ориентированный концептуальный проект. Взаимодействие с реляционными средствами модели данных обеспечивает мост к реляционным операциям (например. использовать SQL).

2 Средства нотации языка UML для описания сценариев использования моделируемой системы. Диаграммы прецедентов (Use Case diagram) как средство описания взаимодействия моделируемой системы с внешней средой. Средства языка UML для детализации поведения системы, описанного на диаграммах сценариев использования. 

Создатели UML представляют его как язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов. Стандарт UML версии 1.1, принятый OMG в 1997 г., предлагает следующий набор диаграмм для моделирования:

– диаграммы вариантов использования (use case diagrams) – для моделирования бизнес-процессов организации и требований к создаваемой системе);

– диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними;

– диаграммы поведения системы (behavior diagrams): диаграммы взаимодействия (interaction diagrams):

– диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams) – для моделирования процесса обмена сообщениями между объектами;

– диаграммы состояний (statechart diagrams) – для моделирования поведения объектов системы при переходе из одного состояния в другое;

– диаграммы деятельностей (activity diagrams) – ля моделирования поведения системы в рамках различных вариантов использования, или моделирования деятельностей;

– диаграммы реализации (implementation diagrams): диаграммы компонентов (component diagrams) – для моделирования иерархии компонентов (подсистем) системы;

– диаграммы размещения (deployment diagrams) – для моделирования физической архитектуры системы.

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

Разработка, управляемая прецедентами

В Rational Unified Process "красной нитью", объединяющей систему при выполнении отдельных задач, являются прецеденты, которые определяют поведение системы. Одним из преимуществ Rational Unified Process является его "управляемый прецедентами подход". Это предполагает, что определенный для системы прецедент является основанием для всего процесса разработки.

Прецеденты играют роль в каждом из четырех основных потоков работ процесса: Требования, Анализ и проектирование, Выполнение и Испытание.

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

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

Затем идентифицируются прецеденты:

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

Объединяющая функция прецедентов прослеживается на всем протяжении цикла развития системы. Одна и та же модель прецедентов используется в потоках работ Требования, Анализ и проектирование и Испытания.

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

Рис.3.1.Диаграмма использования

Поток событий для прецедента

Поток событий (flow of events) – это последовательность событий, необходимых для обеспечения требуемого поведения. Поток событий описывается в терминах предметной области.

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

Между актером и прецедентом может существовать ассоциативное отношение. Ассоциативная связь может быть односторонней или двусторонней. Направление связи показывает, кто является ее инициатором (актер или прецедент). Существует два типа отношений между прецедентами: включает (include) и дополняет (extend). Отношение «включает» изображается как отношение зависимости , направленное от базового прецедента к используемому.

Отношение дополняет (extend relationship) применяется для отражения: дополнительных режимов; режимов, которые запускаются только при определенных условиях, например сигнала тревоги; альтернативных потоков, которые запускаются по выбору актера.

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