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

А>Sshur, во многом согласен, но во это:

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

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

Бизнес растет, расширяется. Появляются новые услуги, старые исчезают. Либо автоматизируются области, ранее нетронутые автоматизацией. Примеры нужны?

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

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

S>Бизнес растет, расширяется. Появляются новые услуги, старые исчезают. Либо автоматизируются области, ранее нетронутые автоматизацией. Примеры нужны?

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

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

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


S>Ну дык мы о разных сценариях говорим. Вы — об изменении структуры сущностей из-за изменения требований заказчика. Ясен пень, что они будут постоянно меняться, если требования типа "информация о заказчике должна отображаться следующим образом: Фамилия И.О. ..." хардкодятся в классы/структуры хранения.

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

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

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

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

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

S>Не часто, но все же меняется. Вот, возвращаясь к упомянотому выше ОПСОС'у. Конкуренты поджали, пришлось вводить "любимые номера", потом льготный роуминг — вот и появились новые сущности в самой предметной области. Я даже не представляю, как тут отделить модель от бизнес логики

Лехко. Абстракцией, сепарацией и изоляцией в дурдом А вообще, лучше не смешивать теорию и практику — хуже всем будет.

Как самый примитивный вариант (не учитывая нюансы предметной области — чревато косяками):

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

Как к такому подходу можно прийти, если танцевать от священности требований "пользователь может пользоваться льготными звонами на 3 выбранных им номера (стоимость ххх независимо от длительности звонка) и роумингом (стоимость увеличивается на yyy каждые zzz секунд начиная с ttt)" — я даже не представляю.

Ваша очередь объяснять

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


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

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

S>Как к такому подходу можно прийти, если танцевать от священности требований "пользователь может пользоваться льготными звонами на 3 выбранных им номера (стоимость ххх независимо от длительности звонка) и роумингом (стоимость увеличивается на yyy каждые zzz секунд начиная с ttt)" — я даже не представляю.

S>Ваша очередь объяснять

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

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

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

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

S>Наверно надо как-то более подробно описать данную схему, потому что я все равно не представляю, как изолировать БЛ от доменной модели. Модель от логики еще можно, а вот наоборот... Как можно что-то посчитать, если ты ничего не знаешь о том, что считаешь? Например, если брать тех же сотовых операторов — вот мне надо посчитать, на какую сумму наговорил абонент в месяц. На входе имеем список звонков вида (номер, время начала, длительность). Как должна в таком случае выглядеть логика расчета стоимости, изолированная от модели (то есть она ничего не должна знать об абонентах, звонках и номерах)?

Логике достаточно знать об интерфейсе модели. Вот простой пример из жизни: например, российские представления об идентификации человека это ФИО, в то время, как в США это ИФ, а в средней азии это И ибн О ибн [ИмяДеда] ибн [ИмяПрадеда], а в Древнем Риме praenomen-nomen-cognomen, и т.д. Поэтому когда такие люди имеют дело с российским законодательством им тяжело, приходится реализовывать интерфейс ФИО, порой довольно убого. Но законодательство(БЛ) не меняется под таких людей. Только изредка, из-за очень веских причин(например, если бы отчества окончательно утратили реальное употребление).

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

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

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

S>>Наверно надо как-то более подробно описать данную схему, потому что я все равно не представляю, как изолировать БЛ от доменной модели. Модель от логики еще можно, а вот наоборот... Как можно что-то посчитать, если ты ничего не знаешь о том, что считаешь? Например, если брать тех же сотовых операторов — вот мне надо посчитать, на какую сумму наговорил абонент в месяц. На входе имеем список звонков вида (номер, время начала, длительность). Как должна в таком случае выглядеть логика расчета стоимости, изолированная от модели (то есть она ничего не должна знать об абонентах, звонках и номерах)?

N>Логике достаточно знать об интерфейсе модели.

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

N> Вот простой пример из жизни: например, российские представления об идентификации человека это ФИО, в то время, как в США это ИФ, а в средней азии это И ибн О ибн [ИмяДеда] ибн [ИмяПрадеда], а в Древнем Риме praenomen-nomen-cognomen, и т.д. Поэтому когда такие люди имеют дело с российским законодательством им тяжело, приходится реализовывать интерфейс ФИО, порой довольно убого. Но законодательство(БЛ) не меняется под таких людей. Только изредка, из-за очень веских причин(например, если бы отчества окончательно утратили реальное употребление).

Ну да. Только этот пример как раз мою мысль подтверждает Тут разные модели подстраиваются под одну логику. Логика имеет четко прописанный инферфейс идентификации человека по ФИО, и вдруг оказывается, что в некоторых случаях это не так. Я к тому и вел, что выделять в качестве фреймворка интерфейс модели как что-то неизменяемое в общем случае нельзя, так как он тоже меняется. Хотя, в определенных случаях это будет возможно, если реализуется коммерческий проект для хорошо изученной области, где 90% организаций работают по одной схеме с незначительными отклонениями. В моей области — логистике и транспортных перевозках — такого нет пока У всех свои тарифы и правила

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

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

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

S>Ну да. Только этот пример как раз мою мысль подтверждает Тут разные модели подстраиваются под одну логику. Логика имеет четко прописанный инферфейс идентификации человека по ФИО, и вдруг оказывается, что в некоторых случаях это не так. Я к тому и вел, что выделять в качестве фреймворка интерфейс модели как что-то неизменяемое в общем случае нельзя, так как он тоже меняется. Хотя, в определенных случаях это будет возможно, если реализуется коммерческий проект для хорошо изученной области, где 90% организаций работают по одной схеме с незначительными отклонениями. В моей области — логистике и транспортных перевозках — такого нет пока У всех свои тарифы и правила

Я считаю это только проблемой реализации. Т.е. даже в вашем случае, возможно подойдёт интерфейс(ну я так, примерно, я ж не специалист) IПеревозка{ Список сущностей (характеристика+ее количественное значение)}, а тарифы получают этот список и выводят или сумму, или факт, что данных о перевозке недостаточно.

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

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

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

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

S>Наверно надо как-то более подробно описать данную схему, потому что я все равно не представляю, как изолировать БЛ от доменной модели. Модель от логики еще можно, а вот наоборот... Как можно что-то посчитать, если ты ничего не знаешь о том, что считаешь?

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

S>Непонятно, что именно объяснять. Как получить архитектуру на основании требований? Это примерно та же задача, что и как построить самолет, имея ТТХ. Либо нужен опыт разработчиков, которые построили уже не один самолет и представляют в общем как он должен выглядеть (если не требуется каких-то революционных изменений), либо, если опыта нет, итеративный процесс.

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

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

Ну, собсно это и спрашивалось с самого начала. Если качество выходного продукта не важно — то нет смысла говорить о архитектуре, требованиях, надёжности и т.п. С другой стороны несколько странно, что в методологии, которая по идее стержень проекта и главная надежда, можно рассматривать вопросы разработки со стороны снижения стоимости изменений, но не рассматривать вопросы надёжности, качества и всего такого. Это ведь тоже вопрос управления. Не появится ведь совершенная архитектура из ничего, верно? А если проектирование ещё и мешает процессу разработки — то точно не появится

S>ХП кстати, дает больше других — там говорится — берем требования, реализуем самым простым образом.
Ога. Получаем быстро и сердито штуку, сильно заточенную под конкретный набор юз-кейсов. Изменение в логике, которые по идее могли быть изолированы в одном методе, расползаются по всему проекту. Но это не страшно, ибо после вкуривания конспекта шаманских обрядов нам уже глубоко пофиг, что и как чинить Всю ответственность — на заказчика ибо сам виноват — сам выбрал таких разработчиков. Just do 'em all

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

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

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

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

На практике оно конеш выглядит совсем-совсем не так — нюансы, пнимаешь. Но начинать с этого можно.

Any comments?

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

S>Не с той стороны мыслите Смысл такого разделения — защита _модели_ от требований заказчика. Начнёте смещивать — закончите реализацией конкретных требований конкретных дядей.

Хороший подход А как быть, если тебе деньги платят именно за реализацию конкретных требований конкретных дядей? Говорить, что их требования потребуют изменения модели, и поэтому реализованы не будут?

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

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


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

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

Но если хочется пофлеймить, то ИМХО особенности есть, но не принципиальные. Вы по NG никогда тайны авиакатастроф не смотрели? Самолеты падают из-за отказа маленьких деталей типа задвижки люка, помню даже интересный случай — из-за замерзания гидравлического клапана у пилота получалась инверсия управления.


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

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

S>>ХП кстати, дает больше других — там говорится — берем требования, реализуем самым простым образом.
S>Ога. Получаем быстро и сердито штуку, сильно заточенную под конкретный набор юз-кейсов. Изменение в логике, которые по идее могли быть изолированы в одном методе, расползаются по всему проекту. Но это не страшно, ибо после вкуривания конспекта шаманских обрядов нам уже глубоко пофиг, что и как чинить Всю ответственность — на заказчика ибо сам виноват — сам выбрал таких разработчиков. Just do 'em all

no comments, ибо непонятна посылка. Если ХП применять по всем правилам, то не будет расползания логики по всему проекту, так как это нетестируемо. В любом случае, главнее профессионализм людей, чем используемая методология. Другое дело, что профессионализм и методология кореллированы между собой, начинающая команда скорее всего не использует никакой процесс, в опытной скорее всего какой-то процесс поставлен.


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

S>Начать можно с очень и очень многого. Самый примитив — почитать старых умных товарищей, что жили в доисторические времена, когда даже методологий не было и попробовать подумать головой. Чтобы система долго-долго жила и работала, нужен какой-никакой костяк, архитектура, модель — называйте как хотите. Зачем оно надо — сиё есть тайное знание, недоступное никому.

Это как раз опыт. Либо свой, либо приобретенный из книг.


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

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


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

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

S>Дальше вам придётся каким-то боком преобразовать модель к виду, который совместим с требованиями заказчика, определить базовые интерфейсы (если CRUD не хватает), и собсно напоследок — реализовать правила что хочет заказчик. Поскольку правила работают через интерфейсы и работают поверх общей модели — шансов поломать что-либо у вас меньше на порядки.

Пусть будет так. А о чем мы спорим?

S>Пусть будет так. А о чем мы спорим?

А хто его знает... выдохлись товарищи... надо сразу было к наездам на конкретные методологии переходить и троллей приманивать. Хз-хз....

S>Хороший подход А как быть, если тебе деньги платят именно за реализацию конкретных требований конкретных дядей? Говорить, что их требования потребуют изменения модели, и поэтому реализованы не будут?
...
S>Мне честно говоря непонятно ваше стремление говорить заказчику, что и как надо делать. Пусть даже на основании вашего более глубокого знания предметной области.

Да ни боже мой! Оно мне надо — рассказывать заказчику про его работу?
Мне кажется естественным когда заказчик понимает чего он хочет и понимает во что ему и разработчикам становятся его _необоснованные_ прихоти. Замечу, по конкретным проблемам непонимания никогда не возникает — это надо, это укладывается в логику — сделаем! На абстрактные "хацю" не стоит подписываться — себе дороже.

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

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

Да пребудут с вами компромиссы, в общем

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

В описанном сценарии сама идея правил рассчёта уже есть. Остаётся реализовать конкретное правило. Что совсем не просто. Да, здесь будут грабли. Но остальную систему они не затронут.

Если надо прям щас — IT-отдел тупо пишет новый класс FavoriteNumberDiscount/хранимку/представление — где оно там считается, регает как новое правило, прогоняет тесты, штампуется грязный гуй с подхватыванием автоматом. Это если рассчёт идёт офлайном. Если рассчёт идёт в процессе регистрации и требователен к ресурсам — добавляется реальная попа с перебалансировкой индексов по таблицам или с развёртыванием аппсерверов из резерва — что дешевле.

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

S>Я аналогию возводил к постановке задачи — там на мой взгляд все так же, требования никак архитектуру под собой не подразумевают. Есть данные о скорости, дальности полета, грузоподъемности итд — а сколько крыльев и двигателей, и какие они будут — не важно. Лишь бы ТТХ соблюдалось.

Ну... не совсем так в общем.
1. Риски, вложения и материальная ответственность на порядки порядков выше. А общая сложность сопоставима со средним софтварным проектом.
2. Лётные характеристики заказчиков не колышат. Точнее есть определённые пороговые значения (которые определяются классом создаваемой техники, а не заказчиком) и экономическая эффективность — вот она-то заказчиков и интересует.
3. В авиастроении нет крупных заказчиков, чтобы создавать штучный самолёт с рюшечками, тонированными жалюзями на движках и "чтоб подпрыгива в такт рингтону". Есть мейнстрим. Он проектируется КБ компании (аутсорсинг на таких тяжёлых проектах очень недешёвая штука, особенно в плане последствий). Затем проект по отдельным системам обкатывается на производственной базе компании (заметьте, КБ учитывает её возможности). Затем куча испытаний/доделок (если где и можно говорить об итеративности — так это здесь). Но всё это выполняется на базе мощностей одной компании/одного холдинга. И только после выхода в серию слетаются заказчики — чтобы попросить нарисовать свой лейбл и салфеточки на спинки повесить. Не более того.

