Спасибо за полноценный вклад

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

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

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

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

Тоже занимаюсь изучением XP/RUP/MSF/DDD, но вопрос другой.

Что из этого может пригодиться в небольшом веб-проекте —
около 20 веб-страниц? Ключевое слово — небольшой.

И какие книги читать?

Кент Бек — это само собой, еще вроде бы Ларман, но
остальное как-то больше пригодится для крупных проектов.

Или я пропустил что-то важное?

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

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

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

S>Попробуйте Скота Амблерса — тож евангелист Agile. Даже помодней как бы. Впрочем тут лучше местных гуру поспрошать.

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

Согласен, методологии тут не нужны, даже ООП кажется лишним.

Но все же "утянуть интересные методики" хотелось бы.

Наверно, где-то есть статьи или книги о том, как использовать
полезные элементы методологии и не ислользовать "не-полезные"?

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

А>Я отдаю должное приоритету Gaperton'а в деле определения давно известных понятий. Но если вы посмотрите в мое первое сообщение, вы увидите, что я употребил там слово "UI". Это сознательно: дизайн — очень общее понятие, и точный смысл зависит от контекста. Употребив вначале UI, я задал контекст, и слово "дизайн" везде по тексту относится к дизайну UI, если явно не написано иное. А смысл того, что написал про дизайн Gaperton, зависит от контекста, заданного им. По-моему, это элементарно.

Ой, ну зачем скромничать. По моему, вы тоже отметились в деле "определения всем известных понятий".

Функция от требований — UI. Функция от всех аспектов UI — архитектура.

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

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

S>Так нет, вы упрямо твердите, что UI определяет архитектуру а само определяется требованиями потому что требования приоритетнее UI, UI приоритетнее архитектуры, а архитектура приоритетнее кода. Когда вам пытаются показать, что это _вы_ так расставляете приоритеты и возможны другие решения (заметьте, в начале я старался отвечать макисмально терпимо), вы начинаете проявлять недюжинные способности к лингвистическому анализу

"UI" — это часть требований . Из полезных вещей, она задает сценарии взаимодействия пользователя с системой + некоторый domain model — набор понятий, которыми пользователь оперирует при общении с программой. Архитектура, как набор ограничений для реализации класса требований, должна допускать реализацию этих сценариев и domain model. Плюс, сам ГУЙ может быть построен в соответствии с некоторой философией и ограничениями, которые будут архитектурными — примером является интерфейс MDI приложений MFC. Только и всего. Является она прямым следствием сиюминутных требований? Нет. Это ж очевидно. Товарищ просто не понимает разницы между двумя "всеми известными понятиями" — архитектурой и дизайном. И не поймет, ему не хочется. Зато поспорить ему сильно хочется и тебя жизни поучить. Таких на РСДН много — зачем давать им то, что они хотят? Только время тратить.

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

G>Что мы будем делать с этим определением "всем известного понятия" в случае, когда у приложения либо нет UI в традиционном понимании, или он, этот UI, играет совершенно второстепенную роль, а вот зато архитектура — есть? Возьмем к примеру сервер IP-телефонии. Сервер колл-центра. Сервер базы данных. Веб-сервер.
Заменим UI на внешний интерфейс системы. И все опять становиться на свои места.

А если заняться словоблудием, то UI = User Interface, а юзер это не только человек, но и IP-телефон, коммутатор, приложение использующее БД, броузер.

СУВ, Aikin

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

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

G>>Что мы будем делать с этим определением "всем известного понятия" в случае, когда у приложения либо нет UI в традиционном понимании, или он, этот UI, играет совершенно второстепенную роль, а вот зато архитектура — есть? Возьмем к примеру сервер IP-телефонии. Сервер колл-центра. Сервер базы данных. Веб-сервер.
A>Заменим UI на внешний интерфейс системы. И все опять становиться на свои места.

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

A>А если заняться словоблудием, то UI = User Interface, а юзер это не только человек, но и IP-телефон, коммутатор, приложение использующее БД, броузер.

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

Gaperton пишет:

> Все, внешний интерфейс системы я описал — спроектируйте
> архитектуру системы пожалуйста. Она у нас прямое следствие внешнего
> интерфейса.

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

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

>> Все, внешний интерфейс системы я описал — спроектируйте
>> архитектуру системы пожалуйста. Она у нас прямое следствие внешнего
>> интерфейса.

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

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

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

РД>Ну а теперь если внимательно на это посмотреть, то увидим что это "те же
РД>яйца, вид сбоку"...

Если внимательно посмотреть сбоку, то кроме яиц можно заметить еще и член.

