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

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

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

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

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