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

Варианты задания по спецкурсу Визуальные нотации программной инженерии. 2020-21 учебный год


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

Требования


В каждом из предложенных вариантов требуется при помощи CASE-средства построить UML модель программного обеспечения. Процесс создания модели состоит из нескольких этапов, по окончании каждого из которых производится сдача полученных результатов:

  1. Создание модели требований (этап может быть выполнен по желанию).

  2. Создание модели анализа (этап может быть выполнен по желанию при условии, что выполнен предыдущий этап).

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

  4. Составление отчёта по выполненному заданию (этап может быть выполнен по желанию при условии, что выполнен хотя бы один из предшествующих этапов).

Процесс моделирования должен проходить так, как это описано в учебном пособии (см. Visual Paradigm). Структура модели должна соответствовать структуре, предусмотренной технологией Unified Process.

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

По итогам выполнения первого этапа через Moodle-форму сдаётся модель (один VPP-файл проекта) и сопровождающий текстовый файл (DOC или PDF). В модели должна присутствовать диаграмма вариантов использования системы и диаграмма деятельности ключевого варианта использования. Модель следует начинать делать с заготовки проекта, а не с пустого проекта (см. учебное пособие). Для одного ключевого варианта использования должна быть составлена диаграмма деятельности. Эта диаграмма моделирует основной поток и альтернативные потоки своего варианта использования. Диаграмма деятельности должна соответствовать описанию варианта использования и его связям с действующими лицами на диаграмме вариантов использования. В сопровождающем текстовом файле должны быть объединены глоссарий проекта, составленный в виде таблицы, а также тексты описаний всех действующих лиц и всех вариантов использования с диаграммы ВИ из модели. Описания должны быть составлены на русском языке. Полное описание одного ключевого варианта использования, выбор которого был согласован с лектором, должно предшествовать кратким описаниям остальных вариантов использования. Описание действующего лица должно коротко (в одну-две строки) сообщать о роли данного лица. Примеры кратких описаний вариантов использования приведены в учебном пособии. В кратком описании варианта использования указываются основные действия (шаги) системы и действующих лиц в рамках основного потока (давать описание основного потока как полную последовательность шагов не следует). Краткое описание не подробно, так в нём нет шагов альтернативных потоков. Полное описание (ключевого) варианта использования должно включать в себя краткое описание, предусловие, гарантии успеха и минимальные гарантии, потоки событий (основной и альтернативные – один или более, без альтернативного потока описание не будет зачтено). Гарантии успеха (что истинно по окончании основного потока) и минимальные гарантии (что истинно всегда, в том числе при неуспехе) не могут быть пусты и/или бессмысленны.

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

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

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

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

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

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

По итогам выполнения третьего этапа через Moodle-форму сдаётся проектная модель (один VPP-файл проекта) и сопровождающий текстовый файл (DOC или PDF) с описаниями классов и интерфейсов. Как сопроводительный файл может быть сдан PDF-файл отчёта по заданию, если Вы его составите по своему желанию. Можно в первую попытку загрузить модель, в которой выполнены не все шаги из следующего списка, а 1-4 или больше. В таком случае стоит в сопровождающем файле дать пояснение, что проектная модель неполна и сдаётся частично.

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

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

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

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

  4. Разместить классы по пакетам в Design model, как это описано в учебном пособии.

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

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

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

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

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

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

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

  12. Для описания поведения экземпляров одного выбранного класса со сложным поведением построить диаграмму состояний. В проектной модели должна быть хотя бы одна нетривиальная диаграмма состояний с действиями. Не следует выбирать для составления диаграммы состояний граничный класс. Подходящим кандидатом, как правило, является класс-ключевая абстракция или «subsystem proxy&radaquo;-класс подсистемы.

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

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

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


1. Ветклиника

2. Кинокасса

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

4. Библиометрическая система

5. Система учёта преподавательской нагрузки

6. Огавирт: поиск гостиницы

7. Авиакасса

8. Авиабилетный терминал

Вариант 1. Ветклиника


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

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

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

  • недельный график работы ветеринаров;

  • перечень услуг и рецептов, относящихся к отдельному пациенту, оказанных/выписанных в заданный период времени;

  • счёт клиенту клиники на оплату медицинской услуги.

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

