Верны ли моя схема вариантов использования и сценарий?

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

введите здесь описание изображения

И я написал сценарий следующим образом:

--- BEGIN ---
Use-case name: Set Up Organization Tree
Description: Allow country admins or customer admins to set up the organization
  structure. Country admins can see or update all members of their country. Customer
  admins can see or update members of their own organization only. 
Actors:
  - Primary actor - Country admin
  - Secondary actor – Customer admin

Basic-flow: Set up an organization structure in the country root
  1) Log in
  2) View organization tree
  3) Create a new organization
  4) Create a new user within the organization
  5) Set the password of the user
  6) 2 to 5 may repeat
  7) Log out

Alternate fow: Set up user accounts within the existing organization
  1) Log in
  2) View organization tree
  3) Create a new user within the selected organization
  4) Set the password of the user
  5) 2 to 5 may repeat
  6) Log out
--- END ---

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

Войтех

ИЗМЕНИТЬ 1:

Вот обновленная версия:

введите здесь описание изображения

И обновленный сценарий:

--- BEGIN ---
Use-case name: Create New Customer Organizational Structure
Description: Allow country admin to create new organizational structure of the customer including users. Allow customer admins to create new users within the existing organizational structure. The country admin can see or update all members of the country. The customer admin can see or update users of his/her own organization only.

Actors:
- Country admin
- Customer admin


Basic-flow: Country admin creates new customer organizational structure

Pre-conditions:
- The country admin is logged in
- The customer organizational hierarchy doesn't exists in the Member Manager

Flow of events: Create New customer Organizational Structure 
1) The country admin views the organization tree
2) The country admin creates a new organization
3) The country admin creates a new user within the organization
4) The country admin sets the password of the user
5) 1 to 4 may repeat

Post-condition:
- Customer organizational hierarchy is created
- Customer users are created
- Each user has a password


Alternate fow: Country admin creates new user in the existing organizational structure

Pre-conditions:
- The country admin is logged in
- The country admin can see or edit all members of the country
- The customer organizational hierarchy exists in the Member Manager
- The user that is going to be created doesn't exist

Flow of events:
1) The country admin views organization tree
2) The country admin creates a new user within the selected organization
2) The country admin sets the password of the user
4) 1 to 3 may repeat

Post-condition:
- New users are created in the selected organization
- Each user has a password


Alternate fow: Customer admin creates new user in the existing organizational structure

Pre-conditions:
- The customer admin is logged in
- The customer admin can see or edit members of his own organization only
- The customer organizational hierarchy exists in the Member Manager
- The user that is going to be created doesn't exist

Flow of events;
1) The customer admin views organization tree
2) The customer admin creates a new user within the selected organization
2) The customer admin sets the password of the user
4) 1 to 3 may repeat

Post-condition:
- New users are created in the selected organization
- Each user has a password

--- END ---

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

- Alternate fow: Country admin creates new user in the existing organizational structure
- Alternate fow: Customer admin creates new user in the existing organizational structure

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

Спасибо. Войтех


person Vojtech    schedule 28.05.2014    source источник
comment
Это может помочь в отношении входа/выхода из системы: stackoverflow.com/questions/19443682/   -  person observer    schedule 16.06.2014


Ответы (1)


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

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

  1. Кажется, вы слишком расширили сценарии UC за пределы UC. Большинство шагов соответствуют другим UC! У вас не должно быть «входа», «выхода из системы» и других подобных действий в каждом UC, поэтому они определяются отдельно. Таким образом, вы должны сосредоточиться только на атомарном действии самого UC.
  2. Описание UC совершенно не соответствует сценариям! В сценарии вы создаете новых пользователей, а заголовок — «настроить организацию». Это неясно. Название UC должно четко обозначать его цель, и это должно быть достигнуто посредством успешного сценария.
  3. Должно быть четко указано, при каких условиях будет вызываться каждый поток.

Я предлагаю вам исправить эти проблемы и опубликовать новую версию сценариев. Затем мы можем настроить их дальше.

ОБНОВЛЕНИЕ (после 1-й переработки):

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

  • вход в систему и выход из системы должны быть там как отдельные варианты использования. Логин имеет постусловие «пользователь вошел в систему». Вы правильно использовали соответствующее предварительное условие!
  • предусловия/постусловия применяются к UC в целом, а не к отдельным потокам, как подробнее поясняется в следующих конкретных пунктах.
  • Я бы разбил основной поток на 2 UC: первые 2 шага соответствуют UC «Создать новую организацию», а шаги 3-4 могут дать UC «Создать пользователя». Шаг 5 не нужен
  • Альтернативные потоки полностью отображаются на «Создать пользователя», вам нужно просто немного уточнить предварительные условия. Они всегда общие, но можно разделить на 2 потока, в зависимости от пользователя
  • Я бы уточнил предусловия/постусловия. Вы должны сохранить небольшое их количество, так как они просто указывают, может ли UC запускаться. Все остальные правила должны быть перемещены внутрь конкретных сценариев. Например, «У каждого пользователя есть пароль» слишком очевидно/слишком подробно, достаточно сказать, что пользователь был создан. «Пользователь, который будет создан, не существует» - это не имеет смысла, так как не может быть оценено в этот момент. :)

Попытайтесь увидеть UC более конкретными и закрытыми. У них должна быть единственная и простая цель. Альтернативные потоки должны показывать разные пути достижения цели и не должны делать разные вещи. Все потоки имеют одинаковые предусловия и все должны иметь одинаковые постусловия (конечно кроме тех, которые содержат ошибки). Используйте правила внутри сценариев UC, чтобы определить альтернативные потоки (например, основной сценарий предназначен для «администратора клиента», а альтернативный поток — для «администратора страны».

Я бы посоветовал вам переработать модель еще раз и опубликовать ее обратно. :)

person Aleks    schedule 28.05.2014
comment
Большое спасибо за ваш отзыв. Я обновил свою диаграмму и сценарий в соответствии с вашими советами. Не могли бы вы посоветовать, что сейчас следует улучшить? Я все еще не уверен, как правильно описать обобщение актера в сценарии. Большое спасибо. - person Vojtech; 02.06.2014
comment
Намного лучше, но все еще нуждается в паре структурных улучшений. Пожалуйста, смотрите обновление в самом ответе. - person Aleks; 04.06.2014