Версия для печати темы

Автор: Янычар 27.02.2014 18:29

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

Автор: OCTAGRAM 4.03.2014 22:50

Если нужно о чём-то договориться, то сразу кодить не получится. Хотя иногда сразу проектировать тоже не получается, и лучше накодить что-то гарантированно неудачное, но хоть понятно станет, в какие ограничения всё на практике упирается.

Не знаю насчёт UML, на обычных листах A4, либо в Dia свои мысли выражаются вполне себе нормально. Хотя, я знаю, есть методики. И я даже книжечку толстенную раздобыл, Saba Zamir Handbook of Object Technology, где в том числе и разные моменты проектирования описаны. BON - Business Object Notation - не знаю, что это, но в книге это тоже есть. Там, где раньше работал, была общая проблема, что наслоения кода накладывались одно на другое, и взять бы да переделать как следует, но для этого нет времени сегодня, завтра, послезавтра, никогда, и код отравлен сиюминутными решениями, так что хорошее проектирование только снилось.

Автор: Rian 30.03.2014 22:07

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

Автор: Edgex 19.05.2019 19:43

Или пошире немножко: какие могут быть побочные эффекты и как от них по возможности уберечься...