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

[Galogen]

Павел, смотрите сами.

Мы при описании ВИ фиксируем требования.

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

Нормальная такая ситуация? Да, конечно. Ведь клиент приходит с кучей платежей. Оператор оформляет их и обычно сразу называет общую сумму, которую клиенту следует заплатить. Как будет реализован процесс вычисления общей суммы не так важно. Например:
Оператор начинает транзакцию
Система предлагает указать тип платежа
Оператор выбирает тип платежа
Система отображает некую форму
Оператор вводит данные и сохраняет результат
Система добавляет результат в некий журнал транзакции и предлагает продолжить
Если оператор желает, то он выбирает следующий платеж все повторятся и платеж добавляется в это журнал транзакции
Если оператор отклоняет продолжение, то система выводит некое сообщение в котором указана сумма всех платежей, есть место для ввода денег от клиента и т.п.

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

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

[RUsh]

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

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

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

[Pavel_T]

RUsh, спасибо за ваш вариант... растерялся прямо 

Galogen, скажите, а что по поводу процентов за услугу? Ведь действительно, он должен где-то участвовать в нашем ВИ...

[Pavel_T]

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

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

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

[RUsh]

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

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

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

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

[Pavel_T]

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

[RUsh]

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

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

[Pavel_T]

Совсем запутался я с этими классами

Вот посмотрите, плиз.

Выделил еще класс "Извещение".

Кроме того остается неучтенная инфа о статистических данных (таблица) и расчетных суммах, которые "вычисляются по данным, хранящимся в архиве" если по постановке ...

Куда их деть?

[Galogen]

Galogen, скажите, а что по поводу процентов за услугу? Ведь действительно, он должен где-то участвовать в нашем ВИ...

Имхо это инкапсулируется в Вычислить сумму платежа  (саму формулу можно приложить в доп требованиях к ВИ)

[Pavel_T]

Galogen, то ест отдельного ВИ для "Выдача данных по заданному виду платежа" не будет?

Получается у оператора только один ВИ?

[Galogen]

Galogen, то ест отдельного ВИ для "Выдача данных по заданному виду платежа" не будет?

Получается у оператора только один ВИ?

А разве я что-то в таком роде сказал?

Почему же выдача данных - это совершенно иная транзакция.

[vit]

Вот моя версия диаграммы классов (вложение). Правда, она не полная, есть недочеты (отсутствие функций, неправильно показаны статические переменные и ф-и классов и др).

P.S. Галоген, большое спасибо за ответы. Я уверен, что ваши ответы будут полезны не только Pavel_T.

[Pavel_T]

А разве я что-то в таком роде сказал?

Почему же выдача данных - это совершенно иная транзакция.

Я правильно понимаю, что "Выдача данных..." - это некий отчет по запросу?

А тогда "Выдача полученной итоговой суммы" - это просто реализация в виде кнопки "Рассчитать итог по всем платежам"? Тогда есть ли смысл делать для этой задачи отдельный кейс?


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

[Galogen]

А тогда "Выдача полученной итоговой суммы" - это просто реализация в виде кнопки "Рассчитать итог по всем платежам"? Тогда есть ли смысл делать для этой задачи отдельный кейс?

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

[InsomniA]

между Оформлением платежа и Платежами - связь обощение (линия с полой стрелкой). Есть абстрактный ВИ Оформить платеж, и есть конкретные ВИ Оформить платеж за газ и т.п.

Здравствуйте.

Правильно ли будет это утверждение применить в следующем примере (чтобы не разводить много букв, конкретизировать не буду, пример приведу общий):

Есть некая сущность, например, Task. Его можно:
1. Посмотреть список моих task'ов
2. Посмотреть информацию о конкретном task'е.
3. Добавить task
4. Редактировать task
5. Удалить task
6. Сдать task на проверку
7. Комментировать task
8. Управлять файлами (чем угодно, комментариями, еще чем-то) task'а:
8.1. Смотреть список файлов task'а
8.2. Добавить файл
8.3. Редактировать файл
8.4. Скачать файл
...

С одной стороны, диаграмма должна облегчать восприятие текстового описания ВИ, то есть быть "удобочитаемой", с другой стороны она должна быть полной.
У меня вопрос, как правильно было бы составлять диаграмму для описанного примера?

Предполагаемые мною варианты:
1. Actor ---> Управлять task'ами<----extend---Управление файлами
2. Подробнейшим образом экстендить всеми перечисленными выше пунктами. Хорошо ли функции системы вытаскивать в UC? Хоть и часто это встречаю, но до сих пор сомневаюсь...
3. Использовать связь обобщение, о которой Вы здесь говорите.
4. - еще какой-то вариант.

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

Возможно, стоит оставить вариант 1 и детализировать уже Activity диаграммами, в которых будет несколько flow, в которых уже и будут описаны все функции до мелочей?

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