Сорри за слегка ламерский вопрос.

Дошли руки до изучения матчасти — книжек товарищей-гуру о конкретных методологиях.

Очень забавно одновременно читать введения в XP/RUP/MSF/DDD и пытаться отделить принципиальные отличия от несовпадений в терминологии.

Подскажите плиз, это я неправильно понимаю, или вся "большая тройка" танцует от функциональных требований? На основе требований разрабатывается конкретные юз-кейсы — из них получаются диаграммы классов, а там уже и до архитектуры недалеко. Не, различия есть, в UP весьма приветствуются тома экспертного анализа, а в XP — бог-заказчик. Но есть такое ощущение, что во всех приводимых примерах архитектура, разбивка на классы и т.п. проектируется исходя из требований к продукту, без учёта реализации или без учёта возможных изменений или вообще с рекомендацией забить на планирование, потому что а) фиг угадаешь и б) если будешь делать всё правильно, стоимость изменений будет линейной, расслабься

Конечно, я намеренно передёргиваю. Но вот Эрик Эванс (который DDD) мягенько так ругает остальных товарищей, что дескть нехорошо обижать предметную область (вообще-то он использует термин domain), она ведь самая главная и вообще давайте жить дружно и использовать одну общую концептуальную модель. И что нехорошо вообще-то строить проектпо самой нестабильной информации. Ибо требования меняются постоянно, а вот архитектура как заложена в самом начале, так и не избавишься... В то же время, сам Эрик Эванс тоже не гнушается рисовать use-case и тащить бизнес-логику в доменную модель.

В общем что-то тут не так. Чую, но обосновать не могу (с)Каганов.

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

S>Подскажите плиз, это я неправильно понимаю, или вся "большая тройка" танцует от функциональных требований?

Архитектура (программного обеспечения) – это совокупность согласованных технических решений направленная на удовлетворение требований, предъявляемых к программному обеспечению.
Т.е. архитектура — есть функция требований. Это аксиома.

Но есть второй аспект — инженерный.
Допустим, есть у нас требования создать устройство для сиденя, то есть — табуретку. Табуретка штука простая, но сделать мы ее можем разными способами. Можем: а) сколотить гвоздями, б) соединить детали в шип на клею, в) использовать современную мебельную фурнитуру для скрепления деталей.
Соответственно мы получим три табуретки с совершенно разными качествами. Первая развалится через пару дней, вторая прослужит пару лет, третья будет служить долго, а при необходимости у нее можно будет легко заменить сломаную ножку.

Так же и с софтом. Можно создать продукт, который удовлетворяет всем требованиям, но по реализации — говно. Можно создать продукт который удовлетворяет всем требованиям и безупречный с инженерной точки зрения (говорят, что можно, но я пока не видел такого ). Можно создать продукт безупречный с инженерной точки зрения и абсолютно бесполезный, потому что он не учитывает требований.

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

S>На основе требований разрабатывается конкретные юз-кейсы — из них получаются диаграммы классов, а там уже и до архитектуры недалеко.
Это как? юзкейсы -> диаграммы классов -> архитектура

Ziaw>Это как? юзкейсы -> диаграммы классов -> архитектура
Меня даже переход юзкейсы -> диаграммы классов смущает. Потому и спрашиваю.

Ну дыкть я ж говорю — тяжко пытаться отличить маркетинг от конкретных рекомендаций Такое чувство, что я читаю не те книжки. XP/Agile — это Кент Бек и Скотт Амблерс. Кого принято читать по RUP/MSF?

Ясно, что любая методология — скорее шаблон, чем готовое решения. Посему вопрос будет звучать так: кого читать чтобы уяснить нюансы применения на практике?

stump, если продолжить аналогию с табуреткой — как происходит выделение отдельных деталей, материалов и определение способа сборки? В требованиях этого нет, заказчику это не важно (точнее, он думает что неважно)... Зависит от квалификации разработчиков?

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

Или этот вопрос нечто типа неуловимого джо и не входит в проблемы, которые решают методологии разработки?

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

Спасибо!

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

S>Но есть второй аспект — инженерный.
S>Допустим, есть у нас требования создать устройство для сиденя, то есть — табуретку. Табуретка штука простая, но сделать мы ее можем разными способами. Можем: а) сколотить гвоздями, б) соединить детали в шип на клею, в) использовать современную мебельную фурнитуру для скрепления деталей.
S>Соответственно мы получим три табуретки с совершенно разными качествами. Первая развалится через пару дней, вторая прослужит пару лет, третья будет служить долго, а при необходимости у нее можно будет легко заменить сломаную ножку.

Тут, видишь ли, нехилая проблема заключается в том, что 99% менеджеров, занимающихся планированием продаж и производства этих самых табуреток, совершенно наплевать на инженерные аспекты реализации табуретки. У них, как правило, основные требования — "Дешевле! Еще дешевле! Быстрее! Еще быстрее! Прямо сейчас, а еще лучше — еще вчера! Главное — продать! Быстрее!". В таких условиях, разумеется, берем абы как сделанные заготовки, и — сколачиваем их гвоздями на скорую руку.... Ну и получаем табуретку соответствующего качества.

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


V_S>Тут, видишь ли, нехилая проблема заключается в том, что 99% менеджеров, занимающихся планированием продаж и производства этих самых табуреток, совершенно наплевать на инженерные аспекты реализации табуретки. У них, как правило, основные требования — "Дешевле! Еще дешевле! Быстрее! Еще быстрее! Прямо сейчас, а еще лучше — еще вчера! Главное — продать! Быстрее!". В таких условиях, разумеется, берем абы как сделанные заготовки, и — сколачиваем их гвоздями на скорую руку.... Ну и получаем табуретку соответствующего качества.

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

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

Здравствуйте, dmoz,

А я, знаешь-ли, совершенно согласен с тем, что эти требования диктует рынок. Но! Очень мало менеджеров, способных эти требования ранжировать в контексте всего комплекса требований к продукту, — как экономических, так и технических. Очень мало менеджеров, знающих и понимающих правило "железного треугольника". Но все же — есть.

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

S>Очень забавно одновременно читать введения в XP/RUP/MSF/DDD и пытаться отделить принципиальные отличия от несовпадений в терминологии.

S>Подскажите плиз, это я неправильно понимаю, или вся "большая тройка" танцует от функциональных требований?

Насколько я знаю, в XP последовательность следующая:

Текущие Use Case ~= текущая метафора системы -> тесты к системе -> наипростейший код, удовлетворяющий тестам

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

Вернемся к табуреткам. Заказчик хочет на чем-то сидеть.

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

Потом пишутся тесты, которые бы проверяли, что то, что будет сделано выдержит 150,000приседаний 140кг, и что эта штука будет весить меньше 7 кг, и что объект размещенный на него будет находиться над полом на высоте 90 см.

Потом на эти тесты смотрят и говорят — а давайте сделаем все это из дерева и скрепим современной фурнитурой! Тут конечно многое зависит от программистов-плотников. Вообще подразумевается, что программисты догадаются, что тут лучший материал — дерево, и что ножки и сиденье к табуретке надо сделать как в ИКЕЕ — ножки отдельно, сиденье отдельно, чтобы если что, сделать табуретку на 6 ножках, или сиденье с круглого на квадратное заменить легко.

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

S>stump, если продолжить аналогию с табуреткой — как происходит выделение отдельных деталей, материалов и определение способа сборки? В требованиях этого нет, заказчику это не важно (точнее, он думает что неважно)... Зависит от квалификации разработчиков?

Ну так это суть процесса системного анализа и проектирования. Это навыки такие, умения. Умение "выделять сущности предметной области из требований", "формулировать нефункциональные требования на основе пожелания заказчика", "принимать проектные решения на основе нефункциональных и функциональных требований" и т.д.
Это не зависит от методологий разработки. Это инженерия. Это суть работы системного аналитика и архитектора, или программиста. Из книжек по методологиям этого не надергаешь, тут другие книжки читать надо.

S>Да, чтобы не было непонимания. Архитектура — есть функция требований. Как тогда обозвать архитектуру с точки зрения инженера? На основе чего принимаются решения?
"Решения" — это и есть архитектура, и принимаются они на основе требований, ну и конечно квалификация "решателя" влияет сильно.

S>Или этот вопрос нечто типа неуловимого джо и не входит в проблемы, которые решают методологии разработки?
Не все. RUP, DDD рассматривают методы системного анализа, как часть своей методологии.

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

S>Сорри за слегка ламерский вопрос.

S>Дошли руки до изучения матчасти — книжек товарищей-гуру о конкретных методологиях.

S>Очень забавно одновременно читать введения в XP/RUP/MSF/DDD и пытаться отделить принципиальные отличия от несовпадений в терминологии.

S>Подскажите плиз, это я неправильно понимаю, или вся "большая тройка" танцует от функциональных требований? На основе требований разрабатывается конкретные юз-кейсы — из них получаются диаграммы классов, а там уже и до архитектуры недалеко. Не, различия есть, в UP весьма приветствуются тома экспертного анализа, а в XP — бог-заказчик. Но есть такое ощущение, что во всех приводимых примерах архитектура, разбивка на классы и т.п. проектируется исходя из требований к продукту, без учёта реализации или без учёта возможных изменений или вообще с рекомендацией забить на планирование, потому что а) фиг угадаешь и б) если будешь делать всё правильно, стоимость изменений будет линейной, расслабься

S>Конечно, я намеренно передёргиваю. Но вот Эрик Эванс (который DDD) мягенько так ругает остальных товарищей, что дескть нехорошо обижать предметную область (вообще-то он использует термин domain), она ведь самая главная и вообще давайте жить дружно и использовать одну общую концептуальную модель. И что нехорошо вообще-то строить проектпо самой нестабильной информации. Ибо требования меняются постоянно, а вот архитектура как заложена в самом начале, так и не избавишься... В то же время, сам Эрик Эванс тоже не гнушается рисовать use-case и тащить бизнес-логику в доменную модель.

S>В общем что-то тут не так. Чую, но обосновать не могу (с)Каганов.

Приведенные референсы на работы по методологиям организации труда (XP/RUP/MSF/DDD) не содержат ответа на основной вопрос, как рождается архитектура. Для этого и книжки надо по архитектуре смотреть. Давид Гарлан, Пол Клементс, Лен Басс, Рик Казман, Феликс Бахманн, Джэймс Иверс, Рид Литтле, Роберт Норд -- вот, кто пишет об архитектурах...

Use case — только лишь форма записи функциональных требований. Только по ним архитектуру не собрать никак. Нужно, как минимум, рассмотреть технические требования, и требования качества. Все вместе они подлежат анализу, в процессе которого создается концептуальная модель будущей системы, внутри которой выделяются домены, проводится ее оптимизация, и т.д. Далее, выбираются технологии, архитектурный стиль, стратегия. И уже после этого начинается работа над архитектурой как таковой. В процессе этой работы часто создают несколько прототипов системы. Подвергают их тестам, проектируя нагрузки, и т.д.

Конечно, я пытаюсь обобщить, а на самом деле, существует множество устоявшихся подходов, которые стоит изучить, если заниматься архитектурой.
Вот наиболее распространенные: 4+1, DODAF, MODAF, TOGAF, SOMF, Zachman framework.

Желаю удачи.

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

N>Текущие Use Case ~= текущая метафора системы -> тесты к системе -> наипростейший код, удовлетворяющий тестам

Там в XP user stories, которые не есть то же самое, что use cases, ибо кейсы бывают не только внешние, обусловленные функциональными требованиями, но и внутренние -- отражающие отношения между элементами архитектуры системы.
Следуя приведенной выше последовательности, xp-ры притащат плиту и стопку кирпичей общим весом 150 кг, быстро сколотят колченогое угрёбище, поставят на него плиту с кипричами, после чего приведут on-site customer-а и скажут: "вот то, что ты просил". Далее, если не будут немедленно посланы, сделают еще несколько итераций в том же духе. После чего спросят у гуру xp: "что же мы сделали не так?". На что гуру ответит: "вы не следовали всем 12-ти заветам xp bible" или что-то в этом духе.

Таак. То есть я правильно понял фишку и методологии разработки — скорее для управления проектом/получения результатов, чем для создания "идеального продукта"(тм)? Ёк...

В некоторых методологиях заниматься архитектурой неудобно как-то. В том же XP: получится идеальная, прочная монолитная табуретка из композитных материалов, вылерживающая 12,5 прямых попаданий слона. На приёмочных испытаниях заказчик, который 1000 раз описывал как выглядит табуретка, спрашивает "а где стул?". Была бы сборно-разборная табуретка — поменяли бы 2 ножки. Впрочем, поскольку мы следуем всем 12 заповедям, кардинальные изменения нас не смущают — мы создаём табуретку с дополнительными 2 ножками сверху и добавляем к ним перекладину. После чего уходим за слоном...

Попробую словами выразить то, что меня смущает: меня смущает подход "делаем один раз то, что хочет заказчик — дальше его проблемы". Как тогда быть с долгоживущим проектом, если заранее известно, что будет куча версий, что требования будут меняться и (главное!) потребуется взаимодействие с другими системами. Здесь видится отдельная проблема — мы не можем предвидеть, что от нас потребуют внешние интеграторы. Т.е. в идеале из нас должно торчать API, совпадающее с доменной моделью (говорим пока без учёта нюансов), доступ к ней должен быть через стандартные интерфейсы, да ещё и неизменным. Как к этим выводам прийти из "и эта. шоп 1с и ыксель мне работали, да!" — непознаваемо.

Если проектировать только из требований — мы надеемся, что часть, что нам удалось выделить в архитектуру будет неизменной. Потому как иначе нам либо перекраивать архитектуру, либо замазывать отдельные косяки. Кажется, я догадываюсь какой вариант предпочтут

Ещё забавней проблема становится, когда мы делаем шароварный продукт и у нас нет заказчика вообще. Ясно, что продаваться мы сможем если будем быстро штамповать версию за версией с новыми мегафичами. Т.е. уже даже все разработчики заинтересованы в нормальной архитектуре. Куда им копать?

Пока из того что я прочитал, явно эти проблемы обсасывались только Эвансом — умные вещи пишет дядька. Что смущает — намёки типа "заинтересуйте всех использованием общей модели — и всё у вас получится". Утопия...

Интересно, вообще эти вопросы поднимались явно в каких-нибудь книгах?

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

S>Не все. RUP, DDD рассматривают методы системного анализа, как часть своей методологии.

Stump, а в каком месте в RUP начинает появляться системный анализ как часть проекта? Пока единственные упоминания что я видел — архитекторы должны использовать анализ, сделанный экспертами по предметной области. Вездесущий Эванс этот подход тоже критиковал, ибо теряется невербальное знание, которое нельзя передать через бумагу, аминь

Что-то подозрительно как-то у Эванса на всё ответ есть. Непризнанный пророк?

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

S>Интересно, вообще эти вопросы поднимались явно в каких-нибудь книгах?

Поднимались

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

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

S>>Не все. RUP, DDD рассматривают методы системного анализа, как часть своей методологии.

S>Stump, а в каком месте в RUP начинает появляться системный анализ как часть проекта? Пока единственные упоминания что я видел — архитекторы должны использовать анализ, сделанный экспертами по предметной области. Вездесущий Эванс этот подход тоже критиковал, ибо теряется невербальное знание, которое нельзя передать через бумагу, аминь

Крэг Ларман "Применение UML и шаблонов проектирования"

Опять скажу про XP.
Здравствуйте, Sinix, Вы писали:

S>В некоторых методологиях заниматься архитектурой неудобно как-то. В том же XP: получится идеальная, прочная монолитная табуретка из композитных материалов, вылерживающая 12,5 прямых попаданий слона. На приёмочных испытаниях заказчик, который 1000 раз описывал как выглядит табуретка, спрашивает "а где стул?". Была бы сборно-разборная табуретка — поменяли бы 2 ножки. Впрочем, поскольку мы следуем всем 12 заповедям, кардинальные изменения нас не смущают — мы создаём табуретку с дополнительными 2 ножками сверху и добавляем к ним перекладину. После чего уходим за слоном...

Просто хотел бы уточнить для ясности
От монолитной табуретки должен спасать опыт программистов. XP — методология создания !ПО!, так что, если кто-то программирует не модульно, не ортогонально, не понятно то это в принципе очень плохо. И результат этого в виде монолитной табуретки, удовлетворяющей требованиям легкости, переносимости и нахождения объекта на высоте — еще очень неплохой результат. Т.е. хотя я и написал, что нужно просто написать что-то удовлетворяющее тестам и как можно проще, всё-таки имел в виду, что это не написано на санскрите через copy-paste.

От внезапной спинки должна спасать метафора системы. Так как в неё входят не только совместное понимание требований заказчика и представление о возможных реализациях этих потребностей, но и совметное понимание перспектив развития проекта, понимание какие требования строгие, а какие можно менять при обсуждении с заказчиком и т.д. Это совместное понимание не выражается в тестах, но может существенно повлиять на том этапе, где программисты по тестам пишут код. Конечно, от того случая, когда спинка была действительно неожиданной это не спасет. Это особенность XP, что оно требует, что если те люди, которые общались с заказчиком понимают, что может понадобиться спинка, то и люди которые пишут код тоже понимали, что может понадобиться спинка.

Кроме того, от сюрприза со спинкой спасут частые релизы. Т.е. уже на первых релизах заказчик спросит: "Ну, тут же подразумевается спинка, я правильно понял?".

S>Попробую словами выразить то, что меня смущает: меня смущает подход "делаем один раз то, что хочет заказчик — дальше его проблемы". Как тогда быть с долгоживущим проектом, если заранее известно, что будет куча версий, что требования будут меняться и (главное!) потребуется взаимодействие с другими системами. Здесь видится отдельная проблема — мы не можем предвидеть, что от нас потребуют внешние интеграторы. Т.е. в идеале из нас должно торчать API, совпадающее с доменной моделью (говорим пока без учёта нюансов), доступ к ней должен быть через стандартные интерфейсы, да ещё и неизменным. Как к этим выводам прийти из "и эта. шоп 1с и ыксель мне работали, да!" — непознаваемо.

Честно говоря не совсем тут понял проблему. Выкладывают потихоньку релиз за релизом систему, она всё растёт. Все понимают, что со временем понадобится общаться с Экселем и 1Сом, а пока реализуют более важные требования. Когда наступает очередь делать интеграцию, общаются с заказчиком, предлагают свои решения, смотрят его, если он готов их предоставить, пишут по результатам общения тесты, выкладывают релизы.

S>Если проектировать только из требований — мы надеемся, что часть, что нам удалось выделить в архитектуру будет неизменной. Потому как иначе нам либо перекраивать архитектуру, либо замазывать отдельные косяки. Кажется, я догадываюсь какой вариант предпочтут

Тут довольно ключевой момент XP. Дело в том, что это чуть ли не главная основа XP, что Software — это что-то soft, легко изменеямое. Сильно отрицается аналогия между архитектурой ПО, и архитектурой, скажем дома. Подразумевается, что ПО обладает таким свойством, что если его писать правильно, то небольшие изменения в требованиях ведут к небольшим изменениям в коде. А так релизы частые, то изменения в требованиях всегда должны быть небольшими. Ну а если заказчик приходит и говорит:"Так, все что мы писали до этого фигня", хотя видел весь процесс, то сомневаюсь, что от этого хоть что-то спасёт...

S>Ещё забавней проблема становится, когда мы делаем шароварный продукт и у нас нет заказчика вообще. Ясно, что продаваться мы сможем если будем быстро штамповать версию за версией с новыми мегафичами. Т.е. уже даже все разработчики заинтересованы в нормальной архитектуре. Куда им копать?

Это проблема масштабируемости XP. Возможны различные решения, например, "внутренний заказачик".

S>Пока из того что я прочитал, явно эти проблемы обсасывались только Эвансом — умные вещи пишет дядька. Что смущает — намёки типа "заинтересуйте всех использованием общей модели — и всё у вас получится". Утопия...

В XP вообще подразумевается, как Вы уже наверное поняли, коллективный разум. Вот это, да, утопия

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

S>Таак. То есть я правильно понял фишку и методологии разработки — скорее для управления проектом/получения результатов, чем для создания "идеального продукта"(тм)? Ёк...

S>В некоторых методологиях заниматься архитектурой неудобно как-то. В том же XP: получится идеальная, прочная монолитная табуретка из композитных материалов, вылерживающая 12,5 прямых попаданий слона. На приёмочных испытаниях заказчик, который 1000 раз описывал как выглядит табуретка, спрашивает "а где стул?". Была бы сборно-разборная табуретка — поменяли бы 2 ножки. Впрочем, поскольку мы следуем всем 12 заповедям, кардинальные изменения нас не смущают — мы создаём табуретку с дополнительными 2 ножками сверху и добавляем к ним перекладину. После чего уходим за слоном...

Ну, если брать конкретно XP, то переписать архитектуру не вопрос — есть же тесты, которые позволят сделать это с минимальными потерями. И заказчик там увидет каркас табуретки задолго до приемочных испытаний, так как постоянное присутствие заказчика и передача результата заказчику как можно быстрее — одни из заповедей XP. То есть после нескольких первых итераций заказчик получит предварительную версию с одной из требуемых функций. Ну скажем это будет пенопластовая табуретка выпиленная лобзиком, которая будет выдерживать игрушечного слона . Но из неё уже будет виднее, куда двигаться дальше. Заказчик сможет понять, что он действительно хотел стул, а не табуретку.
Единственное, что в жизни так не получается, заказчик хочет подробное ТЗ еще до подписания договора, требует установить сроки.. Никто ж до конца работ не будет точно знать, что ему нужно, ни заказчик, ни тем более разработчики.

S>Попробую словами выразить то, что меня смущает: меня смущает подход "делаем один раз то, что хочет заказчик — дальше его проблемы". Как тогда быть с долгоживущим проектом, если заранее известно, что будет куча версий, что требования будут меняться и (главное!) потребуется взаимодействие с другими системами. Здесь видится отдельная проблема — мы не можем предвидеть, что от нас потребуют внешние интеграторы. Т.е. в идеале из нас должно торчать API, совпадающее с доменной моделью (говорим пока без учёта нюансов), доступ к ней должен быть через стандартные интерфейсы, да ещё и неизменным. Как к этим выводам прийти из "и эта. шоп 1с и ыксель мне работали, да!" — непознаваемо.

Нет, не получится сделать "API, совпадающее с доменной моделью". Потому что доменная модель меняется постоянно. Сегодня одни бизнес-привила, завтра другие.

S>Если проектировать только из требований — мы надеемся, что часть, что нам удалось выделить в архитектуру будет неизменной. Потому как иначе нам либо перекраивать архитектуру, либо замазывать отдельные косяки. Кажется, я догадываюсь какой вариант предпочтут

Ни один процесс не выделяет сразу ВСЕ требования в архитектуру. RUP хоть и похож на водопад, но там работы надо архитектурой начинаются до сбора всех требований. Правда, есть риск получить в самом конце одну "малюсенькую доработку", которая перечеркнет все

Быстро отвечу и исчезаю до понедельника.

Где-то выше был довод про невозможность выноса доменной модели как внешнего апи. Я правильно понимаю, что логику операций над доменом (предметной областью — кому как нравится) рассматривают как часть домена?

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

Монолитная табуретка — это идеал который можно построить из требований заказчика. Она будет удовлетворять всем требованиям — лёххкая, прочная, можно даже об ножки пивные бутылки открывать (easter egg, ага Плюс дешёвая в производстве.

Делать табуретку разборной — идти против течения, частично нарушать требования, объяснять заказчику, что он не совсем прав и т.п. Т.е. архитектурные вопросы по уму должны быть частью вопросов, которые решается в методологии. Иначе архитекторы со своими неуместными вопросами так и будут мешать "тщательно поставленному процессу" и будут типичные холивары кто главнее.

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

Зы. Никто не имел щастья выгребать данные допустим с госовских программок типа модулей сбора и т.п. (или не дай бог обмениваться с ними инфой)? Геморрой-геморроем. Причём в основном как раз из-за тесного связывания БЛ и архитектуры. С точки зрения пользователей кстати — мегаклассные софтины, 8 лет развиваются и пользователи довольны.

Когда встречаешь в данных классификатора координаты комбобокса на форме — и без них оно не работает — уже даже рыдать не хоцца. Ещё веселее использовать API. Если оно работает по принципу "имитируем нажатие на кнопки" — уже счастье. Было весело угадывать последовательность в зависимости от введённых данных. А в следующей версии логика уже поломалась...

Про всезнающего заказчика — ещё большая утопия, чем коллективный разум Отставим пока.

stump и Локотков — спасибо за ссылки. Пока просматриваю по диагонали...

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

S>Быстро отвечу и исчезаю до понедельника.

S>Где-то выше был довод про невозможность выноса доменной модели как внешнего апи. Я правильно понимаю, что логику операций над доменом (предметной областью — кому как нравится) рассматривают как часть домена?

Ну, я бы рассматривал их вместе. Хотя, надо уточнять, что значит "рассматривать".

S>Я интуитивно разделяю эти понятия. К доменной логике можно отнести описание сущностей, связей и возможных операций над ними. А вот включать туда бизнес-логику... смущает...

Даже если не включать туда бизнес логику — то сам набор сущностей и их атрибутов постоянно меняется.

S>Монолитная табуретка — это идеал который можно построить из требований заказчика. Она будет удовлетворять всем требованиям — лёххкая, прочная, можно даже об ножки пивные бутылки открывать (easter egg, ага Плюс дешёвая в производстве.
S>Делать табуретку разборной — идти против течения, частично нарушать требования, объяснять заказчику, что он не совсем прав и т.п. Т.е. архитектурные вопросы по уму должны быть частью вопросов, которые решается в методологии. Иначе архитекторы со своими неуместными вопросами так и будут мешать "тщательно поставленному процессу" и будут типичные холивары кто главнее.

Ну тут идеал — табуретка, которая выглядит и обладает всеми свойствами монолитной, а на самом деле разборная. На эту тему есть книга "Психбольница в руках пациетов", автор Купер кажется. Потому что на деле как получается — заказчик хочет монолит, а разработчикам удобнее сделать разборную, так как заказчик каждый день хочет монолит новой формы . И в результате делается конструкция, которой удобно можно пользоваться только зная, как она устроена изнутри. Сделать же, чтобы хорошо было и тем и тем — очень нетривиально. Но я бы пользователя все-таки ставил во главе архитекторов. Хочет он эту фичу, которая по мнению архитектора абсолютно "лишняя" и не нужна — все равно надо делать. Если она действительно не нужна, время покажет. Главное, вести учет использования фич, чтобы знать, что пользователи используют, а что нет. Об этом, кстати, во второй версии XP тоже говорилось.


S>Кажется понял, откуда мой пессимизм — наследие борьбы с различными фреймворками/недоделками/неоднократное изобретание велосипедов ибо у комплектного колёса не крутились. И вот тут как раз вся логика летела на фиг, если заранее не озаботиться изоляцией от фреймворка. Поэтому подход "делаем всё с лёту и оно наверно заработает"...

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

S>Про всезнающего заказчика — ещё большая утопия, чем коллективный разум Отставим пока.

Для этого надо быть рядом с заказчиком. Но и заказчик должен быть хоть чуть-чуть грамотный. Даже у нас в не очень большой организации есть люди, которые могут внятно озвучить свою проблему и поймут, что какие-то части ПО надо переделать, чтобы им было удобнее и быстрее работать. Но есть и такие, которые упорно будут считать на бумажке, вместо того чтобы послать запрос в поддержку "а добавьте нам в отчет колонку с такими-то числами". Или ругаться на неудобную программу, но упорно продолжать с нею бороться.

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

Sshur, во многом согласен, но во это:

S>Даже если не включать туда бизнес логику — то сам набор сущностей и их атрибутов постоянно меняется.

вызывает дикое удивление — у вас реально так? Потому как в моём восприятии набор сущностей определяется предметной областью, в которой работает заказчик, и никак не им самим. Я не говорю о всяких воспомогательных структурах/атрибутах — только о модели. У вас реально был случай, когда область деятельности заказчика всё время менялась? Просветите пожалуйста — интересно

Здравствуйте, Аноним, Вы писали:

А>Sshur, во многом согласен, но во это:

S>>Даже если не включать туда бизнес логику — то сам набор сущностей и их атрибутов постоянно меняется.

А>вызывает дикое удивление — у вас реально так? Потому как в моём восприятии набор сущностей определяется предметной областью, в которой работает заказчик, и никак не им самим. Я не говорю о всяких воспомогательных структурах/атрибутах — только о модели. У вас реально был случай, когда область деятельности заказчика всё время менялась? Просветите пожалуйста — интересно

Бизнес растет, расширяется. Появляются новые услуги, старые исчезают. Либо автоматизируются области, ранее нетронутые автоматизацией. Примеры нужны?

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

А>>вызывает дикое удивление — у вас реально так? Потому как в моём восприятии набор сущностей определяется предметной областью, в которой работает заказчик, и никак не им самим. Я не говорю о всяких воспомогательных структурах/атрибутах — только о модели. У вас реально был случай, когда область деятельности заказчика всё время менялась? Просветите пожалуйста — интересно

S>Бизнес растет, расширяется. Появляются новые услуги, старые исчезают. Либо автоматизируются области, ранее нетронутые автоматизацией. Примеры нужны?

Ну дык мы о разных сценариях говорим. Вы — об изменении структуры сущностей из-за изменения требований заказчика. Ясен пень, что они будут постоянно меняться, если требования типа "информация о заказчике должна отображаться следующим образом: Фамилия И.О. ..." хардкодятся в классы/структуры хранения.

Я говорю об изменении предметной области. Она не так уж и часто меняется, все сущности/взаимоотношения вполне себе выводятся из серий интерьвью/самостоятельного изучения.

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


S>Ну дык мы о разных сценариях говорим. Вы — об изменении структуры сущностей из-за изменения требований заказчика. Ясен пень, что они будут постоянно меняться, если требования типа "информация о заказчике должна отображаться следующим образом: Фамилия И.О. ..." хардкодятся в классы/структуры хранения.

Нет, я совсем не про изменения режима отображения. Речь шла о модели предметной области. Вот например, биллинг сотовых операторов. Предположим самый простой вариант — один поминутный тарфиный план для всех абонентов. Все просто, в модели две сущности "абонент" и "звонок", на основании этого можно за период рассчитать стоимость услуг по абонентам. Смотрим далее:

S>Я говорю об изменении предметной области. Она не так уж и часто меняется, все сущности/взаимоотношения вполне себе выводятся из серий интерьвью/самостоятельного изучения.

Не часто, но все же меняется. Вот, возвращаясь к упомянотому выше ОПСОС'у. Конкуренты поджали, пришлось вводить "любимые номера", потом льготный роуминг — вот и появились новые сущности в самой предметной области. Я даже не представляю, как тут отделить модель от бизнес логики

Здравствуйте, Sshur!

S>>Я говорю об изменении предметной области. Она не так уж и часто меняется, все сущности/взаимоотношения вполне себе выводятся из серий интерьвью/самостоятельного изучения.

S>Не часто, но все же меняется. Вот, возвращаясь к упомянотому выше ОПСОС'у. Конкуренты поджали, пришлось вводить "любимые номера", потом льготный роуминг — вот и появились новые сущности в самой предметной области. Я даже не представляю, как тут отделить модель от бизнес логики

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

Как самый примитивный вариант (не учитывая нюансы предметной области — чревато косяками):

БЛ здесь живёт в операциях рассчёта, единственные создаваемые сущности в предметной области — это список услуг и услуги, используемые абонентом (здесь могут жить всякие параметры, которые выбираются пользователем, насколько знаю — практически не бывает для частных лиц). Аналогично сама процедура расчёта использует правила. Появление нового правила никак не меняет предметную область или структуру сущностей. Единственное, что меняется — параметры каждого правила, но их по-любому надо изолировать от остальной системы.

Как к такому подходу можно прийти, если танцевать от священности требований "пользователь может пользоваться льготными звонами на 3 выбранных им номера (стоимость ххх независимо от длительности звонка) и роумингом (стоимость увеличивается на yyy каждые zzz секунд начиная с ttt)" — я даже не представляю.

Ваша очередь объяснять

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


S>БЛ здесь живёт в операциях рассчёта, единственные создаваемые сущности в предметной области — это список услуг и услуги, используемые абонентом (здесь могут жить всякие параметры, которые выбираются пользователем, насколько знаю — практически не бывает для частных лиц). Аналогично сама процедура расчёта использует правила. Появление нового правила никак не меняет предметную область или структуру сущностей. Единственное, что меняется — параметры каждого правила, но их по-любому надо изолировать от остальной системы.

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

S>Как к такому подходу можно прийти, если танцевать от священности требований "пользователь может пользоваться льготными звонами на 3 выбранных им номера (стоимость ххх независимо от длительности звонка) и роумингом (стоимость увеличивается на yyy каждые zzz секунд начиная с ttt)" — я даже не представляю.

S>Ваша очередь объяснять

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

ХП кстати, дает больше других — там говорится — берем требования, реализуем самым простым образом. То есть есть, с чего начать. Хотя, все равно кто-то должен принять принципиальные решения о платформе, языке, количестве слоев итп. Можно конечно не иметь никакого опыта вообще — но это какой-то совсем крайний случай Все таки, архитектура вырастает из опыта разработчиков.

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

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

S>Наверно надо как-то более подробно описать данную схему, потому что я все равно не представляю, как изолировать БЛ от доменной модели. Модель от логики еще можно, а вот наоборот... Как можно что-то посчитать, если ты ничего не знаешь о том, что считаешь? Например, если брать тех же сотовых операторов — вот мне надо посчитать, на какую сумму наговорил абонент в месяц. На входе имеем список звонков вида (номер, время начала, длительность). Как должна в таком случае выглядеть логика расчета стоимости, изолированная от модели (то есть она ничего не должна знать об абонентах, звонках и номерах)?

Логике достаточно знать об интерфейсе модели. Вот простой пример из жизни: например, российские представления об идентификации человека это ФИО, в то время, как в США это ИФ, а в средней азии это И ибн О ибн [ИмяДеда] ибн [ИмяПрадеда], а в Древнем Риме praenomen-nomen-cognomen, и т.д. Поэтому когда такие люди имеют дело с российским законодательством им тяжело, приходится реализовывать интерфейс ФИО, порой довольно убого. Но законодательство(БЛ) не меняется под таких людей. Только изредка, из-за очень веских причин(например, если бы отчества окончательно утратили реальное употребление).

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

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

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

S>>Наверно надо как-то более подробно описать данную схему, потому что я все равно не представляю, как изолировать БЛ от доменной модели. Модель от логики еще можно, а вот наоборот... Как можно что-то посчитать, если ты ничего не знаешь о том, что считаешь? Например, если брать тех же сотовых операторов — вот мне надо посчитать, на какую сумму наговорил абонент в месяц. На входе имеем список звонков вида (номер, время начала, длительность). Как должна в таком случае выглядеть логика расчета стоимости, изолированная от модели (то есть она ничего не должна знать об абонентах, звонках и номерах)?

N>Логике достаточно знать об интерфейсе модели.

Ну да, хотя бы интерфейс, но знать-то надо. Под изоляцией я понимал, что вообще ничего не известно. Этакий крайний случай, когда есть алгоритм расчета, который считает абстракных слонов, и ему не важно что это — звонки, товары или километры . Такие абстрактные алгоритмы даже существуют — биллинговаые системы. Есть счет, его пополняют платежами, и списывают за услуги, не важно какие. Но схема работы самого биллинга фиксированная, прошел платеж — счет увеличился, прошло списание — счет уменьшился. Основная БЛ и соответственно "стежень изменений" будет находиться вне его — определение, какая услуга сколько стоит.

N> Вот простой пример из жизни: например, российские представления об идентификации человека это ФИО, в то время, как в США это ИФ, а в средней азии это И ибн О ибн [ИмяДеда] ибн [ИмяПрадеда], а в Древнем Риме praenomen-nomen-cognomen, и т.д. Поэтому когда такие люди имеют дело с российским законодательством им тяжело, приходится реализовывать интерфейс ФИО, порой довольно убого. Но законодательство(БЛ) не меняется под таких людей. Только изредка, из-за очень веских причин(например, если бы отчества окончательно утратили реальное употребление).

Ну да. Только этот пример как раз мою мысль подтверждает Тут разные модели подстраиваются под одну логику. Логика имеет четко прописанный инферфейс идентификации человека по ФИО, и вдруг оказывается, что в некоторых случаях это не так. Я к тому и вел, что выделять в качестве фреймворка интерфейс модели как что-то неизменяемое в общем случае нельзя, так как он тоже меняется. Хотя, в определенных случаях это будет возможно, если реализуется коммерческий проект для хорошо изученной области, где 90% организаций работают по одной схеме с незначительными отклонениями. В моей области — логистике и транспортных перевозках — такого нет пока У всех свои тарифы и правила

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

S>Ну да, хотя бы интерфейс, но знать-то надо. Под изоляцией я понимал, что вообще ничего не известно.

Я как раз считаю, что интерфейс это и есть "ничего знать не надо", это просто описание формата взаимодействия. В конце концов бизнес-правила они не витают в воздухе, а регулируют конкретные данные. Интерфейс ФИО не гарантирует нам даже того, что это человек, под ФИО может прийти Бегемот Гиппопотамович Нежвачный, который, строго говоря, зверь. Или скажем гоголевские ревизские души, которые есть только нечто, написанное на бумаге. Интерфейс в коде можно доразбить на элементарные типы, уничтожив явное его описание, но это не уничтожит сам факт того, что взаимодействие между моделью и БЛ осуществляется по каким-то законам. Я вижу огромную разницу между интерфейсом модели и самой моделью, хотя она может и казаться незначительной.

S>Ну да. Только этот пример как раз мою мысль подтверждает Тут разные модели подстраиваются под одну логику. Логика имеет четко прописанный инферфейс идентификации человека по ФИО, и вдруг оказывается, что в некоторых случаях это не так. Я к тому и вел, что выделять в качестве фреймворка интерфейс модели как что-то неизменяемое в общем случае нельзя, так как он тоже меняется. Хотя, в определенных случаях это будет возможно, если реализуется коммерческий проект для хорошо изученной области, где 90% организаций работают по одной схеме с незначительными отклонениями. В моей области — логистике и транспортных перевозках — такого нет пока У всех свои тарифы и правила

Я считаю это только проблемой реализации. Т.е. даже в вашем случае, возможно подойдёт интерфейс(ну я так, примерно, я ж не специалист) IПеревозка{ Список сущностей (характеристика+ее количественное значение)}, а тарифы получают этот список и выводят или сумму, или факт, что данных о перевозке недостаточно.

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

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

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

S>>БЛ здесь живёт в операциях рассчёта, единственные создаваемые сущности в предметной области — это список услуг и услуги, используемые абонентом (здесь могут жить всякие параметры, которые выбираются пользователем, насколько знаю — практически не бывает для частных лиц). Аналогично сама процедура расчёта использует правила. Появление нового правила никак не меняет предметную область или структуру сущностей. Единственное, что меняется — параметры каждого правила, но их по-любому надо изолировать от остальной системы.

S>Наверно надо как-то более подробно описать данную схему, потому что я все равно не представляю, как изолировать БЛ от доменной модели. Модель от логики еще можно, а вот наоборот... Как можно что-то посчитать, если ты ничего не знаешь о том, что считаешь?

Не с той стороны мыслите Смысл такого разделения — защита _модели_ от требований заказчика. Начнёте смещивать — закончите реализацией конкретных требований конкретных дядей. Даже тот примитив что я описал уже явно декларирует, что конкретные правила — проблема реализации и заказчика, системе глубоко всё равно, как эти правила будут считаться — любой расколбас не должен (в идеале) пролазить дальше основных интерфейсов.

S>Непонятно, что именно объяснять. Как получить архитектуру на основании требований? Это примерно та же задача, что и как построить самолет, имея ТТХ. Либо нужен опыт разработчиков, которые построили уже не один самолет и представляют в общем как он должен выглядеть (если не требуется каких-то революционных изменений), либо, если опыта нет, итеративный процесс.

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

S>А все процессы разарботки типа ХП или RUP — это всего лишь способы организации взаимодействия разработчиков, заказчика, руководства, способы формализации процесса, документирования итд.. Если никто не знает, с какой стороны подходить к решению задачи — по никакой процесс не поможет.

Ну, собсно это и спрашивалось с самого начала. Если качество выходного продукта не важно — то нет смысла говорить о архитектуре, требованиях, надёжности и т.п. С другой стороны несколько странно, что в методологии, которая по идее стержень проекта и главная надежда, можно рассматривать вопросы разработки со стороны снижения стоимости изменений, но не рассматривать вопросы надёжности, качества и всего такого. Это ведь тоже вопрос управления. Не появится ведь совершенная архитектура из ничего, верно? А если проектирование ещё и мешает процессу разработки — то точно не появится

S>ХП кстати, дает больше других — там говорится — берем требования, реализуем самым простым образом.
Ога. Получаем быстро и сердито штуку, сильно заточенную под конкретный набор юз-кейсов. Изменение в логике, которые по идее могли быть изолированы в одном методе, расползаются по всему проекту. Но это не страшно, ибо после вкуривания конспекта шаманских обрядов нам уже глубоко пофиг, что и как чинить Всю ответственность — на заказчика ибо сам виноват — сам выбрал таких разработчиков. Just do 'em all

S>То есть есть, с чего начать. Хотя, все равно кто-то должен принять принципиальные решения о платформе, языке, количестве слоев итп. Можно конечно не иметь никакого опыта вообще — но это какой-то совсем крайний случай Все таки, архитектура вырастает из опыта разработчиков.

Начать можно с очень и очень многого. Самый примитив — почитать старых умных товарищей, что жили в доисторические времена, когда даже методологий не было и попробовать подумать головой. Чтобы система долго-долго жила и работала, нужен какой-никакой костяк, архитектура, модель — называйте как хотите. Зачем оно надо — сиё есть тайное знание, недоступное никому. Если отбросить шелуху, то более-менее постоянную информацию можно вытащить только из предметной области. Предметная область не есть деятельность заказчика. Предметная область — само поле игры. Заказчик может выделываться как хочет, хоть в берцах с бантиками — предметной области на него глубоко всё равно. Самое смешное, что сам заказчик довольно часто не пытается ничего узнать о правилах игры — ибо а) и так намальна б) он весь уникальный и создаёт нечто революцыонное в) для этой муйни есть всякие бухгалтера и юристы, не мешайте пилить бабло.

Дальше, если у вас есть модель предметной области — у вас есть основные сущности, зависимости, правила и т.п. Процентов на 90 эта информация будет совпадать с моделью БД, если конечно вы не используете БД только как хранилище.

Дальше вам придётся каким-то боком преобразовать модель к виду, который совместим с требованиями заказчика, определить базовые интерфейсы (если CRUD не хватает), и собсно напоследок — реализовать правила что хочет заказчик. Поскольку правила работают через интерфейсы и работают поверх общей модели — шансов поломать что-либо у вас меньше на порядки.

На практике оно конеш выглядит совсем-совсем не так — нюансы, пнимаешь. Но начинать с этого можно.

Any comments?

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

S>Не с той стороны мыслите Смысл такого разделения — защита _модели_ от требований заказчика. Начнёте смещивать — закончите реализацией конкретных требований конкретных дядей.

Хороший подход А как быть, если тебе деньги платят именно за реализацию конкретных требований конкретных дядей? Говорить, что их требования потребуют изменения модели, и поэтому реализованы не будут?

S>Даже тот примитив что я описал уже явно декларирует, что конкретные правила — проблема реализации и заказчика, системе глубоко всё равно, как эти правила будут считаться — любой расколбас не должен (в идеале) пролазить дальше основных интерфейсов.

Ну если он может быть реализован на основании тех интерфейсов, то да, модель не затронется. Что делать, если интерфейс модели тех самых "любимых номеров" не содержит, а заказчик хочет через 2 недели запустить маркетинговую акцию с этими номерами, и биллинг должен быть готов к тому времени? предположим, вы начальник ИТ отдела сотового оператора, ПО у вас собственной разработки


S>Слуште, давайте отойдём от аналогий с инженерными проектами — там не так уж и много простора для фантазии, очень многое оговорено стандартами/законами материального мира. Почему-то не попадались самолёты, что схлопываются в полёте из-за остатка юнит-теста парковки в ангар В программных продуктах с точностью до наоборот — вплоть до совмещения авиасортира с навигационным оборудованием. Связность компонентов на порядки выше, поскольку исправить очень дёшево, никто не заморачивается интерфейсами и разделением, практически любой компонент может поломать систему, но это не страшно ибо чинится на месте и т.п.

Я аналогию возводил к постановке задачи — там на мой взгляд все так же, требования никак архитектуру под собой не подразумевают. Есть данные о скорости, дальности полета, грузоподъемности итд — а сколько крыльев и двигателей, и какие они будут — не важно. Лишь бы ТТХ соблюдалось.

Но если хочется пофлеймить, то ИМХО особенности есть, но не принципиальные. Вы по NG никогда тайны авиакатастроф не смотрели? Самолеты падают из-за отказа маленьких деталей типа задвижки люка, помню даже интересный случай — из-за замерзания гидравлического клапана у пилота получалась инверсия управления.


S>>А все процессы разарботки типа ХП или RUP — это всего лишь способы организации взаимодействия разработчиков, заказчика, руководства, способы формализации процесса, документирования итд.. Если никто не знает, с какой стороны подходить к решению задачи — по никакой процесс не поможет.

S>Ну, собсно это и спрашивалось с самого начала. Если качество выходного продукта не важно — то нет смысла говорить о архитектуре, требованиях, надёжности и т.п. С другой стороны несколько странно, что в методологии, которая по идее стержень проекта и главная надежда, можно рассматривать вопросы разработки со стороны снижения стоимости изменений, но не рассматривать вопросы надёжности, качества и всего такого. Это ведь тоже вопрос управления. Не появится ведь совершенная архитектура из ничего, верно? А если проектирование ещё и мешает процессу разработки — то точно не появится
Угу, методология — надежда заказчика получить результат.

S>>ХП кстати, дает больше других — там говорится — берем требования, реализуем самым простым образом.
S>Ога. Получаем быстро и сердито штуку, сильно заточенную под конкретный набор юз-кейсов. Изменение в логике, которые по идее могли быть изолированы в одном методе, расползаются по всему проекту. Но это не страшно, ибо после вкуривания конспекта шаманских обрядов нам уже глубоко пофиг, что и как чинить Всю ответственность — на заказчика ибо сам виноват — сам выбрал таких разработчиков. Just do 'em all

no comments, ибо непонятна посылка. Если ХП применять по всем правилам, то не будет расползания логики по всему проекту, так как это нетестируемо. В любом случае, главнее профессионализм людей, чем используемая методология. Другое дело, что профессионализм и методология кореллированы между собой, начинающая команда скорее всего не использует никакой процесс, в опытной скорее всего какой-то процесс поставлен.


S>>То есть есть, с чего начать. Хотя, все равно кто-то должен принять принципиальные решения о платформе, языке, количестве слоев итп. Можно конечно не иметь никакого опыта вообще — но это какой-то совсем крайний случай Все таки, архитектура вырастает из опыта разработчиков.

S>Начать можно с очень и очень многого. Самый примитив — почитать старых умных товарищей, что жили в доисторические времена, когда даже методологий не было и попробовать подумать головой. Чтобы система долго-долго жила и работала, нужен какой-никакой костяк, архитектура, модель — называйте как хотите. Зачем оно надо — сиё есть тайное знание, недоступное никому.

Это как раз опыт. Либо свой, либо приобретенный из книг.


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

Мне честно говоря непонятно ваше стремление говорить заказчику, что и как надо делать. Пусть даже на основании вашего более глубокого знания предметной области.


S>Самое смешное, что сам заказчик довольно часто не пытается ничего узнать о правилах игры — ибо а) и так намальна б) он весь уникальный и создаёт нечто революцыонное в) для этой муйни есть всякие бухгалтера и юристы, не мешайте пилить бабло.

S>Дальше, если у вас есть модель предметной области — у вас есть основные сущности, зависимости, правила и т.п. Процентов на 90 эта информация будет совпадать с моделью БД, если конечно вы не используете БД только как хранилище.

S>Дальше вам придётся каким-то боком преобразовать модель к виду, который совместим с требованиями заказчика, определить базовые интерфейсы (если CRUD не хватает), и собсно напоследок — реализовать правила что хочет заказчик. Поскольку правила работают через интерфейсы и работают поверх общей модели — шансов поломать что-либо у вас меньше на порядки.

Пусть будет так. А о чем мы спорим?

S>Пусть будет так. А о чем мы спорим?

А хто его знает... выдохлись товарищи... надо сразу было к наездам на конкретные методологии переходить и троллей приманивать. Хз-хз....

S>Хороший подход А как быть, если тебе деньги платят именно за реализацию конкретных требований конкретных дядей? Говорить, что их требования потребуют изменения модели, и поэтому реализованы не будут?
...
S>Мне честно говоря непонятно ваше стремление говорить заказчику, что и как надо делать. Пусть даже на основании вашего более глубокого знания предметной области.

Да ни боже мой! Оно мне надо — рассказывать заказчику про его работу?
Мне кажется естественным когда заказчик понимает чего он хочет и понимает во что ему и разработчикам становятся его _необоснованные_ прихоти. Замечу, по конкретным проблемам непонимания никогда не возникает — это надо, это укладывается в логику — сделаем! На абстрактные "хацю" не стоит подписываться — себе дороже.

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

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

Да пребудут с вами компромиссы, в общем

S>Ну если он может быть реализован на основании тех интерфейсов, то да, модель не затронется. Что делать, если интерфейс модели тех самых "любимых номеров" не содержит, а заказчик хочет через 2 недели запустить маркетинговую акцию с этими номерами, и биллинг должен быть готов к тому времени? предположим, вы начальник ИТ отдела сотового оператора, ПО у вас собственной разработки.

В описанном сценарии сама идея правил рассчёта уже есть. Остаётся реализовать конкретное правило. Что совсем не просто. Да, здесь будут грабли. Но остальную систему они не затронут.

Если надо прям щас — IT-отдел тупо пишет новый класс FavoriteNumberDiscount/хранимку/представление — где оно там считается, регает как новое правило, прогоняет тесты, штампуется грязный гуй с подхватыванием автоматом. Это если рассчёт идёт офлайном. Если рассчёт идёт в процессе регистрации и требователен к ресурсам — добавляется реальная попа с перебалансировкой индексов по таблицам или с развёртыванием аппсерверов из резерва — что дешевле.

Такая фигня не готовится за две недели, ибо 2 недели — это только подписание бумажек (даже не написание). Развёртывание на серверах/подготовка кампании/печать буклетов/предизайн рекламы — примерно месяц-полтора (я оптимистичен).
А вообще пример не совсем корректен — на горячих узлах массового биллинга не до красявости архитектуры.

S>Я аналогию возводил к постановке задачи — там на мой взгляд все так же, требования никак архитектуру под собой не подразумевают. Есть данные о скорости, дальности полета, грузоподъемности итд — а сколько крыльев и двигателей, и какие они будут — не важно. Лишь бы ТТХ соблюдалось.

Ну... не совсем так в общем.
1. Риски, вложения и материальная ответственность на порядки порядков выше. А общая сложность сопоставима со средним софтварным проектом.
2. Лётные характеристики заказчиков не колышат. Точнее есть определённые пороговые значения (которые определяются классом создаваемой техники, а не заказчиком) и экономическая эффективность — вот она-то заказчиков и интересует.
3. В авиастроении нет крупных заказчиков, чтобы создавать штучный самолёт с рюшечками, тонированными жалюзями на движках и "чтоб подпрыгива в такт рингтону". Есть мейнстрим. Он проектируется КБ компании (аутсорсинг на таких тяжёлых проектах очень недешёвая штука, особенно в плане последствий). Затем проект по отдельным системам обкатывается на производственной базе компании (заметьте, КБ учитывает её возможности). Затем куча испытаний/доделок (если где и можно говорить об итеративности — так это здесь). Но всё это выполняется на базе мощностей одной компании/одного холдинга. И только после выхода в серию слетаются заказчики — чтобы попросить нарисовать свой лейбл и салфеточки на спинки повесить. Не более того.

