181

Для всех / Re: Диаграммы UML для бизнес-процесса "Кредитование физических лиц"

« : 08 Декабря 2014, 01:40:08 »

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

С помощью вариантов использования (прецедентов) описывается порядок взаимодействия пользователей с системой. Это пошаговая процедура, в которой каждый шаг выполняет кто-то из участников (пользователь или система). Если вам давали шаблон или пример описания прецедентов, воспользуйтесь им. Если не давали, то можно использовать табличный шаблон, например, как здесь: http://www.intuit.ru/studies/courses/32/32/lecture/1006?page=2

Я правильно понимаю, что в вашей модели предполагается, что клиент будет одним из пользователей и будет обращаться к системе для оформления кредитной заявки и для оплаты?

Если кредитную заявку формирует сам клиент, то тут можно пофантазировать, придумав диалог с системой, включающий шаги: выбор цели кредита, выбор кредитного продукта, выбор параметров кредита (срок и сумма), загрузка копий документов. Посмотрите по сайтам банков, как это может выглядеть (вот сбербанк, например: http://www.sberbank.ru/moscowoblast/ru/person/credits/).

Прецедент "Принять решение о возможности кредитования" с теми шагами, которые вы указали, предполагает взаимодействие с внешними системами или ролями, которых здесь пока нет. Не знаю, как оценивать кредитоспособность, но можно предположить, что это решение как-то принимает специальный эксперт. Проверка кредитной истории может включать запрос в бюро кредитных историй. Оценка кредитных рисков - это действие, выполняемое системой на основании множества данных, но его можно вписать в прецедент как один шаг ("система оценивает кредитные риски"), если от вас не требуется знание деталей.

Прецедент составления графика - самый простой: "бухгалтер выбирает договор", "бухгалтер выбирает команду Рассчитать график", "система рассчитывает график оплаты". Только график оплаты обычно прилагается к договору, а значит, это действие должно либо предшествовать оформлению договора, либо быть его частью. И, соответственно, делает это, наверное, не бухгалтер, а сотрудник кредитного отдела.

Для прецедента "Оформить договор" нужно помнить, что договор должен быть подписан клиентом. В реальной жизни это выглядит так: клиент приходит в отделение и вживую общается с сотрудником банка, который взаимодействует и с клиентом, и с системой - проверяет паспорт, ищет заявку, печатает документы, даёт их на подпись клиенту. Всё это тоже можно описать в виде пошаговой процедуры.

Ну и про альтернативные сценарии для каждого прецедента не забывайте, конечно - когда что-то идёт не так (у клиента плохая история, договор не найден, паспорт чужой и т. п.)

182

Для всех / Re: Диаграммы UML для бизнес-процесса "Кредитование физических лиц"

« : 07 Декабря 2014, 23:25:15 »

А вы по какой специальности учитесь - по айтишной или по банковской? Спрашиваю, потому что от этого зависит, что важнее в курсовой - следование нотациям или соответствие вашей модели реальной работе банка.

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

183

Реализация / Re: Композиция, Агрегация

« : 24 Октября 2014, 13:32:34 »

Здравствуйте, уважаемые форумчане. Разбираюсь с темой реализации в коде отношений композиции и агрегации. Из примеров найденных мною в интернете, я увидел, что в случае композиции необходимо в конструкторе класса-контейнера создать объекты и присвоить их полям этого класса. В случае агрегации объекты приходят извне, передаются конструктору контейнерного класса как аргументы и присваиваются полям этого класса. Я не могу понять, обязательно эти действия необходимо производить только в конструкторе класса или можно это делать и в других методах класса контейнера?

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

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

Можно использовать отдельную функцию инициализации объекта, вызываемую после его создания.

Можно подключать и отключать агрегируемые объекты отдельными методами, например, при обработке событий. Имеет смысл, если в процессе жизни агрегатора агрегируемые объекты могут изменяться. Или если агрегатор может выполнять какие-то функции вообще без агрегируемых объектов.


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

184

Примеры / Re: ДВИ формирования претензий по заказу

« : 17 Октября 2014, 13:15:09 »

Вы жалуетесь или хвастаетесь?

185

Примеры / Re: диаграмма последовательности процесса снятия денег в банкомате

« : 13 Октября 2014, 15:21:20 »

Не, не, не. Я имею ввиду сценарий:
...
* Пин клавиатура передает ПИН карте
* Какрта валидирует ПИН

онлайн валидация естественно есть, но только по сети посылается не ПИН и не шифрованный ПИН и не хешированный ПИН. По сети посылается подпись от уникальной комбинации (счетчик защищает от реплай атак). А ПИН проверяет карта. И это правильно, т.к. секьюрно.

Нет, в случае с онлайн верификацией ПИН-блок полностью формируется ПИН-клавиатурой. Карта в этом процессе вообще не участвует.

186

Примеры / Re: диаграмма последовательности процесса снятия денег в банкомате

« : 13 Октября 2014, 13:40:58 »

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

Выдача наличных по картам EMV всегда выполняется с онлайн проверкой ПИНа. Я точно не знаю, чьё это требование - скорее всего, платёжных систем.
Есть ещё карты типа электронного кошелька (были такие Сберкарта и Золотая Корона - возможно, и где-то и сейчас ещё живы). В этих системах ПИН проверяет карта. Но в этом случае нет авторизации в банке.

Вообще, в EMV есть несколько способов верификации держателя карты, включающие: онлайн ПИН (проверяется хостом), оффлайн ПИН (проверяется картой), подпись на чеке (проверяется кассиром), без проверки (да, формально это тоже метод верификации, со своим идентификатором).

В зависимости от вида операции и суммы, могут выбираться разные методы, а также их комбинации (теоретически можно заставить пользователя два раза ввести ПИН и ещё расписаться на чеке, хотя в реальной жизни это вряд ли имеет смысл). При этом учитываются и правила, записанные на карте, и возможности терминала.

Для операции "выдача наличных" всегда прописывается правило "онлайн пин". Я за всё время работы с картами EMV ни разу не видел исключений.

187

Примеры / Re: диаграмма последовательности процесса снятия денег в банкомате

« : 13 Октября 2014, 13:24:38 »

Это задание, предлагаемое на собеседовании, которое звучит так - "Изобразите диаграмму последовательности процесса снятия наличных в банкомате" (без сценария).

Тогда лучше не фантазировать о том, что происходит в невидимой системе, а описать видимый сценарий взаимодействия пользователя с банкоматом. Банк можно оставить для единственной операции "авторизация" (или "проверка запроса"), чтобы показать, что банкомат не принимает решения о выдаче наличных, а пересылает его в банк.

Под "меню" имеются в виду опции меню, которые появляются на экране банкомата после ввода пин-кода.

Я бы сказал, что в этом сценарии банкомат управляет действиями пользователя, а не наоборот. То есть не меню является ответом на запрос, а ввод ПИН, ввод суммы (а ещё выбор операции в самом начале) - это ответы пользователя на запросы банкомата.

А ещё надо не забыть вставить карту (и вынуть её).

188

Примеры / Re: диаграмма последовательности процесса снятия денег в банкомате

« : 12 Октября 2014, 20:32:14 »

Во-первых, в реальности процесс выглядит совсем не так.

Банкоматы всегда проверяют ПИН в режиме онлайн (то есть отсылают его на хост, а не спрашивают у карты, верный ли он). Участник "карта" при этом вообще выпадает из сценария.

Банкомат не обращается к хосту несколько раз для проверки суммы и "блокировок", это делается одним запросом. А хост уже сообщает результат всех необходимых проверок в коде ответа (этих кодов там несколько десятков). Но зачем вообще описывать эти детали, которые зависят от конкретного протокола взаимодействия банкомата с хостом? Возможно, вам дали какой-то учебный сценарий, описанный текстом? Тогда нужно приложить и его, чтобы было с чем сравнивать.


Во-вторых, что понимается под возвратом "меню"? Что в меню входит и почему оно является возвратом на сообщение "ввести пин"?

189

Реализация / Re: Реализация отношений между классами

« : 06 Октября 2014, 11:27:16 »

Здравствуйте, уважаемые форумчане. Не могу разобраться чем отличается реализация отношения ассоциации от агрегации и композиции в коде например в java или си шарпе? Во всех трех случаях необходимо создать в классе поле объектного типа. А в чем разница между ними я не могу понять. Ведь каждое отношение является самостоятельным.

Статически реализация может быть одной и той же (в C++, например, любое из этих отношений может быть реализовано указателями на объект). В динамике тип отношения однозначно влияет на время жизни связанного объекта, пожалуй, только в отношении композиции: вложенный объект должен создаваться вместе (или после) создания контейнера и уничтожаться вместе (или до) уничтожения контейнера. То есть существование вложенного объекта без контейнера не имеет смысла.

Примеры здесь:
http://ootips.org/uml-hasa.html

190

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 02 Октября 2014, 19:13:02 »

Спасибо. А как правильно все-таки формулируются CRUD ВИ и далее специфицируются?

Я обычно просто рисую одно яйцо вместо четырёх и пишу что-то вроде "CRUD: оценка ученика". Примерно как здесь предлагается:

http://www.ijsce.org/attachments/File/v2i2/B0535042212.pdf

Что касается дальнейшей спецификации - я уже говорил, что не использовал ДВИ для этой цели.

191

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 02 Октября 2014, 14:22:32 »

Вот студенты выполнили работу над ошибками и сформировали немного иное представление. 
Буду рад замечаниям и предложениям.

Мне нравится, из этих диаграмм уже хорошо видны различия ролей и цели пользователей.

Замечаний (не очень существенных) два:
1) использовать CRUD, о котором здесь уже говорили, чтобы визуально разгрузить диаграммы
2) вместо "запросить отчёт" использовать "получить отчёт"

