UP или RUP с чего начать свой путь в ООП ???

Здравствуйте, Pelya, Вы писали:

P>UP или RUP с чего начать свой путь в ООП ???

Методология разработки должна поддерживать какую-то архитектуру. Потому сначала надо либо выбрать её либо разработать самому. Последнее имеет отношение к ООП. Здесь могут помочь книжки GoF, POSA и Martin Fowler.

Здравствуйте, Pelya, Вы писали:

P>UP или RUP с чего начать свой путь в ООП ???

А как это связано с ООП?

Здравствуйте, Pelya, Вы писали:

P>UP или RUP с чего начать свой путь в ООП ???

Не пудри себе мозги методологиями раньше времени. Любая методология, по сути, служит упорядочиванию взаимодействий людей и отчасти помогает раобраться с многочисленными "Как?", "Зачем?", "Почему?", "Кто?", "Когда?", "Кому, за что и сколько?" и т.п. Попробуй начать с простой, но фундаментальной вещи: объектной декомпозиции задачи (этому методологии не учат). Выдели объекты, состояния, действия, распредели обязанности объектов... Потом попробуй раскидать реализацию по нескольким людям — посмотри, что из этого получится. Тогда остальные вопросы улягутся в голове куда как проще. А RUP там или не RUP в итоге получится... да какая разница!

P>UP или RUP с чего начать свой путь в ООП ???

Уважаемый Pelya, начните с книжки Гради Буча "Объектно-ориентированное проектирование. С примерами приложений на С++". Моё субъективное мнение: лучшая книга по ООП от одного из его создателей.

с уважением
_master

Здравствуйте, Mishka, Вы писали:

M>Здесь могут помочь книжки GoF, POSA и Martin Fowler.
А POSA это что?

Спасибо всем за коментарии.

Здравствуйте, Кирилл Осенков, Вы писали:

КО>Здравствуйте, Mishka, Вы писали:

M>>Здесь могут помочь книжки GoF, POSA и Martin Fowler.
КО>А POSA это что?

Patterns Of Software Architecture. Набери название книги на amazon. Там их две.

Здравствуйте, Mishka, Вы писали:

M>Здравствуйте, Кирилл Осенков, Вы писали:

КО>>Здравствуйте, Mishka, Вы писали:

M>>>Здесь могут помочь книжки GoF, POSA и Martin Fowler.
КО>>А POSA это что?

M>Patterns Of Software Architecture. Набери название книги на amazon. Там их две.

А как их получить? Заказать на Amazon? И типа доставляют?
Расскажи...

Здравствуйте, Геннадий Васильев, Вы писали:

ГВ>Не пудри себе мозги методологиями раньше времени. Любая методология, по сути, служит упорядочиванию взаимодействий людей и отчасти помогает раобраться с многочисленными "Как?", "Зачем?", "Почему?", "Кто?", "Когда?", "Кому, за что и сколько?" и т.п. Попробуй начать с простой, но фундаментальной вещи: объектной декомпозиции задачи (этому методологии не учат). Выдели

Хм ... вообще стоит начать не с этого ... Применительно к бизнес-системам:
1. Формулировка и понимание того, что вообще нужно делать, какую бизнес-проблему должны решить.
2. Кто заинтересован в этом проекте, какие его запросы, что будет являться критерием успеха.
3. Формулировка функциональных и прочих требований к разрабатываемому ПО (на достаточно высоком уровне);

Одним словом -- управление требованиями -- один из ключевых аспектов, и он практически инвариантен по отношению к тому, используется ли ОО средства разработки, или вообще все на Oracle Developer делается. Другой вопрос, что большинство современных методологий использует OOAD в качестве базиса.

ГВ>объекты, состояния, действия, распредели обязанности объектов... Потом попробуй раскидать реализацию по

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

ГВ>нескольким людям — посмотри, что из этого получится. Тогда остальные вопросы улягутся в голове куда как проще. А RUP там или не RUP в итоге получится... да какая разница!

Разница в том, как вы, как группа разработчиков себя позиционируете вообще, какие у вас проекты, какие требования заказчиков. Отсюда и методология, которая вам подходит, скорее всего -- адаптированная под вас.
Вообще, я достаточно часто встречал конторы, которые декларируют что используют RUP/XP/FDD ..., -- в подавляющем большинстве -- используются только некторые элементы, и часто люди вообще не представляют себе, в чем "core" той или иной методологии и почему они выбрали ту или иную ...

Здравствуйте, byur, Вы писали:

B>Хм ... вообще стоит начать не с этого ... Применительно к бизнес-системам:
B>1. Формулировка и понимание того, что вообще нужно делать, какую бизнес-проблему должны решить.
B>2. Кто заинтересован в этом проекте, какие его запросы, что будет являться критерием успеха.
B>3. Формулировка функциональных и прочих требований к разрабатываемому ПО (на достаточно высоком уровне);

Это совершенно верно. Но находится немного на другом уровне... ИМХО, на самом деле должен быть синтез двух подходов.

B>Одним словом -- управление требованиями -- один из ключевых аспектов, и он практически инвариантен по отношению к тому, используется ли ОО средства разработки, или вообще все на Oracle Developer делается. Другой вопрос, что большинство современных методологий использует OOAD в качестве базиса.

Ну вот в том-то и дело: управление требованиями и менеджмент вообще не дают ответов на вопросы о дизайне. Ну разве что тем, у кого уже есть какой-то базис. А базис надо нарабатывать...

B>Проектирование классов -- без контекста функциональных требований ... хм ... это врядли правильный путь, есть риск, что будет смоделировано то, что заказчику особенно и не нужно ...

Он всегда есть.

B>хотя если задача стоит "срубить бабок и слинять" ... то наверное можно .

Тогда вообще рассуждать об ООП, ИМХО, смысла не имеет.