Форум Сообщества Аналитиков
Общий раздел => Примеры => Тема начата: Апельсин от 27 Февраля 2010, 17:47:13
-
Добрый вечер, товарищи аналитики.
Мне предстоит выполнить небольшое задание, хотел бы задать несколько вопросов
и посоветоваться, правильное ли направление выбрал.
Задание:
"Имеется система банк-клиент. Клиентское приложение хранит и отображает информацию о счете пользователя и его операциях, а также инициирует операции по команде пользователя через Интернет. Банк проводит операции со счетами и хранит данные о счетах и операциях. Программы Клиент и Банк являются многопоточными и не используют стандартных СУБД.
Требуется описать последовательность действий программ Клиент и Банк по подготовке, отправке и обработке запросов/ответов по платежу со счета одного пользователя на счет другого пользователя. Платеж инициируется плательщиком и не требует согласия получателя.
Объем описания - 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, сходу может не понять идею введения контроллеров
И еще - если это тестовое задание, напишите список вопросов и допущений, которые остались вам непонятными и не забудьте нефункциональные требования - сейчас у вас описана лишь логика
-
Соглашусь с Виталием, что нужно описать сущности и добавить атрибуты.
ИМХО Контролы и Соединение не имеет отношения к домиейн модел.
-
По ВИ:
1. Вы переводили когда-нить деньги электронным платежом? ИМХО там требуется больше информации для ввода.
2. В БПр я бы написал формулу вычисления комиссии.
3. Почему E.3 без степа?
4. В расширениях нет возврата в пункты основного сценария.
4. ИМХО на стороне банка делается больше операций, чем Вы написали. Возможно нужно еще подключить сюда АБС.
-
Апельсин, почему на диаграмме только связи агрегации между сущностями?
Потому что, ребята, это ICONIX. Дуга Розенберга. Он говорит что связи есть две has a - собственно агрегация, и is a - иерархия, наследование.
Если мы будем идти от концепции в реализацию, то типично ассоциации уточнять до агрегаций и композиций
-
(Решил писать на английском, т.к. шаблон был на англ. и термины в domain model - тоже)
Почему на английском ? Это требование работодателя?
-
Программы Клиент и Банк являются многопоточными и не используют стандартных СУБД.
Как это может повлиять на концептуальную модель?
-
Ну не знаю..
Я бы отталкивался от слов "Требуется описать последовательность..."
И сделал, например упрощенную sequence-диаграмму (только основные операции, не детализируя сущности в глубине) в которой использовал Клиента, программу Клиент и программу Банк.
Или UC в любом формате с теми же сущностями.
Исхожу из того, что мы из условий знаем только о существовании этих сущностей и ничего об их внутренней архитектуре.
-
Как уже уточнил Galogen, в ICONIX подходе указываются только связи has-a, is-a. От этого я и плясал.
Строго говоря, диаграмма не является чистой domain model из-за присутствия контроллеров, Connection и StorageMethod.
Но без них было бы пустовато, поэтому и решил включить. Так что получилась несколько уточненная модель,
но подходу это не противоречит, т.к. тов. Розенберг призывает с каждым проходом все более уточнять domain model,
пока, наконец, она не превратится в диаграмму классов.
По этой же причине не добавлял атрибутов и методов к классам, для их выявления требуется выполнить п.3 и 4
из моего первого поста, чего я решил не делать, ввиду ограничения объема ответа.
Про описания классов совсем забыл, верно. Спасибо, что напомнили.
Про многопоточность - так и не решил, куда это прикрутить. Можно подумать про кэш соединений, например.
Но, по-моему, это далековато от от задачи "описать последовательность....", поэтому многопоточность не учитывал,
а "неиспользование стандартных СУБД" отразил только наличием StorageMethod.
Виталий Григораш, а стоит ли в данном контексте браться за описание нефункциональных требований?
Или написать применительно к данному ВИ, как практикуется в некоторых подходах?
bas, поправил спецификацию согласно замечаниям. Да, я пользовался электронными платежами, например, Яндекс.Деньги.
У них в качестве параметров, сверх описанного, можно указать и-мэйл вместо номера счета, а также наименование платежа.
Комиссия рассчитывается и отображается после ввода суммы – соответствующую строку добавил в спецификацию.
Бабихин Максим, на английском – моё личное решение. Был шаблон только на англ., решил не переводить, продолжил писать.
Итак, поправил спецификацию (немного), написал записку с пояснениями – в вольной форме.
Осталось еще добавить описания классов.
Спасибо за советы.