19. Итеративный и последовательный подход в процессе объектно-

ориентированного моделирования.

Итеративный подход (англ. iteration — повторение) — выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл: Планирование — Реализация — Проверка — Оценка

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

• акцент усилий на наиболе важные и критичные направления проекта;

• непрерывное итеративное тестирование, позволяющее оценить успешность всего проекта в целом;

• раннее обнаружение конфликтов между требованиями, моделями и реализацией проекта;

• более равномерная загрузка участников проекта;

• эффективное использование накопленного опыта;

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

• затраты распределяются по всему проекту, а не группируются в его конце

Последовательный подход (пп)

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

20. Процесс моделирования, использующий сценарии

21) Процесс моделирования, ориентированный на классы.

Ориентированное на классы (Class-Driven) моделирование приложений

Рисунок показывает процесс моделирования, который часто называется "ориентированным на классы" (Class-Driven), потому что требования определяются с помощью CRC (class-responsibility-collaboration - класс-ответственность взаимодействие) моделирования. CRC моделирование - техника в которой группа экспертов предметной области определяет требования приложения на стандартных карточках, разделенных на три секции: название класса, его ответственности (что он знает и делает) и другие классы с которыми класс взаимодействует для выполнения своих ответственностей.

Можно применять этот подход в окружении, где имеется доступ в пользователям, которые работают изо дня в день. CRC моделирование - это простая техника, которой вы можете научиться за несколько минут. Она не техническая и не отпугивающая техника, которая хорошо согласуется с диаграммами классов, т.к. моделирует множество таких же концепций. Хотя и CRC моделирование не определено в UML, это хорошо распознаваемая техника.

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

Автор предпочитает использовать диаграммы взаимодействия, когда необходимо показать асинхронную передачу сообщений между объектами, и предпочитает использовать диаграммы последовательностей для синхронной логики. Правда, что UML предоставляет механизм отображения асинхронных сообщений на диаграммах последовательностей и синхронных сообщений на диаграммах взаимодействия, но честно говоря механизм тяжеловат. Каждая UML диаграмма имеет свои сильные и слабые стороны, и это прекрасный пример того что вы можете использовать одни диаграммы вместо других.

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