S>Угу, методология — надежда заказчика получить результат.
Убили вы мои надежды ;(

S>no comments, ибо непонятна посылка. Если ХП применять по всем правилам, то не будет расползания логики по всему проекту, так как это нетестируемо.
Мне казалось, что логика не должна расползаться по несколько другим причинам... Кстати расползание логики не всегда очевидно. Ибо тестируются отдельные сценарии, а связи между ними — не такая уж и очевидная штука.

S>В любом случае, главнее профессионализм людей, чем используемая методология. Другое дело, что профессионализм и методология кореллированы между собой, начинающая команда скорее всего не использует никакой процесс, в опытной скорее всего какой-то процесс поставлен.
Золотые ваши слова, Юрий Венедиктович (с)
Собсно если помните я и начал с вопросов, которые возникли при попытке забуриться детально в матчасть.

P.S. Надо менять ник. На что-то, что с Ъ начинается, наверное...

P.P.S. Да, TOGAF и еже с ним несколько зациклены на архитектуре бизнес-процессов или мне так показалось?

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

S>Т.е. архитектура — есть функция требований. Это аксиома.

В случае продуктов, рассчитанных на массовый рынок, я бы сказал так. Функция от требований — UI. Функция от всех аспектов UI — архитектура. А то бывает так, что продукт выполняет все требования и грамотно сархитектурен (легко понять, легко развивать, не тормозит и пр.), но UI гавняный, а когда на следующей итерации улучшение UI превращается в требование, начинаются песни "невозможно архитектурно". Если же разработку UI вынести в отдельный процесс, более приоритетный, чем архитектура, улучшение происходит более плавно.

А>В случае продуктов, рассчитанных на массовый рынок, я бы сказал так. Функция от требований — UI. Функция от всех аспектов UI — архитектура. ... Если же разработку UI вынести в отдельный процесс, более приоритетный, чем архитектура, улучшение происходит более плавно.

Гыг... А умные люди пишут всякие книжки, MVC, MVP всякие придумывают... Проще надо быть, проще

Ну вот смотрите как это поставлено у нас. Как обозвать не знаю. Пусть будет MyMVC (скромненько, но со вкусом (с)). Применяется для большинства десктопных приложений, винформс/впф — не критично. Поехали (в цитату оформил чтоб отделить — моё это, моё ).

[skipped]
6 основных частей:

Локальный кэш. Отражает модель данных для конкретного приложения (с тем что лежит в СУБД очень часто имеет мало общего), кэширует данные, проводит их базовую валидацию. Валидация проходит в момент изменения если что-то не так — бросается исключение. В идеале любая ошибка будет обнаружена сразу, а не при сохранении, и искать её причину не придётся. Также мы используем кэш для сокращения нагрузки на сеть и сервер — вместо сотен мелких запросов в минуту получается пара-тройка больших. Мелкие и большие — слегка условно, по стоимости каждого разницы практически не наблюдается.

DAL. Обслуживает все запросы к СУБД. Поскольку кэш про DAL ничего не знает, может быть заменён в любой момент.

Контроллеры. Каждый из них хранит состояние (выделенные элементы и т.п.), выставляет наружу методы-действия и информацию о том, можно ли дёргать конкретный метод в конкретном состояни или нет. Основная магия живёт здесь

Точка доступа. Обычно это простой static class, через свойства которого можно образащаться к кэшу/DAL/контроллерам.

Гуй. По функционалу разбивается небольшое число областей. Обычно мы стараемся сделать так, чтобы одному контроллеру соответствовал 1 workspace. Каждая область обычно реализуется как user control (но это как повезёт ). У каждой области есть свой набор BindingSource|CollectionViewSource, напрямую прибинденный к кэшу. К одному и тому же набору сущностей может быть прибиндено несколько источников — почему бы и нет? Поскольку контроллеры ничего не знают о гуе — можно использовать любой фреймворк/контролы/компоновку/etc

Code behavior. Легковесная обёртка, которая в ответ на события гуя дёргает контроллер и в ответ на изменение состояния контроллера изменяет гуй.

Естественно, я здесь не привожу особенностей реализации — пальцы отвалятся. Интересно — продолжим.

Слегка отличается от "разработку UI вынести в отдельный процесс, более приоритетный", ага? Как думаете, какое приложение проживёт дольше и потребует меньше изменений при самых бредовых требованиях?

P.S. Чем ещё меряться будем?

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

А>>В случае продуктов, рассчитанных на массовый рынок, я бы сказал так. Функция от требований — UI. Функция от всех аспектов UI — архитектура. ... Если же разработку UI вынести в отдельный процесс, более приоритетный, чем архитектура, улучшение происходит более плавно.

S>Гыг... А умные люди пишут всякие книжки, MVC, MVP всякие придумывают... Проще надо быть, проще
...
S>Слегка отличается от "разработку UI вынести в отдельный процесс, более приоритетный", ага? Как думаете, какое приложение проживёт дольше и потребует меньше изменений при самых бредовых требованиях?

Я искренне люблю MVC, но это не панацея. Простой пример: V оказывается настолько сложно, что у него появляется своя внутренняя архитектура. Допустим, есть данные в M, которые надо показать как чарт. Что будем делать? Купим компонент? Используем Excel через OLE Automation? Набросаем сами? Во, сколько вариантов! И попробуй узнай, на каком из них надо остановиться, пока не обдумаешь интерфейс во всех деталях, и не обкатаешь его на фокус-группе, хотя бы из коридора.

Другой пример, из жизни. Юзера говорят — хотим интерфейс, как в MSO. На дворе — 2002 год (? Точно не помню, плюс-минус год). Дотнет уже есть, но библиотек к нему, дающих такой интерфейс, нет. Infragistics то ли еще не появился, то ли в этой версии страшен, как смертный грех. Приложение создавалось без учета этого пожелания, на pure C#, потому, что архитектор так захотел (а хрен ли — требования-то все выполняются, и более-менее точно). На очередном этапе конкуренты все встроили MSO look like, кто — за счет BCG, кто — компонентами к Дельфе. Пришел черед дотнетной аппликухи, MSO-подобие из вариации на тему ГУЯ превратилось в требование. Начались песни "архитектура не позволяет". И сколько-то там еще лет не позволяло. А поговорили бы с юзверями, перед тем, как проектировать архитектуру, показали им наброски, услышали — "ребята, сделайте нам красиво, как в ворде", глядишь — и до .Net 2.0 сидели бы на MFCях.

Трямс Анониму.

А>Я искренне люблю MVC, но это не панацея.
+5 за понимание. То что я привёл — это вообще хз что — эдакая помесь мвц с тушканодинозавром. Никто специально не изобретал — шамо приползло (с).

A>Простой пример: V оказывается настолько сложно, что у него появляется своя внутренняя архитектура. Допустим, есть данные в M, которые надо показать как чарт. Что будем делать? Купим компонент? Используем Excel через OLE Automation? Набросаем сами? Во, сколько вариантов! И попробуй узнай, на каком из них надо остановиться, пока не обдумаешь интерфейс во всех деталях, и не обкатаешь его на фокус-группе, хотя бы из коридора.

Хз. Этот вопрос более к управлению рисками имхо — т.е. мы имеем такие-то грабли, последствия такие-то, вероятность такая-то, стоимость исправления такая-то. Всегда идти на поводу у тов пользователей и делать сегодня сайт а завтра пылесос... Тем не менее в вашем примере я бы постарался изолировать проблему — чтобы её решение не затрагивало остальную часть системы. Будете смеяццо, но в принципе решаемо даже при описанном подходе — отображение живёт в UI и code behavior — всё остальное не ломается (я не говорю о сервере, ему вообще параллельно). Excel кстати как ActiveX компоненту можно захостить... //ужас-ужас...

А>Другой пример, из жизни. Юзера говорят — хотим интерфейс, как в MSO. На дворе — 2002 год...

Опять-таки — это больше проблема управления рисками чем проблема некорректного проектирования архитектуры. Как вы там сейчас с 2к7-м офисом? Его гуй тоже эмулировать приходится? Соболезную — с такой жосткой конкуренцией, чтобы всё решалось градиентом тулбаров, не сталкивался.

dmoz пишет:
>
> V_S>Тут, видишь ли, нехилая проблема заключается в том, что 99%
> *менеджеров*, занимающихся планированием продаж и производства этих
> самых табуреток, /совершенно наплевать/ на инженерные аспекты реализации
> табуретки. У них, как правило, основные требования — "Дешевле! Еще
> дешевле! Быстрее! Еще быстрее! Прямо сейчас, а еще лучше — еще вчера!
> Главное — продать! Быстрее!". В таких условиях, разумеется, берем абы
> как сделанные заготовки, и — сколачиваем их гвоздями на скорую руку....
> Ну и получаем табуретку соответствующего качества.
>
> Эти требования не придуманы просто так, а продиктованы потребностями
> рынка. Проблема скорее в отсутствии понимания инженерами потребностей
> бизнеса (таких понимающих, к сожалению, единицы), и, как следствие,
> отсутствие альтернативных предложений, вместо тупой поставки кривой
> табуретки.
В итоге, плюнул я на всех нонешних делателей мебели и сам ее делаю для
себя. Все одно они мебель нынче делают не лучше, чем мы проги (как же,
потребности рынка: "мы уже продали, а вы еще не начинали?").

>
> Инженерам очень не помешало бы иногда бывать в шкуре тех, кто продвигает
> продукт на рынке
Я бы еще уточнил, "втюхивает", "впаривает", "вдувает" и священная корова
"откатывает" — да, это не художественные гиперболы — это реальная
терминология.

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

S>Хз. Этот вопрос более к управлению рисками имхо — т.е. мы имеем такие-то грабли, последствия такие-то, вероятность такая-то, стоимость исправления такая-то. Всегда идти на поводу у тов пользователей и делать сегодня сайт а завтра пылесос... Тем не менее в вашем примере я бы постарался изолировать проблему — чтобы её решение не затрагивало остальную часть системы. Будете смеяццо, но в принципе решаемо даже при описанном подходе — отображение живёт в UI и code behavior — всё остальное не ломается (я не говорю о сервере, ему вообще параллельно). Excel кстати как ActiveX компоненту можно захостить... //ужас-ужас...

S>Опять-таки — это больше проблема управления рисками чем проблема некорректного проектирования архитектуры. Как вы там сейчас с 2к7-м офисом? Его гуй тоже эмулировать приходится? Соболезную — с такой жосткой конкуренцией, чтобы всё решалось градиентом тулбаров, не сталкивался.

Моя формула девелопмента: требования >> UI >> архитектура >> код. Значок >> значит одновременно две вещи: Направление Движения и Намного Более Высокий Приоритет. А управление рисками — часть управления проектами.

Здравствуйте, Аноним, Вы писали:

А>Моя формула девелопмента: требования >> UI >> архитектура >> код. Значок >> значит одновременно две вещи: Направление Движения и Намного Более Высокий Приоритет. А управление рисками — часть управления проектами.

Таак... что-то я не понимаю... у вас код приоритетней всего? Кодинг как самоцель?

Завидую глубине и фундаментальности ваших заблуждений Хотя... Что такое у вас "архитектура" — может у нас просто несовпадение в терминологии?

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

S>Здравствуйте, Аноним, Вы писали:

А>>Моя формула девелопмента: требования >> UI >> архитектура >> код. Значок >> значит одновременно две вещи: Направление Движения и Намного Более Высокий Приоритет. А управление рисками — часть управления проектами.

S>Таак... что-то я не понимаю... у вас код приоритетней всего? Кодинг как самоцель?

В физике я встречал такое обозначение: "при a >> b". Это значило, что а не просто больше, а намного больше b. "Намного" взято в курсив как нестрогий термин.

Таким образом, начинать надо со сбора требований. (Частный случай: интерфейс или архитектура являются требованиями сами по себе). Затем — разработать интерфейс, который решает ВСЕ требования. И только потом — думать об архитектуре. А уж код должен соответствовать всем документам, что были написаны в ходе первых трех этапов.

S>Завидую глубине и фундаментальности ваших заблуждений Хотя... Что такое у вас "архитектура" — может у нас просто несовпадение в терминологии?

Не глуюже, чем "меньше" с "больше" перепутать.

Упс... по ходу иронию восприняли как наезд... Сорри.
С другой стороны — надо ж как-то поднимать тему.

А>>>Моя формула девелопмента: требования >> UI >> архитектура >> код. Значок >> значит одновременно две вещи: Направление Движения и Намного Более Высокий Приоритет. А управление рисками — часть управления проектами.
...
А>В физике я встречал такое обозначение: "при a >> b". Это значило, что а не просто больше, а намного больше b. "Намного" взято в курсив как нестрогий термин.

Так у вас "Намного Более Высокий Приоритет" или "а не просто больше, а намного больше b"? Вы уж определитесь пожалуйста.

А>Таким образом, начинать надо со сбора требований. (Частный случай: интерфейс или архитектура являются требованиями сами по себе). Затем — разработать интерфейс, который решает ВСЕ требования. И только потом — думать об архитектуре. А уж код должен соответствовать всем документам, что были написаны в ходе первых трех этапов.

Откройте для себя водопадную модель уже что ли
Ворос на засыпку. Если уж у вас гуй определяет архитектуру системы (если мы под архитектурой понимаем одно и то же) — то к чему приведёт необходимость использовать другие отчёты/список вместо грида/дублирование вызовов через меню/кнопки?

P.S. Если вы УЖЕ решили все требования без архитектуры — зачем она вам теперь? Избавьтесь от неё

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

S>Упс... по ходу иронию восприняли как наезд... Сорри.
S>С другой стороны — надо ж как-то поднимать тему.

А>>>>Моя формула девелопмента: требования >> UI >> архитектура >> код. Значок >> значит одновременно две вещи: Направление Движения и Намного Более Высокий Приоритет. А управление рисками — часть управления проектами.
S>...
А>>В физике я встречал такое обозначение: "при a >> b". Это значило, что а не просто больше, а намного больше b. "Намного" взято в курсив как нестрогий термин.

S>Так у вас "Намного Более Высокий Приоритет" или "а не просто больше, а намного больше b"? Вы уж определитесь пожалуйста.

Слюшай, дарагой, посмотри на значок, да? Вот какой канэц у этого значка бальшой, так и прыоритет с этого канца бальшой, савсэм бальшой. Огромный прыоритет, во какой! Так понял, да?

А>>Таким образом, начинать надо со сбора требований. (Частный случай: интерфейс или архитектура являются требованиями сами по себе). Затем — разработать интерфейс, который решает ВСЕ требования. И только потом — думать об архитектуре. А уж код должен соответствовать всем документам, что были написаны в ходе первых трех этапов.

S>Откройте для себя водопадную модель уже что ли
S>Ворос на засыпку. Если уж у вас гуй определяет архитектуру системы (если мы под архитектурой понимаем одно и то же) — то к чему приведёт необходимость использовать другие отчёты/список вместо грида/дублирование вызовов через меню/кнопки?

Не обязательно ГУЙ. Может и просто УЙ. Поручик, молчать: интерфейс пользователя может быть не только графическим.

S>P.S. Если вы УЖЕ решили все требования без архитектуры — зачем она вам теперь? Избавьтесь от неё

"Что это шумит? Во-до-пад!" Если интерфейс "решает" (как-то не по-русски, может стоило написать "разрешает от"?) требования (отвечает на вопрос, как ПО должно взаимодействовать с пользователем, чтобы требования были "решены", и чтобы оптимально, и универсально, и расширябельно), то архитектура "решает" интерфейс (отвечает на вопрос, как должен быть написан код, чтобы он давал такой интерфейс, и чтобы понятно, и удобно, и нетрудоемко, и, опять же, универсально и пр.).

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

Список вместо грида — это как? Откуда такое странное требование? Если юзеры видели наброски интерфейса со списком и с гридом, и выбрали с гридом, то такое требование не появится. Если не видели, а дизайнер об этом не подумал, то дизайнер плохой, а что будет с архитектурой — не знаю. Возможно, придется и менять, но не думаю, что много.

Дублирование вызовов через меню/кнопки — это третий случай. Это дальнейшее развитие интерфейса, и хорошая архитектура делается с учетом возможности в будущем такого расширения. И она не меняется. Просто в OnMenu() появляется новый Case, очень грубо говоря.

Аноним, если вы сознательно троллите — так и напишите — я не буду разговаривать с вами как с адекватным человеком. Если нет — постарайтесь читать то что вам пишут, ладно?

S>>Так у вас "Намного Более Высокий Приоритет" или "а не просто больше, а намного больше b"? Вы уж определитесь пожалуйста.
А>Слюшай, дарагой, посмотри на значок, да? Вот какой канэц у этого значка бальшой, так и прыоритет с этого канца бальшой, савсэм бальшой. Огромный прыоритет, во какой! Так понял, да?

Тут у нас обычное взаимонедопонимание. У меня "одновременно две вещи: Направление Движения и Намного Более Высокий Приоритет" воспринимается как "следующее приоритетней предыдущего". А "а не просто больше, а намного больше b" воспринимается соответственно наоборот. Замяли, ок?

А>"Что это шумит? Во-до-пад!"
A> Если интерфейс "решает" (как-то не по-русски, может стоило написать "разрешает от"?) требования (отвечает на вопрос, как ПО должно взаимодействовать с пользователем, чтобы требования были "решены", и чтобы оптимально, и универсально, и расширябельно), то архитектура "решает" интерфейс (отвечает на вопрос, как должен быть написан код, чтобы он давал такой интерфейс, и чтобы понятно, и удобно, и нетрудоемко, и, опять же, универсально и пр.).

Кажется, у нас разное восприятие окружающего мира. И языки. И страны. И планеты разные наверно... Поверьте, ирония и наезд — не синонимы. В общем регайте UIDD(tm) (UI-Driven-Development) и в проповедники. Агилисты вас как своего примут.

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

S>Аноним, если вы сознательно троллите — так и напишите — я не буду разговаривать с вами как с адекватным человеком. Если нет — постарайтесь читать то что вам пишут, ладно?

1. Охота на троллей для меня — как охота на ведьм. Казалось бы, думаешь, что человек бесцельно жрет твое внимание — так проходи мимо, но нет, надо обязательно гавкнуть. А те, кто гавкает, обычно такого ума, что все, что не понимают, записывают в троллинг. А понимают они мало что, в силу той же причины. Вас в виду не имею, а так, объясняю свою позицию. Вы пошутили — ну, я пошутил в ответ. Но в главном — как вы это назвали, UIDD — я серьезен.
2. Можно показать на то, что я, по-вашему, невнимательно прочитал? Я перечитаю.

S>>>Так у вас "Намного Более Высокий Приоритет" или "а не просто больше, а намного больше b"? Вы уж определитесь пожалуйста.
А>>Слюшай, дарагой, посмотри на значок, да? Вот какой канэц у этого значка бальшой, так и прыоритет с этого канца бальшой, савсэм бальшой. Огромный прыоритет, во какой! Так понял, да?

S>Тут у нас обычное взаимонедопонимание. У меня "одновременно две вещи: Направление Движения и Намного Более Высокий Приоритет" воспринимается как "следующее приоритетней предыдущего". А "а не просто больше, а намного больше b" воспринимается соответственно наоборот. Замяли, ок?

Лол. Ну да, недопонимание. Я имел в виду, что поскольку каждое следующее менее приоритетное, а двигаться надо от менее приоритетных вещей к более приоритетным, то значок еще и показывает направление движения. В общем, бывает. Проехали.

А>>"Что это шумит? Во-до-пад!"
A>> Если интерфейс "решает" (как-то не по-русски, может стоило написать "разрешает от"?) требования (отвечает на вопрос, как ПО должно взаимодействовать с пользователем, чтобы требования были "решены", и чтобы оптимально, и универсально, и расширябельно), то архитектура "решает" интерфейс (отвечает на вопрос, как должен быть написан код, чтобы он давал такой интерфейс, и чтобы понятно, и удобно, и нетрудоемко, и, опять же, универсально и пр.).

S>Кажется, у нас разное восприятие окружающего мира. И языки. И страны. И планеты разные наверно... Поверьте, ирония и наезд — не синонимы. В общем регайте UIDD(tm) (UI-Driven-Development) и в проповедники. Агилисты вас как своего примут.

Зачем мне его регать, и зачем что-то проповедовать? У меня другой бизнес. Я объяснил свою позицию, почему я считаю, что UI надо заниматься до архитектуры, так? Вы вопросы задали — я ответил. Сделал все, что мог. Не могли бы теперь вы объяснить свою позицию? Согласны, не согласны, почему?

Здравствуйте, Аноним, Вы писали:

А>Лол. Ну да, недопонимание. Я имел в виду, что поскольку каждое следующее менее приоритетное, а двигаться надо от менее приоритетных вещей к более приоритетным, то значок еще и показывает направление движения. В общем, бывает. Проехали.

Тьфу ты, черт! Теперь я сам попутал. От более приоритетных вещей надо двигаться к менее приоритетным. Просто по определению. Надеюсь, теперь тема стрелок окончательно исчерпана.

Здравствуйте, <Аноним>, Вы писали:

А>Моя формула девелопмента: требования >> UI >> архитектура >> код.
Согласен. Именно к этому я сейчас и прихожу.

О первостепенной важности Требований хорошо сказал IT Re[35]: DTO внутри BusinessObject

Автор: IT
Дата: 16.01.07

(в конце поста. У него был еще один пост на эту тему, но лень искать).
О высокой важности UI хорошо написали 37 Signals (авторы RubyOnRails) в своей книге Getting Real (в этой книге много и других очень грамотных идей).
О требованиях к архитектуре хорошо написал Ричардом П. Гэбриелом в принципах (распечатал и повесил перед глазами). Кратко: архитектура должна быть простой.
О требованиях к коду хорошо написал МкКоннел в книге Совершенный код

Автор(ы): С. Макконнелл
Издательство: Питер
Цена: 577р.

Более 10 лет первое издание этой книги считалось одним из лучших практических руководств по программированию. Сейчас эта книга полностью обновлена с учетом современных тенденций и технологий и дополнена сотнями новых примеров, иллюстрирующих

. Кратко: самая важная характеристика (корректно работающего) кода -- читаемость.

СУВ, Aikin

А>>Моя формула девелопмента: требования >> UI >> архитектура >> код.
A>Согласен. Именно к этому я сейчас и прихожу.

О Вас двое

Aikin, спасибо за ссылки на пост IB и на Гэбриэла. Оказывается, я скорее сторонник MIT. За "Неправильный дизайн категорически запрещён." готов ставить памятник.

Вообще сам спор бессмысленен — всё равно что сравнивать превосходство тактики над стратегией. Попытаюсь держаться корректно, хотя когда речь идёт о несовпадении базовых принципов всё неизменно скатывается к разборкам в духе "атцтой твой Гэбриэл". Попробуем так не говорить

Может, дело именно в отношении к коду и к себе. Я ценю своё время. Я стараюсь не делать временных решений, ибо прекрасно понимаю, что их придётся исправлять либо мне, либо, что ещё хуже — другим людям, за что мне будет сильно стыдно. Я не могу себя убедить в том, что построенная на краткосрочных требованиях архитектура будет красивой и стабильной. Посему с лёгкой долей иронии отношусь к агилистам вообще и к подходу в стиле "спроектируем гуй — дальше будем думать о архитектуре и коде".

Ребят, если для вас не критично внутреннее устройство программы, если не волнует как долго оно проживёт или сколько будет стоить её саппорт (особенно другой командой) — тут и говроить не о чем — agile будет и приятней и эффективней.

Просто без качественной отстоявшейся архитектуры не будет ни долгой жизни программы, ни беспроблемного взаимодействия с приложениями-клиентами, ни кошерной декомпозиции ни много чего ещё. Что называть "качественной отстоявшейся архитектурой" — другой вопрос. Если смотреть со стороны методологий есть три подхода: анализ требований, забивание на архитектуру (ибо и без неё хорошо) и проектирование от предметной области. Более-менее объективные критерии наблюдаются только в последнем варианте, впрочем к самому DDD тоже есть куча вопросов, начиная с того что "DDD — это не методология, а скорее стиль мышления" и заканчивая любовью к орм-ам и постоянными попытками протянуть внуть доменной модели бизнес-логику.

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

Ребят, вот вы утверждаете, что приходите к архитектуре через гуй и требования. Приведите пример, что у вас получается в результате — чтобы было о чём предметно поговорить. Потому что иначе мы так и будемгнуть друг перед другом пальцы и гнать всякую пургу (я и о себе тоже, не обижайтесь ).

Мои извинения Аноним'у, слегка отвык от адекватных собеседников... ужс-ужс...

А>2. Можно показать на то, что я, по-вашему, невнимательно прочитал? Я перечитаю.
Изначально имелось ввиду моё непонимание стралочек (уже замяли ). Но можно притянуть за уши и мой коммент насчёт изоляции проблем с UI:

Тем не менее в вашем примере я бы постарался изолировать проблему — чтобы её решение не затрагивало остальную часть системы. Будете смеяццо, но в принципе решаемо даже при описанном подходе — отображение живёт в UI и code behavior — всё остальное не ломается (я не говорю о сервере, ему вообще параллельно). Excel кстати как ActiveX компоненту можно захостить... //ужас-ужас...

Просто в моём восприятии конечный продукт — очень сложная штука, и внешние интерфейсы — это нечто вроде вершины айсберга, которые не могут (да и не должны) определять логику работы. Согласитесь, при таком подходе кажется странным проектировать систему на основе требований. Ведь требования в основе своей есть описание тех самых внешних интерфейсов, и никакой значимой информации о внутренностях "идеальной системы" из них не вытрясешь.

Ну ведь глупо рассматривать горы функционала, внутренние структуры данных, составные части, ту же многозвенку и много чего ещё со стороны потребностей пользователя, точнее со стороны взаимодействия с пользователем. Оно ему вообще ведь не надо. 1с хватит. Или ацесса. Или фокспро. Или вообще экселя.

Кстати на последнем вообще крышесносящие штуки творятся — вплоть до многопользовательского составления расписаний. Из того что приходилось делать самому — сводка по штатному расписанию, построение/сортировка/фильтрация взвешенных графов по матрицам и построение дендрограмм (только не спрашивайте что это такое и как оно делается — мне до сих пор тот ужас вспоминать не хочется). Но это так, офтоп

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

А>>>Моя формула девелопмента: требования >> UI >> архитектура >> код.
A>>Согласен. Именно к этому я сейчас и прихожу.
S>О Вас двое
Заметь я еще не преверженец этой идеи, но жизнь и опыт приводит именно к ней.

S>Aikin, спасибо за ссылки на пост IT и на Гэбриэла.
Не за что.

S>За "Неправильный дизайн категорически запрещён." готов ставить памятник.
Что есть правильный/неправильный дизайн? Продай пару пробных камней.

S>Может, дело именно в отношении к коду и к себе. Я ценю своё время. Я стараюсь не делать временных решений, ибо прекрасно понимаю, что их придётся исправлять либо мне, либо, что ещё хуже — другим людям, за что мне будет сильно стыдно.
Аналогично, коллега. Но вышеописанная цепочка ни в коем случае не провоцирует временные решения. Она просто ставит архитектуру на третье место (код (т.е. поспешные решения) имеет еще меньший приоретет).

Если перефразировать эту цепочку, то будет следующее:
1) Что должно делать приложение
2) Что пользователи будут видеть
3) Насколько сложно вносить в приложение изменения
4) Насколько сложно вносить в приложение изменения (ч2)

Ставить 3-4) выше 2), а уж тем более 1) ... (продолжишь сам).



S> Я не могу себя убедить в том, что построенная на краткосрочных требованиях архитектура будет красивой и стабильной.
Красивой -- легко (это моя цель).
Стабильной? НИКОГДА! НИ ПРИ КАКОМ ПОДХОДЕ! Невозможно предсказать требования. Это нужно написать на стене красной краской: Невозможно предсказать требования.


Год назад я потратил дополнительное время (+30% времени таска) на реализацию очень удобной и красивой архитектуры для части системы. Вылизал ее.
Буквально через пол года заказчик упростил модель отображения этой части, отказался от ряда дополнительной информации.
Моя архитектура не подкачала -- адаптировалась под изменения, но стала слишком сложна для решаемой задачи. Стала "путаться под ногами".
3 месяца я поддерживал эту архитектуру, пока не решился и не выкосли ее нафиг, заменив на менее универсальную, но много более простую.

S>Где-то выше я приводил примитивнейший подход к разбиению клиента на отдельные блоки. К такому в принципе низзя прийти если танцевать от требований, интерфейса, критериев надёжности системы и всего прочего. Тем не менее, он работает и решает кучу проблем из коробки — в том числе и задачу разделения представления и логики работы клиента.
Хмм, есть мировые практики, опыт программистов, книжки по архитектуре... Почему мы должны нащупывать архитектуру как слепые котята? Мне нравится многослойная архитектура. Я ее и исползую.

S>Ребят, вот вы утверждаете, что приходите к архитектуре через гуй и требования. Приведите пример, что у вас получается в результате — чтобы было о чём предметно поговорить. Потому что иначе мы так и будемгнуть друг перед другом пальцы и гнать всякую пургу (я и о себе тоже, не обижайтесь ).
Я не робот чтобы работать по алгоритму "придти к архитектуре через гуй и требования". Процесс намного сложнее.
Можно сказать, что я решаю проблему комплексно (требования+UI+архитектура), что прохожу несколько циклов (требования->UI->архитектура->требования->UI->архитектура->требования->UI->архитектура->...) Но это все равно будет не всей правдой.

Правда находится в другой области: "требования приорететнее UI приорететнее архитектуры".

СУВ, Aikin

---

S> Посему с лёгкой долей иронии отношусь к агилистам вообще и к подходу в стиле "спроектируем гуй — дальше будем думать о архитектуре и коде".
Забудь про Aigle. Судя по всему ты не так его понял.

S>Ребят, если для вас не критично внутреннее устройство программы, если не волнует как долго оно проживёт или сколько будет стоить её саппорт (особенно другой командой) — тут и говроить не о чем — agile будет и приятней и эффективней.
Зачем кидаться пустыми и вкорне неверными фразами?

S>Просто без качественной отстоявшейся архитектуры не будет ни долгой жизни программы, ни беспроблемного взаимодействия с приложениями-клиентами, ни кошерной декомпозиции ни много чего ещё. Что называть "качественной отстоявшейся архитектурой" — другой вопрос. Если смотреть со стороны методологий есть три подхода: анализ требований, забивание на архитектуру (ибо и без неё хорошо) и проектирование от предметной области. Более-менее объективные критерии наблюдаются только в последнем варианте, впрочем к самому DDD тоже есть куча вопросов, начиная с того что "DDD — это не методология, а скорее стиль мышления" и заканчивая любовью к орм-ам и постоянными попытками протянуть внуть доменной модели бизнес-логику.
Бла-бла-бла и куча красивых лозунгов.

О — пошли аргументы Ничего, что чуть претасую порядок ответов?

S>>За "Неправильный дизайн категорически запрещён." готов ставить памятник.
A>Что есть правильный/неправильный дизайн? Продай пару пробных камней.

Имелось в виду противопоставление
"Простой дизайн немного лучше, чем правильный."
-и-
"Неправильный дизайн категорически запрещён."

Из этих двух утверждений я выберу именно второе. Про пример — пару страниц выше я приводил пример разбиения программы независимо от требований. Это разбиение будет долгим и стабильным и не зависит от технологий реализации. Это "правильный" дизайн. "Неправильный" дизайн — хардкодить в контроллере структуру гуя, или держать в нём классы из конкретного фреймворка (допустим, wpf commands) или вообще не выделять логику в отдельный класс, или держать её в обработчиках событий _отдельных_ контролов (как Аноним с OnMenu предлагал). Могу ещё — один и тот же пример подсовываю не из недостатка воображения, а чтобы не плодить сущностей.

S>> Я не могу себя убедить в том, что построенная на краткосрочных требованиях архитектура будет красивой и стабильной.
A>Красивой -- легко (это моя цель).
A>Стабильной? НИКОГДА! НИ ПРИ КАКОМ ПОДХОДЕ! Невозможно предсказать требования. Это нужно написать на стене красной краской: Невозможно предсказать требования.

Собсно топик и заводился ради вопроса "какого архитектура строится от требований — она ж не будет стабильной!" На шестой странице мне отвечают "Стабильной? НИКОГДА! НИ ПРИ КАКОМ ПОДХОДЕ!". Как забавно устроены люди... (с).

A>Если перефразировать эту цепочку, то будет следующее:
A>1) Что должно делать приложение
A>2) Что пользователи будут видеть
A>3) Насколько сложно вносить в приложение изменения
A>4) Насколько сложно вносить в приложение изменения (ч2)

A>Ставить 3-4) выше 2), а уж тем более 1) ... (продолжишь сам).

Вы идёте именно по тому пути, что я описал выше — строите архитектуру от предположений заказчика о требуемом функционале — кто вам виноват, что архитектура меняется вслед за требованиями? И это не основание кричать про "НИ ПРИ КАКОМ ПОДХОДЕ!".

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

A>Я не робот чтобы работать по алгоритму "придти к архитектуре через гуй и требования". Процесс намного сложнее.
A>Можно сказать, что я решаю проблему комплексно (требования+UI+архитектура), что прохожу несколько циклов (требования->UI->архитектура->требования->UI->архитектура->требования->UI->архитектура->...) Но это все равно будет не всей правдой.

A>Правда находится в другой области: "требования приорететнее UI приорететнее архитектуры".

И снова мы оба гнём пальцы. Сила — она в ньютонах Ну разверну я вашу цепочку как "архитектура приорететнее требований приорететнее UI". Что изменится? Хотите обсуждения — давайте конкретику.

S>>Ребят, если для вас не критично внутреннее устройство программы, если не волнует как долго оно проживёт или сколько будет стоить её саппорт (особенно другой командой) — тут и говроить не о чем — agile будет и приятней и эффективней.
A>Зачем кидаться пустыми и вкорне неверными фразами?

А это был disclaimer

S>>Просто без качественной отстоявшейся архитектуры не будет ни долгой жизни программы, ни беспроблемного взаимодействия с приложениями-клиентами, ни кошерной декомпозиции ни много чего ещё. Что называть "качественной отстоявшейся архитектурой" — другой вопрос. Если смотреть со стороны методологий есть три подхода: анализ требований, забивание на архитектуру (ибо и без неё хорошо) и проектирование от предметной области. Более-менее объективные критерии наблюдаются только в последнем варианте, впрочем к самому DDD тоже есть куча вопросов, начиная с того что "DDD — это не методология, а скорее стиль мышления" и заканчивая любовью к орм-ам и постоянными попытками протянуть внуть доменной модели бизнес-логику.
A>Бла-бла-бла и куча красивых лозунгов.

И снова мы гнём пальцы... Ну вот зачем вы так?

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

S>Собсно топик и заводился ради вопроса "какого архитектура строится от требований — она ж не будет стабильной!" На шестой странице мне отвечают "Стабильной? НИКОГДА! НИ ПРИ КАКОМ ПОДХОДЕ!". Как забавно устроены люди... (с).
Раз это главный вопрос топика, то поднимем его наверх.

Давай сначала уточним. Какая архитектура имеется ввиду?
Есть (утрированно) высокоуровневая, среднеуровневая, средненизкоуровневая, низкоуровневая, низконизкоуровневая, ... архитектура. По убыванию "уровня": разбивка на сборки, нэймспэйсы, классы, методы.
Чем выше находится конкретный элемент, тем сложнее его изменять, но, другой стороны, он меньше подвержен влиянию изменению требований.

Так вот. Стабилизировать разбиение на сборки и неймспэйсы в большинстве случаев удается. Классы и методы -- нет.

---

S>Имелось в виду противопоставление
S>"Простой дизайн немного лучше, чем правильный."
S>-и-
S>"Неправильный дизайн категорически запрещён."
В первом случае используются понятия "субъективно простой" и "субъективно правильный" дизайн. Найти (золотую) середину между ними можно.
Но в твоем утверждении используется абсолютное понятие "неправильный дизайн". Поэтому мой вопрос остается в силе

S>Из этих двух утверждений я выберу именно второе. Про пример — пару страниц выше я приводил пример разбиения программы независимо от требований. Это разбиение будет долгим и стабильным и не зависит от технологий реализации. Это "правильный" дизайн. "Неправильный" дизайн — хардкодить в контроллере структуру гуя, или держать в нём классы из конкретного фреймворка (допустим, wpf commands) или вообще не выделять логику в отдельный класс, или держать её в обработчиках событий _отдельных_ контролов (как Аноним с OnMenu предлагал). Могу ещё — один и тот же пример подсовываю не из недостатка воображения, а чтобы не плодить сущностей.
Ок, пришло требование: при закрытии окна пользователем спрашивать действительно ли он хочет это сделать. Куда будет помещена эта логика (предполагается, что дизайн уже "правильный", т.е. содержит Контроллеры и прочую атрибутику)?

S>Вы идёте именно по тому пути, что я описал выше — строите архитектуру от предположений заказчика о требуемом функционале — кто вам виноват, что архитектура меняется вслед за требованиями?
А от чего еще его строить. Предположения заказчика и мой собственный опыт это все что у меня есть.

S>И плиз, не сводите всё к крайностям. Стабильность архитектуры определяется её возможности адаптироваться в заранее определённом диапазоне условий, а не умением работать где угодно и с кем угодно.
Что будешь делать, когда через 2 года потребуется функционирование вне "заранее определённом диапазоне условий"? (отвечать лучше на следующий вопрос)

S>И снова мы оба гнём пальцы. Сила — она в ньютонах Ну разверну я вашу цепочку как "архитектура приорететнее требований приорететнее UI". Что изменится? Хотите обсуждения — давайте конкретику.
К вам приходит требование (сферическое в вакууме) которое требует переделки архитектуры. Ваши действия?

---

S>>>Ребят, если для вас не критично внутреннее устройство программы, если не волнует как долго оно проживёт или сколько будет стоить её саппорт (особенно другой командой) — тут и говроить не о чем — agile будет и приятней и эффективней.
A>>Зачем кидаться пустыми и вкорне неверными фразами?
S>А это был disclaimer
С моей стороны показалось, что это наезд Ибо все что ты перечисил мне критично.


A>>Бла-бла-бла и куча красивых лозунгов.
S>И снова мы гнём пальцы... Ну вот зачем вы так?
Потому что ты написал вкорне неверно.
S>>>Просто без качественной отстоявшейся архитектуры не будет ни долгой жизни программы, ни беспроблемного взаимодействия с приложениями-клиентами, ни кошерной декомпозиции ни много чего ещё.
Лозунги: читаешь -- все верно!, надо именно так! Пытаешься применить...
S>>>анализ требований, забивание на архитектуру (ибо и без неё хорошо) и проектирование от предметной области.
формирование предметной области невозможно без анализа требований. С другой стороны, после анализа требований предметная область получится сама собой.
Забвать на архитектуру -- вообще ересь.
S>>> Более-менее объективные критерии наблюдаются только в последнем варианте
Голые слова.

A>Давай сначала уточним. Какая архитектура имеется ввиду?
A>Есть (утрированно) высокоуровневая, среднеуровневая, средненизкоуровневая, низкоуровневая, низконизкоуровневая, ... архитектура. По убыванию "уровня": разбивка на сборки, нэймспэйсы, классы, методы.
A>Чем выше находится конкретный элемент, тем сложнее его изменять, но, другой стороны, он меньше подвержен влиянию изменению требований.

A>Так вот. Стабилизировать разбиение на сборки и неймспэйсы в большинстве случаев удается. Классы и методы -- нет.

Гммм... В моём понимании архитектура — это нечто описывающее абстрактную структуру системы. Если хотите — разделение на компоненты. Уровень компонентов и способ разбиения — это уже вопрос реализации. Другими словами архитектура отражает долгосрочные (стратегические) особенности работы.

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

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

A>

---

S>>Имелось в виду противопоставление
S>>"Простой дизайн немного лучше, чем правильный."
S>>-и-
S>>"Неправильный дизайн категорически запрещён."
A>В первом случае используются понятия "субъективно простой" и "субъективно правильный" дизайн. Найти (золотую) середину между ними можно.
A>Но в твоем утверждении используется абсолютное понятие "неправильный дизайн". Поэтому мой вопрос остается в силе

Я чесслово считал, что если взять "правильный" и "неправильный" в кавычки, никто не подумает что я абсолютизирую. Ошибся Не бывает абсолютно правильного и неправильного решения. Просто одно решение решает только текущую проблему, другое — текущую и ряд возможных проблем в будущем. Выбор решения — как всегда — управление рисками. Сравниваем _вероятностные_ потери от внесения изменений при "простом" решении и _текущие_ потери при "правильном" решении. Выбираем

А что, у нас уже изобрели другой метод оценки решений?

A>Ок, пришло требование: при закрытии окна пользователем спрашивать действительно ли он хочет это сделать. Куда будет помещена эта логика (предполагается, что дизайн уже "правильный", т.е. содержит Контроллеры и прочую атрибутику)?

Лехко — контроллер дёргает своё событие (скажем OnClosing), подписчики (допустим, та же форма) его обрабатывают. IoC в действии

Логика "если пользователь подтвердил — закрыть" живёт в контроллере. Способ подтверждения — дело гуя.

S>>Вы идёте именно по тому пути, что я описал выше — строите архитектуру от предположений заказчика о требуемом функционале — кто вам виноват, что архитектура меняется вслед за требованиями?
A>А от чего еще его строить. Предположения заказчика и мой собственный опыт это все что у меня есть.

Ну не совсем. Предложения заказчика — это то, чего он хочет сейчас. Вы можете узнать долгосрочные цели, как система будет использоваться/расти в будущем, с кем будет интегрироваться и т.п. и закладываться на это (разумеется с должной подстраховкой).

Но главное — здесь с Эвансом я полностью согласен — у вас есть информация, которая вполне вероятно переживёт и заказчика и ваш продукт и вас самих. Это предметная область (или Domain если вам ближе Эванс). Грубо говоря домен описывает пограничные условия, которые могут быть нарушены только при нарушении самой предметной области. Я не могу изложить всё так же ровно и гладко — почитайте "Domain-Driven-Design: Tackling the complicity in the heart of development". Только не воспринимайте всё близко к сердцу — Эванс отнюдь не идеал

Там есть пара интересных методик — от адаптации моделей при интервьюировании (слово-то какое гадкое...) до рекомендаций по использованию модели как словарика терминологии, как части документации, как сочетать DDD с методологиями и т.п. Читать стоит хотя бы для самообразования.

Модель предметной области не скажет вам ничего о конкретной деятельности заказчика. Зато она вам даст примерную модель данных (я не говорю о воспомогательных табличках). Терминология и связи между сущностями — это тоже очень много. Далее, сопоставляя требования с этой моделью вы увидите что часть идеально ложится на модель, а часть требует серьёзных переделок. Почти наверняка эти требования возникают когда заказчик хочет странного и скорее всего в первую очередь будут меняться в будущем. Ещё как вариант — эти требования не попадают в модель из-за того что вы что-то упустили при построении модели. Или заказчик (точнее, консультант) чего-то не знает в предметной области.


S>>И снова мы оба гнём пальцы. Сила — она в ньютонах Ну разверну я вашу цепочку как "архитектура приорететнее требований приорететнее UI". Что изменится? Хотите обсуждения — давайте конкретику.
A>К вам приходит требование (сферическое в вакууме) которое требует переделки архитектуры. Ваши действия?

Консультация с заказчиком, уточнение требований, выделение причин (хочу потому что) и целей (хочу чтобы), пересмотр модели, оценка исправлений, повторная консультация (если требование мелкое — всё на месте), внесение изменений.

Сферическая проблема — сферичесикй ответ. Почти наверняка окажется что либо поменялась предметная область (ничего не поделаешь ) либо я неверно отразил её в модели, либо деятельность заказчика расширилась. Это объективные причины и их не проигнорируешь.

There is no silver bullet...

A>

---

A>>>Зачем кидаться пустыми и вкорне неверными фразами?
S>>А это был disclaimer
A>С моей стороны показалось, что это наезд Ибо все что ты перечисил мне критично.
Упс. Честно не хотел. Если бы можно было поправить пост — поправил бы. Можете поставить мне минус

S>>И снова мы гнём пальцы... Ну вот зачем вы так?
A>Потому что ты написал вкорне неверно.
Давайте я выделю отдельные утверждения и поспорим по каждому.

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