S>Угу, методология — надежда заказчика получить результат.
Убили вы мои надежды ;(

S>no comments, ибо непонятна посылка. Если ХП применять по всем правилам, то не будет расползания логики по всему проекту, так как это нетестируемо.
Мне казалось, что логика не должна расползаться по несколько другим причинам... Кстати расползание логики не всегда очевидно. Ибо тестируются отдельные сценарии, а связи между ними — не такая уж и очевидная штука.

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

P.S. Надо менять ник. На что-то, что с Ъ начинается, наверное...

P.P.S. Да, TOGAF и еже с ним несколько зациклены на архитектуре бизнес-процессов или мне так показалось?

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

S>Т.е. архитектура — есть функция требований. Это аксиома.

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

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

Гыг... А умные люди пишут всякие книжки, MVC, MVP всякие придумывают... Проще надо быть, проще

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

[skipped]
6 основных частей:

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

DAL. Обслуживает все запросы к СУБД. Поскольку кэш про DAL ничего не знает, может быть заменён в любой момент.

Контроллеры. Каждый из них хранит состояние (выделенные элементы и т.п.), выставляет наружу методы-действия и информацию о том, можно ли дёргать конкретный метод в конкретном состояни или нет. Основная магия живёт здесь

Точка доступа. Обычно это простой static class, через свойства которого можно образащаться к кэшу/DAL/контроллерам.

Гуй. По функционалу разбивается небольшое число областей. Обычно мы стараемся сделать так, чтобы одному контроллеру соответствовал 1 workspace. Каждая область обычно реализуется как user control (но это как повезёт ). У каждой области есть свой набор BindingSource|CollectionViewSource, напрямую прибинденный к кэшу. К одному и тому же набору сущностей может быть прибиндено несколько источников — почему бы и нет? Поскольку контроллеры ничего не знают о гуе — можно использовать любой фреймворк/контролы/компоновку/etc

Code behavior. Легковесная обёртка, которая в ответ на события гуя дёргает контроллер и в ответ на изменение состояния контроллера изменяет гуй.

Естественно, я здесь не привожу особенностей реализации — пальцы отвалятся. Интересно — продолжим.

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

P.S. Чем ещё меряться будем?

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

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

S>Гыг... А умные люди пишут всякие книжки, MVC, MVP всякие придумывают... Проще надо быть, проще
...
S>Слегка отличается от "разработку UI вынести в отдельный процесс, более приоритетный", ага? Как думаете, какое приложение проживёт дольше и потребует меньше изменений при самых бредовых требованиях?

Я искренне люблю MVC, но это не панацея. Простой пример: V оказывается настолько сложно, что у него появляется своя внутренняя архитектура. Допустим, есть данные в M, которые надо показать как чарт. Что будем делать? Купим компонент? Используем Excel через OLE Automation? Набросаем сами? Во, сколько вариантов! И попробуй узнай, на каком из них надо остановиться, пока не обдумаешь интерфейс во всех деталях, и не обкатаешь его на фокус-группе, хотя бы из коридора.

Другой пример, из жизни. Юзера говорят — хотим интерфейс, как в MSO. На дворе — 2002 год (? Точно не помню, плюс-минус год). Дотнет уже есть, но библиотек к нему, дающих такой интерфейс, нет. Infragistics то ли еще не появился, то ли в этой версии страшен, как смертный грех. Приложение создавалось без учета этого пожелания, на pure C#, потому, что архитектор так захотел (а хрен ли — требования-то все выполняются, и более-менее точно). На очередном этапе конкуренты все встроили MSO look like, кто — за счет BCG, кто — компонентами к Дельфе. Пришел черед дотнетной аппликухи, MSO-подобие из вариации на тему ГУЯ превратилось в требование. Начались песни "архитектура не позволяет". И сколько-то там еще лет не позволяло. А поговорили бы с юзверями, перед тем, как проектировать архитектуру, показали им наброски, услышали — "ребята, сделайте нам красиво, как в ворде", глядишь — и до .Net 2.0 сидели бы на MFCях.

Трямс Анониму.

А>Я искренне люблю MVC, но это не панацея.
+5 за понимание. То что я привёл — это вообще хз что — эдакая помесь мвц с тушканодинозавром. Никто специально не изобретал — шамо приползло (с).

A>Простой пример: V оказывается настолько сложно, что у него появляется своя внутренняя архитектура. Допустим, есть данные в M, которые надо показать как чарт. Что будем делать? Купим компонент? Используем Excel через OLE Automation? Набросаем сами? Во, сколько вариантов! И попробуй узнай, на каком из них надо остановиться, пока не обдумаешь интерфейс во всех деталях, и не обкатаешь его на фокус-группе, хотя бы из коридора.

Хз. Этот вопрос более к управлению рисками имхо — т.е. мы имеем такие-то грабли, последствия такие-то, вероятность такая-то, стоимость исправления такая-то. Всегда идти на поводу у тов пользователей и делать сегодня сайт а завтра пылесос... Тем не менее в вашем примере я бы постарался изолировать проблему — чтобы её решение не затрагивало остальную часть системы. Будете смеяццо, но в принципе решаемо даже при описанном подходе — отображение живёт в UI и code behavior — всё остальное не ломается (я не говорю о сервере, ему вообще параллельно). Excel кстати как ActiveX компоненту можно захостить... //ужас-ужас...

А>Другой пример, из жизни. Юзера говорят — хотим интерфейс, как в MSO. На дворе — 2002 год...

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

dmoz пишет:
>
> V_S>Тут, видишь ли, нехилая проблема заключается в том, что 99%
> *менеджеров*, занимающихся планированием продаж и производства этих
> самых табуреток, /совершенно наплевать/ на инженерные аспекты реализации
> табуретки. У них, как правило, основные требования — "Дешевле! Еще
> дешевле! Быстрее! Еще быстрее! Прямо сейчас, а еще лучше — еще вчера!
> Главное — продать! Быстрее!". В таких условиях, разумеется, берем абы
> как сделанные заготовки, и — сколачиваем их гвоздями на скорую руку....
> Ну и получаем табуретку соответствующего качества.
>
> Эти требования не придуманы просто так, а продиктованы потребностями
> рынка. Проблема скорее в отсутствии понимания инженерами потребностей
> бизнеса (таких понимающих, к сожалению, единицы), и, как следствие,
> отсутствие альтернативных предложений, вместо тупой поставки кривой
> табуретки.
В итоге, плюнул я на всех нонешних делателей мебели и сам ее делаю для
себя. Все одно они мебель нынче делают не лучше, чем мы проги (как же,
потребности рынка: "мы уже продали, а вы еще не начинали?").

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

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

S>Хз. Этот вопрос более к управлению рисками имхо — т.е. мы имеем такие-то грабли, последствия такие-то, вероятность такая-то, стоимость исправления такая-то. Всегда идти на поводу у тов пользователей и делать сегодня сайт а завтра пылесос... Тем не менее в вашем примере я бы постарался изолировать проблему — чтобы её решение не затрагивало остальную часть системы. Будете смеяццо, но в принципе решаемо даже при описанном подходе — отображение живёт в UI и code behavior — всё остальное не ломается (я не говорю о сервере, ему вообще параллельно). Excel кстати как ActiveX компоненту можно захостить... //ужас-ужас...

S>Опять-таки — это больше проблема управления рисками чем проблема некорректного проектирования архитектуры. Как вы там сейчас с 2к7-м офисом? Его гуй тоже эмулировать приходится? Соболезную — с такой жосткой конкуренцией, чтобы всё решалось градиентом тулбаров, не сталкивался.

Моя формула девелопмента: требования >> UI >> архитектура >> код. Значок >> значит одновременно две вещи: Направление Движения и Намного Более Высокий Приоритет. А управление рисками — часть управления проектами.

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

А>Моя формула девелопмента: требования >> UI >> архитектура >> код. Значок >> значит одновременно две вещи: Направление Движения и Намного Более Высокий Приоритет. А управление рисками — часть управления проектами.

Таак... что-то я не понимаю... у вас код приоритетней всего? Кодинг как самоцель?

Завидую глубине и фундаментальности ваших заблуждений Хотя... Что такое у вас "архитектура" — может у нас просто несовпадение в терминологии?

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

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

А>>Моя формула девелопмента: требования >> UI >> архитектура >> код. Значок >> значит одновременно две вещи: Направление Движения и Намного Более Высокий Приоритет. А управление рисками — часть управления проектами.

S>Таак... что-то я не понимаю... у вас код приоритетней всего? Кодинг как самоцель?

В физике я встречал такое обозначение: "при a >> b". Это значило, что а не просто больше, а намного больше b. "Намного" взято в курсив как нестрогий термин.

Таким образом, начинать надо со сбора требований. (Частный случай: интерфейс или архитектура являются требованиями сами по себе). Затем — разработать интерфейс, который решает ВСЕ требования. И только потом — думать об архитектуре. А уж код должен соответствовать всем документам, что были написаны в ходе первых трех этапов.

S>Завидую глубине и фундаментальности ваших заблуждений Хотя... Что такое у вас "архитектура" — может у нас просто несовпадение в терминологии?

Не глуюже, чем "меньше" с "больше" перепутать.

Упс... по ходу иронию восприняли как наезд... Сорри.
С другой стороны — надо ж как-то поднимать тему.

А>>>Моя формула девелопмента: требования >> UI >> архитектура >> код. Значок >> значит одновременно две вещи: Направление Движения и Намного Более Высокий Приоритет. А управление рисками — часть управления проектами.
...
А>В физике я встречал такое обозначение: "при a >> b". Это значило, что а не просто больше, а намного больше b. "Намного" взято в курсив как нестрогий термин.

Так у вас "Намного Более Высокий Приоритет" или "а не просто больше, а намного больше b"? Вы уж определитесь пожалуйста.

А>Таким образом, начинать надо со сбора требований. (Частный случай: интерфейс или архитектура являются требованиями сами по себе). Затем — разработать интерфейс, который решает ВСЕ требования. И только потом — думать об архитектуре. А уж код должен соответствовать всем документам, что были написаны в ходе первых трех этапов.

Откройте для себя водопадную модель уже что ли
Ворос на засыпку. Если уж у вас гуй определяет архитектуру системы (если мы под архитектурой понимаем одно и то же) — то к чему приведёт необходимость использовать другие отчёты/список вместо грида/дублирование вызовов через меню/кнопки?

P.S. Если вы УЖЕ решили все требования без архитектуры — зачем она вам теперь? Избавьтесь от неё