В деятельности 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>Если коротко — "предметная область" — очередной баззворд; его толкование зависит в первую очередь от религиозных предпочтений.

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

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

Здравствуйте, Кодёнок, Вы писали:

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

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

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

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


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

JR>

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

JR>Здесь предметная область чётко определена — проектирование оптических сетей

То есть, предметная область у задачи ? ЧТД

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

S>Ну блин, мы по третьему кругу обсуждаем тривиальшину В первом варианте мы не отделяем бизнес заказчика* от его области деятельности. Во втором — отделяем и выражаем первое через второе.

Предметная область есть у задачи. Что там в бизнесе — дело десятое.

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

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

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

Никак. В автоматизации бизнеса причем точно так же. Заказ не может существовать субъективно

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

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

Чушь.

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

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

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

I>То есть, предметная область у задачи ? ЧТД

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

Мне показалось, что он говорит вот о чём.

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

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

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

Это я понял. В проектировании например все точно так же, только в бизнесе границы более размытые.

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

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

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

Описав варианты использования ты определил ЧТО должна делать система. Модель анализа определяет КАК это будет реализовано. Эта модель является связующим звеном между требованиями и программным кодом системы. Поэтому модель анализа описывается на очень высоком уровне абстракции.

С одной стороны, модель анализа описывает ВНУТРЕННЕЕ устройство системы. Поэтому в ней могут быть любые сущности, необходимые для внятного описания системы. С другой стороны, модель описывает систему на высоком уровне. Поэтому ДОСТАТОЧНО использовать понятия предметной области. Все что подробнее — это уже проектирование/реализация.

В модели анализа выделяется три вида классов (ну прям как MVC).
Граничные классы (boundary) — представляющие интерфейс работы с актором.
Управляющие классы (control) — функциональные блоки системы, бизнес-логика.
Классы-сущности (entity) — объекты, с которыми работает система.

Но эти классы ВЫСОКОГО УРОВНЯ. Пример:
интерфейс пользователя (boundary) --- менеджер учетных записей --- пользователь

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

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

1. Построение модели — это тоже затраты. Если затраты на построение/поддержку модели превышают пользу от нее, зачем она нужна?

2. Думаю, что ты сильно детализируешь модели. Из-за этого получается долго. Цель RUP — снизить риски: двигаясь постепенно выявить их и, по возможности, устранить на ранних этапах. Это окупается на больших проектах. На малых проектах надо делать все то же самое — но в уменьшенном размере, уменьшая детализацию, т.к. см. п.1.

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

Б>Описав варианты использования ты определил ЧТО должна делать система. Модель анализа определяет КАК это будет реализовано. Эта модель является связующим звеном между требованиями и программным кодом системы. Поэтому модель анализа описывается на очень высоком уровне абстракции.

Б>С одной стороны, модель анализа описывает ВНУТРЕННЕЕ устройство системы. Поэтому в ней могут быть любые сущности, необходимые для внятного описания системы. С другой стороны, модель описывает систему на высоком уровне. Поэтому ДОСТАТОЧНО использовать понятия предметной области. Все что подробнее — это уже проектирование/реализация.

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

Б>В модели анализа выделяется три вида классов (ну прям как MVC).
Б>Граничные классы (boundary) — представляющие интерфейс работы с актором.
Б>Управляющие классы (control) — функциональные блоки системы, бизнес-логика.
Б>Классы-сущности (entity) — объекты, с которыми работает система.

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

Б>Но эти классы ВЫСОКОГО УРОВНЯ. Пример:
Б>интерфейс пользователя (boundary) --- менеджер учетных записей --- пользователь

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

Б>1. Построение модели — это тоже затраты. Если затраты на построение/поддержку модели превышают пользу от нее, зачем она нужна?

Б>2. Думаю, что ты сильно детализируешь модели. Из-за этого получается долго. Цель RUP — снизить риски: двигаясь постепенно выявить их и, по возможности, устранить на ранних этапах. Это окупается на больших проектах. На малых проектах надо делать все то же самое — но в уменьшенном размере, уменьшая детализацию, т.к. см. п.1.

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

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

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

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

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

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

Важно другое. ЗАЧЕМ Вы хотите четко разделять, что относить к предметной области, а что нет?

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

Для чего нам вообще нужен анализ? Чем он отличается от проектирования?

1. Нам нужно более точно определить требования. Требования написаны на естественном языке и могут быть неполны или противоречивы. Анализ позволяет эти трудности выявить и устранить. Проектирование уже работает с полными и непротиворечивыми требованиями.

