 |
АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция
Описание операции ОП4: Авторизация
Операция LogIn()
Ссылки Прецеденты: Авторизация.
Предусловия Пользователь изъявил желание пройти процедуру
авторизации.
Постусловия - Создан экземпляр customer класса Customer и экземпляр balance класса Balance.
- Экземпляр класса customer связан с CustStorage.
- Атрибутам customer.login и customer.pass присвоены значения введённые пользователем
- Атрибуту customer.flag присвоено значение.
- Атрибуту customer.balance присвоено значение.
Реализация прецедента “Пополнение счёта”:
Проектное решение: makeRefill
Согласно шаблону Controller в качестве контроллера в данном случае выступает класс Controller, т.к. он берёт на себя ответственность за выполнение операций, приходящих от пользователя.
Согласно шаблону Creator класс Customer является оптимальным кандидатом для создания объектов класса Operation, т.к. он обладает данными для инициализации объектов Operation. Также согласно этому же шаблону класс Operation является подходящим кандидатом для создания объектов класса Receipt(именно в классе Operation объявляются условия создания класса Receipt).
Исходя из шаблона Information Expert, информационным экспертом является класс Operation. Именно в объектах этого класса содержится информация об проведённых пользователем операциях. Частичным же информационным экспертом является класс Storage.
Диаграмма взаимодействия для makeRefill
Реализация прецедента “Расчётные операции”:
Проектное решение: makePayment
Обоснование выбора классов согласно шаблонам GRASP аналогично обоснованию в реализации прецедента «Пополнение баланса»
Диаграмма взаимодействия для makePayment
Реализация прецедента “Запрос баланса”:
Проектное решение: getBalance
Согласно шаблону Controller в качестве контроллера в данном случае выступает класс Controller, т.к. он берёт на себя ответственность за выполнение операций, приходящих от пользователя.
Согласно шаблону Creator класс Customer является оптимальным кандидатом для создания объектов класса Operation, т.к. он обладает данными для инициализации объектов Operation. Также согласно этому же шаблону класс Operation является подходящим кандидатом для создания объектов класса Receipt(именно в классе Operation объявляются условия создания класса Receipt).
Исходя из шаблона Information Expert, информационным экспертом является класс Operation. Именно в объектах этого класса содержится информация об проведённых пользователем операциях.
Диаграмма взаимодействия для getBalance
Реализация прецедента “Авторизация”:
Проектное решение: LogIn
Согласно шаблону Controller в качестве контроллера в данном случае выступает класс Controller, т.к. он берёт на себя ответственность за выполнение операций, приходящих от пользователя.
В то же время согласно шаблону Creator класс Controller является подходящим кандидатом для создания объектов класса Operation, т.к. он обладает данными для инициализации объектов Operation.
Исходя из шаблона Information Expert, информационным экспертом является класс Customer. Именно в объектах этого класса содержится информация об проведённых пользователем операциях. Частичным же информационным экспертом является класс CustStorage.
Диаграмма взаимодействия для login
Поиск по сайту: