Собственно, развиваю тему ниже. Выделил я классы анализа(может быть даже правильно выделил . Правильно-ли будет на этапе анализа распределять по ним атрибуты и операции или этого в этой фазе делать не надо

Здравствуйте, Cynic, Вы писали:

C>Собственно, развиваю тему ниже. Выделил я классы анализа(может быть даже правильно выделил . Правильно-ли будет на этапе анализа распределять по ним атрибуты и операции или этого в этой фазе делать не надо

Смотря, какая цель анализа. Я на стадии анализа предметной области создаю только сущности и связи между ними (диаграма классов и ассоциации между классами), плюс добавляю множественность. Как пример, вот такая дриаграма

Здравствуйте, Cynic, Вы писали:

C>Собственно, развиваю тему ниже. Выделил я классы анализа(может быть даже правильно выделил . Правильно-ли будет на этапе анализа распределять по ним атрибуты и операции или этого в этой фазе делать не надо

Товарищ, вы слишком последовательно подходите к активностям разработки.
Запомните: разработка итеративна, вы собираете требования, делаете дизайн, собираете прототип, с помощью прототипа получаете уточненные требования итп.

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

Здравствуйте, gandjustas, Вы писали:

G>Товарищ, вы слишком последовательно подходите к активностям разработки.
G>Запомните: разработка итеративна, вы собираете требования, делаете дизайн, собираете прототип, с помощью прототипа получаете уточненные требования итп.

Хорошо бы ты вспомнил это при чтении книги Эванса

Здравствуйте, gandjustas, Вы писали:

G>Товарищ, вы слишком последовательно подходите к активностям разработки.

А кто Вам сказал, что я последователен

G>Запомните: разработка итеративна, вы собираете требования, делаете дизайн, собираете прототип, с помощью прототипа получаете уточненные требования итп.

Я именно так и делаю

Здравствуйте, Cynic, Вы писали:

C>Собственно, развиваю тему ниже. Выделил я классы анализа(может быть даже правильно выделил . Правильно-ли будет на этапе анализа распределять по ним атрибуты и операции или этого в этой фазе делать не надо

Порекомендую книгу.

Якобсон, Буч, Рамбо. Унифицированный процесс разработки программного обеспечения. Издательство Питер (как всегда)

От создателей UML и UP. Очень подробно описано про UP.

Здравствуйте, Буравчик, Вы писали:

Б>Порекомендую книгу.

Б>Якобсон, Буч, Рамбо. Унифицированный процесс разработки программного обеспечения. Издательство Питер (как всегда)

Б>От создателей UML и UP. Очень подробно описано про UP.

Спасибо Хорошая книга, легко читается. Залил её себе и за час прочитал 20-ть страниц. И даже всё запомнил Прошелся от сбора требований до реализации и тестирования. Стало гораздо понятней. Если так всё написано, придётся её прочитать.

Пока читал появился следующий вопрос. Когда стоит начинать описывать TestCas'ы Просто в книге по этому поводу написаны немного противоречивые вещи. С одной стороны, написано:

Мы начали разработку в подразделе «Определение вариантов использования» с определения вариантов использования, затем в подразделе «Анализ, проектирование и разработка при реализации варианта использования» мы проанализировали, спроектировали и реализовали систему, осуществляющую эти варианты использования. Теперь опишем, как проверить, что варианты использования были осуществлены правильно.

Т.е. TestCas'ы упоминаются как-бы после "реализации системы". Но с другой стороны, утверждается:

Рано определяя варианты использования, мы рано начинаем планировать тестирование и рано находим эффективные тестовые примеры. Эти тестовые примеры могут усложняться по ходу проекта, по мере того, как мы расширяем наше понимание осуществления системой вариантов использования.

Т.е. TestCas'ы лучше писать как можно раньше. Вот я задался вопросом