Вариант 2. Кинокасса


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

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

Система может получить сведения о том, что какие-то билеты были куплены в кассе или терминале кинотеатра. В таком случае система не допускает онлайновой продажи тех же самых билетов. Клиент может оформить полный или частичный возврат билетов за 1,5 часа до начала показа. Для этого он сообщает системе уникальный код, полученный им при покупке. Получив код, система выводит купленные билеты с указанием мест. Клиент указывает, какие именно билеты он желает вернуть. Возврат средств осуществляется через банковскую систему с использованием реквизитов, указанных при покупке. Возвращённые билеты могут быть куплены, если выполнены ограничения по времени. Сведения о возврате система может получить от касс кинотеатра. По истечении 1 месяца с момента покупки билета данные автоматически удаляются из системы. Данные о возвратах также хранятся лишь месяц.
В обязанности работников онлайновой кассы входит внесение в систему сведений о сеансах и об имеющихся в продаже билетах. Данные о сеансе – вид: 2D / 3D; название фильма; описание фильма; кинотеатр, № зала; дата и время начала сеанса, длительность фильма; – хранятся в системе. Один и тот же фильм может идти в разных кинотеатрах, или в разных залах одного и того же кинотеатра, но разные сеансы не могут пересекаться по времени и залу. Запись о билете содержит название фильма, дату, время, кинотеатр, зал, ряд и место, цену билета, статус билета (есть в наличии / выбран для покупки / выкуплен / доступен только офлайн). По истечении 1 недели с даты, указанной в билете, данные о нём автоматически удаляются из системы.

За 30 минут до начала сеанса все не проданные на него билеты передаются для реализации в кассы или терминалы кинотеатра. В системе они автоматически помечаются как "доступен только офлайн". Система ведёт учёт средств, потраченных клиентом для покупки билетов онлайн. Средства за возвращённые билеты в этой сумме не учитываются. Клиенты, потратившие более 5000, получают статус "постоянных". Клиенты, потратившие более 15000, -- vip-статус. Постоянные клиенты могут купить билеты со скидкой 5% на сеансы, участвующие в акции. Vip-клиенты могут купить билеты со скидкой 7% на любые сеансы.

Следует разработать схему реляционной базы данных кинокассы.

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


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

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

Для приобретения билета зритель должен указать дату сеанса, время, название фильма, номер зала, тип билета (взрослый, детский). Цена билета зависит от формата фильма (2D, 3D, IMAX), от зала, в котором проходит сеанс, от времени (утренние сеансы дешевле дневных, а дневные дешевле вечерних), от дня недели (с пятницы по воскресенье сеансы дороже), от расположения места в зале (ближе к середине находится так называемая vip-зона). Далее терминал демонстрирует схему зала и предлагает выбрать от 1 до 5 свободных мест в зале. О том, какие места свободны, терминал узнаёт от сервера киносети. Затем зритель должен вставить в ридер банковскую карту. После вставки банковской карты зритель должен ввести четырёхзначный пин-код. Если введён неверный пин-код, приобретение билета прекращается, а карта возвращается. Если пин-код верен, терминал по линии связи с банком отправляет запрос на операцию для оплаты билетов. Варианты ответов на запрос: операция одобрена банком; операция невозможна, так как карта блокирована; операция невозможна, так как превышен кредитный баланс. Если операция одобрена, сервер киносети информируется о проданных билетах, терминал печатает билеты, указывая дату, тип билета, зал, начало сеанса, название фильма, ряд, место и цену. На этом покупка билета завершается и на экран выводится главное меню. В ходе покупки зритель может раздумать и до момента оплаты поменять тип билета и другие параметры, или отказаться от покупки. Продажа билетов через терминал прекращается в момент начала сеанса.

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

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

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

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

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

Вариант 4. Библиометрическая система


