LINUX.ORG.RU
Форум — Development  

Проектрирование архитектуры программы, что, как, и куда


0

0

Добрый день. Столкнулся недавно с однлй проблемой, и вот незнаю с какой стороны вообще к ней подходить. Есть некая задача, с уже достатачно четким ТЗ, и требуемыми характеристиками. В решении задачи будут участовать несколько человек. Результатом решения будет некий програмный распределенный клиент серверный компплекс. Но вот сейчас нужно как то описать и формализировать всю архитектуру проекта, плюс расписать ко чем занимается, и какие где сроки (иначе потом будет полная ж...уже один раз с таким столкнулся, второй раз натыкатся на теде грабли не хочется). Собсно вопрос, какой инструментарий мне для этого использовать? Ну и возможно КАК использовать? :) Тоесть необходимо что бы в течении недели двух, была как то описана вся архитектура комлпеккса, протоколы взаимодействия, приницпи работы, обьекты данных и тд, причем описан достатачно честко, идеал хиадер файлы с готовыми шаблонами классов, и плюс какието диаграммы взаимодействия и тд (UML?). Сейчас все что приходит в голову это использование UML. Но может кто то, кто уже решал похожие задачи, дастк какието общие рекомендации, советы, что почитать по этому вопрос и тд ( с UML знаком очень поверхностно, на уровне прогуляных лекций по UML в универе :))

anonymous

> идеал хиадер файлы с готовыми шаблонами классов

Это уже не совсем архитектура или даже совсем не.

> плюс какието диаграммы взаимодействия

Диаграммы --- это _иллюстрации_. Диаграммы без текста --- это все равно что из книги вырезать весь текст и оставить одни иллюстрации :) Основа --- это, всё-таки, словесное описание.

> Собсно вопрос, какой инструментарий мне для этого использовать?

Карандаш, бумага, текстовый редактор и рисовалку диаграмм.

> КАК использовать? :)

А вот это тут не описать :)

watashiwa_daredeska ★★★★
()

имхо не мало зависит от программерского контенгента. если им подавай хедеры, а они тупо заполнят класы содержимым без представления общей картины, то готовься рисовать УМЛ диаграммы сотнями без гарантии, что этот весь агрегат заработает.

Pi ★★★★★
()
Ответ на: комментарий от watashiwa_daredeska

Ну тоесть в любом случае идеальный варинт это использование диаграм + текстовые описания к ним. Просто проблема в том ,что никто из нас толком UML то и не знает, вот либо тратить время еще и на изучение UML, либо обходится как то поручными средствами. Вообще желание заранее разработать и продумать всю архитектуру возникло что бы предотвраттить появвление ситуаций вида: пишу код, написал уже достатачно большой кусок какого то метода, и тут вдруг, сидиш, думаш, так, а что если тут так, а тут так, ЕПТ!! так оно ж вобще ж рабоать то не будет! И уже почти полность написаный код стирается и чуть ли не заново пишется, а тут еще оказывается что из за этого нужно переделыват и логику работы парочки соседних методов..а сроки вот вот уже....в результате начинается нагромождение костылей, и выходит непонятно что

anonymous
()
Ответ на: комментарий от anonymous

> написал уже достатачно большой кусок какого то метода, и тут вдруг, сидиш, думаш, так, а что если тут так, а тут так, ЕПТ!! так оно ж вобще ж рабоать то не будет!

Продумывать архитектуру конечно надо. Но от такого 100% гарантии, к сожалению, не бывает :)

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

kpanic ★★
()
Ответ на: комментарий от klon

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

более того, XP хорош, если клиент всегда под рукой, что бывает крайне редко.

Pi ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Development