Вопрос в следующем. Прочтенные мною книги по ОО проектированию и моделированию систем окончательно запутали меня в плане с чего начинать и кто что в процессе разработки должен делать.

В книге: UML 2.0. Объектно-ориентированное моделирование и разработка. Дж. Рамбо, М. Блаха говорится о трех моделях:
        модели классов
        модель состояний 
        модель взаимодействия
Как я понял базовые концепции ОО проектирования и моделирования. В той же последовательности описывается и процесс проектирования приложения.

Открываем другую книгу: Визуальное моделирование с помощью IBM Rational Software Architect и UML (Серия:'developerWorks')
Здесь минимум теории в основном практика. И модели (я так понимаю в соответствии с концепциями RUP'а) строятся немного в другой последовательности. При этом заявляется что в книге описывается именно конкретный пример процесса разработки системы от постановки требования до реализации.  

У меня возникает путаница. С чего вообще начинается моделирование....Какой уровень абстракции необходимо выбрать на каждом из этапов разработки системы...Кто должен какие модели строить, т.е. все делает аналитик.....да ерунда, не может же он уточнять модель до классов понятных разработчикам(которые фактически представляют класс конкретного языка программирования). А тогда если аналитик оперирует с классами на высоком уровне абстракции, то кто тогда уточняет эти классы до низкого уровня(кто рисует диаграммы последовательности, уточняет диаграммы классов типами и т.д...)

Хотелось бы разьяснений от тех кто работал, знает как происходит все на практике. И собственно с чего начинать....?

А единого мнения по этому вопросу нет.

Как только что убедились - каждый предлагает свой план.

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

То есть если проект небольшой и предметная область не очень широкая, то в принципе можно обойтись и несколькими диаграмами описывающими требования, варианты использования и состояния системы(по RUP требования и анализ). А потом собственно кодинг, базинг и дизайнинг.

Если же не все ясно, то следует все выше перечисленное, плюс проектирование(классы, последовательности, уточнение классов)....

Мне кажется это очень грубо, но более менее......  

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

главное, чтобы разработчики понимали, что они написали, что они пишут, и что будут писать, и еще чтобы это было с клиентом согласовано, а что используется для поддержания этого -- схемы/модели или память разработчиков -- второстипенно

хотя Се ля ви может лучше напишет, но его что-то нет

Добавлено через 1 минуту и 18 секунд
да, совсем забыл, куча картинок -- это же еще и повод сбить больше денег...

 Так, походу я догнал. 

Первый этап:  Концептуализация системы

Второй этап: Анализ системы  
                (здесь как раз сразу и выясняются классы которые характерны для предметной области системы и которые отражают все реальные объекты жизни, рисуются диаграммы состояний для системы, т.е. как планируется функционирование ее, перехода из одного состояния в другое)

Третий этап: Анализ приложения  
                (Вот с этого этапа и начинается описание в книге 'Визуальное моделирование с помощью IBM Rational Software Architect и UML (Серия:'developerWorks')'. 
                 Это и модель взаимодействия(диаграммы вариантов использования и диаграммы активности), 
                 это и модель классов, которая перерабатывается из модели классов второго этапа, это и диаграммы последовательностей и состояния уже не для системы, а для объектов.
                вообщем более низкий уровень абстракции.

Четвертый этап:  Проектирование, где все объекты наполняются нюансами, такими как типы полей, функции и т.д.

Пятый этап:  Реализация программистами.

Вот    

Поправляйте если не так)
  

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

В Agile порядок следующий

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

Кто: вся команда.

1. Сначала начинается с цели и видения.
2. Собираются User Stories (кратко см. User Stories by Mike Cohn - тут принципы получения и управления ими)
3. Раскидываются по релизам
4. Исходя из полученной картинки команда начинает моделировать архитектуры
http://www.agilemodeling.com/essays/initia...ureModeling.htm
5. А потом уже наращиваем детали ( пример: http://www.agilemodeling.com/essays/modelStorming.htm )
6. Чем ниже спускаемся, тем моделирование проявляется в кодировании с использованием Test-Driven Development.

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

На практике всегда выходило от общего к частному. Используем распределение модулей, компонент, потом детали. Чаще используем СRC сессию во время обсуждений.


vision -> architecture envision (crc) -> models (crc) -> crc/ class diagrams/ sequences diagramm

* CRC = class responsibility collaboration.

archengel, в книге "UML 2.0. Объектно-ориентированное моделирование и разработка" подход правильный. По крайней мере на мой аналитический взгляд.
Другое дело, что там описана программа-максимум, т.е. при необходимости и в зависимости от задачи можно какие-то этапы выбросить, а на каких-то заострить внимание больше. Тут нет никаких догм, все достаточно гибко (разве это не круто?! ) и определяется решаемой задачей. Нужно просто сконцентрироваться на ее решении, а не на соблюдении кем-то описанных стандартов. Здравый смысл и опыт вам подскажут, что нужно, а что нет. Может не с первого раза, а с пятого  Но разве это так страшно?

Ida, спасибо, я перечитал эту замечательную книгу и склоняюсь именно к тому что "все гибко". Кайф!