Отчет о выполнении лабораторной работы № 2 по дисциплине «Проектирование и архитектура программных средств»
ЗАДАНИЕ
1.Выбрать предметную область для проектирования:
(вариант 5: онлайн сервис записи на тест-драйв).
2.Перечислить основные функциональные и нефункциональные требования к разрабатываемому программному обеспечению.
3.Выбрать архитектурные стили, наиболее подходящие для реализации перечисленных требований.
4.Построить диаграмму классов разрабатываемого ПО.
5.формулировать текстовое описание каждого класса, представленного на диаграмме классов, и его основных методов.
6.Описать влияние выбранных архитектурных стилей на структуру классов разрабатываемого ПО.
КРАТКОЕ ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ
Онлайн сервис предназначен для записи клиентов на тест-драйв. Для организации такого сервиса в базе предусмотрены записи о доступных автомобилях. База пополняема. Клиент создает заявку, администратор системы ее рассматривает и назначает дату и время.
ТРЕБОВАНИЯ К ПО
Обеспечить справочник автомобилей.
Обеспечить ведение базы клиентов.
Обеспечить автоматизацию управления заявками.
Обеспечить создание системой отчетов: записи на выбранный день, записи по свободным автомобилям, статус выбранного автомобиля, записи на выбранный автомобиль, полный отчет по выполненным тест-драйвам.
ДИАГРАММА КЛАССОВ
На рисунке 1 приведена диаграмма классов, выполненная в соответствии с предъявленными требованиями.
Рисунок 1 – Диаграмма классов
ОПИСАНИЕ АРХИТЕКТУРЫ ПРОГРАММЫ
Приведенная на рисунке диаграмма классов включает в себя сочетание фрагментов нескольких архитектурных стилей, среди которых присутствуют:
Стиль «Использует» — для описания отношений класса Заявка и Клиент / Автомобиль. Использование данного стиля позволяет реализовать инкрементные разработку и внедрение программного продукта. Кроме того, стиль «Использует» позволяет планировать процессы тестирования, отладки и внесения изменений в программное обеспечение.
Отчет о выполнении лабораторной работы № 1 по дисциплине «Проектирование и архитектура программных средств»
Необходимо создать диаграммы UML в предметной области «Онлайн сервис записи на тест-драйв»:
1)Выбрать два объекта из предметной области, для которых характерны наличие нескольких, не менее пяти, состояний на разных стадиях работы разрабатываемого программного продукта (ПП) и переходов между ними. Разработать диаграмму состояний для выбранных объектов
2)Выбрать один из наименее тривиальных алгоритмов, которые необходимо реализовать в рамках выбранной предметной области и разработать диаграмму деятельности для выбранного алгоритма.
3)Перечислить основные функциональные и нефункциональные требования к разрабатываемому ПО, выбрать архитектурные стили, подходящие для реализации перечисленных требований и построить диаграмму классов разрабатываемого ПП.
1.ДИАГРАММЫ СОСТОЯНИЙ ОБЪЕКТОВ ПРЕДМЕТНОЙ ОБЛАСТИ
В качестве объектов предметной области, изменяющих свое состояние, могут быть выделены заявки на тест-драйв (Order) и автомобили (Car), которые предоставляются для тест-драйва.
Заявка может принимать следующие состояния:
New – состояние, в котором пользователь создал в системе новую заявку на рассмотрение.
Declined – состояние, в котором находится заявка пользователя, отклоненная администратором системы.
Assigned – состояние, в котором находится заявка после ее подтверждении администратором. В этом состоянии заявке присвоена дата и время, в которое должен прийти клиент. Время и дата могут быть перенесены как администратором системы, так и самим клиентом – это объясняет наличие рефлексивной связи у состояния Assigned.
Suspended – состояние, в котором находится приостановленная заявка. В этом состоянии заявка не отменяется, но приостанавливается до особых обстоятельств (например, требуемая машина отсутствует и т.д.). Из этого состояния заявка может быть возвращена в состояние Assigned при появлении соответствующей возможности.
Completed – конечное состояние заявки, которое свидетельствует о получении услуги клиентом. Заявка помещается в архив как исполненная.
Диаграмма состояний объекта Order, иллюстрирующая граф переходов между описанными состояниями, в нотации UML, приведена на рисунке 1.
Рисунок 1 – Диаграмма состояний объекта Order
Объект Car в рамках рассматриваемой системы может принимать следующие состояния:
Registered – состояние нового объекта, занесенного в систему, но еще на доступного для оказания сервиса.
Assigned – состояние объекта, означающее, что на данный автомобиль уже имеется одна или несколько заявок.
Wait – состояние объекта, означающее, что на данный автомобиль нет ни одной заявки.
Busy – состояние объекта, показывающее, что в данный момент автомобиль находится в режиме исполнения заявки.
OutOfService – состояние объекта, вводимое на время вывода автомобиля из зоны сервиса: например, временное отсутствие автомобиля, связанное с устранением технической неполадки. После ее устранения, объект вновь возвращается в состояние ожидания Wait, либо объект совсем исключается из списка автомобилей и больше недоступен для сервиса.
Диаграмма состояний объекта Car, иллюстрирующая граф переходов между описанными состояниями, в нотации UML, приведена на рисунке 2.
Рисунок 2 – Диаграмма состояний объекта Car
2.ДИАГРАММА ДЕЯТЕЛЬНОСТИ РАБОТЫ ПОЛЬЗОВАТЕЛЕЙ
Основной алгоритм работы пользователей заключается в создании клиентом заявки и управлении администратором сервиса этой заявкой.
На рисунке 3 приведена соответствующая диаграмма действий, отражающая фундаментальную схему работы пользователей с сервисом. На диаграмме дифференцированы действия каждого участника.
Рисунок 3 – Диаграмма действий работы пользователей с сервисом