Форум Сообщества Аналитиков

×


Просмотр сообщений

В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.


Сообщения - PavelZh

Страницы: 1
1
lnew, книги я, конечно же читаю, но стараюсь анализировать предлагаемые стандарты описания и формировать свой удобный инструмент на основе стандартов, который будет понятен всем. Стандарт UML не является широко используемым в нашей компании, поэтому, повторюсь: главным для меня является корректное формулирование ВИ.
Изначально у меня были проблемы с изображением некоторых моментов на диаграмме. Например, отмены на любом шаге (в текстовом описании такая проблема легко решается). Кроме того, остались проблемы, по которым я формулирую вопросы ниже.

Я сейчас сформирую текстовое описание того, что изображено (просто напишу по картинке) и может быть мы попробуем обсудить его?

Опускаю описание абстрактного прецедента "Добавить товар"
Наименование ВИ: Добавить товар
Краткое описание ...
Участники: ...
Предусловия: ...
Постусловия: ...
Основной сценарий: ...
Альтернативные сценарии: ...
Бизнес-правила: ...

Здесь мы обобщенного опишем процедуру добавления товара (независимо от того штука это или единица упаковки)

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

Наименование ВИ: Добавить базовую единицу
Краткое описание: Добавление базовых единиц товара в каталог.
Участники: Публикатор.
Предусловия: нет предварительных условий (хотя здесь можно написать, что публикатор успешно авторизовался, но мне кажется это излишним)
Постусловия: товар добавлен и зарегистрирован [Комментарий: см. вопрос дальше]
Основной сценарий:
1. Публикатор запускает действие добавления базовой единицы товара.
2. Система предлагает форму для заполнения данных о товаре.
[Комментарий: Здесь на блок-схеме в пунктирном прямоугольнике значится точка расширения - это означало наличие точки расширения в будущих релизах на этом месте. Т.е. мы бы написали здесь: точка расширения: подменить пустую форму.]
3. Публикатор заполняет данные о товаре.
4. Публикатор инициирует Зарегистрировать товар Вопрос: Тут мы уходим в выполнение другого сценарий (сценарий, который может быть выполнен самостоятельно, но полагаю на диаграмме ВИ, необходимо изобразить include). Целью сценария "Добавить товар" было добавления товара в чистовики, сценарий "Зарегистрировать товар" преследует цель перевода товара из черновиков в чистовики. При успешном выполнении вызываемого сценария мы достигаем цель, т.е. выполнены постусловия. Верно?
Альтернативные сценарии:
3а Публикатор прерывает выполнение сценария.
    3а1 Система выдает запрос на сохранение изменений.
    3а2 Публикатор подтверждает сохранение изменений. [Комментарий: здесь можно было бы использовать комбинацию Если...иначе]
          3а2а Публикатор отклоняет сохранение изменений.
          3а2b Публикатор отменяет прерывание выполнения сценария. Возвращается к шагу 2.
4а Публикатор сохраняет товар в черновики.
    4а1 Система проверяет товар.
    4а2 Система сохраняет товар в черновики. Вопрос: Стоит ли использовать "минимальные гарантии успеха" для того, чтобы зафиксировать, что сохранение в черновики - это тоже частичное выполнение сценария?
          4а2а Система выдает публикатору сообщение об ошибке.
4b Публикатор инициирует Добавить упаковку. Вопрос: Здесь у меня возникает проблема: публикатор хочет запустить выполнение другого сценария, но системе предварительно необходимо произвести некоторые действия. Как это можно зафиксировать. При этом, опять же достигается выполнение сохранения товара в черновики, но не главная цель.

        

2
Если Вам, вашим клиентам и разработчиком понятно, то критиковать нечего. Мне кажется, я понял, что Вы хотели сказать этой иллюстрацией.

Но ...

... это не UML, увы.

Нужно ли изучать и моделировать на UML - это Ваш выбор. Многие обходятся без этого.
lnew, форумчане, тогда ещё вопрос задам: можно ли сказать, что это хорошо описанный ВИ или нет?
В конце концов: конечная цель у меня сделать хорошо свою работу, независимо от того какой стандарт я применяю.

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

3
Как я это делаю...Критикуйте!!!

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

4
1-3. Если использовать UML: RUP рекомендует использовать для моделирования рабочего потока UC диаграмму деятельности (Activity Diagram). Если Ваша блок-схема - это диаграмма деятельности UML, то я могу посоветовать, как поступить в каждом из описанных случаев. Если нет - кто же знает, что Вы рисуете?
Гм. Попробую сформулировать свое понимание диаграмм деятельности. Поправляйте.
С помощью диаграммы деятельности удобно моделировать поведение системы: порядок выполнения действий/ операций. Еще можно, используя эти диаграммы, описать порядок выполнения ВИ.
С другой стороны, ВИ - как игра в настольный теннис. Здесь есть последовательные действия системы и действия актора. Поэтому затрудняюсь ответить: являются ли мои блок- схемы - диграммой деятельности.
Я постараюсь в ближайшее время показать каким образом выглядит мое описание ВИ. Тогда можно будет более детально оценить, покритиковать:)

5
Посмотрите такой вариант. Пример 5 и 7. Не подойдет?
Ага) что-то похожее на Коберна, но чуть симпатичнее.
P.s имел ввиду отмену всего, что было сделано в рабочем потоке UC

6
Доброго времени суток.
1. Действие "Отмена" доступно пользователю на протяжении всего ВИ. Как зафиксировать данный момент? У Коберна встречал такую практику: на первом шаге описывается расширение со словами "В любой момент до ... пользователь может отменить ...". Не очень понравился такой способ, есть ли ещё какие-нибудь варианты?
2. На некотором шаге ВИ возможным продолжением для пользователя является запуск другого ВИ (при этом обратно пользователь уже не возвращается). В данном случае я не фиксирую связей на диаграмме прецедентов, а в первоначальном ВИ создаю шаг альтернативного (на самом деле может быть и основным, полагаю) сценария, в котором прописываю "Публикатор иницирует Зарегистрировать ...". Верным ли является данный подход?
3. Наконец, я документирую ВИ используя блок-схемы, а не текстовое описание (при этом я стараюсь следовать стандартам текстовых описаний). Возможен ли такой подход? +/- такого решения, на ваш взгляд?

С терминологией могу немного плавать.

P.s. Вкратце о себе: работаю системным аналитиком 2 года, слежу за сообществом уже давно. Вот, наконец, решил включиться в активное общение.

Если вопросы придутся по душе, попробую задать ещё несколько  :)

Страницы: 1