Библиометрическая система предназначена для хранения сведений о научных публикациях, ссылок между публикациями и расчёта библиометрического показателя -- индекса цитирования автора. Операторы системы добавляют в систему данные о публикациях. Научный журнал или издательство присылает им соответствующие сведения в bib-файлах программы BibTeX (см. описание в Википедии). Оператор указывает имя файла, а система считывает данные и водит внутри себя записи о публикации. Если можно однозначно установить автора (авторов), что происходит не всегда, так как могут быть полные тёзки, то система связывает публикацию и автора. Если нет однозначности, то публикация помечается как возможно принадлежащая каждому полному тезке. Если автора в системе нет, то запись о нём автоматически создаётся.

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

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

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

Вариант 5. Система учёта преподавательской нагрузки


Чтобы автоматизировать учёт преподавательской нагрузки за учебный год, в университете внедрена система «Педнагрузка». Каждый преподаватель имеет в системе заведённый им аккаунт для доступа к функциям. В течение учебного года он вводит выполняемые им работы, входящие в нагрузку. Так, преподаватель может указать сведения о проведении им занятий: указывается название курса, количество студентов, слушающих курс, количество групп, количество часов лекций и/или семинаров, количество экзаменов, зачётов, контрольных, домашних работ. Система автоматически рассчитывает часы: за экзамены = 0,5 * количество студентов * количество экзаменов; за зачёты = 0,3 * количество студентов * количество зачётов; за контрольные = 0,25 * количество студентов * количество контрольных; за домашние работы = 0,2 * количество студентов * количество домашних работ; за семинары = количество часов по плану * количество групп. Также преподаватель может указать руководство практикой (по 12 часов на каждого студента); руководство курсовой работой (по 6 часов на каждого студента); руководство ВКР (по 25 часов на каждого студента); руководство диссертацией (по 50 часов на каждого аспиранта); приём вступительных экзаменов (в бакалавриат, магистратуру, аспирантуру) = 0,25 * количество проверенных работ; проверка олимпиад/универсиад = 0,3 * количество проверенных работ; рецензирование = 3 * количество рецензий. Все вычисленные часы суммируются и составляют суммарную нагрузку. Особенностью ввода нагрузки является то, что преподаватель может выполнять разные работы по одному и тому же курсу с разными или одними и теми же группами (например, читать потоковый курс всем группам потока и вести семинары по этому курсу только в одной из групп потока).

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

Нагрузка введённая преподавателями утверждается работником учебного отдела в конце учебного года. Затем она автоматически передаётся в систему «Справедливость» для расчёта рейтинга преподавателя. Утверждённую нагрузку скорректировать нельзя.

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

Сведения о нагрузке считаются актуальными за последние 5 учебных лет. Более поздние данные считаются устаревшими и автоматически удаляются из системы.

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

Вариант 6. Огавирт: поиск гостиницы


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

Представители гостиничных сетей регистрируются на сайте, после чего могут добавить в систему данные о своей гостинице или гостиницах: название, url сайта, юридический адрес и контактную информацию, url страницы с ежедневно обновляемым перечнем предлагаемых для бронирования номеров и цен. На указанной странице в формате CSV публикуются сведения о номерах: категории, описании, цене, url веб-страницы, с которой можно осуществить бронирование. Эти данные система регулярно запрашивает, чтобы поддерживать собственную базу данных в актуальном состоянии. Если сведения о номерах какой-либо гостиницы невозможно получить в течение 5 последних попыток обновления, то гостиница помечается, как недоступная. Для экономии трафика попыток обновить перечни номеров недоступных гостиниц не производятся. Менеджер может связаться с представителем недоступной гостиницы и либо деактивировать его учётную запись, а заодно убрать сведения о связанных гостиницах из системы, либо скорректировать url страницы с перечнем. В последнем случае менеджер помечает гостиницу как вновь доступный.

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

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

Рядовые пользователи сайта, желающие добавлять найденные предложения гостиниц в списки "Избранного", должны завести учётную запись и выполнить "вход" на сайт.

Следует разработать схему реляционной базы данных сайта "Огавирт".

Вариант 7. Авиакасса


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