A>Лозунги: читаешь -- все верно!, надо именно так! Пытаешься применить...
А где это не так... Или вы хотите сказать, что "возлюби ближнего" вас тоже раздражает? Я ж говорю — выбор подхода — это нечто близкое к религии. И защищается так же — священными войнами

Если смотреть со стороны методологий есть три подхода: анализ требований, забивание на архитектуру (ибо и без неё хорошо) и проектирование от предметной области.

A>формирование предметной области невозможно без анализа требований. С другой стороны, после анализа требований предметная область получится сама собой.
Вы отделите _вашу_ предметную область — автоматизацию деятельности от предметной области деятельности _заказчика_. Я везде говорил именно о последней, наивно полагая что это очевидно. Вы ведь не будете утверждать, что в логистике или в делопроизводстве что-то изменится от желаний вашего заказчика?

A>Забвать на архитектуру -- вообще ересь.
Скажите это агилистам. Я естественно утрировал, но абсолютизация микроитераций, код как документация, верификация кода как проверка корректности проектирования, ориентация на решение текущих проблем заказчика — это не забивание на архитектуру?
Могу ещё Бека с Амблерсом поцитатить. Если выдирать с мясом — то там куча кусков где они рекомендуют не делать ничего если этого не хочет заказчик. Про их отношение к системному коду, собственным микрофреймворкам и т.п. — вообще молчу. Но agile — это хорошее забивание на архитектуру. Потому что оно как-никак работает.

Более-менее объективные критерии наблюдаются только в последнем варианте

A>Голые слова.
Гммм... для меня учёт реальных особенностей работы программы — довольно объективно. Чтобы не повторяться — уже писал про DDD выше в этом посте.

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

S>Гммм... В моём понимании архитектура — это нечто описывающее абстрактную структуру системы. Если хотите — разделение на компоненты. Уровень компонентов и способ разбиения — это уже вопрос реализации. Другими словами архитектура отражает долгосрочные (стратегические) особенности работы.

S>Если вернуться к вашему вопросу то ответ будет таким: стабильными будут (точнее по возможности будут) внешние интерфейсы, способ разбиения и классы, отражающие архитектуру системы. Всякая воспомогательная шелуха и реализация актуальных требований наоборот должны быть легкозаменяемыми и не затрагивать архитектуру.
У нас совершенно разные представления об архитектуре. Поэтому продолжать считаю неуместным.

Архитектура (часть определения):

Это представление, которое даёт информацию о компонентах составляющих систему, о взаимосвязях между этими компонентами и правилах регламентирующих эти взаимосвязи.

---

S>Сравниваем _вероятностные_ потери от внесения изменений при "простом" решении и _текущие_ потери при "правильном" решении. Выбираем
Так вот мой опыт говорит, что простое решение чаще всего предпочтительнее.

A>>Ок, пришло требование: при закрытии окна пользователем спрашивать действительно ли он хочет это сделать. Куда будет помещена эта логика (предполагается, что дизайн уже "правильный", т.е. содержит Контроллеры и прочую атрибутику)?
S>Лехко — контроллер дёргает своё событие (скажем OnClosing), подписчики (допустим, та же форма) его обрабатывают. IoC в действии
S>Логика "если пользователь подтвердил — закрыть" живёт в контроллере. Способ подтверждения — дело гуя.
Ну вот. Наплодили кучу сущностей вместо того, чтобы выбрать простое решение: передать всю работу во вью. Вот когда во время закрытия понадобиться что-то большее чем вопрос пользователю, тогда выступает "тяжелая артелерия".

S>Ну не совсем. Предложения заказчика — это то, чего он хочет сейчас. Вы можете узнать долгосрочные цели, как система будет использоваться/расти в будущем, с кем будет интегрироваться и т.п. и закладываться на это (разумеется с должной подстраховкой).
S>Но главное — здесь с Эвансом я полностью согласен — у вас есть информация, которая вполне вероятно переживёт и заказчика и ваш продукт и вас самих. Это предметная область (или Domain если вам ближе Эванс).
Это те же предположения заказчика.

S>Консультация с заказчиком, уточнение требований, выделение причин (хочу потому что) и целей (хочу чтобы), пересмотр модели, оценка исправлений, повторная консультация (если требование мелкое — всё на месте), внесение изменений.
Т.е. изменится архитектура системы. Так? Получается, что изменение требований вызвали изменение архитектуры. Значит они первичны.

---

A>>Лозунги: читаешь -- все верно!, надо именно так! Пытаешься применить...
S>А где это не так... Или вы хотите сказать, что "возлюби ближнего" вас тоже раздражает? Я ж говорю — выбор подхода — это нечто близкое к религии. И защищается так же — священными войнами
А где я сказал ,что меня это раздражает? Некоторые мне даже нравятся (я же об этом сказал). Дело в том, что от этих очевидных вещей практического толку ноль

S>

Если смотреть со стороны методологий есть три подхода: анализ требований, забивание на архитектуру (ибо и без неё хорошо) и проектирование от предметной области.

A>>формирование предметной области невозможно без анализа требований. С другой стороны, после анализа требований предметная область получится сама собой.
S>Вы отделите _вашу_ предметную область — автоматизацию деятельности от предметной области деятельности _заказчика_. Я везде говорил именно о последней, наивно полагая что это очевидно. Вы ведь не будете утверждать, что в логистике или в делопроизводстве что-то изменится от желаний вашего заказчика?
А как ты узнаешь о предметной области? Однажды утром проснешься со всем необходимым объемом знаний?

A>>Забвать на архитектуру -- вообще ересь.
S>Скажите это агилистам. Я естественно утрировал, но абсолютизация микроитераций, код как документация, верификация кода как проверка корректности проектирования, ориентация на решение текущих проблем заказчика — это не забивание на архитектуру?
Нет. В конце каждой микроэтерации запланирована фаза рефакторинга. В начале каждого изменения проводится анализ системы с точки зрения легкого добавление новой фичи. Если добавить ее сложно, то система приводится к виду, в котором ее просто добавить.

S>Могу ещё Бека с Амблерсом поцитатить. Если выдирать с мясом — то там куча кусков где они рекомендуют не делать ничего если этого не хочет заказчик. Про их отношение к системному коду, собственным микрофреймворкам и т.п. — вообще молчу. Но agile — это хорошее забивание на архитектуру. Потому что оно как-никак работает.
Было бы неплохо. Только вот боюсь, что цитата оторванная от конекста будет бесполезной (а контекстом может оказаться вся книга).

Уппс... во время правки потерялось одно слово — "Уровень компонентов и способ разбиения — это уже вопрос реализации архитектуры." Вот так точнее будет. Согласитесь, когда мы обсуждаем архитектуру мы не думаем о классах, методах и неэмспейсах а используем несколько более абстрактное понятие. Пойдёт?

Теперь особой разницы между "архитектура — это нечто описывающее абстрактную структуру системы" и "Это представление, которое даёт информацию о компонентах... взаимосвязях...правилах регламентирующих эти взаимосвязи." не наблюдается. Просто ваше определение более формально и детально.

A>

---

S>>Сравниваем _вероятностные_ потери от внесения изменений при "простом" решении и _текущие_ потери при "правильном" решении. Выбираем
A>Так вот мой опыт говорит, что простое решение чаще всего предпочтительнее.
Вот видите — у нас даже базовые подходы различаются. У вас — "опыт". У меня — явно выделенные факторы их обективная оценка и соотнесение. И кто вам сказал что "правильное" решение будет сложным?

S>>Лехко — контроллер дёргает своё событие (скажем OnClosing), подписчики (допустим, та же форма) его обрабатывают. IoC в действии
S>>Логика "если пользователь подтвердил — закрыть" живёт в контроллере. Способ подтверждения — дело гуя.
A>Ну вот. Наплодили кучу сущностей вместо того, чтобы выбрать простое решение: передать всю работу во вью. Вот когда во время закрытия понадобиться что-то большее чем вопрос пользователю, тогда выступает "тяжелая артелерия".

Вы передёргиваете. Добавилось одно событие. За счёт этого у нас логика по-прежнему отведена от представления. Что это даёт: снижена стоимость сопровождения UI (меньше проверок при реализации альтернативного UI/изменении старого), упрощается тестирование, возможен полный code coverage, проще разделять ответственность между разработчиками. Я в таком духе ещё долго могу

S>>Ну не совсем. Предложения заказчика — это то, чего он хочет сейчас. Ещё вы можете узнать долгосрочные цели, как система будет использоваться/расти в будущем, с кем будет интегрироваться и т.п. и закладываться на это (разумеется с должной подстраховкой).
(добавил выделенное)
S>>Но главное — здесь с Эвансом я полностью согласен — у вас есть информация, которая вполне вероятно переживёт и заказчика и ваш продукт и вас самих. Это предметная область (или Domain если вам ближе Эванс).
A>Это те же предположения заказчика.

Это разные вещи.

Вы отделите _вашу_ предметную область — автоматизацию деятельности от предметной области деятельности _заказчика_. Я везде говорил именно о последней, наивно полагая что это очевидно. Вы ведь не будете утверждать, что в логистике или в делопроизводстве что-то изменится от желаний вашего заказчика?

A>Т.е. изменится архитектура системы. Так? Получается, что изменение требований вызвали изменение архитектуры. Значит они первичны.
Уже отвечал.

Почти наверняка окажется что либо поменялась предметная область (ничего не поделаешь ) либо я неверно отразил её в модели, либо деятельность заказчика расширилась. Это объективные причины и их не проигнорируешь.

There is no silver bullet...

Причина изменения в требованиях — изменение предметной области. Точнее так: объективное изменение тербований — признак изменения в предметной области. Что приоритетней с этой точки зрения?

A>

---

A>>>Лозунги: читаешь -- все верно!, надо именно так! Пытаешься применить...
S>>А где это не так... Или вы хотите сказать, что "возлюби ближнего" вас тоже раздражает? Я ж говорю — выбор подхода — это нечто близкое к религии. И защищается так же — священными войнами
A>А где я сказал ,что меня это раздражает? Некоторые мне даже нравятся (я же об этом сказал). Дело в том, что от этих очевидных вещей практического толку ноль
Это как готовить... Для меня толку от неочевидных шаманских методик в XP — ноль. Но я не называю их бесполезными, а пытаюсь разобраться почему они не работают в конкретных ситуациях и как их собирались использовать авторы.

A>А как ты узнаешь о предметной области? Однажды утром проснешься со всем необходимым объемом знаний?

Если вы не читали Эванса — есть куча неявных источников информации о предметной области. Самый простой — обсуждение требований. Цель выделение того, что Эванс называет "неявным знанием" — той информации которая кажется очевидной специалистам и последние просто её не упоминают. Он приводит пример с расписанием авиаперевозок. Из требований выходило что-то типа "исходный-конечный аэропорт + время прилёта/отлёта". Во время собеседования было совершенно случайно выяснено, что вообще-то расписание определяется планом полёта, а его лучше рассматривать как последовательность четырёхмерных точек (3 координаты + время). Дальше выясняется о связи узловых точек с навигационными маяками и заранее утверждёнными трассами. И так далее.

Вся эта информация оказалась крайне важна, но в требованиях о ней не было ни слова. Эта информация определяется не пожеланиями заказчика, а предметной областью — она объективна. Если её не учитывать её на ранних этапах — она косвенно всплывёт позже через изменения требований, например в виде проверки соблюдения полётного плана или визуализации рейсов.

Именно такие требования чаще всего и приводят к изменению архитектуры.

Сама логика DDD безумно примитивна — заказчик в идеальном случае строит свои требования в ответ на изменения в окружающей среде. Так зачем моделировать среду косвенно, через требования заказчика, если можно моделировать её прямо?

Есть ещё куча способов изучения предментной области. Самые примитивные — консультация со сторонними специалистами/самостоятельное изучение.

A>Нет. В конце каждой микроэтерации запланирована фаза рефакторинга. В начале каждого изменения проводится анализ системы с точки зрения легкого добавление новой фичи. Если добавить ее сложно, то система приводится к виду, в котором ее просто добавить.

Это делается на каждой итерации. Т.е. вместо того, чтобы сразу строить "систему приближенную к идеалу" она строится мелкими-мелкими шажочками. Архтектуры как таковой здесь нет — вместо неё происходит рефакторинг кода в ответ на изменение требований. Такой рефакторинг не отражает какой-либо конечной цели, он бессистемен. Если учесть накладные затраты на каждую итерацию то постоянное изменение архитектуры вполне может оказаться дороже — особенно для больших проектов, из-за затран на коммуникацию и теоретической возможности изменения архитектуры всей системы в любой момент.

S>>Могу ещё Бека с Амблерсом поцитатить. Если выдирать с мясом — то там куча кусков где они рекомендуют не делать ничего если этого не хочет заказчик. Про их отношение к системному коду, собственным микрофреймворкам и т.п. — вообще молчу. Но agile — это хорошее забивание на архитектуру. Потому что оно как-никак работает.
A>Было бы неплохо. Только вот боюсь, что цитата оторванная от конекста будет бесполезной (а контекстом может оказаться вся книга).

Угу. Будет ниже. Попробую не выдирать из контекста.

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

Совершенно бесполезный спор. Не считаешь? Поэтому предлагаю

СУВ, Aikin

Поехали. Кент Бек, "Экстремальное программирование" (Амблерса под рукой нет). Скан с питерского издания, перевод адекватен Extreme Programming Explained от Addison-Wesley — могу поцитатить и оттуда. Естественно книга вводная, конкретных утверждений практически нет, цепляться не за что. Посоветуете талмуд посерьёзней?

Страница 61. Глава 8 "Базовые принципы":

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

Меня подобные утверждения очень настораживают — я вижу в них попытку переложить всю ответственность на заказчика. Если случилось что-то непредвиденное — виноват будет он.

Приемлемая простота — необходимо решать каждую проблему так, как если бы ее можно было решить самым смехотворно простым способом. Времени, которое вы экономите на решении 98% проблем, для которых это утверждение является истинным, вполне хватает, чтобы справиться с решением оставшихся 2% проблем.
...
В рамках установившихся традиций мы приучены к тщательному планированию своих действий, мы привыкли проектировать код с расчетом на его дальнейшее повторное использование. Однако в рамках ХР огромные
усилия ... прикладываются для того, чтобы сегодня программист думал о решении только сегодняшних проблем и был уверен в том, что завтра в случае необходимости имеющийся код можно будет с легкостью усовершенствовать так, как этого требует складывающаяся ситуация. Экономика разработки программ, представленная в виде набора нескольких вариантов, приветствует данный подход.

Эти 98% "решённых" проблем висят дамокловым мечом — от них не избавились, их просто "замазали" временным решением — о чём собственно и написано. Кстати я не так уж и уверен насчёт соотношения 98/2.
Особенно понравился пассаж про не надо рассчитывать на дальнейшее использование и про приветствующую это дело экономику. Так и хочется постебаться про "код на выброс" — некорректно, а хочется ведь...

Страница 66:

Путешествие налегке — вы не можете нести с собой гору багажа и при этом двигаться быстро.
...
Члены команды ХР должны стать интеллектуальными кочевниками, в любую минуту готовыми быстро упаковать свои пожитки и следовать за пастухом. Пастухом в данном случае является дизайн, который развивается в ином направлении, чем это предполагалось ранее, или заказчик, который хочет развивать проект в ином направлении, чем это предполагалось ранее, или член команды, который решил уйти из проекта, или технология, которая подчас эволюционирует с головокружительной быстротой, или изменяющийся климат, в котором функционирует бизнес.

Ребят, если это не закладывание всей архитектуры проекта на сиюминутные требования заказчика/состав разработчиков/используемые технологии — то я последний баклан и не умею читать скрижали. Какого?...

Как все кочевники, члены команды ХР должны привыкнуть путешествовать налегке. Они не должны брать в свое путешествие слишком многого — в багаже не должно оставаться ничего, за исключением того, что необходимо для удовлетворения нужд заказчика, то есть тестов и кода.

А вот вам и долгожданный отказ от архитектуры — она не необходима для "удовлетворения нужд заказчика".

Ниже, на стр 91 (Глава 11 • Как это работает? — простой дизайн):

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

Это действительно всё, за счёт чего гарантируется качество дизайна?

О архитектуре упоминается аж на 145-й странице из 212 (Глава 17 • Стратегия проектирования). Порадовало:

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

На этом собсно про архитектуру всё

Порадовало как в книге мягко обошли тему про фреймворки (стр 200. Глава 26 — ХР в работе):

Можно ли использовать ХР для разработки программных инфраструктур? Одно из правил ХР гласит, что вы должны удалять из системы любую функциональность, которая в данный момент не используется, если следовать этому правилу, то вы должны удалить всю инфраструктуру.
ХР не очень хорошо приспособлена для разработки кода, использование которого планируется не сейчас, а в дальнейшем.
...
В ХР мы занимаемся разработкой конкретных приложений. Если после нескольких лет постоянных переработок дизайна начинают вырисовываться некоторые универсальные абстракции общего использования, значит, настало время подумать о том, как сделать их более широко доступными.

Появление универсальных компонентов после нескольких лет постоянных переработок дизайна??? До меня обычно доходит раньше

Вообще XP агрессивно заточена под решение проблем "здесь и сейчас" без гарантий в будущем. Тоже конеш подход...

Удачи...

A>Совершенно бесполезный спор. Не считаешь? Поэтому предлагаю

Ога. Заканчиваем

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

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

S>>Подскажите плиз, это я неправильно понимаю, или вся "большая тройка" танцует от функциональных требований?

S>Архитектура (программного обеспечения) – это совокупность согласованных технических решений направленная на удовлетворение требований, предъявляемых к программному обеспечению.
S>Т.е. архитектура — есть функция требований. Это аксиома.

Мнээ, плюс — функция технических ограничений, которые неплохо сразу принять во внимание, и _будущих_ требований, которые предположительно может быть возникнут. "Запас прочности" надо бы заложить в архитектуру, иначе что это за архитектура?

Здравствуйте, Gaperton!

S>>>Подскажите плиз, это я неправильно понимаю, или вся "большая тройка" танцует от функциональных требований?

S>>Архитектура (программного обеспечения) – это совокупность согласованных технических решений направленная на удовлетворение требований, предъявляемых к программному обеспечению.
S>>Т.е. архитектура — есть функция требований. Это аксиома.

G>Мнээ, плюс — функция технических ограничений, которые неплохо сразу принять во внимание, и _будущих_ требований, которые предположительно может быть возникнут. "Запас прочности" надо бы заложить в архитектуру, иначе что это за архитектура?

О, здраствуйте Давно хотел пообщаться — мало здесь товарищей, что вплотную занимаются управлением проектами, мало

Пока из общения с товарищами выходит что проектирование чисто от требований — нормальный подход. Смущает две вещи — то, что требования направлены на решение текущих задач и строить на их основе архитектуру системы — как то не того...
и то, что эти вопросы в принципе не подымаются в "тру" методологиях — такие вопросы отдаются на откуп архитекторам (если он есть) или обходятся кучей методик (не будем о DDD — про неё даже Эванс не может уверенно сказать что оно такое, куда уж простым смертным )

Это я дурак и что-то упустил или это такая модель бизнеса — "Сделаем всё за деньги. Не понравилось — платите, не можете сформулировать хотелки — платите, ошиблись — платите"? Потому что я не могу больше придумать доводов, зачем так опровергать тот факт, что архитектура не может быть построена на информации о сиюминутных целях.

Только не уходите плиз, а то сначала спорят-спорят, потом говорят что не о чем спорить и предлагают

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

S>Только не уходите плиз, а то сначала спорят-спорят, потом говорят что не о чем спорить и предлагают


P.S. Спорить-то есть о чем, вот только я не вижу смысла в этом споре. Мы уж слишком с разных сторон подходим к проблеме. (перечитай два последних моих поста по теме, если будут новые мысли, то вполне может подискутировать)

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

S>Вообще XP агрессивно заточена под решение проблем "здесь и сейчас" без гарантий в будущем. Тоже конеш подход...

Гарантия там в том, что несмотря ни на что, проект все время будет работать. И стоимость внесения изменений будет примерно ленейна. В отличии от XP, та методология, которую ты называешь "правильной", выдаст продукт скорее всего дешевле и с более низкой итоговой ценой изменений, но в некоторых случаях проект просто не доживет до релиза (т.к. зациклится на сборе требований по причине их быстрого устаревания). Для таких случаев и придуман XP, можно ругать его безоглядное применение, можно ругать его апологетов за излишнюю религиозность, но факт есть факт, есть ниша, где XP работает лучше (заказчик и исполнитель более удовлетворены результатом проекта).

Оффтоп, наблюдение:
Если есть люди, которые реально заинтересованы в проекте и имеют достаточно полномочий, проект будет сделан по любой методологии или в ее отсутствии. Если таких людей нет или они не обладают достаточными полномочиями — никакая методология, архитектура или безупречный код проект не спасут

Здравствуйте, Aikin
A>Спорить-то есть о чем, вот только я не вижу смысла в этом споре. Мы уж слишком с разных сторон подходим к проблеме. (перечитай два последних моих поста по теме, если будут новые мысли, то вполне может подискутировать)

Дык согласен... если не читали с самого начала — я там только смиренно спрашивал, всё ли я правильно понимаю. Это потом я разошёлся, когда появилось мнение что UI приоритетнее архитектуры.

Но всё равно согласитесь приятно было поспорить — теперь вижу конкретные точки расхождения.

Спасибо!

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

Не хотел быть толкователем чужих идей, но:

S>ПоеСтраница 61. Глава 8 "Базовые принципы":
S>

S>Бизнес должен быстро определять, каким образом система будет полезной для него, и он должен возвращать разработчикам эти сведения в течение дней или недель, но не в течение месяцев или лет.

S>Меня подобные утверждения очень настораживают — я вижу в них попытку переложить всю ответственность на заказчика. Если случилось что-то непредвиденное — виноват будет он.
Во первых, этот принцип -- то без чего не может состояться ни один Айджаил проект. Нет тесного контакта с заказчиком -- нет айджила.

Во вторых, какое именно "непредвиденное"?
Изменение требований -- однозначно "виноват" заказчик и дело хорошей команды, чтобы он пострадал как можно меньше.
Система работает совсем не так как ожидалось -- то же самое, вам каждые 2 недели вам поставлялись результаты итерации, кто вам мешал их просматривать (как я уже сказал, айджаил здесь уже не работает).
"Непредвиденные" баги -- виноваты разработчики.
Система работает не в соответствии с требованиями -- виноваты разработчики.


Пойми простую истину: Только Заказчик знает что именно ему нужно. (то что он часто не может это сформулировать -- другое дело).

S>

S>Приемлемая простота — необходимо решать каждую проблему так, как если бы ее можно было решить самым смехотворно простым способом. Времени, которое вы экономите на решении 98% проблем, для которых это утверждение является истинным, вполне хватает, чтобы справиться с решением оставшихся 2% проблем.
S>...
S>В рамках установившихся традиций мы приучены к тщательному планированию своих действий, мы привыкли проектировать код с расчетом на его дальнейшее повторное использование. Однако в рамках ХР огромные
S>усилия ... прикладываются для того, чтобы сегодня программист думал о решении только сегодняшних проблем и был уверен в том, что завтра в случае необходимости имеющийся код можно будет с легкостью усовершенствовать так, как этого требует складывающаяся ситуация. Экономика разработки программ, представленная в виде набора нескольких вариантов, приветствует данный подход.

S>Эти 98% "решённых" проблем висят дамокловым мечом — от них не избавились, их просто "замазали" временным решением — о чём собственно и написано. Кстати я не так уж и уверен насчёт соотношения 98/2.
S>Особенно понравился пассаж про не надо рассчитывать на дальнейшее использование и про приветствующую это дело экономику. Так и хочется постебаться про "код на выброс" — некорректно, а хочется ведь...
Каким Домокловым мечем? Если простой код перестает справляться со своими обязанностями, он переписывается (возможно даже полностью) в следующий простой код, который уже может решить проблему.
По поводу "неоходимо решать проблему ... самым смехотворно простым способом", если подойти с "размахом" и реализовать все "по книжкам", то:
1) велик шанс, что мы потратим время зря (код так и не будет никогда переиспользован)
2) от него будет тяжело отказаться в случае когда он начнет мешать.

S>Страница 66:
S>

S>Путешествие налегке — вы не можете нести с собой гору багажа и при этом двигаться быстро.
S>...
S>Члены команды ХР должны стать интеллектуальными кочевниками, в любую минуту готовыми быстро упаковать свои пожитки и следовать за пастухом. Пастухом в данном случае является дизайн, который развивается в ином направлении, чем это предполагалось ранее, или заказчик, который хочет развивать проект в ином направлении, чем это предполагалось ранее, или член команды, который решил уйти из проекта, или технология, которая подчас эволюционирует с головокружительной быстротой, или изменяющийся климат, в котором функционирует бизнес.

S>Ребят, если это не закладывание всей архитектуры проекта на сиюминутные требования заказчика/состав разработчиков/используемые технологии — то я последний баклан и не умею читать скрижали. Какого?...
Прости, но не умеешь
Здесь всего лишь говориться о том, что команда должна быть готова в любой момент отказаться от текущего решения и переписать часть системы с использованием более эффективного подхода.
Т.е. если текущий дизан системы стал плох (ввиду изменившихся требований), то он заменяется на такой, который удовлетворяет новым критериям.

S>

Как все кочевники, члены команды ХР должны привыкнуть путешествовать налегке. Они не должны брать в свое путешествие слишком многого — в багаже не должно оставаться ничего, за исключением того, что необходимо для удовлетворения нужд заказчика, то есть тестов и кода.

S>А вот вам и долгожданный отказ от архитектуры — она не необходима для "удовлетворения нужд заказчика".
Спешишь. Архитектура удовлетворяет нуждам кода и тестов: Без модульности у нас не получиться протестировать. Без соответствующего дизайна код будет слишком сложен.

S>Ниже, на стр 91 (Глава 11 • Как это работает? — простой дизайн):
S>

S>• вы привыкаете к постоянной переработке кода, благодаря чему внесение в дизайн системы не представляет для вас сложностей;
S>• вы обладаете понятной всеобщей метафорой, благодаря чему вы можете быть уверенными в том, что любые изменения в дизайне будут выполняться в рамках единого пути, сходящегося в одной точке;
S>• вы программируете не один, а с партнером, поэтому вы можете быть уверенными в том, что вы формируете простой дизайн, а не глупый дизайн.

S>Это действительно всё, за счёт чего гарантируется качество дизайна?
А этого мало?

Часто и этого нет:
1) разработчики не привыкли перерабатывать свой код -- код пестрит костылями и хотфиксам
2) (с метафорами у меня туго) нету единого видения системы всеми разработчикми -- каждый лепит свое, не похожее на дригое (в том числе и то что ты сам писал раньше)
3) (перекликается с 2) + то что просто для меня может быть очень сложно для моего партнера и наоборот

А вообще, что можно к этим пунктам добавить такое, чтобы этого небыло в Айджел команде?

S>О архитектуре упоминается аж на 145-й странице из 212 (Глава 17 • Стратегия проектирования). Порадовало:
S>

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

S>На этом собсно про архитектуру всё
Нет, не так: "на этом собсно про слово архитектура всё"

S>Порадовало как в книге мягко обошли тему про фреймворки (стр 200. Глава 26 — ХР в работе):
S>

S>Можно ли использовать ХР для разработки программных инфраструктур? Одно из правил ХР гласит, что вы должны удалять из системы любую функциональность, которая в данный момент не используется, если следовать этому правилу, то вы должны удалить всю инфраструктуру.
S>ХР не очень хорошо приспособлена для разработки кода, использование которого планируется не сейчас, а в дальнейшем.
S>...
S>В ХР мы занимаемся разработкой конкретных приложений. Если после нескольких лет постоянных переработок дизайна начинают вырисовываться некоторые универсальные абстракции общего использования, значит, настало время подумать о том, как сделать их более широко доступными.

S>Появление универсальных компонентов после нескольких лет постоянных переработок дизайна??? До меня обычно доходит раньше
Боюсь, что ты гений. Не чета остальным. Но хочу огорчить, то что "до тебя обычно доходит раньше", уже будет в дизайне (естественно в случае, когда оно используется полностью, а не служит "будующим изменениям")

S>Вообще XP агрессивно заточена под решение проблем "здесь и сейчас" без гарантий в будущем. Тоже конеш подход...
А какие гаранттии дает твой подход? Тоже никаких кроме "если система будет развиваться так-то и так-то, то". У гибких подходов одно приемущество: они получат готовое решение раньше и они готовы, в отличии от тебя, его изменять.


СУВ, Aikin

P.S. Боюсь получился слишком большой пост. И смысл размазан. И кроме Sinix-а его мало кто прочитает (ослилт )

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



A>СУВ, Aikin

A>P.S. Боюсь получился слишком большой пост. И смысл размазан. И кроме Sinix-а его мало кто прочитает (ослилт )


Осилил и подписываюсь почти под каждым утверждением

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

Z>В отличии от XP, та методология, которую ты называешь "правильной", выдаст продукт скорее всего дешевле и с более низкой итоговой ценой изменений, но в некоторых случаях проект просто не доживет до релиза (т.к. зациклится на сборе требований по причине их быстрого устаревания). Для таких случаев и придуман XP, можно ругать его безоглядное применение, можно ругать его апологетов за излишнюю религиозность, но факт есть факт, есть ниша, где XP работает лучше (заказчик и исполнитель более удовлетворены результатом проекта).
Хочу заметить, что "правильная методология" будет много лучше XP (пусть будет XP) в случае неизменных либо меняющихся в ожидаемом направлении требований.
Гибкие методологии возникли как раз в вет на то, что требования имею особенность меняться (порой совершенно непредстказуемо).

СУВ, Aikin

Здравствуйте, Ziaw!

S>>Вообще XP агрессивно заточена под решение проблем "здесь и сейчас" без гарантий в будущем. Тоже конеш подход...
Z>Гарантия там в том, что несмотря ни на что, проект все время будет работать. И стоимость внесения изменений будет примерно ленейна...
Z> Для таких случаев и придуман XP, можно ругать его безоглядное применение, можно ругать его апологетов за излишнюю религиозность, но факт есть факт, есть ниша, где XP работает лучше (заказчик и исполнитель более удовлетворены результатом проекта).
Насколько я понимаю там идёт хитрая магия — стоимость остаётся линейной за счёт взаимодобивающих методик, которые сами по себе эффективны на ограниченном круге задач и эти задачи довольно удачно пересекаются с аутсорсингом/заказным ПО (особенно хорошо оно сочетается с оплатой за работу а не за результат).

Но об этом явно практически нигде не говорится, и возникает такое ощущение, что люди приобщились к дао и решат все проблемы простым соблюдением шаманских методик. Этакое плацебо — пока ты веришь в себя и в методики — они работают (Бек это зовёт Храбростью). Если методики не работают — это ты просто в них не веришь. Или заказчик не тру. Не мешайте в общем И всё это дело солидно полито наивным сиропом про дружескую взаимовыручку и идеальную команду.

Если есть какие-то более серьёзные работы, которые подробно расписывают методики и объясняют почему оно работает независимо от веры в них — с удовольствием прочитаю. То же относится и ко всем остальным религиям — что там у нас модно кроме MSF 4|RUP|Scrum?

Z> В отличии от XP, та методология, которую ты называешь "правильной", выдаст продукт скорее всего дешевле и с более низкой итоговой ценой изменений, но в некоторых случаях проект просто не доживет до релиза (т.к. зациклится на сборе требований по причине их быстрого устаревания).

Расскажите мне плиз про то, что я называю "правильной" методологией. Я не стебаюсь — большинство идей подсознательно стянуто с различных книжек — половину из них я не вспомню. В памяти естественно осели только те, что подтверждались опытом. Я уверен что изобретаю велосипед и "где-то там" (с) есть Великая Праведная Книга, которую я невольно цитатю. Не поделитесь ссылкой?

Про требования мы вроде уже кучу раз говорили — их всё равно нет смысла рассматривать как нечто вечное. Вроде уже писал, что как правило требования не выходят за рамки описываемого предметной областью — нет?

Заметь, я не кричу, что DDD — наше всё, а только говорю что DDD предлагает более объективный подход к построению архитектуры, т.к. старается сгладить влияние требований. В ответ постоянно идёт что-то вроде "архитектура не так важна как требования" и "вы никогда не построите стабильную архитектуру на основе требований". Это нормальный разговор?

Z>Оффтоп, наблюдение:
Z>Если есть люди, которые реально заинтересованы в проекте и имеют достаточно полномочий, проект будет сделан по любой методологии или в ее отсутствии. Если таких людей нет или они не обладают достаточными полномочиями — никакая методология, архитектура или безупречный код проект не спасут
Ога... но вроде мы до реальной жизни ещё не опускались, нет?

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

Удачи!

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

S>Если есть какие-то более серьёзные работы, которые подробно расписывают методики и объясняют почему оно работает независимо от веры в них — с удовольствием прочитаю. То же относится и ко всем остальным религиям — что там у нас модно кроме MSF 4|RUP|Scrum?
Я считаю, что ни одна методология не способна работать без веры в нее. Под верой я подразумеваю убежденность в необходимости ее применения.

S>Расскажите мне плиз про то, что я называю "правильной" методологией. Я не стебаюсь — большинство идей подсознательно стянуто с различных книжек — половину из них я не вспомню. В памяти естественно осели только те, что подтверждались опытом. Я уверен что изобретаю велосипед и "где-то там" (с) есть Великая Праведная Книга, которую я невольно цитатю. Не поделитесь ссылкой?

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

S>Про требования мы вроде уже кучу раз говорили — их всё равно нет смысла рассматривать как нечто вечное. Вроде уже писал, что как правило требования не выходят за рамки описываемого предметной областью — нет?

Выделенного я не понял. Требования это функционал, предметная область абстрагируется в модель с которой приходится работать, они сильно влияют друг на друга, но ни одно из них не является функцией от другого.

S>Заметь, я не кричу, что DDD — наше всё, а только говорю что DDD предлагает более объективный подход к построению архитектуры, т.к. старается сгладить влияние требований.

DDD это не методолгия разработки, это подход к архитектуре. Я пока не вижу как DDD может сгладить влияние требований. Т.к. требования часто очень круто влияют на модель.

S>В ответ постоянно идёт что-то вроде "архитектура не так важна как требования" и "вы никогда не построите стабильную архитектуру на основе требований". Это нормальный разговор?

Это две несвязанные точки зрения. Архитектура это функция требований, как не крути. Домен это функция требований и предметной области.

S>А с хорошо организованной архитектурой приятней работать. Суеты нет, экзистенциального ужаса перед "а-а-а, поменялись требования, мы все умрём". Да и чуство что делаешь не очередную поделку а Вещь тоже дорого стоит.

Кто-то пропагандирует "плохо организованную архитектуру"? Aikin очень правильную мысль тебе пытается донести: архитектура должна быть предельно проста. А ты ее трактуешь как отказ от архитектуры вообще.

Ух ты — после всех "давай закончим" мы всё ещё продолжаем. Кто же первый сдастся?...

A>P.S. Боюсь получился слишком большой пост. И смысл размазан. И кроме Sinix-а его мало кто прочитает (ослилт )
Я упёртый — я ослилт. Поехали!

A>Во первых, этот принцип -- то без чего не может состояться ни один Айджаил проект. Нет тесного контакта с заказчиком -- нет айджила.
Ёк — кто ж спорит то? За "заказчик на месте" — я всеми конечностями за. Как и за тестирование в должных дозах, постоянные сборки и т.п.

A>Изменение требований -- однозначно "виноват" заказчик и дело хорошей команды, чтобы он пострадал как можно меньше.
...
A>Пойми простую истину: Только Заказчик знает что именно ему нужно. (то что он часто не может это сформулировать -- другое дело).

Вот где у нас расхождение. Смотрите. Выше я писал что для остального аутсорса/сферы услуг вообще используется в принципе другая модель: я плачу за результат и получаю готовый результат. Поскольку я плачу деньги я ожидаю что за мои деньги специалисты решат мои проблемы. Вся ответственность заказчика объективно заканчивается когда он выбрал исполнителя — дальше ему остаётся только контроль. Говорить что у нас плохо получается потому что нас плохо контролируют — это-то меня и смущает. Как-то по детски... По этому пункту ок?

A>Каким Домокловым мечем? Если простой код перестает справляться со своими обязанностями, он переписывается (возможно даже полностью) в следующий простой код, который уже может решить проблему.
A>По поводу "неоходимо решать проблему ... самым смехотворно простым способом", если подойти с "размахом" и реализовать все "по книжкам", то:
A>1) велик шанс, что мы потратим время зря (код так и не будет никогда переиспользован)
A>2) от него будет тяжело отказаться в случае когда он начнет мешать.

Ну ребят... это тоже не серьёзно — "мы не управляемся с камазом поэтому ездим на санках". За любую универсальность надо платить. Вместо того чтобы сказать что для отдельных сценариев не имеет смысла писать сложный долгоживущий код — он не окупится и подробно разобрать пограничные сценарии, нам рассказывают про "путешествуй налегке", пастухов и приветствующую это дело экономику. Я не понял, это секта или методология?

S>>Ребят, если это не закладывание всей архитектуры проекта на сиюминутные требования заказчика/состав разработчиков/используемые технологии — то я последний баклан и не умею читать скрижали. Какого?...
A>Прости, но не умеешь
A>Здесь всего лишь говориться о том, что команда должна быть готова в любой момент отказаться от текущего решения и переписать часть системы с использованием более эффективного подхода.
A>Т.е. если текущий дизан системы стал плох (ввиду изменившихся требований), то он заменяется на такой, который удовлетворяет новым критериям.

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

S>>

Как все кочевники, члены команды ХР должны привыкнуть путешествовать налегке. Они не должны брать в свое путешествие слишком многого — в багаже не должно оставаться ничего, за исключением того, что необходимо для удовлетворения нужд заказчика, то есть тестов и кода.

S>>А вот вам и долгожданный отказ от архитектуры — она не необходима для "удовлетворения нужд заказчика".
A>Спешишь. Архитектура удовлетворяет нуждам кода и тестов: Без модульности у нас не получиться протестировать. Без соответствующего дизайна код будет слишком сложен.
Дыкть код у вас максимально простой и в любой момент может быть заменён вместе с "дизайном" (что они под ним понимают ???) — какая тут архитектура? Тут получается что архитектура — функция от кода а не наоборот.

S>>

S>>• вы привыкаете к постоянной переработке кода, благодаря чему внесение в дизайн системы не представляет для вас сложностей;
S>>• вы обладаете понятной всеобщей метафорой, благодаря чему вы можете быть уверенными в том, что любые изменения в дизайне будут выполняться в рамках единого пути, сходящегося в одной точке;
S>>• вы программируете не один, а с партнером, поэтому вы можете быть уверенными в том, что вы формируете простой дизайн, а не глупый дизайн.

S>>Это действительно всё, за счёт чего гарантируется качество дизайна?
A>А этого мало?
Тут идёт обычная подмена понятий — "простой дизайн" рассматривается как антитеза "глупому". Следовательно "простой" дизайн == "умный" дизайн.
Этого мало. Потому что пока у вас не будет в тасклисте красным маркером "пиши красиво, сын мой — или цих с гвоздями!" — никто ничего не будет делать. Любая система изменяется по пути наименьшего сопротивления. Чудес бесплатно не бывает. И пока вы явно не озаботитесь вопросами качества кода и архитектуры — никто их за вас не решит. Вообще зачем я пишу эту тривиальшину? неужели это так неочевидно?

S>>Появление универсальных компонентов после нескольких лет постоянных переработок дизайна??? До меня обычно доходит раньше
A>Боюсь, что ты гений. Не чета остальным. Но хочу огорчить, то что "до тебя обычно доходит раньше", уже будет в дизайне (естественно в случае, когда оно используется полностью, а не служит "будующим изменениям")

Или я неправильно читаю, или "универсальные абстракции" "начинают вырисовываться" "после нескольких лет постоянных переработок дизайна". Их ещё нет в дизайне. Оно только начинают вырисовываться. Как может то что получится в результате вообще использоваться в фреймворке? XP же настаивает на безжалостном выпалывании "ненужного" кода и максимально возможной простоте.


S>>Вообще XP агрессивно заточена под решение проблем "здесь и сейчас" без гарантий в будущем. Тоже конеш подход...
A>А какие гаранттии дает твой подход? Тоже никаких кроме "если система будет развиваться так-то и так-то, то". У гибких подходов одно приемущество: они получат готовое решение раньше и они готовы, в отличии от тебя, его изменять.

Гмг. Я нигде не говорил ни слова о "моём подходе". Только приводил определённые решения в ответ на вопросы в духе "раз такой умный, расскажи как правильно" (ни разу не про вас — даже не думайте ). Что у вас сложилось в результате — я даже боюсь подумать. Поверьте я здесь ни при чём.

Я нигде не писал об общих решениях, только приводил "что мне не нравится" и "как это можно решить" — если спрашивали. Почему такая уверенность что "у гибких подходов одно приемущество: они получат готовое решение раньше и они готовы, в отличии от тебя, его изменять" —

Я где-то писал о невозможности изменений архитектуры? Или о невозможности реализаций новых требований? Я тоже могу начать комментировать ваше мнение о сепулении сепулек. Но не будем

Ухх... пора завязывать — пожалейте сервер. Мировая?

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

S>Здравствуйте, Aikin
A>>Спорить-то есть о чем, вот только я не вижу смысла в этом споре. Мы уж слишком с разных сторон подходим к проблеме. (перечитай два последних моих поста по теме, если будут новые мысли, то вполне может подискутировать)

S>Дык согласен... если не читали с самого начала — я там только смиренно спрашивал, всё ли я правильно понимаю. Это потом я разошёлся, когда появилось мнение что UI приоритетнее архитектуры.

S>Но всё равно согласитесь приятно было поспорить — теперь вижу конкретные точки расхождения.

S>Спасибо!

Редкий спор на RSDN оканчивается на такой ноте
Респект обоим!

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

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

S>Ух ты — после всех "давай закончим" мы всё ещё продолжаем.
Так это совсем другое дело.

S>Кто же первый сдастся?...
Я уже сдался.

Я не вижу с твоей стороны желания понять о чем же я говорю. Вижу только желание поспорить.

Ёк... мы ходим по кругу...
Z>У меня сложилось впечатление, что единственно правильной ты считаешь примерно такую методологию: сбор всех требований, детальная разработка архитектуры с закладыванием на дальнейшее расширение и вероятное измененение требований. Только потом наступает этап кодирования.

Неа Про планирование — как то так (ни разу не уверен в корректности):

Выделение предметной области, получение модели, отображение сущностей, правил, связей и функционирования предметной области на модель данных.
Параллельно: Анализ бизнес-требований, перевод их в терминологию предметной области, построение функциональной модели как набора операций над моделью данных, проектирование отображение модели данных в наборы сущностей БЛ. Заметьте, что данные системы могут (и скореке всего будут) отличаться от данных, обрабатываемых в отдельных юз-кейсах. Где-то вы работаете со всеми личными данными, где-то достаточно ф.и.о, а где-то ф.и.о — просто часть другой сущности, например "сотрудник". В любом случае БЛ работает с отображением одних и тех же данных, но никак не с самими данными и (не дай бог) не дублирует одну и туже информацию.
Параллельно: Анализ требований к продукту, выделение базовых подсистем, выбор технологий реализации — на основе модели предметной области.
Параллельно: Допиливание инструментария/методологии (если требуется).

Я не углубляюсь в тонкости реализации/разбиения на этапы/всего прочего. Оно очень зависит от команды, а рисовать сферических коней как-то глупо. Но вышеперечисленное явно или косвенно будет присутствовать всегда.

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

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

И никакой магии

---

[поскипано]

У нас совсем разные понятия о том, что относить к архитектуре. Вы (как мне кажется) сильно упираете на требования как источник информации. Цель управления проектом — снижение стоимости адаптация под непредсказуемо изменяющиеся требования.

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

Всё остальное — следствие расхождения понятий. Для вас возможно всё что я пишу кажется ересью. Для меня кажется неразумным построение архитектуры на непроверенных и нестабильных данных, которые только косвенно отражают действительность.

S>>Про требования мы вроде уже кучу раз говорили — их всё равно нет смысла рассматривать как нечто вечное. Вроде уже писал, что как правило требования не выходят за рамки описываемого предметной областью — нет?
Z>Выделенного я не понял. Требования это функционал, предметная область абстрагируется в модель с которой приходится работать, они сильно влияют друг на друга, но ни одно из них не является функцией от другого.

Уххх...

Как бы попрощее.
Когда заказчик от вас чего-то требует — он ведь это не просто так хочет, нет? Его требования — следствие изменений в деятельности заказчика или следствие того, что вы не пошлностью отразили в продукте эту деятельность. Если смотреть на деятельность только через требования — изменения в требованиях кажутся бессистемными, сегодня хотят одно — завтра доугое и т.п. Если смотреть с точки зрения заказчика — ситуация абсолютно другая. Поменялись правила игры, следом меняются требования а эти [censored] по-прежнему живут в прошлом квартале и удивляются "а чего это нужны новые отчёты — всё ж работает".

И в третий наверно раз:
Если модель строить не от требований заказчика а от окружающей среды — которая определяет эти самые требования — то изменений в модели будет гораздо меньше, потому что предметная область стабильней требований заказчика и новые сущности/связи/правила в ней появляются куда реже. Ну а раз уж они там появятся — они появятся и у вас, заказчик ведь не в вакууме живёт Есть только выбор — узнавать о изменениях косвенно, через изменение требований или самим узнавать о изменениях и менять модель в ответ на изменения в деятельности заказчика.

Я не знаю как подробней разжевать эту идею — не гений Спрашивайте конкретно — попробую конкретно ответить.

P.S. Изчезло до понедельника. Не скучайте

S>Редкий спор на RSDN оканчивается на такой ноте

Ага, мы такие, только никак не успокоимся... Са-анита-а-ар!!!

P.S. Уже почти ушло

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

S>Выделение предметной области, получение модели, отображение сущностей, правил, связей и функционирования предметной области на модель данных.
S>Параллельно: Анализ бизнес-требований, перевод их в терминологию предметной области, построение функциональной модели как набора операций над моделью данных, проектирование отображение модели данных в наборы сущностей БЛ. Заметьте, что данные системы могут (и скореке всего будут) отличаться от данных, обрабатываемых в отдельных юз-кейсах. Где-то вы работаете со всеми личными данными, где-то достаточно ф.и.о, а где-то ф.и.о — просто часть другой сущности, например "сотрудник". В любом случае БЛ работает с отображением одних и тех же данных, но никак не с самими данными и (не дай бог) не дублирует одну и туже информацию.
S>Параллельно: Анализ требований к продукту, выделение базовых подсистем, выбор технологий реализации — на основе модели предметной области.
S>Параллельно: Допиливание инструментария/методологии (если требуется).

Все верно, ты понимаешь, что нельзя плясать только от предметной области и доменной модели и параллельно анализируешь требования к продукту. Только что-то мешает тебе признать, что требования к продукту превичны. Именно ими руководствуются при созданиии доменной модели. Ибо некий документ в предметной области в зависимости от требований к продукту может быть представлен как кортеж (№, автор) или как пдф или как набор версионированых документов со множеством связей.

[рассуждения о том, что все зависит от ситуации поскипаны как не несущие полезного]

S>У нас совсем разные понятия о том, что относить к архитектуре. Вы (как мне кажется) сильно упираете на требования как источник информации. Цель управления проектом — снижение стоимости адаптация под непредсказуемо изменяющиеся требования.

S>Я (как мне кажется) — на стабильную информацию, что можно выдернуть из модели предметной области, из используемых технологий, из долгоживущих требований. Цель — изоляция возможных изменений, чтобы они затрагивали как можно меньше зависимостей.

В этом и есть ваша ошибка, модель сильно зависит от требований и часто меняется вместе с ними.

S>Всё остальное — следствие расхождения понятий. Для вас возможно всё что я пишу кажется ересью. Для меня кажется неразумным построение архитектуры на непроверенных и нестабильных данных, которые только косвенно отражают действительность.

Любая абстракция (а модель это абстракция) косвенно отражает действительность. Она включает в себя только те данные, которые нам требуются (от слова требования).

S>Как бы попрощее.
Проще:
Верное утверждение1: модель зависит от требований, предметной области и особенностей заказчика.
Верное утверждение2: требования зависят заказчика и предметной области.
Неверные утверждения: модель зависит только от предметной области, модель зависит только от требований, требования зависят только от предметной области.

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

S>Когда заказчик от вас чего-то требует — он ведь это не просто так хочет, нет? Его требования — следствие изменений в деятельности заказчика или следствие того, что вы не пошлностью отразили в продукте эту деятельность.

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

S>Если модель строить не от требований заказчика а от окружающей среды — которая определяет эти самые требования — то изменений в модели будет гораздо меньше, потому что предметная область стабильней требований заказчика и новые сущности/связи/правила в ней появляются куда реже. Ну а раз уж они там появятся — они появятся и у вас, заказчик ведь не в вакууме живёт Есть только выбор — узнавать о изменениях косвенно, через изменение требований или самим узнавать о изменениях и менять модель в ответ на изменения в деятельности заказчика.

Смотри пример про модель документа в начале сообщения. Если мы при тщательном анализе предметной области поймем, что документ на самом деле является версионированной сущностью с 200 сложными атрибутами и заложим эту модель, забив на то, что для нормального функционирования приложения интересено только количество подобных документов за месяц — мы потритим много лишних денег на реализацию этой модели, правила поведения документов. А самое дерьмовое, что мы заставим работников заказчика часами вбивать все эти данные в систему вместо одной паршивой цифры. С хорошей вероятностью никогда ими не воспользоваться в системе.

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

S>Мои извинения Аноним'у, слегка отвык от адекватных собеседников... ужс-ужс...

А>>2. Можно показать на то, что я, по-вашему, невнимательно прочитал? Я перечитаю.
S>Изначально имелось ввиду моё непонимание стралочек (уже замяли ). Но можно притянуть за уши и мой коммент насчёт изоляции проблем с UI:
S>

S>Тем не менее в вашем примере я бы постарался изолировать проблему — чтобы её решение не затрагивало остальную часть системы. Будете смеяццо, но в принципе решаемо даже при описанном подходе — отображение живёт в UI и code behavior — всё остальное не ломается (я не говорю о сервере, ему вообще параллельно). Excel кстати как ActiveX компоненту можно захостить... //ужас-ужас...

Это все быстро превращается в помойку, которую ни понять, ни изменить. Только выкинуть.

— Зачем вы хостите Excel как ActiveX, Ватсон?
— Э-э..., Холмс, дружище, юзера сказали, что им надо кольцевую диаграмму.
— Так это же элементарно, Ватсон: возьмите Chart.Net (название, конечно, вымышлено). Зачем тащить целый Excel?
— Видите ли Холмс, наши представления могут расширяться только COM-объектами... Бэрримор не нашел на рынке ничего подходящего.
— А почему именно так?
— Тс-с-с! Наш директор, сэр Генри — фанат IUnknown'а и C++. Он избегает .Net'а, потому, что уверен, что тот тормозит.
— Ну и как, а Excel ему теперь не тормозит?
— А... Э...

S>Просто в моём восприятии конечный продукт — очень сложная штука, и внешние интерфейсы — это нечто вроде вершины айсберга, которые не могут (да и не должны) определять логику работы. Согласитесь, при таком подходе кажется странным проектировать систему на основе требований. Ведь требования в основе своей есть описание тех самых внешних интерфейсов, и никакой значимой информации о внутренностях "идеальной системы" из них не вытрясешь.

В своем первоначальном посте я специально оговорил, что, цитирую, "В случае продуктов, рассчитанных на массовый рынок, я бы сказал так". Поэтому, вы правильно делаете, что не говорите о сервере. Тут можно вспомнить "Пять миров" Джоэля (хоть и не люблю я его).

Софт, о котором идет речь, взаимодействует больше всего с юзером. Это не строгие дефиниции, можно и про серверный софт, в принципе, сказать то же самое, мол, ввели в консольку то-то и он начал делать то-то, но взгляд с этой точки не будет продуктивным. Непродуктивно рассматривать SQL-сервер с точки зрения на пользовательский интерфейс консоли. А вот какой-нибудь Ворд — продуктивно.

Далее, вы говорите об изоляции проблемы — но дизайн интерфейса сам по себе изолирует проблему разработки продукта. Пользователь Ворда не знает, по какой архитектуре что сделано. Он этого даже не видит. Но он точно знает, что происходит, когда он нажимает на такую-то кнопочку. И если есть два продукта, которые делают одно и то же при нажатии на кнопочку, юзеру наплевать, какая там архитектура. Вообще, из чего состоит любой такой продукт глазами юзера? Из интерфейса и торговой марки. Все. Причем, интерфейс — это же не просто цвет кнопок или их расположение. Это и то, что софт сохраняет файлы в Мои документы, а не в корень, куда доступ может быть запрещен админом. И т.д. и т.п.

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

Архитектура — о том, как правильно напихать в эти границы кода, чтоб получился настоящий айсберг. Конечно, тут есть свои нюансы. Допустим, чтобы устроить какую-нибудь малозаметную шишечку на поверхности, придется потратить уйму времени и дико усложнить содержание. Ну так на этапе архитектуры встает вопрос о том, что в дизайн закралась самоубийственная опция. Возможно, что дизайнеры поправят это дело, если это действительно левая фичка. А если нет? Если это ОЧЕНЬ важно? Тогда архитекторы стиснут зубы и пойдут ее бороть. Понимаете? А если бы дизайн не прорабатывался с бОльшим приоритетом, тогда этот вопрос ВООБЩЕ БЫ НЕ ВСТАЛ. А потом, когда стало ясно, что без этой фички на рынке делать нечего, начинается архитекторская истерика. Вы не думайте, что это из пальца высосано. Я бы не стал даже думать про какие-то там цепочки, типа "требования-UI-архитектура-код", если бы меня жизнь носом в них не натыкала сто раз.

Что касается требований — требования, это типа "ПО должно выдавать аналитический отчет о". Круговая диаграмма — это уже дизайн. Это дальнейшее уточнение, но кроме того — творчество.

S>Ну ведь глупо рассматривать горы функционала, внутренние структуры данных, составные части, ту же многозвенку и много чего ещё со стороны потребностей пользователя, точнее со стороны взаимодействия с пользователем. Оно ему вообще ведь не надо. 1с хватит. Или ацесса. Или фокспро. Или вообще экселя.

Глупо — что? То, что вы перечислили, вполне может быть результатом проектирования UI. А может и не быть. Нужно на примерах разбирать.

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

S>Пока из общения с товарищами выходит что проектирование чисто от требований — нормальный подход. Смущает две вещи — то, что требования направлены на решение текущих задач и строить на их основе архитектуру системы — как то не того...
S>и то, что эти вопросы в принципе не подымаются в "тру" методологиях — такие вопросы отдаются на откуп архитекторам (если он есть) или обходятся кучей методик (не будем о DDD — про неё даже Эванс не может уверенно сказать что оно такое, куда уж простым смертным )

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

Первое — что такое "архитектура". Нет единого понимания данного термина, что служит поводом для спекуляций.

Определяем три термина. Архитектура, дизайн, детальный дизайн.

Детальный дизайн — алгоритмы и структуры данных.
Дизайн — разбиение функциональности по компонентам, модулям, или классам.
Архитектура — то, что не перечисленное. Комплекс базовых технологий, на которые опирается решение, плюс — идиом или паттернов проектирования, заложенных в "ядро", "фреймворк", или философию построения системы. Если перечисленное вообще есть. Скажем, вы решили, что сериализация объектов у вас будет всегда в XML — это архитектурное решение.

Дизайн и архитектуру часто путают.

S>Это я дурак и что-то упустил или это такая модель бизнеса — "Сделаем всё за деньги. Не понравилось — платите, не можете сформулировать хотелки — платите, ошиблись — платите"? Потому что я не могу больше придумать доводов, зачем так опровергать тот факт, что архитектура не может быть построена на информации о сиюминутных целях.

Разумеется, надо принимать во внимание как требования, так и технические ограничения, так и ваши возможности (знаем Java — архитектура будет базироваться на Java а не дотнет). Будущие требования тоже имеют значение. Главное, архитектуру не путайте с дизайном. Думаю, как только вы мои определения почитали, вам уже все стало понятнее, не так ли? .

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

G>Первое — что такое "архитектура". Нет единого понимания данного термина, что служит поводом для спекуляций.

Странно. Берем IEEE 1471-2000 и читаем:
architecture:
The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.
Далее, если говорить простыми словами, авторы стандарта показывают, что архитектура системы по сути является представлениями системы в виде двух "ящиков": "черного" -- с точки зрения взаимодействия с окружением; и "прозрачного" -- с точки зрения взаимодействия элементов внутренней структуры.

G>Определяем три термина. Архитектура, дизайн, детальный дизайн.
G>Детальный дизайн — алгоритмы и структуры данных.
G>Дизайн — разбиение функциональности по компонентам, модулям, или классам.
G>Архитектура — то, что не перечисленное. Комплекс базовых технологий, на которые опирается решение, плюс — идиом или паттернов проектирования, заложенных в "ядро", "фреймворк", или философию построения системы.

Положим, архитектура не есть дизайн, т.е. не включает в себя множество компонентов, алгоритмов и структур данных, но включает в себя комплекс базовых технологий и паттернов проектирования ("ядро" и "фреймворк" пока отложим в сторону, потому как из определения не очень понятно, являются они частью архитектуры или нет, как и метафорическое понятие "философия построения"). Что есть "паттерн проектирования"? В википедии не дано внятного определения, однако в тексте там говорится о повторяемых [или характерных] отношениях и взаимодействиях (тавтология, кстати) между объектами или классами и т.д., при этом "участники" паттерна не являются конкретными классами/объектами, а лишь абстрактными ролями в отношении, который описывается паттерном. Однако при реализации паттерна в "дизайне" абстрактные роли в отношении, определяемом паттерном, трансформируются во вполне конкретные элементы "дизайна": интерфейсы, объекты-медиаторы и т.п., т.е. паттерн становится частью дизайна, особенно, если мы понимаем под "детальным дизайном" одно и то же -- алгоритмы и структуры данных. Хотя можно, конечно, упереться и объявить паттерн и реализацию паттерна разными вещами и упражняться в риторике до посинения.

Кстати, если рассматривать использование xml для сериализации в качестве архитектурного решения в отрыве от дизайна и ограничений на дизайн, то могут получаться удивительные по своей абсурдности вещи, как в некоторых middleware, когда для передачи по сети одного скалярного значения риалтаймовых данных с меткой времени требуется посылать по "веревке" килобайт xml-ной чепухи.

G>Главное, архитектуру не путайте с дизайном. Думаю, как только вы мои определения почитали, вам уже все стало понятнее, не так ли? .

И как же их не путать то? Может, для пользы дела примем дизайн/детальный дизайн в качестве одного из архитектурных представлений?

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

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

G>>Первое — что такое "архитектура". Нет единого понимания данного термина, что служит поводом для спекуляций.

AL>Странно. Берем IEEE 1471-2000 и читаем:
AL>architecture:
AL>The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.
AL>Далее, если говорить простыми словами, авторы стандарта показывают, что архитектура системы по сути является представлениями системы в виде двух "ящиков": "черного" -- с точки зрения взаимодействия с окружением; и "прозрачного" -- с точки зрения взаимодействия элементов внутренней структуры.

Действительно странно. Особенно странно то, что многие "серьезные дядьки" либо не знакомы с этим определением, либо не ставят его во грошь. А теперь берем базовый архитектурный курс по MCSD, и читаем там совсем другое, до крайности мутное определение, которое я даже затрудняюсь воспроизвести. Берем PSP/TSP, и не находим там термина "архитектура" вовсе. Что делать будем? Откроем википедию:

The distinction from detailed design
Software architecture, also described as strategic design, is an activity concerned with global design constraints, such as programming paradigms, architectural styles, component-based software engineering standards, design principles, and law-governed regularities. Detailed design, also described as tactical design, is an activity concerned with local design constraints, such as design patterns, architectural patterns, programming idioms, and refactorings. According to the Intension/Locality Hypothesis[9], the distinction between strategic and tactical design is defined by the Locality Criterion[9], according to which a statement about software design is non-local if and only if a program that satisfies it can be expanded into a program which does not. For example, the Client-Server style is architectural (strategic) because a program that is built by this principle can be expanded into a program which is not client server; for example, by adding peer-to-peer nodes.
Architecture is design but not all design is architectural. In practice, the architect is the one who draws the line between software architecture (architectural design) and detailed design (non-architectural design). There aren't rules or guidelines that fit all cases.

Получаем, некоторые другие авторы понимают "архитектуру" как "стратегический" дизайн, отличающийся от "тактического". И это по сути единственное, на чем все сходятся. Только и всего.

Есть разные системы определений. Каким надо пользоваться? Удобным в текущий момент, конструктивным, которое делает ситуацию очевидным. Мое тройное определение четко отделяет 100% "тактические" решения (алгоритмы и структуры данных), 100% стратегические (парадигмы и функдаментальные решения, вроде применения "клиент-сервер", плюс — прикладные фрейморки и их правила, если они есть), и те, что на границе (разбиение по модулям и прочим компонентам, и отношения между ними).

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

G>>Определяем три термина. Архитектура, дизайн, детальный дизайн.
G>>Детальный дизайн — алгоритмы и структуры данных.
G>>Дизайн — разбиение функциональности по компонентам, модулям, или классам.
G>>Архитектура — то, что не перечисленное. Комплекс базовых технологий, на которые опирается решение, плюс — идиом или паттернов проектирования, заложенных в "ядро", "фреймворк", или философию построения системы.

AL>Хотя можно, конечно, упереться и объявить паттерн и реализацию паттерна разными вещами и упражняться в риторике до посинения.

Давай не будем.

AL>Кстати, если рассматривать использование xml для сериализации в качестве архитектурного решения в отрыве от дизайна и ограничений на дизайн, то могут получаться удивительные по своей абсурдности вещи, как в некоторых middleware, когда для передачи по сети одного скалярного значения риалтаймовых данных с меткой времени требуется посылать по "веревке" килобайт xml-ной чепухи.

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

Еще пример — решаем, что все прикладные объекты хранят свое состояние в реляционной БД. Со всеми вытекающими, в частности — некая общая подсистема управления этим состоянием.

Архитектура в таком определении слабо зависит от конкретных требований. Она скорее накрывает некий "класс" или "метакласс" возможных требований. Непосредственно сами требования реализуются дизайном (в рамках ограничений, заданных архитектурой).

G>>Главное, архитектуру не путайте с дизайном. Думаю, как только вы мои определения почитали, вам уже все стало понятнее, не так ли? .

AL>И как же их не путать то? Может, для пользы дела примем дизайн/детальный дизайн в качестве одного из архитектурных представлений?

Следуя предложенному мной определению, не перепутать довольно легко.

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

G>Первое — что такое "архитектура". Нет единого понимания данного термина, что служит поводом для спекуляций.

G>Определяем три термина. Архитектура, дизайн, детальный дизайн.

G>Детальный дизайн — алгоритмы и структуры данных.
G>Дизайн — разбиение функциональности по компонентам, модулям, или классам.
G>Архитектура — то, что не перечисленное. Комплекс базовых технологий, на которые опирается решение, плюс — идиом или паттернов проектирования, заложенных в "ядро", "фреймворк", или философию построения системы. Если перечисленное вообще есть. Скажем, вы решили, что сериализация объектов у вас будет всегда в XML — это архитектурное решение.

Я не согласен с такими определениями. На мой взгляд архитектура — это, в первую очередь, "набор решений по организации программной системы: выбору элементов структуры этой системы, их интерфейсов и поведения, задаваемого кооперациями между элементами". Т.е. разбиение системы на подсистемы. При таком разбинении также учитываются нефункциональные требования. И самое важное отличие архитектуры от всего остального в том, что архитектура содержит только самые важные элементы системы — остов, скелет.

Определение дизайна я дать не могу. Но я бы предположил, что указанные три термина могли бы обозначать следующее:
Возмем систему, со всеми ее классами и пр. = Детальный дизайн
Выкинем из классов код, оставим только интерфейсы (описания) классов = Дизайн
Выкинем все "лишние" классы, оставим только минимальное необходимое количество для функционирования системы, объединим в подсистемы = Архитектура
Естественно, при проектировании порядок будет противоположный, но это так, для иллюстрации.

Отсюда же следует, что алгоритмы и структуры данных ортогональны этим определениям.

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

G>Действительно странно. Особенно странно то, что многие "серьезные дядьки" либо не знакомы с этим определением, либо не ставят его во грошь. А теперь берем базовый архитектурный курс по MCSD, и читаем там совсем другое, до крайности мутное определение, которое я даже затрудняюсь воспроизвести. Берем PSP/TSP, и не находим там термина "архитектура" вовсе. Что делать будем?

Я на серьезных дядек типа Рэмбо, Буча и ко. как бы и не ссылаюсь, ибо пустое это дело -- ссылаться на авторитетных дядек А в PSP/TSP легко найти термин "архитектура" в том смысле, что PSP/TSP к архитектуре, требованиям и прочей технической ерунде вроде как ортогональны:

PSP-BOK v1.0:
1.1 PURPOSE
... there are categories of software and other engineering knowledge that are not represented in the PSP BOK (architecture, requirements definition,
hardware design, etc.), although it is assumed that a proficient software professional will have some degree of familiarity with such topics.

G>Получаем, некоторые другие авторы понимают "архитектуру" как "стратегический" дизайн, отличающийся от "тактического". И это по сути единственное, на чем все сходятся. Только и всего.

Пусть другие авторы сходятся, на чем угодно, -- нет проблем. Стратегический дизайн, так стратегический, -- лишь бы не был чисто метафорическим и имел под собой что-то осязаемое и полезное как для разработчиков, так и заказчиков/пользователей.

G>Еще пример — решаем, что все прикладные объекты хранят свое состояние в реляционной БД. Со всеми вытекающими, в частности — некая общая подсистема управления этим состоянием.

Боюсь, не всегда получится принять такое решение на уровне стратегии, не вдаваясь в детали и не решив вопросы о том, что такое в данном случае "прикладной объект", что такое "состояние прикладного объекта" и что значит "хранят состояние". Вернее, получиться-то может и получится, но потом может быть мучительно больно из-за последствий такого стратегического решения.

G>Архитектура в таком определении слабо зависит от конкретных требований. Она скорее накрывает некий "класс" или "метакласс" возможных требований. Непосредственно сами требования реализуются дизайном (в рамках ограничений, заданных архитектурой).

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

Здравствуйте, Ziaw!

Либо у меня больное самомнение либо вы пытаетесь увести разговор в сторону. Смотрите сами:

Z>Все верно, ты понимаешь, что нельзя плясать только от предметной области и доменной модели и параллельно анализируешь требования к продукту. Только что-то мешает тебе признать, что требования к продукту превичны.

Гммм... забавный диалог. Я: "модель строится на основе информации взятой из предметной области". Вы: "требования к продукту превичны. Именно ими руководствуются при созданиии доменной модели."

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

Z>Именно ими руководствуются при созданиии доменной модели. Ибо некий документ в предметной области в зависимости от требований к продукту может быть представлен как кортеж (№, автор) или как пдф или как набор версионированых документов со множеством связей.

Не может документ _в предметной области_ быть представлен. Документ — это часть предметной области. Модель предметной области — это точное (в пределах разумного) её отражение. Начиная искажать модель мы непредсказуемо меняем стабильность модели. Оно нам надо?

Z>В этом и есть ваша ошибка, модель сильно зависит от требований и часто меняется вместе с ними.

От того, что заказчик придумал новый тип ценников кардинально поменялся принцип интернет-торговли??? Боюсь, вы ненамеренно включаете в модель быстро изменяющуюся информацию и заявляете что модель зависит от требований. Вы их разделите.
Хотя бы так: модель предметной области влияет на архитектуру, требования заказчика — на функционал. Хоть это и неправда...

Гммм... вот смотрите. Вы пишете автоматизацию логистики. Или интернет-магазин. Или социальную сеть. (во всём вышеперечисленном одинаково некомпетентен ). И везде-везде внутренняя логика работы зависит от требований заказчика???

Для вас предметная область функция от требований — "заказчик хочет магазин — сделаем". Для меня наоборот — заказчик работает в определённой области, он подчиняется правилам, принятым в этой области (не изобретает же он нечто совершенно особое?), и информация об этой области заведомо переживёт все его хотелки. Независимо от желания заказчика в магазине будут товары, персонал, покупатели и т.п. и будут известны некоторые "правила игры" типа "персонал не продаётся" (ну это смотря какой магазин...).

Предметная область _независима_ от желаний заказчика. Как бы он не выёживался, ничего нового в рамках области он не придумает — он играет по правилам. Правила неявно присутствуют в каждом требовании и выцарапать их оттуда практически невозможно. Но если поменяются правила — поменяются требования и вам всё равно придётся изменять продукт. Только разница будет в том, что в первом случае вы _знаете_ причину изменений, а во втором _угадываете_.

Z>Любая абстракция (а модель это абстракция) косвенно отражает действительность. Она включает в себя только те данные, которые нам требуются (от слова требования).
Дыкть это критерий построения модели. Вы жертвуете стабильностью ради детализации и отвечаете так как будто этоо единственно возможный подход.

Z>Верное утверждение1: ...
Вы даёте свои определения которые не имеют ничего общего с исходными посылками. Так можно доказать что угодно. Не будем

Z>Логично, имея на входе закачика и предметную область, сначала получить и изучить требования, а потом применить утверждение 2 и разработать модель. Проектируя модель без учета требований нам придется переделывать ее гораздо чаще.
Ещё раз. Если модель предметной области _не отражает требования_ и не зависит от них — почему она будет меняться????

S>>Когда заказчик от вас чего-то требует — он ведь это не просто так хочет, нет? Его требования — следствие изменений в деятельности заказчика или следствие того, что вы не пошлностью отразили в продукте эту деятельность.
Z>Продукт разрабатывается для вполне конкретных целей. Полное отражение деятельности заказчика в продукте это не цель и никому особо не интересно, всегда оперируют необходимым минимумом информации.
Тут два варианта. Либо вы намеренно передёргиваете мои слова пытаясь выставить меня идиотом, либо вы считаете меня идиотом и уверены, что я на полном серьёзе рассматриваю возможность полного отражения деятельности заказчика. Я не могу каждую свою строчку сопровождать дисклаймером. 9/10 моих ответов — либо повторение уже написанного либо комменты и разъяснения. Не будем уходить от темы.

Z>Если мы при тщательном анализе предметной области поймем, что документ на самом деле является версионированной сущностью с 200 сложными атрибутами и заложим эту модель...

Снова то же самое. Откуда вы взяли что модель предметной области должна быть целиком отображена в архитектуре/коде?

Если _в данной части системы_ документ должен быть отображён циферкой — он и _должен_ быть отображён циферкой для данной части системы. Но то, что _на самом деле_ документ — сложная сущность — должно быть учтено в архитектуре. Ваша система будет жить в вакууме? Она не будет взаимодействовать с другими системами?

Если документ — важная часть предметной области — то он по-любому рано или поздно всплывёт в требованиях. Если документ — "из другого мира" и нас интересует только конкретное его отображение — мы это отображение и используем, предусмотрев возможность получения этого отображения из других источников. Ведь та самая циферка не из воздуха берётся, а как-то зависит от 200 полей. Или вы предлагаете что и она должна быть вбита ручками и должна перебиваться каждый раз при изменении зависимостей?

Сорри за чрезмерную резкость. Ничего личного

Здравствуйте, Аноним!

А>Это все быстро превращается в помойку, которую ни понять, ни изменить. Только выкинуть.

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

S>>Просто в моём восприятии конечный продукт — очень сложная штука, и внешние интерфейсы — это нечто вроде вершины айсберга, которые не могут (да и не должны) определять логику работы. Согласитесь, при таком подходе кажется странным проектировать систему на основе требований. Ведь требования в основе своей есть описание тех самых внешних интерфейсов, и никакой значимой информации о внутренностях "идеальной системы" из них не вытрясешь.

А>В своем первоначальном посте я специально оговорил, что, цитирую, "В случае продуктов, рассчитанных на массовый рынок, я бы сказал так". Поэтому, вы правильно делаете, что не говорите о сервере. Тут можно вспомнить "Пять миров" Джоэля (хоть и не люблю я его).

А для массовых продуктов логика зависит только от гуя? и нет ни работы с сетью, ни многопоточности (а потоковая модель тех же цштащкьы имеет свои ограничения...), ни файликов? Как эти задачи определяются гуем? Да, Джолэла я тоже не люблю (если это который Joel on Software и FogsBugz).

А>Софт, о котором идет речь, взаимодействует больше всего с юзером... Непродуктивно рассматривать SQL-сервер с точки зрения на пользовательский интерфейс консоли. А вот какой-нибудь Ворд — продуктивно.

Непродуктивно. С точки зрения пользователя спеллчекер — это красные полосочки под словами. Опишите мне архитектуру спеллчекера на основе вышеприведённого. Я молчу про подпись документов, поддержку кастомныхх конвертеров/надстроек/макросов, печать и несколько видов отображения документа, которые предоставляют волзможность делать одно и то же различными способами.

А>Пользователь Ворда не знает, по какой архитектуре что сделано ... Но он точно знает, что происходит, когда он нажимает на такую-то кнопочку ... Вообще, из чего состоит любой такой продукт глазами юзера? Из интерфейса и торговой марки. Все. Причем, интерфейс — это же не просто цвет кнопок или их расположение. Это и то, что софт сохраняет файлы в Мои документы, а не в корень...

Вы продаёте продукты или вы их пишете? Если второе — к чему вышенаписанное? Архитектура нужна вам, потому что она стабилизирует продукт, заставляет думать перед тем как делать и явно показывает вам, где у вас проблемы, не укладывающиеся в текущую концепцию развития продукта. Вы же не хотите закрывать глаза на существующие проблемы? Я могу ещё и маркетинговую составляющую расписать — про конкурентоспособность и прочее.

Кстати, с вашей точки зрения 2003 и 2007-й офисы — совершенно разные продукты. И у MS даже теоретичестки не должнобыло получиться внести кардинальные изменения в гуй не переписав весь офис с нуля.

А>Поэтому, это не вершина айсберга. Это, продолжая вашу метафору — полная поверхность айсберга, включая его подводную часть (куда по умолчанию сохранять файлы, можно ли подключаться к серверу, как осуществляется вставка других объектов других софтов — ну, вы поняли).

Ок. У вас требование "я хочу айсберг в форме перевёрнутой пирамиды". Расскажите мне как из этого требования вы узнаете хоть что-то про внутренности аёсберга. Или это проблемы архитекторов?


А>Что касается требований — требования, это типа "ПО должно выдавать аналитический отчет о". Круговая диаграмма — это уже дизайн. Это дальнейшее уточнение, но кроме того — творчество.

Неа Отчёт — это метод реализации. Тру-требование читается так: "продукт должен проводить анализ..." + "результаты анализа доолжны быть представлены в виде ... (а вот здесь и описыцвается как)".

Продолжим?
S>>Ну ведь глупо рассматривать горы функционала, внутренние структуры данных, составные части, ту же многозвенку и много чего ещё со стороны потребностей пользователя, точнее со стороны взаимодействия с пользователем. Оно ему вообще ведь не надо. 1с хватит. Или ацесса. Или фокспро. Или вообще экселя.

А>Глупо — что? То, что вы перечислили, вполне может быть результатом проектирования UI. А может и не быть. Нужно на примерах разбирать.

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

S>Пока из общения с товарищами выходит что проектирование чисто от требований — нормальный подход. Смущает две вещи — то, что требования направлены на решение текущих задач и строить на их основе архитектуру системы — как то не того...
Системный аналитик определяет требования к системе. До него может поработать еще бизнес-аналитик, который работает выше — на уровне целей заказчика.
Вот их задача выявить требования, в том числе предусмотреть "вероятные требования", т.е. вероятное развитие системы.

Архитектор выдяеляет архитектурно-важные требования и строит архитектуру. Все это есть в RUP например.

S>и то, что эти вопросы в принципе не подымаются в "тру" методологиях — такие вопросы отдаются на откуп архитекторам (если он есть) или обходятся кучей методик (не будем о DDD — про неё даже Эванс не может уверенно сказать что оно такое, куда уж простым смертным )
Архитектор — "технарь", он не должен выдумывать требования

Здравствуйте Gaperton'у!

G>"Учителя разных школ психотерапии имеют больше общего между собой, чем их ученики — с ними". Слишком много придаете значения методологиям и букве. Они на самом деле все об одном, фундаментальной разницы между ними нет.

Я знал, я знал Была у меня такая мыслишка... — уж слишком много уделяется внимания уникальности методологии и священным методикам. Скромно посчитал, что я ещё не проникся вселенской мудростью

G>Детальный дизайн — алгоритмы и структуры данных.
G>Дизайн — разбиение функциональности по компонентам, модулям, или классам.
G>Архитектура — то, что не перечисленное. Комплекс базовых технологий, на которые опирается решение, плюс — идиом или паттернов проектирования, заложенных в "ядро", "фреймворк", или философию построения системы. Если перечисленное вообще есть. Скажем, вы решили, что сериализация объектов у вас будет всегда в XML — это архитектурное решение.

Ок. Принято. Вопрос: должен ли дизайн (с архитектурой вроде всем ясно) проектироваться исключительно на основе требований? (Вопрос провокационный, больше чтобы было от чего идти). Если нет, как можно компенсировать перекос дизайна из-за учёта только актуальных требований?


S>>Это я дурак и что-то упустил или это такая модель бизнеса — "Сделаем всё за деньги. Не понравилось — платите, не можете сформулировать хотелки — платите, ошиблись — платите"? Потому что я не могу больше придумать доводов, зачем так опровергать тот факт, что архитектура не может быть построена на информации о сиюминутных целях.

G>Разумеется, надо принимать во внимание как требования, так и технические ограничения, так и ваши возможности (знаем Java — архитектура будет базироваться на Java а не дотнет). Будущие требования тоже имеют значение. Главное, архитектуру не путайте с дизайном. Думаю, как только вы мои определения почитали, вам уже все стало понятнее, не так ли? .

Да-да, уже легче Вообще-то вопрос был о том, почему два-три товарища так настойчиво утверждают, что "архитектура — функция от требований". Пока ответ -"расхождение в определениях". Остались смутные сомнения — может товарищей всё-таки посетило дао?

Интересно также ваше мнение про модель бизнеса — я не могу придумать других рациональных объясенений такой агрессивной пропаганде решений "здесь и сейчас". Или это только моя мнительность и кто-то кроме вас говорил о "надо принимать во внимание как требования, так и технические ограничения, так и ваши возможности" и "Будущие требования тоже имеют значение"?

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

S>Здравствуйте, Аноним!

А>>Это все быстро превращается в помойку, которую ни понять, ни изменить. Только выкинуть.

S>Гммм... я не понимаю как "изоляция проблемы" может превратить архитектуру в помойку. Мне казалось, что оно наоборот должно предотвращать помойку...

S>>>Просто в моём восприятии конечный продукт — очень сложная штука, и внешние интерфейсы — это нечто вроде вершины айсберга, которые не могут (да и не должны) определять логику работы. Согласитесь, при таком подходе кажется странным проектировать систему на основе требований. Ведь требования в основе своей есть описание тех самых внешних интерфейсов, и никакой значимой информации о внутренностях "идеальной системы" из них не вытрясешь.

А>>В своем первоначальном посте я специально оговорил, что, цитирую, "В случае продуктов, рассчитанных на массовый рынок, я бы сказал так". Поэтому, вы правильно делаете, что не говорите о сервере. Тут можно вспомнить "Пять миров" Джоэля (хоть и не люблю я его).

S>А для массовых продуктов логика зависит только от гуя? и нет ни работы с сетью, ни многопоточности (а потоковая модель тех же winforms имеет свои ограничения...), ни файликов? Как эти задачи определяются гуем? Да, Джолэла я тоже не люблю (если это который Joel on Software и FogsBugz).

Так. Штрафной вам. Я специально обратил внимание, что не ГУЯ, а УЯ. А вы опять пишете — ГУЙ! Это уже не взаимное недопонимание, а результат вашего невнимательного прочтения. И теперь мне остается только второй раз написать то же самое.

Файлики — это часть дизайна интерфейса, в смысле, как им называться, куда сохраняться и т.д. Возьмем такой продукт как Outlook и его самый знаменитый файл — pst-шник. Это интерфейс, поскольку пользователь взаимодействует с этим файлом. Куча юз-кейсов завязана на его копирование и пр. Дизайн подразумевает, что весь контент хранится в нем, а архитектуре остается только плясать в этих рамках. Архитектор может сделать некую БД, которая бинарно сохраняется в этот файл, как база mySQL представляет собой несколько файликов с невразумительными названиями на диске, а может сделать плоский файл. В первом случае ему придется заводить модуль (dll-ку или exe-шник), который обрабатывает запросы и возвращает датасеты, во-втором — скорее всего, достаточно простого класса-сериализатора массива. Вот это — архитектура поверх UI.

Далее. Работа с сетью — а подразумевается, что продукт работатет с сетью? Как? В спецификации дизайна описано — пользователь нажимает сюда, идет соединение с таким-то сервером по выбранному им протоколу? Если да — все прекрасно зависит. Если нет — ЗАЧЕМ такому продукту соединение с сетью? Ах, чтобы настучать о нелицензионности? Тогда это требование, и оно как-то обрабатывается дизайном (скорее всего, там будет стоять "соединение оставляется на усмотрение архитекторам", т.е. результат обработки — нулевой). Или чтобы запустить расчет на удаленном сервере, чисто для правильной архитектуры, хотя ни дизайн, ни требования такого не предусматривали? Что ж, последний случай — когда логика действительно НЕ зависит от UI, и от требований. Я же говорю: работа архитектора — тоже творческая. Кто сказал, что нельзя творить в рамках. Даже у картины есть рамка, что ж говорить про рамки, которые налагает дизайн на архитектуру?

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

А>>Софт, о котором идет речь, взаимодействует больше всего с юзером... Непродуктивно рассматривать SQL-сервер с точки зрения на пользовательский интерфейс консоли. А вот какой-нибудь Ворд — продуктивно.

S>Непродуктивно. С точки зрения пользователя спеллчекер — это красные полосочки под словами. Опишите мне архитектуру спеллчекера на основе вышеприведённого. Я молчу про подпись документов, поддержку кастомныхх конвертеров/надстроек/макросов, печать и несколько видов отображения документа, которые предоставляют волзможность делать одно и то же различными способами.

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

Спелчекер — это не просто красные полосочки. Это, во-первых, полосочки зигзагом. Вы знаете, когда-то давно я участвовал в проекте одного софта, где пользователь вводил тексты по формулам. Нарушения синтаксиса надо было "показывать как спелчекером" (требование). Так вот, от себя я (в роли дизайнера) дописал про зигзаг, обосновав это тем, что так сделано в Ворде и пользователь должен четко понимать, что это не элемент форматирования, а признак ошибки, а для этого надо скопировать один в один. И знаете что? До тех пор в качестве редактора предполагалось использование IE в режиме редактирования, а после — уже нет. ПОТОМУ, ЧТО В HTML ТОГДА НЕ БЫЛО ПОДЧЕРКИВАНИЯ ЗИГЗАГОМ! (Не знаю, как сейчас). Вот бы было весело, если бы архитектор действовал в первый черед, началоось бы всем известное: "архитектура не поддерживает, идите в опу".

(Правда, закончилось все Скинтиллой, которая тоже не поддерживала такое подчеркивание, но это потому, что процесс обсуждения между группами UI/архитектуры/кода и визионером проекта шел в сто итераций, нашлись и другие требования, и другие дизайнерские приоритеты, и другие архитектурные).

Далее, это полосочки, которые появляются не отвлекая пользователя от печатания текста.

Наконец, это полосочки, которые появляются под словами, не найденными в словаре.

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

А>>Пользователь Ворда не знает, по какой архитектуре что сделано ... Но он точно знает, что происходит, когда он нажимает на такую-то кнопочку ... Вообще, из чего состоит любой такой продукт глазами юзера? Из интерфейса и торговой марки. Все. Причем, интерфейс — это же не просто цвет кнопок или их расположение. Это и то, что софт сохраняет файлы в Мои документы, а не в корень...

S>Вы продаёте продукты или вы их пишете? Если второе — к чему вышенаписанное? Архитектура нужна вам, потому что она стабилизирует продукт, заставляет думать перед тем как делать и явно показывает вам, где у вас проблемы, не укладывающиеся в текущую концепцию развития продукта. Вы же не хотите закрывать глаза на существующие проблемы? Я могу ещё и маркетинговую составляющую расписать — про конкурентоспособность и прочее.

И то, и другое. Видимо поэтому я и вижу процесс полнее.

S>Кстати, с вашей точки зрения 2003 и 2007-й офисы — совершенно разные продукты. И у MS даже теоретичестки не должнобыло получиться внести кардинальные изменения в гуй не переписав весь офис с нуля.

Ну, я ж говорю: дизайн для вас — это гламурные тона. Если не считать цветовой схемы и убранной кастомизации, в MSO 2007 дизайн поменялся не очень много. Это во-первых. А во-вторых, у вас здесь логическая ошибка. Пусть дизайны различаются на все 100%. Придется ли при этом переписывать все с нуля? Ответ: необязательно. Зависит от дизайнов до и после. Может быть, оба разных дизайна вполне могут работать на одной и той же архитектуре.

Ключевой момент в том, что ИНОГДА — НЕ МОГУТ. Поэтому и надо давать дизайну более высокий приоритет. Это и вылезает из моей формулы.

А>>Поэтому, это не вершина айсберга. Это, продолжая вашу метафору — полная поверхность айсберга, включая его подводную часть (куда по умолчанию сохранять файлы, можно ли подключаться к серверу, как осуществляется вставка других объектов других софтов — ну, вы поняли).

S>Ок. У вас требование "я хочу айсберг в форме перевёрнутой пирамиды". Расскажите мне как из этого требования вы узнаете хоть что-то про внутренности аёсберга. Или это проблемы архитекторов?

Да, архитектора. Но не "проблемы", а "зона ответственности". Если такая чисто дизайнерская фишка, как перевернутость пирамиды, дорастает до статуса требования, наверное, это важно. Иначе, никто бы не стал такое требование писать. Не должны аналисты приносить такие требования, пока половина юзеров не скажет им — в микрософте айсберги перевернутые, и мы хотим такое же. Так вот, если такое требование попадает дизайнеру, ЧТО он может с ним сделать? Отдать архитектору, а уже тот пусть думает про центр тяжести и прочие дела.

То вы недовольны, что архитектору мало приходится решать, то — что много.

А>>Что касается требований — требования, это типа "ПО должно выдавать аналитический отчет о". Круговая диаграмма — это уже дизайн. Это дальнейшее уточнение, но кроме того — творчество.

S>Неа Отчёт — это метод реализации. Тру-требование читается так: "продукт должен проводить анализ..." + "результаты анализа доолжны быть представлены в виде ... (а вот здесь и описыцвается как)".

Я не учу своих клиентов тру-требованиям. Если они говорят мне, что "ПО должно выдавать аналитический отчет о", я это записываю. Я, впрочем, об этом тоже написал, и даже сказал, как это называется. Это называется path dependance. Когда все продукты на рынке выдают аналитические отчеты, пользователи автоматически начинают говорить в таких терминах.

S>Продолжим?
S>>>Ну ведь глупо рассматривать горы функционала, внутренние структуры данных, составные части, ту же многозвенку и много чего ещё со стороны потребностей пользователя, точнее со стороны взаимодействия с пользователем. Оно ему вообще ведь не надо. 1с хватит. Или ацесса. Или фокспро. Или вообще экселя.

А>>Глупо — что? То, что вы перечислили, вполне может быть результатом проектирования UI. А может и не быть. Нужно на примерах разбирать.

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

B>Определение дизайна я дать не могу. Но я бы предположил, что указанные три термина могли бы обозначать следующее:
B>Возмем систему, со всеми ее классами и пр. = Детальный дизайн

Код, это очевидно, не "детальный дизайн". Код — это код. Ошибка кодирования четко отличается от ошибки детального дизайна. Одно дело ошибиться в алгоритме, или выбрать неподходящую структуру данных, и совсем другое дело — ошибка кодирования. Определение детального дизайна я взял из PSP/TSP, где все эти определения берутся из классификатора ошибок. В UML для описания алгоритмов в принципе подойдет activity диаграмма, однако честнее и правильнее сказать что UML детальный дизайн не покрывает. Детальный дизайн — это уровень "псевдокода".

B>Выкинем из классов код, оставим только интерфейсы (описания) классов = Дизайн

Это дизайн. Вернее, один его не самый важный элемент — структурные модели, без поведения и потока данных. Кроме интерфейса у класса может быть протокол взаимодействия (state chart), и контракты. Кроме того, в системе есть разнообразные потоки данных и управления (sequence и collaboration диаграммы). Ничего из перечисленного не получается из интерфейсов классов.

B>Выкинем все "лишние" классы, оставим только минимальное необходимое количество для функционирования системы, объединим в подсистемы = Архитектура

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

B>Естественно, при проектировании порядок будет противоположный, но это так, для иллюстрации.

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

B>Отсюда же следует, что алгоритмы и структуры данных ортогональны этим определениям.

Отсюда много чего интересного следует, например — по вашему алгоритмы и структуры данных ортогональны тому самому коду (!), который вы выкинули из классов, назвав оставшееся дизайном . Любопытно, как же этот код, который вы выкинули, без алгоритмов-то и структур данных работает, а? Что в этом коде тогда написано, не объясните?

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

AL>Я на серьезных дядек типа Рэмбо, Буча и ко. как бы и не ссылаюсь, ибо пустое это дело -- ссылаться на авторитетных дядек А в PSP/TSP легко найти термин "архитектура" в том смысле, что PSP/TSP к архитектуре, требованиям и прочей технической ерунде вроде как ортогональны:

В PSP/TSP подобная техническая ерунда присутствует в классификаторе ошибок (весь их подход к оптимизации процесса базируется на анализе природы ошибки). И термины "детальный дизайн" и "дизайн" там определяются достаточно точно. Как и такие мероприятия как "design inspection", "detailed design inspection", и "code inspection", являющиеся основными элементами подхода. По крайней мере, нас на курсах PSP/TSP учили именно этому.

G>>Еще пример — решаем, что все прикладные объекты хранят свое состояние в реляционной БД. Со всеми вытекающими, в частности — некая общая подсистема управления этим состоянием.

AL>Боюсь, не всегда получится принять такое решение на уровне стратегии, не вдаваясь в детали и не решив вопросы о том, что такое в данном случае "прикладной объект", что такое "состояние прикладного объекта" и что значит "хранят состояние". Вернее, получиться-то может и получится, но потом может быть мучительно больно из-за последствий такого стратегического решения.

Кто-то говорит, что стратегические решения надо принимать от балды, не вдаваясь в детали и не анализируя их последствия в долгосрочной перспективе?

G>>Архитектура в таком определении слабо зависит от конкретных требований. Она скорее накрывает некий "класс" или "метакласс" возможных требований. Непосредственно сами требования реализуются дизайном (в рамках ограничений, заданных архитектурой).

AL>В таком случае не очень понятно, от чего зависит архитектура и как на уровне стратегии понять, правильная она или нет. Например, решив хранить состояние прикладных объектов в реляционной базе, через год дизайна выясняем, что пользователям системы придется курить по 5 минут после каждого изменения любого совместно изменяемого объекта на любом клиентском рабочем месте.

"Архитектура", понимаемая как комплекс стратегических решений, направленных на долгосрочную перспективу, является зачастую тонким балансом между всеми факторами, и выработка грамотных решений такого уровня — скорее искусство, нежели технология. Слишком много неизвестных и параметров, столько, что приходится полагаться во многом на чутье и интуицию. Ты чего-то другого ожидал, разве твой опыт говорит об обратном?

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

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

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

B>>Определение дизайна я дать не могу. Но я бы предположил, что указанные три термина могли бы обозначать следующее:
B>>Возмем систему, со всеми ее классами и пр. = Детальный дизайн

G>Код, это очевидно, не "детальный дизайн". Код — это код. Ошибка кодирования четко отличается от ошибки детального дизайна. Одно дело ошибиться в алгоритме, или выбрать неподходящую структуру данных, и совсем другое дело — ошибка кодирования. Определение детального дизайна я взял из PSP/TSP, где все эти определения берутся из классификатора ошибок. В UML для описания алгоритмов в принципе подойдет activity диаграмма, однако честнее и правильнее сказать что UML детальный дизайн не покрывает. Детальный дизайн — это уровень "псевдокода".

Все очень просто. Я не встречал упоминания одновременно трех этих терминов. "Дизайн — Детальный дизайн" то бишь "Архитектура — Дизайн" или "Стратегический — тактический дизайн" — это было. А вот "Архитектура — Дизайн — Детальный дизайн" — нет. Поэтому я предположил, что могли бы означать эти три термина вместе.

Но, вернемся к Вашему посту.

Детальный дизайн — алгоритмы и структуры данных.
Дизайн — разбиение функциональности по компонентам, модулям, или классам.
Архитектура — то, что не перечисленное. Комплекс базовых технологий, на которые опирается решение, плюс — идиом или паттернов проектирования, заложенных в "ядро", "фреймворк", или философию построения системы. Если перечисленное вообще есть. Скажем, вы решили, что сериализация объектов у вас будет всегда в XML — это архитектурное решение.

Я не согласен с выделенным. Как минимум, потому что архитектура включает в себя разбиение по компонентам и их взамодействие. Но Вы эти элементы архитектуры исключили.
Поэтому считаю Ваше определение архитектуры, м-м-м... не полным.

G>При проектировании порядок не должен быть фиксированным. Нельзя спроектировать архитектуру без ошибок, не сделав дизайна, а его — в свою очередь — без детального дизайна (по крайней мере некоторых фрагментов). Поэтому, разумные люди не проектирует слои в определенном порядке, будь то сверху вниз или снизу вверх, потому как процесс итеративен по природе. Порядок работ при проектировании разумнее брать по функциям, а не по слоям, начиная рассмотрение с небольшого количества, и постепенно добавляя в рассмотрение все большее их количество. Опять же, если вы хотите нормальный результат получить.

Согласен.

Здравствуйте, Аноним.
А>Так. Штрафной вам. Я специально обратил внимание, что не ГУЯ, а УЯ. А вы опять пишете — ГУЙ! Это уже не взаимное недопонимание, а результат вашего невнимательного прочтения. И теперь мне остается только второй раз написать то же самое.

Читаю я, читаю — а куда деваться? Просто на инглиш всё время переключаться лень, а "уй" склонять — воспитание не позволяет. Ради вашего спокойствия буду использовать "UI". Кстати, 1:1 — я вас выше в троллизме обвинял, теперь вы меня — в нечтении. Квиты?

А>Файлики — это часть дизайна интерфейса, в смысле, как им называться, куда сохраняться и т.д. Возьмем такой продукт как Outlook и его самый знаменитый файл — pst-шник. Это интерфейс, поскольку пользователь взаимодействует с этим файлом. Куча юз-кейсов завязана на его копирование и пр. Дизайн подразумевает, что весь контент хранится в нем, а архитектуре остается только плясать в этих рамках. Архитектор может сделать некую БД, которая бинарно сохраняется в этот файл, как база mySQL представляет собой несколько файликов с невразумительными названиями на диске, а может сделать плоский файл. В первом случае ему придется заводить модуль (dll-ку или exe-шник), который обрабатывает запросы и возвращает датасеты, во-втором — скорее всего, достаточно простого класса-сериализатора массива. Вот это — архитектура поверх UI.

О. Теперь у нас UI — это все _возможные_ варианты использования в том числе и те, что никак не будут отображаться пользователю? В вашем примере с PST нет кстати копирования — это для пользователя оно так выглядит. Две самые важные функции — импорт/экспорт — выполняются как операции с внутренней стуктурой pst. Или для вас это всё равно копирование — потому что "документики летают"?

А>Далее. Работа с сетью — а подразумевается, что продукт работатет с сетью? Как? В спецификации дизайна описано — пользователь нажимает сюда, идет соединение с таким-то сервером по выбранному им протоколу?

А теперь к UI и к "дизайну интерфейса" добавляется "спецификация дизайна". Я не успеваю следить за появлением новых терминов. Или это синонимы? Что ж у вас такое — спецификация дизайна? Для меня казалось что UI и внутренняя логика работы — по дефолту разные вещи. У вас в UI уже вошли внутренние алгоритмы работы. Что ещё туда войдёт?