Первое — насчет интерфейсов. Я уж за вас точно определю, что это такое. "Интерфейс" определяется двумя вещами — форматом передаваемых данных, и протоколом взаимодействия по данному интерфейсу. Протокол подразумевает согласованные действия всех сторон взаимодействия, и может быть, к примеру, непротиворечиво и точно описан конечными автоматами. В случае взаимодействия peer-to-peer — нужна пара автоматов. Это касается абсолютно любого интерфейса.

Протоколы у нас могут каскадироваться, формируя стек. Именно это происходит, например, при взаимодействии человека и телевизора посредством пульта ДУ. Или сейчас у нас в форуме, я сообщаю свою мысль Вам, и она проходит через потрясающей глубины стек протоколов, превращаясь на пути к вашему мозгу, страшно сказать, в IP-датаграммы. И обратно.

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

Так вот, товарищ тут утверждал, что, в данных терминах, описания только одного протокола прикладного уровня (это и есть GUI по своей сути) достаточно для того, чтобы спроектировать архитектуру. Его на самом деле достаточно, чтобы спроектирвоать прототип ГУЯ, не более того. На самом деле надо еще:
1) Описание окружения, необходимого для работы системы.
2) Способы использования вашей программы через этот ГУЙ. Какую потребность они решает и каким способом, какая от нее польза? Предназначение у нее какое?
3) Функциональность вашей программы — делать-то она что будет в конце концов, кроме того, что окошки отрисовывать или взаимодействовать с кем-то? Ввсе не обязательно все, что она должна делать полезного, показывается вам в реакциях в гуе. Наблюдаемый результат оператора INSERT в базу данных SQL — что-то вроде "ок, получилось". Такой же, как у многих других. Она ничего вам не показала — она в ответ на воздействие изменила внутреннее состояние. Потом, может быть, вам это аукнется. И не всегда вы можете это изменение состояния привязать к внешнему воздействию — к примеру, в той же БД есть триггера, реагирующие на внутренние события.
4) Нефункциональные требования
Влияют на архитектуру сильнее всего. Ваша система должна работать на микроконтроллере — вы будете строить ее на .NET? Ваша система требует реакции в жестком реальном времени — вы будете хранить ее состояние в MS SQL? От вас требуется 5 девяток надежности и накатывание апгрейда без остановки сервиса — ну неужто это не повлияет на архитектуру?

Кроме того. Требования могут каскадироваться — "реализация" требований верхнего уровня может являеться набором требований для компонент нижних уровней. Что до архитектуры — это набор ограничений, которые заложены в основу вашей системы, так, что у вас есть гибкость и вы можете реализовать класс требований, а не конкретный список. Обыкновенно — это выражается в требовании использовать некоторые прикладные сервисы, возможно — вашей собственной разработки (плюс правила их использования и структурирования системы), комбинируя которые вы и удовлетворяете уже конкретные требования. Эти сервисы обычно не завязаны на интерфейсы, более того, могут давать обстракцию от них. Скажем, сервис TCP/IP, доступный вам через API сокетов, совершенно не зависит от физического интерфейса, хоть голубиной почтой может датаграммы слать. Нефункциональные требования же относятся обычно именно к классу задач, потому так сильно на архитектуру и влияют.

"UI" говорите, да? Честно, меня поражает богатое воображение людей, которые могут столько всего нафантазировать за "интерфейсами".

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

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

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

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

Ну да, а там либо ишак сдохнет, либо халиф.

Меж тем, user stories сама по себе штука толковая. И думать о тестах вперед — тоже толковая. И парная работа — толковая. И ранняя обратная связь скастомером — толковая. А вот не делать дизайна, постоянно рефакторить, дергать кастомера чрезмерно часто, и вообще — парадоксальная стратегия "поменьше думать, и побольше прыгать" — настолько бестолковая, что сводит на дерьмо все здравое, что есть в XP.

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

G>Меж тем, user stories сама по себе штука толковая. И думать о тестах вперед — тоже толковая. И парная работа — толковая. И ранняя обратная связь скастомером — толковая. А вот не делать дизайна, постоянно рефакторить, дергать кастомера чрезмерно часто, и вообще — парадоксальная стратегия "поменьше думать, и побольше прыгать" — настолько бестолковая, что сводит на дерьмо все здравое, что есть в XP.

Вообще, ИМХО, основная проблема агилистов не в том, что у них неверные посылки, а то, что они делают из них парадоксальные выводы, идущие вразрез со здравым смыслом. Делается это с целью дистанцироваться от "классики", "мэйнстрима", и создать впечатление, что они предлагают что-то совсем особенное, не то что другие. Типичный подход реакционных религиозных сект.

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

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

