Игра Домино

[Alf]

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

Olegator, попробуй представить себя в роли продавца программного обеспечения, который решил заработать на продаже сетевой игры "Домино". Попытайся составить ТЗ на разработку программы, которое потом можно будет передать профессиональным разработчикам софта. Упор делаем на функциональную часть, поскольку сроки для учебного проекта - не главное.

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

[Olegator]

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

Описываются элементарные действия.
Но при этом всё должно быть достаточно подробно. Т.е. на какую кнопку надо нажать, чтобы выполнилось нужное действие.
Описывать надо именно так, как поступил бы пользователь, а не как функции программы. Т.е. написать:”кость может быть перетащена на стол”, наверное, неправильно.

Я всё это вычитал из книги про ICONIX. Там есть десять самых распространённых ошибок при составлении модели прецедентов. К вечеру я их выложу.

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

[Olegator]

Как составляется прецедент:
1. Прецедент состоит из главной последовательности и альтернативных последовательностей.
2. Задаться вопросом "Что происходит?" С ответа на него начинается главная последовательность
3. Задаться вопросом "Что дальше?" Задаваться этим вопросом пока не будут обнаружены все детали главной последовательности.
4. Задаться вопросом "Что ещё может произойти?" Надо найти все альтернативные последовательности. И тут надо стараться найти все альтернативные последовательности.

Целью является описать всё, что может сделать пользователь.

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

[Olegator]

В книге описывется 10 самых распространённых ошибок при составлении прецедентов:
10. Пишут функциональные требования вместо словесного описания использования.
9. Описывают атрибуты и требования, а не порядок использования.
8. Слишком лаконично записываются требования.
7. Полностью абстрогируются от интерфейса пользователя
6. Не присваивают явные имена граничным объектам
5. Описывают прецеденты не с точки зрения пользователя.
4. Описывают только действия пользователя, игнорируя реакцию системы
3. Опускают альтернативные последовательности действий.
2. Акцентируют внимание на чём-то не относящемуся к самому прецеденту. Например на том когда он начинается или, что происходит позже.
1. Затрачивают много времени, решая, что использовать включение или расширение. (Это что-то из UML)

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

[Olegator]

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

[Igel]

Прочитал - все понятно.
Нужно составлять список прецендентов?
П.С. Вопрос, а тесты писать будем?

[Olegator]

Нужно составлять список прецендентов?

Не прецендентов, а прецедентов.
Нужно.

П.С. Вопрос, а тесты писать будем?

Тесты чего?

[nikedeforest]

Он, наверное, имееет ввиду, будете ли вы использовать технологию Юнит-тестирования

[Igel]

Он, наверное, имееет ввиду, будете ли вы использовать технологию Юнит-тестирования

Да! Вы абсолютно правы!

Не прецендентов, а прецедентов.
Нужно.

Бывает...
Попробую...

[Olegator]

1. Надо ли сделать так, чтобы программа в некоторые моменты делала очевидные действия за игрока? Например:
Когда у игрока и в базаре нет подходящей кости программа сама передавала бы ход следующему игроку. Или же сделать наиболее близко к реальности. Игрок сам нажимает на кнопку пропуск хода. Плюс ещё заставить игрока самого вести счёт, а программа будет просто проверять правильность подсчёта.

2. Надо ли ввести в словарь терминов переход хода и как его описать.

3. Надо ли ввести в словарь терминов подходящяя и неподходящяя для хода кость и как это описать.

[nikedeforest]

По пункту 1, думаю, что надо вывести информационное сообщение, что игрок пропускает ход по причине тобою указанной и передать ход следующему. Это мое имхо.

Олегатор, а ты выкладывал уже словарь терминов? Что есть сейчас?

[Olegator]

Олегатор, а ты выкладывал уже словарь терминов? Что есть сейчас?

Во втором посте этой темы.