Федеральное государственное бюджетное образовательное учреждение

высшего профессионального образования

«Пермская государственная сельскохозяйственная академия

имени академика Д.Н. Прянишникова»

ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ

направление 230700 «Прикладная информатика»

Лабораторное занятие № 5

Тема: Модель прецедентов: описание системных операций

Учебные вопросы:

1. Модель прецедентов: диаграммы последовательностей.

2. Модель прецедентов: детализация с помощью описания операций.

Вопрос 1. Модель прецедентов: диаграммы последовательностей

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

Прежде чем приступать к проектированию логики работы программного прило­жения, необходимо исследовать и определить ее поведение как "черного ящика".

Поведение системы (system behavior) представляет собой описание того, какие действия выполняет система, без определения механизма их реализации. Одной из частей такого описания является диаграмма последовательностей. К осталь­ным частям относятся прецеденты и описания системных операций.

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

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

Например, кассир, введя идентификатор товара, тем самым предписывает, чтобы система POS записала данные о приобретении товара. Это событие инициирует в системе выполнение некоторой операции.

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

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

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

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

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

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

Пример, приведенный на рис. 1.1, соответствует основному успешному сце­нарию прецедента Оформление продажи. Он иллюстрирует, что для POS-системы кассир генерирует системные события makeNewSale, enterItem, endSale и makePayment.

Рисунок 1.1 – Диаграмма последовательностей для сценария прецедента Оформление продажи

Системные события и прецеденты

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

Рисунок 1.2 – Диаграммы последовательностей строятся на основе описания прецедентов

Системные события и границы системы

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

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

Рисунок 1.3 – Определение границ системы

Имена системных событий и операций

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

Имя системного события лучше всего начинать с глагола: add. . . (добавить), enter... (ввести), end... (завершить), make... (выполнить) (рис. 1.4). Это повышает читабельность имен и, кроме того, дополнительно под­черкивает направление передачи событий.

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

Рисунок 1.4 – Выбирайте имена событий и операций на абст­рактном уровне

Отображение текста из описания прецедента

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

Рисунок 1.5 – Диаграмма последовательностей системы с текстом из описания прецедента

Вопрос 2. Модель прецедентов: детализация с помощью описания операций

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

Описания Системных операций (system operation contract) описывают детальное поведение системы в терминах изменения состояния объектов модели предметной области после выполнения системных операций.

Описания определяются для системных операций (system operations).

Сис­темные операции – это операции, входящие в открытый интерфейс системы для обработки входных системных событий, которые система выполняет как «черный ящик». Системные операции можно идентифицировать на основе системных событий (рис. 2.1).

Рисунок 2.1 – Системные операции обрабатывают входные системные события

Весь набор системных операций, выполняемых в процессе всех прецедентов, определяет открытый системный интерфейс, в ракурсе которого система рас­сматривается как единый компонент или класс. В UML систему в целом можно представить в виде одного класса.

Разделы описания

Постусловия

В разделе "Постусловия" декларируются изменения состояния объектов моде­ли предметной области. К таким изменениям относятся создание экземпляра, формирование или разрыв ассоциации, или изменение атрибута.

Постусловия – это не действия, выполняемые в процессе операции, а лишь декларация об изменении состоянии объектов модели предметной области после выполнения операции.

Существуют следующие категории постусловий описаний:

• создание и удаление экземпляра;

• модификация атрибута;

• формирование и разрыв ассоциаций.

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

Обсуждение: постусловия описания операции enterItem

В этом подразделе подробно рассматриваются постусловия системной операции enterltem.

Создание и удаление экземпляра

Какие новые объекты создаются в системе, когда кассир вводит код товара itemID и количество его единиц quantity? Должен быть создан экземпляр объ­екта SalesLineItem.

Таким образом:

• создан экземпляр sli класса SalesLineItem (создание экземпляра).

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

Модификация атрибута

Какие атрибуты новых или уже существующих объектов должны быть мо­дифицированы, когда кассир вводит код товара itemID и количество его единиц quantity? Должно быть установлено количество покупаемых единиц для товара SalesLineItem.

Таким образом:

• атрибуту sli. quantity присвоено значение quantity (модификация атрибута).

Формирование и разрыв ассоциации

Какие ассоциации между новыми или существующими объектами должны быть сформированы или разорваны, когда кассир вводит код товара itemID и количество его единиц quantity? Новый покупаемый товар SalesLineItem должен быть связан с текущей продажей Sale, а также со своей спецификацией productSpecification.

Таким образом:

• экземпляр sli связан с текущим экземпляром класса Sale (формирование ассоциации);

• экземпляр sli связан с классом ProductSpecification на основе соответ­ствия идентификатора товара itemID (формирование ассоциации).

Обратите внимание на неформальную констатацию формирования взаимо­связи с конкретным экземпляром класса ProductSpecification на основе соот­ветствия идентификатора товара itemID.

Составление описания

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

1. Определите системные операции из диаграмм последовательностей.

2. Составьте описание для сложных системных операций, результаты кото­рых с очевидностью не следуют из описания прецедента.

3. При описании постусловий используйте следующие категории:

• создание и удаление экземпляра;

• модификация атрибута;

• формирование и разрыв ассоциаций.

Советы по составлению описаний системных операций

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

• Создан экземпляр SalesLineItem (лучше).

• Создание экземпляра SalesLineItem (хуже).

• Необходимо установить отношения между существующими и вновь созда­ваемыми объектами путем формирования ассоциаций. Например, при вы­полнении операции enterItem недостаточно просто создать новый экземп­ляр записи о покупке товара SalesLineItem. После выполнения операции этот экземпляр должен быть связан с текущей продажей Sale. Поэтому од­ним из постусловий этой операции является следующее.

• Вновь созданный экземпляр SalesLineItem связан с объектом Sale (формирование ассоциации).

Пример POS-системы ТТ: описания

Системные операции для прецедента оформление продажи Описание операции

ОП 1: makeNewSale

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

Напомним один из основных принципов RUP: стремитесь к максимальной про­стоте и избегайте использования артефактов, которые не добавляют новых знаний.

ОП 2: enterItem

ОП 3: endSale

ОП 4: makePayment