| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Системный анализ, проектирование и UML > Прецеденты |
| Автор: SLeN 13.2.2008, 19:53 | ||
Меня мучают сомнения правильно ли я составляю развернутое описание прецедента, не слишком ли это подробно (на алгоритм уже тянет) ? или так и надо - чем подробнее тем лучше в развернутом описании...
|
| Автор: Aazmandius 17.2.2008, 02:35 |
| +1 сценарии-рассказы намного легче воспринимать |
| Автор: SLeN 17.2.2008, 12:56 | ||
| Надеюсь что понял К примеру если я буду испоьзовать метод система как "Черный ящик" и описывать лиш взаимодействие актер - система, ситема - актер то прецеденты будут лучше ? Продолжая тему купонов
Очень хочется увидеть Прецеденты с Мэтом и Пегги |
| Автор: SLeN 17.2.2008, 15:56 | ||
В общем получилась такая тема:
P.S.: Попробовал составлять веселые сценарии-рассказы... По мне так они больше годятся для «Функционального» программирования, чем для последующего анализа, или я опять что то недопонял |
| Автор: Aazmandius 18.2.2008, 19:01 |
| Ну Мэт и Пегги в данном случае представляют экземпляры каких-либо классов, Мастер, Клиент, Клерк и т.д (выделяем объектную модель). То есть при достаточно детализированном описании их деятельности можно определить, что является их сферой деятельности - то бишь выделить методы классов, которые будут нужны в проектируемой системе. Аналогично в рассказе наверняка промелькнет взаимодействие наших героев с другими участниками бизнес-процесса, Начальником например. А те бумажки, которые Пегги будет заполнять по ходу рассказа - документооборот внутри компании, то бишь потоки данных. Их также можно и нужно анализировать. Ну и т.д. Непринужденный стиль - это не самоцель, он служит именно для облегчения восприятия, потому что когда читаешь сухие казенные фразы, то заснуть хочется на второй строчке. У Акоффа (который Рассел) подобные изложения в казенном стиле (например постановка задачи, которую он когда-то решал) как правило дальше расписаны в доступном изложении и он сам называет это "В переводе на человеческий язык". Оставим казенные фразы бюрократам |
| Автор: SLeN 18.2.2008, 20:22 |
| |
| Автор: ida 25.3.2008, 17:09 |
| SLeN, внимательно не читала - в целом описание хорошее (степень детализации оптимальная, ни мало ни много), но над ним еще предстоит поработать. В-частности: 1. "Система не записывает в заказ номер купона" - таких формулировок быть не должно. Нас интересует, что система ДЕЛАЕТ, а не чего она не делает. Если она чего-то не делает - просто не пишите ничего. 2. Система проверяет бизнес правила ( можно ли добавить купон к заказу ) 2.а Бизнес правила Запрещают добавление номера купона к заказу 1. Мастер Приносит свои соболезнования клиенту 2.б Система не может проверить бизнес правила Где вариант: "Бизнес-правила разрешают добавление номера купона к заказу"?... Вы должны описать ВСЕ возможные ветви алгоритма, иначе возникнет исключительная ситуация, которую непонятно как обрабатывать. 3. 1. Мастер производит попытку добавить номер еще 1го купона Такие формулировки также лучше не использовать: лучше "Мастер добавляет номер еще одного купона" (проверка того, можно ли это сделать, должна осуществляться ПЕРЕД действием). Бегло вроде все. Потом может посмотрю внимательнее, еще что-то напишу. |
| Автор: SLeN 31.3.2008, 09:57 |
| ida, Спасибо! Буду ждать вниматеьного просмотра =) |
| Автор: ida 4.4.2008, 12:20 |
| Нашла у себя книгу "Современные методы описания функциональных требований к системам" (в оригинале "Writing effective use cases"), автор Алистер Коберн. Она вышла каким-то невероятно маленьким тиражом, но можно поискать в Интернете. Это как раз про варианты использования. |
| Автор: ida 26.4.2008, 17:32 |
| SLeN, вот что еще пишет А.Коберн в своей книге, возможно, это будет вам интересно. Большинство хорошо написанных вариантов использования имеют от 2 до 8 шагов (неясно, имеются ли в виду и альтернативные сценарии - скорее всего нет). Если в варианте использования более 10 шагов, то скорее всего туда включены действия более низкого уровня абстракции. Т.е. его надо пересмотреть. Можно еще пользоваться правилом "7+-2" - емкость краткосрочной памяти человека. |