Господа, добрый день!

Грызу гранит науки и пытаюсь научиться анализу.

Имеется задание по разработке приложения, предназначенного для установки на АРМ оператора по приему коммунальных платежей.
Подробнее см. задание в 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. Сохранение в базе, это не задача оператора, то есть выходит, что это не кейс, а уже функция системы.


Правильно?