Главная страница « Информация « ООАП «

Варианты 2-го задания по ООАП (МАППО). 2018-19 учебный год


«Нет проблем! Мы можем покончить с этой ерундой за выходные!»
Э. Йордон «Путь камикадзе»

Требования


В каждом из предложенных вариантов требуется при помощи Visual Paradigm Community Edition 15.1 (или выше) построить UML-модель программного обеспечения. Процесс выполнения задания делится на несколько этапов, по окончании каждого из которых производится сдача полученных результатов:

  1. Создание модели требований.

  2. Создание модели анализа.

  3. Создание проектной модели системы.

  4. Составление отчёта по модели.

Отправляя свои результаты по этапу 2-го задания, выполняйте следующее: закройте проект в среде; vpp-файл проекта сархивируйте zip; полученный zip-файл и другое, что требуется по этапу, присоедините к письму.

Процесс моделирования должен проходить так, как это описано в методическом пособии по Visual Paradigm [html]. Начинать работу следует не с пустого проекта, а с заготовки архив шаблона (15.1 [zip]). Структура модели должна соответствовать структуре, предусмотренной Rational Unified Process.

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

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

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

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

Сдаваемая после выполнения второго этапа модель должна удовлетворять перечисленным ниже требованиям. В Analysis Model должна быть создана диаграмма KeyAbstractions, на которой отображены все классы – ключевые абстракции, а также перечислимые типы и связи между ними. Следует создать пакет, названный Usecase realizations, внутри Analysis Model. В этом пакете следует для каждого из трёх вариантов использования, выделенных и описанных на первом этапе, создать отдельную кооперацию, содержащую относящиеся к реализации этого варианта использования элементы модели:

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

  • диаграмму классов View of Participating Classes, на которой представлены все классы анализа, участвующие в реализации этого варианта использования.

Все классы анализа следует разместить непосредственно в пакете Analysis Model (на верхнем уровне). Созданные диаграммы могут содержать необходимые пояснения в виде примечаний. В сложных потоках событий ветвления и циклы должны быть промоделированы с помощью комбинированных фрагментов на диаграммах последовательности. Не следует увлекаться усложнением потоков.

До конца астрономического года можно заработать дополнительные баллы, добавив в модель анализа помимо реализаций трёх ключевых вариантов использования реализации 1 или 2 дополнительных, при условии, что это те же дополнительные ВИ, которыми уже была ранее пополнена модель требований. Каждая добавленная реализация (диаграмма VOPC + диаграммы последовательности для потоков событий) даёт 4 балла. Сделанное сверх указанной границы не оценивается, не рассматривается. Присланное в новом астрономическом году не оценивается, не рассматривается. Штрафы за дополнительное моделирование не начисляются. При отправке результатов в электронном письме должна быть явно сообщена информация о дополнительном моделировании.

При работе над проектной моделью (третий этап) требуется:

  1. Разбить систему на 3 уровня (Application, Business Services, Middleware).

  2. Создать структуру пакетов внутри Design model, как это описано в методичке.

  3. Создать диаграмму размещения внутри Deployment View. Для встроенных систем (варианты со словом «терминал» в названии, вариант «Продуктомат», вариант «Кофемат») диаграмма размещения должна изображать связи между процессором и устройствами, а также узлами внешних систем. В остальных вариантах диаграмма размещения показывает узлы вычислительной среды системы, узлы внешних систем, связи между ними и размещение процессов разрабатываемой системы по узлам. Для упрощения допускается и рекомендуется рисовать среды выполнения без объемлющих их аппаратных узлов.

  4. Разместить классы по пакетам в Design model, как это описано в методичке и рассказано в лекциях.

  5. Выделить не менее чем одну подсистему. В частности, в большинстве вариантов предусмотрена работа с устойчивыми объектами, её следует поручить подсистеме обеспечения устойчивости (взаимодействия с БД на основе JDBC). Либо предусмотрен обмен данными / запросами с внешней программной системой. Его реализацию следует поручить подсистеме (взаимодействия с внешним ПО на основе XML-RPC). Одну из подсистем следует спроектировать, как это описано в методичке и рассказано на лекциях.

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

  7. Для подсистемы создать класс-фасад («subsystem proxy») и при необходимости другие классы подсистемы. На отдельной диаграмме классов показать связи между классами подсистемы, а также связи между классами подсистемы и элементами модели, лежащими вне подсистемы. Создать диаграммы последовательности для описания реализации операций интерфейса подсистемы. При наличии в интерфейсе нескольких однотипных операций следует промоделировать по одной операции каждого типа (например, один «read», один «update», один «delete», один «create»).

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

  9. Уточнить связи между классами системы, заменяя необязательные ассоциации на зависимости, указывая направления у всех оставшихся ассоциаций, выбирая при необходимости тип для ассоциаций «часть -- целое»: агрегация или композиция, уместно добавляя квалификаторы и/или свойства полюсов ассоциаций (ordered, nonunique).

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

  11. Каждый класс (ключевую абстракцию, участника реализаций вариантов использования, класс подсистемы) снабдить описанием, помещённым в общий текстовый файл, где ранее описан интерфейс подсистемы. Описание класса должно включать в себя краткое указание ответственности класса, описания атрибутов и операций (с указанием для каждого атрибута и каждой операции полной сигнатуры и его/её назначения). Не описывайте тривиальные операции с очевидной сигнатурой: геттеры, сеттеры, конструкторы без параметров.

  12. Для описания поведения экземпляров отдельных классов со сложным поведением построить диаграммы состояний. В проектной модели должна быть хотя бы одна нетривиальная диаграмма состояний с действиями.

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

  14. Разработать схему базы данных и отобразить её в виде диаграммы классов со стереотипами из специализированного профиля UML (во всех вариантах).

Можно заработать дополнительные баллы, добавив в проектную модель помимо реализаций трёх ключевых вариантов использования реализации 1 или 2 дополнительных, при условии, что это те же дополнительные ВИ, которыми уже были ранее пополнены модель требований и модель анализа. Каждая добавленная реализация (VOPC, диаграммы последовательности для потоков событий) даёт 4 балла. Либо можно смоделировать вторую подсистему в дополнение к первой, при условии, что подсистемы базируются на разных архитектурных механизмах. Реализация второй подсистемы даёт 4 балла. Сделанное сверх указанной границы не оценивается, не рассматривается. Присланное в новом астрономическом году не оценивается, не рассматривается. Штрафы за дополнительное моделирование не начисляются. При отправке результатов в электронном письме должна быть явно сообщена информация о дополнительном моделировании.

Требования по составлению отчёта опубликованы отдельно [html].

Список вариантов

  1. Терминал почтового отделения

  2. Сайт сети пиццерий

  3. Терминал службы «единого окна»

  4. Онлайновая городская служба

  5. Терминал пиццерии

  6. Онлайновая почтовая служба

  7. Сайт поликлиники

  8. Онлайновая служба недвижимости

  9. Терминал библиотеки

  10. Онлайновая библиотечная служба

  11. Продуктомат

  12. Интернет-магазин продуктов

  13. Кофемат

  14. Валидатор городского транспорта

Вариант 1. Терминал почтового отделения


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

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

Если в почтовом отделении, где установлен терминал, есть отправления клиента, готовые к выдаче, то терминал предлагает выбрать одно из них для оформления выдачи. На экран выводятся сведения о выдаваемом отправлении. Отправление может быть без оплаты либо с оплатой наложенным платежом. Если отправление должно быть оплачено, то терминал просит клиента ввести банковскую карту в считыватель. Клиент вводит карту. Если карту удалось прочесть, то терминал запрашивает ПИН. По введённому ПИН терминал вычисляет некоторое другое число (PVV) и вместе с данными карты, считанными с её магнитной полосы, отправляет в систему оплаты. В ответ может придти либо подтверждение успешной оплаты, либо отказ. При отказе клиенту предоставляются ещё не более чем 2 попытки оплаты той же или другой картой. Если и они неуспешны, то сеанс обслуживания завершается неуспехом. При успехе распечатывается чек об оплате. Распечатывается и выдаётся клиенту заполненное извещение, по которому служащий выдаёт отправление. Клиент обязан расписаться на извещении, подтверждая, что отправление им получено. Терминал завершает обслуживание клиента, высвечивает приглашение и ожидает следующего клиента. Если у одного клиента несколько готовых к выдаче отправлений, то он может забрать их в течение нескольких сеансов работы с терминалом.

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

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

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

Вариант 2. Сайт сети пиццерий


Сеть пиццерий с доставкой «Pizza Hit» открывает сайт для автоматизированного онлайнового обслуживания клиентов. Воспользоваться сайтом может любой клиент, имеющий клубную карту и доступ в Веб. Выдача карт осуществляется офлайн в пиццериях. При этом работники пиццерий вводят с помощью терминала данные о клиенте (ф. и. о., дату рождения, e-mail, мобильный телефон, адрес). У разных клиентов не может совпадать e-mail, номера мобильных и сочетания ф. и. о. с датой рождения. Клиенты -- полные тёзки -- встречаются, но редко. На карту наносится ID клиента в виде QR-кода и записи цифрами. Терминал пересылает данные на сервер сайта, где они сохраняются. Клиент может войти на сайт, если верно введёт свой e-mail и ID с клубной карты. После входа клиент может оформить заказ пиццы с доставкой на дом либо с получением в одной из пиццерий (заказ на вынос). В любом заказе с доставкой указан адрес доставки и телефон клиента. В заказе на вынос указана пиццерия, в которой будет выдан заказ. В любом заказе указан его номер, общая стоимость заказа и непустой список позиций. В каждой позиции указана конкретная пицца и заказанное количество таких пицц. Про любую пиццу известно её название, цена, а также непустой набор начинок, тип основы (тонкая, пышная, обычная), вид (открытая пицца или закрытая). Начинки отличаются признаком (обязательная, дополнительная) и разновидностью (томаты, перец, оливки, салями, ветчина, базилик, орегано, моцарелла, пармезан). Например, пицца Napoli -- это открытая пицца на тонкой основе с таким набором начинок: томаты, моцарелла, пармезан и базилик. В пиццу начинка может быть положена в одинарном, двойном или тройном объёме по выбору клиента.

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

