Здравствуйте, A.Lokotkov, Вы писали:
AL>Документ с описанием самих команд и того, чем они оперируют (боюсь сказать, "структур данных"), описывает архитектуру уровня системы команд или что-то другое? Если что-то другое, то что именно? Если все-таки архитектуру, то где там "стратегия" и как быть с тем, что там явно перечисляются и описываются операции и операнды, которые по сути являются интерфейсом процессора с окружением?
Документ с названием SPARCv8 ISA (Instruction Set Architecture) или подобным описывает архитектуру уровня системы команд. "Стратегия" в ней состоит в том, что это система команд RISC, и она не содержит команд арифметики, оперирующих с памятью. Там четко разделены команды память-регистр и регистр-арифметика, плюс зарезаны способы адресации, с целью упростить реализацию конвейера. Кроме того, в SPARCv8 ISA присутствует регистровое окно, которое имеет целью снизить оверхэд на передачу параметров при системных вызовах (окно сдвигается при вызове процедуры, эмулируя стек). Эта система команд придумана не от балды, а является результатом многолетних исследований в Berkley.
Это архитектурные решения, затрудняющие реализацию суперскаляра, между прочим. В MIPS ISA сделано лучше — там асинхронное умножение, позволяющее наложить умножение на другие операции, плюс — там нет операций с признаком результата, что сокращает глубину арифметики при реализации и позволяет при прочих равных получить большую тактовую частоту.
G>>Детальным дизайном в случае микропроцессора являются внутренние алгоритмы работы блоков. Скажем, описание алгоритма работы шедулера инструкций, выполняющих выборку независимых по регистрам инструкций в окне просмотра. Или логическая структура и алгоритмы кэша L1. Эти описания алгоритмов настолько далеко от реализации в Verilog, что является именно дизайном.
AL>Мне удобнее называть это уровнем микроархитектуры, который реализует систему команд неким способом и состоит из неких блоков, связанных так-то и так-то и выполняющих такие-то функции. Каким именно образом -- см. раздел/документы, относящиеся к "детальному дизайну".
Это традиционно называется уровнем микроархитектуры, и мы не будем ломать эту традицию. Я тебе назвал это "дизайном" с целью иллюстрации своих определений. Сам же привел пример процессоров?
AL>>>Поэтому в повседневном труде мы считаем архитектуру сочетанием структуры системы и множества отношений между элементами структуры, в котором реализуются не внешние требования к системе, а функции, позволяющие удовлетворить некие требования.
G>>При таком взгляде на вещи и получается закономерный результат, который ты описал выше.
AL>У кого получается? Вообще получается? У нас довольно сносно получается вроде бы.
Я аккуратно сформулировал фразу . Получается у тех, кого ты имел в виду описав ситуацию выше .
G>>При такой трактовке "архитектура" неотличима от дизайна, что значит, что стратегические вопросы просто выпадают из под контроля. Ничего оригинального и полезного в этой трактовке я не вижу.
AL>Архитектура в моем понимании является продуктом разработки (на оригинальность не претендую). Нашим пользователям пофиг, есть или нет в системе архитектура, но нам, разработчикам, которым придется сопровождать и совершенствовать систему (или даже целый класс систем), далеко не пофиг. Поэтому "потребителем" архитектуры являемся мы сами, и воплощается она в конкретных документах и коде, а не только и не столько в стратегических вопросах.
Это не определение архитектуры, а декларации некоторых ее свойств. Декларация правильная. Но не определение. Много что является продуктов разработки, на который пользователям пофиг. "Человек — есть существо двуногое и бесперое". Кто сказал? Знаешь, что ему ответили? "Ощипанный петух — вот человек Платона".
G>>Полгода — это, во первых, далеко не копейки, если взять ассоциированные расходы и упущенную прибыль (часто задержка на полгода может стоить провала всего проекта), а во-вторых, с циклом в полгода существуют только прототипы или наколенные поделки, для которых не надо вообще заморачиваться понятием архитектуры.
AL>Ну, что ж делать, надо же кому-то и наколенными поделками заниматься (скажем, новыми изделиями в рамках существующей продуктовой линейки или небольшими системами в рамках проектной программы)
Новые изделия в рамках существующей линейки — не наколенные поделки. И полгода — это далеко не пофиг.
G>>Слово "архитектура" имеет смысл употреблять, когда цикл развития и поддержки продукта измеряется годами, и/или работает на ним больше одной рабочей группы в 5-6 человек.
AL>Т.е. при семи годах и смешанной группе из 12 человек таки имеет смысл употреблять.
При семи годах не имеет смысл употреблять "цикл жизни — полгода". Ваша архитектура — в семи годах, а не в тех "полгода", которые вы готовы прощелкать. Стратегия — это не полгода.
G>>Кстати, употребленный тобой термин "фреймворк" — это к архитектуре относится. Архитектурным решением является сам факт наличия фреймворка, а также структура фреймворка и граница между ним и прикладной логикой. Фреймворк является одной из базовых технологий, только своей собственной, а не сторонней разработки.
AL>Если бы было что-то готовое, удовлетворяющее нашим требованиям, наверное взяли бы готовое. А появился фреймворк в процессе разработки в виде одного из системных слоев и представляет он собой почти не претендующий на оригинальность стейт-машинный движок, координирующий работу разных подсистем так, что они ничего не знают друг о друге, а движок -- об их функциональных особенностях. Подсистема при этом -- вполне конкретное и ни капли не метафорическое понятие. Мне хочется продолжать считать, что сей фреймворк является одним из основных элементов архитектуры, лежащей в основе наших систем. Как и слой абстракции окружения, позволяющий одним взмахом генерить бинари и запускаться под Windows, QNX, RTOS-32, Windows CE и CMX-RTX. Ну хочется, и всё тут, ничего не могу с собой поделать
Да, фреймворк и есть элемент архитектуры, о чем я с самого начала и говорил.
G>>Ну, "от себя скажу" ((с) thesz), что автором понятия "детальный дизайн" является небезызвестный Уотс Хамфри, автор модели CMMI. Ты тоже не только со мной споришь, это не я придумал.
AL>Я не ставлю под сомнение ценность понятия "детальный дизайн". Более того, стандарт IEEE 1016-1998 IEEE Recommended Practice for Software Design Descriptions, можно сказать, является настольной брошюрой
Ой, ну право слово лень разбираться .
AL>В общем, готов признать, что с точки зрения принятой сейчас практики, я, видимо, неправильно/напрасно рассматриваю дизайн и архитектуру, как сущности одного порядка. Но по-другому у меня не получается .
Учиццо надо. Тем более что все просто до тупизны. Фреймворк у вас есть? Это архитектура. Его использование — дизайн. То, что не детальный дизайн, конечно
Re[27]: Просветите про роль требований в проектировании, пли
Здравствуйте, Аноним! А>Как жаль, что эту тягомотину кроме нас никто больше не читает. Очень интересно, сколько человек встало бы на вашу точку зрения. С другой стороны, никто не лезет с соплями и слюнями. Пусть уж лучше не читают.
Это да. Кстати, а я тут причём — это всё Ожегов
А>Плясать можно без меня. Какие еще тут Ожоговы и Задорновы? Определения были древним грекам известны. Определить — значит провести границу: то, что тут — это оно, а то, что там — уже не оно. Понятия, например, именно так и определяются.
Гыг. Вот это я и называю дилетантскими плясками с языком, когда "Определить — значит провести границу", ибо так очевидно. Что вы скажете насчёт английских вариантов — definition vs limitation? de и finita. definition — разокончать, т.е. разограничивать? А понятия — это то что и так понятно? Аккуратнее
Вы ведь не лингвист — шо ж вы прям напрашиваетесь, чтоб вас грубо осадили? Насчёт грамотности — именно грамотность и не даёт соглашаться, когда человек несёт чушь, аргументируя это "это очевидно", "я так вижу", и "давайте сосредоточися на главном".
А>... Дизайн именно это и делает — ограничивает архитектуру. Если сказано — подчеркивание зигзагом как в ворде, IE уже не используешь. Альтернатива — выбирать архитектуру без учета дизайна. Тогда архитектура будет ограничивать интерфейс. Сказано — IE, значит никаких вам "как в ворде".
Гммм... боюсь у нас и здесь проблемы будут. Первым в этом топике привёл определеия Gaperton: Архитектура — это организация ядра (фреймворк и т.п.) + архитектурные решения типа "используем СУБД" и "пишем на .net"
дизайн — это описание разбиения системы на компоненты, детальный дизайн — алгоритмы и структуры данных.
Чтобы не перевирать — ссылка:http://www.rsdn.ru/forum/message/3290920.1.aspx
Как дизайн может ограничивать архитектуру — хз. Возможно у вас есть ваши определения, но я их не увидел.
В вашем примере у вас есть требования к UI — отражать ошибки волнистым подчёркиванием. Как оно налагает ограничения на дизайн и архитектуру системы? В дизайне у нас фигурирует EditWorkspace, реализация которого ничего общего с дизайном не имеет. Логика проверки формул и прочая мура живёт в каком-нить FormulaValidator и привязывается к UI обёртками, которые ничего ценного в себе не содержат. Замена IE на scintilla приведёт к изменению внутренностей EditWorkspace и никак не повлияет на остальную часть системы. Как здесь архитектура/дизайн ограничивает интерфейс или ui ограничивает архитектуру/дизайн?
Вы видите только часть возможных решений — всегда есть альтернатива. Кстати, в IE вполне можно хостить WinForms (или Word) ч/з ActiveX.
Риск выбора технологии реализации есть конечно, но в нём нет ничего особенного. Это совершенно рядовой риск, которым надо управлять точно так же, как риском потерять сотрудника, риск утери данных, риск некорректного дизайна и так далее.
А>Мы говорим о приоритетах. У кого больше приоритет — у дизайна или архитектуры — тот другого и ограничивает. У требований приоритет самый высший, они ограничивают все остальное. У кода — наименьший, это значит, что код уже ничего сам не будет ограничивать.
Вы опять о ограничениях — зачем сюда приплетать приоритеты? Потому что слово красивое?
На самом деле не так всё просто. И код может поограничивать требования — их может оказаться слишком дорого/сложно реализовать, например невинное требование распознавание жестов мышью может вылиться в забавные танцы с нейронными сетями.
Меня слегка раздражает то, что вы описываете подход, который сложился _у вас_ как универсальный, что так должно быть на самом деле и что так делать правильно. При этом, возникает такое ощущение, имеете смутное представление о особенностях процесса разработки, но не боитесь высказывать своё мнение — как с лингвистикой.
А>Утверждения у вас появились совсем недавно. Вот это хорошее утверждение: "Я утверждаю что UI в идеале не должен никак влиять на архитектуру и архитектура в идеале должна допускать произвольную логику взаимодействия с пользователем". Я соглашаюсь, но возражаю против попыток вывести из этого тезиса практические универсальные правила для организации проектов: этот идеал недостижим для большого класса ПО. Хуже всего, что он непредсказуемо недостижим.
Да писал я об этом и раньше. И что подобная универсальность задаром не достаётся и что без специальных телодвижений ничего не получится... Вообще-то всё предсказуемо и достижимо — думать только надо а не тупо реализовывать требования
А>Я болею за частное образование, где каждый выбирает по вкусу. Кто хочет — фундаментальное образование, кто хочет — государственно-сертифицированное, кто хочет — православное и католическое. Параллелей с обсуждаемой темой не вижу, предлагаю не офтопить, пока никто не вмешивается.
Гммм... Очень модно кстати. Эдак постмодернистки — каждый имеет право получать образование какое он хочет. Кстати, а работу каждый имеет право получать какую хочет? Ребят, раз уж государство вбухивает в образование деньги, осуществляет надзор и всё такое — в ответ должны получаться специалисты а не астрологи, нет?
Параллель — "архитектура на все случаи жизни" vs "заказчик выбирает архитектуру по вкусу". Передёргиваю, но что-то в этом есть...
Кто вмешается — попросим вынести только ветку, не бойтесь
Представляю себе студента медфака, что не ходит в анатомичку, не учит названия костей и латынь...
Мдя
P.S. Кстати, кто наблюдает за этим цирком — отметьтесь как-нить, чтоб знали что мы не одни
Re[6]: Просветите про роль требований в проектировании, плиз
S>Да-да, уже легче Вообще-то вопрос был о том, почему два-три товарища так настойчиво утверждают, что "архитектура — функция от требований". Пока ответ -"расхождение в определениях". Остались смутные сомнения — может товарищей всё-таки посетило дао?
Это "дао" — древняя, испытанная штука (как и положено быть дао). Называется оно: "проектирование сверху-вниз".
лэт ми спик фром май харт
Re[7]: Просветите про роль требований в проектировании, плиз
Здравствуйте, Sinix, Вы писали:
S>Что вы скажете насчёт английских вариантов — definition vs limitation?
Зачем я буду что-то говорить? Посмотрите сюда: http://www.etymonline.com/index.php?term=define (иногда браузер глючит и надо выделить текст)
Латинское слово definire, от которого через французский, пошло define, переводят на современный английский как "to limit". Больше я на эту тему ничего не скажу, ибо незачем.
А>>... Дизайн именно это и делает — ограничивает архитектуру. Если сказано — подчеркивание зигзагом как в ворде, IE уже не используешь. Альтернатива — выбирать архитектуру без учета дизайна. Тогда архитектура будет ограничивать интерфейс. Сказано — IE, значит никаких вам "как в ворде".
S>Гммм... боюсь у нас и здесь проблемы будут. Первым в этом топике привёл определеия Gaperton: Архитектура — это организация ядра (фреймворк и т.п.) + архитектурные решения типа "используем СУБД" и "пишем на .net" S>дизайн — это описание разбиения системы на компоненты, детальный дизайн — алгоритмы и структуры данных. S>Чтобы не перевирать — ссылка:http://www.rsdn.ru/forum/message/3290920.1.aspx
S>Как дизайн может ограничивать архитектуру — хз. Возможно у вас есть ваши определения, но я их не увидел.
Я отдаю должное приоритету Gaperton'а в деле определения давно известных понятий. Но если вы посмотрите в мое первое сообщение, вы увидите, что я употребил там слово "UI". Это сознательно: дизайн — очень общее понятие, и точный смысл зависит от контекста. Употребив вначале UI, я задал контекст, и слово "дизайн" везде по тексту относится к дизайну UI, если явно не написано иное. А смысл того, что написал про дизайн Gaperton, зависит от контекста, заданного им. По-моему, это элементарно.
S>В вашем примере у вас есть требования к UI — отражать ошибки волнистым подчёркиванием. Как оно налагает ограничения на дизайн и архитектуру системы? В дизайне у нас фигурирует EditWorkspace, реализация которого ничего общего с дизайном не имеет. Логика проверки формул и прочая мура живёт в каком-нить FormulaValidator и привязывается к UI обёртками, которые ничего ценного в себе не содержат. Замена IE на scintilla приведёт к изменению внутренностей EditWorkspace и никак не повлияет на остальную часть системы. Как здесь архитектура/дизайн ограничивает интерфейс или ui ограничивает архитектуру/дизайн?
Я не буду придираться к формулировкам. Я просто напишу: вы рассуждаете как практик, или как теоретик? На практике решения такого уровня как "Замена IE на scintilla", это очень тяжелые решения. Теряется много времени, команда демотивируется (нет хуже ничего, как выбрасывать отлаженный код не по своей воле), а когда программист три раза поменяет компоненты туда-сюда, вы никогда его уже не переубедите, что вы ПМ, а не гавно.
S>Вы видите только часть возможных решений — всегда есть альтернатива. Кстати, в IE вполне можно хостить WinForms (или Word) ч/з ActiveX.
Можно на потолке спать. Можно передавать хэндл окна через командную строку в локальный КОМ-сервер, чтобы через WM_COPYDATA откачивать данные назад. Все можно. Но не нужно.
S>Риск выбора технологии реализации есть конечно, но в нём нет ничего особенного. Это совершенно рядовой риск, которым надо управлять точно так же, как риском потерять сотрудника, риск утери данных, риск некорректного дизайна и так далее.
Я уже сказал, что риск есть только в вашем подходе. В моем риска нет ВООБЩЕ, насколько это возможно. И я не понимаю, зачем идти на риск, когда можно сесть, продумать, и идти гарантированно приводящей к цели тропинкой.
А>>Мы говорим о приоритетах. У кого больше приоритет — у дизайна или архитектуры — тот другого и ограничивает. У требований приоритет самый высший, они ограничивают все остальное. У кода — наименьший, это значит, что код уже ничего сам не будет ограничивать.
S>Вы опять о ограничениях — зачем сюда приплетать приоритеты? Потому что слово красивое?
Потому, что от приоритета зависит, кто кого ограничивает.
S>На самом деле не так всё просто. И код может поограничивать требования — их может оказаться слишком дорого/сложно реализовать, например невинное требование распознавание жестов мышью может вылиться в забавные танцы с нейронными сетями.
Никто не говорит, что просто. Я написал это уже, и второй раз писать не хочу. На сегодня все, остальное потом.
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, mrTwister!
T>>Это "дао" — древняя, испытанная штука (как и положено быть дао). Называется оно: "проектирование сверху-вниз".
S>Эммм... и как оно пересекается с "архитектура — функция от требований"?
Интерфейс с требованиями — это и есть верхний уровень программы. Таким образом, проектирование сверху-вниз — означает проектирование от интерфейса к реализации. По сути, тему спора можно переформулировать как: "Top-down vs bottom-up".
Здравствуйте, mrTwister.
T>Интерфейс с требованиями — это и есть верхний уровень программы. Таким образом, проектирование сверху-вниз — означает проектирование от интерфейса к реализации. По сути, тему спора можно переформулировать как: "Top-down vs bottom-up".
Гммм вы что под интерфейсом понимаете? Потому что в классическом Top-down:
Top-down approaches emphasize planning and a complete understanding of the system. It is inherent that no coding can begin until a sufficient level of detail has been reached in the design of at least some part of the system.
Переводить или сами? От требований к архитектуре — это классический Bottom-up approach. Поэтому и удивлялся. Вы уж читайте матчасть перед тем как делать утверждения. Иначе некрасиво получается.
Так что пусть уж тема останется как есть.
Re[29]: Просветите про роль требований в проектировании, пли
Здравствуйте, Аноним...
S>>Что вы скажете насчёт английских вариантов — definition vs limitation?
А>http://www.etymonline.com/index.php?term=define (иногда браузер глючит и надо выделить текст) А>Латинское слово definire, от которого через французский, пошло define, переводят на современный английский как "to limit". Больше я на эту тему ничего не скажу, ибо незачем.
По вашей же ссылке:
Definite (1553) means "defined, clear, precise, unmistakable;
...
Definition is recorded from 1645 as a term in logic; the "meaning of a word" sense is from 1551.
Аккуратней с мухлежом — про "переводят на современный английский как "to limit"" в оригинале ничего нет. В первых предложениях говорится о значении исходных слов, не новообразованного. Говорил же, не лингвист — не лезь!
А>... слово "дизайн" везде по тексту относится к дизайну UI, если явно не написано иное. А смысл того, что написал про дизайн Gaperton, зависит от контекста, заданного им. По-моему, это элементарно.
Ок, про дизайн не говорим, только о UI. Впрочем и раньше-то не говорили.
S>>В вашем примере у вас есть требования к UI — отражать ошибки волнистым подчёркиванием. Как оно налагает ограничения на дизайн и архитектуру системы? В дизайне у нас фигурирует EditWorkspace, реализация которого ничего общего с дизайном не имеет. Логика проверки формул и прочая мура живёт в каком-нить FormulaValidator и привязывается к UI обёртками, которые ничего ценного в себе не содержат. Замена IE на scintilla приведёт к изменению внутренностей EditWorkspace и никак не повлияет на остальную часть системы. Как здесь архитектура/дизайн ограничивает интерфейс или ui ограничивает архитектуру/дизайн?
А>...На практике решения такого уровня как "Замена IE на scintilla", это очень тяжелые решения. Теряется много времени, команда демотивируется (нет хуже ничего, как выбрасывать отлаженный код не по своей воле), а когда программист три раза поменяет компоненты туда-сюда, вы никогда его уже не переубедите, что вы ПМ, а не гавно.
Ага. Т.е. то что я выше описал — это тяжёлое решение?
Уже писалось — задача выбора технологии реализации не относится к области проектирования. Они затрагивают друг друга, но выбор технологии — это скорее вопрос управления рисками. У вас ведь IE хостился как контрол? Следовательно чисто теоретически он не должен влиять на основную часть программы — которая занималась проверкой формул. Если у вас получилось иначе — это либо результат оценки риска (стоимость исправления в случае неверного выбора у вас получалась ниже стоимости грамотного проектирования), либо упущенный риск либо отсутствие управления проектом вообще.
По-прежнему не видно вашего комментария о моём варианте решения/обоснования чем ваш подход лучше.
А>Я уже сказал, что риск есть только в вашем подходе. В моем риска нет ВООБЩЕ, насколько это возможно. И я не понимаю, зачем идти на риск, когда можно сесть, продумать, и идти гарантированно приводящей к цели тропинкой.
Вы неправильно понимаете значение термина "риск" в управлении проектами. Рассматривайте риск как документированную проблему. Например в вашем случае был бы документ "Оценка архитектуры", где было бы явно указано, что архитектуры как таковой нет, что любое неожиданное требование может привести к выбросу большого объёма написанного кода и демотивации команды (именно в таком чернушном стиле оно бы и было написано). Но! Этот риск нам не страшен, потому что он происходит в таких-то и таких-то случаях и мы приняли такие-то и такие-то меры чтобю этот риск не случился. Дальше шла бы оценка альтернативных вариантов реализации и обоснование принятого решения.
ТО, что вы не производите оценку рисков, не означает их отсутствия.
А>Потому, что от приоритета зависит, кто кого ограничивает.
S>>На самом деле не так всё просто. И код может поограничивать требования — их может оказаться слишком дорого/сложно реализовать, например невинное требование распознавание жестов мышью может вылиться в забавные танцы с нейронными сетями.
А>Никто не говорит, что просто. Я написал это уже, и второй раз писать не хочу. На сегодня все, остальное потом.
Ну а фига вы тогда становитесь в позу и на пять листов размазываете дискуссию о сферических конях в вакууме?!! У вас, в вашем частном случае, стоимость изменения UI обходится дороже чем реализация всей основной части. Это может быть обусловлено постановкой процесса, некачественной архитектурой, спецификой проекта (в глаза не видел, чтобы такое было, но пусть будет) и кучей объективных факторов о которых вы не говорите ничего. Сказали бы так — честь вам и хвала, соглашусь и посочуствую.
Так нет, вы упрямо твердите, что UI определяет архитектуру а само определяется требованиями потому что требования приоритетнее UI, UI приоритетнее архитектуры, а архитектура приоритетнее кода. Когда вам пытаются показать, что это _вы_ так расставляете приоритеты и возможны другие решения (заметьте, в начале я старался отвечать макисмально терпимо), вы начинаете проявлять недюжинные способности к лингвистическому анализу
Сорри, сорвался. Надоедает впустую аргументировать свою точку зрения, а потом обнаружить, что собеседник не владеет элементарными познаниями в обсуждаемой теме и маскирует это под обобщением собственного опыта. Я тоже так делаю Но подтвержлаю ссылками и не ленюсь переуточнять и преспрашивать, чтобы убедиться что говорим об одном и том же. Посчитайте сколько постов мы убили чтобы убедить вас что "определять" и "ограничивать" — суть разные вещи?
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, mrTwister.
T>>Интерфейс с требованиями — это и есть верхний уровень программы. Таким образом, проектирование сверху-вниз — означает проектирование от интерфейса к реализации. По сути, тему спора можно переформулировать как: "Top-down vs bottom-up".
S>Гммм вы что под интерфейсом понимаете?
То, как программа выглядит и ведет себя с точки зрения внешнего мира.
S>Потому что в классическом Top-down: S>
S>Top-down approaches emphasize planning and a complete understanding of the system. It is inherent that no coding can begin until a sufficient level of detail has been reached in the design of at least some part of the system.
S>Переводить или сами?
Какая разница, что top-down акцентирует, а что нет? Речь идет о сути. И к чему ты привел этот кусок текста? Какое он имеет отношение к обсуждаемому вопросу? Логичнее было бы привести эту цитату:
A top-down approach is essentially breaking down a system to gain insight into its compositional sub-systems. In a top-down approach an overview of the system is first formulated, specifying but not detailing any first-level subsystems. Each subsystem is then refined in yet greater detail, sometimes in many additional subsystem levels, until the entire specification is reduced to base elements. A top-down model is often specified with the assistance of "black boxes" that make it easier to manipulate. However, black boxes may fail to elucidate elementary mechanisms or be detailed enough to realistically validate the model.
Интерфейс — это верхний уровень системы. Требования обычно являются частью интерфейса, соответственно они тоже находятся на верхнем уровне.
S>От требований к архитектуре — это классический Bottom-up approach.
Да нет, проектирование архитектуры в отрыве от требований, полагаясь только на "здравый смысл" и умозрительную модель доменной области — это как раз bottom-up. Ты сначала проектируешь более нижний уровень: "идеальную" модель предметной области. И лишь потом поднимаешься на уровень выше до требований и интерфейса, пытаясь придумать, как вписать их в уже готовый нижний доменный уровень. Из твоей же ссылки:
In a bottom-up approach the individual base elements of the system are first specified in great detail. These elements are then linked together to form larger subsystems, which then in turn are linked, sometimes in many levels, until a complete top-level system is formed.
Здравствуйте, mrTwister, Вы писали:
T>Интерфейс — это верхний уровень системы. Требования обычно являются частью интерфейса, соответственно они тоже находятся на верхнем уровне.
Речь идет о пользовательском интерфейсе?
А если его нет, то нет требований?
Здравствуйте, samius, Вы писали:
S>Здравствуйте, mrTwister, Вы писали:
T>>Интерфейс — это верхний уровень системы. Требования обычно являются частью интерфейса, соответственно они тоже находятся на верхнем уровне. S>Речь идет о пользовательском интерфейсе? S>А если его нет, то нет требований?
Речь идет о том, как программа выглядит и ведет себя с точки зрения внешнего мира.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>Здравствуйте, mrTwister, Вы писали:
T>>>Интерфейс — это верхний уровень системы. Требования обычно являются частью интерфейса, соответственно они тоже находятся на верхнем уровне. S>>Речь идет о пользовательском интерфейсе? S>>А если его нет, то нет требований?
T>Речь идет о том, как программа выглядит и ведет себя с точки зрения внешнего мира.
Допустим что некий сервис отслеживает изменения в файловой системе и логирует их в БД. Давайте разбираться, кто есть пользователь (БД штоли?) и через какой интерфейс этот пользователь работает с программой? И какое отношение к этому интерфейсу имеют требования к этой программе?
T>>Речь идет о том, как программа выглядит и ведет себя с точки зрения внешнего мира. S>Допустим что некий сервис отслеживает изменения в файловой системе и логирует их в БД. Давайте разбираться, кто есть пользователь (БД штоли?) и через какой интерфейс этот пользователь работает с программой? И какое отношение к этому интерфейсу имеют требования к этой программе?
Где ты увидел в моем сообщении слово "пользователь"?
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, samius, Вы писали:
T>>>Речь идет о том, как программа выглядит и ведет себя с точки зрения внешнего мира. S>>Допустим что некий сервис отслеживает изменения в файловой системе и логирует их в БД. Давайте разбираться, кто есть пользователь (БД штоли?) и через какой интерфейс этот пользователь работает с программой? И какое отношение к этому интерфейсу имеют требования к этой программе?
T>Где ты увидел в моем сообщении слово "пользователь"?
Я намеренно переспросил, хотел уточнить. А ты не ответил.
Ладно, уберем слово "пользователь", вернемся к тезисам
Интерфейс — это верхний уровень системы. Требования обычно являются частью интерфейса, соответственно они тоже находятся на верхнем уровне.
в контексте описанной мной программы. Будут комментарии, или сделаешь акцент на "обычно являются частью интерфейса"?
Здравствуйте, mrTwister.
S>>Гммм вы что под интерфейсом понимаете?
T>То, как программа выглядит и ведет себя с точки зрения внешнего мира.
T>Какая разница, что top-down акцентирует, а что нет? Речь идет о сути. И к чему ты привел этот кусок текста? Какое он имеет отношение к обсуждаемому вопросу? Логичнее было бы привести эту цитату:
[поскипано]
Где там говорится хоть что-то об интерфейсах и требованиях? "In a top-down approach an overview of the system is first formulated" куда больше подходит к модели предметной области и архитектуре, чем к дизайнерским наброскам UI.
T>Интерфейс — это верхний уровень системы. Требования обычно являются частью интерфейса, соответственно они тоже находятся на верхнем уровне.
Опять то же самое... Слушайте, а вы не виртуал Анонима случаем? Те же определения, взятые с потолка, невнимание к цитатам, ответы в духе "Какая разница, что top-down акцентирует, а что нет? Речь идет о сути" и стремление запутать термины. Почитайте :)
S>>От требований к архитектуре — это классический Bottom-up approach. T>Да нет, проектирование архитектуры в отрыве от требований, полагаясь только на "здравый смысл" и умозрительную модель доменной области — это как раз bottom-up.
T>Ты сначала проектируешь более нижний уровень: "идеальную" модель предметной области. И лишь потом поднимаешься на уровень выше до требований и интерфейса, пытаясь придумать, как вписать их в уже готовый нижний доменный уровень.
Это чисто ваша расстановка акцентов. В Wikipedia ясно сказано, что при проектировании снизу-вверх система рассматривается как набор невзаимосвязанных компонентов, каждый из которых решает конкретную задачу, а общая система, которая их кое-как объединяет, появляется только потом:
In a bottom-up approach the individual base elements of the system are first specified in great detail. These elements are then linked together to form larger subsystems, which then in turn are linked, sometimes in many levels, until a complete top-level system is formed.
Гы... вас надо в тот топик цитатить. Никогда бы не подумал, что высокоуровневую архитектуру можно рассматривать как "индивидуальные несвязанные элементы". Более того,
However, "organic strategies" may result in a tangle of elements and subsystems, developed in isolation and subject to local optimization as opposed to meeting a global purpose.
Прямо говорит об отсутствии некоторой общей модели.
Не мухлюйте больше. И перестаньте уводить топик в сторону. Хотите холиварить о своём незнании терминов — заводите топик, присоединюсь.
Кстати, вы тоже за образование по выбору учащегося? //Это я так, для статистики.
Здравствуйте, samius, Вы писали:
S>Я намеренно переспросил, хотел уточнить. А ты не ответил.
Я считал очевидным, что пользователь является частью "внешнего мира", и что это не единственная его часть.
S>Ладно, уберем слово "пользователь", вернемся к тезисам S>
S>Интерфейс — это верхний уровень системы. Требования обычно являются частью интерфейса, соответственно они тоже находятся на верхнем уровне.
S>в контексте описанной мной программы. Будут комментарии, или сделаешь акцент на "обычно являются частью интерфейса"?
С точки зрения внешнего мира, нас сервис выглядит так: "Если сделать N изменений в файловой системе то в базе данных появятся N новых записей". Как записи появляются в БД, внешнему миру не важно — хоть святым духом. Если для внешнего мира важна пропускная способность (количество изменений в секунду), то сервис, удовлетворяющий этим требованиям уже будет выглядеть немного иначе, а именно: "Если сделать N изменений в файловой системе за время T1, то в течении времени T2 в базе данных появятся N новых записей".
S>Где там говорится хоть что-то об интерфейсах и требованиях?
Нигде. Про Agile, RUP, DDD там тоже ничего не говорится.
S>"In a top-down approach an overview of the system is first formulated" куда больше подходит к модели предметной области и архитектуре, чем к дизайнерским наброскам UI.
Почему?
T>>Ты сначала проектируешь более нижний уровень: "идеальную" модель предметной области. И лишь потом поднимаешься на уровень выше до требований и интерфейса, пытаясь придумать, как вписать их в уже готовый нижний доменный уровень.
S>Это чисто ваша расстановка акцентов. В Wikipedia ясно сказано, что при проектировании снизу-вверх система рассматривается как набор невзаимосвязанных компонентов, каждый из которых решает конкретную задачу, а общая система, которая их кое-как объединяет, появляется только потом:
S>
In a bottom-up approach the individual base elements of the system are first specified in great detail. These elements are then linked together to form larger subsystems, which then in turn are linked, sometimes in many levels, until a complete top-level system is formed.
S>Гы... вас надо в тот топик цитатить. Никогда бы не подумал, что высокоуровневую архитектуру можно рассматривать как "индивидуальные несвязанные элементы".
При чем тут "высокоуровневая архитектура"?. Речь идет не о том, нужна она, или нет, а о том, что первично при её проектировании: умозрительная модель домена, или интерфейс.
S>Более того,
S>
S>However, "organic strategies" may result in a tangle of elements and subsystems, developed in isolation and subject to local optimization as opposed to meeting a global purpose.
S>Прямо говорит об отсутствии некоторой общей модели.
Ни о чем это не говорит. Просто твоя модель домена будет одним из элементов, который "developed in isolation" и прикручен постфактум проволокой к интерфейсу.
S>Кстати, вы тоже за образование по выбору учащегося? //Это я так, для статистики.
Я за мир во всем мире.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>Ладно, уберем слово "пользователь", вернемся к тезисам S>>
S>>Интерфейс — это верхний уровень системы. Требования обычно являются частью интерфейса, соответственно они тоже находятся на верхнем уровне.
S>>в контексте описанной мной программы. Будут комментарии, или сделаешь акцент на "обычно являются частью интерфейса"?
T>С точки зрения внешнего мира, нас сервис выглядит так: "Если сделать N изменений в файловой системе то в базе данных появятся N новых записей".
Так это и есть интерфейс? или требование? T>Как записи появляются в БД, внешнему миру не важно — хоть святым духом.
Это мы и не обсуждаем.
T>Если для внешнего мира важна пропускная способность (количество изменений в секунду), то сервис, удовлетворяющий этим требованиям уже будет выглядеть немного иначе, а именно: "Если сделать N изменений в файловой системе за время T1, то в течении времени T2 в базе данных появятся N новых записей".
Я правильно понимаю, что удовлетворение требования в этом случае влияет на интерфейс?
Здравствуйте, samius, Вы писали:
S>Здравствуйте, mrTwister, Вы писали:
T>>Здравствуйте, samius, Вы писали:
S>>>Ладно, уберем слово "пользователь", вернемся к тезисам S>>>
S>>>Интерфейс — это верхний уровень системы. Требования обычно являются частью интерфейса, соответственно они тоже находятся на верхнем уровне.
S>>>в контексте описанной мной программы. Будут комментарии, или сделаешь акцент на "обычно являются частью интерфейса"?
T>>С точки зрения внешнего мира, нас сервис выглядит так: "Если сделать N изменений в файловой системе то в базе данных появятся N новых записей". S>Так это и есть интерфейс? или требование?
Требование, если явно специфицировано, является частью интерфейса.
S>Я правильно понимаю, что удовлетворение требования в этом случае влияет на интерфейс?
Да. Интерфейс определяет не только набор операций, а скорее контракт, в который также входят обязательства всех сторон.
Здравствуйте, mrTwister, Вы писали:
T>Здравствуйте, samius, Вы писали:
S>>Я правильно понимаю, что удовлетворение требования в этом случае влияет на интерфейс? T>Да. Интерфейс определяет не только набор операций, а скорее контракт, в который также входят обязательства всех сторон.
И нефункциональные тоже?
У нас довольно сносно получается вроде бы.
.
