И попробуйте мне предметно объяснить, что именно по вашему я не понимаю. Просто страсть как любопытно, что нового мне могут рассказать про архитектуру, требования, и интерфейсы.
Вставая на точку зрения автора rsdn'вского сообшения: Достаточно часто возникающая поблема в том, что заказчик хочет фенечку в UI, а архитектура, пардон, не позволяет. Толчок к архитектуре от UI - это попытка избежать таких проблем.
Выбирая точку зрения Gaperton'a Пацаны! Да дохр..на чего есть помимо UI. Требованием к системе иногда является то чтобы система , о боже, работала, работала быстро, масштабировалась, не требовала антигеморойных свечей для программистов её расширяющих. Ну как ну-ка.. вынь да положь мне архитектуру для таких случаев отталкиваясь от UI
> Достаточно часто возникающая поблема в том, что заказчик хочет фенечку в UI, а архитектура, пардон, не позволяет. Толчок к архитектуре от UI - это попытка избежать таких проблем.
Аккуратно поинтересуемся - хоть вы и не автор этих слов, но что это за "архитектура" такая, простите, что она фенечку добавить не позволяет? Это может быть как те яйца, что известному танцору мешают? Можно пример этой страшной ситуации?
G> Требования могут каскадироваться - "реализация" требований верхнего уровня может являеться набором требований для компонент нижних уровней.
Опять же.. не особо отстаивая точку зрения приоритетности UI, но все же.
Изменения вернего уровня, бывает что, вызывают каскадные изменения во всех нижних. Такие изменения обычно достаточно трудозатратны. Попытка начать строить архитектуру сверху от UI, это как раз imho попытка верно спроектироать _все_ уровни, сразу.
А если бы заказчику требовался тщательно отранжированный каталог, то супер мега архитектура обеспечивающая автоматический подбор релевантности по введенным пользователем словам оказывается полностью непригодной.
>>И каким именно образом UI нам поможет Предотвратит фатальтную ошибку, но не подскажет конечно, критичных мест.
На мой взгляд у людей мешаются два внешнесхожих, но очень разных по сути понятия - ВИ и УИ. Варианты использования действительно определяют архитектуру, потому как собственно описывают зачем вообще нужен продукт и что с ним будут делать. Юзер интерфейс описывает только КАК с продуктом будут делать то что требуется. И в этом смысле УИ является следствием, а не основанием.
грубо - ни в чём, это синонимы. чуть точнее - слово "дизайн" чуть более inclusive. например, на нижнем уровне можно говорить про дизайн конкретного класса или даже метода. говорить про архитектуру класса - чересчур пафосно. а вот на более высоком уровне - архитектура системы или дизайн системы - синонимы, как в смысле процесса, так и в смысле результата.
Ну вот. С этого надо было начинать. Ты не отличаешь архитектуру от дизайна, вся разница между ними для тебя - в "пафосности" терминов. То есть, попросту, ты не понимаещь, о чем люди говорят.
Я уже давно заметил, что если человеку есть что сказать по существу - то он с этого и начинает. Ему длинная прелюдия, в духе "ах какой вы тупой и ничего не понимаете, а я умный и все понимаю" с попутным ломанием "ах нет, я не буду вам ничего рассказывать, потому что оскорблен в лучших чувствах" не нужна. Не требуется ему маскировать пустоту.
Comments 25
Reply
Reply
Reply
http://rsdn.ru/forum/message/3306487.1.aspx
И попробуйте мне предметно объяснить, что именно по вашему я не понимаю. Просто страсть как любопытно, что нового мне могут рассказать про архитектуру, требования, и интерфейсы.
Reply
Достаточно часто возникающая поблема в том, что заказчик хочет фенечку в UI, а архитектура, пардон, не позволяет. Толчок к архитектуре от UI - это попытка избежать таких проблем.
Выбирая точку зрения Gaperton'a
Пацаны! Да дохр..на чего есть помимо UI. Требованием к системе иногда является то чтобы система , о боже, работала, работала быстро, масштабировалась, не требовала антигеморойных свечей для программистов её расширяющих. Ну как ну-ка.. вынь да положь мне архитектуру для таких случаев отталкиваясь от UI
:)
Reply
Аккуратно поинтересуемся - хоть вы и не автор этих слов, но что это за "архитектура" такая, простите, что она фенечку добавить не позволяет? Это может быть как те яйца, что известному танцору мешают? Можно пример этой страшной ситуации?
Reply
Вот пример как архитектура языка, увеличивает сложность создания продукта(пользовательского интерфейса), и ограничивает функционал.
Reply
Опять же.. не особо отстаивая точку зрения приоритетности UI, но все же.
Изменения вернего уровня, бывает что, вызывают каскадные изменения во всех нижних. Такие изменения обычно достаточно трудозатратны. Попытка начать строить архитектуру сверху от UI, это как раз imho попытка верно спроектироать _все_ уровни, сразу.
Reply
Пример: google.com
И каким именно образом UI нам поможет при разработке архитектуры поискового движка?
Reply
>>И каким именно образом UI нам поможет
Предотвратит фатальтную ошибку, но не подскажет конечно, критичных мест.
Reply
Reply
Варианты использования действительно определяют архитектуру, потому как собственно описывают зачем вообще нужен продукт и что с ним будут делать. Юзер интерфейс описывает только КАК с продуктом будут делать то что требуется. И в этом смысле УИ является следствием, а не основанием.
Reply
А вот действительно ли именно варианты использования определяют именно архитектуру? В чем разница между архитектурой, и дизайном?
Reply
Reply
Я уже давно заметил, что если человеку есть что сказать по существу - то он с этого и начинает. Ему длинная прелюдия, в духе "ах какой вы тупой и ничего не понимаете, а я умный и все понимаю" с попутным ломанием "ах нет, я не буду вам ничего рассказывать, потому что оскорблен в лучших чувствах" не нужна. Не требуется ему маскировать пустоту.
Reply
Leave a comment