1

Для всех / Re: Логическая модель БД: правила именования сущностей

« : 08 Июня 2011, 12:20:02 »

Используйте стереотип enumeration, т.е. перечисление

Дополняю изначальные данные: моделирование производится в ERwin. Нотация и программные средства использование стереотипов будто бы не поддерживают.

2

Для всех / Логическая модель БД: правила именования сущностей

« : 08 Июня 2011, 11:36:53 »

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

3

Примеры / Re: Проектная работа - Коммунальные платежи

« : 01 Февраля 2010, 15:44:55 »

RUsh, а как в стейтчарт задействовать класс "Рабочий день"?

Не уверен, что он того достоин. У него можно выделить всего пару состояний - открыт\закрыт. Можно ещё, конечно, повысасывать известно что известно откуда и нафантазировать всяческое "параметры определены" и "отчётность сформирована", но это уместнее подразумевать в базовых состояниях.

4

Примеры / Re: Проектная работа - Коммунальные платежи

« : 01 Февраля 2010, 15:15:43 »

Пытаюсь нарисовать диаграмму. Классов. Посмотрите плиз, классы. Верно выделил?

1. Извещение
2. Платеж (3 вида) через обобщение в один общий
3. Архив
4. АРМ оператора
5. "Пользователь" со свойствами - Оператор, Администратор.

Просто мне по ним, видимо, стейтчарт диаграмму надо будет еще наваять.

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

5

Примеры / Re: Проектная работа - Коммунальные платежи

« : 01 Февраля 2010, 13:18:16 »

И второе. Навая активити-диаграмму.

Посмотрите пожалуйста...  

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

6

Примеры / Re: Проектная работа - Коммунальные платежи

« : 01 Февраля 2010, 12:58:42 »

Разбавлю ваш диалог, господа.
Мой вариант основного сценария приёма платежа по данной постановке:
1. Оператор выбирает тип платежа и инициирует ввод данных

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

2. Система запрашивает набор параметров платежа в соответствии с выбранным типом.
3. Оператор определяет параметры платежа в соответствии с извещением.
4. Система рассчитывает и отображает оператору:
- Сумму, начисленную согласно текущим тарифам, и разницу с данными, предоставленными клиентом;
- Сумму комиссии за приём платежа;
- Итоговую сумму, которую должен внести клиент.

(Тут Вы, господа, явно упустили аж 2 важнейших момента из постановки: 1) То, что насчитал клиент (или система начислений) в своём извещении может не сойтись с тем, что насчитает наша система (ведь у нас администратор каждый день это настраивает), об этом обязательно нужно оповестить клиента 2) За приём платежа через наш АРМ взимается комиссия, итоговую сумму клиент не знает и может с ней быть не согласен.)

5. Оператор знакомит с итоговыми суммами клиента (клиент не возражает), и инициирует добавление платежа в группу.

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

6. Система отображает общую сумму оплаты для группы и предлагает ввести сумму фактической оплаты.
7. Шаги 1-7 повторяются для всех извещений текущего клиента.

(Тут расширения из серии "клиент передумал насчёт вон того платежа").

8. Оператор вводит сумму фактической оплаты.
9. Система рассчитывает и отображает сдачу.
10. Оператор подтверждает приём группы платежей.
11. Система запрашивает подтверждение - оператор подтверждает.

(Опять упущенный и весьма важный шаг, диктуемый суровой реальностью.)

12. Система добавляет информацию о платежах в архив и формирует квитанции.

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