Недавно начал осваивать проектирование и UML.
Для более наглядного понимания начал маленький проект.
Определил роли, описал use case и отношения между ними.
Составил доменную модель. Начал для каждого use case
описывать диаграммы последовательности и вот возник вопрос.
Для веб уровня хочу использовать Spring MVC, а там надо будет
описывать контроллеры, которые будут наследоваться от AbstractController
или подобных.
На каком этапе надо подключать спринговские классы?
Нужно ли это делать во время проектирование системы или после генерации кода?
AS>Составил доменную модель. Начал для каждого use case AS>описывать диаграммы последовательности и вот возник вопрос. AS>Для веб уровня хочу использовать Spring MVC, а там надо будет AS>описывать контроллеры, которые будут наследоваться от AbstractController AS>или подобных.
А зачем показывать конкретную реализацию контроллера в контексте описания варианта использования?
Это один из аспектов реализации, в отдельном месте — если надо — и нарисуйте его.
На уровне варианта использования это не интересно и не нужно. Обозначьте абстрактный фасад приложения и
развёртывайте от него.
Представьте, вы поменяли SpringMVC например на Wicket. Так вот, картинки, связанные с описанием вариантов использования,
измениться не должны.
А насчёт хибера... Да вообще не надо его без особой нужды показывать-то. Нарисуйте просто интерфейс DAO без каких-либо
деталей его реализации. Как будто-бы ещё и не знаете, будет хибер, jdo или что-нибудь ещё другое.
Здравствуйте, cvoronin, Вы писали:
C>А зачем показывать конкретную реализацию контроллера в контексте описания варианта использования? C>Это один из аспектов реализации, в отдельном месте — если надо — и нарисуйте его. C>На уровне варианта использования это не интересно и не нужно. Обозначьте абстрактный фасад приложения и C>развёртывайте от него.
C>Представьте, вы поменяли SpringMVC например на Wicket. Так вот, картинки, связанные с описанием вариантов использования, C>измениться не должны.
C>А насчёт хибера... Да вообще не надо его без особой нужды показывать-то. Нарисуйте просто интерфейс DAO без каких-либо C>деталей его реализации. Как будто-бы ещё и не знаете, будет хибер, jdo или что-нибудь ещё другое.
Получается модель вариантов использования должна иметь более высокую степень абстракции, чем я думаю.
И вместо классов для описания доменной модели использовать интерфейсы и абстрактные классы?
Фасад я уже обозначил и наметил шаги по его реализации.
Jdo к сожаления я не знаю, поэтому придется рисовать интерфейсы dao уровня ориентируясь только на мои знания о хибернэйте.
AS>Получается модель вариантов использования должна иметь более высокую степень абстракции, чем я думаю. AS>И вместо классов для описания доменной модели использовать интерфейсы и абстрактные классы?
Варианты использования тут вообще не при делах. Даже не в этом форуме.
... << RSDN@Home 1.2.0 alpha 4 rev. 1138 on Windows Vista 6.0.6001.65536 >>
"В любое мгновение принятия решения, лучшее, что вы можете сделать, это принять правильное решение; следующим лучшим вариантом будет принять неправильное решение, худший вариант – не принимать решения совсем" (c) Теодор Рузвельт.
Здравствуйте, VGn, Вы писали:
AS>>Получается модель вариантов использования должна иметь более высокую степень абстракции, чем я думаю. AS>>И вместо классов для описания доменной модели использовать интерфейсы и абстрактные классы?
VGn>Варианты использования тут вообще не при делах. Даже не в этом форуме.
Ээээ.. почему не в этом форуме. Про архитектуру ведь речь идет!
VGn>>Варианты использования тут вообще не при делах. Даже не в этом форуме. AS>Ээээ.. почему не в этом форуме. Про архитектуру ведь речь идет!
Варианты использования — термин управления требованиями. Use cases с архитектурой не связаны.
И если можно ещё поспорить о связи акторов с доменной моделью, то механизм доступа к БД, как и наличие собственно БД с вариантами использования не связаны абсолютно.
Здравствуйте, VGn, Вы писали:
VGn>Варианты использования — термин управления требованиями. Use cases с архитектурой не связаны. VGn>И если можно ещё поспорить о связи акторов с доменной моделью, то механизм доступа к БД, как и наличие собственно БД с вариантами использования не связаны абсолютно.
Механизм доступа к БД с вариантами(прецедентами) использования не связан ибо на момент
формирования use case разработчик может и не знать вовсе какая база данных будет использоваться,
а может она будет и не одна.
Вы уж извините за мою безграничную безграмотность, но что же тогда представляет из себя архитектура системы?
Нашел на сайте ibm.com :
"Архитектура — это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением,
а также принципы, определяющие проектирование и развитие системы. [IEEE 1471]"
Разве у нас на основе use case'ов и доменной модели, а в последствии модели классов не получаются компоненты(.dll)?
AS>Вы уж извините за мою безграничную безграмотность, но что же тогда представляет из себя архитектура системы? AS>Нашел на сайте ibm.com : AS>"Архитектура — это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением, AS>а также принципы, определяющие проектирование и развитие системы. [IEEE 1471]"
Безусловно.
AS>Разве у нас на основе use case'ов и доменной модели, а в последствии модели классов не получаются компоненты(.dll)?
— На основе use case'ов формируются требования.
— На основе требований формируется доменная модель, которая впрочем тоже не имеет отношения к базе.
— На основе доменной модели и требований, формируются классы (или другие сущности проектной модели).
И собственно здесь мы уже думаем о базе.
Варианты использования, сценарии и требования относятся к управлению требованиями.
Всё остальное — либо к архитектуре, либо к дизайну.
Компоненты — абстракция развёртывания, тоже относящаяся к архитектуре (не знаю зачим вы её тут приплели)
То, что одно основано на другом, не значит, что надо смешивать разные уровни абстракции.
Цель программирования — борьба со сложностью (с) Не помню кто
Абстрагирование является основным способом борьбы со сложностью.
Здравствуйте, VGn, Вы писали:
VGn> — На основе use case'ов формируются требования. VGn> — На основе требований формируется доменная модель, которая впрочем тоже не имеет отношения к базе. VGn> — На основе доменной модели и требований, формируются классы (или другие сущности проектной модели). VGn> И собственно здесь мы уже думаем о базе. VGn> Варианты использования, сценарии и требования относятся к управлению требованиями. VGn> Всё остальное — либо к архитектуре, либо к дизайну. VGn> Компоненты — абстракция развёртывания, тоже относящаяся к архитектуре (не знаю зачим вы её тут приплели) VGn> То, что одно основано на другом, не значит, что надо смешивать разные уровни абстракции. VGn> Цель программирования — борьба со сложностью (с) Не помню кто VGn> Абстрагирование является основным способом борьбы со сложностью.
А приплел я их потому, что плохо представляю этапы проектирования.
Теперь, на основе вашего небольшого топика, я более менее понимаю что к чему.
Проектированием начал заниматься всего месяц назад, до этого писал "как обычно"(т.е. сразу с классов).
Сейчас общая картина проекта стала проясняться и я понял на каком этапе мне придется подумать о том, как прикрутить Спринг и Хибер.
Благодарю за внимание.
Правильно вы написали про архитектуру. Если сказать более простым языком, то архитектура это "а вот здесь у нас будут фасады, а тут DAO, а тут вот сервисы дёргаются, а вот тут вот интеграция и т.д."
А UC это "пользователь нажал, система сохранила, система загрузила, система отправила, пользователь получил" — здесь нет (как и в бизнес модели, построенной по UC и похожей на диаграмму классов) поробностей реализации, так как это более высокий уровень абстракции, который навряд ли будет меняться, даже если вы с java на .net перейдёте.
Здравствуйте, AliveSubstance, Вы писали:
AS>Здравствуйте, VGn, Вы писали:
VGn>>Варианты использования — термин управления требованиями. Use cases с архитектурой не связаны. VGn>>И если можно ещё поспорить о связи акторов с доменной моделью, то механизм доступа к БД, как и наличие собственно БД с вариантами использования не связаны абсолютно.
AS>Механизм доступа к БД с вариантами(прецедентами) использования не связан ибо на момент AS>формирования use case разработчик может и не знать вовсе какая база данных будет использоваться, AS>а может она будет и не одна.
AS>Вы уж извините за мою безграничную безграмотность, но что же тогда представляет из себя архитектура системы? AS>Нашел на сайте ibm.com : AS>"Архитектура — это базовая организация системы, воплощенная в ее компонентах, их отношениях между собой и с окружением, AS>а также принципы, определяющие проектирование и развитие системы. [IEEE 1471]"
AS>Разве у нас на основе use case'ов и доменной модели, а в последствии модели классов не получаются компоненты(.dll)?
Здравствуйте, Polosatiy, Вы писали:
P>Правильно вы написали про архитектуру. Если сказать более простым языком, то архитектура это "а вот здесь у нас будут фасады, а тут DAO, а тут вот сервисы дёргаются, а вот тут вот интеграция и т.д."
P>А UC это "пользователь нажал, система сохранила, система загрузила, система отправила, пользователь получил" — здесь нет (как и в бизнес модели, построенной по UC и похожей на диаграмму классов) поробностей реализации, так как это более высокий уровень абстракции, который навряд ли будет меняться, даже если вы с java на .net перейдёте.
Ну с явы на .нЭт я переходить не собираюсь, ибо сделал обратное некоторое время назад, но мысль ваша мне ясна.
Спасибо за разъяснение "на пальцах".
