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

Тема в разделе "Общие вопросы", создана пользователем sasha465, 27 фев 2014.

  1. sasha465

    sasha465 Well-Known Member

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

    rrrFer Well-Known Member
    Команда форума C\C++ Team

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

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

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

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

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

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

    rrrFer Well-Known Member
    Команда форума C\C++ Team

    Регистрация:
    6 сен 2011
    Сообщения:
    1.324
    Симпатии:
    36
    диаграммы классов (или объектов) + диаграмма последовательности.
    Мне всегда хватало этих 3 видов диаграмм.
    Хотя вместо диаграмм последовательности я чаще словами описываю (а чем не вариант?) - очень неудобно их рисовать потому что и инструментов удобных я не видел под линукс. кривое Umbrello меня достало.
     
  4. sasha465

    sasha465 Well-Known Member

    Регистрация:
    29 мар 2009
    Сообщения:
    69
    Симпатии:
    0
    Довольно удобным под Linux мне показалась Dia, по-моему гораздо лучше Umbrella будет.
     
  5. sasha465

    sasha465 Well-Known Member

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

    rrrFer Well-Known Member
    Команда форума C\C++ Team

    Регистрация:
    6 сен 2011
    Сообщения:
    1.324
    Симпатии:
    36
    Что я и пишу, сколько я книжек не читал, не мог сказать что узнал что-то новое.

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

    Есть такая штука...структурные паттерны - вот про них я читал у Гаммы и не только.
    Небольшой обзор книг по теме есть тут: http://pro-prof.com/books/%D0%BF%D1%80%D0%...%BD%D0%B8%D0%B5

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

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

Поделиться этой страницей