2. Когда Вы анализируете требования, формируется некоторое понимание устройства системы, ее частей. Т.е. черновой набросок системы. Эта информация затем используется в проектировании. Но в процессе анализа внутреннее устройство описывается в терминах предметной области, без учета деталей, связанных с языками программирования, БД, операционных систем и пр. В проектировании учитывается особенности языка, библиотек и прочих инструментов.

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

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


Б>>В модели анализа выделяется три вида классов (ну прям как MVC).
Б>>Граничные классы (boundary) — представляющие интерфейс работы с актором.
Б>>Управляющие классы (control) — функциональные блоки системы, бизнес-логика.
Б>>Классы-сущности (entity) — объекты, с которыми работает система.

C>Вообще это в RUP классы анализа делятся на три категории. В классическом UP такого деления нет. Там наоборот подчёркивается, что существует множество способов классификации таких понятий, а выбор наилучшего из них зависит от рассматриваемой задачи и является одной из приоритетных задач аналитика.

Они и не противоречат друг другу (по крайней мере те, которые упомянуты в Вашей книжке)

Для каждого варианта использования:
1. Выделяем сущности (сушествительные)
2. Выделяем управляющие классы (глаголы)
3. Выделяем граничные классы (как с системой работать будут)
4. Смотрим, а нельзя ли в п.1-3 использовать, что-нибудь, что уже есть в модели
5. Если получаемые классы слишком сложны, разбиваем их
6. Если получаемые классы слишком просты, объединяем их

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

Б>Важно другое. ЗАЧЕМ Вы хотите четко разделять, что относить к предметной области, а что нет?

Ну фиг его знает. А вдруг я не понял, что нибудь про анализ и это принципиально? Вот я и решил уточнить.

Б>Для чего нам вообще нужен анализ? Чем он отличается от проектирования?

Б>1. Нам нужно более точно определить требования. Требования написаны на естественном языке и могут быть неполны или противоречивы. Анализ позволяет эти трудности выявить и устранить. Проектирование уже работает с полными и непротиворечивыми требованиями.

Б>2. Когда Вы анализируете требования, формируется некоторое понимание устройства системы, ее частей. Т.е. черновой набросок системы. Эта информация затем используется в проектировании. Но в процессе анализа внутреннее устройство описывается в терминах предметной области, без учета деталей, связанных с языками программирования, БД, операционных систем и пр. В проектировании учитывается особенности языка, библиотек и прочих инструментов.

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

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

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

Если я ошибаюсь поправьте. Но в моём понимании цель анализа всё таки с минимальными усилиями выделить предполагаемые функциональные блоки программы, а уточнение требований это уже вопрос десятый. Уточнение требований происходит во всех фазах и рабочих потоках UP. Просто в фазе анализа появляется возможность описать требования используя кроме словаря предметной области ещё и словарь анализа, в который входят термины появившееся во время анализа. Так-же на этапе проектирования можно уточнить требования в терминах проектных классов.
В анализе же, на мой взгляд, главное другое. На момент когда вы начинаете анализ у вас есть UseCase'ы которые описывают ожидаемое поведение системы. В этом описании, явно или не явно, описывается взаимодействие сущностей для реализации этого поведения. Мы выделяем эти сущности и взаимодействия, и получаем кашу. Цель анализа навести в этой каше порядок. Мы берём и для каждой сущности определяем круг обязанностей и пытаемся понять как они при взаимодействии выполняют UseCase, попутно можно уточнить требования. Получившаяся модель является сырьём для проектирования классов. Она неполна поскольку не учитывает особенностей реализации и будет дополнена позже.

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

C>Точно определить требования? Хм... Некоторые требования конечно можно уточнить, но мне так кажется, что это касается только требований для уточнения которых нужно знать детали функционирования системы, которые всплывают в процессе анализа. А большая часть требований просто декларирует ожидаемое поведение системы. Их уточнять уже некуда. Например как уточнить следующие требования: "Система должна блокировать пароль учётной записи если три раза он был введён неверно"? С точки зрения ожидаемого от системы поведения, тут и так всё понятно. С другой стороны если вы под прояснением требований имели ввиду реализацию этих требований через взаимодействие классов анализа, тогда я с вами согласен.

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

Да. Вы смотрите внутрь системы и пытаетесь "реализовать" требования (на высоком уровне). Это основная работа в процессе анализа.

