Аннотация:
В статье автор подводит итог и пропускает через призму собственного опыта основные человеческие аспекты архитектуры программного обеспечения. Рассматривается эволюционная природа архитектуры, особенно ярко выраженная в малых проектах и стартапах. Субъективность решений по поводу применения шаблонов проектирования в социальном контексте конкретного проекта приводит к наличию разных стилей применения этих шаблонов. Неоднозначность и многогранность роли архитектора подчёркивает и усиливает первоочерёдность человеческих факторов (личных и командных) для процесса принятия технических решений и проектирования архитектуры в проектах по разработке программного обеспечения.
Re: Архитектура программного обеспечения с человеческим лицо
Очень интересная статья. Но есть пара вопросов. Если предположить, что приложение достаточно большое (архитектура утилиты ping как правило тривиальна), то интересно, какие именно "шаблоны проектирования" имелись в виду относительно архитектуры. Если описанные в книге gang of four — то непонятно, какое они отношение имеют к архитектуре. Те шаблоны — это рецепты по решению небольших задач в рамках программы. Совсем небольших. Тоесть понятно что в Microsoft Word применяется шаблон проектирования "observer". Даже несколько тысячь раз применяется. Но является ли это (существенной) частью архитектуры приложения? Нельзя же сказать что "архитектуры photoshop состоит из шаблонов проектирования visitor, observer и facade". Или можно?
Re[2]: Архитектура программного обеспечения с человеческим л
Здравствуйте, Eye of Hell, Вы писали:
EOH>Очень интересная статья. Но есть пара вопросов. Если предположить, что приложение достаточно большое (архитектура утилиты ping как правило тривиальна), то интересно, какие именно "шаблоны проектирования" имелись в виду относительно архитектуры. Если описанные в книге gang of four — то непонятно, какое они отношение имеют к архитектуре. Те шаблоны — это рецепты по решению небольших задач в рамках программы. Совсем небольших. Тоесть понятно что в Microsoft Word применяется шаблон проектирования "observer". Даже несколько тысячь раз применяется. Но является ли это (существенной) частью архитектуры приложения? Нельзя же сказать что "архитектуры photoshop состоит из шаблонов проектирования visitor, observer и facade". Или можно?
Вы правы, существует большое количество типов шаблонов проектирования, однако в статье не подразумевался какой-то конкретный. Умозаключения статьи равно применимы как для архитектурных шаблонов высокого уровня, так в том числе и для объектно-ориентированных шаблонов GoF.
Что касается правомерности утверждения о том, что шаблоны GoF можно/нельзя относить к предмету архитектуры программного обеспечения — на мой взгляд это выходит за рамки статьи, так что предлагаю обсудить это отдельно. Я выразил своё мнение по этому поводу на своём блоге: http://blog.tsybulnyk.com/post/Is-Design-Patterns-Usage-a-Part-of-Architecture.aspx
Re: Архитектура программного обеспечения с человеческим лицо
ЦВА>Авторы: ЦВА> Цыбульник Виталий Александрович
ЦВА>Аннотация: ЦВА>В статье автор подводит итог и пропускает через призму собственного опыта основные человеческие аспекты архитектуры программного обеспечения. Рассматривается эволюционная природа архитектуры, особенно ярко выраженная в малых проектах и стартапах. Субъективность решений по поводу применения шаблонов проектирования в социальном контексте конкретного проекта приводит к наличию разных стилей применения этих шаблонов. Неоднозначность и многогранность роли архитектора подчёркивает и усиливает первоочерёдность человеческих факторов (личных и командных) для процесса принятия технических решений и проектирования архитектуры в проектах по разработке программного обеспечения.
Опять на лице смешение понятия архитектуры и дизайна.
Архитектура ПО — некоторые рамки в пределах которых будет строиться ПО. Например будет ли приложение веб или декстоп, будет ли оно размещено в "облаке" или нет. Будет ли использовать реляционную СУБД или какую-то другую. С какими другими программами придется взаимодействовать и как это делать. Используемые языки и технологии.
Весь прикол архитектуры ПО, что она мало коррелирует с требованиями пользователей.
Как и архитектура в строительстве: задает некоторые каконы, по которым будет строиться здание: этажность, материалы итд. Но совершенно не говорит о том как будет строиться здание, какие функции у него будут итп.
Другое дело дизайн — это конкретный набор компонент и связей между ними для решения определенных задач. Выделенное как-бы намекает что должны быть задачи.
Архитектура определяет дизайн. Используемые языки и технологии сильно влияют на используемые паттерны. Приемы работы с БД в трехзвенном приложении вряд ли пригодятся на мобильном устройстве. Примеров можно привести много.
Архитектура не может быть эволюционной. В процессе эволюции декстоп не станет вебом, язык и платформа вряд ли сменится. Некоторые архитектурные решения могут поменяться, но зачастую это приводит к огромным затратам.
Дизайн при этом очень эволюционен, итерации дизайна выявляют новые требования, которые изменяют общий подход к решению.
Теперь главное: дизайном ПО должен заниматься каждый разработчик в меру своих способностей. Не бывает так что все важные решения уже приняты и осталось просто написать код.
Архитектура зачастую диктуется заказчиком, классом задач, окружением. Редко когда можно позволить себе вольности в архитектуре.
Когда говорим "архитектор ПО" надо четко представлять о ком мы говорим. Это может быть Ray Ozzie, а может быть Вася Пупкин из стартапа в три с половиной человека.
Re[2]: Архитектура программного обеспечения с человеческим л
Здравствуйте, gandjustas, Вы писали:
G>Опять на лице смешение понятия архитектуры и дизайна.
Согласен, архитектура и проектирование часто и здесь в частности смешаны. Но с процитированными высказываниями ниже сложно согласиться.
G>Архитектура ПО — некоторые рамки в пределах которых будет строиться ПО. Например будет ли приложение веб или декстоп, будет ли оно размещено в "облаке" или нет. Будет ли использовать реляционную СУБД или какую-то другую. С какими другими программами придется взаимодействовать и как это делать. Используемые языки и технологии. G>Весь прикол архитектуры ПО, что она мало коррелирует с требованиями пользователей.
Как раз архитектура и призвана выбрать средства для реализации требований к системе. Вы сами пишете, что архитектура определяет дизайн, а кто определяет архитектуру?
G>Как и архитектура в строительстве: задает некоторые каконы, по которым будет строиться здание: этажность, материалы итд. Но совершенно не говорит о том как будет строиться здание, какие функции у него будут итп.
По-крайней мере, если верить жене и всем ее знакомым строителям, которых я давно пытаю на тему отличия архитектора ПО и строительства, это не совсем так. Строительный архитектор задает внешнее качество здания: красоту и удобство проживания, к примеру, расположение того же туалета. В моем понимании это ровно то, что обязан делать архитектор ПО: отвечать за внешнее качество черного ящика, а не дизайнить его как белый. А вот в материалах строительный архитектор ничего не понимает (говорили, что даже в ВУЗе их этому не учат), точнее в их подборе на основе расчета сопротивления материалов и т.п. Этим у них занимается главный инженер проекта.
G>Архитектура не может быть эволюционной. В процессе эволюции декстоп не станет вебом, язык и платформа вряд ли сменится. Некоторые архитектурные решения могут поменяться, но зачастую это приводит к огромным затратам.
Разумеется, изменения в архитектурных принципах происходят не так часто, как выход новой версии компилятора C#. Все-таки уровень абстракции разный. Но в том же Architects Journal регулярно описывают старые рецепты архитектуры, которые только сейчас начинают применять в деле. В некотором роде эволюция...
Re[3]: Архитектура программного обеспечения с человеческим л
Здравствуйте, rsn81, Вы писали:
G>>Архитектура ПО — некоторые рамки в пределах которых будет строиться ПО. Например будет ли приложение веб или декстоп, будет ли оно размещено в "облаке" или нет. Будет ли использовать реляционную СУБД или какую-то другую. С какими другими программами придется взаимодействовать и как это делать. Используемые языки и технологии. G>>Весь прикол архитектуры ПО, что она мало коррелирует с требованиями пользователей. R>Как раз архитектура и призвана выбрать средства для реализации требований к системе. Вы сами пишете, что архитектура определяет дизайн, а кто определяет архитектуру?
Архитектура зачастую диктуется заказчиком, классом задач, окружением. Редко когда можно позволить себе вольности в архитектуре.
Например для системы документооборота это почти всегда будет многозвенное приложение, вероятнее всего с реляционной субд, написанное на управляемом языке, вроде java или .NET.
Довольно много ограничений не так ли? А даже не заикнулись о задачах.
Можно еще рассмотреть реальные параметры типа ограничения доступа, открытых портов, схем авторизации итп.
Другой пример. GSM-GPRS(Глонасс) модуль. Получает текущие координаты и другие параметры от датчиков и отправляет куданить. Задача единственная и очень простая.
Архитектурных решений надо принимать больше: форматы передачи, расширяемость протокола, обновление прошивки удаленно и многие другие вещи. Хотя с точки зрения дизайна все просто: получили текущие значения с устройств, сериализовали, отправили.
G>>Как и архитектура в строительстве: задает некоторые каконы, по которым будет строиться здание: этажность, материалы итд. Но совершенно не говорит о том как будет строиться здание, какие функции у него будут итп. R>По-крайней мере, если верить жене и всем ее знакомым строителям, которых я давно пытаю на тему отличия архитектора ПО и строительства, это не совсем так. Строительный архитектор задает внешнее качество здания: красоту и удобство проживания, к примеру, расположение того же туалета. В моем понимании это ровно то, что обязан делать архитектор ПО: отвечать за внешнее качество черного ящика, а не дизайнить его как белый. А вот в материалах строительный архитектор ничего не понимает (говорили, что даже в ВУЗе их этому не учат), точнее в их подборе на основе расчета сопротивления материалов и т.п. Этим у них занимается главный инженер проекта.
Не путай роли и задачи.
G>>Архитектура не может быть эволюционной. В процессе эволюции декстоп не станет вебом, язык и платформа вряд ли сменится. Некоторые архитектурные решения могут поменяться, но зачастую это приводит к огромным затратам. R>Разумеется, изменения в архитектурных принципах происходят не так часто, как выход новой версии компилятора C#. Все-таки уровень абстракции разный. Но в том же Architects Journal регулярно описывают старые рецепты архитектуры, которые только сейчас начинают применять в деле. В некотором роде эволюция...
Обычно описываются давно применяемые рецепты, но под другим "соусом", то есть под другим названием и вроде как с другими целями.
Re[3]: Архитектура программного обеспечения с человеческим л
Спасибо за развернутый ответ. Теперь могу с вами согласиться — да, оно субъективно . Лично я вижу в этом одну из основных проблемм отрасли — каждый архитектор применяет архитектурное решение "фундамент" не из индустриального справочника "типовые фундаменты", а придумывает его заного, основываясь на прочитанной пять лет назад книжке "фундаменты коттеджных домов — инструкция для дачников" .
однако читая между строк вопроса, мне кажется что на самом деле вопрос звучал так: "Чем больше приложение, тем менее детально оно проектируется, тем меньше проектных деталей включается в архитектуру, так ведь?". Отвечаю: нет, как раз наоборот. Фазы проектирования небольших программ (например упомянутой утилиты ping) может не быть вовсе, проект от этого врядли пострадает, и от того какой именно GoF-шаблон применит разработчик зависит не так уж много в проекте.
Вы мне льстите. На самом деле между строк было написано "А какие еще шаблоны кроме GoF знает автор?" На вопрос меня подвигли отсылки к литературе, где как раз и рассматривались шаблоны мелкоузлового проектирования. Теперь, ознакомившись с упоминанием "enterprise-шаблонами наподобие MVC, Client-Server или N-Tier" я вижу что автор разбирается в вопросе и к высказанному можно относиться серьезно.
BTW, подскажите старику — "мелкоузловое" и "крупноузловое" проектирование — у этих терминов для софтостроения есть английские аналоги? Очень мне эти термины понравились
Re[2]: Архитектура программного обеспечения с человеческим л
Опять на лице смешение понятия архитектуры и дизайна. Архитектура ПО — некоторые рамки в пределах которых будет строиться ПО. Например будет ли приложение веб или декстоп, будет ли оно размещено в "облаке" или нет. Будет ли использовать реляционную СУБД или какую-то другую. С какими другими программами придется взаимодействовать и как это делать. Используемые языки и технологии.
Скажем так — это ведь ваше мнение? Кто еще из известных архитекторов его придерживается? В каких признанных книгах оно отражено? Вот у меня например, опыт работы архитектором крупных продуктов конечно поскромнее, лет десять, но мнение по поводу того "что есть архитектура" отличается от сказанного. Что я понимаю под архитектурой. Wikipedia, "software architecture": set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both. Как я это вижу. Архитектура программного продукта — это то, как он устроен внутри, как устроены его внутренности, как они организованы и как взаимодействую между собой.
Например, если у меня есть Radmin, то я могу сказать что архитектура программы включает в себя драйвер видеозахвата, взаимодействующий с видеокартой и с user mode сервисом. Сервис построен в соответствии с архитектурой actor model, список акторов, их контрактов и взаимодействий прилагается. Сетевая подсистема реализована через асинхронные сокеты, взаимодействие с акторами такое-то. Шифрование происходит тут, сжатие происходит там, GUI вот в этой части с использованием MVC. Ну и так далее. При этом то, что программа написана на C++ — оно как бы вторично к архитектуре. Все то же самое можно переписать хоть на Java, хоть на .NET.
Весь прикол архитектуры ПО, что она мало коррелирует с требованиями пользователей.
Не соглашусь. Если к Radmin стоит требование "обеспечить одно подключение к удаленному компьютеру" — то архитектура в разы проще, чем при требовании "обеспечить произвольное количество одновременных подключений, тестируем до 100". Хотелки пользователей обеспечивают некие глобальные критерии выбора архитектуры — как мы будем использовать потоки, как взаимодействовать с базой данных, где нужно заложить оптимизацию сразу в архитектуру. Вторичные хотелки, такие как GUI и дополнительные функции, с архитектурой уже почти не взаимодействуют.
Неужели вы не сталкивались с ситуациями, когда изменения требования, на взгляд заказчика незначительные, приводят к смене архитектуры и переписыванию продукта практически заного? .
Как и архитектура в строительстве: задает некоторые каконы, по которым будет строиться здание: этажность, материалы итд. Но совершенно не говорит о том как будет строиться здание, какие функции у него будут итп.
Аналогия неуместна. Мы не здания строим.
Архитектура определяет дизайн. Используемые языки и технологии сильно влияют на используемые паттерны. Приемы работы с БД в трехзвенном приложении вряд ли пригодятся на мобильном устройстве. Примеров можно привести много.
Я бы сказал наоборот. То, что вы называете дизайном — это архитектура. А то, что вы называете архитектурой — это реализация архитектуры. Повторю, что одни и те же принципы архитектуры можно реализовать на любом языке, с использованием разных фреймворков. Как правило, архитектура ВКЛЮЧАЕТ в себя некие положения о ее реализации. Тоесть если я говорю, что надо под windows деражть миллион входящих подключений, то я как бы намекаю на C++, completion ports и соответствующие архитектурные решения. На практике вопросы "как будет работать" и "как будем реализовывать" решаются начерно вместе. Потом, естественно, вносятся коррективы.
Архитектура не может быть эволюционной. В процессе эволюции декстоп не станет вебом. язык и платформа вряд ли сменится
Это потому, что то, что вы называете архитектурой — это реализация. Естественно, что если у нас все приложение реализовано на C++, то мы реализацию сменить не можем — иначе это уже другое приложение. А вот поменять MV на MVC потому что гуй неожиданно из одного маленького окошка стал десятком больших — легко и непринужденно. Или SQLite на Postgres. Или блокирующие сокеты на асинхронные.
Теперь главное: дизайном ПО должен заниматься каждый разработчик в меру своих способностей. Не бывает так что все важные решения уже приняты и осталось просто написать код.
Холиварный вопрос про менеджмент. Мой скромный опыт показывает, что если разработчикам отдавать на откуп аръитектуру, то мы через полгода плодотворной работы получаем неподдерживаемую совокупность велосипедов и странных архитектурных решений. Потому как архитекторов мало и стоят они очень дорого .
Re[3]: Архитектура программного обеспечения с человеческим л
Опять на лице смешение понятия архитектуры и дизайна. Архитектура ПО — некоторые рамки в пределах которых будет строиться ПО. Например будет ли приложение веб или декстоп, будет ли оно размещено в "облаке" или нет. Будет ли использовать реляционную СУБД или какую-то другую. С какими другими программами придется взаимодействовать и как это делать. Используемые языки и технологии.
EOH>Скажем так — это ведь ваше мнение? Кто еще из известных архитекторов его придерживается? В каких признанных книгах оно отражено? Вот у меня например, опыт работы архитектором крупных продуктов конечно поскромнее, лет десять, но мнение по поводу того "что есть архитектура" отличается от сказанного. Что я понимаю под архитектурой. Wikipedia, "software architecture": set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both. Как я это вижу. Архитектура программного продукта — это то, как он устроен внутри, как устроены его внутренности, как они организованы и как взаимодействую между собой.
Тут важно понимать различие между архитектурой и дизайном, чтобы говорить на общем языке.
EOH>
Весь прикол архитектуры ПО, что она мало коррелирует с требованиями пользователей.
EOH>Не соглашусь. Если к Radmin стоит требование "обеспечить одно подключение к удаленному компьютеру" — то архитектура в разы проще, чем при требовании "обеспечить произвольное количество одновременных подключений, тестируем до 100".
Я же и говорю "мало коррелирует", а не "совсем не кореллирует". Кстати переход от одного пользователя ко многим пользователям в корне архитектуру меняет. так сказать меняет класс приложения.
Например есть ms word, в один момент времени только один человек может редактировать документ. Как поменяется архитектура, если необходимо будет нескольким одновременно редактировать документы.
EOH>Неужели вы не сталкивались с ситуациями, когда изменения требования, на взгляд заказчика незначительные, приводят к смене архитектуры и переписыванию продукта практически заного? .
EOH>
Как и архитектура в строительстве: задает некоторые каконы, по которым будет строиться здание: этажность, материалы итд. Но совершенно не говорит о том как будет строиться здание, какие функции у него будут итп.
EOH>Аналогия неуместна. Мы не здания строим.
Читал брукса Design of Design? Довольно много общего.
EOH>
Архитектура определяет дизайн. Используемые языки и технологии сильно влияют на используемые паттерны. Приемы работы с БД в трехзвенном приложении вряд ли пригодятся на мобильном устройстве. Примеров можно привести много.
EOH>Я бы сказал наоборот. То, что вы называете дизайном — это архитектура. А то, что вы называете архитектурой — это реализация архитектуры.
Да пожалуйста, используй любые термины, главное отличать одно от другого.
EOH>
Теперь главное: дизайном ПО должен заниматься каждый разработчик в меру своих способностей. Не бывает так что все важные решения уже приняты и осталось просто написать код.
EOH>Холиварный вопрос про менеджмент. Мой скромный опыт показывает, что если разработчикам отдавать на откуп аръитектуру, то мы через полгода плодотворной работы получаем неподдерживаемую совокупность велосипедов и странных архитектурных решений.
Как раз странные решения наиболее часто встречаются когда дизайном занимается один человек. Часто обосновывая это "мы всегда так делали".
Если разработчики будут учиться, а не быдлокодить, то очень быстро смогут принимать адекватные решения.
Re[4]: Архитектура программного обеспечения с человеческим л
EOH>>Аналогия неуместна. Мы не здания строим.
G>Читал брукса Design of Design? Довольно много общего.
Нет еще — она недавно вышла. В этом мире вообще много общего. Только вот строительство домов и разработка программного обеспечения — это совершенно разные дисциплины. В строительстве домов есть институты обучения инженеров и архитекторов, есть типовые решения и практики. А разработка софта — это каждый раз суп из ингредиентов, которые ты видишь первый раз в жизни (c) кто-то.
Re[5]: Архитектура программного обеспечения с человеческим л
EOH>>Аналогия неуместна. Мы не здания строим.
G>>Читал брукса Design of Design? Довольно много общего.
EOH>Нет еще — она недавно вышла. В этом мире вообще много общего. Только вот строительство домов и разработка программного обеспечения — это совершенно разные дисциплины. В строительстве домов есть институты обучения инженеров и архитекторов, есть типовые решения и практики. А разработка софта — это каждый раз суп из ингредиентов, которые ты видишь первый раз в жизни (c) кто-то.
А ты всетаки книгу прочитай, узнаешь много нового.
Re[6]: Архитектура программного обеспечения с человеческим л
А ты всетаки книгу прочитай, узнаешь много нового.
Увы, Станислав, — меня мало, а книжек много . Книжка наверняка хорошая и интересная, но у меня тут список из десятка, которые надо читать "вот здесь и сейчас" чтобы так нелюбимая всеми архитектура руководимых мною проектов не загнулась через пару лет . Но за наводку спасибо — если вдруг появится время... *мечтательно*.
Re[4]: Архитектура программного обеспечения с человеческим л
Здравствуйте, Eye of Hell, Вы писали:
EOH>BTW, подскажите старику — "мелкоузловое" и "крупноузловое" проектирование — у этих терминов для софтостроения есть английские аналоги? Очень мне эти термины понравились
В английском обычно используются термины "high-level" и "low-level", например "At a higher level there are architectural patterns that are larger in scope, usually describing an overall pattern followed by an entire system."
Но в пререводе на русский "высокоуровневые" и "низкоуровневые" звучит как-то унизительно по отношению ко вторым, поэтому я придумал эти термины "крупноузловые" и "мелкоузловые", которые мне кажутся более точными в русскоязычном употреблении.
Re[3]: Архитектура программного обеспечения с человеческим л
Совершенно согласен в данной дискуссии с Eye of Hell и пользуюсь именно тем пониманием терминов "архитектура" и "дизайн", которое им приведено.
2 gandjustas:
В статье как раз и был акцент на том, что к сожалению всё ещё нет единого мнения о понятии "архитектура", но есть некие общепринятые представлнения, поддерживаемые лидерами индустрии, и на которые и сделаны ссылки.
В частности если обратиться к Martin Fowler: “Who Needs an Architect?”, IEEE Software, July/August 2003 (http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf), то там замечательно все эти несогласия показаны.
Так вот по Фаулеру архитектура как раз ближе к тому, что вы называете дизайном, и об этом и была статья.
Re[4]: Архитектура программного обеспечения с человеческим л
Здравствуйте, Виталий Цыбульник, Вы писали:
ВЦ>В статье как раз и был акцент на том, что к сожалению всё ещё нет единого мнения о понятии "архитектура"
Если постоянно говорить о том что нет единого мнения, то его и не появится. Внеси свое непротиворечивое мнение о разделении понятий архитектура и дизайн.
ВЦ>но есть некие общепринятые представлнения, поддерживаемые лидерами индустрии, и на которые и сделаны ссылки.
Только эти "общеприятные" отличаются друг от друга. Причем многие из них наполнены противоречиями.
Re[5]: Архитектура программного обеспечения с человеческим л
Но в пререводе на русский "высокоуровневые" и "низкоуровневые" звучит как-то унизительно по отношению ко вторым, поэтому я придумал эти термины "крупноузловые" и "мелкоузловые", которые мне кажутся более точными в русскоязычном употреблении.
Мне тоже нравятся. Хорошие термины, годные. Бум внедрять .
Re[4]: Архитектура программного обеспечения с человеческим л
Здравствуйте, gandjustas, Вы писали:
G>Например для системы документооборота это почти всегда будет многозвенное приложение, вероятнее всего с реляционной субд, написанное на управляемом языке, вроде java или .NET. G>Довольно много ограничений не так ли? А даже не заикнулись о задачах. G>Можно еще рассмотреть реальные параметры типа ограничения доступа, открытых портов, схем авторизации итп.
G>Другой пример. GSM-GPRS(Глонасс) модуль. Получает текущие координаты и другие параметры от датчиков и отправляет куданить. Задача единственная и очень простая. G>Архитектурных решений надо принимать больше: форматы передачи, расширяемость протокола, обновление прошивки удаленно и многие другие вещи. Хотя с точки зрения дизайна все просто: получили текущие значения с устройств, сериализовали, отправили.
Странно, что в первом примере не упоминается необходимость принимать подобные решения. А они там тоже есть.
Re[5]: Архитектура программного обеспечения с человеческим л
Здравствуйте, Mihas, Вы писали:
M>Здравствуйте, gandjustas, Вы писали:
G>>Например для системы документооборота это почти всегда будет многозвенное приложение, вероятнее всего с реляционной субд, написанное на управляемом языке, вроде java или .NET. G>>Довольно много ограничений не так ли? А даже не заикнулись о задачах. G>>Можно еще рассмотреть реальные параметры типа ограничения доступа, открытых портов, схем авторизации итп.
G>>Другой пример. GSM-GPRS(Глонасс) модуль. Получает текущие координаты и другие параметры от датчиков и отправляет куданить. Задача единственная и очень простая. G>>Архитектурных решений надо принимать больше: форматы передачи, расширяемость протокола, обновление прошивки удаленно и многие другие вещи. Хотя с точки зрения дизайна все просто: получили текущие значения с устройств, сериализовали, отправили.
M>Странно, что в первом примере не упоминается необходимость принимать подобные решения. А они там тоже есть.
Там они окружением диктуются. При разработке на заказ — особенно.
Re[3]: Архитектура программного обеспечения с человеческим л
Опять на лице смешение понятия архитектуры и дизайна. Архитектура ПО — некоторые рамки в пределах которых будет строиться ПО. Например будет ли приложение веб или декстоп, будет ли оно размещено в "облаке" или нет. Будет ли использовать реляционную СУБД или какую-то другую. С какими другими программами придется взаимодействовать и как это делать. Используемые языки и технологии.
EOH>Скажем так — это ведь ваше мнение? Кто еще из известных архитекторов его придерживается? В каких признанных книгах оно отражено?
Коллега,а RUP подойдет?
“Software Architect. This role leads the development of the system's software architecture, which includes promoting and creating support for the key technical decisions that constrain the overall design and implementation for the project”.
“Designer. This role leads the design of a part of the system, within the constraints of the requirements, architecture, and development process for the project”.
. Лично я вижу в этом одну из основных проблемм отрасли — каждый архитектор применяет архитектурное решение "фундамент" не из индустриального справочника "типовые фундаменты", а придумывает его заного, основываясь на прочитанной пять лет назад книжке "фундаменты коттеджных домов — инструкция для дачников" 