G>Делаем медицинский диагностический прибор. Внешний интерфейс — электрические присоски, цепляющиеся на человека, плюс принтер, печатающий диагноз. Диагноз — plain text. Прибор запускается одной кнопкой. Все, внешний интерфейс системы я описал — спроектируйте архитектуру системы пожалуйста. Она у нас прямое следствие внешнего интерфейса.
Пожалуйста (см. ниже). Даже на этих данных можно пстроить каркас архитектуры, который будет далее наполнятся исходя из остальных требований. Причем я не вижу требований не относящихся напрямую к интерфейсу, которые могут повлиять на полученную схему (возможно из-за недостатка знаний/опыта).
ИМХО, это следствие того, что удовлетворение внешнего контракта и есть та причина по которой приложение создается.

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

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

G>Конечно. Вы мне прям глаза на мир открыли — я раньше был слеп. Оказывается, юзер АТС — это телефон, юзер телевизора — это инфракрасный пульт, юзер DVD-диска — это DVD проигрыватель, а юзеры компьютера — это мышка и клавиатура. А юзер раутера — страшно сказать — Сам Интернет, да не будет его имя помянуто всуе. Всего этого безусловно достаточно, чтобы спроектировать архитектуру всех перечисленных устройств и их встроенного ПО. Интересно только, кто юзер микросхемы, стоящей в DVD-проигрывателе. Есть у нее архитектура, или нет?! Значит и юзер должон быть!! То-ли встроенное ПО, то-ли разработчики DVD-плеера, то-ли злополучный пульт дистанционного управления, то-ли печатная плата, то-ли микросхема памяти с блоком питания, теперь уж не поймешь. Я, как Ваш ярый последователь, больше склоняюсь к печатной плате.
Ерунда какая-то написана. Если бы не пример выше, то я бы подумал, что у вас украли аккаунт

---

Вот что у меня получилось:


1) Даже имея минимум данных, система неплохо разделилась на три независимые части
2) Как вяжется принцип "простоты дизайна" с интерфейсами (IReader/IWriter)? Они обходимы для тестирования
3) Что собой представляет InputData и ProcessingResult для этой диаграммы не важно.
4) Неплохо бы узнать юзкейс работы с устройством, так как это очень сильно повлияет на интерфейс представленный IReader (но не на его вид)

После проектирования мы получили два внутренних интерфейса на основе которых которых и оставшихся требований требований к системе можно продолжать проектирование:
Примем за требования:
1) Вариант работы с устройством: подключили датчики, нажали кнопку, система попыхтела и выплюнула диагноз // в варианте, когда человек сутками подключен к системе и она его мониторит в realtime спользование интерфейсов будет совсем другим
2) Системе нужен полный объем исходных данных для анализа, а не по частям
3) Распечатать отчет можно "одним махом" в конце работы системы

Получим:
1) InputData -- последовательность съемов данных с датчиков (один съем, скорее всего будет массивом чисел: напряжений/сопротивлений/сил тока на каждом из проводов).
2) Читается один раз при нажатии кнопки Process. // В отличии от realtime-системы когда данные читаются постоянно путем последовательного вызова метода Read
3) ProcessingResult -- данные полность готовые к преобразованию в текст и последующей отправки на принтер

и т.д. и т.п.


СУВ, Aikin

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

G>Так вот, товарищ тут утверждал, что, в данных терминах, описания только одного протокола прикладного уровня (это и есть GUI по своей сути) достаточно для того, чтобы спроектировать архитектуру.
Если "товарищ" это я, то такой чуши "он" не утверждал. Ознакомьтесь пожалуйста с моим первым постом по теме

Автор: Aikin
Дата: 11.02.09

и ниже по ветке.

СУВ, Aikin

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

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

G>>Делаем медицинский диагностический прибор. Внешний интерфейс — электрические присоски, цепляющиеся на человека, плюс принтер, печатающий диагноз. Диагноз — plain text. Прибор запускается одной кнопкой. Все, внешний интерфейс системы я описал — спроектируйте архитектуру системы пожалуйста. Она у нас прямое следствие внешнего интерфейса.
A>Пожалуйста (см. ниже). Даже на этих данных можно пстроить каркас архитектуры, который будет далее наполнятся исходя из остальных требований. Причем я не вижу требований не относящихся напрямую к интерфейсу, которые могут повлиять на полученную схему (возможно из-за недостатка знаний/опыта).
A>ИМХО, это следствие того, что удовлетворение внешнего контракта и есть та причина по которой приложение создается.

Еще раз прочтиайте определение архитектуры, которое дал Gaperton. Вы спорите о разных вещах.

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

G>Еще раз прочтиайте определение архитектуры, которое дал Gaperton. Вы спорите о разных вещах.
Обзови мою Архитектуру словом Дизайн.

Неужели все что Гапертон написал тут

Автор: Gaperton
Дата: 26.02.09