192

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 01 Октября 2014, 19:06:37 »

может быть будет кому-то полезно
http://www.sparxsystems.com/resources/uml2_tutorial/uml2_usecasediagram.html

Вот это вообще для меня новость.

193

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 01 Октября 2014, 13:44:16 »

Я предпочитаю придерживаться мнения Коберна, который считает, что: "Вариант использования описывает ПОВЕДЕНИЕ системы при её ответах на запрос одного из участников, называемого основным дествующим лицом, в различных условиях.". Графическое изображение ВИ, соответственно, даёт общее представление о поведении через обозначение цели эктора.

Вариант использования как сценарий, безусловно, описывает поведение.

Диаграмма вариантов использования сама по себе поведение не описывает (хоть UML и относит её к классу bihavior diagram).

Графическое изображение варианта использования (как сценария) - imho это другие диаграммы (activity, sequence, communication в терминологии uml).

А зачем выявлять требования, но не описывать их? Agile?.

Выявлять, но не описывать в виде сценариев. Сценарии ведь не являются единственно возможным вариантом описания требований.

Agile - да, диаграмма ВИ может быть источником user stories.

194

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 30 Сентября 2014, 17:27:16 »

Логично, и как это будет потом синхронизироваться с окончательными вариантами вариантов использования?

Ты имеешь в виду описанные сценарии?

