Форум Сообщества Аналитиков

×


Перевод электронных денег на счёт получателя(Прочитано 11812 раз)
Добрый вечер, товарищи аналитики.

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

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

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

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


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

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

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


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



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



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

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



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



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

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

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



Я бы сделал п. 1 и 2, как раз будет 1-2 страницы.
Не важно какой ты сейчас - большой или маленький, важно - как ты растешь.
Б.А.С.



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



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

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

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



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

И еще - если это тестовое задание, напишите список вопросов и допущений, которые остались вам непонятными и не забудьте нефункциональные требования - сейчас у вас описана лишь логика
« Последнее редактирование: 01 Марта 2010, 08:56:34 от Виталий Григораш »
Если вы не знаете куда идете, то вы вряд ли туда дойдете [Форест Гамп]
www.grigorash.ru



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



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



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

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



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

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



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

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



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

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




 

Sitemap 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19