Re[4]: Просветите про роль требований в проектировании, плиз - Управление проектами

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

S>Здравствуйте, Аноним!

А>>Это все быстро превращается в помойку, которую ни понять, ни изменить. Только выкинуть.

S>Гммм... я не понимаю как "изоляция проблемы" может превратить архитектуру в помойку. Мне казалось, что оно наоборот должно предотвращать помойку...

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

А>>В своем первоначальном посте я специально оговорил, что, цитирую, "В случае продуктов, рассчитанных на массовый рынок, я бы сказал так". Поэтому, вы правильно делаете, что не говорите о сервере. Тут можно вспомнить "Пять миров" Джоэля (хоть и не люблю я его).

S>А для массовых продуктов логика зависит только от гуя? и нет ни работы с сетью, ни многопоточности (а потоковая модель тех же winforms имеет свои ограничения...), ни файликов? Как эти задачи определяются гуем? Да, Джолэла я тоже не люблю (если это который Joel on Software и FogsBugz).

Так. Штрафной вам. Я специально обратил внимание, что не ГУЯ, а УЯ. А вы опять пишете — ГУЙ! Это уже не взаимное недопонимание, а результат вашего невнимательного прочтения. И теперь мне остается только второй раз написать то же самое.

Файлики — это часть дизайна интерфейса, в смысле, как им называться, куда сохраняться и т.д. Возьмем такой продукт как Outlook и его самый знаменитый файл — pst-шник. Это интерфейс, поскольку пользователь взаимодействует с этим файлом. Куча юз-кейсов завязана на его копирование и пр. Дизайн подразумевает, что весь контент хранится в нем, а архитектуре остается только плясать в этих рамках. Архитектор может сделать некую БД, которая бинарно сохраняется в этот файл, как база mySQL представляет собой несколько файликов с невразумительными названиями на диске, а может сделать плоский файл. В первом случае ему придется заводить модуль (dll-ку или exe-шник), который обрабатывает запросы и возвращает датасеты, во-втором — скорее всего, достаточно простого класса-сериализатора массива. Вот это — архитектура поверх UI.

Далее. Работа с сетью — а подразумевается, что продукт работатет с сетью? Как? В спецификации дизайна описано — пользователь нажимает сюда, идет соединение с таким-то сервером по выбранному им протоколу? Если да — все прекрасно зависит. Если нет — ЗАЧЕМ такому продукту соединение с сетью? Ах, чтобы настучать о нелицензионности? Тогда это требование, и оно как-то обрабатывается дизайном (скорее всего, там будет стоять "соединение оставляется на усмотрение архитекторам", т.е. результат обработки — нулевой). Или чтобы запустить расчет на удаленном сервере, чисто для правильной архитектуры, хотя ни дизайн, ни требования такого не предусматривали? Что ж, последний случай — когда логика действительно НЕ зависит от UI, и от требований. Я же говорю: работа архитектора — тоже творческая. Кто сказал, что нельзя творить в рамках. Даже у картины есть рамка, что ж говорить про рамки, которые налагает дизайн на архитектуру?

Следующий случай — потоки. По-моему, потоки как ничто другое являются прямым следствием дизайна. Написано: при нажатии "Синхронизировать" пользователю открывается окно (см. схему 137) с прогрессом синхронизации, а он в то же время может продолжать работу в основном окне 1. И я посмотрю, как вы это сделаете без потоков. Ну а если потоки нужны вам для оптимизации вычислений внутри, чтобы скорость увеличить, хотя и одним потоком можно обойтись — опять же, внутри рамок дизайна творите что хотите. Можете сделать 28 потоков, если это с вашей точки зрения улучшит продукт. Но не забывайте, что вашу архитектуру потом программистам реализовывать.

А>>Софт, о котором идет речь, взаимодействует больше всего с юзером... Непродуктивно рассматривать SQL-сервер с точки зрения на пользовательский интерфейс консоли. А вот какой-нибудь Ворд — продуктивно.

S>Непродуктивно. С точки зрения пользователя спеллчекер — это красные полосочки под словами. Опишите мне архитектуру спеллчекера на основе вышеприведённого. Я молчу про подпись документов, поддержку кастомныхх конвертеров/надстроек/макросов, печать и несколько видов отображения документа, которые предоставляют волзможность делать одно и то же различными способами.

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

Спелчекер — это не просто красные полосочки. Это, во-первых, полосочки зигзагом. Вы знаете, когда-то давно я участвовал в проекте одного софта, где пользователь вводил тексты по формулам. Нарушения синтаксиса надо было "показывать как спелчекером" (требование). Так вот, от себя я (в роли дизайнера) дописал про зигзаг, обосновав это тем, что так сделано в Ворде и пользователь должен четко понимать, что это не элемент форматирования, а признак ошибки, а для этого надо скопировать один в один. И знаете что? До тех пор в качестве редактора предполагалось использование IE в режиме редактирования, а после — уже нет. ПОТОМУ, ЧТО В HTML ТОГДА НЕ БЫЛО ПОДЧЕРКИВАНИЯ ЗИГЗАГОМ! (Не знаю, как сейчас). Вот бы было весело, если бы архитектор действовал в первый черед, началоось бы всем известное: "архитектура не поддерживает, идите в опу".

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

Далее, это полосочки, которые появляются не отвлекая пользователя от печатания текста.

Наконец, это полосочки, которые появляются под словами, не найденными в словаре.

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

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

S>Вы продаёте продукты или вы их пишете? Если второе — к чему вышенаписанное? Архитектура нужна вам, потому что она стабилизирует продукт, заставляет думать перед тем как делать и явно показывает вам, где у вас проблемы, не укладывающиеся в текущую концепцию развития продукта. Вы же не хотите закрывать глаза на существующие проблемы? Я могу ещё и маркетинговую составляющую расписать — про конкурентоспособность и прочее.

И то, и другое. Видимо поэтому я и вижу процесс полнее.

S>Кстати, с вашей точки зрения 2003 и 2007-й офисы — совершенно разные продукты. И у MS даже теоретичестки не должнобыло получиться внести кардинальные изменения в гуй не переписав весь офис с нуля.

Ну, я ж говорю: дизайн для вас — это гламурные тона. Если не считать цветовой схемы и убранной кастомизации, в MSO 2007 дизайн поменялся не очень много. Это во-первых. А во-вторых, у вас здесь логическая ошибка. Пусть дизайны различаются на все 100%. Придется ли при этом переписывать все с нуля? Ответ: необязательно. Зависит от дизайнов до и после. Может быть, оба разных дизайна вполне могут работать на одной и той же архитектуре.

Ключевой момент в том, что ИНОГДА — НЕ МОГУТ. Поэтому и надо давать дизайну более высокий приоритет. Это и вылезает из моей формулы.

А>>Поэтому, это не вершина айсберга. Это, продолжая вашу метафору — полная поверхность айсберга, включая его подводную часть (куда по умолчанию сохранять файлы, можно ли подключаться к серверу, как осуществляется вставка других объектов других софтов — ну, вы поняли).

S>Ок. У вас требование "я хочу айсберг в форме перевёрнутой пирамиды". Расскажите мне как из этого требования вы узнаете хоть что-то про внутренности аёсберга. Или это проблемы архитекторов?

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

То вы недовольны, что архитектору мало приходится решать, то — что много.

А>>Что касается требований — требования, это типа "ПО должно выдавать аналитический отчет о". Круговая диаграмма — это уже дизайн. Это дальнейшее уточнение, но кроме того — творчество.

S>Неа

Отчёт — это метод реализации. Тру-требование читается так: "продукт должен проводить анализ..." + "результаты анализа доолжны быть представлены в виде ... (а вот здесь и описыцвается как)".

Я не учу своих клиентов тру-требованиям. Если они говорят мне, что "ПО должно выдавать аналитический отчет о", я это записываю. Я, впрочем, об этом тоже написал, и даже сказал, как это называется. Это называется path dependance. Когда все продукты на рынке выдают аналитические отчеты, пользователи автоматически начинают говорить в таких терминах.

S>Продолжим?
S>>>Ну ведь глупо рассматривать горы функционала, внутренние структуры данных, составные части, ту же многозвенку и много чего ещё со стороны потребностей пользователя, точнее со стороны взаимодействия с пользователем. Оно ему вообще ведь не надо. 1с хватит. Или ацесса. Или фокспро. Или вообще экселя.

А>>Глупо — что? То, что вы перечислили, вполне может быть результатом проектирования UI. А может и не быть. Нужно на примерах разбирать.

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

B>Определение дизайна я дать не могу. Но я бы предположил, что указанные три термина могли бы обозначать следующее:
B>Возмем систему, со всеми ее классами и пр. = Детальный дизайн

Код, это очевидно, не "детальный дизайн". Код — это код. Ошибка кодирования четко отличается от ошибки детального дизайна. Одно дело ошибиться в алгоритме, или выбрать неподходящую структуру данных, и совсем другое дело — ошибка кодирования. Определение детального дизайна я взял из PSP/TSP, где все эти определения берутся из классификатора ошибок. В UML для описания алгоритмов в принципе подойдет activity диаграмма, однако честнее и правильнее сказать что UML детальный дизайн не покрывает. Детальный дизайн — это уровень "псевдокода".

B>Выкинем из классов код, оставим только интерфейсы (описания) классов = Дизайн

