Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: Pavel_T от 22 Января 2010, 17:59:03
-
Господа, добрый день!
Грызу гранит науки и пытаюсь научиться анализу.
Имеется задание по разработке приложения, предназначенного для установки на АРМ оператора по приему коммунальных платежей.
Подробнее см. задание в 2-ух картинках.
Наваял две диаграммы Use Case и Class (тоже в картинках к сообщению).
Покритикуйте пожалуйста, что не верно, что верно и на правильном ли я пути.
Очень хочу научиться.
Спасибо.
-
Профессионалы, покритикуйте плиз :(
-
1. Диаграмма ВИ на самом деле мало понятна.
2. Начинать нужно с выделения действующих лиц и их целей в использовании системы
3. По ДК - это что за диаграмма? какого уровня? Не совсем ясно что такое класс АРМ, и класс Архив. Почему оператор - это граничный класс
-
1. Диаграмма ВИ на самом деле мало понятна.
2. Начинать нужно с выделения действующих лиц и их целей в использовании системы
3. По ДК - это что за диаграмма? какого уровня? Не совсем ясно что такое класс АРМ, и класс Архив. Почему оператор - это граничный класс
1 и 2. Действующие лица: Клиент, Оператор, Администратор (согласно заданию других не вычитал).
Система будет установлена на АРМ Оператора, поэтому по сути Клиента можно не включать, поскольку он не действует никоим образом на Систему.
Цель Оператора - Оформить с помощью Системы платежи.
Цель Администратора - Настроить АРМ Оператора и снять статистику.
Где я ошибся? :(
3. Какого уровня? Не очень понял. Моя цель была перечислить все диаграммы классов, присутствующих в постановке.
Где ошибка? :(
-
Ой, опечатка:
3. Какого уровня? Не очень понял. Моя цель была перечислить на ДК все КЛАССЫ, присутствующих в постановке.
-
Цель Оператора - Оформить с помощью Системы платежи.
И все? больше Оператор никаким образом не будет использовать систему?
Цель Администратора - Настроить АРМ Оператора и снять статистику.
А что значит настроить АРМ оператора, как часто и сколько времени это занимает?
Что такое снять статистику? Какого рода статистика
3. Какого уровня? Не очень понял. Моя цель была перечислить все диаграммы классов, присутствующих в постановке.
ДК бывают концептуального уровня - т.е. бизнес-объекты, дале аналитическая ДК, далее проектная ДК, где появляются программные классы и т.д.
-
И все? больше Оператор никаким образом не будет использовать систему?
А что значит настроить АРМ оператора, как часто и сколько времени это занимает?
Что такое снять статистику? Какого рода статистика
ДК бывают концептуального уровня - т.е. бизнес-объекты, дале аналитическая ДК, далее проектная ДК, где появляются программные классы и т.д.
Оператор. Еще можно добавить расширение "Запрос данных (суммы) из архива"
ДК - вроде как преподаватель говорил, что изображаются классы данных.
-
Павел, у Вас достаточно полная и точная постановка задачи.
Практически это описание того, что должна делать Ваша система. Уже по этой постановке можно начинать делать проектное решение.
Тем не менее, если задача также состоит в том, чтобы использовать UML, то надо внимательно перечитать задание и произвести ясный текстуальный анализ.
Функции оператора или задачи оператора:
1. оформление платежа по электроснабжению
2. оформление платежа по газоснабжению
3. оформление платежа по услугам телефонной связи
4. выдачу полученной итоговой суммы по каждому из видов платежей
5. выдачу данных по заданному виду платежа с указанием разницы между суммой, указанной клиентом и расчетной действующему тарифу оплаты суммой по действующему тарифу
Действия администратора:
1. Ежедневно установить текущую дату на рабочем месте оператора (Число, Месяц, Год)
2. Ежедневно задать текущий тариф по каждому из видов платежей - Стоимость одного киловатта электроэнергии - Стоимость газоснабжения для одною проживающего - Стоимость одной минуты разговора по телефону
3. Ежедневно задать Текущий процент, взимаемый за услугу по оформлению платежа. Текущий тариф по всем платежам и текущий процент в течение дня не изменяются.
4. В конце рабочего дня администратором на рабочем месте оператора снимается статистика загруженности оператора в течение дня
Т.е. в принципе имеем 9 ВИ. Возможно следует включить такие ВИ как регистрация оператора в системе, Авторизация пользователя в системе. Можно подумать и об обслуживании базы (архива), но опционально.
Кроме того описание позволяет построить модель предметной области, т.е. модель объектов предметной области со связями (но без операций)
Расписав каждый из ВИ, можно будет в дальнейшем принять решение об объединении 1-3 в один ВИ (если это не будет усложнять картину) и т.д.
Модель предметной области, основанной на описании, может включать такие объекты, как:
Клиент, Платеж, Извещение, АРМ, Оператор, Тариф платежа, Процент за платеж, Отчет и соответствующие связи между ними. Данная модель отражает в первую очередь бизнес-объекты - люди, документы и т.п.
Архив тоже можно рассматривать как некий объект, но лично я бы не стал этого делать. Архив - это производная от совокупности хранимых объектов, это база данных или другое хранилище информации.
Очевидно, что возможная архитектура будет включать:
1. приложение оператора, реализующее функционал оператора
2. приложение администратора (если необходимо)
3. само централизованное хранилище (файл БД или сервер БД вместе с БД)
Если разработка идет в объектно-ориентированном стиле, то очевидно задачей будет реализация объектной модели приложения, которая будет включать:
классы форм и контролов этих форм
классы обработчики событий формы
классы управления и бизнес-логики
возможно классы предметной области
Все эти классы должны выстраиваться исходя из принципов разделения обязанностей
-
Galogen, спасибо, но есть вопросы:
1. По действиям оператора: Разве нельзя свернуть 1-3 в один общий кейс?
2. По действиям администратора: Разве нельзя ввод данных, указанных в п.п. 1-3 свернуть в один общий кейс?
3. По ДК - не совсем понял.
В ДК мне нужно указать, те классы, которые содержат в себе данные, участвующие в системе тем или иным образом, а точнее по заданию написано "Разработать Диаграмму классов (в конечном итоге с указанием стереотипов классов, типов атрибутов, сигнатуры операций)
Скажем Классы: Извещение, Платеж (3 вида) или один общий, Архив, АРМ оператора (оператор, администратор можно не выделять как класс, можно выделить класс - "пользователь" с атрибутами "оператор" и "администратор"). Я верно понимаю?
PS. Кроме того, мне еще предстоит нарисовать 6 диаграмм :(
-
1. По действиям оператора: Разве нельзя свернуть 1-3 в один общий кейс?
А не надо торопиться. Объединить можно и наверное нужно, я Вам это уже писал. Но крайне осторожно, а то можно ребенка выплеснуть вместе с водой.
2. По действиям администратора: Разве нельзя ввод данных, указанных в п.п. 1-3 свернуть в один общий кейс?
А Вы сами подумайте. Разве для установки времени, мне потребуется установка текущих тарифов? А если процент не изменился, что же ВИ не будет завершен?
3. По ДК - не совсем понял.
В ДК мне нужно указать, те классы, которые содержат в себе данные, участвующие в системе тем или иным образом, а точнее по заданию написано "Разработать Диаграмму классов (в конечном итоге с указанием стереотипов классов, типов атрибутов, сигнатуры операций)
Вам ехать или шашечки? Вы хотите отвязаться от преподавателя или научиться?
Почему Вы думаете, что у Вас в системе те классы, что Вы нарисовали? Начинать нужно от печки - печка - это объекты предметной области и их связи. Чаще всего именно информацию об этих объектах следует хранить. Однако будут ли в Вашем приложении представлены объекты предметной области или нет - пока не ясно, это определяют другие требования.
В Вашем случае, что должна отображать ДК? Реализацию вариантов использования. Т.е. Вы должны прийти к ДК, которая отражает каким образом достигается выполнение того или иного ВИ
Скажем Классы: Извещение, Платеж (3 вида) или один общий, Архив, АРМ оператора (оператор, администратор можно не выделять как класс, можно выделить класс - "пользователь" с атрибутами "оператор" и "администратор"). Я верно понимаю?
Верно, но к этому следует прийти путем анализа и учета множества факторов. Как система понимает, что с ней работает именно Оператор? А что будет, если появится еще один вид пользователя с иными правами и иными потребностями в функциях и интерфейсе?
Далее платеже указывается информация об извещении, следует ли указывать в платеже само извещение? номер там, если да, то как платеж связан с этим извещением? Если это неважно, то извещение внешний документ и в программной реализации не будет участвовать, но в предметной модели - ему место.
Для отчетов Вы тоже можете создать соответствующие классы, а может это будет просто метод класса, создающий отчеты
PS. Кроме того, мне еще предстоит нарисовать 6 диаграмм :(
Какие? И почему так пессимистично?
[/quote]
-
Вот, прикрепляю пока ДВИ.
А какие еще нужны, так это вот:
Диаграмма деятельности
Диаграмма состояний
Диаграмма коопераций
Диаграмма последовательности
Диаграмма компонентов
Диаграмма развертывания
-
между Оформлением платежа и Платежами - связь обощение (линия с полой стрелкой). Есть абстрактный ВИ Оформить платеж, и есть конкретные ВИ Оформить платеж за газ и т.п.
Между Настройка АРМ оператора и остальными ВИ - связь расширение кажется приемлемой, но!!! Главный ВИ может проходить и проходит без расширяющих ВИ, а если не одно из расширений не будет выполнено, что тогда будет делать Администратор?
У вас не так много ВИ, не надо их пока структурировать. Поймите ценность диаграммы почти нулевая, она нужна на этапе обсуждения + задействовать правое полушарие :)
-
между Оформлением платежа и Платежами - связь обощение (линия с полой стрелкой). Есть абстрактный ВИ Оформить платеж, и есть конкретные ВИ Оформить платеж за газ и т.п.
Между Настройка АРМ оператора и остальными ВИ - связь расширение кажется приемлемой, но!!! Главный ВИ может проходить и проходит без расширяющих ВИ, а если не одно из расширений не будет выполнено, что тогда будет делать Администратор?
Попробую порассуждать:
1. Оператор:
Что он хочет от Системы?
1. Ввести данные по тарифам платежей, на основании квитанции, предоставленной клиентом.
2. Рассчитать сумму оплаты по тарифам (на основании установленной оплаты за единицу)
3. Ввести сумму оплаты, предоставленную клиентом
4. Рассчитать сдачу
Верно?
У вас не так много ВИ, не надо их пока структурировать. Поймите ценность диаграммы почти нулевая, она нужна на этапе обсуждения + задействовать правое полушарие :)
[/quote]
-
Попробую порассуждать:
1. Оператор:
Что он хочет от Системы?
1. Ввести данные по тарифам платежей, на основании квитанции, предоставленной клиентом.
2. Рассчитать сумму оплаты по тарифам (на основании установленной оплаты за единицу)
3. Ввести сумму оплаты, предоставленную клиентом
4. Рассчитать сдачу
Верно?
Думаю не совсем.
По заданию тарифы определяет администратор. Оператор вводит информацию с извещения клиента. Скорее всего показания счетчиков. Система на основании ранее заданных администратором тарифов рассчитывает сумму платежа - требуемую.
Клиент возможно вносит не всю сумму, а только часть, возможно большую.
Система исчисляет сдачу, если это предусмотрено и сохраняет платеж, а также печатает квитанцию или чек на извещении (как это обычно и бывает)
-
Скорее всего показания счетчиков
Ну я там назвал это "1. Ввести данные... на основании квитанции". Просто тарифы меня сбивают все время.
Система на основании ранее заданных администратором тарифов рассчитывает сумму платежа
То есть "2. Рассчитать сумму оплаты по тарифам" - это не то, для чего "пользователь обращается к системе"?
Ведь оператор хочет узнать - "А какая сумма то к оплате"?
Потом оператору нужно, собственно, произвести оплату, то есть внести сумму оплаты в систему, которую дал ему на руки клиент.
Потом оператору нужно узнать сдачу, которую ему нужно сдать клиенту.
а также печатает квитанцию
Вот здесь согласен. Это тоже нужно оператору - "Выдать квитанцию об оплате".
Вроде все.
PS. Сохранение в базе, это не задача оператора, то есть выходит, что это не кейс, а уже функция системы.
Правильно?
-
Ну я там назвал это "1. Ввести данные... на основании квитанции". Просто тарифы меня сбивают все время.
В нашем деле ясность и однозначность формулировко имеет первостепенное значение.
То есть "2. Рассчитать сумму оплаты по тарифам" - это не то, для чего "пользователь обращается к системе"?
Ведь оператор хочет узнать - "А какая сумма то к оплате"?
Оператору думаю это без надобности. Оператор желает внести сумму платежа и оформить этот платеж надлежайшим образом. А система в этом ему помогает. Это основная задача оператора - зафиксировать прием платежей.
Ведь как Вы понимаете, оператор мог делать это как-то иначе:
- получает извещение
- регистрирует извещение в журнале регистрации
- вычисляет сумму оплаты (правда мое мнение это уже делается ранее, когда извещение приходит клиенту. Обычно клиент платит за прошлые расходы и указывает новые показатели, которые в следующем месяце приходят новой суммой с учетом долга в извещении. У Вас расчет как бы по факту, ну можно и так)
- указывает вычисленную сумму в журнале
- принимает деньги от клиента и оформляет квитанцию или выбивает чек
- записывает уплаченню сумму в журнал регистрации
- корешок извещения кладет в ящик входящих извещений
Теперь бац - появляется система
Потом оператору нужно, собственно, произвести оплату, то есть внести сумму оплаты в систему, которую дал ему на руки клиент.
Оператору произвести оплату не нужно, ему нужно принять оплату и должным образом ее зарегистрировать
Потом оператору нужно узнать сдачу, которую ему нужно сдать клиенту.
Да оператор хотел бы выяснить сдачу с переданной клиентом суммы и оплачиваемой им - но это не цель оператора, это защита интереса клиента -(ему дадут правильную сдачу) и оператора (он тоже сдаст правильную сдачу, не обманув клиента или сам не обманувшись)
PS. Сохранение в базе, это не задача оператора, то есть выходит, что это не кейс, а уже функция системы.
Да это функция системы. В нашем случае это постусловие, т.е. состояние в которое перейдет система после исполнения варианта использования.
Очень часто значимость ВИ определяется тем, изменит ли свое состояние система или нет.
Другой фактор значимости увидеть не долько успешный сценарий, но и понять какие возможны альтернативы, ошибки и исключения (см. например здесь (http://www.uml2.ru/index.php?option=com_content&task=category§ionid=3&id=31&Itemid=51)
-
Вот, переосмыслил диаграмму.
Решил объединить запросные данные к архиву в один кейс. Пока без детализации. Правильное ли решение?
Как в остальном?
-
Вот, переосмыслил диаграмму.
Не стоит слишком замарачиваться с диаграммой ВИ. Больше усилий потратьте на спецификацию ВИ и связанных с ним артефактов: доп требований, пользовательских интерфейсов, бизнес-объектов
В целом пусть будет такая диаграмма. Кстати к Печать квитанции я бы от Оформить платеж сделал отношение включения, поскольку квитанцию следует печатать всегда. Либо вооще убрал Печатать квитанцию - это шаг Оформления платежа
-
Кейс 1:
Предусловия:
1) Выполнен Кейс "Настройка АРМ пользователя"
2) Оператор ввел логин и пароль.
Основной сценарий (электроснабжение):
1. Оператор вводит данные: ФИО клиента, месяц оплаты, текущее и предыдущее показания счетчика, сумму, указанную клиентом в извещении
2. Система сохраняет введенные данные в архив
2. Оператор инициирует расчет суммы, на основании установленного тарифа
3. Система расчитывает и выводит сумму оплаты, на основании установленного тарифа
4. Оператор инициирует оплату
5. Система сохраняет транзакцию в архиве
6. Оператор инициирует печать квитанции с указанием номер АРМ, даты платежа, номера платежа и оплаченной суммы, с учетом услуги по оформлению платежа.
-
Почитайте рекомендации по написанию ВИ (http://www.uml2.ru/index.php?option=com_content&task=view&id=399&Itemid=47)
Кейс 1:
Что за кейс? как именуется, какова его цель?, кто действующее лицо, если другие участники кейса, интересы которых следует соблюсти
Предусловия:
1) Выполнен Кейс "Настройка АРМ пользователя"
2) Оператор ввел логин и пароль.
Действительно так? Может все-таки написать проще? Заданы тарифы, дата - хотя мне как-то все это представляется странноватым
Оператор ввел логин и пароль - больше смахивает на реализацию, может просто авторизирован в системе?
Основной сценарий (электроснабжение):
1. Оператор вводит данные: ФИО клиента, месяц оплаты, текущее и предыдущее показания счетчика, сумму, указанную клиентом в извещении
2. Система сохраняет введенные данные в архив
Архив понятие реализации. Вообще сохранение данных начато рано, а если у клиента не окажется денег? (забыл кошелек)
2. Оператор инициирует расчет суммы, на основании установленного тарифа
3. Система расчитывает и выводит сумму оплаты, на основании установленного тарифа
все это описание в стиле "программа выполняет действия", а не в стиле что должна делать будущая система, слишком мелко и подробно. И мне думается система после введенных данных платежа без всякой подсказки оператора должна рассчитать сумму
4. Оператор инициирует оплату
5. Система сохраняет транзакцию в архиве
Как то выглядит странно и похоже на описание того, что сделано, а не на то что должно быть сделано
6. Оператор инициирует печать квитанции с указанием номер АРМ, даты платежа, номера платежа и оплаченной суммы, с учетом услуги по оформлению платежа.
К чему такие подробности - покажите их на форме квитанции. А где кстати реакция системы?
Незачтено :) Попробуйте еще разок
-
ВИ: Оформить платеж за электроснабжение
ID: 1
Краткое описание:
Оформление платежа за электроснабжение на основании предоставленного клиентом извещении
Основное действующее лицо: Оператор
Второстепенные действующие лица: Клиент
Предусловия:
1. Оператор авторизован в системе
2. Клиентом предоставлено извещение по электроснабжению
3. На рабочем месте оператора установлен тариф, процент за услугу, текущая дата (а что Вам кажется странным, где ошибка?)
Основной поток:
1. Оператор вводит данные: ФИО клиента, месяц оплаты, текущее и предыдущее показания счетчика, сумму, указанную клиентом в извещении
2. Система определяет сумму оплаты, на основании установленного тарифа
3. Система определяет сдачу, как разницу между введенной и рассчитанной суммой
4. Оператор принимает от клиента наличные и совершает оплату
5. Система выдает квитанцию об оплате
6. Система регистрирует транзакцию
Постусловия:
Нет
Альтернативные потоки:
Нет.
А так?
-
Второстепенные действующие лица: Клиент
Конечно, этого нет явно в описании, но заинтересованным лицом будет в данном ВИ и коммунальная служба - она заинтересована в получении денег. Но это я так, просто рассуждаю :)
Предусловия:
1. Оператор авторизован в системе
2. Клиентом предоставлено извещение по электроснабжению
3. На рабочем месте оператора установлен тариф, процент за услугу, текущая дата (а что Вам кажется странным, где ошибка?)
странно, что нужно устанавливать текущую дату, странно, что нужно устанавливать тариф. Смотрите сами - плата же обычно за месяц, а тариф каждый день у вас выставляется, что это означает?
Основной поток:
1. Оператор вводит данные: ФИО клиента, месяц оплаты, текущее и предыдущее показания счетчика, сумму, указанную клиентом в извещении
2. Система определяет сумму оплаты, на основании установленного тарифа
3. Система определяет сдачу, как разницу между введенной и рассчитанной суммой
Тут вы что-то пропустили. Сумма - указанная в извещении, это сумма которую клиент готов оплатить - полностью, или частично. Сдача будет вычисляться как я понимаю, после того когда клиент передаст сумму денег превышающую сумму указанную в извещении. Либо я чего-то не догоняю
4. Оператор принимает от клиента наличные и совершает оплату
Опять же реакция системы не видна. Оператор принял оператор совершил, а система что делает? Выдает квитанцию?
5. Система выдает квитанцию об оплате
6. Система регистрирует транзакцию
Объединить в один шаг
Постусловия:
Нет
как же нет.
зарегистрирован новый платеж, напечатана квитанция, выдана сдача
Альтернативные потоки:
Нет.
ну с этим еще предстоит разобраться :)
А так?
Уже много лучше :)
-
Переосмыслил. Все таки решил выделить запросы оператора к архиву, как отдельный кейс.
Все таки цель в данном конкретном кейсе это просто провести платеж, без всяких дополнительных тарифов и расчетов.
Я так думаю :)
ВИ: Оформить платеж за электроснабжение
ID: 1
Краткое описание:
Оформление платежа за электроснабжение на основании предоставленного клиентом извещении
Основное действующее лицо: Оператор
Второстепенные действующие лица: Клиент
Предусловия:
1. Оператор авторизован в системе
2. Клиентом предоставлено извещение по электроснабжению
Основной поток:
1. Оператор вводит данные: ФИО клиента, месяц оплаты, текущее и предыдущее показания счетчика, сумму, указанную клиентом в извещении
2. Оператор вводит сумму, переданную клиентом для оплаты
3. Система определяет сдачу
4. Оператор подтверждает оплату
5. Система регистрирует платеж и выдает квитанцию об оплате
Постусловия:
Зарегистрирован новый платеж, напечатана квитанция, выдана сдача
Расширения:
1а. Оператор вводит данные с другого извещения, предоставленного клиентом
1b. Система определяет общую сумму к оплате за все извещения
1с. Возврат на п.2 основного сценария
-
Что-то мне ваши расширения не нравятся.
Я так понимаю, вы хотите передать то, что можно оформить сразу несколько платежей (в данном случае одного типа). Система подсчитает общую сумму за все сделанные платежи. Когда будет сделана оплата, система рассчитает требуемую сдачу и напечатает нужно количество квитанций?
Если я правильно понял, то тут скорее следует на шаге 1 прописать что-то типа цикла:
для всех поданных извещений, оператор вводит: бла бла
система вычисляет сумму платежа, прибавляя ее к предыдущей
оператор указывает сумму денег, полученную от клиента
система вычисляет сдачу
оператор подтверждает оплату
система регистрирует(сохраняет) платеж(и) и выдает квитанции об оплате
-
А если несколько платежей разных типов ? То как следуте поступить в этом случае, чтобы система рассчитала общую сумму по всем платежам?
-
И еще вопрос.
Как лучше поступить с разными видами платежей (за разные услуги)?
Все таки описать в общем кейсе?
Каким образом правильно это сделать?
-
Ё-маё. Мне за сегодня надо все диаграммы закончить :(
-
И еще вопрос.
Как лучше поступить с разными видами платежей (за разные услуги)?
Все таки описать в общем кейсе?
Каким образом правильно это сделать?
Это может быть один ВИ, но с различными альтернативами. Каждый из платежей является самостоятельным. Выделить типичный основной сценарий, например, платеж за электроснабжение, было бы не верно.
Можно было бы указать так:
1. Оператор инициирует ВИ "оформить платеж"
2. Система предлагает выбрать тип платежа
3. Оператор указывает один из типов
4. Система предлагает ввести детали платежа
5. Оператор вводит необходимые данные согласно извещению
6. Система вычисляет сумму платежа, добавляя ее к общей сумме, предъявляемой к оплате
7. Система предлагает добавить следующий платеж
8. Если есть еще платежи
8.1 Оператор повторяет пункты 3-6
9. Иначе
9.1 Оператор Завершает оформление платежей
9.2 Система выводит общую сумму платежа и предлагает ввести сумму денег о клиента
9.3 Оператор подтверждает совершение оплаты
9.4 Система сохраняет данные платежей, вычисляет сдачу, печатает квитанции
Т.е. вариантов может быть много, правильным будет тот, который наиболее полно описывает цели и удовлетворяет интересы участников
-
Galogen, спасибо!
Но остался вопрос с п.6. Система вычисляет сумму платежа, добавляя ее к общей сумме, предъявляемой к оплате
Нужен ли этот пункт вобще?
И второе. Навая активити-диаграмму.
Посмотрите пожалуйста... ???
-
Разбавлю ваш диалог, господа.
Мой вариант основного сценария приёма платежа по данной постановке:
1. Оператор выбирает тип платежа и инициирует ввод данных
(Имхо изящнее и ближе к реалу, чем вариант Эдуарда, при реализации тут будет 3 батона или выпадающий список, в любом случае для пользователя это будет буквально один клик.)
2. Система запрашивает набор параметров платежа в соответствии с выбранным типом.
3. Оператор определяет параметры платежа в соответствии с извещением.
4. Система рассчитывает и отображает оператору:
- Сумму, начисленную согласно текущим тарифам, и разницу с данными, предоставленными клиентом;
- Сумму комиссии за приём платежа;
- Итоговую сумму, которую должен внести клиент.
(Тут Вы, господа, явно упустили аж 2 важнейших момента из постановки: 1) То, что насчитал клиент (или система начислений) в своём извещении может не сойтись с тем, что насчитает наша система (ведь у нас администратор каждый день это настраивает), об этом обязательно нужно оповестить клиента 2) За приём платежа через наш АРМ взимается комиссия, итоговую сумму клиент не знает и может с ней быть не согласен.)
5. Оператор знакомит с итоговыми суммами клиента (клиент не возражает), и инициирует добавление платежа в группу.
(Как я уже писал ранее - важный шаг с точки зрения бизнеса, да ещё и расширения тут могут быть.)
6. Система отображает общую сумму оплаты для группы и предлагает ввести сумму фактической оплаты.
7. Шаги 1-7 повторяются для всех извещений текущего клиента.
(Тут расширения из серии "клиент передумал насчёт вон того платежа").
8. Оператор вводит сумму фактической оплаты.
9. Система рассчитывает и отображает сдачу.
10. Оператор подтверждает приём группы платежей.
11. Система запрашивает подтверждение - оператор подтверждает.
(Опять упущенный и весьма важный шаг, диктуемый суровой реальностью.)
12. Система добавляет информацию о платежах в архив и формирует квитанции.
Работу с группой платежей я бы вынес в отдельный ВИ, ибо в рамках группы вижу расширения, связанные, как минимум, с изменением, отменой и восстановлением отдельных платежей. Единый ВИ с описанием расширений тут может превратиться в месиво.
-
Павел, смотрите сами.
Мы при описании ВИ фиксируем требования.
Оператор должен иметь возможность зарегистрировать платеж.
Оператор должен иметь возможность зарегистрировать несколько платежей в одной транзакции.
Нормальная такая ситуация? Да, конечно. Ведь клиент приходит с кучей платежей. Оператор оформляет их и обычно сразу называет общую сумму, которую клиенту следует заплатить. Как будет реализован процесс вычисления общей суммы не так важно. Например:
Оператор начинает транзакцию
Система предлагает указать тип платежа
Оператор выбирает тип платежа
Система отображает некую форму
Оператор вводит данные и сохраняет результат
Система добавляет результат в некий журнал транзакции и предлагает продолжить
Если оператор желает, то он выбирает следующий платеж все повторятся и платеж добавляется в это журнал транзакции
Если оператор отклоняет продолжение, то система выводит некое сообщение в котором указана сумма всех платежей, есть место для ввода денег от клиента и т.п.
С другой стороны можно реализовать такую ситуацию, что каждый платеж оформляется строго индивидуально и тут возникает вопрос - удобно ли так, сокращает ли это время на обработку платежей одного клиента или наоборот увеличивает и т.п.
Диаграмма активностей - ну вижу, она ничего особо нового не дополняет как мы видим в данном случае и скорее формальная, чем необходимая
-
И второе. Навая активити-диаграмму.
Посмотрите пожалуйста... ???
1. Первые 4 пункта, предлагаю свести в один на совесть пользователя - так и информативность не пострадает и читабельность диаграммы возрастёт. А то действие системы "Принимает запрос" - это уже что-то за гранью добра и зла, можно подумать, она там список услуг с веб сервера сторонней системы запрашивает.
2. Вычислять общую сумму к оплате система должна до внесения очередного платежа - вдруг клиенту нужно будет остановиться (мало ли - не рассчитал или не учёл комиссионного вознаграждения).
3. Категорически не нравятся конструкции, в которых "Система предлагает". Не будет же у пользователя в действительности только один вариант, слишком громоздкий интерфейс получится. Скорее у него будет одна экранная форма, из которой он сможет и посмотреть уже введённые платежи и общую сумму оплаты указать и инициировать введение другого платежа. Отказ от данных дейстивий опять нам упростит диаграмму без ущерба для понимания.
-
RUsh, спасибо за ваш вариант... растерялся прямо :-\
Galogen, скажите, а что по поводу процентов за услугу? Ведь действительно, он должен где-то участвовать в нашем ВИ...
-
Пытаюсь нарисовать диаграмму. Классов. Посмотрите плиз, классы. Верно выделил?
1. Извещение
2. Платеж (3 вида) через обобщение в один общий
3. Архив
4. АРМ оператора
5. "Пользователь" со свойствами - Оператор, Администратор.
Просто мне по ним, видимо, стейтчарт диаграмму надо будет еще наваять. :(
-
Пытаюсь нарисовать диаграмму. Классов. Посмотрите плиз, классы. Верно выделил?
1. Извещение
2. Платеж (3 вида) через обобщение в один общий
3. Архив
4. АРМ оператора
5. "Пользователь" со свойствами - Оператор, Администратор.
Просто мне по ним, видимо, стейтчарт диаграмму надо будет еще наваять. :(
Извещений я бы тоже выделил 3.
Тариф и комиссионное вознаграждение так же достойны если не отдельных классов, то хотя бы атрибутов в классе рабочий день. Я бы выделил в качестве отдельных классов все 3 означенные сущности.
По части платежа, для "повыпендриваться перед преподом": можно выделить единый класс Платёж, отдельный класс Параметр платежа и, для метаинформации, Тип платежа, Тип параметра платежа и класс для связи двух последних, регулирующий Параметры платежа. В атрибуты класса Платёж кидаем общие атрибуты, в экземпляры класса Параметр платежа - частные. Получается конструкция позволяющая забыть, с какими конкретно платежами мы имеем дело. Для данной задачи излишне, для реальной системы - суровая необходимость. Но это, повторюсь, из разряда "повыпендриваться".
-
RUsh, а как в стейтчарт задействовать класс "Рабочий день"?
-
RUsh, а как в стейтчарт задействовать класс "Рабочий день"?
Не уверен, что он того достоин. У него можно выделить всего пару состояний - открыт\закрыт. Можно ещё, конечно, повысасывать известно что известно откуда и нафантазировать всяческое "параметры определены" и "отчётность сформирована", но это уместнее подразумевать в базовых состояниях.
-
Совсем запутался я с этими классами :(
Вот посмотрите, плиз.
Выделил еще класс "Извещение".
Кроме того остается неучтенная инфа о статистических данных (таблица) и расчетных суммах, которые "вычисляются по данным, хранящимся в архиве" если по постановке :(...
Куда их деть?
-
Galogen, скажите, а что по поводу процентов за услугу? Ведь действительно, он должен где-то участвовать в нашем ВИ...
Имхо это инкапсулируется в Вычислить сумму платежа (саму формулу можно приложить в доп требованиях к ВИ)
-
Galogen, то ест отдельного ВИ для "Выдача данных по заданному виду платежа" не будет?
Получается у оператора только один ВИ?
-
Galogen, то ест отдельного ВИ для "Выдача данных по заданному виду платежа" не будет?
Получается у оператора только один ВИ?
А разве я что-то в таком роде сказал?
Почему же выдача данных - это совершенно иная транзакция.
-
Вот моя версия диаграммы классов (вложение). Правда, она не полная, есть недочеты (отсутствие функций, неправильно показаны статические переменные и ф-и классов и др).
P.S. Галоген, большое спасибо за ответы. Я уверен, что ваши ответы будут полезны не только Pavel_T.
-
А разве я что-то в таком роде сказал?
Почему же выдача данных - это совершенно иная транзакция.
Я правильно понимаю, что "Выдача данных..." - это некий отчет по запросу?
А тогда "Выдача полученной итоговой суммы" - это просто реализация в виде кнопки "Рассчитать итог по всем платежам"? Тогда есть ли смысл делать для этой задачи отдельный кейс?
PS. Господа эксперты, хочется узнать ваше мнение так же и по поводу диаграммы классов.
-
А тогда "Выдача полученной итоговой суммы" - это просто реализация в виде кнопки "Рассчитать итог по всем платежам"? Тогда есть ли смысл делать для этой задачи отдельный кейс?
А что такое "Выдача полученной итоговой суммы" - какова цель. Если вы можете себе ответить, что оператор сидит и в течение рабочего дня только и делает что запрашивает итоговую сумму - это может быть ВИ, но не в нашем случае. В нашем случае мы лишь определяем требование к системе и это такое требование как: система должна вычислить итоговую сумму по всем платежам - естественно это шаг ВИ офрмить платежи клиента
-
между Оформлением платежа и Платежами - связь обощение (линия с полой стрелкой). Есть абстрактный ВИ Оформить платеж, и есть конкретные ВИ Оформить платеж за газ и т.п.
Здравствуйте.
Правильно ли будет это утверждение применить в следующем примере (чтобы не разводить много букв, конкретизировать не буду, пример приведу общий):
Есть некая сущность, например, 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, в которых уже и будут описаны все функции до мелочей?
Заранее спасибо за помощь, извиняюсь, что уже несколько не в тему, просто не хотелось терять цитату и открывать новую тему.