Войдя в систему, клиент может ознакомиться с расписанием рейсов, указав город вылета, город прилёта и дату. Для продажи билетов доступны рейсы, время до вылета которых находится в диапазоне от 12 часов до 90 суток. Для каждого рейса в расписании указаны номер рейса, аэропорт вылета и аэропорт прилёта, время вылета, время прилёта, длительность рейса, модель авиалайнера и значок о наличии/отсутствии доступных для покупки билетов. Клиенту даётся возможность сортировки расписания по номеру рейса, времени вылета или прилёта, наличию билетов. Выбрав рейс в расписании, пассажир может купить нужное ему количество билетов. Единовременно одному клиенту система продаёт не более чем 3 билета на один рейс. Система сообщает клиенту перечень свободных мест. Места могут отличаться по классу обслуживания (эконом, бизнес-класс, первый класс). После выбора класса обслуживания, система выводит цена билетов, которая зависит от рейса, класса обслуживания, времени до вылета рейса (билеты, выкупаемые за 60 суток до вылета, предлагаются со скидкой 25%). Билеты могут быть получены клиентом до завершения регистрации на рейс в офлайновой кассе авиакомпании или в терминалах выдачи электронных билетов в аэропорту. Указав выбранные им места и сведения о пассажирах -- владельцах билетов (ф., и., о, № паспорта -- без этих полных сведений билеты не продаются), а также реквизиты своей банковской карты, клиент должен подтвердить покупку билетов. Получив сведения и подтверждение от клиента, система запрашивает списание средств у банковской системы. В ответ может придти либо подтверждение списания, либо сообщение об ошибке (недостаточно средств, неверные реквизиты, нет связи). При успешной оплате система сообщает клиенту уникальный код, который он использует для получения билета в кассе или в терминале. Соответствующие места помечаются, как выкупленные. Если возникла ошибка, система даёт клиенту возможность повторить ввод сведений о пассажирах, реквизитов и повторить попытку. Покупка билета должна быть совершена за не более чем 9 минут. Не допускается приобретение пассажиром нескольких билетов на своё собственное имя, если все билеты на один и тот же рейс и время вылета одинаковое.

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

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

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

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

Вариант 8. Авиабилетный терминал


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

Для приобретения билета пассажир должен указать дату, город вылета, город прилёта, класс обслуживания (экономический, бизнес-класс, первый класс). При желании, авиапассажир может указать номер рейса. Цена билета зависит от класса обслуживания, номера рейса, времени покупки (билеты, приобретаемые за 60 суток до вылета, предлагаются со скидкой 20%). Далее терминал выводит список подходящих рейсов, на которых есть незанятые места, того класса обслуживания, который нужен пользователю. Эти сведения терминал получает от сервера авиакомпании. Затем авиапассажир должен выбрать рейс (если он не сделал этого ранее, указав известный ему номер). Авиапассажир указывает сведения о владельцах билетов (ф., и., о, № паспорта -- без этих полных сведений билеты не продаются). Единовременно одному клиенту система продаёт не более чем 3 билета на один рейс. На своё имя пассажир не может купить более чем один билет на один и тот же рейс, если время вылета совпадает. Допускается приобретение пассажиром нескольких билетов на своё собственное имя на разные рейсы, вылетающие в разное время. Сообщив данные, пассажир должен вставить в ридер банковскую карту. После вставки банковской карты он должен ввести четырёхзначный пин-код. Если введён неверный пин-код, приобретение билетов прекращается, а карта возвращается. Если пин-код верен, терминал по линии связи с банком отправляет запрос на операцию для оплаты билетов. Варианты ответов на запрос: операция одобрена банком; операция невозможна, так как карта блокирована; операция невозможна, так как превышен кредитный баланс. Если операция одобрена, сервер авиакомпании информируется о проданных билетах, терминал печатает билеты, указывая в каждом № билета, класс обслуживания, № рейса, сведения о прилёте и вылете (аэропорты, даты и время) и цену. На этом покупка билета завершается. В ходе покупки пассажир может раздумать и до момента оплаты поменять класс обслуживания и другие параметры, или отказаться от покупки. Продажа билетов через терминал прекращается за 2 часа до вылета рейса. Покупка электронного билета должна быть совершена за не более чем 9 минут.

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

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

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

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

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

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

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


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

  

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

Обновлено: 3.II.2021