Опять на лице смешение понятия архитектуры и дизайна. Архитектура ПО — некоторые рамки в пределах которых будет строиться ПО. Например будет ли приложение веб или декстоп, будет ли оно размещено в "облаке" или нет. Будет ли использовать реляционную СУБД или какую-то другую. С какими другими программами придется взаимодействовать и как это делать. Используемые языки и технологии.
Скажем так — это ведь ваше мнение? Кто еще из известных архитекторов его придерживается? В каких признанных книгах оно отражено? Вот у меня например, опыт работы архитектором крупных продуктов конечно поскромнее, лет десять, но мнение по поводу того "что есть архитектура" отличается от сказанного. Что я понимаю под архитектурой. 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: Архитектура программного обеспечения с человеческим лицо
ЦВА>Авторы: ЦВА> Цыбульник Виталий Александрович
ЦВА>Аннотация: ЦВА>В статье автор подводит итог и пропускает через призму собственного опыта основные человеческие аспекты архитектуры программного обеспечения. Рассматривается эволюционная природа архитектуры, особенно ярко выраженная в малых проектах и стартапах. Субъективность решений по поводу применения шаблонов проектирования в социальном контексте конкретного проекта приводит к наличию разных стилей применения этих шаблонов. Неоднозначность и многогранность роли архитектора подчёркивает и усиливает первоочерёдность человеческих факторов (личных и командных) для процесса принятия технических решений и проектирования архитектуры в проектах по разработке программного обеспечения.
Опять на лице смешение понятия архитектуры и дизайна.
Архитектура ПО — некоторые рамки в пределах которых будет строиться ПО. Например будет ли приложение веб или декстоп, будет ли оно размещено в "облаке" или нет. Будет ли использовать реляционную СУБД или какую-то другую. С какими другими программами придется взаимодействовать и как это делать. Используемые языки и технологии.
Весь прикол архитектуры ПО, что она мало коррелирует с требованиями пользователей.
Как и архитектура в строительстве: задает некоторые каконы, по которым будет строиться здание: этажность, материалы итд. Но совершенно не говорит о том как будет строиться здание, какие функции у него будут итп.
Другое дело дизайн — это конкретный набор компонент и связей между ними для решения определенных задач. Выделенное как-бы намекает что должны быть задачи.
Архитектура определяет дизайн. Используемые языки и технологии сильно влияют на используемые паттерны. Приемы работы с БД в трехзвенном приложении вряд ли пригодятся на мобильном устройстве. Примеров можно привести много.
Архитектура не может быть эволюционной. В процессе эволюции декстоп не станет вебом, язык и платформа вряд ли сменится. Некоторые архитектурные решения могут поменяться, но зачастую это приводит к огромным затратам.
Дизайн при этом очень эволюционен, итерации дизайна выявляют новые требования, которые изменяют общий подход к решению.
Теперь главное: дизайном ПО должен заниматься каждый разработчик в меру своих способностей. Не бывает так что все важные решения уже приняты и осталось просто написать код.
Архитектура зачастую диктуется заказчиком, классом задач, окружением. Редко когда можно позволить себе вольности в архитектуре.
Когда говорим "архитектор ПО" надо четко представлять о ком мы говорим. Это может быть Ray Ozzie, а может быть Вася Пупкин из стартапа в три с половиной человека.
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: Архитектура программного обеспечения с человеческим лицо
EOH>>Аналогия неуместна. Мы не здания строим.
G>Читал брукса Design of Design? Довольно много общего.
Нет еще — она недавно вышла. В этом мире вообще много общего. Только вот строительство домов и разработка программного обеспечения — это совершенно разные дисциплины. В строительстве домов есть институты обучения инженеров и архитекторов, есть типовые решения и практики. А разработка софта — это каждый раз суп из ингредиентов, которые ты видишь первый раз в жизни (c) кто-то.
Re: Архитектура программного обеспечения с человеческим лицо
Очень интересная статья. Но есть пара вопросов. Если предположить, что приложение достаточно большое (архитектура утилиты ping как правило тривиальна), то интересно, какие именно "шаблоны проектирования" имелись в виду относительно архитектуры. Если описанные в книге gang of four — то непонятно, какое они отношение имеют к архитектуре. Те шаблоны — это рецепты по решению небольших задач в рамках программы. Совсем небольших. Тоесть понятно что в Microsoft Word применяется шаблон проектирования "observer". Даже несколько тысячь раз применяется. Но является ли это (существенной) частью архитектуры приложения? Нельзя же сказать что "архитектуры photoshop состоит из шаблонов проектирования visitor, observer и facade". Или можно?
Re[3]: Архитектура программного обеспечения с человеческим л
Здравствуйте, rsn81, Вы писали:
G>>Архитектура ПО — некоторые рамки в пределах которых будет строиться ПО. Например будет ли приложение веб или декстоп, будет ли оно размещено в "облаке" или нет. Будет ли использовать реляционную СУБД или какую-то другую. С какими другими программами придется взаимодействовать и как это делать. Используемые языки и технологии. G>>Весь прикол архитектуры ПО, что она мало коррелирует с требованиями пользователей. R>Как раз архитектура и призвана выбрать средства для реализации требований к системе. Вы сами пишете, что архитектура определяет дизайн, а кто определяет архитектуру?
Архитектура зачастую диктуется заказчиком, классом задач, окружением. Редко когда можно позволить себе вольности в архитектуре.
Например для системы документооборота это почти всегда будет многозвенное приложение, вероятнее всего с реляционной субд, написанное на управляемом языке, вроде java или .NET.
Довольно много ограничений не так ли? А даже не заикнулись о задачах.
Можно еще рассмотреть реальные параметры типа ограничения доступа, открытых портов, схем авторизации итп.
Другой пример. GSM-GPRS(Глонасс) модуль. Получает текущие координаты и другие параметры от датчиков и отправляет куданить. Задача единственная и очень простая.
Архитектурных решений надо принимать больше: форматы передачи, расширяемость протокола, обновление прошивки удаленно и многие другие вещи. Хотя с точки зрения дизайна все просто: получили текущие значения с устройств, сериализовали, отправили.
G>>Как и архитектура в строительстве: задает некоторые каконы, по которым будет строиться здание: этажность, материалы итд. Но совершенно не говорит о том как будет строиться здание, какие функции у него будут итп. R>По-крайней мере, если верить жене и всем ее знакомым строителям, которых я давно пытаю на тему отличия архитектора ПО и строительства, это не совсем так. Строительный архитектор задает внешнее качество здания: красоту и удобство проживания, к примеру, расположение того же туалета. В моем понимании это ровно то, что обязан делать архитектор ПО: отвечать за внешнее качество черного ящика, а не дизайнить его как белый. А вот в материалах строительный архитектор ничего не понимает (говорили, что даже в ВУЗе их этому не учат), точнее в их подборе на основе расчета сопротивления материалов и т.п. Этим у них занимается главный инженер проекта.
Не путай роли и задачи.
G>>Архитектура не может быть эволюционной. В процессе эволюции декстоп не станет вебом, язык и платформа вряд ли сменится. Некоторые архитектурные решения могут поменяться, но зачастую это приводит к огромным затратам. R>Разумеется, изменения в архитектурных принципах происходят не так часто, как выход новой версии компилятора C#. Все-таки уровень абстракции разный. Но в том же Architects Journal регулярно описывают старые рецепты архитектуры, которые только сейчас начинают применять в деле. В некотором роде эволюция...
Обычно описываются давно применяемые рецепты, но под другим "соусом", то есть под другим названием и вроде как с другими целями.
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[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[2]: Архитектура программного обеспечения с человеческим л
Здравствуйте, gandjustas, Вы писали:
G>Опять на лице смешение понятия архитектуры и дизайна.
Согласен, архитектура и проектирование часто и здесь в частности смешаны. Но с процитированными высказываниями ниже сложно согласиться.
G>Архитектура ПО — некоторые рамки в пределах которых будет строиться ПО. Например будет ли приложение веб или декстоп, будет ли оно размещено в "облаке" или нет. Будет ли использовать реляционную СУБД или какую-то другую. С какими другими программами придется взаимодействовать и как это делать. Используемые языки и технологии. G>Весь прикол архитектуры ПО, что она мало коррелирует с требованиями пользователей.
Как раз архитектура и призвана выбрать средства для реализации требований к системе. Вы сами пишете, что архитектура определяет дизайн, а кто определяет архитектуру?
G>Как и архитектура в строительстве: задает некоторые каконы, по которым будет строиться здание: этажность, материалы итд. Но совершенно не говорит о том как будет строиться здание, какие функции у него будут итп.
По-крайней мере, если верить жене и всем ее знакомым строителям, которых я давно пытаю на тему отличия архитектора ПО и строительства, это не совсем так. Строительный архитектор задает внешнее качество здания: красоту и удобство проживания, к примеру, расположение того же туалета. В моем понимании это ровно то, что обязан делать архитектор ПО: отвечать за внешнее качество черного ящика, а не дизайнить его как белый. А вот в материалах строительный архитектор ничего не понимает (говорили, что даже в ВУЗе их этому не учат), точнее в их подборе на основе расчета сопротивления материалов и т.п. Этим у них занимается главный инженер проекта.
G>Архитектура не может быть эволюционной. В процессе эволюции декстоп не станет вебом, язык и платформа вряд ли сменится. Некоторые архитектурные решения могут поменяться, но зачастую это приводит к огромным затратам.
Разумеется, изменения в архитектурных принципах происходят не так часто, как выход новой версии компилятора C#. Все-таки уровень абстракции разный. Но в том же Architects Journal регулярно описывают старые рецепты архитектуры, которые только сейчас начинают применять в деле. В некотором роде эволюция...
Re[3]: Архитектура программного обеспечения с человеческим л
Спасибо за развернутый ответ. Теперь могу с вами согласиться — да, оно субъективно . Лично я вижу в этом одну из основных проблемм отрасли — каждый архитектор применяет архитектурное решение "фундамент" не из индустриального справочника "типовые фундаменты", а придумывает его заного, основываясь на прочитанной пять лет назад книжке "фундаменты коттеджных домов — инструкция для дачников" .
однако читая между строк вопроса, мне кажется что на самом деле вопрос звучал так: "Чем больше приложение, тем менее детально оно проектируется, тем меньше проектных деталей включается в архитектуру, так ведь?". Отвечаю: нет, как раз наоборот. Фазы проектирования небольших программ (например упомянутой утилиты ping) может не быть вовсе, проект от этого врядли пострадает, и от того какой именно GoF-шаблон применит разработчик зависит не так уж много в проекте.
Вы мне льстите. На самом деле между строк было написано "А какие еще шаблоны кроме GoF знает автор?" На вопрос меня подвигли отсылки к литературе, где как раз и рассматривались шаблоны мелкоузлового проектирования. Теперь, ознакомившись с упоминанием "enterprise-шаблонами наподобие MVC, Client-Server или N-Tier" я вижу что автор разбирается в вопросе и к высказанному можно относиться серьезно.
BTW, подскажите старику — "мелкоузловое" и "крупноузловое" проектирование — у этих терминов для софтостроения есть английские аналоги? Очень мне эти термины понравились
Re[5]: Архитектура программного обеспечения с человеческим л
EOH>>Аналогия неуместна. Мы не здания строим.
G>>Читал брукса Design of Design? Довольно много общего.
EOH>Нет еще — она недавно вышла. В этом мире вообще много общего. Только вот строительство домов и разработка программного обеспечения — это совершенно разные дисциплины. В строительстве домов есть институты обучения инженеров и архитекторов, есть типовые решения и практики. А разработка софта — это каждый раз суп из ингредиентов, которые ты видишь первый раз в жизни (c) кто-то.
А ты всетаки книгу прочитай, узнаешь много нового.
Re[6]: Архитектура программного обеспечения с человеческим л
А ты всетаки книгу прочитай, узнаешь много нового.
Увы, Станислав, — меня мало, а книжек много . Книжка наверняка хорошая и интересная, но у меня тут список из десятка, которые надо читать "вот здесь и сейчас" чтобы так нелюбимая всеми архитектура руководимых мною проектов не загнулась через пару лет . Но за наводку спасибо — если вдруг появится время... *мечтательно*.
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”.
Теперь главное: дизайном ПО должен заниматься каждый разработчик в меру своих способностей. Не бывает так что все важные решения уже приняты и осталось просто написать код.
EOH>Холиварный вопрос про менеджмент. Мой скромный опыт показывает, что если разработчикам отдавать на откуп аръитектуру, то мы через полгода плодотворной работы получаем неподдерживаемую совокупность велосипедов и странных архитектурных решений. Потому как архитекторов мало и стоят они очень дорого .
Стремление системного архитектора влезать в дизайн каждого компонента и там похозяйничать, ИМХО, это неприятие делегирования и зло мелкоменджмента.
А что касается "изобретения велосипедов", так сам виноват. Не поручай проектирование компонентов "кухаркам".
Re[4]: Архитектура программного обеспечения с человеческим л
Здравствуйте, craft-brother, Вы писали:
CB>“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”.
CB>“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”.
А вот скажите, коллега, а выбор языка программирования является ли частью архитектуры? или дизайна?
Я к тому что уж больно размытое это понятние key technical decisions that constrain the overall design — каждый архитектор интерпретирует его в зависимости от условий и требований проекта.
Об этом и была статья...
Re[5]: Архитектура программного обеспечения с человеческим л
Здравствуйте, Виталий Цыбульник, Вы писали:
ВЦ>А вот скажите, коллега, а выбор языка программирования является ли частью архитектуры? или дизайна?
ВЦ>Я к тому что уж больно размытое это понятние key technical decisions that constrain the overall design — каждый архитектор интерпретирует его в зависимости от условий и требований проекта. ВЦ>Об этом и была статья...
К первоисточникам! Коллега. "Учиться, учиться и учиться..." (с) Классики марксизма-ленинизма
Что делает системный архитектор — смотрим RUP:
Успехов.
Re[4]: Архитектура программного обеспечения с человеческим л
Я этого боялся . Ладно, рассмотрим RUP ;-E~. Прежде чем его рассмотреть, уточним что такое RUP. RUP — это формализованный процесс для автоматизации бизнеса. Согласитесь, задача достаточно специфическая. Сильно отличается от разработки коробочных продуктов, операционных систем или веб-порталов.
В качестве информации воспользуюсь сайтом IBM. Понимаю, что источник так себе, но вручную выжимку из process books я сделать не смогу. Есть у IBM такая хорошая статья, называется Understanding RUP roles. Что там пишут:
"The iterative approach to software development embodied in RUP urges practitioners to adopt two perspectives. First, it urges the team to understand the overall solution, and then in each iteration to re-evaluate and adjust the overall solution, based on the results of previous iterations. The two views corresponding to these perspectives are often called the breadth view and the depth view. In an iterative project, you focus first on the breadth view, and then pick a piece to focus on in depth. Separating breadth and depth, as we do in iterative development, makes a project much more resilient to change. Not only is the breadth view easier to create, but also, when change comes, you can smile, shrug, and adjust the breadth view with little effort."
А под этим табличка, в которой и архитектор и дизайнер соответствую как раз двум фокусам на "Analysis and Design". Смотрим:
Software Architect: Decides on technologies for the whole solution.
Designer: Details the analysis and design for a single set of use cases.
Совмещая это с выше процитированным тестом, делаем выжимку на русском: "Есть задача 'анализ и дизайн'. В рамках RUP рассматривается в широком фокусе и в узком фокусе. В широком фокусе задачу решает архитектор. В узком фокусе — дизайнер. Занимаются одним и тем же".
Вывод: RUP считает, что архитектор и дизайнер делают одно и то же на разном уровне детализованности. То есть мое определение архитектуры тут всего лишь разделено на два: макроархитектура в лице архитектора и микроархитектура в лице UML и имплементации индусами.
Напоминаю основной вопрос. Я считаю что макроархитектура и икроархитектура — это одно и то же, но разного уровня детализованности. Вы же с коллегой считаете, что макроархитектура ( в вашей терминологии — архитектура и микроархитектура (в вашей терминологии — дизайн) — это разные вещи, где на макро уровне стек технологий вида LAMP, а на микро уровне непосредствено код. RUP, насколько я вижу, все-таки ближе к моей позиции, хотя и использует термин "designer"
Re[5]: Архитектура программного обеспечения с человеческим л
EOH>Я этого боялся . Ладно, рассмотрим RUP ;-E~. Прежде чем его рассмотреть, уточним что такое RUP. RUP — это формализованный процесс для автоматизации бизнеса. Согласитесь, задача достаточно специфическая. Сильно отличается от разработки коробочных продуктов, операционных систем или веб-порталов.
Ок. Понял. Могут быть только два мнения: твое и неправильное : .
EOH>В качестве информации воспользуюсь сайтом IBM. Понимаю, что источник так себе, но вручную выжимку из process books я сделать не смогу. Есть у IBM такая хорошая статья, называется Understanding RUP roles. Что там пишут:
EOH>"The iterative approach to software development embodied in RUP urges practitioners to adopt two perspectives. First, it urges the team to understand the overall solution, and then in each iteration to re-evaluate and adjust the overall solution, based on the results of previous iterations. The two views corresponding to these perspectives are often called the breadth view and the depth view. In an iterative project, you focus first on the breadth view, and then pick a piece to focus on in depth. Separating breadth and depth, as we do in iterative development, makes a project much more resilient to change. Not only is the breadth view easier to create, but also, when change comes, you can smile, shrug, and adjust the breadth view with little effort."
Упс... А где здесь про архитектуру и проектирование???
EOH>А под этим табличка, в которой и архитектор и дизайнер соответствую как раз двум фокусам на "Analysis and Design". Смотрим: EOH>Software Architect: Decides on technologies for the whole solution. EOH>Designer: Details the analysis and design for a single set of use cases.
EOH>Совмещая это с выше процитированным тестом, делаем выжимку на русском: "Есть задача 'анализ и дизайн'. В рамках RUP рассматривается в широком фокусе и в узком фокусе. В широком фокусе задачу решает архитектор. В узком фокусе — дизайнер. Занимаются одним и тем же".
EOH>Вывод: RUP считает, что архитектор и дизайнер делают одно и то же на разном уровне детализованности. То есть мое определение архитектуры тут всего лишь разделено на два: макроархитектура в лице архитектора и микроархитектура в лице UML и имплементации индусами.
EOH>Напоминаю основной вопрос. Я считаю что макроархитектура и икроархитектура — это одно и то же, но разного уровня детализованности. Вы же с коллегой считаете, что макроархитектура ( в вашей терминологии — архитектура и микроархитектура (в вашей терминологии — дизайн) — это разные вещи, где на макро уровне стек технологий вида LAMP, а на микро уровне непосредствено код. RUP, насколько я вижу, все-таки ближе к моей позиции, хотя и использует термин "designer"
Да о чем спорим-то! И тот и другой делают одинаковую работу: анализ проблемы и синтез решения, удовлетворяющего требованиям. Только делают ее на разном уровне.
Готов предложить свой вариант. Архитектор – это дизайнер системы на верхнем уровне. Проектировщик – дизайнер компонента системы. Программист – дизайнер программного пакета. Стажер – дизайнер класса HelloWorld.
Не важно, как называть. Но важно, что в больших проектах — это должны быть разные люди. Иначе мы не справимся со сложностью. И каждый должен отвечать за свою часть общего результата. И архитектор не должен запускать свои ручки в компонент. Нет права на самостоятельное решение – не может быть ответственности за результат.
Но есть одна из важнейших задач архитектора — следить за общими архитектурными принципами, которые он установил и о которых договорился с проектировщиками. Архитектор должен беспощадно душить тех, кто их не соблюдает.
Где-то так...
Re[5]: Архитектура программного обеспечения с человеческим л
Здравствуйте, Виталий Цыбульник, Вы писали:
ВЦ>Здравствуйте, craft-brother, Вы писали:
CB>>“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”.
CB>>“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”.
ВЦ>А вот скажите, коллега, а выбор языка программирования является ли частью архитектуры? или дизайна? ВЦ>Я к тому что уж больно размытое это понятние key technical decisions that constrain the overall design — каждый архитектор интерпретирует его в зависимости от условий и требований проекта. ВЦ>Об этом и была статья...
Не то выделил. См что я выделил. Сразу субъективизм пропадает. Designer занимается тем что решает конкретные задачи, реализующие определенные требования. Software Architect задает подход к их решению, которые тоже своего рода ограничения.
Очевидно что язык больше относится к общим подходам, поэтому выбор языка — архитектурный вопрос.
Re[6]: Архитектура программного обеспечения с человеческим л
Здравствуйте, craft-brother, Вы писали:
ВЦ>>А вот скажите, коллега, а выбор языка программирования является ли частью архитектуры? или дизайна?
CB>Что делает системный архитектор — смотрим RUP:
CB>
1) Не увидел ответа на свой вопрос о языке программированя — хотелось бы однозначного "да" или "нет"
2) Дискуссия не о том, какая роль арихитектора или проектировщика в RUP, почему именно RUP? А давайте посмотрим для сравнения какая его роль в XP? А если мне больше нравится Scrum, что там мат часть говорит на эту тему? Давайте не будем сужать до того конкретного процесса, по которому привыкли работать именно Вы.
Re[6]: Архитектура программного обеспечения с человеческим л
EOH>>"The iterative approach to software development embodied in RUP urges practitioners to adopt two perspectives. First, it urges the team to understand the overall solution, and then in each iteration to re-evaluate and adjust the overall solution, based on the results of previous iterations. The two views corresponding to these perspectives are often called the breadth view and the depth view. In an iterative project, you focus first on the breadth view, and then pick a piece to focus on in depth. Separating breadth and depth, as we do in iterative development, makes a project much more resilient to change. Not only is the breadth view easier to create, but also, when change comes, you can smile, shrug, and adjust the breadth view with little effort." CB>Упс... А где здесь про архитектуру и проектирование???
Здесь про роли. Вы же из RUP названия ролей взяли?
EOH>>Напоминаю основной вопрос. Я считаю что макроархитектура и икроархитектура — это одно и то же, но разного уровня детализованности. Вы же с коллегой считаете, что макроархитектура ( в вашей терминологии — архитектура и микроархитектура (в вашей терминологии — дизайн) — это разные вещи, где на макро уровне стек технологий вида LAMP, а на микро уровне непосредствено код. RUP, насколько я вижу, все-таки ближе к моей позиции, хотя и использует термин "designer"
CB>Да о чем спорим-то! И тот и другой делают одинаковую работу: анализ проблемы и синтез решения, удовлетворяющего требованиям. Только делают ее на разном уровне.
Согласен. А что говорил Станислав:
Архитектура ПО — некоторые рамки в пределах которых будет строиться ПО. Например будет ли приложение веб или декстоп, будет ли оно размещено в "облаке" или нет. Будет ли использовать реляционную СУБД или какую-то другую. С какими другими программами придется взаимодействовать и как это делать. Используемые языки и технологии.Другое дело дизайн — это конкретный набор компонент и связей между ними для решения определенных задач. Выделенное как-бы намекает что должны быть задачи.
Архитектура не может быть эволюционной. В процессе эволюции декстоп не станет вебом, язык и платформа вряд ли сменится. Некоторые архитектурные решения могут поменяться, но зачастую это приводит к огромным затратам.
Дизайн при этом очень эволюционен, итерации дизайна выявляют новые требования, которые изменяют общий подход к решению.
Согласитесь, что он не считает что архитектура и дизайн — это одно и то же на разном уровне ^_^.
CB>Готов предложить свой вариант. Архитектор – это дизайнер системы на верхнем уровне. Проектировщик – дизайнер компонента системы. Программист – дизайнер программного пакета. Стажер – дизайнер класса HelloWorld.
Меня вполне устроит такая трактовка. Слово "дизайн" я правдо выкинул бы в поьзу макроархитектуры, архитектуры и микроархитектуры — но это уже дело вкуса.
CB>Не важно, как называть. Но важно, что в больших проектах — это должны быть разные люди. Иначе мы не справимся со сложностью. И каждый должен отвечать за свою часть общего результата. И архитектор не должен запускать свои ручки в компонент. Нет права на самостоятельное решение – не может быть ответственности за результат.
Естественно макроархитектура (если есть) — это отдельная должность. Там другие компетенции — как большие блоки между собой стыковать чтобы оно не развалилось и соответствало требованиям.
Re[7]: Архитектура программного обеспечения с человеческим л
Здравствуйте, Eye of Hell, Вы писали:
CB>>Да о чем спорим-то! И тот и другой делают одинаковую работу: анализ проблемы и синтез решения, удовлетворяющего требованиям. Только делают ее на разном уровне.
EOH>Согласен.
Вы очень легко переходите от обсуждения собственно архитектуры и дизайна к обсуждению ролей, и наоборот.
С ролями еще сложнее и больше неоднозначностей.
Re[7]: Архитектура программного обеспечения с человеческим л
Здравствуйте, Виталий Цыбульник, Вы писали:
ВЦ>1) Не увидел ответа на свой вопрос о языке программированя — хотелось бы однозначного "да" или "нет"
И "да" и "нет". Язык может быть задан на всю систему, например, Java + PL SQL. А может и нет. Например, для одной подсистемы будет эффективнее PHP, а для другой Эрланг. ИМХО, выбор языка, может быть частью проектирования модуля.
ВЦ>2) Дискуссия не о том, какая роль арихитектора или проектировщика в RUP, почему именно RUP? А давайте посмотрим для сравнения какая его роль в XP? А если мне больше нравится Scrum, что там мат часть говорит на эту тему? Давайте не будем сужать до того конкретного процесса, по которому привыкли работать именно Вы.
Не стоит сравнивать PUP со Srum или XP. RUP это фреймворк для построения процессов. Из компонентов RUP может быть построен любой процесс от Agile до CMM L5. А Scrum и XP это всего лишь конкретные процессы.
Однако это не имеет отношение к нашей дискуссии. Поскольку архитектора системы требуется при любом процессе разработки. Или я не прав?
Re[8]: Архитектура программного обеспечения с человеческим л
CB>>>Да о чем спорим-то! И тот и другой делают одинаковую работу: анализ проблемы и синтез решения, удовлетворяющего требованиям. Только делают ее на разном уровне. EOH>>Согласен. G>Вы очень легко переходите от обсуждения собственно архитектуры и дизайна к обсуждению ролей, и наоборот. G>С ролями еще сложнее и больше неоднозначностей.
.
.
тех, кто их не соблюдает.