G> Требования могут каскадироваться - "реализация" требований верхнего уровня может являеться набором требований для компонент нижних уровней.
Опять же.. не особо отстаивая точку зрения приоритетности UI, но все же.
Изменения вернего уровня, бывает что, вызывают каскадные изменения во всех нижних. Такие изменения обычно достаточно трудозатратны. Попытка начать строить архитектуру сверху от UI, это как раз imho попытка верно спроектироать _все_ уровни, сразу.
А если бы заказчику требовался тщательно отранжированный каталог, то супер мега архитектура обеспечивающая автоматический подбор релевантности по введенным пользователем словам оказывается полностью непригодной.
>>И каким именно образом UI нам поможет Предотвратит фатальтную ошибку, но не подскажет конечно, критичных мест.
Use Cases уже лучше. В описании Use Case говориться не только "как", но и "зачем". В Use Cases для диагностического прибора будут описаны не интерфейсы, а способы полезного использования прибора. Однако, Use Cases - покрывает не все виды требований, хотя и значительную их часть.
Можно-ли проигнорировать нефункциональные требования, и не ошибиться при этом в архитектуре? А если нельзя, и принимать надо во внимание _все_ требования, то какая разница, что в них более приоритетно?
Хм.. ну вот например, я не раз сталкивался с тем что заказчик воспринимает только прототипы UI интерфейса... а на все остальное только выдает стандартный ответ - That's OK, THKS 4 good job.
Пример архитектурной ошибки в одном из вполне "гражданских" проектов по разработке ПО, в котором я учавствовал. В архитектуру системы разработки и запуска торговых роботов было заложено применение SQL Server для хранения всех персистентных данных приложения - на сервере. Казалось бы, нормально. Однако, мы поимели чудовищный геморрой на ровном месте. Приложение работало, но трудозатраты вспухли вдвое на ровном месте. Начиная с того, что пришлось переписывать файловые диалоги (неблагодарное занятие эмулировать ФС поверх MS SQL), заканчивая чудовищным геморроем при апгрейде сервера и клиентов (сильная связь по схеме БД). Сделать можно все - было бы ради чего
( ... )
Когда мы рассуждаем о дизайне, архитектуре, и прочем - очень полезен взгляд от ошибок, он многое проясняет.
А вот еще примеры. В одной компании, где я работал, в основу архиектуры сервера компьютерной телефонии положен майкрософтский TAPI - он стоит в центре. Что является теперь основной проблемой - источником багов, тормозов, и умножителем трудозатрат для простых модификаций, и, таким образом - ограничителем для добавления нового функционала.
Пользователь видит TAPI? Да в общем, нет, ему все равно, стоит TAPI в центре или сбоку.
Опять же.. не особо отстаивая точку зрения приоритетности UI, но все же.
Изменения вернего уровня, бывает что, вызывают каскадные изменения во всех нижних. Такие изменения обычно достаточно трудозатратны. Попытка начать строить архитектуру сверху от UI, это как раз imho попытка верно спроектироать _все_ уровни, сразу.
Reply
Пример: google.com
И каким именно образом UI нам поможет при разработке архитектуры поискового движка?
Reply
>>И каким именно образом UI нам поможет
Предотвратит фатальтную ошибку, но не подскажет конечно, критичных мест.
Reply
Reply
Можно-ли проигнорировать нефункциональные требования, и не ошибиться при этом в архитектуре? А если нельзя, и принимать надо во внимание _все_ требования, то какая разница, что в них более приоритетно?
Reply
Reply
Reply
А вот еще примеры. В одной компании, где я работал, в основу архиектуры сервера компьютерной телефонии положен майкрософтский TAPI - он стоит в центре. Что является теперь основной проблемой - источником багов, тормозов, и умножителем трудозатрат для простых модификаций, и, таким образом - ограничителем для добавления нового функционала.
Пользователь видит TAPI? Да в общем, нет, ему все равно, стоит TAPI в центре или сбоку.
Reply
Leave a comment