Aikin, вот ты ставишь минус — тему-то раскрывай, а? А то хрен его поймешь, с чем именно из всего упомянутого ты не согласен. Я вот прям теряюсь в догадках. В конце концов, так не интересно. Минус — и все. У нас "обмен мнениями" — или нет?

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

G>Слова человека, укушенного DDD.
G>Уже есть укушенные Agile, укушенные ООП и укушенные Столлманом, теперь новый вид появился.
G>(не в обиду сказано)

G>Все называть моделью конечно можно, но не нужно, и даже вредно так как ведет к неверному толкованию.

Во многом он прав. Однако, реальная работа, прибегая к аналогиям из единоборств — это mixfight, а не бокс, дзю-до, каратэ, и прочие "школы". Надо одинаково хорошо владеть приемами в партере, на короткой дистанции, и на длинной. И формировать свой стиль, без перекосов. В нашем деле жизнь все покажет.

Gaperton пишет:

> примере как вы будете проводить это следствие. Было? Было. Вы вроде как
> согласны с тезисом, и со мной спорите? Вроде как да.

я не за и не против, я высказал свою точку зрения

> будете*, или будете мне тут какую-то ерунду про СБОР говорить? Вопрос
> крайне простой, мне в самому в нем понятно все, и тратить время на
> рассусоливание вокруг да около я не хочу.

ну тогда предлагаю сворачиваться

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

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

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

G>

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

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

1. То, что процитировано, не определение, а тезис. Разницу знаете, или подсказать?
2. Что делать — предлагаю перечитать с начала и очень внимательно. Я даже сослался на некий классифицирующий труд. То есть, я определил, к какому софту относятся мои утверждения, а к какому — нет. Ваши примеры — за пределами.

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

G>>

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

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

А>1. То, что процитировано, не определение, а тезис. Разницу знаете, или подсказать?
А>2. Что делать — предлагаю перечитать с начала и очень внимательно. Я даже сослался на некий классифицирующий труд. То есть, я определил, к какому софту относятся мои утверждения, а к какому — нет. Ваши примеры — за пределами.

Причем, вот что хотелось бы уточнить. Утверждения-то справедливы для любого софта, но возникают нюансы.

Допустим, система идет на заказ, и конкурентное преимущество обеспечивается, например, лицензией. Конечно, лучше сделать первый раз без подчеркиваний и прочих вещей, а потом героически все переделывать. За дополнительные деньги. Это не делает формулу менее справедливой, просто цели, которых она позволяет добиваться, оказываются смещены. Это ж не массовый рынок, где надо за каждую итерацию приближаться к идеальной версии как можно сильнее, при этом ничего, по возможности, не переписывая.

Или сервер базы данных. От того, что сначала им позанимается UI-ст, хуже точно не будет. Просто, что сказать UI-сту про сервер баз данных, если у него почти отсутствует UI как таковой? Поэтому такие вещи нет смысла давать дизайнерам. Заранее ясно, каков будет результат. То есть, так не делают просто из оптимизации трудового процесса. Добавлю, что в базоданном комплексе обычно есть много UI-шных тулзов, и над ними работать лучше сначала дизайнерам.

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

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

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

Нельзя ли сформулировать, что вы доказываете и/или опровергаете? Или иллюстрируете?

Допустим, ваша UI-спецификация полна. Сильно сомневаюсь, что это так — у вас даже не указано, допустим wrapping или нет. Каковы паузы. Надо ли начинать печать по первым результатам, а затем продолжать, или сначала все собрать, затем печатать целиком. У меня бы вы бегали и писали, пока все не прояснилось досконально. Еще смешнее будет в интеракциях — сходите к врачам, покажите им свое "описание". Узнаете сразу, что ваша спецификация не годится, как оно и бывает в таких случаях.

Ну ладно, допустим. Тем более, что все равно больше странички А4 не выжмешь, скорее всего, а дополнительная спецификация столь же мало влияет на архитектуру, как и то, что уже написано. Тогда это пример UI-спецификации, не влияющей на архитектуру, только и всего. Значит, у архитектора полностью развязаны руки. И что? Я еще раз спрошу — что это доказывает или опровергает? Что нет спецификаций UI, которые оставляли бы архитектору две дырки в заборе на выбор и один патрон в пистолете? Сами понимаете, это не так. Еще раз, одной строкой: лучше сделать спецификацию UI и убедиться, что UI не влияет на архитектуру, чем не сделать и убедиться, что влияет. Если жаба давит нанимать дизайнера UI для проекта, делайте разовый заказ. Или сами сыграйте его роль как PM. Только не отдавайте заказ какому-нибудь "самому известному российскому дизайнеру". Для такой работы надо уметь писать и думать, а не выеживанием заниматься. Это чистый кошмар. Найти исполнителя, который хотя бы склассифицировал разделы своей спецификации правильно — непосильная задача.

