День добрый! Только начинаю изучать все это дело, поэтому вопросы...
Положим, нужно построить диаграмму юзкейсов простой игры, рафинируем требования (из как бы ТЗ) до 4х пунктов:
— игрок может начать новую игру
— перед началом новой игры игрок вводит имена игроков
— игрок может делать ходы (собственно, основной процесс)
— игрок может сделать рестарт игры (т.е. начать игру с ранее введенными параметрами)
Такие соображения:
Актанты: игрок
Юзкейсы (описание сильно сократил, для краткости):
1.начать новую игру
2.ввести имена игроков
3.сделать ход
4.рестарт игры
Такое выделение юзкейсов сделал прямо из ТЗ.
Мне кажется, что это неправильное выделение, как правильно — не знаю. Соображения следующие.
Актант взаимодействует со всеми 4-мя юзкейсами (т.к. все 4 юзкейса требуют пользовательской реакции). При этом "ввести имена игроков" инклюдится в "начать новую игру", т.к. по якобсону-бучу-рамбо (ябр) этот юзкейс не существует отдельно, т.к. сам по себе не инициируется и, к тому же, не несет актанту конкретной пользы.
Плюс к этому, "рестарт игры" инклюдит в себя "начать новую игру", но юзкейс "ввести имена игроков" уже в случае рестарта игры не должен активироваться (а он инклюжен в "начать новую игру", и, следовательно, по транзитивности, инклюжен и в "рестарт игры"). Т.е. получается, что юзкейсы включаются в другие юзкейсы, но при этом имеют прямую связь с актантом (т.к. все 4-е либо активируются пользователем, либо принимают ввод от пользователя). Что нужно сделать? Как правильно?
Здравствуйте, Predicate, Вы писали:
P>Положим, нужно построить диаграмму юзкейсов простой игры, рафинируем требования (из как бы ТЗ) до 4х пунктов:
Вообще, юзкейсы лучше оформлять в виде текста — это позволяет их лучше структурировать. Представлять юзкейс в виде диаграммы выгодно в том случае, когда он уже хорошо структурирован. Диаграмма — лишь дополнительная иллюстрация.
P>- игрок может начать новую игру
Ваш юзкейс я бы описал таким образом:
Прецедент 1. Выбор действия.
Действующие лица: Программа, Пользователь.
Программа предлагает Пользователю выбрать действие.
Пользователь выбирает действие "Начать новую игру".
Пользователь выбирает действие "Продолжить существующую игру".
Пользователь выбирает действие "Рестарт игры".
P>Плюс к этому, "рестарт игры" инклюдит в себя "начать новую игру", но юзкейс "ввести имена игроков" уже в случае рестарта игры не должен активироваться (а он инклюжен в "начать новую игру", и, следовательно, по транзитивности, инклюжен и в "рестарт игры"). Т.е. получается, что юзкейсы включаются в другие юзкейсы, но при этом имеют прямую связь с актантом (т.к. все 4-е либо активируются пользователем, либо принимают ввод от пользователя). Что нужно сделать? Как правильно?
Расписываю далее (из примеров, думаю, будет понятно решение).
Прецедент 2. Начать новую игру.
Действующие лица: Программа.
Программа создаёт новую игру.
Программа начинает созданную игру. Прецедент 3. Рестарт игры.
Действующие лица: Программа.
Программа начинает созданную игру. Прецедент 4. Создать новую игру.
Действующие лица: Программа, Пользователь.
Программа предлагает Пользователю ввести имя игрока.
Пользователь вводит имя игрока.
Программа запоминает имя игрока.
Здравствуйте, Кирилл Лебедев, Вы писали:
КЛ>Здравствуйте, Predicate, Вы писали:
P>>Положим, нужно построить диаграмму юзкейсов простой игры, рафинируем требования (из как бы ТЗ) до 4х пунктов: КЛ>Вообще, юзкейсы лучше оформлять в виде текста — это позволяет их лучше структурировать. Представлять юзкейс в виде диаграммы выгодно в том случае, когда он уже хорошо структурирован. Диаграмма — лишь дополнительная иллюстрация.
P>>- игрок может начать новую игру КЛ>Ваш юзкейс я бы описал таким образом:
КЛ>Прецедент 1. Выбор действия. КЛ>Действующие лица: Программа, Пользователь.
КЛ> КЛ>Программа предлагает Пользователю выбрать действие. КЛ>Пользователь выбирает действие "Начать новую игру". КЛ>Пользователь выбирает действие "Продолжить существующую игру". КЛ>Пользователь выбирает действие "Рестарт игры". КЛ>
P>>Плюс к этому, "рестарт игры" инклюдит в себя "начать новую игру", но юзкейс "ввести имена игроков" уже в случае рестарта игры не должен активироваться (а он инклюжен в "начать новую игру", и, следовательно, по транзитивности, инклюжен и в "рестарт игры"). Т.е. получается, что юзкейсы включаются в другие юзкейсы, но при этом имеют прямую связь с актантом (т.к. все 4-е либо активируются пользователем, либо принимают ввод от пользователя). Что нужно сделать? Как правильно? КЛ>Расписываю далее (из примеров, думаю, будет понятно решение).
КЛ>Прецедент 2. Начать новую игру. КЛ>Действующие лица: Программа.
КЛ> КЛ>Программа создаёт новую игру. КЛ>Программа начинает созданную игру. КЛ>
КЛ>Прецедент 3. Рестарт игры. КЛ>Действующие лица: Программа.
КЛ> КЛ>Программа начинает созданную игру. КЛ>
КЛ>Прецедент 4. Создать новую игру. КЛ>Действующие лица: Программа, Пользователь.
КЛ> КЛ>Программа предлагает Пользователю ввести имя игрока. КЛ>Пользователь вводит имя игрока. КЛ>Программа запоминает имя игрока. КЛ>
Хм... а корректно ли, что в данном случае Прецедент 4 инклюдится в Прецедент 2 (и транзитивно в Прецедент 1), и при этом имеет прямую ассоциацию с актантом Пользователь? Хотя инициатором последней связи выступает в данном случае не Пользователь, а Программа. Т.е. получается этакое "зацикливание"... не должно ли это быть одним прецедентом (с точки зрения атомарности)?
И такой еще вопрос: в предложенном варианте получается, что Прецедент 1 следует оформить как имеющего два расширения? ("Начать новую игру" и "Рестарт игры", т.к. "Продолжить существующую игру" — как бы основной процесс)
Хм... а корректно ли, что в данном случае Прецедент 4 инклюдится в Прецедент 2 (и транзитивно в Прецедент 1), и при этом имеет прямую ассоциацию с актантом Пользователь? Хотя инициатором последней связи выступает в данном случае не Пользователь, а Программа. Т.е. получается этакое "зацикливание"... не должно ли это быть одним прецедентом (с точки зрения атомарности)?
И такой еще вопрос: в предложенном варианте получается, что Прецедент 1 следует оформить как имеющего два расширения? ("Начать новую игру" и "Рестарт игры", т.к. "Продолжить существующую игру" — как бы основной процесс)
Здравствуйте, Predicate, Вы писали:
P>Хм... а корректно ли, что в данном случае Прецедент 4 инклюдится в Прецедент 2 (и транзитивно в Прецедент 1), и при этом имеет прямую ассоциацию с актантом Пользователь? Хотя инициатором последней связи выступает в данном случае не Пользователь, а Программа. Т.е. получается этакое "зацикливание"... не должно ли это быть одним прецедентом (с точки зрения атомарности)?
Вопрос справедливый. Но в данном случае, как мне кажется, следует поступать так: писать прецеденты, как в момент написания кажется правильным, обращая внимание на операции (действия), а не на действующие лица. Затем, если окажется, что операция делегирована не тому действующему лицу, её всегда можно переделегировать. Например, все приведённые мною прецеденты можно спокойно переписать так, как будто они инициированы Пользователем.
P>И такой еще вопрос: в предложенном варианте получается, что Прецедент 1 следует оформить как имеющего два расширения? ("Начать новую игру" и "Рестарт игры", т.к. "Продолжить существующую игру" — как бы основной процесс)
Можно и так. Это всего лишь вопрос записи.
КЛ>Вопрос справедливый. Но в данном случае, как мне кажется, следует поступать так: писать прецеденты, как в момент написания кажется правильным, обращая внимание на операции (действия), а не на действующие лица. Затем, если окажется, что операция делегирована не тому действующему лицу, её всегда можно переделегировать. Например, все приведённые мною прецеденты можно спокойно переписать так, как будто они инициированы Пользователем.
Да, но в этом случае мы вернемся к 1-му посту: Один прецедент инклюдит в себя другой, и при этом оба прецедента имеют прямую ассоциацию с Пользователем: в данном случае, Прецедент 1 включает в себя Прецедент 4, и оба взаимодействуют с Пользователем... Это корректно? Или нужно что-то менять? А если избавиться от Прецедента 1, ввиду того, что он является посредником между Пользователем и другими прецедентами? (и при этом, Пользователь как бы изначально может обратиться только к одному прецеденту). Хотя сделать это просто не получится, т.к. в нем тоже заключена логика, в частности — предоставление Пользователю возможности выбрать действие.
А если вариант такой: убрать Прецедент 1, тогда пользователь будет напрямую связан с остальными прецедентами, у нег будет свобода выбора прецедента, к которому обратиться. Но при этом вписать предусловия в каждый прецедент. Скажем, в Прецедент "Продолжить существующую игру" впишем "была создана новая игра"? Правда, мне кажется, в этом случае не получится наглядно изобразить диаграмму состояний (например, автомат переходов, т.к. он навешивается на конкретный юзкейс, так?).
Здравствуйте, Predicate, Вы писали:
P>Да, но в этом случае мы вернемся к 1-му посту: Один прецедент инклюдит в себя другой, и при этом оба прецедента имеют прямую ассоциацию с Пользователем: в данном случае, Прецедент 1 включает в себя Прецедент 4, и оба взаимодействуют с Пользователем... Это корректно?
А почему некорректно? Вы просто разделяете операцию "Начать новую игру" на две: "Создать новую игру" и "Начать игру". И всё. А если для выполнения прецедента важно пообщаться с пользователем, то почему бы и нет?
P>А если вариант такой: убрать Прецедент 1, тогда пользователь будет напрямую связан с остальными прецедентами, у нег будет свобода выбора прецедента, к которому обратиться.
Мне кажется Вы слишком формально относитесь к написанию прецедентов. Прецеденты нужны, во-первых, для того, чтобы уточнить функциональные требования к программе (а при случае — и выявить их), во-вторых, для разработки эргономичного интерфейса взаимодействия программы с пользователем, и, в-третьих, для понимания логики работы программы и для составления алгоритмов работы самой программы (и её отдельных модулей). Т.е. прецеденты — чисто утилитарная вещь. К тому же, не надо относиться к ним, как к чему-то законченному и завершённому. Вполне вероятно, что при разработке эргономичного интерфейса Вы логику взаимодействия пользователя и программы существенно переделаете. Прецеденты просто задают необходимую канву.
КЛ>Мне кажется Вы слишком формально относитесь к написанию прецедентов. Прецеденты нужны, во-первых, для того, чтобы уточнить функциональные требования к программе (а при случае — и выявить их), во-вторых, для разработки эргономичного интерфейса взаимодействия программы с пользователем, и, в-третьих, для понимания логики работы программы и для составления алгоритмов работы самой программы (и её отдельных модулей). Т.е. прецеденты — чисто утилитарная вещь. К тому же, не надо относиться к ним, как к чему-то законченному и завершённому. Вполне вероятно, что при разработке эргономичного интерфейса Вы логику взаимодействия пользователя и программы существенно переделаете. Прецеденты просто задают необходимую канву.
Ну да , просто непривычно это все... пытаясь описать прецеденты, в голове роятся мысли по поводу возможной архитектуры приложения, а этого, видимо, допускать нельзя, т.к. процесс должен идти от прецедентов к архитектуре, а не наоборот. Надо практиковаться
А если избавиться от Прецедента 1, ввиду того, что он является посредником между Пользователем и другими прецедентами? (и при этом, Пользователь как бы изначально может обратиться только к одному прецеденту). Хотя сделать это просто не получится, т.к. в нем тоже заключена логика, в частности — предоставление Пользователю возможности выбрать действие.
, просто непривычно это все... пытаясь описать прецеденты, в голове роятся мысли по поводу возможной архитектуры приложения, а этого, видимо, допускать нельзя, т.к. процесс должен идти от прецедентов к архитектуре, а не наоборот. Надо практиковаться 