Под уточнением требований я все же понимаю именно их уточнение, а не реализацию Другое дело, что понять проблемы, которые есть в требованиях, можно только в процессе их анализа ("реализации"). Пример: прецедент "Снять деньги со счета" и прецедент "Заблокировать счет". Оба работают с сущностью Счет. В процессе анализа "заблокировать счет" Вы выявляете, что счет может быть заблокирован (это атрибут Счета). Но вот почему-то в прецеденте "Снять деньги со счета" ничего не говорится о порядке снятия денег с заблокированного счета. Что должна делать система в этом случае?

А вот после анализа нам уже все известно — можно строить систему и не бояться, что всплывет что-нибудь еще.

И что-то мне не очень нравится выражение "уточнить требования в терминах проектных классов".

C>В анализе же, на мой взгляд, главное другое. На момент когда вы начинаете анализ у вас есть UseCase'ы которые описывают ожидаемое поведение системы. В этом описании, явно или не явно, описывается взаимодействие сущностей для реализации этого поведения. Мы выделяем эти сущности и взаимодействия, и получаем кашу. Цель анализа навести в этой каше порядок. Мы берём и для каждой сущности определяем круг обязанностей и пытаемся понять как они при взаимодействии выполняют UseCase, попутно можно уточнить требования. Получившаяся модель является сырьём для проектирования классов. Она неполна поскольку не учитывает особенностей реализации и будет дополнена позже.

А вот с этим полностью согласен.

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

Б>В процессе анализа "заблокировать счет" Вы выявляете, что счет может быть заблокирован (это атрибут Счета).

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

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

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

КЛ>Здравствуйте, Буравчик, Вы писали:

Б>>В процессе анализа "заблокировать счет" Вы выявляете, что счет может быть заблокирован (это атрибут Счета).

КЛ>Небольшая поправка: лучше завести систему Заблокированные Счета и проверять у неё, заблокирован ли конкретный Счёт, нежели заводить атрибут заблокирован у Счёта.

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

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

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

Б>Да. Вы смотрите внутрь системы и пытаетесь "реализовать" требования (на высоком уровне). Это основная работа в процессе анализа.

Б>Под уточнением требований я все же понимаю именно их уточнение, а не реализацию Другое дело, что понять проблемы, которые есть в требованиях, можно только в процессе их анализа ("реализации"). Пример: прецедент "Снять деньги со счета" и прецедент "Заблокировать счет". Оба работают с сущностью Счет. В процессе анализа "заблокировать счет" Вы выявляете, что счет может быть заблокирован (это атрибут Счета). Но вот почему-то в прецеденте "Снять деньги со счета" ничего не говорится о порядке снятия денег с заблокированного счета. Что должна делать система в этом случае?

Б>А вот после анализа нам уже все известно — можно строить систему и не бояться, что всплывет что-нибудь еще.

Б>И что-то мне не очень нравится выражение "уточнить требования в терминах проектных классов".

Ну это я видимо немного кривовато выразился Я вот, что имел ввиду.

На этапе сбора требований мы говорим — "Система должна препятствовать попыткам взлома пароля"
Потом описывая UseCase'ы мы понимаем, что его можно перебрать и — "Система должна препятствовать попыткам перебора пароля"
Перейдя к анализу видим, что пароль будет храниться на диске, соответственно — "Система должна шифровать пароль в файле на диске"
А на этапе проектирования мы понимаем, что нужно выбрать алгоритм шифрования, ну и — "Система должна шифровать пароль на диске алгоритмом AES"

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

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

C>А зачем городить огород? Просто счёт имеет атрибут, типа boolean например, true — счёт разблокирован, false — заблокирован.

Потому что дальше легко продолжить:

1. Жёсткий блок — заблокирован совсем и не может быть разблокирован.
   
2. Мягкий блок — заблокирован, но может быть разблокирован по заявлению клиента.
   
3. Заблокирован для операций со всеми картами (но клиент может снять деньги, прийдя в отделение).
   
4. Заблокирован для операций по конкретной карте.
   
5. Заблокирован для операций за рубежом.
   
6. Заблокирован для операций из банкомата.
   
7. Заблокирован для покупок через платежный терминал.
   
8. И т.д.

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

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

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

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

C>>А зачем городить огород? Просто счёт имеет атрибут, типа boolean например, true — счёт разблокирован, false — заблокирован.

КЛ>Потому что дальше легко продолжить:

КЛ>

КЛ>
1. Жёсткий блок — заблокирован совсем и не может быть разблокирован.
   КЛ>
2. Мягкий блок — заблокирован, но может быть разблокирован по заявлению клиента.
   КЛ>
