Файл: Лабораторная работа № 2.pdf

Лабораторная работа №2

В ходе выполнения второй лабораторной работы необходимо повторить этапы анализа

и   проектирования   ИС   для   выбранной   предметной   области   с   помощью   объектно-
ориентированного подхода [2].

В качестве выполнения этой лабораторной работы возьмем пример работы банкомата.

Предлагается   вариант   разработки   подсистемы   работы   банкомата   (программное

обеспечение   банкомата)   банковской   информационной   системы   на   основе   концепции
объектно-ориентированного проектирования систем. Цель данной подсистемы 

— позволить

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

В нашем  примере  предполагается, что наша  фирма 

— это производитель банкомата,

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

— от базы данных.

На   рис.   2.1   показана   постановка   задачи   для   сети   банкоматов.   Банкоматы   могут

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

Рис. 2.1 - Сеть банкоматов

Банкоматы   взаимодействуют   с   центральным   компьютером,   который   осуществляет

транзакции   с   соответствующими   банками.   Банкомат   принимает   от   клиента   его   карту,
взаимодействует   с   клиентом,   соединяется   с   центральной   системой   для   выполнения
транзакции,   выдает   наличные   и   печатает   чеки.   Система   требует   ведения   записей   и
обеспечения   безопасности.   Система   должна   корректно   обрабатывать   одновременное
обращение   к   одному   и   тому   же   счету.   Банки   предоставляют   собственное   ПО   для   своих
компьютеров.   В   результате   выделения   понятий   из   описания   задачи   можно   получить
потенциальные классы, перечисленные на рис. 2.2.

Рис. 2.2 - Выделенные классы в модели банкомата

На основании введенных классов запишем их определения согласно нашей предметной

области.

Счет 

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

разных типов, например чеки и сбережения. Клиент может иметь несколько счетов.

Банкомат  

— терминал,   позволяющий   клиентам   совершать   транзакции,   используя   в

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

Банк  

— финансовое   учреждение,   хранящее   счета   клиентов   и   выдающее   кредитные

карты для доступа к счетам с помощью банкоматов.

БанковкийКомпьютер  

— компьютер,   принадлежащий   банку   и   связанный   в   единую

сеть   с   банкоматами   и   кассовыми   терминалами   банка.   У   банка   может   быть   отдельный
компьютер, работающий со счетами клиентов, но нас интересует только тот, который связан с
сетью банкоматов.

КредитнаяКарта 

— карта, выданная клиенту банка и используемая для доступа к счету

через банкомат. Каждая карта содержит код банка и имеет порядковый номер. Каждый банк
имеет уникальный код внутри консорциума. Номер карты определяет счета, к которым открыт
доступ.   С   помощью   карты   клиент   может   получать   доступ   не   обязательно   ко   всем   своим
счетам. У карты может  быть только  один владелец, однако  может  существовать несколько
копий карты, поэтому надо учитывать возможность одновременной работы с одной и той же
картой с разных банкоматов.

Кассир  

— работник   банка,   уполномоченный   вводить   транзакции   и   принимать   и

выдавать   наличные   деньги   и   чеки   клиентам.   Все   транзакции,   наличные   деньги   и   чеки,
обрабатываемые кассирами, должны учитываться.

КассовыйТерминал  

— терминал,   с   помощью   которого   кассиры   вводят   транзакции.

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

ЦентральныйКомпьютер  

— компьютер,   с   которым   работает   консорциум   для

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

Консорциум  

— сообщество   банков,   владеющих   банкоматами   и   совершающих

операций   в   сети   банкоматов.   Сеть   банкоматов   поддерживает   транзакции   только   между
банками, входящих в консорциум.

Клиент  

— владелец   одного   или   нескольких   счетов   в   банке.   Клиента   может

представлять не только один человек, но и несколько человек или организация 

— для данной

задачи это не имеет значения. Одного и того же человека, владеющего счетом в нескольких
банках, следует рассматривать как несколько клиентов.

Транзакция 

— единичный цельный запрос на операции со счетами одного клиента.

На рис. 2.3 приведена диаграмма классов с нанесенными на нее ассоциациями, а на

рис   2.4  

— список   атрибутов  для   каждого  класса.   Следует   отметить,   что   на  этих  рисунках

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

Рис. 2.3 - Исходная диаграмма классов для банкомата

Рис. 2.4 - Модель классов банкомата с атрибутами