А>Следующий случай — потоки. По-моему, потоки как ничто другое являются прямым следствием дизайна. Написано: при нажатии "Синхронизировать" пользователю открывается окно (см. схему 137) с прогрессом синхронизации, а он в то же время может продолжать работу в основном окне 1...

Раз мы отображаем окно с надписью "синхронизируемся" — то мы работаем в другом потоке. Вы смешиваете описание UI и реализацию в одном предложении, добавляете низкоуровневой инфы и называете это спецификацией и проектируете на основе её архитектуру?

S>>Непродуктивно. С точки зрения пользователя спеллчекер — это красные полосочки под словами. Опишите мне архитектуру спеллчекера на основе вышеприведённого. Я молчу про подпись документов, поддержку кастомныхх конвертеров/надстроек/макросов, печать и несколько видов отображения документа, которые предоставляют волзможность делать одно и то же различными способами.

А>Понятно. Не "архитектура" у нас разная, как вы предположили, а "дизайн". Если спелчекер — это просто красные полосочки, видимо дизайн для вас — это гламурность цветовой гаммы.

Хорошо. Как спеллчекер выглядит со стороны пользователей? Отображение возможных опечаток + варианты исправления + настройка параметров. Приведите архитектуру спеллчекера, описание основных компонентов — вордбрикера/стеммера/тезауруса/grammar/tokenizer'а и как оно строится на основе взаимодействия с пользователем.

А>Спелчекер — это не просто красные полосочки. Это, во-первых, полосочки зигзагом. ... ПОТОМУ, ЧТО В HTML ТОГДА НЕ БЫЛО ПОДЧЕРКИВАНИЯ ЗИГЗАГОМ! (Не знаю, как сейчас). Вот бы было весело, если бы архитектор действовал в первый черед, началоось бы всем известное: "архитектура не поддерживает, идите в опу".

Гмм... http://lmgtfy.com/?q=html+%D0%BF%D0%BE%D0%B4%D1%87%D1%91%D1%80%D0%BA%D0%B8%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5+%D0%B2%D0%BE%D0%BB%D0%BD%D0%B8%D1%81%D1%82%D0%BE%D0%B9+%D0%BB%D0%B8%D0%BD%D0%B8%D0%B5%D0%B9. Первая ссылка.
-или-
http://www.htmlbook.ru/content/?id=65
-или-
http://www.tigir.com/css.htm.
То, что вы предпочли отказаться от технологии из-за незнания её возможностей ещё не говорит о том что UI должен быть на первом месте. Если бы у вас в команде был архитектор — UI был бы отделён от логики работы и его можно было бы менять как вам понравится.

А>Спелчекер — это не просто красные полосочки. Это, во-первых, полосочки зигзагом...
А>(Правда, закончилось все Скинтиллой, которая тоже не поддерживала такое подчеркивание, но это потому, что процесс обсуждения между группами UI/архитектуры/кода и визионером проекта шел в сто итераций, нашлись и другие требования, и другие дизайнерские приоритеты, и другие архитектурные).
А>Далее, это полосочки, которые появляются не отвлекая пользователя от печатания текста.
А>Наконец, это полосочки, которые появляются под словами, не найденными в словаре.
А>Все вместе это ограничивает архитектуру до известных рамок. Редактор текста должен быть выбран такой, чтобы либо подчеркивания в нем были, либо легко добавлялись. Проверка должна идти в отдельном потоке (как же еще это можно сделать?). Должен быть механизм подключения словаря, а интерфейсы его ориентированы на быстрое нахождение по списку. Видите, как прекрасно описывается архитектура по результатам дизайна?

1) http://lmgtfy.com/?q=scintilla+wave+underline
2) Как у вас от этих перетрясок менялся алгоритм проверки формул — основная часть спеллчекера? Как у вас проектировалась архитектура спеллчекера?

S>>Вы продаёте продукты или вы их пишете?
А>И то, и другое. Видимо поэтому я и вижу процесс полнее.
А... Ну сорри — я всего лишь девелопер. Куда нам до высоких интересов бизнеса...

S>>Кстати, с вашей точки зрения 2003 и 2007-й офисы — совершенно разные продукты. И у MS даже теоретичестки не должнобыло получиться внести кардинальные изменения в гуй не переписав весь офис с нуля.

А>Ну, я ж говорю: дизайн для вас — это гламурные тона. Если не считать цветовой схемы и убранной кастомизации, в MSO 2007 дизайн поменялся не очень много. Это во-первых. А во-вторых, у вас здесь логическая ошибка. Пусть дизайны различаются на все 100%. Придется ли при этом переписывать все с нуля? Ответ: необязательно. Зависит от дизайнов до и после. Может быть, оба разных дизайна вполне могут работать на одной и той же архитектуре.
А>Ключевой момент в том, что ИНОГДА — НЕ МОГУТ. Поэтому и надо давать дизайну более высокий приоритет. Это и вылезает из моей формулы.

Так у вас UI уже не всегда определяет архитектуру? Вы уж определитесь
Да, незнание того, как поменялись внутренности ворда — а там много изменений — не повод упрекать других в "дизайн для вас — это гламурные тона".
Кстати тот же офис безумно страдает от вашего подхода. Как пример "архитектурного" решения: формат файлов офиса изначально был спроектирован так, чтобы использовать memory mapping — файл напрямую отображался в память и ворд работал с отдельными частями без преобразований/загрузки всего файла в память. Это привело к куче граблей с совместимостью форматов (внутренняя логика конвертеров 2000го и 2003-го ворда — тот ещё кошмар). Я молчу о плясках с бубном и с OpenXML.

А>>>Поэтому, это не вершина айсберга. Это, продолжая вашу метафору — полная поверхность айсберга, включая его подводную часть (куда по умолчанию сохранять файлы, можно ли подключаться к серверу, как осуществляется вставка других объектов других софтов — ну, вы поняли).

S>>Ок. У вас требование "я хочу айсберг в форме перевёрнутой пирамиды". Расскажите мне как из этого требования вы узнаете хоть что-то про внутренности аёсберга. Или это проблемы архитекторов?

А>Да, архитектора. Но не "проблемы", а "зона ответственности". Если такая чисто дизайнерская фишка, как перевернутость пирамиды, дорастает до статуса требования, наверное, это важно. Иначе, никто бы не стал такое требование писать. Не должны аналисты приносить такие требования, пока половина юзеров не скажет им — в микрософте айсберги перевернутые, и мы хотим такое же. Так вот, если такое требование попадает дизайнеру, ЧТО он может с ним сделать? Отдать архитектору, а уже тот пусть думает про центр тяжести и прочие дела.

Дарагой вы наш! Сказали бы сразу, что смотрите на продукт с точки зрения дизайнера/продавца — никто вам и слова бы не сказал, время бы сэкономили. Естественно, что свою работу вы ставите как самую приоритетную. Здесь вообще-то тема о влиянии требований на внутренности подукта. Если вы не занимаетесь проектированием архитектуры и не имеете в этой области никакого опыта — какого влазите? тьфу...

Здравствуйте, Beam!

B>Системный аналитик определяет требования к системе. До него может поработать еще бизнес-аналитик, который работает выше — на уровне целей заказчика.
B>Вот их задача выявить требования, в том числе предусмотреть "вероятные требования", т.е. вероятное развитие системы.

Вы распределили ответственность: заказчик выставляет требования, системный аналитик и бизнес-аналитик их анализируют-анализируют и выдают информацию архитектору/проектировщикам — те создают архитектуру/спецификации. Ок. Кто из них должен учитывать "вероятные требования"? Каким образом находятся эти самые "вероятные требования"? Путём индукции — у нас есть текущие требования и мы думаем что заказчик захочет ещё это и это (вопрос провокационный — чтобы поставить точку)?

Про оценку требований пока говорить не будем — в принципе те же методы что и в управлении рисками. Точнее, это оно и есть.

B>Архитектор выдяеляет архитектурно-важные требования и строит архитектуру. Все это есть в RUP например.
На основе чего эти требования выделяются? Исключительно на основе интуиции? Как можно снизить риск некорректной подборки требований или того, что были упущены/не названы важные требования?

B>Архитектор — "технарь", он не должен выдумывать требования.
Бизнес-требования — согласен. Уточнение: архитектура (я всё ещё использую определения Gaperton'a. Как они там доспорят — посмотрим ) накладывает некоторые ограничения и их можно трактовать как дополнительные требования к функционалу. Согласны?

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

А>>Файлики — это часть дизайна интерфейса, в смысле, как им называться, куда сохраняться и т.д. Возьмем такой продукт как Outlook и его самый знаменитый файл — pst-шник. Это интерфейс, поскольку пользователь взаимодействует с этим файлом. Куча юз-кейсов завязана на его копирование и пр. Дизайн подразумевает, что весь контент хранится в нем, а архитектуре остается только плясать в этих рамках. Архитектор может сделать некую БД, которая бинарно сохраняется в этот файл, как база mySQL представляет собой несколько файликов с невразумительными названиями на диске, а может сделать плоский файл. В первом случае ему придется заводить модуль (dll-ку или exe-шник), который обрабатывает запросы и возвращает датасеты, во-втором — скорее всего, достаточно простого класса-сериализатора массива. Вот это — архитектура поверх UI.

S>О. Теперь у нас UI — это все _возможные_ варианты использования в том числе и те, что никак не будут отображаться пользователю?

Из чего вы это вывели?

>В вашем примере с PST нет кстати копирования — это для пользователя оно так выглядит. Две самые важные функции — импорт/экспорт — выполняются как операции с внутренней стуктурой pst. Или для вас это всё равно копирование — потому что "документики летают"?

Копирование — это часть юз-кейса. Юз-кейс такой: выгрузить все в pst-шку, скопировать на флешку, загрузить в Outlook на другой машине. Пользователь это видит — значит, это дизайн. Содержимое этой pst-шки он не видит — там может быть что угодно, это уже архитектура. Аналогично, пользователь не видит всех тех dll-ок, которые готовят pst, и ему наплевать, сколько в программе модулей и каких. Значит, это тоже не дизайн.

А>>Далее. Работа с сетью — а подразумевается, что продукт работатет с сетью? Как? В спецификации дизайна описано — пользователь нажимает сюда, идет соединение с таким-то сервером по выбранному им протоколу?

S>А теперь к UI и к "дизайну интерфейса" добавляется "спецификация дизайна". Я не успеваю следить за появлением новых терминов. Или это синонимы? Что ж у вас такое — спецификация дизайна? Для меня казалось что UI и внутренняя логика работы — по дефолту разные вещи. У вас в UI уже вошли внутренние алгоритмы работы. Что ещё туда войдёт?

Спецификация — это полное описание. Или устное, или в виде документа. Может, еще гвоздем нацарапано на мониторе. Поэтому, спецификация к дизайну интерфейса не добавляется. Когда дизайнер долго думал над дизайном, проработал его до мелочей, на свет появляется документ, содержащий эту самую спецификацию.

Можете, если вас напрягают термины, заменить "спецификацию" на "документ, подробно описывающий UI". Внутренняя логика работы и UI — это не одно и то же. Но описание "и когда пользователь нажал сюда, появляется диалог, предлагающий сохранить pst" — это описание UI, а не "внутренней логики".

А>>Следующий случай — потоки. По-моему, потоки как ничто другое являются прямым следствием дизайна. Написано: при нажатии "Синхронизировать" пользователю открывается окно (см. схему 137) с прогрессом синхронизации, а он в то же время может продолжать работу в основном окне 1...

S>Раз мы отображаем окно с надписью "синхронизируемся" — то мы работаем в другом потоке. Вы смешиваете описание UI и реализацию в одном предложении, добавляете низкоуровневой инфы и называете это спецификацией и проектируете на основе её архитектуру?

Вообще-то, ничего я не смешиваю. Можете сделать цикл, который будет выполнять один шаг синхронизации, затем — обрабатывать оконные сообщения в окне 1 и в окне 137. И без потоков. Тем самым, потоки НЕ закладываются дизайнером. Дизайнером закладывается параллельность дизайна, а как это будет выполнено — ему пофиг. Хоть святым духом.

Когда я написал, что посмотрю, как вы это будете проектировать без потоков, я, собственно, циклы в виду и имел. Поток — это единственное разумное проектировочное решение на такой дизайн. Единственное разумное, а не единственное ВООБЩЕ. Поэтому, ничего я не смешиваю. И покажите хоть грамм "низкоуровневой инфы" в моем примере. Я даже не знаю, что и подумать. "Синхронизировать" — это надпись на кнопке, то есть дизайн. Схема 137 — это схема №137 из документа, описывающего дизайн. Прогресс — это название элемента управления из ОС Windows (progress control). А то, что пользователь может — так это уже по определению дизайн. Как этого добьются архитекторы с программистами, никого не колышет. Короче, что за "низкоуровневая инфа" такая?

S>Гмм... http://lmgtfy.com/?q=html+%D0%BF%D0%BE%D0%B4%D1%87%D1%91%D1%80%D0%BA%D0%B8%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5+%D0%B2%D0%BE%D0%BB%D0%BD%D0%B8%D1%81%D1%82%D0%BE%D0%B9+%D0%BB%D0%B8%D0%BD%D0%B8%D0%B5%D0%B9. Первая ссылка.
S>-или-
S>http://www.htmlbook.ru/content/?id=65
S>-или-
S>http://www.tigir.com/css.htm.
S>То, что вы предпочли отказаться от технологии из-за незнания её возможностей ещё не говорит о том что UI должен быть на первом месте. Если бы у вас в команде был архитектор — UI был бы отделён от логики работы и его можно было бы менять как вам понравится.

Все эти дешевые трюки с картинками не стоят, извините, ничего даже в режиме отображения. Откройте ваш тигир и выделите параграф со словом "ошимбок" целиком. А теперь откройте Ворд, и выделите параграф с таким словом в нем. Разницу видите? Так это еще режим ОТОБРАЖЕНИЯ html. А я писал про режим РЕДАКТИРОВАНИЯ, в котором есть свои заморочки. Я вот только не помню, были ли еще и заморочки с версией IE, вообще-то много лет уже прошло. Попробуйте поверить, что кругом вас тоже не одни дураки. Особенно, когда им нужно было решать свою проблему.

Я еще раз говорю, когда все эти дизайнерские тонкости заранее не продуманы, а решение "давайте использовать IE" или там "давайте использовать скинтиллу" принимаются с кондачка, получается потом продукт из серии "не пришей #$%де рукав".

А>>Спелчекер — это не просто красные полосочки. Это, во-первых, полосочки зигзагом...
А>>(Правда, закончилось все Скинтиллой, которая тоже не поддерживала такое подчеркивание, но это потому, что процесс обсуждения между группами UI/архитектуры/кода и визионером проекта шел в сто итераций, нашлись и другие требования, и другие дизайнерские приоритеты, и другие архитектурные).
А>>Далее, это полосочки, которые появляются не отвлекая пользователя от печатания текста.
А>>Наконец, это полосочки, которые появляются под словами, не найденными в словаре.
А>>Все вместе это ограничивает архитектуру до известных рамок. Редактор текста должен быть выбран такой, чтобы либо подчеркивания в нем были, либо легко добавлялись. Проверка должна идти в отдельном потоке (как же еще это можно сделать?). Должен быть механизм подключения словаря, а интерфейсы его ориентированы на быстрое нахождение по списку. Видите, как прекрасно описывается архитектура по результатам дизайна?

S>1) http://lmgtfy.com/?q=scintilla+wave+underline

Да, тут меня память подвела. Как раз в скинтилле-то это и решалось.

S>2) Как у вас от этих перетрясок менялся алгоритм проверки формул — основная часть спеллчекера? Как у вас проектировалась архитектура спеллчекера?

Вопрос не релевантен. Алгоритм проверки формул не имеет отношения ни к дизайну, ни к архитектуре. Алгоритм — это код, часть реализации. Самый нижний слой.

S>>>Вы продаёте продукты или вы их пишете?
А>>И то, и другое. Видимо поэтому я и вижу процесс полнее.
S>А... Ну сорри — я всего лишь девелопер. Куда нам до высоких интересов бизнеса...

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

S>>>Кстати, с вашей точки зрения 2003 и 2007-й офисы — совершенно разные продукты. И у MS даже теоретичестки не должнобыло получиться внести кардинальные изменения в гуй не переписав весь офис с нуля.

А>>Ну, я ж говорю: дизайн для вас — это гламурные тона. Если не считать цветовой схемы и убранной кастомизации, в MSO 2007 дизайн поменялся не очень много. Это во-первых. А во-вторых, у вас здесь логическая ошибка. Пусть дизайны различаются на все 100%. Придется ли при этом переписывать все с нуля? Ответ: необязательно. Зависит от дизайнов до и после. Может быть, оба разных дизайна вполне могут работать на одной и той же архитектуре.
А>>Ключевой момент в том, что ИНОГДА — НЕ МОГУТ. Поэтому и надо давать дизайну более высокий приоритет. Это и вылезает из моей формулы.

S>Так у вас UI уже не всегда определяет архитектуру? Вы уж определитесь

Всегда, но два совершенно разных UI теоретически можно реализовать на базе одной и той же архитектуры. Поэтому, тезис "И у MS даже теоретичестки не должнобыло получиться внести кардинальные изменения в гуй не переписав весь офис с нуля" несправедлив. Голая логика, больше ничего. Теоретически это, как раз, очень даже может быть. Я говорю, на практике чаще всего бывает так, что даже небольшое (не радикальное) изменение интерфейса приводит к радикальному изменению архитектуры.

S>Да, незнание того, как поменялись внутренности ворда — а там много изменений — не повод упрекать других в "дизайн для вас — это гламурные тона".

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

А вот что я утверждаю, так это то, что интерфейс поменялся не настолько сильно, чтобы говорить, что это "совершенно разные продукты". Серьезное изменение дизайна там ровно одно, остальное — или новый функционал, или жонглирование иконками.

S>Кстати тот же офис безумно страдает от вашего подхода. Как пример "архитектурного" решения: формат файлов офиса изначально был спроектирован так, чтобы использовать memory mapping — файл напрямую отображался в память и ворд работал с отдельными частями без преобразований/загрузки всего файла в память. Это привело к куче граблей с совместимостью форматов (внутренняя логика конвертеров 2000го и 2003-го ворда — тот ещё кошмар). Я молчу о плясках с бубном и с OpenXML.

Пользователь в гробу видал ваш memory mapping. Никакого отношения к дизайну он не имеет.

А>>>>Поэтому, это не вершина айсберга. Это, продолжая вашу метафору — полная поверхность айсберга, включая его подводную часть (куда по умолчанию сохранять файлы, можно ли подключаться к серверу, как осуществляется вставка других объектов других софтов — ну, вы поняли).

S>>>Ок. У вас требование "я хочу айсберг в форме перевёрнутой пирамиды". Расскажите мне как из этого требования вы узнаете хоть что-то про внутренности аёсберга. Или это проблемы архитекторов?

А>>Да, архитектора. Но не "проблемы", а "зона ответственности". Если такая чисто дизайнерская фишка, как перевернутость пирамиды, дорастает до статуса требования, наверное, это важно. Иначе, никто бы не стал такое требование писать. Не должны аналисты приносить такие требования, пока половина юзеров не скажет им — в микрософте айсберги перевернутые, и мы хотим такое же. Так вот, если такое требование попадает дизайнеру, ЧТО он может с ним сделать? Отдать архитектору, а уже тот пусть думает про центр тяжести и прочие дела.

S>Дарагой вы наш! Сказали бы сразу, что смотрите на продукт с точки зрения дизайнера/продавца — никто вам и слова бы не сказал, время бы сэкономили. Естественно, что свою работу вы ставите как самую приоритетную. Здесь вообще-то тема о влиянии требований на внутренности подукта. Если вы не занимаетесь проектированием архитектуры и не имеете в этой области никакого опыта — какого влазите? тьфу...

Я могу еще раз повторить то, что имеет отношение к теме: для весьма немаленького класса ПО между требованиями и "внутренностями" стоят "внешности", то есть интерфейс со своим дизайном. Извините, что разжевывал эту простую мысль так долго. Больше не буду. Понимающему open-minded человеку разжевывать не нужно, а остальным объясняй, не объясняй, чистый time waste.

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

G>Кто-то говорит, что стратегические решения надо принимать от балды, не вдаваясь в детали и не анализируя их последствия в долгосрочной перспективе?

Когда мне говорят:

Детальный дизайн — алгоритмы и структуры данных. Дизайн — разбиение функциональности по компонентам, модулям, или классам. Архитектура — то, что не перечисленное.

я теряюсь, потому как до сих пор считал структурное и поведеческое представления одними из составных частей архитектурного описания системы. Взять хотя бы микроархитектуру процессора какого-нибудь или архитектуру команд ... впрочем, пустое это всё , ибо как говорит один мой молодой коллега: "ничего нет! вообще ничего!"

G>"Архитектура", понимаемая как комплекс стратегических решений, направленных на долгосрочную перспективу, является зачастую тонким балансом между всеми факторами, и выработка грамотных решений такого уровня — скорее искусство, нежели технология. Слишком много неизвестных и параметров, столько, что приходится полагаться во многом на чутье и интуицию. Ты чего-то другого ожидал, разве твой опыт говорит об обратном?

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

Поэтому в повседневном труде мы считаем архитектуру сочетанием структуры системы и множества отношений между элементами структуры, в котором реализуются не внешние требования к системе, а функции, позволяющие удовлетворить некие требования. При этом архитектура является неотъемлемой частью системы и создается, развивается и эволюционирует вместе с системой. Получив или выявив требования, мы формируем перечень функций и ограничений, после чего функции группируются в подсистемы по сходности достигаемых целей и режутся снизу вверх на слои для минимизации зависимости друг от друга и от окружения. Магия в том, как правильно сгруппировать и порезать, не поддавшись дьявольскому соблазну начать проектирование "в лоб". Есть ли польза от такой трактовки? Ну, иначе я даже не представляю, как хотя бы сформировать перечень целей и задач, которые должны быть достигнуты и выполнены в процессе проектирования при детальном планировании работ и последующем контроле. Это во-первых. Во-вторых, таким образом на базе одного фреймворка и кодовой базы удается реализовывать разные проекты для разных платформ в довольно короткие сроки при крайней ограниченности в ресурсах. Хотя, как недавно заметил thesz, наши проекты -- это по-любому полгода максимум, так что риск провала стоит копейки

Забыл сказать, что одним из авторов IEEE 1471-2000 является небезызвестный Philippe Kruchten. Вероятно, поэтому среди правильных дядек сей труд не фаворе

Здравствуйте, Аноним...

S>>О. Теперь у нас UI — это все _возможные_ варианты использования в том числе и те, что никак не будут отображаться пользователю?

А>Из чего вы это вывели?
Ваше?

Это интерфейс, поскольку пользователь взаимодействует с этим файлом.Куча юз-кейсов завязана на его копирование и пр.
...
Архитектор может сделать некую БД, которая бинарно сохраняется в этот файл, как база mySQL представляет собой несколько файликов с невразумительными названиями на диске, а может сделать плоский файл.
...
Вот это — архитектура поверх UI.

Юз-кейзы у вас определяют способ хранения внутренних данных исходя из того, что эти данные надо будет копировать. Gaperton назвал это архитектурой — т.к. такое решение ограничивает возможности реализации. В частности возможность _копирования_ файла в любой момент слегка конфликтует с традиционным write-ahead подходом в транзакционных СУБД.

Самое смешное, что несмотря на то, что ваше требование _уже_ наложило ограничения, никакого копирования на самом деле не будет — будет экспорт (очистка системных метаданных, преобразование к совместимому формату, возможно шифрование и выгрузка). Но никак не копирование посредством вызовов системного api.

А>Копирование — это часть юз-кейса. Юз-кейс такой: выгрузить все в pst-шку, скопировать на флешку, загрузить в Outlook на другой машине. Пользователь это видит — значит, это дизайн. Содержимое этой pst-шки он не видит — там может быть что угодно, это уже архитектура.

Понимаете, то что видит пользователь не обязательно совпадает с действительностью. Более того, одна и та же информация может быть представлена по-разному. Если у вас есть частичные представлениях — получить исходные данные можно только индукцией. Что там в матлогике говорится о неполной индукции?

Продолжаем разбираться с вашим примером. Проблемы аутлука заканчиваются на "выгрузить все в pst-шку по указанному пути". Выше вы заявляли:

Возьмем такой продукт как Outlook и его самый знаменитый файл — pst-шник. Это интерфейс, поскольку пользователь взаимодействует с этим файлом. Куча юз-кейсов завязана на его копирование и пр. Дизайн подразумевает, что весь контент хранится в нем

Теперь выясняется что pst нужен только для экспорта/импорта между оутглюками на разных компах. Но вы заявили возможность только копирования файла и используете один и тот же формат для экспорта и для хранения внутренних данных. Это накладывает нехилые ограничения на будущее продукта. Начиная от совместимости версий и заканчивая проблемами с другими методами синхронизации. Для них придётся использовать свой механизм. Аутлук, к слову, использует общий механизм для импорта/экспорта и синхронизацией с почтовыми серверами и (в последней версии) с rss. Между прочим это явно противоречит тому что видит пользователь — почту он получает по сети, а импортированные письма — из файла.

---

А>Спецификация — это полное описание. ... Когда дизайнер долго думал над дизайном, проработал его до мелочей, на свет появляется документ, содержащий эту самую спецификацию.

А>Можете, если вас напрягают термины, заменить "спецификацию" на "документ, подробно описывающий UI". Внутренняя логика работы и UI — это не одно и то же. Но описание "и когда пользователь нажал сюда, появляется диалог, предлагающий сохранить pst" — это описание UI, а не "внутренней логики".

Всё чудесатей и чудесатей(с). У вас полное описание системы создаётся дизайнером UI (я вас правильно понимаю?)? Реализоваться система тоже на основе этого описания будет? Зачем вам тогда архитектор и архитектура?

Кстати, запомните ваш пример с диалоговым окошком. Сейчас это у вас UI. Ниже — это уже "незначительные изменения и жонглирование иконками".

S>>Раз мы отображаем окно с надписью "синхронизируемся" — то мы работаем в другом потоке. Вы смешиваете описание UI и реализацию в одном предложении, добавляете низкоуровневой инфы и называете это спецификацией и проектируете на основе её архитектуру?

А>Вообще-то, ничего я не смешиваю. ... Тем самым, потоки НЕ закладываются дизайнером. Дизайнером закладывается параллельность дизайна, а как это будет выполнено — ему пофиг. Хоть святым духом.
A> ... А то, что пользователь может — так это уже по определению дизайн. Как этого добьются архитекторы с программистами, никого не колышет. Короче, что за "низкоуровневая инфа" такая?

Понимаете, вы хардкодите логику работы системы в UI. Т.е. проектируя систему вы закладываетесь на то что это самое окошко и эта самая кнопка будет у вас отныне и во веки веков — вон, в схеме 137 написано. Вы не учитываете, что одна и та же операция может быть несколькими способами, в том числе и в цепочки последовательностей. Если у вас синхронизация всегда происходит асинхронно (ибо так сказано в схеме 137) — будут грабли при синхронизации с несколькими источниками или при изменении UI.

---

А>Все эти дешевые трюки с картинками не стоят, извините, ничего даже в режиме отображения. ...

Угу. Принято. Тем не менее есть хотя бы намёк на возможность решения. Раздражает когда говарят нечто в духе "ie в принципе не способен".

А>Я еще раз говорю, когда все эти дизайнерские тонкости заранее не продуманы, а решение "давайте использовать IE" или там "давайте использовать скинтиллу" принимаются с кондачка, получается потом продукт из серии "не пришей #$%де рукав".

Это тривиальные риски выбора технологии реализации — что вы с ними носитесь как будто это нечто уникальное? Те же самые проблемы с подбором инструментария, команды, методологии и т.п. Почему всё это дело у вас определяет архитектуру —

---

S>>2) Как у вас от этих перетрясок менялся алгоритм проверки формул — основная часть спеллчекера? Как у вас проектировалась архитектура спеллчекера?
А>Вопрос не релевантен. Алгоритм проверки формул не имеет отношения ни к дизайну, ни к архитектуре. Алгоритм — это код, часть реализации. Самый нижний слой.

Чуть выше вы писали

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

"Должен быть механизм подключения словаря, а интерфейсы его ориентированы на быстрое нахождение по списку" —
это у вас архитектура, а разбиение спеллчекера на компоненты и алгоритм проверки — это не архитектура. Или это всё дело архитекторов и программистов? Если да — то вы просто предъявляете определённые требования к архитектуре. Как их сформировать — "надо чтобы логика умела работать с любым представлением" или "надо чтобы логика работала с scintilla" — это ваши проблемы. То что вы поставили узкую задачу перед ребятами не оправдывает ни их, ни вас.

---

А>Будучи всего лишь девелопером, можно вполне представлять, что если продукт и пишется для чьего-то удовлетворения, то скорее юзера, чем архитектора.

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

---

S>>>>Кстати, с вашей точки зрения 2003 и 2007-й офисы — совершенно разные продукты. И у MS даже теоретичестки не должнобыло получиться внести кардинальные изменения в гуй не переписав весь офис с нуля.

S>>Так у вас UI уже не всегда определяет архитектуру? Вы уж определитесь

А>Всегда, но два совершенно разных UI теоретически можно реализовать на базе одной и той же архитектуры. ... Я говорю, на практике чаще всего бывает так, что даже небольшое (не радикальное) изменение интерфейса приводит к радикальному изменению архитектуры.

S>>Да, незнание того, как поменялись внутренности ворда — а там много изменений — не повод упрекать других в "дизайн для вас — это гламурные тона".

А>А вот что я утверждаю, так это то, что интерфейс поменялся не настолько сильно, чтобы говорить, что это "совершенно разные продукты". Серьезное изменение дизайна там ровно одно, остальное — или новый функционал, или жонглирование иконками.

В новом офисе очень много чего поменялось. Даже 95/97-й внутри имели куда меньше новых фич.

Забавно. В ваших примерах вы расписываете UI вплоть до самых детальных нюансов — диалоги сохранения, формат хранения данных и т.п. И всё это определяется желаниями пользователей и на этой же основе проектируется архитекутра и т.п.

Как только я применил вашу же логику к продукту в целом — уже нет никаких кардинальных изменений и все те нюансы, что в примерах с pst определяли архитектуру теперь не имеют значения. Самое смешное, что с точки зрения пользователей там есть серьёзные изменения в дизайне — вплоть до отказа пользователя работать с модным UI. Вы выше долго писали, что UI первично, что архитектура определяется UI, что продукт зависит в первую очередь от UI и спецификации, которую создаёт дизайнер, а всякие мелкие технические проблемы — это дело архитекторов и программистов. Так?

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

S>>Кстати тот же офис безумно страдает от вашего подхода.

А>Пользователь в гробу видал ваш memory mapping. Никакого отношения к дизайну он не имеет.

Таак. Т.е в случае оутлука логика работы с файлом — это UI, а в случае с вордом — это не UI. Выстройте наконец стройную концепцию и приходите — с субъективными ощущениями спорить неудобно

---

А>Я могу еще раз повторить то, что имеет отношение к теме: для весьма немаленького класса ПО между требованиями и "внутренностями" стоят "внешности", то есть интерфейс со своим дизайном. Извините, что разжевывал эту простую мысль так долго. Больше не буду. Понимающему open-minded человеку разжевывать не нужно, а остальным объясняй, не объясняй, чистый time waste.

Гы... теперь знаю современный синоним для анацефалов — open-minded. Однако как политкорректно
//сорри, не удержался

Вначале вы утверждали, что

S>>Так у вас UI уже не всегда определяет архитектуру? Вы уж определитесь
А>Всегда ...

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

Что вы будете утверждать завтра?)

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

S>>>О. Теперь у нас UI — это все _возможные_ варианты использования в том числе и те, что никак не будут отображаться пользователю?
А>>Из чего вы это вывели?

S>Ваше?
S>

S>Это интерфейс, поскольку пользователь взаимодействует с этим файлом.Куча юз-кейсов завязана на его копирование и пр.
S>...
S>Архитектор может сделать некую БД, которая бинарно сохраняется в этот файл, как база mySQL представляет собой несколько файликов с невразумительными названиями на диске, а может сделать плоский файл.
S>...
S>Вот это — архитектура поверх UI.