Во-первых, я считаю, что диаграммы ВИ и сценарии ВИ прекрасно могут существовать друг без друга. Если я не использую сценарии ВИ для описания требований, я ведь могу использовать ДВИ для их выявления? (Могу, конечно, я так и делаю.) И, на самом деле, use cases на диаграмме и use cases в виде сценариев - это разные вещи, названные одним именем. Я не знаю истории этой диаграммы - возможно, изначально она использовалась именно как "карта сценариев", но возможности её применения гораздо шире.

Во-вторых, если что-то действительно нужно синхронизировать, то это должно делаться автоматически. В этом случае ДВИ может генерироваться из набора сценариев подобно тому, как диаграммы классов генерируются из исходного кода. Но это совсем другая цель использования ДВИ, и если ты посмотришь на мой список, то увидишь, что там этой цели нет.

195

UML SysML и пр. / Re: Характерные ошибки use case диаграммы

« : 30 Сентября 2014, 13:48:40 »

Мне кажется, корень разногласий в разных целях применения ДВИ. Давайте попробуем сформулировать эти цели: для чего вы разрабатываете диаграммы ВИ?

Начну с себя. Я использую ДВИ
- для выявления и описания целей пользователей по отношению к разрабатываемой системе;
- для визуализации ролей пользователей и различий между ними.