Это дизайн. Вернее, один его не самый важный элемент — структурные модели, без поведения и потока данных. Кроме интерфейса у класса может быть протокол взаимодействия (state chart), и контракты. Кроме того, в системе есть разнообразные потоки данных и управления (sequence и collaboration диаграммы). Ничего из перечисленного не получается из интерфейсов классов.

B>Выкинем все "лишние" классы, оставим только минимальное необходимое количество для функционирования системы, объединим в подсистемы = Архитектура

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

B>Естественно, при проектировании порядок будет противоположный, но это так, для иллюстрации.

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

B>Отсюда же следует, что алгоритмы и структуры данных ортогональны этим определениям.

Отсюда много чего интересного следует, например — по вашему алгоритмы и структуры данных ортогональны тому самому коду (!), который вы выкинули из классов, назвав оставшееся дизайном

. Любопытно, как же этот код, который вы выкинули, без алгоритмов-то и структур данных работает, а?

Что в этом коде тогда написано, не объясните?

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

AL>Я на серьезных дядек типа Рэмбо, Буча и ко. как бы и не ссылаюсь, ибо пустое это дело -- ссылаться на авторитетных дядек

А в PSP/TSP легко найти термин "архитектура" в том смысле, что PSP/TSP к архитектуре, требованиям и прочей технической ерунде вроде как ортогональны:

В PSP/TSP подобная техническая ерунда присутствует в классификаторе ошибок (весь их подход к оптимизации процесса базируется на анализе природы ошибки). И термины "детальный дизайн" и "дизайн" там определяются достаточно точно. Как и такие мероприятия как "design inspection", "detailed design inspection", и "code inspection", являющиеся основными элементами подхода. По крайней мере, нас на курсах PSP/TSP учили именно этому.

G>>Еще пример — решаем, что все прикладные объекты хранят свое состояние в реляционной БД. Со всеми вытекающими, в частности — некая общая подсистема управления этим состоянием.

AL>Боюсь, не всегда получится принять такое решение на уровне стратегии, не вдаваясь в детали и не решив вопросы о том, что такое в данном случае "прикладной объект", что такое "состояние прикладного объекта" и что значит "хранят состояние". Вернее, получиться-то может и получится, но потом может быть мучительно больно из-за последствий такого стратегического решения.

Кто-то говорит, что стратегические решения надо принимать от балды, не вдаваясь в детали и не анализируя их последствия в долгосрочной перспективе?

G>>Архитектура в таком определении слабо зависит от конкретных требований. Она скорее накрывает некий "класс" или "метакласс" возможных требований. Непосредственно сами требования реализуются дизайном (в рамках ограничений, заданных архитектурой).

AL>В таком случае не очень понятно, от чего зависит архитектура и как на уровне стратегии понять, правильная она или нет. Например, решив хранить состояние прикладных объектов в реляционной базе, через год дизайна выясняем, что пользователям системы придется курить по 5 минут после каждого изменения любого совместно изменяемого объекта на любом клиентском рабочем месте.

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

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

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

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

B>>Определение дизайна я дать не могу. Но я бы предположил, что указанные три термина могли бы обозначать следующее:
B>>Возмем систему, со всеми ее классами и пр. = Детальный дизайн

G>Код, это очевидно, не "детальный дизайн". Код — это код. Ошибка кодирования четко отличается от ошибки детального дизайна. Одно дело ошибиться в алгоритме, или выбрать неподходящую структуру данных, и совсем другое дело — ошибка кодирования. Определение детального дизайна я взял из PSP/TSP, где все эти определения берутся из классификатора ошибок. В UML для описания алгоритмов в принципе подойдет activity диаграмма, однако честнее и правильнее сказать что UML детальный дизайн не покрывает. Детальный дизайн — это уровень "псевдокода".

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

Но, вернемся к Вашему посту.

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

Я не согласен с выделенным. Как минимум, потому что архитектура включает в себя разбиение по компонентам и их взамодействие. Но Вы эти элементы архитектуры исключили.
Поэтому считаю Ваше определение архитектуры, м-м-м... не полным.

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

Согласен.

... << RSDN@Home 1.2.0 alpha 4 rev. 1136>>

Здравствуйте, Аноним.
А>Так. Штрафной вам. Я специально обратил внимание, что не ГУЯ, а УЯ. А вы опять пишете — ГУЙ! Это уже не взаимное недопонимание, а результат вашего невнимательного прочтения. И теперь мне остается только второй раз написать то же самое.

Читаю я, читаю — а куда деваться? Просто на инглиш всё время переключаться лень, а "уй" склонять — воспитание не позволяет. Ради вашего спокойствия буду использовать "UI". Кстати, 1:1 — я вас выше в троллизме обвинял, теперь вы меня — в нечтении. Квиты?

А>Файлики — это часть дизайна интерфейса, в смысле, как им называться, куда сохраняться и т.д. Возьмем такой продукт как Outlook и его самый знаменитый файл — pst-шник. Это интерфейс, поскольку пользователь взаимодействует с этим файлом. Куча юз-кейсов завязана на его копирование и пр. Дизайн подразумевает, что весь контент хранится в нем, а архитектуре остается только плясать в этих рамках. Архитектор может сделать некую БД, которая бинарно сохраняется в этот файл, как база mySQL представляет собой несколько файликов с невразумительными названиями на диске, а может сделать плоский файл. В первом случае ему придется заводить модуль (dll-ку или exe-шник), который обрабатывает запросы и возвращает датасеты, во-втором — скорее всего, достаточно простого класса-сериализатора массива. Вот это — архитектура поверх UI.

О. Теперь у нас UI — это все _возможные_ варианты использования в том числе и те, что никак не будут отображаться пользователю? В вашем примере с PST нет кстати копирования — это для пользователя оно так выглядит. Две самые важные функции — импорт/экспорт — выполняются как операции с внутренней стуктурой pst. Или для вас это всё равно копирование — потому что "документики летают"?

А>Далее. Работа с сетью — а подразумевается, что продукт работатет с сетью? Как? В спецификации дизайна описано — пользователь нажимает сюда, идет соединение с таким-то сервером по выбранному им протоколу?

А теперь к UI и к "дизайну интерфейса" добавляется "спецификация дизайна". Я не успеваю следить за появлением новых терминов. Или это синонимы? Что ж у вас такое — спецификация дизайна? Для меня казалось что UI и внутренняя логика работы — по дефолту разные вещи. У вас в UI уже вошли внутренние алгоритмы работы. Что ещё туда войдёт?

А>Следующий случай — потоки. По-моему, потоки как ничто другое являются прямым следствием дизайна. Написано: при нажатии "Синхронизировать" пользователю открывается окно (см. схему 137) с прогрессом синхронизации, а он в то же время может продолжать работу в основном окне 1...

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

S>>Непродуктивно. С точки зрения пользователя спеллчекер — это красные полосочки под словами. Опишите мне архитектуру спеллчекера на основе вышеприведённого. Я молчу про подпись документов, поддержку кастомныхх конвертеров/надстроек/макросов, печать и несколько видов отображения документа, которые предоставляют волзможность делать одно и то же различными способами.

А>Понятно. Не "архитектура" у нас разная, как вы предположили, а "дизайн". Если спелчекер — это просто красные полосочки, видимо дизайн для вас — это гламурность цветовой гаммы.

Хорошо. Как спеллчекер выглядит со стороны пользователей? Отображение возможных опечаток + варианты исправления + настройка параметров. Приведите архитектуру спеллчекера, описание основных компонентов — вордбрикера/стеммера/тезауруса/grammar/tokenizer'а и как оно строится на основе взаимодействия с пользователем.

А>Спелчекер — это не просто красные полосочки. Это, во-первых, полосочки зигзагом. ... ПОТОМУ, ЧТО В HTML ТОГДА НЕ БЫЛО ПОДЧЕРКИВАНИЯ ЗИГЗАГОМ! (Не знаю, как сейчас). Вот бы было весело, если бы архитектор действовал в первый черед, началоось бы всем известное: "архитектура не поддерживает, идите в опу".

Гмм... http://lmgtfy.com/?q=html+%D0%BF%D0%BE%D0%B4%D1%87%D1%91%D1%80%D0%BA%D0%B8%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5+%D0%B2%D0%BE%D0%BB%D0%BD%D0%B8%D1%81%D1%82%D0%BE%D0%B9+%D0%BB%D0%B8%D0%BD%D0%B8%D0%B5%D0%B9. Первая ссылка.
-или-
http://www.htmlbook.ru/content/?id=65
-или-
http://www.tigir.com/css.htm.
То, что вы предпочли отказаться от технологии из-за незнания её возможностей ещё не говорит о том что UI должен быть на первом месте. Если бы у вас в команде был архитектор — UI был бы отделён от логики работы и его можно было бы менять как вам понравится.

А>Спелчекер — это не просто красные полосочки. Это, во-первых, полосочки зигзагом...
А>(Правда, закончилось все Скинтиллой, которая тоже не поддерживала такое подчеркивание, но это потому, что процесс обсуждения между группами UI/архитектуры/кода и визионером проекта шел в сто итераций, нашлись и другие требования, и другие дизайнерские приоритеты, и другие архитектурные).
А>Далее, это полосочки, которые появляются не отвлекая пользователя от печатания текста.
А>Наконец, это полосочки, которые появляются под словами, не найденными в словаре.
А>Все вместе это ограничивает архитектуру до известных рамок. Редактор текста должен быть выбран такой, чтобы либо подчеркивания в нем были, либо легко добавлялись. Проверка должна идти в отдельном потоке (как же еще это можно сделать?). Должен быть механизм подключения словаря, а интерфейсы его ориентированы на быстрое нахождение по списку. Видите, как прекрасно описывается архитектура по результатам дизайна?

1) http://lmgtfy.com/?q=scintilla+wave+underline
2) Как у вас от этих перетрясок менялся алгоритм проверки формул — основная часть спеллчекера? Как у вас проектировалась архитектура спеллчекера?

S>>Вы продаёте продукты или вы их пишете?
А>И то, и другое. Видимо поэтому я и вижу процесс полнее.
А... Ну сорри — я всего лишь девелопер. Куда нам до высоких интересов бизнеса...

S>>Кстати, с вашей точки зрения 2003 и 2007-й офисы — совершенно разные продукты. И у MS даже теоретичестки не должнобыло получиться внести кардинальные изменения в гуй не переписав весь офис с нуля.

А>Ну, я ж говорю: дизайн для вас — это гламурные тона. Если не считать цветовой схемы и убранной кастомизации, в MSO 2007 дизайн поменялся не очень много. Это во-первых. А во-вторых, у вас здесь логическая ошибка. Пусть дизайны различаются на все 100%. Придется ли при этом переписывать все с нуля? Ответ: необязательно. Зависит от дизайнов до и после. Может быть, оба разных дизайна вполне могут работать на одной и той же архитектуре.
А>Ключевой момент в том, что ИНОГДА — НЕ МОГУТ. Поэтому и надо давать дизайну более высокий приоритет. Это и вылезает из моей формулы.

Так у вас UI уже не всегда определяет архитектуру? Вы уж определитесь

Да, незнание того, как поменялись внутренности ворда — а там много изменений — не повод упрекать других в "дизайн для вас — это гламурные тона".
Кстати тот же офис безумно страдает от вашего подхода. Как пример "архитектурного" решения: формат файлов офиса изначально был спроектирован так, чтобы использовать memory mapping — файл напрямую отображался в память и ворд работал с отдельными частями без преобразований/загрузки всего файла в память. Это привело к куче граблей с совместимостью форматов (внутренняя логика конвертеров 2000го и 2003-го ворда — тот ещё кошмар). Я молчу о плясках с бубном и с OpenXML.

А>>>Поэтому, это не вершина айсберга. Это, продолжая вашу метафору — полная поверхность айсберга, включая его подводную часть (куда по умолчанию сохранять файлы, можно ли подключаться к серверу, как осуществляется вставка других объектов других софтов — ну, вы поняли).

S>>Ок. У вас требование "я хочу айсберг в форме перевёрнутой пирамиды". Расскажите мне как из этого требования вы узнаете хоть что-то про внутренности аёсберга. Или это проблемы архитекторов?

А>Да, архитектора. Но не "проблемы", а "зона ответственности". Если такая чисто дизайнерская фишка, как перевернутость пирамиды, дорастает до статуса требования, наверное, это важно. Иначе, никто бы не стал такое требование писать. Не должны аналисты приносить такие требования, пока половина юзеров не скажет им — в микрософте айсберги перевернутые, и мы хотим такое же. Так вот, если такое требование попадает дизайнеру, ЧТО он может с ним сделать? Отдать архитектору, а уже тот пусть думает про центр тяжести и прочие дела.

Дарагой вы наш! Сказали бы сразу, что смотрите на продукт с точки зрения дизайнера/продавца — никто вам и слова бы не сказал, время бы сэкономили. Естественно, что свою работу вы ставите как самую приоритетную. Здесь вообще-то тема о влиянии требований на внутренности подукта. Если вы не занимаетесь проектированием архитектуры и не имеете в этой области никакого опыта — какого влазите? тьфу...

Здравствуйте, Beam!

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

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

Про оценку требований пока говорить не будем — в принципе те же методы что и в управлении рисками. Точнее, это оно и есть.

B>Архитектор выдяеляет архитектурно-важные требования и строит архитектуру. Все это есть в RUP например.
На основе чего эти требования выделяются? Исключительно на основе интуиции? Как можно снизить риск некорректной подборки требований или того, что были упущены/не названы важные требования?

B>Архитектор — "технарь", он не должен выдумывать требования.
Бизнес-требования — согласен. Уточнение: архитектура (я всё ещё использую определения Gaperton'a. Как они там доспорят — посмотрим

) накладывает некоторые ограничения и их можно трактовать как дополнительные требования к функционалу. Согласны?

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

А>>Файлики — это часть дизайна интерфейса, в смысле, как им называться, куда сохраняться и т.д. Возьмем такой продукт как Outlook и его самый знаменитый файл — pst-шник. Это интерфейс, поскольку пользователь взаимодействует с этим файлом. Куча юз-кейсов завязана на его копирование и пр. Дизайн подразумевает, что весь контент хранится в нем, а архитектуре остается только плясать в этих рамках. Архитектор может сделать некую БД, которая бинарно сохраняется в этот файл, как база mySQL представляет собой несколько файликов с невразумительными названиями на диске, а может сделать плоский файл. В первом случае ему придется заводить модуль (dll-ку или exe-шник), который обрабатывает запросы и возвращает датасеты, во-втором — скорее всего, достаточно простого класса-сериализатора массива. Вот это — архитектура поверх UI.

S>О. Теперь у нас UI — это все _возможные_ варианты использования в том числе и те, что никак не будут отображаться пользователю?

Из чего вы это вывели?

>В вашем примере с PST нет кстати копирования — это для пользователя оно так выглядит. Две самые важные функции — импорт/экспорт — выполняются как операции с внутренней стуктурой pst. Или для вас это всё равно копирование — потому что "документики летают"?

Копирование — это часть юз-кейса. Юз-кейс такой: выгрузить все в pst-шку, скопировать на флешку, загрузить в Outlook на другой машине. Пользователь это видит — значит, это дизайн. Содержимое этой pst-шки он не видит — там может быть что угодно, это уже архитектура. Аналогично, пользователь не видит всех тех dll-ок, которые готовят pst, и ему наплевать, сколько в программе модулей и каких. Значит, это тоже не дизайн.

А>>Далее. Работа с сетью — а подразумевается, что продукт работатет с сетью? Как? В спецификации дизайна описано — пользователь нажимает сюда, идет соединение с таким-то сервером по выбранному им протоколу?

S>А теперь к UI и к "дизайну интерфейса" добавляется "спецификация дизайна". Я не успеваю следить за появлением новых терминов. Или это синонимы? Что ж у вас такое — спецификация дизайна? Для меня казалось что UI и внутренняя логика работы — по дефолту разные вещи. У вас в UI уже вошли внутренние алгоритмы работы. Что ещё туда войдёт?

Спецификация — это полное описание. Или устное, или в виде документа. Может, еще гвоздем нацарапано на мониторе. Поэтому, спецификация к дизайну интерфейса не добавляется. Когда дизайнер долго думал над дизайном, проработал его до мелочей, на свет появляется документ, содержащий эту самую спецификацию.

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

А>>Следующий случай — потоки. По-моему, потоки как ничто другое являются прямым следствием дизайна. Написано: при нажатии "Синхронизировать" пользователю открывается окно (см. схему 137) с прогрессом синхронизации, а он в то же время может продолжать работу в основном окне 1...

S>Раз мы отображаем окно с надписью "синхронизируемся" — то мы работаем в другом потоке. Вы смешиваете описание UI и реализацию в одном предложении, добавляете низкоуровневой инфы и называете это спецификацией и проектируете на основе её архитектуру?

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

Когда я написал, что посмотрю, как вы это будете проектировать без потоков, я, собственно, циклы в виду и имел. Поток — это единственное разумное проектировочное решение на такой дизайн. Единственное разумное, а не единственное ВООБЩЕ. Поэтому, ничего я не смешиваю. И покажите хоть грамм "низкоуровневой инфы" в моем примере. Я даже не знаю, что и подумать. "Синхронизировать" — это надпись на кнопке, то есть дизайн. Схема 137 — это схема №137 из документа, описывающего дизайн. Прогресс — это название элемента управления из ОС Windows (progress control). А то, что пользователь может — так это уже по определению дизайн. Как этого добьются архитекторы с программистами, никого не колышет. Короче, что за "низкоуровневая инфа" такая?

S>Гмм... http://lmgtfy.com/?q=html+%D0%BF%D0%BE%D0%B4%D1%87%D1%91%D1%80%D0%BA%D0%B8%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5+%D0%B2%D0%BE%D0%BB%D0%BD%D0%B8%D1%81%D1%82%D0%BE%D0%B9+%D0%BB%D0%B8%D0%BD%D0%B8%D0%B5%D0%B9. Первая ссылка.
S>-или-
S>http://www.htmlbook.ru/content/?id=65
S>-или-
S>http://www.tigir.com/css.htm.
S>То, что вы предпочли отказаться от технологии из-за незнания её возможностей ещё не говорит о том что UI должен быть на первом месте. Если бы у вас в команде был архитектор — UI был бы отделён от логики работы и его можно было бы менять как вам понравится.

Все эти дешевые трюки с картинками не стоят, извините, ничего даже в режиме отображения. Откройте ваш тигир и выделите параграф со словом "ошимбок" целиком. А теперь откройте Ворд, и выделите параграф с таким словом в нем. Разницу видите? Так это еще режим ОТОБРАЖЕНИЯ html. А я писал про режим РЕДАКТИРОВАНИЯ, в котором есть свои заморочки. Я вот только не помню, были ли еще и заморочки с версией IE, вообще-то много лет уже прошло. Попробуйте поверить, что кругом вас тоже не одни дураки. Особенно, когда им нужно было решать свою проблему.

Я еще раз говорю, когда все эти дизайнерские тонкости заранее не продуманы, а решение "давайте использовать IE" или там "давайте использовать скинтиллу" принимаются с кондачка, получается потом продукт из серии "не пришей #$%де рукав".

А>>Спелчекер — это не просто красные полосочки. Это, во-первых, полосочки зигзагом...
А>>(Правда, закончилось все Скинтиллой, которая тоже не поддерживала такое подчеркивание, но это потому, что процесс обсуждения между группами UI/архитектуры/кода и визионером проекта шел в сто итераций, нашлись и другие требования, и другие дизайнерские приоритеты, и другие архитектурные).
А>>Далее, это полосочки, которые появляются не отвлекая пользователя от печатания текста.
А>>Наконец, это полосочки, которые появляются под словами, не найденными в словаре.
А>>Все вместе это ограничивает архитектуру до известных рамок. Редактор текста должен быть выбран такой, чтобы либо подчеркивания в нем были, либо легко добавлялись. Проверка должна идти в отдельном потоке (как же еще это можно сделать?). Должен быть механизм подключения словаря, а интерфейсы его ориентированы на быстрое нахождение по списку. Видите, как прекрасно описывается архитектура по результатам дизайна?

S>1) http://lmgtfy.com/?q=scintilla+wave+underline

Да, тут меня память подвела. Как раз в скинтилле-то это и решалось.

S>2) Как у вас от этих перетрясок менялся алгоритм проверки формул — основная часть спеллчекера? Как у вас проектировалась архитектура спеллчекера?

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

S>>>Вы продаёте продукты или вы их пишете?
А>>И то, и другое. Видимо поэтому я и вижу процесс полнее.
S>А... Ну сорри — я всего лишь девелопер. Куда нам до высоких интересов бизнеса...

Будучи всего лишь девелопером, можно вполне представлять, что если продукт и пишется для чьего-то удовлетворения, то скорее юзера, чем архитектора.

S>>>Кстати, с вашей точки зрения 2003 и 2007-й офисы — совершенно разные продукты. И у MS даже теоретичестки не должнобыло получиться внести кардинальные изменения в гуй не переписав весь офис с нуля.

А>>Ну, я ж говорю: дизайн для вас — это гламурные тона. Если не считать цветовой схемы и убранной кастомизации, в MSO 2007 дизайн поменялся не очень много. Это во-первых. А во-вторых, у вас здесь логическая ошибка. Пусть дизайны различаются на все 100%. Придется ли при этом переписывать все с нуля? Ответ: необязательно. Зависит от дизайнов до и после. Может быть, оба разных дизайна вполне могут работать на одной и той же архитектуре.
А>>Ключевой момент в том, что ИНОГДА — НЕ МОГУТ. Поэтому и надо давать дизайну более высокий приоритет. Это и вылезает из моей формулы.

S>Так у вас UI уже не всегда определяет архитектуру? Вы уж определитесь

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

S>Да, незнание того, как поменялись внутренности ворда — а там много изменений — не повод упрекать других в "дизайн для вас — это гламурные тона".

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

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

S>Кстати тот же офис безумно страдает от вашего подхода. Как пример "архитектурного" решения: формат файлов офиса изначально был спроектирован так, чтобы использовать memory mapping — файл напрямую отображался в память и ворд работал с отдельными частями без преобразований/загрузки всего файла в память. Это привело к куче граблей с совместимостью форматов (внутренняя логика конвертеров 2000го и 2003-го ворда — тот ещё кошмар). Я молчу о плясках с бубном и с OpenXML.

Пользователь в гробу видал ваш memory mapping. Никакого отношения к дизайну он не имеет.

А>>>>Поэтому, это не вершина айсберга. Это, продолжая вашу метафору — полная поверхность айсберга, включая его подводную часть (куда по умолчанию сохранять файлы, можно ли подключаться к серверу, как осуществляется вставка других объектов других софтов — ну, вы поняли).

S>>>Ок. У вас требование "я хочу айсберг в форме перевёрнутой пирамиды". Расскажите мне как из этого требования вы узнаете хоть что-то про внутренности аёсберга. Или это проблемы архитекторов?

А>>Да, архитектора. Но не "проблемы", а "зона ответственности". Если такая чисто дизайнерская фишка, как перевернутость пирамиды, дорастает до статуса требования, наверное, это важно. Иначе, никто бы не стал такое требование писать. Не должны аналисты приносить такие требования, пока половина юзеров не скажет им — в микрософте айсберги перевернутые, и мы хотим такое же. Так вот, если такое требование попадает дизайнеру, ЧТО он может с ним сделать? Отдать архитектору, а уже тот пусть думает про центр тяжести и прочие дела.

S>Дарагой вы наш! Сказали бы сразу, что смотрите на продукт с точки зрения дизайнера/продавца — никто вам и слова бы не сказал, время бы сэкономили. Естественно, что свою работу вы ставите как самую приоритетную. Здесь вообще-то тема о влиянии требований на внутренности подукта. Если вы не занимаетесь проектированием архитектуры и не имеете в этой области никакого опыта — какого влазите? тьфу...

Я могу еще раз повторить то, что имеет отношение к теме: для весьма немаленького класса ПО между требованиями и "внутренностями" стоят "внешности", то есть интерфейс со своим дизайном. Извините, что разжевывал эту простую мысль так долго. Больше не буду. Понимающему open-minded человеку разжевывать не нужно, а остальным объясняй, не объясняй, чистый time waste.

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

G>Кто-то говорит, что стратегические решения надо принимать от балды, не вдаваясь в детали и не анализируя их последствия в долгосрочной перспективе?

Когда мне говорят:

Детальный дизайн — алгоритмы и структуры данных. Дизайн — разбиение функциональности по компонентам, модулям, или классам. Архитектура — то, что не перечисленное.

я теряюсь, потому как до сих пор считал структурное и поведеческое представления одними из составных частей архитектурного описания системы. Взять хотя бы микроархитектуру процессора какого-нибудь или архитектуру команд ... впрочем, пустое это всё

, ибо как говорит один мой молодой коллега: "ничего нет! вообще ничего!"

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

Типо магия с элементами божественного просветления, да?

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

Поэтому в повседневном труде мы считаем архитектуру сочетанием структуры системы и множества отношений между элементами структуры, в котором реализуются не внешние требования к системе, а функции, позволяющие удовлетворить некие требования. При этом архитектура является неотъемлемой частью системы и создается, развивается и эволюционирует вместе с системой. Получив или выявив требования, мы формируем перечень функций и ограничений, после чего функции группируются в подсистемы по сходности достигаемых целей и режутся снизу вверх на слои для минимизации зависимости друг от друга и от окружения. Магия в том, как правильно сгруппировать и порезать, не поддавшись дьявольскому соблазну начать проектирование "в лоб". Есть ли польза от такой трактовки? Ну, иначе я даже не представляю, как хотя бы сформировать перечень целей и задач, которые должны быть достигнуты и выполнены в процессе проектирования при детальном планировании работ и последующем контроле. Это во-первых. Во-вторых, таким образом на базе одного фреймворка и кодовой базы удается реализовывать разные проекты для разных платформ в довольно короткие сроки при крайней ограниченности в ресурсах. Хотя, как недавно заметил thesz, наши проекты -- это по-любому полгода максимум, так что риск провала стоит копейки

Забыл сказать, что одним из авторов IEEE 1471-2000 является небезызвестный Philippe Kruchten. Вероятно, поэтому среди правильных дядек сей труд не фаворе

Здравствуйте, Аноним...

S>>О. Теперь у нас UI — это все _возможные_ варианты использования в том числе и те, что никак не будут отображаться пользователю?

А>Из чего вы это вывели?
Ваше?

Это интерфейс, поскольку пользователь взаимодействует с этим файлом.Куча юз-кейсов завязана на его копирование и пр.
...
Архитектор может сделать некую БД, которая бинарно сохраняется в этот файл, как база mySQL представляет собой несколько файликов с невразумительными названиями на диске, а может сделать плоский файл.
...
Вот это — архитектура поверх UI.

Юз-кейзы у вас определяют способ хранения внутренних данных исходя из того, что эти данные надо будет копировать. Gaperton назвал это архитектурой — т.к. такое решение ограничивает возможности реализации. В частности возможность _копирования_ файла в любой момент слегка конфликтует с традиционным write-ahead подходом в транзакционных СУБД.

Самое смешное, что несмотря на то, что ваше требование _уже_ наложило ограничения, никакого копирования на самом деле не будет — будет экспорт (очистка системных метаданных, преобразование к совместимому формату, возможно шифрование и выгрузка). Но никак не копирование посредством вызовов системного api.

А>Копирование — это часть юз-кейса. Юз-кейс такой: выгрузить все в pst-шку, скопировать на флешку, загрузить в Outlook на другой машине. Пользователь это видит — значит, это дизайн. Содержимое этой pst-шки он не видит — там может быть что угодно, это уже архитектура.

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

Продолжаем разбираться с вашим примером. Проблемы аутлука заканчиваются на "выгрузить все в pst-шку по указанному пути". Выше вы заявляли:

Возьмем такой продукт как Outlook и его самый знаменитый файл — pst-шник. Это интерфейс, поскольку пользователь взаимодействует с этим файлом. Куча юз-кейсов завязана на его копирование и пр. Дизайн подразумевает, что весь контент хранится в нем

Теперь выясняется что pst нужен только для экспорта/импорта между оутглюками на разных компах. Но вы заявили возможность только копирования файла и используете один и тот же формат для экспорта и для хранения внутренних данных. Это накладывает нехилые ограничения на будущее продукта. Начиная от совместимости версий и заканчивая проблемами с другими методами синхронизации. Для них придётся использовать свой механизм. Аутлук, к слову, использует общий механизм для импорта/экспорта и синхронизацией с почтовыми серверами и (в последней версии) с rss. Между прочим это явно противоречит тому что видит пользователь — почту он получает по сети, а импортированные письма — из файла.

А>Спецификация — это полное описание. ... Когда дизайнер долго думал над дизайном, проработал его до мелочей, на свет появляется документ, содержащий эту самую спецификацию.

А>Можете, если вас напрягают термины, заменить "спецификацию" на "документ, подробно описывающий UI". Внутренняя логика работы и UI — это не одно и то же. Но описание "и когда пользователь нажал сюда, появляется диалог, предлагающий сохранить pst" — это описание UI, а не "внутренней логики".

Всё чудесатей и чудесатей(с). У вас полное описание системы создаётся дизайнером UI (я вас правильно понимаю?)? Реализоваться система тоже на основе этого описания будет? Зачем вам тогда архитектор и архитектура?

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

S>>Раз мы отображаем окно с надписью "синхронизируемся" — то мы работаем в другом потоке. Вы смешиваете описание UI и реализацию в одном предложении, добавляете низкоуровневой инфы и называете это спецификацией и проектируете на основе её архитектуру?

А>Вообще-то, ничего я не смешиваю. ... Тем самым, потоки НЕ закладываются дизайнером. Дизайнером закладывается параллельность дизайна, а как это будет выполнено — ему пофиг. Хоть святым духом.
A> ... А то, что пользователь может — так это уже по определению дизайн. Как этого добьются архитекторы с программистами, никого не колышет. Короче, что за "низкоуровневая инфа" такая?

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

А>Все эти дешевые трюки с картинками не стоят, извините, ничего даже в режиме отображения. ...

Угу. Принято. Тем не менее есть хотя бы намёк на возможность решения. Раздражает когда говарят нечто в духе "ie в принципе не способен".

А>Я еще раз говорю, когда все эти дизайнерские тонкости заранее не продуманы, а решение "давайте использовать IE" или там "давайте использовать скинтиллу" принимаются с кондачка, получается потом продукт из серии "не пришей #$%де рукав".

Это тривиальные риски выбора технологии реализации — что вы с ними носитесь как будто это нечто уникальное? Те же самые проблемы с подбором инструментария, команды, методологии и т.п. Почему всё это дело у вас определяет архитектуру —

S>>2) Как у вас от этих перетрясок менялся алгоритм проверки формул — основная часть спеллчекера? Как у вас проектировалась архитектура спеллчекера?
А>Вопрос не релевантен. Алгоритм проверки формул не имеет отношения ни к дизайну, ни к архитектуре. Алгоритм — это код, часть реализации. Самый нижний слой.

Чуть выше вы писали

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

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

А>Будучи всего лишь девелопером, можно вполне представлять, что если продукт и пишется для чьего-то удовлетворения, то скорее юзера, чем архитектора.

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

S>>>>Кстати, с вашей точки зрения 2003 и 2007-й офисы — совершенно разные продукты. И у MS даже теоретичестки не должнобыло получиться внести кардинальные изменения в гуй не переписав весь офис с нуля.

S>>Так у вас UI уже не всегда определяет архитектуру? Вы уж определитесь

А>Всегда, но два совершенно разных UI теоретически можно реализовать на базе одной и той же архитектуры. ... Я говорю, на практике чаще всего бывает так, что даже небольшое (не радикальное) изменение интерфейса приводит к радикальному изменению архитектуры.

S>>Да, незнание того, как поменялись внутренности ворда — а там много изменений — не повод упрекать других в "дизайн для вас — это гламурные тона".

А>А вот что я утверждаю, так это то, что интерфейс поменялся не настолько сильно, чтобы говорить, что это "совершенно разные продукты". Серьезное изменение дизайна там ровно одно, остальное — или новый функционал, или жонглирование иконками.

В новом офисе очень много чего поменялось. Даже 95/97-й внутри имели куда меньше новых фич.

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

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

Как же бедным мс удалось радикальное изменение гуя без поломанной архитектуры? Может, они не знали о ваших принципах?

S>>Кстати тот же офис безумно страдает от вашего подхода.

А>Пользователь в гробу видал ваш memory mapping. Никакого отношения к дизайну он не имеет.

Таак. Т.е в случае оутлука логика работы с файлом — это UI, а в случае с вордом — это не UI. Выстройте наконец стройную концепцию и приходите — с субъективными ощущениями спорить неудобно

А>Я могу еще раз повторить то, что имеет отношение к теме: для весьма немаленького класса ПО между требованиями и "внутренностями" стоят "внешности", то есть интерфейс со своим дизайном. Извините, что разжевывал эту простую мысль так долго. Больше не буду. Понимающему open-minded человеку разжевывать не нужно, а остальным объясняй, не объясняй, чистый time waste.

Гы... теперь знаю современный синоним для анацефалов — open-minded. Однако как политкорректно

//сорри, не удержался

Вначале вы утверждали, что

S>>Так у вас UI уже не всегда определяет архитектуру? Вы уж определитесь
А>Всегда ...

Теперь вы сводите UI к ещё одной форме требований, но по-прежнему утверждаете, что эти требования имеют самый высокий приоритет и определяют способ реализации всех остальных требований.

Что вы будете утверждать завтра?)

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

S>>>О. Теперь у нас UI — это все _возможные_ варианты использования в том числе и те, что никак не будут отображаться пользователю?
А>>Из чего вы это вывели?

S>Ваше?
S>

S>Это интерфейс, поскольку пользователь взаимодействует с этим файлом.Куча юз-кейсов завязана на его копирование и пр.
S>...
S>Архитектор может сделать некую БД, которая бинарно сохраняется в этот файл, как база mySQL представляет собой несколько файликов с невразумительными названиями на диске, а может сделать плоский файл.
S>...
S>Вот это — архитектура поверх UI.

Мое. Но как отсюда выводится, что "UI — это все _возможные_ варианты использования в том числе и те, что никак не будут отображаться пользователю"?

S>Юз-кейзы у вас определяют способ хранения внутренних данных исходя из того, что эти данные надо будет копировать. Gaperton назвал это архитектурой — т.к. такое решение ограничивает возможности реализации. В частности возможность _копирования_ файла в любой момент слегка конфликтует с традиционным write-ahead подходом в транзакционных СУБД.
S>Самое смешное, что несмотря на то, что ваше требование _уже_ наложило ограничения, никакого копирования на самом деле не будет — будет экспорт (очистка системных метаданных, преобразование к совместимому формату, возможно шифрование и выгрузка). Но никак не копирование посредством вызовов системного api.

А кто вам сказал "в любой момент"? Разумеется, надо делать экспорт и импорт. Но экспорт и импорт обусловлены чем? Копированием. В справке написано: экспортируйте, скопируйте, импортируйте. Ключевой момент — скопируйте. Ради этого юзеру и показывается файл. А все, что показывается юзеру — юзерский интерфейс.

А>>Копирование — это часть юз-кейса. Юз-кейс такой: выгрузить все в pst-шку, скопировать на флешку, загрузить в Outlook на другой машине. Пользователь это видит — значит, это дизайн. Содержимое этой pst-шки он не видит — там может быть что угодно, это уже архитектура.
S>Понимаете, то что видит пользователь не обязательно совпадает с действительностью. Более того, одна и та же информация может быть представлена по-разному. Если у вас есть частичные представлениях — получить исходные данные можно только индукцией. Что там в матлогике говорится о неполной индукции?

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

S>Продолжаем разбираться с вашим примером. Проблемы аутлука заканчиваются на "выгрузить все в pst-шку по указанному пути". Выше вы заявляли:

S>

S>Возьмем такой продукт как Outlook и его самый знаменитый файл — pst-шник. Это интерфейс, поскольку пользователь взаимодействует с этим файлом. Куча юз-кейсов завязана на его копирование и пр. Дизайн подразумевает, что весь контент хранится в нем

S>Теперь выясняется что pst нужен только для экспорта/импорта между оутглюками на разных компах. Но вы заявили возможность только копирования файла и используете один и тот же формат для экспорта и для хранения внутренних данных. Это накладывает нехилые ограничения на будущее продукта. Начиная от совместимости версий и заканчивая проблемами с другими методами синхронизации. Для них придётся использовать свой механизм. Аутлук, к слову, использует общий механизм для импорта/экспорта и синхронизацией с почтовыми серверами и (в последней версии) с rss. Между прочим это явно противоречит тому что видит пользователь — почту он получает по сети, а импортированные письма — из файла.

Я? Один и то же формат? Шутите вы что ли! Я даже не в курсе, тот pst, что экспортится-импортится, и тот, в котором аутглюк ведет свою работу — это один и тот же формат или нет. Юзеру не предлагается подменять pst-хи из-под рабочего аутглюка, в справке про это ничего нет, я не удивлюсь, узнав что это реально разные форматы. И будь я дизайнером аутглюка, мне бы было все равно, используют ли архитекторы один и тот же формат или разные. Юзер этим просто не интересуется.

S>

А>>Спецификация — это полное описание. ... Когда дизайнер долго думал над дизайном, проработал его до мелочей, на свет появляется документ, содержащий эту самую спецификацию.

А>>Можете, если вас напрягают термины, заменить "спецификацию" на "документ, подробно описывающий UI". Внутренняя логика работы и UI — это не одно и то же. Но описание "и когда пользователь нажал сюда, появляется диалог, предлагающий сохранить pst" — это описание UI, а не "внутренней логики".

S>Всё чудесатей и чудесатей(с). У вас полное описание системы создаётся дизайнером UI (я вас правильно понимаю?)? Реализоваться система тоже на основе этого описания будет? Зачем вам тогда архитектор и архитектура?

Полное описание системы — это ее код. Он описывает систему на машинопонятном языке и так, что полнее не бывает. А спецификация дизайна — заведомо НЕПОЛНОЕ описание. Это описание одного-единственного аспекта — юзерского. Другое неполное описание системы — архитектурная спецификация.

Зачем архитектор — а кто будет думать, на каком языке надо писать, Пушкин? Что выбрать — C++, C#, Java? КОМ или дотНет? Файловый ввод-вывод или SQL-движок? Компонент А или Б? А сервер — внутрипроцессный или локальный? Надо ли использовать MVC?

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

Вы как-то интересно сравниваете. Диалоговое окошко — это дизайнерская статика. Обычное дизайнерское решение. Переход от команд на кастомизируемых тулбарах и меню к командам на некастомизируемых лентах — это дизайнерская динамика (изменение дизайна). И "ниже" одно в другое не переходит.

Диалог — это UI, и ныне, и присно, и во веки веков, а не "сейчас". Где я написал, что ниже он — "незначительные изменения и жонглирование иконками"? Диалог не может быть изменением. Сущность у него такая: объектная, а не процессная.

S>>>Раз мы отображаем окно с надписью "синхронизируемся" — то мы работаем в другом потоке. Вы смешиваете описание UI и реализацию в одном предложении, добавляете низкоуровневой инфы и называете это спецификацией и проектируете на основе её архитектуру?

А>>Вообще-то, ничего я не смешиваю. ... Тем самым, потоки НЕ закладываются дизайнером. Дизайнером закладывается параллельность дизайна, а как это будет выполнено — ему пофиг. Хоть святым духом.
A>> ... А то, что пользователь может — так это уже по определению дизайн. Как этого добьются архитекторы с программистами, никого не колышет. Короче, что за "низкоуровневая инфа" такая?

S>Понимаете, вы хардкодите логику работы системы в UI. Т.е. проектируя систему вы закладываетесь на то что это самое окошко и эта самая кнопка будет у вас отныне и во веки веков — вон, в схеме 137 написано. Вы не учитываете, что одна и та же операция может быть несколькими способами, в том числе и в цепочки последовательностей. Если у вас синхронизация всегда происходит асинхронно (ибо так сказано в схеме 137) — будут грабли при синхронизации с несколькими источниками или при изменении UI.

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

И, извините, но что-то уж больно вы перевираете мои слова. "Вы не учитываете, что одна и та же операция может быть несколькими способами" — я как раз учитываю. Если операция может быть выполнена несколькими способами, я обязательно отражу это в дизайнерской документации.

Кнопка и схема 137 делаются такими, чтоб в будущем их не пришлось менять как можно дольше. Но, конечно, когда-то и их придется отправить на помойку.

Что такое "синхронизация происходит асинхронно" я вообще не понял. В схеме 137 ничего не написано. Схема — это схема, внешний вид окна. Откройте Визио, там есть такой тип схем — XP UI. Поймете, о какой схеме я говорил. Написано — в спецификации, и пример того, что там пишут я привел:

при нажатии "Синхронизировать" пользователю открывается окно (см. схему 137) с прогрессом синхронизации, а он в то же время может продолжать работу в основном окне 1

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

S>

А>>Все эти дешевые трюки с картинками не стоят, извините, ничего даже в режиме отображения. ...

S>Угу. Принято. Тем не менее есть хотя бы намёк на возможность решения. Раздражает когда говарят нечто в духе "ie в принципе не способен".

Скажите, а если вместо зарплаты за программу вам предложат намек на возможность зарплаты, вас это устроит? Вот и нас нет. Пользователю нельзя сказать — вот тебе чувак, IE, он в принципе-то способен, но через ж. Или это работает так, как надо, или оно не работает вообще. Поэтому так и важно, чтоб дизайн был впереди всего, кроме требований.

А>>Я еще раз говорю, когда все эти дизайнерские тонкости заранее не продуманы, а решение "давайте использовать IE" или там "давайте использовать скинтиллу" принимаются с кондачка, получается потом продукт из серии "не пришей #$%де рукав".

S>Это тривиальные риски выбора технологии реализации — что вы с ними носитесь как будто это нечто уникальное? Те же самые проблемы с подбором инструментария, команды, методологии и т.п. Почему всё это дело у вас определяет архитектуру —

Нет, это не риски. Когда вы выбираете инструментарий (допустим, библиотеку), вы не знаете, работает она глючно или безглючно. Это риск. Когда вы нанимаете программиста, вы не знаете, принесет он вам доход или загонит в убытки (насколько его сил хватит). Это риск. Когда вы проектируете систему, имея полную дизайнерскую спецификацию на руках, вы в безрисковом порядке, со стопроцентной гарантией, получаете архитектуру, которая соответствует финальному варианту этой самой дизайнерской спецификации. Понятно? А вот если решения о скинтилле/ИЕ принимаются исходя из общих соображений, типа, в принципе и с молитовкой все возможно, вот тогда и начинаются риски. Которых могло не быть. И прямая обязанность ПМа сделать так, чтоб их не было.

S>

S>>>2) Как у вас от этих перетрясок менялся алгоритм проверки формул — основная часть спеллчекера? Как у вас проектировалась архитектура спеллчекера?
А>>Вопрос не релевантен. Алгоритм проверки формул не имеет отношения ни к дизайну, ни к архитектуре. Алгоритм — это код, часть реализации. Самый нижний слой.

S>Чуть выше вы писали
S>

S>Все вместе это ограничивает архитектуру до известных рамок. Редактор текста должен быть выбран такой, чтобы либо подчеркивания в нем были, либо легко добавлялись. Проверка должна идти в отдельном потоке (как же еще это можно сделать?). Должен быть механизм подключения словаря, а интерфейсы его ориентированы на быстрое нахождение по списку. Видите, как прекрасно описывается архитектура по результатам дизайна?

Не надо мне напоминать, что я писал, а? Я не страдаю амнезией. Вы прямо покажите, как из моих слов вытекает то-то и то-то.

Я настаиваю: вопрос "Как у вас от этих перетрясок менялся алгоритм проверки формул" нерелевантен, поскольку алгоритм не имеет отношения ни к архитектуре, ни к дизайну. А вот то, что я написал "чуть выше" — это имеет отношение и к дизайну, и к архитектуре.

S>"Должен быть механизм подключения словаря, а интерфейсы его ориентированы на быстрое нахождение по списку" —
S>это у вас архитектура, а разбиение спеллчекера на компоненты и алгоритм проверки — это не архитектура. Или это всё дело архитекторов и программистов?

Если да — то вы просто предъявляете определённые требования к архитектуре. Как их сформировать — "надо чтобы логика умела работать с любым представлением" или "надо чтобы логика работала с scintilla" — это ваши проблемы. То что вы поставили узкую задачу перед ребятами не оправдывает ни их, ни вас.

Разбиение спелчекера на компоненты и алгоритм проверки не надо валить в одну кучу. Если действительно есть спелчекерские компоненты, связанные через интерфейсы или что-то типа — это архитектура. А алгоритм проверки, он алгоритм и есть. Вот и все, что я могу сказать. Дадут вам ТЗ — имплементировать ISpellCheck { Load(BSTR); SAFEARRAY GetErrorWordIndices(); } — и интересовать ваша реализация будет только других кодеров, которым ваш код править после вашего увольнения, тестеров, которым важно, чтоб ошибок не было, и профилировщика с секундомером. Но не дизайнера и не архитектора. А вот вы будете заинтересованы в таком дизайне и архитектуре, чтоб их было реально и просто выполнять.

S>>>Кстати тот же офис безумно страдает от вашего подхода.
А>>Пользователь в гробу видал ваш memory mapping. Никакого отношения к дизайну он не имеет.
S>Таак. Т.е в случае оутлука логика работы с файлом — это UI, а в случае с вордом — это не UI. Выстройте наконец стройную концепцию и приходите — с субъективными ощущениями спорить неудобно

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

S>

А>>Я могу еще раз повторить то, что имеет отношение к теме: для весьма немаленького класса ПО между требованиями и "внутренностями" стоят "внешности", то есть интерфейс со своим дизайном. Извините, что разжевывал эту простую мысль так долго. Больше не буду. Понимающему open-minded человеку разжевывать не нужно, а остальным объясняй, не объясняй, чистый time waste.

S>Теперь вы сводите UI к ещё одной форме требований, но по-прежнему утверждаете, что эти требования имеют самый высокий приоритет и определяют способ реализации всех остальных требований.

Э-э... Что-то я припух уже. Требования — это требования. UI — это UI. Архитектура — это архитектура. Во имя человеколюбия, я вам отправлю образцы того, и другого, и третьего, если вы оставите здесь адрес электропочты. Иначе можно до того года переписываться.

S>Что вы будете утверждать завтра?)

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

G>>Кто-то говорит, что стратегические решения надо принимать от балды, не вдаваясь в детали и не анализируя их последствия в долгосрочной перспективе?

AL>Когда мне говорят:

AL>

AL>Детальный дизайн — алгоритмы и структуры данных. Дизайн — разбиение функциональности по компонентам, модулям, или классам. Архитектура — то, что не перечисленное.

AL>я теряюсь, потому как до сих пор считал структурное и поведеческое представления одними из составных частей архитектурного описания системы. Взять хотя бы микроархитектуру процессора какого-нибудь или архитектуру команд ... впрочем, пустое это всё

, ибо как говорит один мой молодой коллега: "ничего нет! вообще ничего!"

Стоп. Стоп. Архитектура уровня системы команд (Instructions Set Architecture) — это как раз хороший пример "стратегического решения", архитектуры в чистом виде, не имеющей отношения ни к дизайну, ни к алгоритмам со структурами данных. Одна и та же ISA может быть реализована совершенно по разному. SPARCv9 ISA можно реализовать c пятиступенчатым конвейром, можно с семи, или с девяти. Можно построить на ее основе суперскалярный проц. А можно — мультитредный, как Ниагара, не имеющий по внутренностям ничего общего с суперскалярным.

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

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

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

AL>Типо магия с элементами божественного просветления, да?

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

AL>Мой опыт говорит следующее. Всякий раз, когда предпринимается попытка реализовать требования в архитектуре (ты об этом говоришь в позапрошлом посте),

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

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

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

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

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

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

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

AL>Ну, иначе я даже не представляю, как хотя бы сформировать перечень целей и задач, которые должны быть достигнуты и выполнены в процессе проектирования при детальном планировании работ и последующем контроле. Это во-первых. Во-вторых, таким образом на базе одного фреймворка и кодовой базы удается реализовывать разные проекты для разных платформ в довольно короткие сроки при крайней ограниченности в ресурсах. Хотя, как недавно заметил thesz, наши проекты -- это по-любому полгода максимум, так что риск провала стоит копейки

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

Слово "архитектура" имеет смысл употреблять, когда цикл развития и поддержки продукта измеряется годами, и/или работает на ним больше одной рабочей группы в 5-6 человек.

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

AL>Забыл сказать, что одним из авторов IEEE 1471-2000 является небезызвестный Philippe Kruchten. Вероятно, поэтому среди правильных дядек сей труд не фаворе

Ну, "от себя скажу" ((с) thesz), что автором понятия "детальный дизайн" является небезызвестный Уотс Хамфри, автор модели CMMI.

Ты тоже не только со мной споришь, это не я придумал.

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

G>Стоп. Стоп. Архитектура уровня системы команд (Instructions Set Architecture) — это как раз хороший пример "стратегического решения", архитектуры в чистом виде, не имеющей отношения ни к дизайну, ни к алгоритмам со структурами данных. Одна и та же ISA может быть реализована совершенно по разному. SPARCv9 ISA можно реализовать c пятиступенчатым конвейром, можно с семи, или с девяти. Можно построить на ее основе суперскалярный проц. А можно — мультитредный, как Ниагара, не имеющий по внутренностям ничего общего с суперскалярным.

Документ с описанием самих команд и того, чем они оперируют (боюсь сказать, "структур данных"), описывает архитектуру уровня системы команд или что-то другое? Если что-то другое, то что именно? Если все-таки архитектуру, то где там "стратегия" и как быть с тем, что там явно перечисляются и описываются операции и операнды, которые по сути являются интерфейсом процессора с окружением?

G>Детальным дизайном в случае микропроцессора являются внутренние алгоритмы работы блоков. Скажем, описание алгоритма работы шедулера инструкций, выполняющих выборку независимых по регистрам инструкций в окне просмотра. Или логическая структура и алгоритмы кэша L1. Эти описания алгоритмов настолько далеко от реализации в Verilog, что является именно дизайном.

Мне удобнее называть это уровнем микроархитектуры, который реализует систему команд неким способом и состоит из неких блоков, связанных так-то и так-то и выполняющих такие-то функции. Каким именно образом -- см. раздел/документы, относящиеся к "детальному дизайну".

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

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

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

Пардон-пардон, вот здесь я действительно сурово все исказил, на самом деле опоннируя вот этой фразе:

Непосредственно сами требования реализуются дизайном (в рамках ограничений, заданных архитектурой)

и говоря о том, что реализуются не требования, а функционал, удовлетворяющий неким требованиям.

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

G>При таком взгляде на вещи и получается закономерный результат, который ты описал выше.

У кого получается? Вообще получается?

У нас довольно сносно получается вроде бы.

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

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

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

G>Полгода — это, во первых, далеко не копейки, если взять ассоциированные расходы и упущенную прибыль (часто задержка на полгода может стоить провала всего проекта), а во-вторых, с циклом в полгода существуют только прототипы или наколенные поделки, для которых не надо вообще заморачиваться понятием архитектуры.

Ну, что ж делать, надо же кому-то и наколенными поделками заниматься (скажем, новыми изделиями в рамках существующей продуктовой линейки или небольшими системами в рамках проектной программы)

G>Слово "архитектура" имеет смысл употреблять, когда цикл развития и поддержки продукта измеряется годами, и/или работает на ним больше одной рабочей группы в 5-6 человек.

Т.е. при семи годах и смешанной группе из 12 человек таки имеет смысл употреблять.

G>Кстати, употребленный тобой термин "фреймворк" — это к архитектуре относится. Архитектурным решением является сам факт наличия фреймворка, а также структура фреймворка и граница между ним и прикладной логикой. Фреймворк является одной из базовых технологий, только своей собственной, а не сторонней разработки.

Если бы было что-то готовое, удовлетворяющее нашим требованиям, наверное взяли бы готовое. А появился фреймворк в процессе разработки в виде одного из системных слоев и представляет он собой почти не претендующий на оригинальность стейт-машинный движок, координирующий работу разных подсистем так, что они ничего не знают друг о друге, а движок -- об их функциональных особенностях. Подсистема при этом -- вполне конкретное и ни капли не метафорическое понятие. Мне хочется продолжать считать, что сей фреймворк является одним из основных элементов архитектуры, лежащей в основе наших систем. Как и слой абстракции окружения, позволяющий одним взмахом генерить бинари и запускаться под Windows, QNX, RTOS-32, Windows CE и CMX-RTX. Ну хочется, и всё тут, ничего не могу с собой поделать

G>Ну, "от себя скажу" ((с) thesz), что автором понятия "детальный дизайн" является небезызвестный Уотс Хамфри, автор модели CMMI.

Ты тоже не только со мной споришь, это не я придумал.

Я не ставлю под сомнение ценность понятия "детальный дизайн". Более того, стандарт IEEE 1016-1998 IEEE Recommended Practice for Software Design Descriptions, можно сказать, является настольной брошюрой

The purpose of the SDD is as follows:
IEEE/EIA 12207.1-1997, Clause 6.16.1: Purpose: Describe the design of a software item. Along with
the software architecture, it provides the detailed design needed to implement the software. It may be
supplemented by software item interface design and database design.

SDD -- software design description.

А авторы CMMI словно сговорились нас (в смысле меня) запутать

Вот, например, цитата со с. 247 книжки Practical Insight into CMMI:

When we define functions, place them into logical groupings, and associate them with the requirements, we refer to this as the functional architecture.

В книжке Real Process Improvement Using the CMMI термин "архитектура процессных систем" упоминается в связке с термином "дизайн" через "или": architecture or design, например:

Critical Factor 4: Design First, Then Build
As briefly addressed in Chapter 3 — Managing the Process Improvement Project, process systems are sometimes built without an architecture or design. Not surprisingly, such process systems are often later rebuilt because the builders, usually SEPG, skipped design decisions which would have yielded a system closer to correct the first time

В общем, готов признать, что с точки зрения принятой сейчас практики, я, видимо, неправильно/напрасно рассматриваю дизайн и архитектуру, как сущности одного порядка. Но по-другому у меня не получается

Здравствуйте, Аноним!

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

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

Единственное что могу посоветовать — попробовать поработать на проекте в другой роли — весь максимализм быстро выветрится.

Я конеш мгу ещё поспорить, но я не думаю что мне удастся вас переубедить, а вам — привести мне объективные доводы обуславливающие нечеловеческую мощь дизайнера в славном деле проектирования архитектуры.

Мировая?

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

S>а вам — привести мне объективные доводы обуславливающие нечеловеческую мощь дизайнера в славном деле проектирования архитектуры.

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

Здравствуйте, Аноним...

S>>а вам — привести мне объективные доводы обуславливающие нечеловеческую мощь дизайнера в славном деле проектирования архитектуры.

А>На последней итерации выяснилось, что вы банально не поняли того, что вам говорили, но взялись спорить (с неверно понятым).

У-ххх.
Забавно, мило спорили, вроде договорились что спорить не о чем ибо разные понятийные аппараты — и тут пошли лёгкие намёки на наезды

Поцитируем что вы писали в начале:

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

Теперь это превратилось в

Нечеловеческая мощь дизайнера — в славном деле ограничения архитектуры, а не ее проектирования