3. Заблокирован для операций со всеми картами (но клиент может снять деньги, прийдя в отделение).
   КЛ>
4. Заблокирован для операций по конкретной карте.
   КЛ>
5. Заблокирован для операций за рубежом.
   КЛ>
6. Заблокирован для операций из банкомата.
   КЛ>
7. Заблокирован для покупок через платежный терминал.
   КЛ>
8. И т.д.
   КЛ>

А-а-а, ну это просто:

Атрибут счёта "Тип блокировки счёта" типа short int, со следующими значениями:

1. 000 — Жёсткий блок — заблокирован совсем и не может быть разблокирован.
   
2. 001 — Мягкий блок — заблокирован, но может быть разблокирован по заявлению клиента.
   
3. 010 — Заблокирован для операций со всеми картами (но клиент может снять деньги, прийдя в отделение).
   
4. 011 — Заблокирован для операций по конкретной карте.
   
5. 100 — Заблокирован для операций за рубежом.
   
6. 101 — Заблокирован для операций из банкомата.
   
7. 110 — Заблокирован для покупок через платежный терминал.
   
8. 111 — и т.д.

КЛ>Связность возникает не тогда, когда система при снятии денег со счета обращается к подсистеме Заблокированные счета, а тогда, когда отдельный класс начинает содержать в себе данные (или методы), специфичные для разных функциональных подсистем, в данном случае, подсистемы Заблокированные счета.

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

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

C>Атрибут счёта "Тип блокировки счёта" типа short int, со следующими значениями:

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

У Вас, как у проектировщика, есть три варианта решений:

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

2) Делегировать механизм принятия решения о допустимости транзакции сущности Счет.
Это позволит Вам избежать размазывания функционала по коду, но зато нагрузит класс Счет не свойственными ему функциями. Как результат, это решение приведет к сцеплению класса Счет с другими классами — такими, как: Транзакция, Регион, Карта, Платежный Терминал и т.д. Это произойдет, потому что при принятии решения учитывается не только счет клиента, но и все остальные перечисленные объекты.

Таким образом, Вы создатите связность, которую так пытаетесь избежать.

3) Делегировать обязанность принятия решения о допустимости транзакции отдельной сущности, которую можно условно назвать Разрешальщик Транзакций.
Это поможет Вам избежать установления вредных взаимосвязей между Счетом и другими посторонними объектами, но только в том случае, если Вы не будете хранить флажки о блокировке в классе Счет. В противном случае Вы рискуете модифицировать класс Счет каждый раз, как только у Вас меняется бизнес-логика внутри Разрешальщика Транзакций. А если таких Разрешальщиков у Вас не один, а несколько, и все их внутренние данные хранятся в виде флагов в классе Счет, то Счет у Вас превращается в некое бутылочное горлышко, в которое пишут и из которого читают различные подсистемы.

Опять-таки получается связность, которую Вы хотите избежать.

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

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

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

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

КЛ>Небольшая поправка: лучше завести систему Заблокированные Счета и проверять у неё, заблокирован ли конкретный Счёт, нежели заводить атрибут заблокирован у Счёта.

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

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

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

C>А зачем городить огород? Просто счёт имеет атрибут, типа boolean например, true — счёт разблокирован, false — заблокирован. А когда вы говорите "завести систему", то вы предполагаете, что атрибут блокировки счёта будет храниться отдельно от данных счёта.

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


C>И вот ещё, пытаетесь вы снять деньги со счёта, система должна обратиться к системе "Заблокированные счета", что бы проверить его состояние, а это лишняя внешняя связность. В то время как сделав это атрибутом счёта, вы упаковываете атрибут внутрь класса, т.е. делаете его более связным внутренне.

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

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

А я вам сразу написал:

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

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

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

C>

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

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

В серьезном виде данная ошибка хорошо описана здесь, а в шуточном — здесь и здесь.

А предметная область — тут вовсе не при чём.

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

КЛ>И какое отношение имеет дизайн системы к предметной области? У Вас ошибка в подходе, который приведет к созданию подсистемы, на которую всё завязано. И как результат — к постоянному рефакторингу.

КЛ>В серьезном виде данная ошибка хорошо описана здесь, а в шуточном — здесь и здесь.

КЛ>А предметная область — тут вовсе не при чём.

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

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

КЛ>>А предметная область — тут вовсе не при чём.

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

Все правильно — детали задания не только в ТЗ, но и в предметной области, т.к. задание всегда опирается на конкретную предметную область.

Следовательно дизайн как минимум косвенно зависит от предметной области.

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

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

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