Мое. Но как отсюда выводится, что "UI — это все _возможные_ варианты использования в том числе и те, что никак не будут отображаться пользователю"?

S>Юз-кейзы у вас определяют способ хранения внутренних данных исходя из того, что эти данные надо будет копировать. Gaperton назвал это архитектурой — т.к. такое решение ограничивает возможности реализации. В частности возможность _копирования_ файла в любой момент слегка конфликтует с традиционным write-ahead подходом в транзакционных СУБД.
S>Самое смешное, что несмотря на то, что ваше требование _уже_ наложило ограничения, никакого копирования на самом деле не будет — будет экспорт (очистка системных метаданных, преобразование к совместимому формату, возможно шифрование и выгрузка). Но никак не копирование посредством вызовов системного api.

А кто вам сказал "в любой момент"? Разумеется, надо делать экспорт и импорт. Но экспорт и импорт обусловлены чем? Копированием. В справке написано: экспортируйте, скопируйте, импортируйте. Ключевой момент — скопируйте. Ради этого юзеру и показывается файл. А все, что показывается юзеру — юзерский интерфейс.

А>>Копирование — это часть юз-кейса. Юз-кейс такой: выгрузить все в pst-шку, скопировать на флешку, загрузить в Outlook на другой машине. Пользователь это видит — значит, это дизайн. Содержимое этой pst-шки он не видит — там может быть что угодно, это уже архитектура.
S>Понимаете, то что видит пользователь не обязательно совпадает с действительностью. Более того, одна и та же информация может быть представлена по-разному. Если у вас есть частичные представлениях — получить исходные данные можно только индукцией. Что там в матлогике говорится о неполной индукции?

Не понимаю. Глюки у него, что ли? Я бы понял, если бы вы сказали, что дизайн оперирует метафорами. Например, утверждается, что файл хранится в папке и выбрасывается в корзину. Но на самом деле есть таблица FAT и маркер удаленности. Вот это я бы понял. Ну и?

S>Продолжаем разбираться с вашим примером. Проблемы аутлука заканчиваются на "выгрузить все в pst-шку по указанному пути". Выше вы заявляли:

S>

S>Возьмем такой продукт как Outlook и его самый знаменитый файл — pst-шник. Это интерфейс, поскольку пользователь взаимодействует с этим файлом. Куча юз-кейсов завязана на его копирование и пр. Дизайн подразумевает, что весь контент хранится в нем

S>Теперь выясняется что pst нужен только для экспорта/импорта между оутглюками на разных компах. Но вы заявили возможность только копирования файла и используете один и тот же формат для экспорта и для хранения внутренних данных. Это накладывает нехилые ограничения на будущее продукта. Начиная от совместимости версий и заканчивая проблемами с другими методами синхронизации. Для них придётся использовать свой механизм. Аутлук, к слову, использует общий механизм для импорта/экспорта и синхронизацией с почтовыми серверами и (в последней версии) с rss. Между прочим это явно противоречит тому что видит пользователь — почту он получает по сети, а импортированные письма — из файла.

Я? Один и то же формат? Шутите вы что ли! Я даже не в курсе, тот pst, что экспортится-импортится, и тот, в котором аутглюк ведет свою работу — это один и тот же формат или нет. Юзеру не предлагается подменять pst-хи из-под рабочего аутглюка, в справке про это ничего нет, я не удивлюсь, узнав что это реально разные форматы. И будь я дизайнером аутглюка, мне бы было все равно, используют ли архитекторы один и тот же формат или разные. Юзер этим просто не интересуется.

S>

---

А>>Спецификация — это полное описание. ... Когда дизайнер долго думал над дизайном, проработал его до мелочей, на свет появляется документ, содержащий эту самую спецификацию.

А>>Можете, если вас напрягают термины, заменить "спецификацию" на "документ, подробно описывающий UI". Внутренняя логика работы и UI — это не одно и то же. Но описание "и когда пользователь нажал сюда, появляется диалог, предлагающий сохранить pst" — это описание UI, а не "внутренней логики".

S>Всё чудесатей и чудесатей(с). У вас полное описание системы создаётся дизайнером UI (я вас правильно понимаю?)? Реализоваться система тоже на основе этого описания будет? Зачем вам тогда архитектор и архитектура?

Полное описание системы — это ее код. Он описывает систему на машинопонятном языке и так, что полнее не бывает. А спецификация дизайна — заведомо НЕПОЛНОЕ описание. Это описание одного-единственного аспекта — юзерского. Другое неполное описание системы — архитектурная спецификация.

Зачем архитектор — а кто будет думать, на каком языке надо писать, Пушкин? Что выбрать — C++, C#, Java? КОМ или дотНет? Файловый ввод-вывод или SQL-движок? Компонент А или Б? А сервер — внутрипроцессный или локальный? Надо ли использовать MVC?

S>Кстати, запомните ваш пример с диалоговым окошком. Сейчас это у вас UI. Ниже — это уже "незначительные изменения и жонглирование иконками".

Вы как-то интересно сравниваете. Диалоговое окошко — это дизайнерская статика. Обычное дизайнерское решение. Переход от команд на кастомизируемых тулбарах и меню к командам на некастомизируемых лентах — это дизайнерская динамика (изменение дизайна). И "ниже" одно в другое не переходит.

Диалог — это UI, и ныне, и присно, и во веки веков, а не "сейчас". Где я написал, что ниже он — "незначительные изменения и жонглирование иконками"? Диалог не может быть изменением. Сущность у него такая: объектная, а не процессная.

S>>>Раз мы отображаем окно с надписью "синхронизируемся" — то мы работаем в другом потоке. Вы смешиваете описание UI и реализацию в одном предложении, добавляете низкоуровневой инфы и называете это спецификацией и проектируете на основе её архитектуру?

А>>Вообще-то, ничего я не смешиваю. ... Тем самым, потоки НЕ закладываются дизайнером. Дизайнером закладывается параллельность дизайна, а как это будет выполнено — ему пофиг. Хоть святым духом.
A>> ... А то, что пользователь может — так это уже по определению дизайн. Как этого добьются архитекторы с программистами, никого не колышет. Короче, что за "низкоуровневая инфа" такая?

S>Понимаете, вы хардкодите логику работы системы в UI. Т.е. проектируя систему вы закладываетесь на то что это самое окошко и эта самая кнопка будет у вас отныне и во веки веков — вон, в схеме 137 написано. Вы не учитываете, что одна и та же операция может быть несколькими способами, в том числе и в цепочки последовательностей. Если у вас синхронизация всегда происходит асинхронно (ибо так сказано в схеме 137) — будут грабли при синхронизации с несколькими источниками или при изменении UI.

Хардкодится не просто какая-то там абстрактная логика работы, а логика работы юзера с программой. Это нормальный этап планирования — продумывать все до мелочей. А какова альтернатива? Проектируем, а там пусть получится интерфейс, какой получится?

И, извините, но что-то уж больно вы перевираете мои слова. "Вы не учитываете, что одна и та же операция может быть несколькими способами" — я как раз учитываю. Если операция может быть выполнена несколькими способами, я обязательно отражу это в дизайнерской документации.

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

Что такое "синхронизация происходит асинхронно" я вообще не понял. В схеме 137 ничего не написано. Схема — это схема, внешний вид окна. Откройте Визио, там есть такой тип схем — XP UI. Поймете, о какой схеме я говорил. Написано — в спецификации, и пример того, что там пишут я привел:

при нажатии "Синхронизировать" пользователю открывается окно (см. схему 137) с прогрессом синхронизации, а он в то же время может продолжать работу в основном окне 1

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

S>

---

А>>Все эти дешевые трюки с картинками не стоят, извините, ничего даже в режиме отображения. ...

S>Угу. Принято. Тем не менее есть хотя бы намёк на возможность решения. Раздражает когда говарят нечто в духе "ie в принципе не способен".

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

А>>Я еще раз говорю, когда все эти дизайнерские тонкости заранее не продуманы, а решение "давайте использовать IE" или там "давайте использовать скинтиллу" принимаются с кондачка, получается потом продукт из серии "не пришей #$%де рукав".

S>Это тривиальные риски выбора технологии реализации — что вы с ними носитесь как будто это нечто уникальное? Те же самые проблемы с подбором инструментария, команды, методологии и т.п. Почему всё это дело у вас определяет архитектуру —

Нет, это не риски. Когда вы выбираете инструментарий (допустим, библиотеку), вы не знаете, работает она глючно или безглючно. Это риск. Когда вы нанимаете программиста, вы не знаете, принесет он вам доход или загонит в убытки (насколько его сил хватит). Это риск. Когда вы проектируете систему, имея полную дизайнерскую спецификацию на руках, вы в безрисковом порядке, со стопроцентной гарантией, получаете архитектуру, которая соответствует финальному варианту этой самой дизайнерской спецификации. Понятно? А вот если решения о скинтилле/ИЕ принимаются исходя из общих соображений, типа, в принципе и с молитовкой все возможно, вот тогда и начинаются риски. Которых могло не быть. И прямая обязанность ПМа сделать так, чтоб их не было.

S>

---

S>>>2) Как у вас от этих перетрясок менялся алгоритм проверки формул — основная часть спеллчекера? Как у вас проектировалась архитектура спеллчекера?
А>>Вопрос не релевантен. Алгоритм проверки формул не имеет отношения ни к дизайну, ни к архитектуре. Алгоритм — это код, часть реализации. Самый нижний слой.

S>Чуть выше вы писали
S>

S>Все вместе это ограничивает архитектуру до известных рамок. Редактор текста должен быть выбран такой, чтобы либо подчеркивания в нем были, либо легко добавлялись. Проверка должна идти в отдельном потоке (как же еще это можно сделать?). Должен быть механизм подключения словаря, а интерфейсы его ориентированы на быстрое нахождение по списку. Видите, как прекрасно описывается архитектура по результатам дизайна?

Не надо мне напоминать, что я писал, а? Я не страдаю амнезией. Вы прямо покажите, как из моих слов вытекает то-то и то-то.

Я настаиваю: вопрос "Как у вас от этих перетрясок менялся алгоритм проверки формул" нерелевантен, поскольку алгоритм не имеет отношения ни к архитектуре, ни к дизайну. А вот то, что я написал "чуть выше" — это имеет отношение и к дизайну, и к архитектуре.

S>"Должен быть механизм подключения словаря, а интерфейсы его ориентированы на быстрое нахождение по списку" —
S>это у вас архитектура, а разбиение спеллчекера на компоненты и алгоритм проверки — это не архитектура. Или это всё дело архитекторов и программистов? Если да — то вы просто предъявляете определённые требования к архитектуре. Как их сформировать — "надо чтобы логика умела работать с любым представлением" или "надо чтобы логика работала с scintilla" — это ваши проблемы. То что вы поставили узкую задачу перед ребятами не оправдывает ни их, ни вас.

Разбиение спелчекера на компоненты и алгоритм проверки не надо валить в одну кучу. Если действительно есть спелчекерские компоненты, связанные через интерфейсы или что-то типа — это архитектура. А алгоритм проверки, он алгоритм и есть. Вот и все, что я могу сказать. Дадут вам ТЗ — имплементировать ISpellCheck { Load(BSTR); SAFEARRAY GetErrorWordIndices(); } — и интересовать ваша реализация будет только других кодеров, которым ваш код править после вашего увольнения, тестеров, которым важно, чтоб ошибок не было, и профилировщика с секундомером. Но не дизайнера и не архитектора. А вот вы будете заинтересованы в таком дизайне и архитектуре, чтоб их было реально и просто выполнять.

S>>>Кстати тот же офис безумно страдает от вашего подхода.
А>>Пользователь в гробу видал ваш memory mapping. Никакого отношения к дизайну он не имеет.
S>Таак. Т.е в случае оутлука логика работы с файлом — это UI, а в случае с вордом — это не UI. Выстройте наконец стройную концепцию и приходите — с субъективными ощущениями спорить неудобно

В случае аутлука имеет место непонимание вами меня. Логика работы с файлом сводится к тому, что в него надо-таки сбросить данные перед тем, как копировать при помощи флешки на другой комп. Все. Как оно там мапится — это в обоих случаях не дизайн.

S>

---

А>>Я могу еще раз повторить то, что имеет отношение к теме: для весьма немаленького класса ПО между требованиями и "внутренностями" стоят "внешности", то есть интерфейс со своим дизайном. Извините, что разжевывал эту простую мысль так долго. Больше не буду. Понимающему open-minded человеку разжевывать не нужно, а остальным объясняй, не объясняй, чистый time waste.

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

Э-э... Что-то я припух уже. Требования — это требования. UI — это UI. Архитектура — это архитектура. Во имя человеколюбия, я вам отправлю образцы того, и другого, и третьего, если вы оставите здесь адрес электропочты. Иначе можно до того года переписываться.

S>Что вы будете утверждать завтра?)

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

G>>Кто-то говорит, что стратегические решения надо принимать от балды, не вдаваясь в детали и не анализируя их последствия в долгосрочной перспективе?

AL>Когда мне говорят:

AL>

AL>Детальный дизайн — алгоритмы и структуры данных. Дизайн — разбиение функциональности по компонентам, модулям, или классам. Архитектура — то, что не перечисленное.

AL>я теряюсь, потому как до сих пор считал структурное и поведеческое представления одними из составных частей архитектурного описания системы. Взять хотя бы микроархитектуру процессора какого-нибудь или архитектуру команд ... впрочем, пустое это всё , ибо как говорит один мой молодой коллега: "ничего нет! вообще ничего!"

Стоп. Стоп. Архитектура уровня системы команд (Instructions Set Architecture) — это как раз хороший пример "стратегического решения", архитектуры в чистом виде, не имеющей отношения ни к дизайну, ни к алгоритмам со структурами данных. Одна и та же ISA может быть реализована совершенно по разному. SPARCv9 ISA можно реализовать c пятиступенчатым конвейром, можно с семи, или с девяти. Можно построить на ее основе суперскалярный проц. А можно — мультитредный, как Ниагара, не имеющий по внутренностям ничего общего с суперскалярным.

Детальным дизайном в случае микропроцессора являются внутренние алгоритмы работы блоков. Скажем, описание алгоритма работы шедулера инструкций, выполняющих выборку независимых по регистрам инструкций в окне просмотра. Или логическая структура и алгоритмы кэша L1. Эти описания алгоритмов настолько далеко от реализации в Verilog, что является именно дизайном.

Архитектурой в случае проца (помимо системы команд, которая ближе к требованиям) является сам подход к выполнению инстукций — суперскаляр, мультитредность, или что еще, и возможно, структура на крупном уровне — здесь грань между дизайном и архитектурой тонка, и поэтому в данном определении это "дизайн". "Дизайн", как промежуточный пункт данного определения, как раз создан для тех вещей, когда хрен разберешь, "дизайн" это или "архитектура".

G>>"Архитектура", понимаемая как комплекс стратегических решений, направленных на долгосрочную перспективу, является зачастую тонким балансом между всеми факторами, и выработка грамотных решений такого уровня — скорее искусство, нежели технология. Слишком много неизвестных и параметров, столько, что приходится полагаться во многом на чутье и интуицию. Ты чего-то другого ожидал, разве твой опыт говорит об обратном?

AL>Типо магия с элементами божественного просветления, да?

Не магия, а трудноформализуемое умение, являющееся эмпирическим процессом по природе, и приходящее с опытом, с элементами интуиции и искусства. Зачем вырезал, следующий абзац, кстати?

AL>Мой опыт говорит следующее. Всякий раз, когда предпринимается попытка реализовать требования в архитектуре (ты об этом говоришь в позапрошлом посте),

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

AL>почти всегда, в большей или меньшей степени, происходит фиксация понятий предметной области в модели реализации системы. Ну, например, чтобы было всем понятно, если в предметной области есть понятия "счет" и "заказ", то люди немедленно начинают "дизайнить" вокруг них, что в конечном итоге порождает монолитную глыбу с кучей зависимостей, обвешанную костылями и абсолютно непригодную для последующей эволюции, которую, рано или поздно, приходится либо выбрасывать, либо оставлять в качестве тяжкого груза рядом с создаваемой новой системой, призванной удовлетворить растущие потребности. Причем это вообще не зависит ни от предметной области, ни от используемых технологий.

После этого не означает вследствие этого. Ничего плохого в анализе domain model, и появлении этих понятий в архитектуре, нет. Дело совсем не в наличии или отсуствии в системе понятий предметной области, и не в том, кто от чего начинает дизайнить. Дело в том, как вся система структурирована в целом, и насколько широкий класс приложений задает архитектура. То, что описываешь ты — происходит тогда, когда люди об архитектуре просто не думают. И она получается какая попало, никакой не класс требований — а целиком продиктованная сиюминутными требованиям, и поэтому хрупкая — сыпется от любого серьезного изменения. Архитектура — не та вещь, которая дешево делается итеративно. Ошибки в ней дороги. И над ней надо думать.

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

При таком взгляде на вещи и получается закономерный результат, который ты описал выше.

AL>При этом архитектура является неотъемлемой частью системы и создается, развивается и эволюционирует вместе с системой. Получив или выявив требования, мы формируем перечень функций и ограничений, после чего функции группируются в подсистемы по сходности достигаемых целей и режутся снизу вверх на слои для минимизации зависимости друг от друга и от окружения. Магия в том, как правильно сгруппировать и порезать, не поддавшись дьявольскому соблазну начать проектирование "в лоб". Есть ли польза от такой трактовки?

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

AL>Ну, иначе я даже не представляю, как хотя бы сформировать перечень целей и задач, которые должны быть достигнуты и выполнены в процессе проектирования при детальном планировании работ и последующем контроле. Это во-первых. Во-вторых, таким образом на базе одного фреймворка и кодовой базы удается реализовывать разные проекты для разных платформ в довольно короткие сроки при крайней ограниченности в ресурсах. Хотя, как недавно заметил thesz, наши проекты -- это по-любому полгода максимум, так что риск провала стоит копейки

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

Слово "архитектура" имеет смысл употреблять, когда цикл развития и поддержки продукта измеряется годами, и/или работает на ним больше одной рабочей группы в 5-6 человек.

Кстати, употребленный тобой термин "фреймворк" — это к архитектуре относится. Архитектурным решением является сам факт наличия фреймворка, а также структура фреймворка и граница между ним и прикладной логикой. Фреймворк является одной из базовых технологий, только своей собственной, а не сторонней разработки.

AL>Забыл сказать, что одним из авторов IEEE 1471-2000 является небезызвестный Philippe Kruchten. Вероятно, поэтому среди правильных дядек сей труд не фаворе

Ну, "от себя скажу" ((с) thesz), что автором понятия "детальный дизайн" является небезызвестный Уотс Хамфри, автор модели CMMI. Ты тоже не только со мной споришь, это не я придумал.

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

G>Стоп. Стоп. Архитектура уровня системы команд (Instructions Set Architecture) — это как раз хороший пример "стратегического решения", архитектуры в чистом виде, не имеющей отношения ни к дизайну, ни к алгоритмам со структурами данных. Одна и та же ISA может быть реализована совершенно по разному. SPARCv9 ISA можно реализовать c пятиступенчатым конвейром, можно с семи, или с девяти. Можно построить на ее основе суперскалярный проц. А можно — мультитредный, как Ниагара, не имеющий по внутренностям ничего общего с суперскалярным.

Документ с описанием самих команд и того, чем они оперируют (боюсь сказать, "структур данных"), описывает архитектуру уровня системы команд или что-то другое? Если что-то другое, то что именно? Если все-таки архитектуру, то где там "стратегия" и как быть с тем, что там явно перечисляются и описываются операции и операнды, которые по сути являются интерфейсом процессора с окружением?

G>Детальным дизайном в случае микропроцессора являются внутренние алгоритмы работы блоков. Скажем, описание алгоритма работы шедулера инструкций, выполняющих выборку независимых по регистрам инструкций в окне просмотра. Или логическая структура и алгоритмы кэша L1. Эти описания алгоритмов настолько далеко от реализации в Verilog, что является именно дизайном.

Мне удобнее называть это уровнем микроархитектуры, который реализует систему команд неким способом и состоит из неких блоков, связанных так-то и так-то и выполняющих такие-то функции. Каким именно образом -- см. раздел/документы, относящиеся к "детальному дизайну".

G>Не магия, а трудноформализуемое умение, являющееся эмпирическим процессом по природе, и приходящее с опытом, с элементами интуиции и искусства. Зачем вырезал, следующий абзац, кстати?

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


AL>>Мой опыт говорит следующее. Всякий раз, когда предпринимается попытка реализовать требования в архитектуре (ты об этом говоришь в позапрошлом посте),
G>О сколько нам открытий чудных. Покаж, где я об этом говорю. Можешь даже фразу из контекста выдернуть, я его (контекст) все равно верну обратно. Не люблю, когда пытаются извратить мои слова, игнорируя суть и цепляясь к второстепенным мелочам.

Пардон-пардон, вот здесь я действительно сурово все исказил, на самом деле опоннируя вот этой фразе:

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

и говоря о том, что реализуются не требования, а функционал, удовлетворяющий неким требованиям.

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

G>При таком взгляде на вещи и получается закономерный результат, который ты описал выше.

У кого получается? Вообще получается? У нас довольно сносно получается вроде бы.

AL>>При этом архитектура является неотъемлемой частью системы и создается, развивается и эволюционирует вместе с системой. Получив или выявив требования, мы формируем перечень функций и ограничений, после чего функции группируются в подсистемы по сходности достигаемых целей и режутся снизу вверх на слои для минимизации зависимости друг от друга и от окружения. Магия в том, как правильно сгруппировать и порезать, не поддавшись дьявольскому соблазну начать проектирование "в лоб". Есть ли польза от такой трактовки?

G>При такой трактовке "архитектура" неотличима от дизайна, что значит, что стратегические вопросы просто выпадают из под контроля. Ничего оригинального и полезного в этой трактовке я не вижу.

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

G>Полгода — это, во первых, далеко не копейки, если взять ассоциированные расходы и упущенную прибыль (часто задержка на полгода может стоить провала всего проекта), а во-вторых, с циклом в полгода существуют только прототипы или наколенные поделки, для которых не надо вообще заморачиваться понятием архитектуры.

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

G>Слово "архитектура" имеет смысл употреблять, когда цикл развития и поддержки продукта измеряется годами, и/или работает на ним больше одной рабочей группы в 5-6 человек.

Т.е. при семи годах и смешанной группе из 12 человек таки имеет смысл употреблять.

G>Кстати, употребленный тобой термин "фреймворк" — это к архитектуре относится. Архитектурным решением является сам факт наличия фреймворка, а также структура фреймворка и граница между ним и прикладной логикой. Фреймворк является одной из базовых технологий, только своей собственной, а не сторонней разработки.

Если бы было что-то готовое, удовлетворяющее нашим требованиям, наверное взяли бы готовое. А появился фреймворк в процессе разработки в виде одного из системных слоев и представляет он собой почти не претендующий на оригинальность стейт-машинный движок, координирующий работу разных подсистем так, что они ничего не знают друг о друге, а движок -- об их функциональных особенностях. Подсистема при этом -- вполне конкретное и ни капли не метафорическое понятие. Мне хочется продолжать считать, что сей фреймворк является одним из основных элементов архитектуры, лежащей в основе наших систем. Как и слой абстракции окружения, позволяющий одним взмахом генерить бинари и запускаться под Windows, QNX, RTOS-32, Windows CE и CMX-RTX. Ну хочется, и всё тут, ничего не могу с собой поделать

G>Ну, "от себя скажу" ((с) thesz), что автором понятия "детальный дизайн" является небезызвестный Уотс Хамфри, автор модели CMMI. Ты тоже не только со мной споришь, это не я придумал.

Я не ставлю под сомнение ценность понятия "детальный дизайн". Более того, стандарт IEEE 1016-1998 IEEE Recommended Practice for Software Design Descriptions, можно сказать, является настольной брошюрой

The purpose of the SDD is as follows:
IEEE/EIA 12207.1-1997, Clause 6.16.1: Purpose: Describe the design of a software item. Along with
the software architecture, it provides the detailed design needed to implement the software. It may be
supplemented by software item interface design and database design.

SDD -- software design description.


А авторы CMMI словно сговорились нас (в смысле меня) запутать Вот, например, цитата со с. 247 книжки Practical Insight into CMMI:

When we define functions, place them into logical groupings, and associate them with the requirements, we refer to this as the functional architecture.

В книжке Real Process Improvement Using the CMMI термин "архитектура процессных систем" упоминается в связке с термином "дизайн" через "или": architecture or design, например:

Critical Factor 4: Design First, Then Build
As briefly addressed in Chapter 3 — Managing the Process Improvement Project, process systems are sometimes built without an architecture or design. Not surprisingly, such process systems are often later rebuilt because the builders, usually SEPG, skipped design decisions which would have yielded a system closer to correct the first time

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

Здравствуйте, Аноним!

Я сдаюсь. У вас какие-то странные представления о процессе разработки десктоп-приложений. Подозреваю, что вам приходилось работать в командах без грамотного архитектора/постановки процесса — иначе откуда такой перекос ответственности и влияния в сторону дизайнера?

Точно так же можно было абсолютизировать роли программиста (поскольку он лучше вас знает возможности платформы) или проектировщика форматов данных — ибо пользователь покупает вашу программу не ради неё самой а ради её умения обрабатывать нужные пользователю данные, или эксперта в предметной области — кто ж лучше знает что нужно пользователю?

Единственное что могу посоветовать — попробовать поработать на проекте в другой роли — весь максимализм быстро выветрится.

Я конеш мгу ещё поспорить, но я не думаю что мне удастся вас переубедить, а вам — привести мне объективные доводы обуславливающие нечеловеческую мощь дизайнера в славном деле проектирования архитектуры.

Мировая?

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

S>а вам — привести мне объективные доводы обуславливающие нечеловеческую мощь дизайнера в славном деле проектирования архитектуры.

На последней итерации выяснилось, что вы банально не поняли того, что вам говорили, но взялись спорить (с неверно понятым). Нечеловеческая мощь дизайнера — в славном деле ограничения архитектуры, а не ее проектирования. Начните с этого тезиса. А будете ли вы продолжать — мне реально пофиг. У меня проблема с моей формулой была за всю историю ее применения только одна — где брать адекватных кадров, способных играть свои роли. Ваше непонимание моей проблемой не является.

Здравствуйте, Аноним...

S>>а вам — привести мне объективные доводы обуславливающие нечеловеческую мощь дизайнера в славном деле проектирования архитектуры.

А>На последней итерации выяснилось, что вы банально не поняли того, что вам говорили, но взялись спорить (с неверно понятым).

У-ххх.
Забавно, мило спорили, вроде договорились что спорить не о чем ибо разные понятийные аппараты — и тут пошли лёгкие намёки на наезды

Поцитируем что вы писали в начале:

Функция от требований — UI. Функция от всех аспектов UI — архитектура.

Теперь это превратилось в

Нечеловеческая мощь дизайнера — в славном деле ограничения архитектуры, а не ее проектирования

Я всё время спорил с вашим начальным тезисом, по своей наивной привычке считаю, что люди должны отдавать себе отчёт о чём они пишут и быть способными как минимум прокомментировать свою точку зрения.

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

Как с подобным можно спорить?

Удачи вам в подборе исполнителей своих ролей!

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

S>>>а вам — привести мне объективные доводы обуславливающие нечеловеческую мощь дизайнера в славном деле проектирования архитектуры.
А>>На последней итерации выяснилось, что вы банально не поняли того, что вам говорили, но взялись спорить (с неверно понятым).
S>У-ххх.
S>Забавно, мило спорили, вроде договорились что спорить не о чем ибо разные понятийные аппараты — и тут пошли лёгкие намёки на наезды

А что такое понятийный аппарат? Это как в анекдоте "аппарат-то у меня есть", то есть мозг?

S>Поцитируем что вы писали в начале:

S>

S>Функция от требований — UI. Функция от всех аспектов UI — архитектура.

S>Теперь это превратилось в
S>

S>Нечеловеческая мощь дизайнера — в славном деле ограничения архитектуры, а не ее проектирования

С моей точки зрения, вы весьма точно это сформулировали. Действительно, первое утверждение превратилось во второе. Они не являются тождественными: второе в первое не может превратиться (есть много причин и способов ограничивать одних другим). А первое во второе — может. Поскольку утверждается (мной), что (при известных условиях) славное дело — это когда архитектура зависит от дизайна, а наоборот — бесславное дело, значит дизайнер, так или иначе, ограничивает архитектуру. Если их переставить в "пищевой цепочке", то дизайн будет зависеть от архитектуры, и, значит, будет ей ограничиваться.

S>Я всё время спорил с вашим начальным тезисом, по своей наивной привычке считаю, что люди должны отдавать себе отчёт о чём они пишут и быть способными как минимум прокомментировать свою точку зрения.

Прокомментировал?

S>Теперь у вас UI всего лишь ограничивает архитектуру (хотя где-то выше вы писали что UI определяет архитектуру). Но вы по-прежнему уверены в исключительности UI и ведущей роли дизайнера. Сам вопрос о проектировании вы старательно обходите, заявляя что это проблемы архитектора.

??? Вы русский язык знаете? Ограничивать и определять — это синонимы. Ограничивать — проводить границу. Определять — проводить предел. Пределы и границы — это синонимы, потому и произведенные от них глаголы — синонимы.

S>Как с подобным можно спорить?
S>Удачи вам в подборе исполнителей своих ролей!

Спасибо, но не до актеров сейчас: кризис. Хоть сам пой на все голоса.

Здравствуйте, Аноним!

Сочуствую вашим проблемам с кризисом. Тем не менее:

А>??? Вы русский язык знаете? Ограничивать и определять — это синонимы. Ограничивать — проводить границу. Определять — проводить предел. Пределы и границы — это синонимы, потому и произведенные от них глаголы — синонимы.

Начались пляски с языком аля Задорнов сотоварищи? (где-то уже писалось про дилетантов от лингвистики — не про вас ни в коем случае). С.И.Ожегов, Н.Ю.Шведова — Толковый словарь русского языка:

ОПРЕДЕЛИТЬ
...
1. что. С точностью выяснить, установить.
...
2. что. Раскрыть словами содержание чего-н.
...
3. что. Установить, назначить.
...
4. (1 и 2 л. не употр.), что. То же, что обусловить (во 2 знач.). Хорошая подготовка определила успех дела.
...
5. кого (что). Назначить, устроить на какую-н. должность или в какое-н. учебное заведение (устар. и прост.).

и

ОГРАНИЧИТЬ...
Поставить в какие-н. рамки, границы, определить какими-н. условиями, а также сделать меньше, сократить охват кого-чего-н. ...

Одно и то же ? Я — наивный — вместе с Ожеговым понимал "определить" в 1-м или 2-м смыслах. Я ж говорю — расхождения ещё на уровне понятийного аппарата.

А>Действительно, первое утверждение превратилось во второе. Они не являются тождественными: второе в первое не может превратиться (есть много причин и способов ограничивать одних другим). А первое во второе — может. Поскольку утверждается (мной), что (при известных условиях) славное дело — это когда архитектура зависит от дизайна, а наоборот — бесславное дело, значит дизайнер, так или иначе, ограничивает архитектуру. Если их переставить в "пищевой цепочке", то дизайн будет зависеть от архитектуры, и, значит, будет ей ограничиваться.

Слушайте, давайте определимся — мы говорим о приоритетах, о ограничении или определении — это всё суть разные понятия. Про приоритеты вообще бестолку говорить — опять всё закончится на "кто в команде главнее". Про ограничения — вы утверждаете что UI должен (или может ) ограничивать архитектуру. Я утверждаю что UI в идеале не должен никак влиять на архитектуру и архитектура в идеале должна допускать произвольную логику взаимодействия с пользователем.

Что видите некорретного в моих утверждениях — опишите. А то остаётся чуство тягостного недоумения — вроде сказал, вроде услышали, а толку? Подозреваю, симметрично?

А>Прокомментировал?
Принято.

P.S. Вообще мне это сильно напоминает холивар "фундаментальное образование vs ЕГЭ". Та же аргументация — "мы не можем закладываться на сиюминутные требования рынка" vs "рынок должен определять требования к выпускникам".
На какой стороне мои симпатии — догадайтесь.
Вы за кого болеете?