В деятельности UP "Анализ прецедента" требуется, чтобы класс анализа чётко и однозначно проецировался на некоторое реальное понятие предметной области. В связи с этим у меня возник вопрос: Что есть предметная область?
Например, для предприятия имеющего устранявшуюся систему бумажного документооборота, разрабатывается система электронного документооборота. Что будет входить в предметную область?
1) Только понятия касающиеся документооборота на предприятии и смежных областей, или
2) Понятия касающиеся документооборота на предприятии и смежных областей, а также понятия касающиеся будущей системы электронного документооборота;
Другими словами, относятся ли к предметной области понятия связанные с функционированием предполагаемой системы электронного документооборота. Или к ней относятся, только понятия самого бумажного документооборота предприятия

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

C>В деятельности UP "Анализ прецедента" требуется, чтобы класс анализа чётко и однозначно проецировался на некоторое реальное понятие предметной области. В связи с этим у меня возник вопрос: Что есть предметная область?

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

Автор: perekrestov
Дата: 17.11.10

---

Есть 2 основных подхода к моделированию предметной области:
— предметная область — это автоматизируемый бизнес заказчика (примерно то, что у вас под №2)
— предметная область — это область деятельности заказчика (ака DDD). (примерно то, что у вас под №1)

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

Увы, если полученная модель не будет активно использоваться дальше, толку от неё никакого не будет

C>Например, для предприятия имеющего устранявшуюся систему бумажного документооборота, разрабатывается система электронного документооборота. Что будет входить в предметную область?
Вам решать

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

ИМХО понятие предметной области станет понятным после того, как будут построены две модели: модель AS-IS и модель TO-BE/
Первая должна описывать текущее состояние документооборота, вторая — собственно проект...

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

S>Есть 2 основных подхода к моделированию предметной области:
S> — предметная область — это автоматизируемый бизнес заказчика (примерно то, что у вас под №2)
S> — предметная область — это область деятельности заказчика (ака DDD). (примерно то, что у вас под №1)

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

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

Про документооборот, это я так для примера привёл первое, что взбрело в голову

У меня есть проект. Там уже собраны требования(около 100 шт) и разработаны UseCase'ы(около 60 штук). Следующий этап Анализ. Начал с анализа существительное/глагол и сразу-же вспомнил о том что "класс анализа должен чётко и однозначно проецировался на некоторое реальное понятие предметной области". А у меня после анализа нескольких страниц текста, всплыли такие понятия как Учётная запись, Действительный/Недействительный пароль, Пользователь и т.п., т.е. понятие имеющие непосредственное отношения к функционировании системы. В то время как в самой предметной области они не используются. Соответственно, сразу встал вопрос правильно-ли я всё понял! Вот я и на примере документооборота и спрашиваю по сути, должны-ли эти понятия всплывать при Анализе, точнее в соответствии с UP в деятельности "Анализ прецедента"
Просто у меня нет ни какого опыта в анализе вообще. Я бы уже сто раз и так написал требуемую систему, но решил упереться и пройти весь путь в соответствии с UP до конца.
Кроме того, немного поразмыслив я задался таким вопросом: Правильно-ли я вообще понимаю суть деятельности "Анализ прецедента"
В моём понимании, суть его такова. Понятия предметной области, их отношения и операции проецируются на разрабатываемую систему и для каждого из этих понятий, отношений и операций в системе есть представитель. Поскольку происходит проецирование с предметной области в систему, то понятия, отношения и операции существующие в реальном мире(предметной области) накладывают ограничения на их представление в системе. Таким образом установив связи эти понятия, а также выяснив их отношения и операции которые над ними выполняют, мы получаем ограничения которым должны удовлетворять представители понятий, отношений и операций внутри разрабатываемой системы. И мы просто изображаем их на диаграммах как класс с его атрибутами и операциями. НО, классом анализа должно быть именно понятие предметной области, а не разрабатываемой системы.

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

C>У меня есть проект. Там уже собраны требования(около 100 шт) и разработаны UseCase'ы(около 60 штук). Следующий этап Анализ.

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

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

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

Зависит от подхода. Ничего смертельно неправильного я не вижу. Главное не смешивать мух с котлетами — логика — отдельно, инфраструктура — отдельно.

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

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

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

C>У меня есть проект. Там уже собраны требования(около 100 шт) и разработаны UseCase'ы(около 60 штук). Следующий этап Анализ. Начал с анализа существительное/глагол и сразу-же вспомнил о том что "класс анализа должен чётко и однозначно проецировался на некоторое реальное понятие предметной области". А у меня после анализа нескольких страниц текста, всплыли такие понятия как Учётная запись, Действительный/Недействительный пароль, Пользователь и т.п., т.е. понятие имеющие непосредственное отношения к функционировании системы.