По окончании оформления заказа клиенту по e-mail или на мобильный телефон в виде SMS (в зависимости от его настроек) отправляются сведения о заказе. Оформленный заказ на вынос клиент должен оплатить. Заказ с доставкой оплачивается через курьера. При оплате заказа сайт просит клиента ввести сведения о банковской карте (номер, дату истечения срока действия, сведения о держателе карты и трёхзначный контрольный код. Клиент вводит сведения о карте. Полученные от него данные карты отправляются в систему оплаты. В ответ может придти либо подтверждение успешной оплаты, либо отказ. При отказе клиенту предоставляются ещё не более чем 2 попытки оплаты той же или другой картой. Если и они неуспешны, то оплата заказа завершается неуспехом. При успехе заказ помечается как оплаченный.

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

Администратор сайта может изменить общий прайс-лист сети пиццерий. Изменённый прайс-лист начинает действовать с наступлением новых суток. Ежесуточно в период с 00-00 по 00-30 сервер сайта должен связаться со всеми терминалами и выслать актуальные данные о ценах на пиццы и начинки.

Моделированию подлежит сайт (сервер). Платёжная система, терминалы, шлюз сотовой сети для отправки SMS, SMTP-сервер находятся за границами моделируемой системы и моделированию в качестве её частей не подлежат. Следует создать схему базы данных сервера «Pizza Hit», где хранятся сведения о клиентах, заказах, ценах.

Вариант 3. Терминал службы «единого окна»


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

Терминал ожидает очередного клиента, высвечивая приглашение ввести номер мобильного телефона. Клиент набирает на клавиатуре терминала запрошенный номер. Если на сервере городской службы зарегистрирован клиент с таким номером, то терминал через шлюз сотовой связи отправляет по введённому номеру SMS c 4хзначным кодом и выводит запрос кода на свой экран. Клиент получает код на телефон и вводит его в терминал. Если ввод верен, сеанс обслуживания продолжается, иначе он завершается неуспехом. В продолжение обслуживания происходит запрос на сервер о штрафах и заявках клиента с введённым номером телефона. Список штрафов и список заявок выводятся клиенту. О своей заявке клиент может узнать историю операций с ней. Виды операций: заявка принята, заявка обрабатывается, заявка отклонена из-за неполных и/или недостоверных сведений, документ оформлен, документ готов к выдаче заявителю, документ вручён заявителю. По каждой операции указывается её дата, время, а также, возможно, дополнительные сведения.

Если в отделении службы «единого окна», где установлен терминал, есть заявки клиента, по которым документы готовы к выдаче, то терминал предлагает выбрать одну из них для оформления выдачи. На экран выводятся сведения о выдаваемом документе и указание клерков, которые могут выдать документ и имеют свободный слот в своём расписании в текущие сутки. Документ может быть оформлен без оплаты либо с оплатой пошлины по банковской карте. Если пошлина должна быть уплачена, то терминал просит клиента ввести банковскую карту в считыватель. Клиент вводит карту. Если карту удалось прочесть, то терминал запрашивает ПИН. По введённому ПИН терминал вычисляет некоторое другое число (PVV) и вместе с данными карты, считанными с её магнитной полосы, отправляет в систему оплаты. В ответ может придти либо подтверждение успешной оплаты, либо отказ. При отказе клиенту предоставляются ещё не более чем 2 попытки оплаты той же или другой картой. Если и они неуспешны, то сеанс обслуживания завершается неуспехом. При успехе распечатывается чек об уплате пошлины. Распечатывается и выдаётся клиенту чек об уплате пошлины и талон, по которому клерк выдаст доумент. Терминал завершает обслуживание клиента, высвечивает приглашение и ожидает следующего клиента. Если у одного клиента несколько готовых к выдаче документов, то он может оплатить пошлину и забрать их в течение нескольких сеансов работы с терминалом.

Оплата штрафов и/или пеней клиентом происходит сходим образом. Клиент выбирает штраф из высвечиваемого терминалом списка. Далее следует попытка оплаты с помощью банковской карты (см. выше). Штрафы оплачиваются по одному. Сведения об оплате передаются на сервер городской службы. Клиент может оставить с помощью терминала заявку для оформления справки и/или документа. В заявке указывается тип (справка / документ), наименование, а также дополнительные сведения, необходимые для оформления (например, СНИЛС, ИНН, номер свидетельства о рождении и проч.). Сведения об оставленной заявке терминал пересылает на сервер городской службы.

Клерк использует терминал на свой лад. С помощью специальной карты, помещаемой в считыватель, он переводит терминал в служебный режим. В этом режиме клерк вводит сведения об операциях с заявками клиентов. Клерк выбирает одну заявку из списка, высвеченного терминалом и выбирает тип операции с ним (см. выше). Сведения о дате и времени операции терминал заполняет самостоятельно. Дополнительные сведения могут быть добавлены клерком. Когда ввод завершён и подтверждён, сведения отправляются на сервер городской службы. От сервера может придти подтверждение или отказ. Если вводимая операция некорректна, то сервер должен прислать отказ, так как он отслеживает корректность последовательности операций (например, по отклонённой заявке не могут быть оформлены и/или выданы документы; после выдачи документов нельзя отклонить заявку и т. п.). Для исправления подобной ситуации клерк может запросить весь список операций по заявке и внести необходимые изменения. Также клерк отмечает в терминале выполненные им приёмы клиентов. Приём не может быть помечен выполненным заранее, до его начала. Клер может работать с данными о своём расписании работы на неделе. В течение недели он должен отработать 30 часов. Если есть заявки клиентов на приём на какое-то время, то клерк не может изменить своё расписание так, что это время станет не рабочим. Сведения запрашиваются и сохраняются на сервере городской службы. По окончании работы клерк должен перевести терминал обратно в режим обслуживания клиентов.

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

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

Вариант 4. Онлайновая городская служба


Онлайновая городская служба -- это сайт, предоставляющий своим пользователям услуги по оформлению документов, выдаче справок, уплате штрафов или пени, а также решению подобных вопросов. Чтобы стать пользователем службы, нужно в ней зарегистрироваться, указав логин-email, пароль, ф., и., о., адрес, паспортные данные, мобильный номер. Если форма заполнена верно, e-mail не совпадает с e-mail'ом другого пользователя и телефон не совпадает с телефоном другого пользователя, регистрационная запись о новом пользователе создаётся, пользователь получает в свой электронный почтовый ящик сообщение для подтверждения e-mail со сгенерированным случайным, но достаточно стойким паролем. На телефон пользователя отправляется SMS с кодом подтверждения номера телефона. Чтобы подтвердить e-mail и телефон, пользователь должен воспользоваться ссылкой из полученного по e-mail сообщения. По ссылке открывается форма, в которую пользователь вбивает свой логин, пароль и код из SMS. Если все данные сообщены верно, то пользователь получает полноценный доступ к службе. Теперь он может «входить» и получать доступ ко всем возможностям, предоставляемым пользователем.

Так, пользователь может записаться на приём к клерку. Служба предоставляет перечень работающих клерков, каждый из которых решает свой круг вопросов. У них есть еженедельное расписание с указанием рабочих дней и рабочих часов. Рабочие часы делятся на слоты по 15 минут. Пользователь может записаться к любому клерку, выбрав не более чем один свободный слот этого клерка. Список заявок на приёмы высвечивается пользователю. Накануне запланированного приёма пользователь получает от службы оповещение-напоминание о записи на приём. За двое суток до приёма запись можно отменить. По завершении приёма он помечается в системе как выполненный. Новый статус приёма служба получает с терминала службы «единого окна», через который клерк отчитывается о своей работе.

Пользователь может оставить в службе заявку для оформления справки и/или документа. В заявке указывается тип (справка / документ), наименование, а также дополнительные сведения, необходимые для оформления (например, СНИЛС, ИНН, номер свидетельства о рождении и проч.). Данные об операциях по оформлению служба принимает от своих клерков через терминалы службы «единого окна». Виды операций: заявка принята, заявка обрабатывается, заявка отклонена из-за неполных и/или недостоверных сведений, документ оформлен, документ готов к выдаче заявителю, документ вручен заявителю. По каждой операции указывается её дата, время, а также, возможно, дополнительные сведения. При получении данных о новой операции по оформлению служба посылает уведомление либо по электронной почте заявителя, либо через SMS в зависимости от настроек пользователя. Служба отслеживает корректность последовательности операций по оформлению (например, по отклонённой заявке не могут быть оформлены и/или выданы документы; после выдачи документов нельзя отклонить заявку и т. п.), а также уведомляет об истечении контрольных сроков выполнения заявок: 45 суток для документов и 20 суток для справок. Сведения о некорректных операциях служба отказывается принимать. Работающие за терминалами клерки должны исправить некорректные сведения и заново отправить их, и тогда они будут приняты службой.

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

Если пользователь забыл свой пароль, то служба может прислать ему ссылку для восстановления доступа с новым паролем. При этом также отправляется SMS с кодом подтверждения, как при регистрации. Если пользователь меняет email и/или номер телефона и/или пароль в своих настройках, то это также контролируется с помощью кода подтверждения, получаемого через SMS. Если пользователь не обращается к службе более 365 суток с момента последнего «входа», то считается, что он больше не является клиентом и все его данные удаляются. Если пользователь закончил работу со службой, то он «выходит» из неё.

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


Вариант 5. Терминал пиццерии


Сеть пиццерий с доставкой «Pizza Hit» установила в своих пиццериях терминалы для автоматизированного обслуживания клиентов. Воспользоваться терминалом может любой клиент, имеющий клубную карту. Карта подносится к сканеру QR-кодов, после чего терминал узнаёт ID клиента и запрашивает сведения о нём у сервера «Pizza Hit». В ответ может придти отказ, если ID неверен, либо подтверждение и сведения о клиенте. Во втором случае обслуживание продолжается. Клиент может оформить свой заказ. Типы заказов: на месте (оформляются только при наличии свободных столиков в пиццерии, где установлен терминал); на вынос (клиент получает заказанные пиццы и уходит); с доставкой (клиент делает заказ и получает его от курьера на дому). В любом заказе с доставкой указан адрес доставки и телефон клиента. В заказе на месте указан номер столика, назначенный терминалом клиенту. В любом заказе указан его номер, общая стоимость заказа и непустой список позиций. В каждой позиции указана конкретная пицца и заказанное количество таких пицц. Про любую пиццу известно её название, цена, а также непустой набор начинок, тип основы (тонкая, пышная, обычная), вид (открытая пицца или закрытая). Начинки отличаются признаком (обязательная, дополнительная) и разновидностью (томаты, перец, оливки, салями, ветчина, базилик, орегано, моцарелла, пармезан). Например, пицца Napoli -- это открытая пицца на тонкой основе с таким набором начинок: томаты, моцарелла, пармезан и базилик. В пиццу начинка может быть положена в одинарном, двойном или тройном объёме по выбору клиента.

Общая стоимость заказа равна сумме цен позиций и цены доставки. В стоимость заказа на месте включена 5%-ная наценка за обслуживание. Цена позиции равна цене её пиццы, умноженной на количество пицц в позиции. Цена пиццы зависит от её названия и от того, положены ли в неё какие-либо начинки в более чем ординарном объёме. Для каждой начинки известна сумма наценки за двойной и за тройной её объем. Все цены терминал получает ежесуточно в начале суток (с 00-00 по 00-30) от сервера «Pizza Hit». Во время обновления этих сведений обслуживание клиентов не производится.

По окончании оформления заказа клиенту распечатываются сведения о заказе. Оформленный заказ на вынос клиент должен оплатить. Заказы других типов оплачиваются через официанта / курьера. При оплате заказа терминал просит клиента ввести банковскую карту в считыватель. Клиент вводит карту. Если карту удалось прочесть, то терминал запрашивает ПИН. По введённому ПИН терминал вычисляет некоторое другое число (PVV) и вместе с данными карты, считанными с её магнитной полосы, отправляет в систему оплаты. В ответ может придти либо подтверждение успешной оплаты, либо отказ. При отказе клиенту предоставляются ещё не более чем 2 попытки оплаты той же или другой картой. Если и они неуспешны, то оплата заказа завершается неуспехом. При успехе распечатывается чек об оплате. Сведения о заказе и об оплате заказов терминал пересылает на сервер «Pizza Hit» для учёта

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

Если клиент закончил использование терминала, то он должен выполнить «выход». После этого на терминале высвечивается приглашение для следующего клиента, и терминал ожидает, когда следующий клиент выполнит вход с помощью клубной карты.

Работник пиццерии может использовать терминал на свой лад. С помощью специальной карты, помещаемой в считыватель, он переводит терминал в служебный режим. В этом режиме работник вводит сведения новом клиенте, которому выдаётся клубная карта. Служащий вводит ф. и. о., дату рождения, номер телефона и адрес клиента. Сведения пересылаются на сервер, чтобы убедиться, что клиент не был зарегистрирован раньше. Сервер сообщает результат проверки. Иногда клиенты теряют клубные карты, в этом случае им может быть выдан дубликат. Если карта выдаётся, то работник распечатывает через терминал QR-код на прозрачной клейкой ленте. Затем он наклеивает ленту на пластиковую основу и выдаёт клиенту. У дубликата QR-код прежний -- тот, что был на утерянной карте. У новой карты QR-код новый.

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

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

Моделированию подлежит терминал. Сервер и платёжная система находятся за границами моделируемой системы и моделированию в качестве её частей не подлежат. Несмотря на это, дополнительно следует создать схему базы данных сервера «Pizza Hit», где хранятся сведения о клиентах, заказах, ценах. Предполагается, что в самом терминале нет собственной БД, а значит, следует смоделировать внешнюю БД.

Вариант 6. Онлайновая почтовая служба


Онлайновая почтовая служба -- это сайт, предоставляющий своим пользователям почтовые услуги. Чтобы стать клиентом службы, нужно в ней зарегистрироваться, указав логин-email, пароль, ф., и., о., адрес, паспортные данные, мобильный номер. Если форма заполнена верно, e-mail не совпадает с e-mail'ом другого клиента и телефон не совпадает с телефоном другого клиента, регистрационная запись о новом клиенте создаётся, клиент получает в свой электронный почтовый ящик сообщение для подтверждения e-mail со сгенерированным случайным, но достаточно стойким паролем. На телефон клиента отправляется SMS с кодом подтверждения номера телефона. Чтобы подтвердить e-mail и телефон, клиент должен воспользоваться ссылкой из полученного по e-mail сообщения. По ссылке открывается форма, в которую клиент вбивает свой логин, пароль и код из SMS. Если все данные сообщены верно, то клиент получает полноценный доступ к службе. Теперь он может «входить» и получать доступ ко всем возможностям, предоставляемым клиентам.

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

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

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

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

Если клиент забыл свой пароль, то служба может прислать ему ссылку для восстановления доступа с новым паролем. При этом также отправляется SMS с кодом подтверждения, как при регистрации. Если клиент меняет email и/или номер телефона и/или пароль в своих настройках, то это также контролируется с помощью кода подтверждения, получаемого через SMS. Если клиент не пользуется службой более 365 суток с момента последнего «входа», то считается, что он больше не является клиентом и все его данные удаляются. Если клиент закончил работу со службой, то он «выходит» из неё.

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

Вариант 7. Сайт поликлиники


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

Чтобы стать пациентом поликлиники, нужно зарегистрироваться на сайте, указав логин-email, пароль, ф., и., о., № страхового полиса, адрес, паспортные данные, мобильный номер. Если форма заполнена верно, e-mail не совпадает с e-mail'ом другого зарегистрированного пациента, телефон не совпадает с телефоном другого зарегистрированного пациента, № страхового полиса также не совпадает, то регистрационная запись создаётся, отправляется в электронный почтовый ящик сообщение для подтверждения e-mail со сгенерированным случайным, но достаточно стойким паролем. На указанный телефон отправляется SMS с кодом подтверждения номера телефона. Чтобы подтвердить e-mail и телефон, зарегистрированный пациент должен воспользоваться ссылкой из полученного по e-mail сообщения. По ссылке открывается форма, в которую зарегистрированный пациент вбивает свой логин, пароль и код из SMS. Если все данные сообщены верно, то зарегистрированный пациент получает полноценный доступ к сайту. Теперь он может «входить» и получать доступ ко всем возможностям сайта.

Так, пациент может записаться на приём к врачу. Сайт предоставляет перечень работающих врачей, каждый из которых является специалистом в своей области. У них есть еженедельное расписание с указанием рабочих дней и рабочих часов. Рабочие часы делятся на слоты по 20 минут. Пациент может записаться к врачу через сайт, выбрав не более чем один свободный слот этого врача. Список принятых заявок на приёмы высвечивается пациенту. Пациент может обратиться в регистратуру очно или по телефону для записи на приём. В этом случае, заявку на приём на сайт вносит сотрудник регистратуры. Накануне запланированного приёма пациент получает от сайта оповещение-напоминание о записи на приём по email и SMS. За двое суток до приёма запись можно отменить. По завершении приёма он помечается в системе как выполненный. Новый статус приёма сайт получает от врача. Так врач отчитывается о своей работе.

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

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

Если зарегистрированный пользователь забыл свой пароль, то сайт может прислать ему ссылку для восстановления доступа с новым паролем. При этом также отправляется SMS с кодом подтверждения, как при регистрации. При изменении email'а и/или номера телефона и/или пароля в настройках пользователя, также осуществляется контроль с помощью кода подтверждения, получаемого через SMS. Если пациент не осуществляет вход либо не пользуется медицинскими услугами поликлиники более 365 суток, то все его данные удаляются. Если вошедший пользователь закончил работу с сайтом, то он осуществляет «выход».

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

Вариант 8. Онлайновая служба недвижимости


Онлайновая служба недвижимости -- это сайт, предоставляющий своим пользователям услуги по сдаче / аренде / купле / продаже комнат / квартир / домов. Сайт принимает и публикует предложения от застройщиков и агентств недвижимости, а также частные объявления от собственников недвижимости. Чтобы стать клиентом службы, нужно в ней зарегистрироваться, указав логин-email, пароль, ф., и., о., адрес, паспортные данные, мобильный номер. Если форма заполнена верно, e-mail не совпадает с e-mail'ом другого зарегистрированного пользователя и телефон не совпадает с телефоном другого зарегистрированного пользователя, регистрационная запись создаётся, отправляется в электронный почтовый ящик сообщение для подтверждения e-mail со сгенерированным случайным, но достаточно стойким паролем. На указанный телефон отправляется SMS с кодом подтверждения номера телефона. Чтобы подтвердить e-mail и телефон, зарегистрированный пользователь должен воспользоваться ссылкой из полученного по e-mail сообщения. По ссылке открывается форма, в которую зарегистрированный пользователь вбивает свой логин, пароль и код из SMS. Если все данные сообщены верно, то зарегистрированный пользователь получает полноценный доступ к службе. Теперь он может «входить» и получать доступ ко всем возможностям сайта. Часть возможностей доступны пользователям без регистрации. Так, любой пользователь может искать нужные ему объявления. Критериями поиска являются: тип объявления, тип объекта, фрагмент адреса (может иметь вид: город, метро), диапазон подходящей стоимости. Поиск осуществляется даже в тех случаях, когда не всем критериям заданы значения. Результат поиска может быть отсортирован по стоимости либо по дате размещения объявления. Зарегистрированный пользователь, выполнивший "вход", может сохранять интересные ему объявления в своё "Избранное", чтобы потом просматривать этот список. Объявление, внесённое в "избранное" может быть удалено оттуда.

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

Чтобы поддерживать базу в актуальном состоянии, сайт автоматически определяет объявления, поданные более 30 дней назад, и перестаёт включать их в результаты поиска. Создатель объявления может заново пометить такое объявление как актуальное. Счётчик давности при этом сбрасывается, отсчёт начинается с нуля.

Если посетитель сайта попытался воспользоваться объявлением и выяснил, что оно недостоверно, он при помощи сайта может сообщить об этом редакторам. Такие сообщения проверяются. По итогам проверки объявление может быть удалено с сайта, а учётная запись его создателя закрыта проверяющим редактором.

Если зарегистрированный пользователь забыл свой пароль, то служба может прислать ему ссылку для восстановления доступа с новым паролем. При этом также отправляется SMS с кодом подтверждения, как при регистрации. При изменении email'а и/или номера телефона и/или пароля в настройках пользователя, также осуществляется контроль с помощью кода подтверждения, получаемого через SMS. Если зарегистрированный пользователь не осуществляет вход более 365 суток, то все его данные удаляются. Если вошедший пользователь закончил работу с сайтом, то он осуществляет «выход».

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

Вариант 9. Терминал библиотеки


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

В режиме обслуживания читателей библиотечный терминал ожидает очередного читателя, высвечивая приглашение ввести логин-email. Читатель набирает на клавиатуре терминала запрошенный логин. Если на сервере библиотечной службы зарегистрирован читатель с таким логином, то терминал через шлюз сотовой связи отправляет по мобильному номеру этого читателя SMS c 4тизначным кодом и выводит запрос кода на свой экран. Читатель получает код на телефон и вводит его в терминал. Если ввод верен, сеанс обслуживания продолжается, иначе он завершается неуспехом. В продолжение обслуживания происходит запрос на сервер экземплярах, взятых текущим читателем и пока не возвращённых. Список экземпляров выводится читателю. В нём красным выделяются экземпляры, срок пользования которыми просрочен. О каждом экземпляре из списка читатель может получить полные сведения, в частности, когда экземпляр ему был выдан. Возврат экземпляров читатель осуществляет с помощью оператора -- работника библиотеки.

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

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

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

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

Вариант 10. Онлайновая библиотечная служба


Онлайновая библиотечная служба -- это сайт, предоставляющий своим пользователям услуги нескольких библиотек. Чтобы стать читателем, нужно зарегистрироваться в службе, указав логин-email, пароль, ф., и., о., адрес, паспортные данные, мобильный номер. Если форма заполнена верно, e-mail не совпадает с e-mail'ом другого читателя и телефон не совпадает с телефоном другого читателя, регистрационная запись о новом читателе создаётся, читатель получает в свой электронный почтовый ящик сообщение для подтверждения e-mail со сгенерированным случайным, но достаточно стойким паролем. На телефон читателя отправляется SMS с кодом подтверждения номера телефона. Чтобы подтвердить e-mail и телефон, читатель должен воспользоваться ссылкой из полученного по e-mail сообщения. По ссылке открывается форма, в которую читатель вбивает свой логин, пароль и код из SMS. Если все данные сообщены верно, то читатель получает полноценный доступ к службе. Теперь он может «входить» и получать доступ ко всем возможностям, предоставляемым читателям. Если пользователь хочет завершить сеанс работы со службой, то он «выходит» из неё.

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

Служба поддерживает реестры всех экземпляров всех книг библиотек (по одному наименованию в одной библиотеке может быть несколько экземпляров). В реестре о каждом экземпляре книги хранится список операций с ним. Виды операций: приём экземпляра на учёт, выдача экземпляра читателю, возвращение экземпляра читателем, списание пришедшего в негодность экземпляра. По каждой операции указывается её дата, время, а также, возможно, дополнительные сведения. Так при возвращении экземпляра читателем указывается, возвращён ли он до истечения срока пользования книгой или после его истечения. Данные об операциях с экземплярами служба принимает от своих операторов через служебные терминалы. Служба отслеживает корректность последовательности операций с экземплярами (например, уже выданный экземпляр не может быть снова выдан ранее, чем он будет возвращён и т. п.), а также уведомляет читателей об истечении срока пользования книгой: 45 суток (по каждой просроченной книге читатель каждые сутки получает от системы напоминание по e-mail и SMS). Сведения о некорректных операциях служба отказывается принимать от служебных терминалов. Работающие за терминалами операторы должны исправить некорректные сведения и заново отправить их, и тогда они будут приняты службой.

После выдачи читателю экземпляр добавляется в список читателя. После возвращения экземпляр остаётся в списке читателя до тех пор, пока он не решит удалить его оттуда.

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

Операторы, пользуясь служебными терминалами, вносят новые сведения / редактируют ранее введённые сведения / удаляют неактуальные сведения из каталогов библиотек. Операторы могут работать со сведениями о читателях. Так, постоянные нарушители сроков пользования книгами и/или те читатели, которые просрочили и не вернули 3 последние взятые ими книги, по решению оператора могут быть наказаны. На время наказания не допускается выдача новых книг читателю (соответственно, читатель не может заказывать экземпляры для получения в библиотеках). По окончании срока наказания оператор может «разбанить» читателя, если сочтёт нужным. Возвращать взятые экземпляры читатель может независимо от наличия / отсутствия у него «бана»

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

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

Вариант 11. Продуктомат


Продуктомат -- это автоматизированный пункт обслуживания клиентов интернет-магазина. С его помощью клиенты получают свои заказы, а также могут полностью или частично вернуть заказ, не подошедший им по какой-то причине. Получение заказа осуществляется следующим образом: Продуктомат ожидает очередного клиента, высвечивая приглашение ввести номер мобильного телефона. Клиент набирает на клавиатуре продуктомата запрошенный номер. Продуктомат через шлюз сотовой связи отправляет по введённому номеру SMS c 6тизначным кодом и выводит запрос кода на свой экран. Клиент получает код на телефон и вводит его в продуктомат. Если ввод верен, выдача продолжается, иначе сеанс обслуживания завершается неуспехом. В продолжение обслуживания происходит проверка того, что внутрь продуктомата курьер уже разместил заказ/заказы клиента с введённым номером телефона. Если проверка неудачна, то продуктомат запрашивает сервер интернет-магазина, чтобы выяснить, есть ли у клиента заказы, готовые к выдаче и в каких продуктоматах они находятся. Сведения, сообщённые сервером в ответе, выводятся клиенту, чтобы он мог забрать свои заказы в другом продуктомате.

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

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

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

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

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

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

Вариант 12. Интернет-магазин продуктов


Интернет-магазин позволяет клиентам заказывать в Веб продукты с доставкой. Чтобы стать клиентом интернет-магазина нужно зарегистрироваться. В регистрационную форму следует ввести следующие сведения: фамилию, имя и отчество клиента; его e-mail, служащий логином; номер мобильного телефона клиента. Если форма заполнена верно, e-mail не совпадает с e-mail'ом другого клиента и телефон не совпадает с телефоном другого клиента, регистрационная запись о новом клиенте создаётся, клиент получает в свой электронный почтовый ящик сообщение для подтверждения e-mail со сгенерированным случайным, но достаточно стойким паролем. На телефон клиента отправляется SMS с кодом подтверждения номера телефона. Чтобы подтвердить e-mail и телефон, клиент должен воспользоваться ссылкой из полученного по e-mail сообщения. По ссылке открывается форма, в которую клиент вбивает свой логин, пароль и код из SMS. Если все данные сообщены верно, то клиент получает полноценный доступ к интернет-магазину. Теперь он может «входить» в него, делать в нём заказы и использовать его другие возможности.

Для оформления заказа пользователь должен войти в интернет-магазин по логину и паролю. После успешного входа «корзина» клиента пуста. Клиент может просматривать каталог продуктов. О каждом продаваемом продукте в каталоге хранится название, описание, фотографию, производитель, страну происхождения, наличие/отсутствие в продаже, цену, скидку, массу, отзывы клиентов, купивших продукт ранее. Часть этих сведений видна только на странице продукта (производитель, страна происхождения, отзывы, снимок в полном размере). Остальные сведения также видны в списке продуктов. Список выдаётся пользователю после указания раздела (хлеб, бакалея, овощи-фрукты, молоко-сыр-яйца, мясо-птица, рыба-морепродукты, сладости, приправы-специи, напитки, заморозка-мороженное). Продукты внутри одного раздела могут быть объединены в не пересекающиеся группы (например, мясо-птица -- на говядину, свинину, баранину, конину, курицу, индейку и т. п.). Интернет-магазин поддерживает поиск по разделам: по группе, по слову из названия, по производителю, по стране происхождения, по диапазону цены, по наличию/отсутствию скидки. Список продуктов может быть отсортирован по цене, названию, среднему баллу, вычисленному по оценкам из отзывов. Сортировка осуществляется либо по невозрастанию, либо по неубыванию.

Со страницы продукта клиент получает возможность добавить продукт, находящийся в продаже, в свою «корзину». Содержимое «корзины» может быть обнулено. Количество единиц продукта в «корзине»может быть изменено (при обнулении количества продукт удаляется из «корзины»). Текущая стоимость «корзины» постоянно высвечивается вошедшему клиенту и пересчитывается при изменении «корзины». Продукты в «корзину» могут добавляться многократно. Если добавляемый продукт уже есть в «корзине», то его количество увеличивается на 1 единицу. После выхода клиента из системы текущее содержимое непустой «корзины» пропадает.

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

Когда заказ готов к отправке, складская система сообщает системе интернет-магазина об изменении статуса заказа. Клиент интернет-магазина может узнать статусы своих заказов, посмотрев их список (только после успешного «входа»). В списке высвечиваются как текущие заказы, так и прошлые. Клиент может подписаться на получение сообщений обо всех изменениях статусов заказов по e-mail и/или SMS. Операторы интернет-магазина могут пометить готовые к отправке заказы как переданные курьеру или как переданные для самовывоза (в автоматизированный пункт выдачи -- продуктомат). Также они указывают дату доставки. По обстоятельствам непреодолимой силы оператор может отменить заказ. По предоплаченным отменённым заказам система обеспечивает возврат оплаченных средств на банковскую карту клиента через шлюз платёжной системы.

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

По впечатлениям от покупки клиент может оставить один отзыв на каждый купленный им продукт. В отзыве указаны оценка от 0 до 5 и текст. Отзывы "публикуются", т. е. становятся видны другим пользователям только после проверки оператором. Если текст отзыва приемлем для публикации, то оператор «открывает» оставленный клиентом отзыв.

Каждые сутки с 4:00 до 4:30 система занимается обновлением своих данных. В это время работа клиентов с интернет-магазином невозможна. Из всех активных в это время сеансов клиентов система осуществляет принудительный выход. Система запрашивает данные извне -- от источника обновлений. Обновления могут содержать сведения о новых продуктах, а также изменённые сведения о продуктах, которые известны системе ранее. Сведения о продуктах, продажа которых прекращена навсегда, из системы не удаляются. Такие продукты лишь помечаются как отсутствующие в продаже.

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

Вариант 13. Кофемат


Кофемат -- это автоматический киоск по продаже горячих свежеприготовленных напитков. В ожидании очередного покупателя, он высвечивает приглашение выбрать тип напитка. Покупатель может сделав выбор, нажав на кнопку, рядом с названием типа напитка (американо, эспрессо, латте, капучино, кипяток, чай). После выбора напитка покупателю предлагается провести его «настройку». В напиток можно добавить не более чем одну порцию сиропа (ванильного, орехового, мятного). В напиток можно добавить нужное количество порций сахара (от 0 до 3, по умолчанию -- 1). У напитков на основе молока (латте, капучино) можно регулировать объём молока (обычный, увеличенный). У напитков на основе кофе (американо, эспрессо, латте, капучино) можно регулировать крепость (количество кофе при заваривании): малая, средняя (по умолчанию), большая, очень большая. У эспрессо можно регулировать объём: одинарный, двойной. После того, как покупатель произведёт настройки, кофемат высчитывает и высвечивает стоимость напитка, а также предлагает внести оплату. Стоимость напитка определяется в зависимости от базовой цены, которая привязана к типу напитка, цены добавок (сиропа, дополнительного сахара, дополнительного молока), цены дополнительно использованного кофе (при большой или очень большой крепости), цены за дополнительный объём (двойной эспрессо в два раза дороже обычного). Текущий прайс-лист на напитки и добавки кофемат получает в начале каждых суток от сервера сети кофематов. Покупатель может выбрать отказ (от «настройки» / от оплаты) и сеанс обслуживания будет завершён неуспехом.

Оплата может быть принята либо банкнотами и/или монетами через приёмник денег, либо банковской картой через считыватель карт. При оплате наличными покупатель последовательно помещает в приёмник очередную купюру/монету одну за другой, пока не наберётся необходимая сумма. Как только она набрана, кофемат помещает деньги в хранилище, выдаёт сдачу (если введено больше денег, чем требовалось) и переходит к приготовлению напитка. До этого момента покупатель может отказаться от оплаты, и тогда ему будут возвращены все принятые от него наличные, а сеанс обслуживания завершится и кофемат будет ожидать следующего покупателя. При оплате банковской картой покупатель вводит карту в считыватель. Если карту удалось прочесть, то кофемат запрашивает ПИН. По введённому ПИН кофемат вычисляет некоторое другое число (PVV) и вместе с данными карты, считанными с её магнитной полосы, отправляет в систему оплаты. В ответ может придти либо подтверждение успешной оплаты, либо отказ. При отказе покупателю предоставляются ещё не более чем 2 попытки оплаты той же или другой картой. Если и они неуспешны, то сеанс обслуживания завершается неуспехом. Не допускается смешанная оплата, т. е. вся сумма должна быть оплачена либо наличными, либо по карте.

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

Приготовление чая отличается тем, что после получения кипятка и помещения его в стакан туда же опускается пакетик с чаем. Затем происходит добавление сиропа и проч. (см. выше). Приготовление двойного эспрессо отличается от одинарного тем, что используется двойной объём воды и двойное количество зёрен кофе. Приготовление кипятка очевидно. Кипяток является не «настраиваемым» напитком. В нём нет добавок, его объём фиксирован, ложечка к нему не выдаётся.

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

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

В начале очередных суток с 00-00 до 00-10 с кофемат направляет на сервер отчёт обо всех сеансах обслуживания. В отчёте для каждого сеанса сообщены исчерпывающие сведения: порядковый номер сеанса (от начала суток), время и длительность сеанса, статус сеанса (как он завершился), какой напиток был приготовлен (если был), «настройка» напитка (если была), стоимость напитка, способ оплаты. После отправки отчёта данные сеансов удаляются из кофемата, так как они больше не нужны. Затем кофемат запрашивает и получает у сервера актуальную версию прайс-листа.

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

Моделированию подлежит кофемат. Сервер и платёжная система находятся за границами моделируемой системы. Несмотря на это, дополнительно следует создать схему базы данных сервера сети кофематов. Предполагается, что в самом кофемате нет собственной БД, а значит, следует смоделировать внешнюю БД.

Вариант 14. Валидатор городского транспорта


Валидатор контролирует оплату проезда пассажирами на маршрутах городских автобусов, троллейбусов, трамваев. Валидатор имеет устройство, осуществляющее чтение из запись данных с бесконтактных транспортных карт и/или банковских карт, часы, устройство подачи звуковых сигналов, дисплей для вывода сведений пассажиру, линию связи с сервером городского транспорта, линию связи с банковской системой, устройство беспроводного обмена данными с мобильным терминалом контролёра.
Рассмотрим работу валидатора при оплате проезда пассажиром. В начале на его дисплее высвечивается "Приложите карту для оплаты". Для оплаты пассажир должен приложить бесконтактную транспортную карту (либо банковскую карту) к считывающему устройству. Каждая транспортная карта имеет срок годности, по истечении которого она не может быть использована для прохода. Транспортные карты бывают трёх типов: с фиксированным количеством поездок; с неограниченным количеством поездок; карта-"кошелёк". Валидатор считывает с транспортной карты данные: срок годности карты, номер карты, тип карты и количество поездок. Если данные не удаётся считать, или карта просрочена, или количество поездок нулевое, то валидатор подаёт предупредительный звуковой сигнал. Иначе с карты с фиксированным количеством поездок списывается одна поездка, на дисплее высвечивается количество оставшихся поездок. Через 5 секунд после этого возвращается в начальное состояние. Если карта имеет неограниченное количество поездок, то при валидации карты такого типа поездки не списываются, а на дисплее высвечивается срок, до которого действует карта. Во избежание злоупотреблений с картами без лимита поездок в течение трёх минут после их валидации должны блокироваться другие попытки валидировать ту же карту. Работа с картами-"кошельками" отличается тем, что на них записывается не количество поездок, а некоторая денежная сумма. Карта-"кошелёк" пригодна для оплаты проезда, если сумма на ней больше чем цена поездки. При валидации такой карты с неё списывается цена поездки и высвечивается оставшаяся сумма. При списывании денежной суммы остаток средств на карте не может стать ниже нуля.

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

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

Контроллёры используют валидатор для проверки оплаты проезда. Мобильный терминал контролёра подносится к валидатору, и на него передаются данные обо всех валидациях за последние 60 минут. По окончании передачи на дисплее высвечивается "Передача данных завершена успешно". Данные после передачи остаются в памяти валидатора, чтобы быть переданными на сервер в конце рабочего дня.

Пассажир может использовать валидатор в справочных целях, чтобы получить сведения о количестве поездок / сроке годности / остатке средств на своей транспортной карте. Для этого пассажир перед тем как приложить карту нажимает кнопку на корпусе валидатора. Затем, после прикладывания карты, валидатор считывает с неё данные и высвечивает их на дисплее.

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

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

Предупреждение


Размещение на других ресурсах, а также коммерческое использование материалов, опубликованных в данном разделе, возможно только с разрешения авторов. По всем вопросам пишите:   

  

© Кафедра системного программирования ВМК МГУ.

Обновлено: 25.II.2019