Предложение "спроектируйте архитектуру системы" — лукаво. ВСЕ, что выше архитектора, должно им учитываться, так что гоните требования, предшествовашие дизайну. Описание аппаратной части, например. (Если для вашего проекта оно было требованием).

Считаю своим долгом заявить, что я не поддерживаю шахер-махер с "внешними" и "не-внешними" интерфейсами. Оккам не позволяет. Я говорил и говорю только про один Iнтерфейс — U[зерский].

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

G>>

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

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

А>1. То, что процитировано, не определение, а тезис. Разницу знаете, или подсказать?

Подскажи, подскажи, не стесняйся.

А>2. Что делать — предлагаю перечитать с начала и очень внимательно.

Извини, я его уже в топку выбросил. Это ведь не определение, а какой-то там "тезис".

А> Я даже сослался на некий классифицирующий труд. То есть, я определил, к какому софту относятся мои утверждения, а к какому — нет. Ваши примеры — за пределами.

Вот, весь твой пост. Первый. Перечитай внимательно (было б что перечитывать внимательно). Выдели мне в нем пожалуйста жирным ссылку на классифицирующий труд, и объясни, где именно ты определил, к какому софту относятся твои утверждения.

В случае продуктов, рассчитанных на массовый рынок, я бы сказал так. Функция от требований — UI. Функция от всех аспектов UI — архитектура. А то бывает так, что продукт выполняет все требования и грамотно сархитектурен (легко понять, легко развивать, не тормозит и пр.), но UI гавняный, а когда на следующей итерации улучшение UI превращается в требование, начинаются песни "невозможно архитектурно". Если же разработку UI вынести в отдельный процесс, более приоритетный, чем архитектура, улучшение происходит более плавно.

Хотя, впрочем, мне уже и так с твоими "тезисами" все понятно, можешь не утруждать себя.

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

G>>>

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

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

А>>1. То, что процитировано, не определение, а тезис. Разницу знаете, или подсказать?
А>>2. Что делать — предлагаю перечитать с начала и очень внимательно. Я даже сослался на некий классифицирующий труд. То есть, я определил, к какому софту относятся мои утверждения, а к какому — нет. Ваши примеры — за пределами.

А> Утверждения-то справедливы для любого софта...

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

А> Это не делает формулу менее справедливой...

Ерунду сложно сделать менее справедливой. Да, да, я считаю Вашу "формулу" чушью. Но доказывать это Вам у меня нет ни малейшего желания. Уверен, Вас это не сильно расстроит, и вы с легкостью найдете себе другого собеседника.

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

G>Ерунду сложно сделать менее справедливой. Да, да, я считаю Вашу "формулу" чушью. Но доказывать это Вам у меня нет ни малейшего желания. Уверен, Вас это не сильно расстроит, и вы с легкостью найдете себе другого собеседника.

Принято единогласно.

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

Не-не-не, теперь все, ждем другого собеседника.

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

Хоть тема и умерла, добавлю свои три копейки.

Если смотреть на ПО совсем ценично, то можно выделить две задачи, которые оно решает:
1) представление данных и поддержка операций над ними;
2) отображение данных пользователю и предоставление доступа к операциями над ними.

1) и 2) вносят разный вклад в общую сложность ПО.

Очевидно, что есть приложения, где одна из задач существенно менее сложная, чем другая.

Н-р,
Если 1) прост, а 2) сложен — правы Aikin и Аноним. Архитектор будет плясать от требований к UI.
Если 2) прост, а 1) сложен — прав Sinix. Основное внимание будет сосредоточенно на вещах далёких от UI.

---

И ещё немного "потока сознания":

"1)" — это, фактически, отображение модели предметной области. Эта модель обычно редко меняется, а если меняется, то так, что удаётся сохранить 90% существующего кода без изменений (об этом заботится архитектор при поддрежке аналитиков на этапе проработки предметной области). Тут рулит ООП и использование тяжёлых методологий разработки, т.к. код пишется "раз и навсегда".

"2)" — это реализация модели, возникающей из требований к пользовательскому интерфейсу (назавём её "модель UI").
Проблема заключается в том, что "небольшие" изменения в требованиях к UI могут приводить к существенному пересмотру отделных частей "модели UI" и выбросу "красивого" кода. Поэтому тяжёлая артиллерия оказывается бесполезной, если UI состоит не из "типовых" форм. Точнее говоря, не бесполезной, а требующей большего вложения времени и/или средств, чем вариант, когда реализуется самое простое решение из возможных.
Особенно хорошо это видно, когда идёт фаза поддежки/развития — очень непросто (да и не нужно) аргументировать необходимость потратить месяц на разработку "мега фреймворка", чтобы потом "за полдня долететь", если "не красивое" решение возможно и требует 2-х дней.

А>Не-не-не, теперь все, ждем другого собеседника.
Да ради бога. Всем привет.
Лично я вижу здесь просто логическую ошибку:

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

Эти утверждения абсолютно верны, но ничто не указывает на то, что UI — единственный аргумент архитектуры. Необходимое не есть достаточное.

NGG>Если смотреть на ПО совсем цинично, то можно выделить две задачи, которые оно решает:
NGG>1) представление данных и поддержка операций над ними;
NGG>2) отображение данных пользователю и предоставление доступа к операциями над ними.

Это не задачи. Это всего лишь взгляд на реализацию. Не более.

Дня NotGonnaGetUs!

Это не тема умерла — товарищи ушли. На посты по теме я отвечаю как увижу, если конечно на них раньше никто не ответил.

Мне не нравится односторонний подход — либо представление данных (расскажите, как вы его понимаете — а то будем спорить впустую), либо UI. Во-первых жисть куда сложнее, во-вторых /*дело ленина*/ любая система живёт и развивается, приоритеты регулярно тасуются. И получается, что сейчас труёвее "подход Sinix'a" или "подход Aikin'а/Анонима", поэтому сегодня танцуем от UI, а завтра от предметной области...

Коротко: Архитектура штука неповоротливая, но без неё тяжко. Поскольку она (равно как и реляционные СУБД) очень мешает жить правоверным агилистам — чтобы не портить им нервы, продолжать эту тему не будем.

Точно так же не согласен с утверждением, что ООП рулит для отображения модели предметной области. Сорри за тыканье носом в историю, но подобные идеи жили задолго до ООП — поищите тексты времён первых сетевых СУБД или первые рекламки XML. Главня особенность — фиксированные пути доступа — это одновременно и хорошее преимущество (для описания логики, если она укладывается в одну область) и конкретнейший недостаток, когда нам нужно несколько представлений одних и тех же данных. DTO не от хорошей жизни появились.

Коротко: ООП эффективен для реализации поведения, а не для работы с представлением однородных данных. Я могу долго на эту тему распинаться, есть желание — продолжим.

Далее. Второй подход — типичная иллюстрация глобального "Code&fix". Кстати, вы привели замечательнейший пример рассуждений — не считая изначальной предпосылки, каждый шаг абсолютно логичен. В результате получается вывод, что на архитектуру проще забить, чем сделать её тру — она постоянно переделывается. Это дело неизбежно заканчивается горой костылей, поскольку каждый костыль куда быстрее и дешевле мегафреймворка. А в сумме?

Тут мне конечно возразят, что микроитерации с рефакторингом спасут /*суверенную демократию*/ тру-команду. Расскажите мне, в чём смысл регулярнейше редизайнить горы кода без конечной цели, только ради того что чтобы сделать _текущий_ код как можно проще (мы всё ещё говорим о KISS?). После кучи итераций вы всё равно придёте примерно к аналогичному по функционалу решению. Только нельзя будет сказать, почему оно у вас вышло так как вышло — обоснованных решений не было, только реализация требований. У Бека подобное звалось мобильностью(мантра "путешествуй налегке") и способностью следовать за пастырем, если не ошибаюсь.

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

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

Коротко: заменяем мантру "вы не следуете всем методикам XP" на "вы не разделяете логику и представление" — новая религия готова

Удачи вам.

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

А>>Не-не-не, теперь все, ждем другого собеседника.
VGn> Да ради бога. Всем привет.
VGn> Лично я вижу здесь просто логическую ошибку:
VGn>

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

VGn>Эти утверждения абсолютно верны, но ничто не указывает на то, что UI — единственный аргумент архитектуры. Необходимое не есть достаточное.

Разве я с этим спорю? Более того, в ответ на предложение по "голому" UI спроектировать архитектуру, я написал

Автор:
Дата: 05.03.09

:

Предложение "спроектируйте архитектуру системы" — лукаво. ВСЕ, что выше архитектора, должно им учитываться, так что гоните требования, предшествовашие дизайну. Описание аппаратной части, например. (Если для вашего проекта оно было требованием).

В чем же вы видите логическую ошибку? И с чего решили, что я поддерживаю тезис "UI — единственный аргумент архитектуры"?

А>В чем же вы видите логическую ошибку? И с чего решили, что я поддерживаю тезис "UI — единственный аргумент архитектуры"?

Хорошо. Тезис был: UI — основной приоритет после требований. Но почему бы не принять, что приоритет — это тоже функция требований? Это особенно видно в тех вырожденных для UI случаях, примеры которых привёл Gaperton.

Для меня UI — всего лишь один из внешних аспектов системы, которые собственно и определяют пользовательский (клиентский) функционал.

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

ИМХО всё просто: три уровня проектирования — три уровня ответственности.
Вы видели проекты, где собственно проектирование осуществлялось разными людьми на трёх уровнях? Я даже не могу представить себе всей сложности взаимодействия таких специалистов.

S>Таак. То есть я правильно понял фишку и методологии разработки — скорее для управления проектом/получения результатов, чем для создания "идеального продукта"(тм)? Ёк...

Да. Апологеты RUP утверждают: мы не делаем программу, мы решаем проблему заказчика.
Правда это не мешает RUP вести активености по архитектуре и ставить ей довольно высокий приоритет, банально основываясь на вопросах рисков и трудоёмкости.

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

Тогда вам точно не в XP и DDD

А>>В чем же вы видите логическую ошибку? И с чего решили, что я поддерживаю тезис "UI — единственный аргумент архитектуры"?

VGn>Хорошо. Тезис был: UI — основной приоритет после требований. Но почему бы не принять, что приоритет — это тоже функция требований? Это особенно видно в тех вырожденных для UI случаях, примеры которых привёл Gaperton.

Уважаемый VGn,

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

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

Таким образом, мой тезис — "дизайн UI должен иметь приоритет перед архитектурным проектированием". Это не придирки. Половина глупых споров могла бы никогда не возникнуть, если бы люди точно писали и точно читали.

Примем, что приоритет это порядок следования (как нормальные компьютерщики). Может ли быть приоритет функцией требований? Я считаю, нет. В примерах, которые тут приводили, процесс дизайна шел с нулевым результатом. Дизайнеру нечего писать в своей документации. Поэтому, хоть он и шел с бОльшим приоритетом, но никак не влиял на последующий процесс. Соответственно, его можно было просто выкинуть из рассмотрения. О чем я и написал: в частных случаях, когда он становится ненужным, его можно сократить, но все равно, в общем случае формула работает. Если предполагается, что результат дизайна может быть ненулевым, выкидывать процесс дизайна ни в коем случае нельзя. Теперь, ваш тезис. Пусть приоритет дизайна зависит от требований (функционально или не функционально — неважно). Из этого следует что результат дизайна предполагается ненулевым, иначе какой смысл давать дизайну приоритет? Так? А раз так, значит, дизайнерам есть что сказать о продукте. Значит, UI какой-никакой есть. Ну, а дальше все просто: вы о чем думаете, о пользователе или о технологиях? Вот и приоритеты такие же. Я всегда думаю о пользователе. Допустим, стоит задача сделать продукт для... недалеких чайников. Это один случай. Или для умных инженеров, которые хотят, чтобы было эффективно работать, пусть даже ценой того, что сложно разобраться. Это другой случай. Возможно, архитектура для этих двух случаев будет разная. Поэтому, design comes first. Очевидно, что сторонники противоположного подхода — техноцентристы, которые думают сначала о том, MS SQL или Oracle, а уже потом про тех, кто будет оплачивать процесс создания.

VGn>Для меня UI — всего лишь один из внешних аспектов системы, которые собственно и определяют пользовательский (клиентский) функционал.

Аспект — это взгляд [откуда-то]. Примерно, то же, что и точка зрения. UI не может быть точкой зрения и я опять полностью потерял нить рассуждений. Допустим, мы смотрим на систему, и на все закрываем глаза, кроме UI. Видим только его. Как это может что-то определять?

Я согласен с одним: что UI, не будучи аспектом, а будучи свойством системы, определяет пользовательский функционал. Да, это так. Не предусмотрели разработчики стандартного таск манагера в UI показ родительских отношений — и хрен я получу такой функционал.

Но разве не очевидно, что любой другой функционал, кроме пользовательского, нужен постольку, поскольку нужен пользовательский функционал? Нахрена была бы нужна база, если бы не форум, который на ней сидит? Раз так, то и пользовательский функционал имеет приоритет перед любым другим функционалом. Что жизнь неоднократно и доказала. UNIX, говорят, архитектурно превосходил винду, как бог черепаху. Но унихисты всегда давали приоритет архитектуре, а БГ говорил — если что-то как следует не работает, пусть оно хотя бы хорошо выглядит. Чем закончилось, знаете?