Если строго по теории, то "Анализ прецедента" должен давать на выходе "Класс анализа"

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

(с)Арлоу, Нэйштадт

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

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

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

Но может Вы пишите какую-нибудь систему управления учётками, и тогда термины "Учётная запись, Действительный/Недействительный пароль, Пользователь" — самые что ни на есть предметные

Вот как-то так мне это видится.

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

S>Есть 2 основных подхода к моделированию предметной области:
S> — предметная область — это автоматизируемый бизнес заказчика (примерно то, что у вас под №2)
S> — предметная область — это область деятельности заказчика (ака DDD). (примерно то, что у вас под №1)

Если про DDD, то это и 1 и 2

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

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

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

C>Про документооборот, это я так для примера привёл первое, что взбрело в голову

C>У меня есть проект. Там уже собраны требования(около 100 шт) и разработаны UseCase'ы(около 60 штук). Следующий этап Анализ. Начал с анализа существительное/глагол и сразу-же вспомнил о том что "класс анализа должен чётко и однозначно проецировался на некоторое реальное понятие предметной области". А у меня после анализа нескольких страниц текста, всплыли такие понятия как Учётная запись, Действительный/Недействительный пароль, Пользователь и т.п., т.е. понятие имеющие непосредственное отношения к функционировании системы. В то время как в самой предметной области они не используются.

Предметная область у _задачи_. Поэтому нормально, что будет учетнаz запись, пароль, пользователь и тд.

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

S>>Есть 2 основных подхода к моделированию предметной области:
S>> — предметная область — это автоматизируемый бизнес заказчика (примерно то, что у вас под №2)
S>> — предметная область — это область деятельности заказчика (ака DDD). (примерно то, что у вас под №1)

I>Если про DDD, то это и 1 и 2
Мааленький дисклаймер. Если вы с gandjustas'ом опять собираетесь превратить ветку в филиал КСВ — я пас

Разница на практике очень большая, примерно такая же как между введением в книге Эванса и остальной частью. Сначала идут довольно здравые мысли про постоянность предметной области, про её независимость от желаний заказчика и про использование терминов из модели в качестве языка общения в рамках проекта. А дальше — попытки подружиться и с фаулером, и с явой, и с агилистами. Появляется репозитарий, модель постепенно подменяется бизнес-логикой, "TDD тоже имеет право на жизнь" и в конце идёт религиозная нудятина почище, чем у Бека с Адамсом.
Евангелист, чего с него взять. Позавчера — за DDD, сегодня — за NoSQL, завтра — ещё за что-нить будет агитировать. Но популяризатор классный, не отнимешь.

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

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

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

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

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

Фаулер, Эванс, Кент Бек — это одна бригада и идеи у них очень часто пересекаются и они хором исповедуют ТДД. Грубо говоря, DDD Эванса это XP + MDA + TDD.

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

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

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

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

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

И здесь точно так же. Разница только в том, что в первом случае ты можешь разобраться с автоматизацией бизнеса и работать с разными заказчиками в разных нишах, а во втором случае область как правило новая для тебя. Т.е. разница в количестве новых знаний для тебя. Но подход остается тем же самым.

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

Я приводил нормальный пример — заказчик это мега-порнушник, владелец нескольких сайтов, магазинов, студий и тд. Заказывает программу для проектирования оптических сетей для внутренних целей.Какая предметная область ? Здесь нет ни автоматизации бизнеса, и с порно тоже дела иметь не надо. Что же выходит, нет предметной области ?

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

I>Фаулер, Эванс, Кент Бек — это одна бригада и идеи у них очень часто пересекаются и они хором исповедуют ТДД. Грубо говоря, DDD Эванса это XP + MDA + TDD.
DDD Эванса — это популяризация старой идеи "ПО — действующая модель деятельности заказчика", корни которой идёт ещё из концептуальной модели из предложений ANSI/SPARC. То, что Эванс показывал использование DDD на примере аджиль-разработки, не значит, что DDD хорошо на неё ложится. Напротив, идеология DDD противоречит "идём за пастухом" Бека и "главная цель — код" Амблера, и Эвансу пришлось специально расшаркиваться — мол, DDD ортогонален и хорошо ложится на любую модель разработки. Увы, на ортодоксальный аджиль с "пока вы думаете, мы уже 10 раз сделали" DDD ложится очень плохо.

I>Предметная область это у _задачи_. В автоматизации бизнеса нужно обязательно заглядывать внутрь бизнеса. Например если ты не знаешь, как работают склады у заказчика, ты не можешь сделать эту самую автоматизацию.
Можно заглядывать по разному. Например, штампуя прототипы, пока заказчику не надоест

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

I>И делать придется именно тебе, потому что заказчик как правило не может проанализировать свои потребности что бы формализовать их в виде, пригодном для софтостроения.
Дык это ж бубль гум классика:

Then, slowly, I came to realize that the most useful service I was performing for my client was helping him decide what he really wanted.

(с) Брукс, The Design of Design: Essays from a Computer Scientist

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


I>Я приводил нормальный пример — заказчик это мега-порнушник, владелец нескольких сайтов, магазинов, студий и тд. Заказывает программу для проектирования оптических сетей для внутренних целей.Какая предметная область ? Здесь нет ни автоматизации бизнеса, и с порно тоже дела иметь не надо. Что же выходит, нет предметной области ?

Если вы разрабатываете вакуумный сферософт, то да, предметной области нет. Если смотрите на область деятельности, которую автоматизирует ПО — есть. Намекну: на оптические сети нет никаких стандартов/правил проектирования/физических ограничений?

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

I>>Фаулер, Эванс, Кент Бек — это одна бригада и идеи у них очень часто пересекаются и они хором исповедуют ТДД. Грубо говоря, DDD Эванса это XP + MDA + TDD.
S>DDD Эванса — это популяризация старой идеи "ПО — действующая модель деятельности заказчика", корни которой идёт ещё из концептуальной модели из предложений ANSI/SPARC. То, что Эванс показывал использование DDD на примере аджиль-разработки, не значит, что DDD хорошо на неё ложится. Напротив, идеология DDD противоречит "идём за пастухом" Бека и "главная цель — код" Амблера, и Эвансу пришлось специально расшаркиваться — мол, DDD ортогонален и хорошо ложится на любую модель разработки. Увы, на ортодоксальный аджиль с "пока вы думаете, мы уже 10 раз сделали" DDD ложится очень плохо.

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

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

I>>Предметная область это у _задачи_. В автоматизации бизнеса нужно обязательно заглядывать внутрь бизнеса. Например если ты не знаешь, как работают склады у заказчика, ты не можешь сделать эту самую автоматизацию.
S>Можно заглядывать по разному. Например, штампуя прототипы, пока заказчику не надоест

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

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

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

Все очень просто — для n-хотелок есть k-вариантов представления модели. Какой из них лучший на перспективу сказать можно только зная наперед, какие хотелки могут появиться. В случае с автоматизацией эту всю работу за тебя уже сделали. Грубо говоря, в типичных случаях тебе уже не надо изобретать уравнение Менделеева-Клайпейрона

I>>Я приводил нормальный пример — заказчик это мега-порнушник, владелец нескольких сайтов, магазинов, студий и тд. Заказывает программу для проектирования оптических сетей для внутренних целей.Какая предметная область ? Здесь нет ни автоматизации бизнеса, и с порно тоже дела иметь не надо. Что же выходит, нет предметной области ?

S>Если вы разрабатываете вакуумный сферософт, то да, предметной области нет. Если смотрите на область деятельности, которую автоматизирует ПО — есть. Намекну: на оптические сети нет никаких стандартов/правил проектирования/физических ограничений?

Читаем твои высказывания:

1 — предметная область — это автоматизируемый бизнес заказчика (примерно то, что у вас под №2)
2 — предметная область — это область деятельности заказчика (ака DDD). (примерно то, что у вас под №1)

Очевидно, пример с порнушником не явлется ни 1, ни 2. Что не так ?

А вот если взять твое "область деятельности, которую автоматизирует ПО", то очевидно, что под это определение подходят и 1 и 2.

Щас ты вот плавно меняешь формулировки — "область деятельности, которую автоматизирует ПО". О чем я и говорил ранее — предметная область определяется задачей, а не заказчиком. Потому твои формулировки 1 и 2 просто ересь.

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

I>Я не согласен. DDD не противоречит ни идее "идём за пастухом", ни идее "главная цель — код".
А я не согласен Но чтоб накормить страшного зверя обоснуй, надо много цитат и рассуждений. Поскольку некритично — замнём?

I> ДДД не ложится куда угодно. При этом ортодоксальный аджиль так же не ложится куда угодно.
Тут полностью согласен.

I>Вообще то у Эванса примеры по обоим вариантам Во втором случае модель точно так же будет серьезно меняться при появлении очередных хотелок.

Почему? Этот довод всплывает в каждой дискуссии без каких-либо обоснований. Если мы не тащим в модель хотелки, а строим на основе области деятельности заказчика — как повлияют на модель требования? Как бы не хотел авиаперевозчик — законодательство не поменяется, логистику новых дорог не построят и строителю дармового и сверхпрочного бетона не завезут. Все они вынуждены работать с реальностью, со всеми прелестями и ограничениями, и эти ограничения:
раз — существуют объективно, вне зависимости от заказчика;
два — относительно постоянны;
три — не будут пополняться при появлении новых хотелок.

Итак, почему?

I>С автоматизацией вопрос хороши изученый и предварительная модель уже имеется и тебе не надо думать на тему, какие фичи могут её поломать.

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

Собсно об этом и речь — "переносим существующий процесс в машину" vs "облегчаем людям работу".

I>Все очень просто — для n-хотелок есть k-вариантов представления модели. Какой из них лучший на перспективу сказать можно только зная наперед, какие хотелки могут появиться. В случае с автоматизацией эту всю работу за тебя уже сделали.

Нет. Для автоматизации есть только модель для фиксированного набора требований. Будут новые — модель рассыпется. Если за основу модели ПО берётся модель предметной области, то k вариантов представлений изоморфны друг другу.

I>Читаем твои высказывания:

1 — предметная область — это автоматизируемый бизнес заказчика (примерно то, что у вас под №2)
2 — предметная область — это область деятельности заказчика (ака DDD). (примерно то, что у вас под №1)

I>Очевидно, пример с порнушником не явлется ни 1, ни 2. Что не так ?
Просто неверно сформулировал, на чём вы меня и подловили
Если играть в буквализм — безусловно да. Если рассматривать заказчика как проектировщика оптоволоконных сетей — нет

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

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

Не понял что ты хотел сказать под "тащим в модель хотелки". Новые хотелки как правило требуют увеличения детализации. Т.е. будут появляться новые объекты, старые объекты будут дробиться на более мелкие и будут добавляться разные связи. Обычно одну и ту же модель можно предтавить разными вариантами. Чем больше хотелок, тем сильнее эти варианты будут похожи друг на друга.

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

Необязательно. Всегда есть логические сущности, а не только физические.

S>два — относительно постоянны;

поскольку есть логические сущности, то этого нельзя гарантировать.

S>три — не будут пополняться при появлении новых хотелок.

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

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

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

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

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

см. выше про аппетит.

I>>Все очень просто — для n-хотелок есть k-вариантов представления модели. Какой из них лучший на перспективу сказать можно только зная наперед, какие хотелки могут появиться. В случае с автоматизацией эту всю работу за тебя уже сделали.

S>Нет. Для автоматизации есть только модель для фиксированного набора требований. Будут новые — модель рассыпется.

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

I>>Очевидно, пример с порнушником не явлется ни 1, ни 2. Что не так ?
S>Просто неверно сформулировал, на чём вы меня и подловили
S>Если играть в буквализм — безусловно да. Если рассматривать заказчика как проектировщика оптоволоконных сетей — нет

Тогда можно продавца автомобилей рассматривать как автоматизатора бизнеса

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

I>Тогда можно продавца автомобилей рассматривать как автоматизатора бизнеса

Ну почему-же. Вот Вы писали

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

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

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

I>Не понял что ты хотел сказать под "тащим в модель хотелки". Новые хотелки как правило требуют увеличения детализации.

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

*Ага, я опять ленюсь вставлять оговорки про "область деятельности, которую автоматизирует ПО"

>>Все они вынуждены работать с реальностью, со всеми прелестями и ограничениями, и эти ограничения:
S>>раз — существуют объективно, вне зависимости от заказчика;

I>Необязательно. Всегда есть логические сущности, а не только физические.
Ещё раз цитата:

вынуждены работать с реальностью, со всеми прелестями и ограничениями, и эти ограничения ... существуют объективно

Я не пойму: как ограничения предметной области, пускай и логические становятся субъективными.

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

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

Я таки закругляюсь, пережёвывать одно и то же не люблю Спасибо!

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

S>В 1-м варианте мы получаем классику — набор требований -> ??? -> диаграмма классов.

Набор требований -> Функциональная модель системы -> Технологическая модель системы -> Диаграмма классов

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

КЛ>Набор требований -> Функциональная модель системы -> Технологическая модель системы -> Диаграмма классов\

Ага. Просто вспомнил чудо-книжку по UP, где вместо "???" стыдливо нарисовали облачко с аналитиками внутри Название опуса — мнэээ... Полуэкт? не вспомню.

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

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

Автор: perekrestov
Дата: 17.11.10

В ретроспективе: одним из человеков оказался я

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

C>>В деятельности UP "Анализ прецедента" требуется, чтобы класс анализа чётко и однозначно проецировался на некоторое реальное понятие предметной области. В связи с этим у меня возник вопрос: Что есть предметная область?

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

И что? Ни одно слово в языке не имеет абсолютно четкого смысла и на некотором уровне любой процесс уточнения скатится к “религиозным предпочтениям”.

Самый главный баззворд это само слово “баззворд”. Уж очень модно стало его везде тыкать.