Я всё время спорил с вашим начальным тезисом, по своей наивной привычке считаю, что люди должны отдавать себе отчёт о чём они пишут и быть способными как минимум прокомментировать свою точку зрения.

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

Как с подобным можно спорить?

Удачи вам в подборе исполнителей своих ролей!

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

S>>>а вам — привести мне объективные доводы обуславливающие нечеловеческую мощь дизайнера в славном деле проектирования архитектуры.
А>>На последней итерации выяснилось, что вы банально не поняли того, что вам говорили, но взялись спорить (с неверно понятым).
S>У-ххх.
S>Забавно, мило спорили, вроде договорились что спорить не о чем ибо разные понятийные аппараты — и тут пошли лёгкие намёки на наезды

А что такое понятийный аппарат? Это как в анекдоте "аппарат-то у меня есть", то есть мозг?

S>Поцитируем что вы писали в начале:

S>

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

S>Теперь это превратилось в
S>

S>Нечеловеческая мощь дизайнера — в славном деле ограничения архитектуры, а не ее проектирования

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

S>Я всё время спорил с вашим начальным тезисом, по своей наивной привычке считаю, что люди должны отдавать себе отчёт о чём они пишут и быть способными как минимум прокомментировать свою точку зрения.

Прокомментировал?

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

??? Вы русский язык знаете? Ограничивать и определять — это синонимы. Ограничивать — проводить границу. Определять — проводить предел. Пределы и границы — это синонимы, потому и произведенные от них глаголы — синонимы.

S>Как с подобным можно спорить?
S>Удачи вам в подборе исполнителей своих ролей!

Спасибо, но не до актеров сейчас: кризис. Хоть сам пой на все голоса.

Здравствуйте, Аноним!

Сочуствую вашим проблемам с кризисом. Тем не менее:

А>??? Вы русский язык знаете? Ограничивать и определять — это синонимы. Ограничивать — проводить границу. Определять — проводить предел. Пределы и границы — это синонимы, потому и произведенные от них глаголы — синонимы.

Начались пляски с языком аля Задорнов сотоварищи? (где-то уже писалось про дилетантов от лингвистики — не про вас ни в коем случае). С.И.Ожегов, Н.Ю.Шведова — Толковый словарь русского языка:

ОПРЕДЕЛИТЬ
...
1. что. С точностью выяснить, установить.
...
2. что. Раскрыть словами содержание чего-н.
...
3. что. Установить, назначить.
...
4. (1 и 2 л. не употр.), что. То же, что обусловить (во 2 знач.). Хорошая подготовка определила успех дела.
...
5. кого (что). Назначить, устроить на какую-н. должность или в какое-н. учебное заведение (устар. и прост.).

ОГРАНИЧИТЬ...
Поставить в какие-н. рамки, границы, определить какими-н. условиями, а также сделать меньше, сократить охват кого-чего-н. ...

Одно и то же ?

Я — наивный — вместе с Ожеговым понимал "определить" в 1-м или 2-м смыслах. Я ж говорю — расхождения ещё на уровне понятийного аппарата.

А>Действительно, первое утверждение превратилось во второе. Они не являются тождественными: второе в первое не может превратиться (есть много причин и способов ограничивать одних другим). А первое во второе — может. Поскольку утверждается (мной), что (при известных условиях) славное дело — это когда архитектура зависит от дизайна, а наоборот — бесславное дело, значит дизайнер, так или иначе, ограничивает архитектуру. Если их переставить в "пищевой цепочке", то дизайн будет зависеть от архитектуры, и, значит, будет ей ограничиваться.

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

) ограничивать архитектуру. Я утверждаю что UI в идеале не должен никак влиять на архитектуру и архитектура в идеале должна допускать произвольную логику взаимодействия с пользователем.

Что видите некорретного в моих утверждениях — опишите. А то остаётся чуство тягостного недоумения — вроде сказал, вроде услышали, а толку? Подозреваю, симметрично?

А>Прокомментировал?
Принято.

P.S. Вообще мне это сильно напоминает холивар "фундаментальное образование vs ЕГЭ". Та же аргументация — "мы не можем закладываться на сиюминутные требования рынка" vs "рынок должен определять требования к выпускникам".
На какой стороне мои симпатии — догадайтесь.
Вы за кого болеете?

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

S>Сочуствую вашим проблемам с кризисом. Тем не менее:

А>>??? Вы русский язык знаете? Ограничивать и определять — это синонимы. Ограничивать — проводить границу. Определять — проводить предел. Пределы и границы — это синонимы, потому и произведенные от них глаголы — синонимы.

S>Начались пляски с языком аля Задорнов сотоварищи? (где-то уже писалось про дилетантов от лингвистики — не про вас ни в коем случае). С.И.Ожегов, Н.Ю.Шведова — Толковый словарь русского языка:
S>Одно и то же ?

Я — наивный — вместе с Ожеговым понимал "определить" в 1-м или 2-м смыслах. Я ж говорю — расхождения ещё на уровне понятийного аппарата.

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

Плясать можно без меня. Какие еще тут Ожоговы и Задорновы? Определения были древним грекам известны. Определить — значит провести границу: то, что тут — это оно, а то, что там — уже не оно. Понятия, например, именно так и определяются. Так же точно работают предикаты в математике и программировании. Козлищ отделяют от агнцев, группы элементов массива — друг от друга и так далее. Вы же грамотный человек, судя по лексике, неужели непонятно, что все эти "раскрыть содержание" — это чисто побочные значения, существующие только благодаря главному?

Вернемся к теме. Как бы то ни было, первое и основное значение видно из корня. Определить — провести пределы. Ограничить — провести границы. Дизайн именно это и делает — ограничивает архитектуру. Если сказано — подчеркивание зигзагом как в ворде, IE уже не используешь. Альтернатива — выбирать архитектуру без учета дизайна. Тогда архитектура будет ограничивать интерфейс. Сказано — IE, значит никаких вам "как в ворде".

Так что же вам не нравится?

А>>Действительно, первое утверждение превратилось во второе. Они не являются тождественными: второе в первое не может превратиться (есть много причин и способов ограничивать одних другим). А первое во второе — может. Поскольку утверждается (мной), что (при известных условиях) славное дело — это когда архитектура зависит от дизайна, а наоборот — бесславное дело, значит дизайнер, так или иначе, ограничивает архитектуру. Если их переставить в "пищевой цепочке", то дизайн будет зависеть от архитектуры, и, значит, будет ей ограничиваться.

S>Слушайте, давайте определимся — мы говорим о приоритетах, о ограничении или определении — это всё суть разные понятия. Про приоритеты вообще бестолку говорить — опять всё закончится на "кто в команде главнее". Про ограничения — вы утверждаете что UI должен (или может

) ограничивать архитектуру. Я утверждаю что UI в идеале не должен никак влиять на архитектуру и архитектура в идеале должна допускать произвольную логику взаимодействия с пользователем.

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

Ограничения и определения (хотя бы, как процесс) — это одно и то же.

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

Про идеал я не понял. Мы живем в реальном мире. В реальном мире, скорее всего, UI будет ограничивать архитектуру или наоборот, и заранее предсказать, как именно — невозможно. Примеры же я приводил. Дело все в чем: обычно так четко выделенное выше не формулируется. Я сформулировал четко. Жизнь заставила.

S>Что видите некорретного в моих утверждениях — опишите. А то остаётся чуство тягостного недоумения — вроде сказал, вроде услышали, а толку? Подозреваю, симметрично?

Я не вижу самих утверждений, а не чего-то некорректного. Вы меня цитируете, и даже не показываете, в чем противоречие. Это на мой взгляд не является утверждением.

Утверждения у вас появились совсем недавно. Вот это хорошее утверждение: "Я утверждаю что UI в идеале не должен никак влиять на архитектуру и архитектура в идеале должна допускать произвольную логику взаимодействия с пользователем". Я соглашаюсь, но возражаю против попыток вывести из этого тезиса практические универсальные правила для организации проектов: этот идеал недостижим для большого класса ПО. Хуже всего, что он непредсказуемо недостижим. До определенного этапа может казаться, что влияния нет, а потом оно проявляется. Поэтому, сделав спецификацию дизайна вперед, вы можете убедиться, что ваш идеал выдерживается. Но скорее всего вы убедитесь, что все наоборот. В любом случае, если влияния нет, значит приоритет неважен, так? Пускайте дизайн вперед, хуже не будет.

А>>Прокомментировал?
S>Принято.

S>P.S. Вообще мне это сильно напоминает холивар "фундаментальное образование vs ЕГЭ". Та же аргументация — "мы не можем закладываться на сиюминутные требования рынка" vs "рынок должен определять требования к выпускникам".
S>На какой стороне мои симпатии — догадайтесь.
S>Вы за кого болеете?

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

	От:	Beam
	Дата:	15.02.09 14:24
	Оценка:	-1

	От:	Sinix
	Дата:	15.02.09 14:38
	Оценка:

	От:	Аноним
	Дата:	15.02.09 20:52
	Оценка:	-2

От:	Gaperton	http://gaperton.livejournal.com
Дата:	15.02.09 21:02
Оценка:

От:	Gaperton	http://gaperton.livejournal.com
Дата:	15.02.09 21:25
Оценка:

От:	A.Lokotkov	http://www.linkedin.com/pub/alexander-lokotkov/a/701/625
Дата:	16.02.09 07:50
Оценка: