Форум Сообщества Аналитиков
Общий раздел => Методологии => Тема начата: Денис Иванов от 04 Сентября 2008, 11:36:31
-
Мне интересно, но что такое "модель дизайна"?
Модель предметной области? Аналитическая модель приложения? Проектная модель?
-
Мне интересно, но что такое "модель дизайна"?
Модель предметной области? Аналитическая модель приложения? Проектная модель?
Модели анализа, дизайна и имплементации являются композитными артефактами классического 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-ую?
Где можно почитать об этой классификации?
-
Мне интересно, но что такое "модель дизайна"?
Модель предметной области? Аналитическая модель приложения? Проектная модель?
Где можно ознакомиться с тем, что понимается под "Аналитическая модель приложения и Проектная модель"?
-
Где можно ознакомиться с тем, что понимается под "Аналитическая модель приложения и Проектная модель"?
Скорее всего это можно сделать в книге Рамбо и Блаха (http://www.piter.com/book.phtml?978546900814).
Авторы не привязываются к какому-то процессу разработки и дают (на их взгляд) более абстрактное деление моделей.
Они выделяют модель предметной области, т.е. модель абстракции ПрОб близкой по смыслу бизнес-модели RUP, если я не ошибаюсь.
Далее они предлагают аналитическую модель приложения, которая дополняется классами, не входящими собственно в предметную область, но которые определяют интерфейсы будущей системы с окружением.
Т.е. нет классов реализации, которые в дальнейшем и составляют проектную модель.
-
а если совсем просто, то аналитическая модель - результат фазы анализа, а проектная - фазы проектирования.
-
Скорее всего это можно сделать в книге Рамбо и Блаха (http://www.piter.com/book.phtml?978546900814).
Авторы не привязываются к какому-то процессу разработки и дают (на их взгляд) более абстрактное деление моделей.
Они выделяют модель предметной области, т.е. модель абстракции ПрОб близкой по смыслу бизнес-модели 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?
Правомощность такого вопроса попытался обосновать предыдущим постом.
-
1. Ссылочки, где это описано у "знающих людей",
Сложно сказать. Книжки читаешь, работаешь, ну и складывается впечатление....
2. Что лично Вы подразумеваете под приведёнными классами моделей?
Аналитическая модель после анализа.
Проектная модель после проектирования.
При этом конечно задачи данных фаз надо иметь в виду.
А так Эдуард дал правильную ссылку. Заметьте кстати, один из авторов этой книги - автор RUP, но о нем (о RUP) даже не упоминает.
3. Какое лично у Вас отношение к RUP?
Просто не интересно? Или
интересно, но во многом не согласны с предлагаемыми концепциями
и поэтому - не приемлемо?
Отношение такое - прекрасно разработанная теория, которую очень сложно и дорого применить на практике.
Тщательно изучать не пробовал, так как не вижу области применения. По моему мнению у нас (в России) это невостребованное знание.
-
Вопрос мне кажется надо поставить по другому.
А почему собственно RUP?
Правомощность такого вопроса попытался обосновать предыдущим постом.
Реально ничего не понял из пояснения "прошлым постом" ... таки где "Аналитическая модель приложения и Проектная модель"?
Позволю себе не согласиться с изменением постановки вопроса и настаиваю на первоначальной формулировке .... чем ЭТО отличается от RUP? Задаю прямой и четкий вопрос, и прошу на него столь же четкий и прямой ответ.
-
Реально ничего не понял из пояснения "прошлым постом" ... таки где "Аналитическая модель приложения и Проектная модель"?
"Прошлым постом" я выразил свое мнение о том, каким образом создаются Процессы и считаю, что ... скажем так ... алгоритм их создания примерно одинаков и зависит только от креативности авторов, их опыта и пр.
"Аналитическая модель приложения и Проектная модель" - это артефакты, которые являются выходами различных видов деятельности. В частности "Анализа" и "Проектирования".
У разных авторов одни и те же модели могут носить различные названия. У RUP это, например, "Модели анализа, дизайна и имплементации".
Позволю себе не согласиться с изменением постановки вопроса и настаиваю на первоначальной формулировке .... чем ЭТО отличается от RUP? Задаю прямой и четкий вопрос, и прошу на него столь же четкий и прямой ответ.
Если под ЭТИМ подразумевается Процесс, описанный Блахом и Рамбо, то прямой и четкий ответ я дать не могу, так как не силен в RUP.
Что касается переформулировки вопроса, то я просто хотел обратить внимание, что по моему мнению выбор Процесса не должен повлиять на результат (с точность до именований фаз, артефактов и пр.).
В результате ведь получится модель?
Рисовать то ее (всю или часть) будем на UML (или на SysML или в другой нотации)?
А нотации к Процессам никак не привязаны (раньше это было не так).
-
Итого имеем ...
1) "... то прямой и четкий ответ я дать не могу, так как не силен в RUP." ...
2) отсутствие четкого понимания используемых терминов "Аналитическая модель приложения и Проектная модель", вне контекста RUP ...
Все, что хотелось сказать -- в основном, подходы Лармана, тем более Румбаха (как одного из основоположников UML) концентрированно выражены именно в RUP. Чего я ожидал -- демонстрации либо более конкретного выражения описания "объектно-ориентированного анализа и дизайна ПО", чем это представлено в том же RUP со ссылками на конкретные фреймворки, который доступны для изучения. Либо презентацию собственного опыта, с явной демонстрацией отличия от RUP, причем как для конкретного проекта, так и в обобщении. Но пока складывается ощущение, что все что предлагается -- вариации на тему RUP (или как вариант -- RUP вобрал в себя разные подходы :-) ... как будет угодно ...)
-
Но пока складывается ощущение, что все что предлагается -- вариации на тему RUP (или как вариант -- RUP вобрал в себя разные подходы :-) ... как будет угодно ...)
Я c RUP близко не знаком, только несколько книг "про RUP" прочитал, но, как мне представляется, это попытка обобщения накопленного опыта во всех (или большинстве) областях программной инженерии. Так сказать, "все грабли в одном флаконе". :) Наверняка там, как в Библии, есть ответы на все вопросы. Но чтобы найти ответы, нужно знать вопросы.
На OpenUp я тоже смотрел. Меня особенно восхитил одинокий артефакт разработки архитектуры - "architecture notebook".
-
Я c RUP близко не знаком, только несколько книг "про RUP" прочитал, но, как мне представляется, это попытка обобщения накопленного опыта во всех (или большинстве) областях программной инженерии. Так сказать, "все грабли в одном флаконе". :) Наверняка там, как в Библии, есть ответы на все вопросы. Но чтобы найти ответы, нужно знать вопросы.
На OpenUp я тоже смотрел. Меня особенно восхитил одинокий артефакт разработки архитектуры - "architecture notebook".
Так проблема в том, что нет вопросов? Тогда нужно для начала сформулировать желаемое идеальное состояние ... а потом задавать вопросы как к нему приблизиться. :-)
-
Так проблема в том, что нет вопросов? Тогда нужно для начала сформулировать желаемое идеальное состояние ... а потом задавать вопросы как к нему приблизиться. :-)
Проблема как раз в том, что невозможно сформулировать желаемое состояние "для начала". То есть можно попытаться его сформулировать, но очень быстро выяснится, что оно не идеальное, да и не желаемое.
Но с чего-то начинать, конечно, надо. Дорогу осилит идущий. Но стоит ли начинать с RUP?
-
Итого имеем ...
1) "... то прямой и четкий ответ я дать не могу, так как не силен в RUP." ...
2) отсутствие четкого понимания используемых терминов "Аналитическая модель приложения и Проектная модель",
вне контекста RUP ...
отсутствие чёткого понимания используемых терминов ещё не признак отсутствия за ними полезных понятий и полезного опыта их использования.
я заинтерсовался классификацией Дениса, в её состоянии As Is.
оказалось, что ЭТО - на уровне личных наработок,
изложить которые в общем виде у автора не получается,
а подходящих контекста и фреймворков от Гуру - не нашлось.
Денис, мне действительно интересно знать, что Вы для себя подразумеваете под терминами "Аналитическая модель приложения и Проектная модель"?
Если можно - примеры или просто описание структуры этих моделей.
а если совсем просто, то аналитическая модель - результат фазы анализа, а проектная - фазы проектирования.
Denis, меня, как инициатора темы,
интересует, что конкретно у Вас приходит на вход и получается на выходе каждой из фаз: анализ и проектирование.
Очень желательно, - с примерами, чтобы уменьшить разночтения терминов.
-
отсутствие чёткого понимания используемых терминов ещё не признак отсутствия за ними полезных понятий и полезного опыта их использования.
я заинтерсовался классификацией Дениса, в её состоянии As Is.
Кто ясно мыслит, тот ясно излагает ... :-)
оказалось, что ЭТО - на уровне личных наработок,
изложить которые в общем виде у автора не получается,
а подходящих контекста и фреймворков от Гуру - не нашлось.
ОК, где можно прочитать про эти личные наработки ... ?
-
Проблема как раз в том, что невозможно сформулировать желаемое состояние "для начала".
То есть можно попытаться его сформулировать, но очень быстро выяснится, что оно не идеальное, да и не желаемое.
пока могу что-то определённое сказать только про исходное состояние:
"стою на асфальте, в лыжы обут" - и задаю себе 2 вопроса:
- то ли лыжы не те,
- то ли асфальт сильно на лыжню похож? :-)
Вроде и UML не плохо знаю (и людям преподаю и сам использую),
И по части "объектно-ориентированного анализа и дизайна ПО" не новичок: и проектировал и сам программил.
И с паттернами хоть и не на "Ты" а только слегка на "Вы", но знаком.
А лыжы(RUP) - ну никак не идут :-(
не то что в работе, но и в простом понимании.
-
Бывает :-)
-
оказалось, что ЭТО - на уровне личных наработок,
изложить которые в общем виде у автора не получается,
ЭТО, RUP и пр. - это СЛЕДСТВИЯ.
Разве вам не интересно подумать про ПРИЧИНЫ. Именно мое видение ПРИЧИН я описал в "предыдущем посте".
А про ЭТО есть книга. Рамбо и Блаха.
2) отсутствие четкого понимания используемых терминов "Аналитическая модель приложения и Проектная модель", вне контекста RUP ...
Ну что же. Повторение - мать ученья.
Модель, которая имеет место быть после завершения фазы анализа принято называть Аналитической моделью.
Модель, которая имеет место быть после завершения фазы проектирования принято называть Проектной моделью.
За деталями к известной книге.
-
Мне думается, проблема понимания РУП возможно связана с проблемой перевода. Я как-то пытался кое-что переводить из РУП - но просто замучился. Хотя как я помню исторически РУП как раз был результатом существенного упрощения, при это он как раз позиционировался как достаточно легкий процесс.
Безусловно в нем заложен менталитет скажем так западной цивилизации. Потому то, что вполне очевидно, у нас идет трудно. Могет в этом дело?
-
Добавлю свои 5 копеек в обсуждение.
Нельзя рассматривать аналитическую модель, проектную модель как результаты фаз. Результатом фаз RUP является определенное целевое их состояние (скажем, "готова на 25%", "готова на 100%"). Кстати, анализ и проектирование -- это процессы в RUPе, не стадии, т. е. другое измерение.
Если к чему привязывать эти модели, то к ролям. Аналитическую модель делает аналитик. Проектную модель -- проектировщик.
Разница между моделями четче всего проявляется при сравнении классов анализа с проектными классами. Если первые -- результат "начального подхода" к проблеме -- ее разложение на 3 полки ("граница", "управление", "сущность"), то вторые отражают архитектуру.
Позволю пару цитат
===
Модель анализа включает основные классы, необходимые для реализации выделенных вариантов использования, а также возможные связи между классами. Выделяемые классы разбиваются на три разновидности — граничные, управляющие и классы-сущности. Эти классы представляют собой набор начальных абстракций, в терминах которых представляется работа системы. Они являются понятиями, с помощью которых достаточно удобно объяснять себе и другим происходящее внутри системы, не слишком вдаваясь в детали.
===
Модель проектирования является детализацией и специализацией модели анализа. Она также состоит из классов, но более четко определенных, с более точным и детальным распределением обязанностей чем у классов анализа. Проектные классы должны быть специализированы для конкретной используемой платформы. Каждая такая платформа может включать несколько операционных систем; используемые языки программирования; интерфейсы и классы конкретных компонентных сред, таких как J2EE, .NET, COM или CORBA; интерфейсы выбранных для использования СУБД, например, Oracle или MS SQL Server; используемые библиотеки разработки пользовательского интерфейса, такие как swing или swt в Java, MFC или gtk; интерфейсы взаимодействующих внешних систем и пр.
===
Изложение всего с позиций RUPа, конечно же.
-
Добавлю свои 5 копеек в обсуждение.
Нельзя рассматривать аналитическую модель, проектную модель как результаты фаз. Результатом фаз RUP является определенное целевое их состояние (скажем, "готова на 25%", "готова на 100%"). Кстати, анализ и проектирование -- это процессы в RUPе, не стадии, т. е. другое измерение.
Изложение всего с позиций RUPа, конечно же.
Полностью согласна, спасибо! У меня в голове все вертелось, а у Вас так хорошо и понятно получилось словами сказать!