Как Вы Проектируете?

[sasha465]

Всем доброго дня! Хочу вот у вас спросить, как вы проектируете ваши будущие системы? Вопрос проектирования ИС для меня возник недавно, когда появилась задача написать довольно крупный веб-сервис для внутренних нужд компании. Решил сделать все "по уму" и начать с проектирования, вспомнил что когда-то в универе проходили UML, стал читать книжки по проектированию, напирмер такие: Стив Макконнелл - Совершенный код, Хант Эндрю. Программист-прагматик, Анализ требований и проектирования систем, Технология разработки программного обеспечения, Фаулер М. - UML, Alistair Cockburn - Writing Effective Use Cases, Принципы работы с требованиями к программному обеспечению - Дин Леффингуэлл. Но из всех этих книг стало лишь понятно как вырабатывать требования к системе и строить диаграммы UML. Разве этого мало ? - спросите вы, но вынужден ответить что мне мало, потому что такое ощущение что после установления требований я должен ринуться строить идаграммы прецендентов(которые кстати сказать, совершенно мне не нужны) или рисовтаь идаграммы классов, которые я еще плохо себе представляю или, что естественней - сразу кодить. Неужели так вы и делаете (в смысле сразу кодите)? Почему нету никакого метода предварительного проектирования, как у инженеров или архитекторов - они ведь не начинают сразу ложить кирпичи, сначала у них есть план(проект). Так вот я не смог найти метод построения такого плана. Ну например: как описать взаимодействие серверной программы со скриптом на стороне клиента, как спроектировать модель взаимодействия системы с пользователям посредством событий, или как построить модель взаимодействия подсистем между собой ? В общем, поделитесь опытом, как вы работаете над большими и средними проектами, потому что у меня уже появилась мысль самому создать нотацию описания крупных систем, возможно вы отговорите меня, чему я буду несказанно рад))

 

[rrrFer]

Разбиваешь задачу на части. Если все еще сложная - делишь еще на части.
Диаграммы рисуешь чтобы не забыть.
Модель взаимодействия подсистем можно изобразить в виде UML диаграмм как раз. Но можно и без них.

Когда учился на военной кафедре, были там эпически сложные системы, состоящие из нескольких грузовиков с оборудованием.
Изображается эта система вот так как я описал. Диаграмма всей системы (все машины), диграмма каждой машины, диаграмма каждой части машины, подсистем и т.п. Нарисовано там все это было в здоровенных альбомах и талмудов безо всяких ГОСТов (был там видимо какой-то СТО, который никто не знает).

Настолько сложные штуковины (да еще с такими требованиями к надежности) в программировании вряд-ли вообще встречаются. Но принципы те же.

Разделяй сложную задачу на подзадачи, систему - на подсистемы.

И я не знаю почему на эти темы там много дискутируют.
Я прочитал книгу Буча, он много пишет - но все сводится к тем 5 словам, что я выделил жирным. И это всем известно с давних времен. Причем примеры у буча тоже ни о чем не расскажут (типа система полива грядок какая-то, там у него описываются садовники всякие и прочее), выводы которые он из этого делает более чем очевидны. Даже в детском саде такие книжки сочтут примитивными.

По поводу UML у буча тоже описано, но кто сказал, что без UML нельзя обойтись? - посмотрите классическую книгу страуструпа по С++, там есть диаграммы отражающие связи между классами. но они не соответствуют UML ни разу. При этом суть отражают не хуже.

 

[rrrFer]

как описать взаимодействие серверной программы со скриптом на стороне клиента, как спроектировать модель взаимодействия системы с пользователям посредством событий, или как построить модель взаимодействия подсистем между собой

диаграммы классов (или объектов) + диаграмма последовательности.
Мне всегда хватало этих 3 видов диаграмм.
Хотя вместо диаграмм последовательности я чаще словами описываю (а чем не вариант?) - очень неудобно их рисовать потому что и инструментов удобных я не видел под линукс. кривое Umbrello меня достало.

 

[sasha465]

диаграммы классов (или объектов) + диаграмма последовательности.
Мне всегда хватало этих 3 видов диаграмм.
Хотя вместо диаграмм последовательности я чаще словами описываю (а чем не вариант?) - очень неудобно их рисовать потому что и инструментов удобных я не видел под линукс. кривое Umbrello меня достало.

Довольно удобным под Linux мне показалась Dia, по-моему гораздо лучше Umbrella будет.

 

[sasha465]

Разбиваешь задачу на части. Если все еще сложная - делишь еще на части.
Диаграммы рисуешь чтобы не забыть.
Модель взаимодействия подсистем можно изобразить в виде UML диаграмм как раз. Но можно и без них.

Когда учился на военной кафедре, были там эпически сложные системы, состоящие из нескольких грузовиков с оборудованием.
Изображается эта система вот так как я описал. Диаграмма всей системы (все машины), диграмма каждой машины, диаграмма каждой части машины, подсистем и т.п. Нарисовано там все это было в здоровенных альбомах и талмудов безо всяких ГОСТов (был там видимо какой-то СТО, который никто не знает).

Настолько сложные штуковины (да еще с такими требованиями к надежности) в программировании вряд-ли вообще встречаются. Но принципы те же.

Разделяй сложную задачу на подзадачи, систему - на подсистемы.

И я не знаю почему на эти темы там много дискутируют.
Я прочитал книгу Буча, он много пишет - но все сводится к тем 5 словам, что я выделил жирным. И это всем известно с давних времен. Причем примеры у буча тоже ни о чем не расскажут (типа система полива грядок какая-то, там у него описываются садовники всякие и прочее), выводы которые он из этого делает более чем очевидны. Даже в детском саде такие книжки сочтут примитивными.

По поводу UML у буча тоже описано, но кто сказал, что без UML нельзя обойтись? - посмотрите классическую книгу страуструпа по С++, там есть диаграммы отражающие связи между классами. но они не соответствуют UML ни разу. При этом суть отражают не хуже.

Спасибо за подробный ответ, хотя не могу сказать что я этого не знал) Просто хочется чтобы был какой-то стандарт, проверенный метод, по которому можно было бы как по шаблону делать. Но тут мне надо было понять - проектирование - это не автоматизированный процесс, точнее не может им быть, скорее это эвристический процесс.
Сразу после написания темы я неожиданно нашел полезную книжку, в которой как раз даются ответы на мои вопросы. Называется эта прекрасная книга так: "Архитектура корпоративных программных приложений" - Мартин Фаулер. Вообще мне скорее странно что данной теме мало уделяется внимания, ведь процесс - проектирования, как мне кажется, более важен чем собственно само кодирование.

 

[rrrFer]

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

Что я и пишу, сколько я книжек не читал, не мог сказать что узнал что-то новое.

Книгу Фаулера не читал, хотя когда начал искать, оказалось, месяц назад уже скачал ее с торрента ))
Начал читать, пишет он про паттерны, только называет другими словами.

Есть такая штука...структурные паттерны - вот про них я читал у Гаммы и не только.
Небольшой обзор книг по теме есть тут:

Ссылка скрыта от гостей

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

У макколма очень забавная книжа (в конце есть исчисление паттернов, прикольно).