Мне интересно, но что такое "модель дизайна"?
Модель предметной области? Аналитическая модель приложения? Проектная модель?

Мне интересно, но что такое "модель дизайна"?
Модель предметной области? Аналитическая модель приложения? Проектная модель?

Модели анализа, дизайна и имплементации являются композитными артефактами классического RUP.
В частности более детально можно посмотреть тут http://www.ibm.com/developerworks/rational/library/4871.html

Мне интересно, но что такое "модель дизайна"?
Модель предметной области? Аналитическая модель приложения? Проектная модель?

Модели анализа, дизайна и имплементации являются композитными артефактами классического RUP.

RUP может быть не всем интересен...

а вот это уже и мне интересно.

Denis, помогите разобраться, почему при всём уважении к RUP,
я Вашу классификацию моделей воспринимаю намного естественнее, чем RUP-ую?

Для начала у меня вопросы:
1. Ссылочки, где это описано у "знающих людей",
2. Что лично Вы подразумеваете под приведёнными классами моделей?
3. Какое лично у Вас отношение к RUP?
Просто не интересно? Или
интересно, но во многом не согласны с предлагаемыми концепциями
и поэтому - не приемлемо?

2 BAS: это уже похоже на Off-Topic,
подскажи, где правильное место таким вопросам?

Denis, помогите разобраться, почему при всём уважении к RUP,
я Вашу классификацию моделей воспринимаю намного естественнее, чем RUP-ую?

Где можно почитать об этой классификации?

Мне интересно, но что такое "модель дизайна"?
Модель предметной области? Аналитическая модель приложения? Проектная модель?

Где можно ознакомиться с тем, что понимается под "Аналитическая модель приложения и Проектная модель"?

Где можно ознакомиться с тем, что понимается под "Аналитическая модель приложения и Проектная модель"?

Скорее всего это можно сделать в книге Рамбо и Блаха.
Авторы не привязываются к какому-то процессу разработки и дают (на их взгляд) более абстрактное деление моделей.
Они выделяют модель предметной области, т.е. модель абстракции ПрОб близкой по смыслу бизнес-модели RUP, если я не ошибаюсь.

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

Т.е. нет классов реализации, которые в дальнейшем и составляют проектную модель.

а если совсем просто, то аналитическая модель - результат фазы анализа, а проектная - фазы проектирования.

Скорее всего это можно сделать в книге Рамбо и Блаха.
Авторы не привязываются к какому-то процессу разработки и дают (на их взгляд) более абстрактное деление моделей.
Они выделяют модель предметной области, т.е. модель абстракции ПрОб близкой по смыслу бизнес-модели RUP, если я не ошибаюсь.

Не понял, чем это принципиально отличается от domain model, как части модели анализа, и далее ... от модели дизайна и имплементации ... ?

а если совсем просто, то аналитическая модель - результат фазы анализа, а проектная - фазы проектирования.

И чем это ОТЛИЧАЕТСЯ ОТ RUP ??

И чем это ОТЛИЧАЕТСЯ ОТ RUP ??

Предлагаю развить эту тему в другом топике, я там задал пару вопросов.

И чем это ОТЛИЧАЕТСЯ ОТ RUP ??

Много слышал о великом и ужасном RUP, но никогда не приходилось трогать его руками.

Можно ли получить ответы на такие вопросы:

RUP бесплатный?
Полностью ли переведен на русский язык?
Не привязан ли RUP к конкретным инструментам?

Не понял, чем это принципиально отличается от domain model, как части модели анализа, и далее ... от модели дизайна и имплементации ... ?

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

RUP бесплатный?

Нет. Его в некоторой степени эквивалент OpenUP

Полностью ли переведен на русский язык?

Только частным образом и как я понимаю тоже не бесплатно

Не привязан ли RUP к конкретным инструментам?

Нет, если например не считать инструмент от Ecllips
Многие инструменты, такие как РОза, VP?, EA включают шаблоны RUP в той или иной степени. Многие также используют стереотипы для бизнес-объектов например от этого самого RUP

RUP велик, но только как полномасштабный каркас. Ларман говорит RUP - это гибкая методология - не пользуйся ею слепо, экспериментируй.

В RUP есть такая фаза, дисциплина, артефакт - как разработка процесса, Development Case. Т.е. анализируем то что будем делать, орагнизуем под него процесс и подбираем необходимые артефакты используя чеклисты и рекомендации RUP

Примерно так себе этопредставляю

Мое понимание.

Начнем с самого начала.
Есть субъект и есть объект.
Субъект что-то делает над объектом.
Субъект - тот кто делает.
Объект - тот над кем производят действия.
Например, программист исправляет баг.
Программист - субъект.
Баг - объект.
Обе эти сущности имеют свой Жизненный Цикл.
ЖЦ бага хорошо описывается диаграммой автомата, потому что это пассивная сущность (над ним совершают действия).
Какие состояния могут быть у бага?
Ну например, opened, assigned, closed, rejected, reopened, postponed, etc
Переход между этими состояниями осуществляется по событиям.
Кто генерирует события? Активная сущность - субъект (програмист)
Деятельность программиста при этом лучше всего описывается через диаграмму деятельности.
Какие деятельности могут быть?
Reproduce bag, Analysis, Coding, Testing, etc
Совокупность ЖЦ-ов субъекта и объекта определяет Процесс Исправления Бага!

Рассмотрим другой пример.
Разработчик разрабатывает ПО.
Все тоже самое.
Совокупность ЖЦ-ов субъекта и объекта определяет Процесс Разработки ПО!
Уделим внимание диаграмме деятельности разработчика.
Так сложилось исторически, что там есть такие деятельности как Анализ, Проектирование, Реализация и т.д. (а могут быть и другие, зависит от авторов)
Если мы после каждой фазы делаем последующую и назад не возвращаемся - Водопад/Каскад.
Думаю понятно, что вводя всякие обратные связи, циклы и прочее мы получим все множество процессов разработки, которые имеем.
Осталось сказать, что ПО разрабатывает не один человек, а команда. В команде каждый играет какую-то Роль.
Каждая роль (субъект) описывается своим ЖЦ. Ну и у каждой роли есть один или несколько объектов (на которые она влияет). Все это вместе и есть Процесс.
И последний вопрос. Что же мы получает после выполнения каждой деятельности? АРТЕФАКТЫ.
Это и документы, и модели, и исходный код, и исполняемые модули, и файлы конфигурации и т.д.
Они являются результатом деятельности субъектов над объектами.
Ну еще добавлю, что после каждой деятельности можно вехи порасставлять.

По поводу RUP.
Все построено по описанной схеме. RUP претендует на универсальность, поэтому он такой тяжелый. Там множество субъектов, объектов и артефактов. Еще он примечателен тем, что его описание сделано на UML.

И чем это ОТЛИЧАЕТСЯ ОТ RUP ??

Вопрос мне кажется надо поставить по другому.
А почему собственно RUP?
Правомощность такого вопроса попытался обосновать предыдущим постом.