Добрый вечер, товарищи аналитики.

Мне предстоит выполнить небольшое задание, хотел бы задать несколько вопросов
и посоветоваться, правильное ли направление выбрал.

Задание:
"Имеется система банк-клиент. Клиентское приложение хранит и отображает информацию о счете пользователя и его операциях, а также инициирует операции по команде пользователя через Интернет. Банк проводит операции со счетами и хранит данные о счетах и операциях. Программы Клиент и Банк являются многопоточными и не используют стандартных СУБД.

Требуется описать последовательность действий программ Клиент и Банк по подготовке, отправке и обработке запросов/ответов по платежу со счета одного пользователя на счет другого пользователя. Платеж инициируется плательщиком и не требует согласия получателя.

Объем описания - 1-2 страницы."


В моём представлении, суть задания состоит в моделировании ВИ "Перевести средства со счета плательщика на счет получателя".

Как собираюсь выполнять. Придерживаясь методологии ICONIX, сделаю следующее:
1. Набросаю domain model, чтобы понять, какие сущности задействованы.
2. Напишу сценарий для этого ВИ, оперируя терминами из domain model (шаблон возьму у доброго дяди Вигерса).
3. Нарисую robustness diagram, чтобы выявить контроллеры.
4. Нарисую sequence diagram, чтобы все устаканить и присвоить операции классам.

Теперь мои наивные вопросы:
1. В задании указан объем: 1-2 стр., тут будет явно больше. Я полез не в ту степь?
2. Уточняется, что не используется стандартных СУБД. Как это может повлиять?
3. Стоит ли рассматривать Банк-Клиент как единую неделимую систему, или нужно ввести Актора, который действует как Клиент по отношению к банку?


Спасибо! Буду рад любым идеям.

Не совсем понятно задание. Для чего и кем будет использовано описание "последовательность действий программ Клиент и Банк"?

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

Мне вот тоже не совсем понятно 

Я бы у него уточнил, в какой форме он хочет оформленный результат и для кого потенциально будет использован данный документ (т.е. уточнил бы степень детализации).
И на какую позицию Вы претендуете?

В общем, мне было сказано, чтобы я сам выбрал способ описания (покажет, чем я владею).
Детализация не максимальная, описать основные моменты.

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

Итак, пока буду придерживаться плана, описанного в первом посте, пора за дело.

Я бы сделал п. 1 и 2, как раз будет 1-2 страницы.

Выкладываю domain model.

А вот и use case specification подоспела.
(Решил писать на английском, т.к. шаблон был на англ. и термины в domain model - тоже)

Есть ли какие-нибудь замечания?

Последую совету bas и остановлюсь на выполнении п.1 и 2.

Выкладываю domain model.

Апельсин, почему на диаграмме только связи агрегации между сущностями? Посмотрит еще раз внимательней и исправьте
Так же опишите каждую сущность, тем более вы используете их в описании ВИ
Компоненты (контролы), которые вы используете в спецификации лучше тоже кратко описать, если человек не знаком с ICONIX или подходом boundary-control-entity, сходу может не понять идею введения контроллеров

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

Соглашусь с Виталием, что нужно описать сущности и добавить атрибуты.
ИМХО Контролы и Соединение не имеет отношения к домиейн модел.

По ВИ:
1. Вы переводили когда-нить деньги электронным платежом? ИМХО там требуется больше информации для ввода.
2. В БПр я бы написал формулу вычисления комиссии.
3. Почему E.3 без степа?
4. В расширениях нет возврата в пункты основного сценария.
4. ИМХО на стороне банка делается больше операций, чем Вы написали. Возможно нужно еще подключить сюда АБС.

Апельсин, почему на диаграмме только связи агрегации между сущностями?

Потому что, ребята, это ICONIX. Дуга Розенберга. Он говорит что связи есть две has a - собственно агрегация, и is a - иерархия, наследование.

Если мы будем идти от концепции в реализацию, то типично ассоциации уточнять до агрегаций и композиций

(Решил писать на английском, т.к. шаблон был на англ. и термины в domain model - тоже)

Почему на английском ? Это требование работодателя?

Программы Клиент и Банк являются многопоточными и не используют стандартных СУБД.

Как это может повлиять на концептуальную модель?

Ну не знаю..
Я бы отталкивался от слов "Требуется описать последовательность..."
И сделал, например упрощенную sequence-диаграмму (только основные операции, не детализируя сущности в глубине) в которой использовал Клиента, программу Клиент и программу Банк.
Или UC в любом формате с теми же сущностями.

Исхожу из того, что мы из условий знаем только о существовании этих сущностей и ничего об их внутренней архитектуре.