является только Архитектурой (в смысле

Автор: Gaperton
Дата: 23.02.09

)?

СУВ, Aikin

Gaperton пишет:

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

если мы говорим о СБОРЕ информации — про диагностику говорить пока еще
рано.

> Если внимательно посмотреть сбоку, то кроме яиц можно заметить еще и член.

яйца фаберже знаю, про член фаберже не слышал

> Первое — насчет интерфейсов. Я уж за вас точно определю, что это такое.

не надо за меня ничего определять. Можете за Aikin поопределять, если он
разрешает

> "Интерфейс" определяется двумя вещами — форматом передаваемых данных, и

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

а это уже классическая декомпозиция. На уровне взаимодействия
"человек-телевизор" нам на каскадирование глубоко плевать.

> Так вот, товарищ тут утверждал, что, в данных терминах, описания только

"товарищ" вроде за себя ответил выше

> "UI" говорите, да? Честно, меня поражает богатое воображение людей,
> которые могут столько всего нафантазировать за "интерфейсами".

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

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

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

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

Автор: Aikin
Дата: 11.02.09

и ниже по ветке.

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

Пример: интерфейс — примерно такой: www.google.com. Еще один "внешний интерфейс" — он сканирует веб через HTTP. Я никаких требований не пропустил, которые относятся к внешним интерфейсам?

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

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

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

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

РД>если мы говорим о СБОРЕ информации — про диагностику говорить пока еще
РД>рано.

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

>> Первое — насчет интерфейсов. Я уж за вас точно определю, что это такое.

РД>не надо за меня ничего определять. Можете за Aikin поопределять, если он
РД>разрешает

Да на здоровье, определяйте сами, я вам разве запрещаю?

>> "Интерфейс" определяется двумя вещами — форматом передаваемых данных, и

РД>религия проектирования "от интерфейса" подразумевает несколько широкое
РД>определение. Кроме формата и протокола — также и сопутствующее
РД>поведение. В примере выше — в описании вывода распечатки архитектор "от
РД>интерфейса" как раз и напишет, как она генерится, включая Ваш
РД>запатентованный алгоритм диагностики. Иначе таки да, дырочка получится

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

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

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

РД>а это уже классическая декомпозиция. На уровне взаимодействия
РД>"человек-телевизор" нам на каскадирование глубоко плевать.

Это тебе плевать, а разработчику телевизора — нет. На уровне архитектуры мне как раз интересны эти слои и каскадирование, а на то, какие там будут на пульте кнопки и когда их кто нажимать будет — мне глубоко плевать. Потому, архитектуры софта телевизора, не принимая во внимание каскадирование, сделать нельзя. Цепочка там:
Человек -> инфракрасный пульт -> инфракрасный датчик -> порт UART -> драйвер порта UART -> Подсистема LIRC (если на телевизоре Linux) -> прикладные сервисы -> система меню.

Из перечисленного, разработчик телевизора делает пульт, программирует его микроконтроллер, проектирует плату со всеми вытекающими, должен озаботится LIRC-ом, если SDK производителя проца его не включает, и придумать, как он обойдется с этими нажатиями на кнопки дальше, до того, как оно попадет в софт. Скажем, он может на уровне софта изобразить из пульта обычную клавиатуру.

>> "UI" говорите, да? Честно, меня поражает богатое воображение людей,
>> которые могут столько всего нафантазировать за "интерфейсами".

РД>Gaperton, я Вас уважаю и порой с интересом читаю Ваши посты, но Ваш
РД>категоризм тут имхо лишний. "Люби свою религию и при этом уважай и
РД>другие"

Я Вам говорил, Роман, я не интересуюсь религией. Software Engineering не имеет с религией ничего общего, в нем практически все можно точно определить и измерить, это экспериментальная дисциплина. И поэтому, увы, может получиться, что кто-то неправ, или сказал чушь. И если, Роман, мне покажется что Вы говорите чушь, то на этом форуме я Вам не просто об этом сообщу, но и постараюсь Вам объяснить почему. Я уже постарался, и в этом и проявляется мое уважение к Вам, Роман, а вовсе не в том, что я с Вами из уважения не должен спорить. Все мои утверждения фальсифицируемы, то есть допускают логическое опровержение. Несогласны — пробуйте. Я буду только за.

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

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

G>>Еще раз прочтиайте определение архитектуры, которое дал Gaperton. Вы спорите о разных вещах.
A>Обзови мою Архитектуру словом Дизайн.

Давай для полноты картины твое "да" обзовем "нет".

A>Неужели все что Гапертон написал тут

Автор: Gaperton
Дата: 26.02.09

является только Архитектурой (в смысле

Автор: Gaperton
Дата: 23.02.09

)?

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