Теперь   необходимо   провести   организацию   классов   при   помощи   наследования   путем

выявления   их   общей   структуры.   На   рис.   2.5   показана   модель   классов   банкомата   после
добавления   наследования.   Анализ   этого   рисунка   ставит   перед   разработчиком   некоторые
проблемы, выявленные в этой модели.

Рис. 2.5 - Преобразованная модель классов банкомата

Класс CashCard (Банковская карта) на самом деле обладает двойственной сущностью:

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

— носитель   права   на   доступ   к   счетам   клиента   и

CashCard   (БанковскаяКарта)  

— кусочек   пластика,  на  котором  записан   код  банка  и   номер

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

Класс   транзакций   определен   не   достаточно   универсально,   чтобы   можно   было

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

— это   одно   действие   (снятие   наличных,

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

Различие   между   классами   Bank   (Банк)   и   BankComputer   (БанковскийКомпьютер),   а

также   между   Consortium   (Консорциум)   и   CentralComputer   (ЦентральныйКомпьютер)   не
влияет   на   аналитическую   модель.   Тот   факт,   что   взаимодействие   осуществляется
компьютерами,   на   самом   деле   является   артефактом   реализации.   Мы   превращаем
BankComputer в Bank, а CentralComputer в Consortium.

Класс   Customer   (Клиент)   пока   не   появлялся   в   аналитической   модели.   Однако   если

учесть возможные операции по открытию новых счетов, клиент может стать важным, поэтому
пока мы оставим его в покое. На рис. 2.6 показана исправленная диаграмма классов, которая
стала проще и яснее.

Рис. 2.6 - Модель классов банкоматов после очередных исправений

Теперь нам необходимо выявить состояния классов. В частности, класс Account (Счет)

может   находиться   в   состояниях   Normal   (нормальное  

— обычные   режим   доступа),   Closed

(закрытый  

— клиент   закрыл   свой   счет,   но   он   еще   не   был   исключен   из   записей   банка),

Overdrawn   (с   превышенным   кредитным   лимитом  

— клиент   превысил   кредитный   лимит   по

своему   счету)   и   Suspended   (приостановлен  

— доступ   к   счету   был   заблокирован   по

каким-либо причинам).

Перечислим   важнейшие   события   в   нашей   модели:   close   account   (закрытие   счета),

withdraw excess funds (превышение кредитного лимита), repeated incorrect PIN (повторный
неправильный   ввод   ПИН-кода),   suspected   fraud   (возможная   подделка),   administrative   action
(административные действия). На рис. 2.7 показана модель состояний для класса Account
(Счет).

Рис. 2.7 - Модель состояния предметной области

Для   создания   модели   взаимодействий   сначала   определим   действующих   лиц.   Один

человек   может   одновременно   быть   кассиром   и   клиентом   одного   и   того   же   банка.   Это
интересное совпадение, которое, однако, чаще всего не является важным. По отношению к
банку человек всегда выступает либо в одной, либо в другой роли. Для приложения банкомата
действующими лицами будут Customer (Клиент), Bank (Банк), Consortium (Консорциум).

Варианты   использования   банкомата   (см.   рис.   2.8):   1)   Initiate   session   (Инициализация

сеанса).   Банкомат   определяет   личность   пользователя   и   предлагает   ему   список   счетов   и
действий; 2) Query account (Опрос счета). Система предоставляет общие сведения о счете,
такие, как текущий баланс, дату последней транзакции, дату отправки последнего отчета по
почте;   3)   Process   transaction   (Обработка   транзакции).   Система   банкомата   выполняет
действие,   влияющее   на   баланс   счета,   такое,   как   вклад,   снятие   и   перевод.   Банкомат
гарантирует, что все завершенные транзакции в конечном итоге записываются в базу данных
банка;  4)  Transmit data  (Передача  данных).  Банкомат использует возможности консорциума
для взаимодействия с компьютерами соответствующего банка.

Рис. 2.8 - Диаграмма вариантов использования для банкомата

Определим   начальное   и   конечное   события   для   каждого   варианта   использования:   1)

Initiate session (Инициализация сеанса). Начальным событием является помещение клиентом
банковской карты в  банкомат. Конечных событий может быть  два: либо  система  оставляет
банковскую карту себе, либо возвращает ее обратно клиенту; 2) Query account (Опрос счета).
Начальное   событие:   клиент   запрашивает   данные   о   состоянии   счета.   Конечное   событие: