Re[5]: Просветите про роль требований в проектировании, плиз
От: Sinix  
Дата: 13.02.09 08:04
Оценка:
Здравствуйте, Aikin
A>Спорить-то есть о чем, вот только я не вижу смысла в этом споре. Мы уж слишком с разных сторон подходим к проблеме. (перечитай два последних моих поста по теме, если будут новые мысли, то вполне может подискутировать)

Дык согласен... если не читали с самого начала — я там только смиренно спрашивал, всё ли я правильно понимаю. Это потом я разошёлся, когда появилось мнение что UI приоритетнее архитектуры.

Но всё равно согласитесь приятно было поспорить — теперь вижу конкретные точки расхождения.

Спасибо!
Re[15]: Просветите про роль требований в проектировании, пли
От: Aikin Беларусь kavaleu.ru
Дата: 13.02.09 08:22
Оценка: 6 (1) +1
Здравствуйте, Sinix, Вы писали:

Не хотел быть толкователем чужих идей, но:

S>ПоеСтраница 61. Глава 8 "Базовые принципы":

S>

S>Бизнес должен быстро определять, каким образом система будет полезной для него, и он должен возвращать разработчикам эти сведения в течение дней или недель, но не в течение месяцев или лет.

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

Во вторых, какое именно "непредвиденное"?
Изменение требований -- однозначно "виноват" заказчик и дело хорошей команды, чтобы он пострадал как можно меньше.
Система работает совсем не так как ожидалось -- то же самое, вам каждые 2 недели вам поставлялись результаты итерации, кто вам мешал их просматривать (как я уже сказал, айджаил здесь уже не работает).
"Непредвиденные" баги -- виноваты разработчики.
Система работает не в соответствии с требованиями -- виноваты разработчики.


Пойми простую истину: Только Заказчик знает что именно ему нужно. (то что он часто не может это сформулировать -- другое дело).

S>

S>Приемлемая простота — необходимо решать каждую проблему так, как если бы ее можно было решить самым смехотворно простым способом. Времени, которое вы экономите на решении 98% проблем, для которых это утверждение является истинным, вполне хватает, чтобы справиться с решением оставшихся 2% проблем.
S>...
S>В рамках установившихся традиций мы приучены к тщательному планированию своих действий, мы привыкли проектировать код с расчетом на его дальнейшее повторное использование. Однако в рамках ХР огромные
S>усилия ... прикладываются для того, чтобы сегодня программист думал о решении только сегодняшних проблем и был уверен в том, что завтра в случае необходимости имеющийся код можно будет с легкостью усовершенствовать так, как этого требует складывающаяся ситуация. Экономика разработки программ, представленная в виде набора нескольких вариантов, приветствует данный подход.

S>Эти 98% "решённых" проблем висят дамокловым мечом — от них не избавились, их просто "замазали" временным решением — о чём собственно и написано. Кстати я не так уж и уверен насчёт соотношения 98/2.
S>Особенно понравился пассаж про не надо рассчитывать на дальнейшее использование и про приветствующую это дело экономику. Так и хочется постебаться про "код на выброс" — некорректно, а хочется ведь...
Каким Домокловым мечем? Если простой код перестает справляться со своими обязанностями, он переписывается (возможно даже полностью) в следующий простой код, который уже может решить проблему.
По поводу "неоходимо решать проблему ... самым смехотворно простым способом", если подойти с "размахом" и реализовать все "по книжкам", то:
1) велик шанс, что мы потратим время зря (код так и не будет никогда переиспользован)
2) от него будет тяжело отказаться в случае когда он начнет мешать.

S>Страница 66:

S>

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

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

S>

Как все кочевники, члены команды ХР должны привыкнуть путешествовать налегке. Они не должны брать в свое путешествие слишком многого — в багаже не должно оставаться ничего, за исключением того, что необходимо для удовлетворения нужд заказчика, то есть тестов и кода.

S>А вот вам и долгожданный отказ от архитектуры — она не необходима для "удовлетворения нужд заказчика".
Спешишь. Архитектура удовлетворяет нуждам кода и тестов: Без модульности у нас не получиться протестировать. Без соответствующего дизайна код будет слишком сложен.

S>Ниже, на стр 91 (Глава 11 • Как это работает? — простой дизайн):

S>

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

S>Это действительно всё, за счёт чего гарантируется качество дизайна?
А этого мало?

Часто и этого нет:
1) разработчики не привыкли перерабатывать свой код -- код пестрит костылями и хотфиксам
2) (с метафорами у меня туго) нету единого видения системы всеми разработчикми -- каждый лепит свое, не похожее на дригое (в том числе и то что ты сам писал раньше)
3) (перекликается с 2) + то что просто для меня может быть очень сложно для моего партнера и наоборот

А вообще, что можно к этим пунктам добавить такое, чтобы этого небыло в Айджел команде?

S>О архитектуре упоминается аж на 145-й странице из 212 (Глава 17 • Стратегия проектирования). Порадовало:

S>

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

S>На этом собсно про архитектуру всё
Нет, не так: "на этом собсно про слово архитектура всё"

S>Порадовало как в книге мягко обошли тему про фреймворки (стр 200. Глава 26 — ХР в работе):

S>

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

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

S>Вообще XP агрессивно заточена под решение проблем "здесь и сейчас" без гарантий в будущем. Тоже конеш подход...

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


СУВ, Aikin

P.S. Боюсь получился слишком большой пост. И смысл размазан. И кроме Sinix-а его мало кто прочитает (ослилт )
Re[16]: Просветите про роль требований в проектировании, пли
От: Sshur Россия http://shurygin-sergey.livejournal.com
Дата: 13.02.09 08:28
Оценка: 1 (1) :)
Здравствуйте, Aikin, Вы писали:



A>СУВ, Aikin


A>P.S. Боюсь получился слишком большой пост. И смысл размазан. И кроме Sinix-а его мало кто прочитает (ослилт )



Осилил и подписываюсь почти под каждым утверждением
Шурыгин Сергей

"Не следует преумножать сущности сверх необходимости" (с) Оккам
Re[16]: Просветите про роль требований в проектировании, пли
От: Aikin Беларусь kavaleu.ru
Дата: 13.02.09 08:30
Оценка:
Здравствуйте, Ziaw, Вы писали:

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

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

СУВ, Aikin
Re[16]: Просветите про роль требований в проектировании, пли
От: Sinix  
Дата: 13.02.09 08:32
Оценка:
Здравствуйте, Ziaw!

S>>Вообще XP агрессивно заточена под решение проблем "здесь и сейчас" без гарантий в будущем. Тоже конеш подход...

Z>Гарантия там в том, что несмотря ни на что, проект все время будет работать. И стоимость внесения изменений будет примерно ленейна...
Z> Для таких случаев и придуман XP, можно ругать его безоглядное применение, можно ругать его апологетов за излишнюю религиозность, но факт есть факт, есть ниша, где XP работает лучше (заказчик и исполнитель более удовлетворены результатом проекта).
Насколько я понимаю там идёт хитрая магия — стоимость остаётся линейной за счёт взаимодобивающих методик, которые сами по себе эффективны на ограниченном круге задач и эти задачи довольно удачно пересекаются с аутсорсингом/заказным ПО (особенно хорошо оно сочетается с оплатой за работу а не за результат).

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

Если есть какие-то более серьёзные работы, которые подробно расписывают методики и объясняют почему оно работает независимо от веры в них — с удовольствием прочитаю. То же относится и ко всем остальным религиям — что там у нас модно кроме MSF 4|RUP|Scrum?

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


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

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

Заметь, я не кричу, что DDD — наше всё, а только говорю что DDD предлагает более объективный подход к построению архитектуры, т.к. старается сгладить влияние требований. В ответ постоянно идёт что-то вроде "архитектура не так важна как требования" и "вы никогда не построите стабильную архитектуру на основе требований". Это нормальный разговор?

Z>Оффтоп, наблюдение:

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

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

Удачи!
Re[17]: Просветите про роль требований в проектировании, пли
От: Ziaw Россия  
Дата: 13.02.09 08:55
Оценка: 5 (1) +1
Здравствуйте, Sinix, Вы писали:

S>Если есть какие-то более серьёзные работы, которые подробно расписывают методики и объясняют почему оно работает независимо от веры в них — с удовольствием прочитаю. То же относится и ко всем остальным религиям — что там у нас модно кроме MSF 4|RUP|Scrum?

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

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


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

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


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

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


DDD это не методолгия разработки, это подход к архитектуре. Я пока не вижу как DDD может сгладить влияние требований. Т.к. требования часто очень круто влияют на модель.

S>В ответ постоянно идёт что-то вроде "архитектура не так важна как требования" и "вы никогда не построите стабильную архитектуру на основе требований". Это нормальный разговор?


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

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


Кто-то пропагандирует "плохо организованную архитектуру"? Aikin очень правильную мысль тебе пытается донести: архитектура должна быть предельно проста. А ты ее трактуешь как отказ от архитектуры вообще.
... << RSDN@Home 1.2.0 alpha 4 rev. 0>>
Re[16]: Просветите про роль требований в проектировании, пли
От: Sinix  
Дата: 13.02.09 09:16
Оценка:
Ух ты — после всех "давай закончим" мы всё ещё продолжаем. Кто же первый сдастся?...

A>P.S. Боюсь получился слишком большой пост. И смысл размазан. И кроме Sinix-а его мало кто прочитает (ослилт )

Я упёртый — я ослилт. Поехали!

A>Во первых, этот принцип -- то без чего не может состояться ни один Айджаил проект. Нет тесного контакта с заказчиком -- нет айджила.

Ёк — кто ж спорит то? За "заказчик на месте" — я всеми конечностями за. Как и за тестирование в должных дозах, постоянные сборки и т.п.

A>Изменение требований -- однозначно "виноват" заказчик и дело хорошей команды, чтобы он пострадал как можно меньше.

...
A>Пойми простую истину: Только Заказчик знает что именно ему нужно. (то что он часто не может это сформулировать -- другое дело).

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

A>Каким Домокловым мечем? Если простой код перестает справляться со своими обязанностями, он переписывается (возможно даже полностью) в следующий простой код, который уже может решить проблему.

A>По поводу "неоходимо решать проблему ... самым смехотворно простым способом", если подойти с "размахом" и реализовать все "по книжкам", то:
A>1) велик шанс, что мы потратим время зря (код так и не будет никогда переиспользован)
A>2) от него будет тяжело отказаться в случае когда он начнет мешать.

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

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

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

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

S>>

Как все кочевники, члены команды ХР должны привыкнуть путешествовать налегке. Они не должны брать в свое путешествие слишком многого — в багаже не должно оставаться ничего, за исключением того, что необходимо для удовлетворения нужд заказчика, то есть тестов и кода.

S>>А вот вам и долгожданный отказ от архитектуры — она не необходима для "удовлетворения нужд заказчика".
A>Спешишь. Архитектура удовлетворяет нуждам кода и тестов: Без модульности у нас не получиться протестировать. Без соответствующего дизайна код будет слишком сложен.
Дыкть код у вас максимально простой и в любой момент может быть заменён вместе с "дизайном" (что они под ним понимают ???) — какая тут архитектура? Тут получается что архитектура — функция от кода а не наоборот.

S>>

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

S>>Это действительно всё, за счёт чего гарантируется качество дизайна?
A>А этого мало?
Тут идёт обычная подмена понятий — "простой дизайн" рассматривается как антитеза "глупому". Следовательно "простой" дизайн == "умный" дизайн.
Этого мало. Потому что пока у вас не будет в тасклисте красным маркером "пиши красиво, сын мой — или цих с гвоздями!" — никто ничего не будет делать. Любая система изменяется по пути наименьшего сопротивления. Чудес бесплатно не бывает. И пока вы явно не озаботитесь вопросами качества кода и архитектуры — никто их за вас не решит. Вообще зачем я пишу эту тривиальшину? неужели это так неочевидно?

S>>Появление универсальных компонентов после нескольких лет постоянных переработок дизайна??? До меня обычно доходит раньше

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

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


S>>Вообще XP агрессивно заточена под решение проблем "здесь и сейчас" без гарантий в будущем. Тоже конеш подход...

A>А какие гаранттии дает твой подход? Тоже никаких кроме "если система будет развиваться так-то и так-то, то". У гибких подходов одно приемущество: они получат готовое решение раньше и они готовы, в отличии от тебя, его изменять.

Гмг. Я нигде не говорил ни слова о "моём подходе". Только приводил определённые решения в ответ на вопросы в духе "раз такой умный, расскажи как правильно" (ни разу не про вас — даже не думайте ). Что у вас сложилось в результате — я даже боюсь подумать. Поверьте я здесь ни при чём.

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

Я где-то писал о невозможности изменений архитектуры? Или о невозможности реализаций новых требований? Я тоже могу начать комментировать ваше мнение о сепулении сепулек. Но не будем

Ухх... пора завязывать — пожалейте сервер. Мировая?
Re[6]: Просветите про роль требований в проектировании, плиз
От: samius Япония http://sams-tricks.blogspot.com
Дата: 13.02.09 09:38
Оценка: 12 (1) +1
Здравствуйте, Sinix, Вы писали:

S>Здравствуйте, Aikin

A>>Спорить-то есть о чем, вот только я не вижу смысла в этом споре. Мы уж слишком с разных сторон подходим к проблеме. (перечитай два последних моих поста по теме, если будут новые мысли, то вполне может подискутировать)

S>Дык согласен... если не читали с самого начала — я там только смиренно спрашивал, всё ли я правильно понимаю. Это потом я разошёлся, когда появилось мнение что UI приоритетнее архитектуры.


S>Но всё равно согласитесь приятно было поспорить — теперь вижу конкретные точки расхождения.


S>Спасибо!


Редкий спор на RSDN оканчивается на такой ноте
Респект обоим!

(Часто приходится наблюдать как точки расхождения используются для закладывания атомного фугаса, чтоб пыли не осталось от оппонента )
Re[17]: Просветите про роль требований в проектировании, пли
От: Aikin Беларусь kavaleu.ru
Дата: 13.02.09 09:55
Оценка:
Здравствуйте, Sinix, Вы писали:

S>Ух ты — после всех "давай закончим" мы всё ещё продолжаем.

Так это совсем другое дело.

S>Кто же первый сдастся?...

Я уже сдался.

Я не вижу с твоей стороны желания понять о чем же я говорю. Вижу только желание поспорить.
Re[18]: Просветите про роль требований в проектировании, пли
От: Sinix  
Дата: 13.02.09 10:01
Оценка:
Ёк... мы ходим по кругу...
Z>У меня сложилось впечатление, что единственно правильной ты считаешь примерно такую методологию: сбор всех требований, детальная разработка архитектуры с закладыванием на дальнейшее расширение и вероятное измененение требований. Только потом наступает этап кодирования.

Неа Про планирование — как то так (ни разу не уверен в корректности):

Выделение предметной области, получение модели, отображение сущностей, правил, связей и функционирования предметной области на модель данных.
Параллельно: Анализ бизнес-требований, перевод их в терминологию предметной области, построение функциональной модели как набора операций над моделью данных, проектирование отображение модели данных в наборы сущностей БЛ. Заметьте, что данные системы могут (и скореке всего будут) отличаться от данных, обрабатываемых в отдельных юз-кейсах. Где-то вы работаете со всеми личными данными, где-то достаточно ф.и.о, а где-то ф.и.о — просто часть другой сущности, например "сотрудник". В любом случае БЛ работает с отображением одних и тех же данных, но никак не с самими данными и (не дай бог) не дублирует одну и туже информацию.
Параллельно: Анализ требований к продукту, выделение базовых подсистем, выбор технологий реализации — на основе модели предметной области.
Параллельно: Допиливание инструментария/методологии (если требуется).

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

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

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

И никакой магии




[поскипано]

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

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

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

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

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

Уххх...

Как бы попрощее.
Когда заказчик от вас чего-то требует — он ведь это не просто так хочет, нет? Его требования — следствие изменений в деятельности заказчика или следствие того, что вы не пошлностью отразили в продукте эту деятельность. Если смотреть на деятельность только через требования — изменения в требованиях кажутся бессистемными, сегодня хотят одно — завтра доугое и т.п. Если смотреть с точки зрения заказчика — ситуация абсолютно другая. Поменялись правила игры, следом меняются требования а эти [censored] по-прежнему живут в прошлом квартале и удивляются "а чего это нужны новые отчёты — всё ж работает".

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

Я не знаю как подробней разжевать эту идею — не гений Спрашивайте конкретно — попробую конкретно ответить.

P.S. Изчезло до понедельника. Не скучайте
Re[7]: Просветите про роль требований в проектировании, плиз
От: Sinix  
Дата: 13.02.09 10:03
Оценка:
S>Редкий спор на RSDN оканчивается на такой ноте

Ага, мы такие, только никак не успокоимся... Са-анита-а-ар!!!

P.S. Уже почти ушло
Re[19]: Просветите про роль требований в проектировании, пли
От: Ziaw Россия  
Дата: 13.02.09 10:55
Оценка: +2
Здравствуйте, Sinix, Вы писали:

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

S>Параллельно: Анализ бизнес-требований, перевод их в терминологию предметной области, построение функциональной модели как набора операций над моделью данных, проектирование отображение модели данных в наборы сущностей БЛ. Заметьте, что данные системы могут (и скореке всего будут) отличаться от данных, обрабатываемых в отдельных юз-кейсах. Где-то вы работаете со всеми личными данными, где-то достаточно ф.и.о, а где-то ф.и.о — просто часть другой сущности, например "сотрудник". В любом случае БЛ работает с отображением одних и тех же данных, но никак не с самими данными и (не дай бог) не дублирует одну и туже информацию.
S>Параллельно: Анализ требований к продукту, выделение базовых подсистем, выбор технологий реализации — на основе модели предметной области.
S>Параллельно: Допиливание инструментария/методологии (если требуется).

Все верно, ты понимаешь, что нельзя плясать только от предметной области и доменной модели и параллельно анализируешь требования к продукту. Только что-то мешает тебе признать, что требования к продукту превичны. Именно ими руководствуются при созданиии доменной модели. Ибо некий документ в предметной области в зависимости от требований к продукту может быть представлен как кортеж (№, автор) или как пдф или как набор версионированых документов со множеством связей.

[рассуждения о том, что все зависит от ситуации поскипаны как не несущие полезного]

S>У нас совсем разные понятия о том, что относить к архитектуре. Вы (как мне кажется) сильно упираете на требования как источник информации. Цель управления проектом — снижение стоимости адаптация под непредсказуемо изменяющиеся требования.


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


В этом и есть ваша ошибка, модель сильно зависит от требований и часто меняется вместе с ними.

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


Любая абстракция (а модель это абстракция) косвенно отражает действительность. Она включает в себя только те данные, которые нам требуются (от слова требования).

S>Как бы попрощее.

Проще:
Верное утверждение1: модель зависит от требований, предметной области и особенностей заказчика.
Верное утверждение2: требования зависят заказчика и предметной области.
Неверные утверждения: модель зависит только от предметной области, модель зависит только от требований, требования зависят только от предметной области.

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

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


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

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


Смотри пример про модель документа в начале сообщения. Если мы при тщательном анализе предметной области поймем, что документ на самом деле является версионированной сущностью с 200 сложными атрибутами и заложим эту модель, забив на то, что для нормального функционирования приложения интересено только количество подобных документов за месяц — мы потритим много лишних денег на реализацию этой модели, правила поведения документов. А самое дерьмовое, что мы заставим работников заказчика часами вбивать все эти данные в систему вместо одной паршивой цифры. С хорошей вероятностью никогда ими не воспользоваться в системе.
... << RSDN@Home 1.2.0 alpha 4 rev. 0>>
Re[14]: Просветите про роль требований в проектировании, пли
От: Аноним  
Дата: 13.02.09 22:13
Оценка: -1
Здравствуйте, Sinix, Вы писали:

S>Мои извинения Аноним'у, слегка отвык от адекватных собеседников... ужс-ужс...


А>>2. Можно показать на то, что я, по-вашему, невнимательно прочитал? Я перечитаю.

S>Изначально имелось ввиду моё непонимание стралочек (уже замяли ). Но можно притянуть за уши и мой коммент насчёт изоляции проблем с UI:
S>

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


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

— Зачем вы хостите Excel как ActiveX, Ватсон?
— Э-э..., Холмс, дружище, юзера сказали, что им надо кольцевую диаграмму.
— Так это же элементарно, Ватсон: возьмите Chart.Net (название, конечно, вымышлено). Зачем тащить целый Excel?
— Видите ли Холмс, наши представления могут расширяться только COM-объектами... Бэрримор не нашел на рынке ничего подходящего.
— А почему именно так?
— Тс-с-с! Наш директор, сэр Генри — фанат IUnknown'а и C++. Он избегает .Net'а, потому, что уверен, что тот тормозит.
— Ну и как, а Excel ему теперь не тормозит?
— А... Э...

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


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

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

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

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

Архитектура — о том, как правильно напихать в эти границы кода, чтоб получился настоящий айсберг. Конечно, тут есть свои нюансы. Допустим, чтобы устроить какую-нибудь малозаметную шишечку на поверхности, придется потратить уйму времени и дико усложнить содержание. Ну так на этапе архитектуры встает вопрос о том, что в дизайн закралась самоубийственная опция. Возможно, что дизайнеры поправят это дело, если это действительно левая фичка. А если нет? Если это ОЧЕНЬ важно? Тогда архитекторы стиснут зубы и пойдут ее бороть. Понимаете? А если бы дизайн не прорабатывался с бОльшим приоритетом, тогда этот вопрос ВООБЩЕ БЫ НЕ ВСТАЛ. А потом, когда стало ясно, что без этой фички на рынке делать нечего, начинается архитекторская истерика. Вы не думайте, что это из пальца высосано. Я бы не стал даже думать про какие-то там цепочки, типа "требования-UI-архитектура-код", если бы меня жизнь носом в них не натыкала сто раз.

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

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


Глупо — что? То, что вы перечислили, вполне может быть результатом проектирования UI. А может и не быть. Нужно на примерах разбирать.
Re[4]: Просветите про роль требований в проектировании, плиз
От: Gaperton http://gaperton.livejournal.com
Дата: 13.02.09 23:30
Оценка: 10 (1)
Здравствуйте, Sinix, Вы писали:

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

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

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

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

Определяем три термина. Архитектура, дизайн, детальный дизайн.

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

Дизайн и архитектуру часто путают.

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


Разумеется, надо принимать во внимание как требования, так и технические ограничения, так и ваши возможности (знаем Java — архитектура будет базироваться на Java а не дотнет). Будущие требования тоже имеют значение. Главное, архитектуру не путайте с дизайном. Думаю, как только вы мои определения почитали, вам уже все стало понятнее, не так ли? .
Re[5]: Просветите про роль требований в проектировании, плиз
От: A.Lokotkov Россия http://www.linkedin.com/pub/alexander-lokotkov/a/701/625
Дата: 15.02.09 08:17
Оценка: +1
Здравствуйте, Gaperton, Вы писали:

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


Странно. Берем IEEE 1471-2000 и читаем:
architecture:
The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.
Далее, если говорить простыми словами, авторы стандарта показывают, что архитектура системы по сути является представлениями системы в виде двух "ящиков": "черного" -- с точки зрения взаимодействия с окружением; и "прозрачного" -- с точки зрения взаимодействия элементов внутренней структуры.

G>Определяем три термина. Архитектура, дизайн, детальный дизайн.

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

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

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

G>Главное, архитектуру не путайте с дизайном. Думаю, как только вы мои определения почитали, вам уже все стало понятнее, не так ли? .


И как же их не путать то? Может, для пользы дела примем дизайн/детальный дизайн в качестве одного из архитектурных представлений?
bloß it hudla
Re[6]: Просветите про роль требований в проектировании, плиз
От: Gaperton http://gaperton.livejournal.com
Дата: 15.02.09 11:08
Оценка:
Здравствуйте, A.Lokotkov, Вы писали:

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


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


AL>Странно. Берем IEEE 1471-2000 и читаем:

AL>architecture:
AL>The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.
AL>Далее, если говорить простыми словами, авторы стандарта показывают, что архитектура системы по сути является представлениями системы в виде двух "ящиков": "черного" -- с точки зрения взаимодействия с окружением; и "прозрачного" -- с точки зрения взаимодействия элементов внутренней структуры.

Действительно странно. Особенно странно то, что многие "серьезные дядьки" либо не знакомы с этим определением, либо не ставят его во грошь. А теперь берем базовый архитектурный курс по MCSD, и читаем там совсем другое, до крайности мутное определение, которое я даже затрудняюсь воспроизвести. Берем PSP/TSP, и не находим там термина "архитектура" вовсе. Что делать будем? Откроем википедию:

The distinction from detailed design
Software architecture, also described as strategic design, is an activity concerned with global design constraints, such as programming paradigms, architectural styles, component-based software engineering standards, design principles, and law-governed regularities. Detailed design, also described as tactical design, is an activity concerned with local design constraints, such as design patterns, architectural patterns, programming idioms, and refactorings. According to the Intension/Locality Hypothesis[9], the distinction between strategic and tactical design is defined by the Locality Criterion[9], according to which a statement about software design is non-local if and only if a program that satisfies it can be expanded into a program which does not. For example, the Client-Server style is architectural (strategic) because a program that is built by this principle can be expanded into a program which is not client server; for example, by adding peer-to-peer nodes.
Architecture is design but not all design is architectural. In practice, the architect is the one who draws the line between software architecture (architectural design) and detailed design (non-architectural design). There aren't rules or guidelines that fit all cases.


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

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

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

G>>Определяем три термина. Архитектура, дизайн, детальный дизайн.

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

AL>Хотя можно, конечно, упереться и объявить паттерн и реализацию паттерна разными вещами и упражняться в риторике до посинения.


Давай не будем.

AL>Кстати, если рассматривать использование xml для сериализации в качестве архитектурного решения в отрыве от дизайна и ограничений на дизайн, то могут получаться удивительные по своей абсурдности вещи, как в некоторых middleware, когда для передачи по сети одного скалярного значения риалтаймовых данных с меткой времени требуется посылать по "веревке" килобайт xml-ной чепухи.


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

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

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

G>>Главное, архитектуру не путайте с дизайном. Думаю, как только вы мои определения почитали, вам уже все стало понятнее, не так ли? .


AL>И как же их не путать то? Может, для пользы дела примем дизайн/детальный дизайн в качестве одного из архитектурных представлений?


Следуя предложенному мной определению, не перепутать довольно легко.
Re[5]: Просветите про роль требований в проектировании, плиз
От: Beam Россия  
Дата: 15.02.09 12:40
Оценка:
Здравствуйте, Gaperton, Вы писали:

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


G>Определяем три термина. Архитектура, дизайн, детальный дизайн.


G>Детальный дизайн — алгоритмы и структуры данных.

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

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

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

Отсюда же следует, что алгоритмы и структуры данных ортогональны этим определениям.
... << RSDN@Home 1.2.0 alpha 4 rev. 1136>>
Best regards, Буравчик
Re[7]: Просветите про роль требований в проектировании, плиз
От: A.Lokotkov Россия http://www.linkedin.com/pub/alexander-lokotkov/a/701/625
Дата: 15.02.09 12:41
Оценка:
Здравствуйте, Gaperton, Вы писали:

G>Действительно странно. Особенно странно то, что многие "серьезные дядьки" либо не знакомы с этим определением, либо не ставят его во грошь. А теперь берем базовый архитектурный курс по MCSD, и читаем там совсем другое, до крайности мутное определение, которое я даже затрудняюсь воспроизвести. Берем PSP/TSP, и не находим там термина "архитектура" вовсе. Что делать будем?


Я на серьезных дядек типа Рэмбо, Буча и ко. как бы и не ссылаюсь, ибо пустое это дело -- ссылаться на авторитетных дядек А в PSP/TSP легко найти термин "архитектура" в том смысле, что PSP/TSP к архитектуре, требованиям и прочей технической ерунде вроде как ортогональны:

PSP-BOK v1.0:
1.1 PURPOSE
... there are categories of software and other engineering knowledge that are not represented in the PSP BOK (architecture, requirements definition,
hardware design, etc.), although it is assumed that a proficient software professional will have some degree of familiarity with such topics.



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


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

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


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

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


В таком случае не очень понятно, от чего зависит архитектура и как на уровне стратегии понять, правильная она или нет. Например, решив хранить состояние прикладных объектов в реляционной базе, через год дизайна выясняем, что пользователям системы придется курить по 5 минут после каждого изменения любого совместно изменяемого объекта на любом клиентском рабочем месте.
bloß it hudla
Re[20]: Просветите про роль требований в проектировании, пли
От: Sinix  
Дата: 15.02.09 13:59
Оценка:
Здравствуйте, Ziaw!

Либо у меня больное самомнение либо вы пытаетесь увести разговор в сторону. Смотрите сами:

Z>Все верно, ты понимаешь, что нельзя плясать только от предметной области и доменной модели и параллельно анализируешь требования к продукту. Только что-то мешает тебе признать, что требования к продукту превичны.


Гммм... забавный диалог. Я: "модель строится на основе информации взятой из предметной области". Вы: "требования к продукту превичны. Именно ими руководствуются при созданиии доменной модели."

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

Z>Именно ими руководствуются при созданиии доменной модели. Ибо некий документ в предметной области в зависимости от требований к продукту может быть представлен как кортеж (№, автор) или как пдф или как набор версионированых документов со множеством связей.


Не может документ _в предметной области_ быть представлен. Документ — это часть предметной области. Модель предметной области — это точное (в пределах разумного) её отражение. Начиная искажать модель мы непредсказуемо меняем стабильность модели. Оно нам надо?

Z>В этом и есть ваша ошибка, модель сильно зависит от требований и часто меняется вместе с ними.


От того, что заказчик придумал новый тип ценников кардинально поменялся принцип интернет-торговли??? Боюсь, вы ненамеренно включаете в модель быстро изменяющуюся информацию и заявляете что модель зависит от требований. Вы их разделите.
Хотя бы так: модель предметной области влияет на архитектуру, требования заказчика — на функционал. Хоть это и неправда...

Гммм... вот смотрите. Вы пишете автоматизацию логистики. Или интернет-магазин. Или социальную сеть. (во всём вышеперечисленном одинаково некомпетентен ). И везде-везде внутренняя логика работы зависит от требований заказчика???

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

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

Z>Любая абстракция (а модель это абстракция) косвенно отражает действительность. Она включает в себя только те данные, которые нам требуются (от слова требования).

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

Z>Верное утверждение1: ...

Вы даёте свои определения которые не имеют ничего общего с исходными посылками. Так можно доказать что угодно. Не будем

Z>Логично, имея на входе закачика и предметную область, сначала получить и изучить требования, а потом применить утверждение 2 и разработать модель. Проектируя модель без учета требований нам придется переделывать ее гораздо чаще.

Ещё раз. Если модель предметной области _не отражает требования_ и не зависит от них — почему она будет меняться????

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

Z>Продукт разрабатывается для вполне конкретных целей. Полное отражение деятельности заказчика в продукте это не цель и никому особо не интересно, всегда оперируют необходимым минимумом информации.
Тут два варианта. Либо вы намеренно передёргиваете мои слова пытаясь выставить меня идиотом, либо вы считаете меня идиотом и уверены, что я на полном серьёзе рассматриваю возможность полного отражения деятельности заказчика. Я не могу каждую свою строчку сопровождать дисклаймером. 9/10 моих ответов — либо повторение уже написанного либо комменты и разъяснения. Не будем уходить от темы.

Z>Если мы при тщательном анализе предметной области поймем, что документ на самом деле является версионированной сущностью с 200 сложными атрибутами и заложим эту модель...


Снова то же самое. Откуда вы взяли что модель предметной области должна быть целиком отображена в архитектуре/коде?

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

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

Сорри за чрезмерную резкость. Ничего личного
Re[15]: Просветите про роль требований в проектировании, пли
От: Sinix  
Дата: 15.02.09 14:21
Оценка: +1
Здравствуйте, Аноним!

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


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

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


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


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

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


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

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


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

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

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


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


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


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

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

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