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

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

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

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

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

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

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

Тема: Модель прецедентов: диаграмма прецедентов

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

1. Алгоритм построения прецедентов.

2. Дополнительная спецификация.

3. Видение.

4. Словарь терминов.

Вопрос 1. Алгоритм построения прецедентов

POS-система (point-of-sale system) – это компьютеризированное приложение, предназначен­ное для организации товарооборота и обработки платежей в обычных мага­зинах.

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

Это приложение свя­зано с различными служебными программами, например с программой вы­числения налогов, разработанной сторонними производителями, или с систе­мой складского учета товаров.

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

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

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

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

Процедура выделения прецедентов:

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

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

3. Для каждого исполнителя определить его задачи. Составить иерархию: в соответствии с рекомендациями по выделению ЕВР.

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

5. Построить диаграмму прецедентов.

Пояснения по каждому шагу процедуры:

Шаг 1. Определение рамок системы

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

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

Шаги 2 и 3. Определение основных исполнителей и задач

Нельзя однозначно указать последовательность определения исполнителей и задач. Иногда исполнители опре­деляются после формулировки задач, а иногда наоборот.

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

При определении основных исполнителей и задач пользователей следует от­ветить на следующие вопросы, чтобы не упустить из виду некоторые неочевид­ные моменты:

• Кто запускает и выключает систему?

• Кто является системным администратором?

• Кто осуществляет управление пользователями и безопасностью?

• Относится ли время к числу исполнителей, другими словами, должна ли система выполнять какие-либо действия в ответ на события времени?

• Существует ли процесс мониторинга, благодаря которому система пере­запускается в случае сбоя?

• Кто контролирует деятельность и производительность системы?

• Как выполняется обновление программного обеспечения?

• Кто анализирует журналы регистрации? Можно ли обеспечить удален­ный доступ к ним?

Основные и вспомогательные исполнители

Основные исполнители – это те, чьи потребности удовле­творяются с помощью системы. Для решения своих задач они используют сис­тему. В отличие от них, вспомогательные исполнители (supporting actor) зани­маются обслуживанием системы.

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

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

Таблица 1.1 – Перечень исполнителей и их задач

Примечание: Система анализа торговой деятельности (Sales Activity System) – это уда­ленное приложение, которое достаточно часто будет запрашивать данные от ка­ждого узла POS-системы по сети.

Основной исполнитель и задачи системы зависят от ее рамок.

Почему основным исполнителем для прецедента Оформление продажи является кассир, а не покупатель? Почему покупатель не включен в список исполнителей?

Ответ определяется рамками разрабатываемой системы, как показано на рис. 1.1. Если предприятие или торговую организацию рассматривать как агрегатную систему, то для нее основным исполнителем должен являться покупатель, задача которого – приобретение товаров или услуг. Однако с точки зрения самой POS-системы (которая определяет рамки системы для данного прецедента), основным исполнителем является кассир, задача кото­рого – обслуживание продаж.

Рисунок 1.1 – Основные исполнители и их задачи при определении рамок системы

Определение исполнителей и задач путем анализа событий

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

Таблица 1.2 – Перечень исполнителей и их задач на основе анализа внешних событий

Шаг 4. Определение прецедентов

Как правило, каждой задаче пользователя соответствует один прецедент уровня ЕВР. Его имя должно соответствовать названию задачи, например, задаче оформле­ния продажи должен соответствовать прецедент Оформление продажи.

Как правило, имя прецедента начинается с существительного, описываю­щего действие.

Типичным исключением из правила соответствия задач и прецедентов явля­ется прецедент, решающий четыре задачи – создание, восстановление, обновле­ние и удаление. Обычно такой прецедент называется Управление <чем-либо>. Например, задачи "изменение информации о пользователях", "удаление пользо­вателей" и т.д. решаются в рамках прецедента Управление пользователями.

Определение прецедентов выполняется за несколько этапов, одни из которых занимают несколько минут (например, присвоение имен прецедентам), а дру­гие – по несколько дней (развернутое описание).

Описание прецедентов, относящихся к интерфейсу пользователя

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

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

Такой процесс исследования позволяет получить новые и более эффектив­ные решения.

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

Базовый стиль описания

Эта идея была сформулирована в различных рекомендациях типа "не уде­ляйте внимания вопросам интерфейса пользователя, сосредоточьте внимание на содержательной стороне вопроса". Подобные идеи и предложения наиболее полно были изучены Ларри Константином (Larry Constantine) в контексте созда­ния наиболее удачного интерфейса пользователя и исследования удобства использования программных продуктов.

Если описание не содержит под­робной информации о реализации пользовательского интерфейса, а основное внимание в нем сосредоточено на содержательных моментах, то такой стиль описания Константин называет базовым (essential).¹

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

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

Все приведенные выше примеры прецедентов были выдержаны в базовом стиле описания, в том числе прецедент Оформление продажи.

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

Конкретный стиль описания

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

1. Администратор вводит идентификатор и пароль в диалоговом окне.

2. Система аутентифицирует администратора,

3. Система отображает окно Изменение пользователей.

4. ...

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

Исполнители

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

• Основной исполнитель (primary actor) – его задачи выполняются с использова­нием системы. Примером основного исполнителя является кассир.

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

• Вспомогательный исполнитель (supporting actor) – обслуживает систему (например, предоставляет информацию). Примером вспомогательного ис­полнителя является служба авторизации платежей.

• Зачем его идентифицировать? Чтобы определить внешние интерфейсы и протоколы.

• Закулисный исполнитель (offstage actor) – заинтересован в реализации преце­дента, но не является основным или вспомогательным исполнителем. При­мером закулисного исполнителя является налоговая служба.

• Зачем его идентифицировать? Чтобы удостовериться, что все интересы определены и удовлетворены. Интересы закулисных исполнителей обыч­но не очевидны и их легко упустить из виду, если не идентифицировать их в явной форме.

Шаг 5. Построить диаграмму прецедентов

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

Все сущности, включая разрабатываемую систему, могут играть различные роли.

Рисунок 1.2 – Фрагмент диаграммы прецедентов

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

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

Замечание: Целесообразно строить простые диаграммы прецедентов в соответствии со списком исполни­телей и их задач.

Диаграмма прецедентов – это изображение системного контекста, поскольку она отображает границы системы, внешние для системы понятия и способы использования системы. Она подытоживает поведение системы и ее исполнителей. Фрагмент простой диаграммы прецедентов для системы "ТТ" показан выше на рис. 1.2.

Система обозначений для диаграммы прецедентов