Файл: Пояснительная записка к курсовому проекту по дисциплинам Проектирование и архитектура пс, Конструирование на н листах.docx

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

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

– при сбоях в системе электроснабжения аппаратной части, приводящих к перезагрузке ОС, восстановление программы должно происходить после перезагрузки ОС и запуска Системы;

– при ошибках в работе аппаратных средств (кроме носителей данных и программ) восстановление функций системы возлагается на ОС;

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

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

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

5. 
   Требования безопасности 
   

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

6. 
   Требования к эргономике и технической эстетике
   

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

7. 
   Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы
   

---

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

Для нормальной эксплуатации разрабатываемой системы должно быть обеспечено бесперебойное питание персональных компьютеров (ПК). При эксплуатации системы должна быть обеспечена соответствующая стандартам хранения носителей и эксплуатации ПК температура и влажность воздуха.

8. 
   Требования к защите информации от несанкционированного доступа
   

ИС должна обеспечивать защиту от несанкционированного доступа (НСД) на уровне, не ниже установленного требованиями, предъявляемыми к категории 1Д по классификации действующего РД Гостехкомиссии России [6].

Разрабатываемая система должна обеспечивать разграничение доступа на уровне отдельных программных модулей и структур данных. Компоненты подсистемы защиты от НСД должны обеспечивать:

– идентификацию пользователя;

– проверку полномочий пользователя при работе с системой;

– разграничение доступа пользователей на уровне задач и информационных массивов.

Разрабатываемая система должна использовать «слепые» пароли (при наборе пароля его символы не показываются на экране либо заменяются одним типом символов).

9. 
   Требования по сохранности информации при авариях
   

Программное обеспечение Системы должно восстанавливать свое функционирование при корректном перезапуске аппаратных средств. Должна быть предусмотрена возможность организации автоматического и (или) ручного резервного копирования данных системы средствами системного и базового программного обеспечения (ОС, СУБД), входящего в состав программно-технического комплекса Заказчика.

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

10. 
    Требования к защите от влияния внешних воздействий
    

Требования к защите от влияния внешних воздействий не предъявляются.

---

11. 
    Требования к патентной чистоте
    

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

12. 
    Дополнительные требования
    

Специальные требования не предъявляются.

2. 
   Требования к функциям, выполняемым системой
   

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

1. 
   Модель вариантов использования
   

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



Рис.3.2.1 Диаграмма вариантов использования

Цель ВИ «Посмотреть каталог автомобилей» - просмотреть информацию, размещенную на странице каталога информацию из БД, по такому же принципу работает и ВИ «Посмотреть каталог доп. аксессуаров».

ВИ «Отправить заявку на покупку»: пользователь хочет приобрести определенный автомобиль, но в данный момент его нет в наличии. Тогда ему необходимо оставить заявку на покупку в виде своего номера и имени. Администратор автосалона свяжется с потенциальным клиентом. Клиенту нужно будет внести предоплату в салоне, и после внесения оформляется заказ на пригон необходимой машины в автосалон.

Вариант использования «Вести каталог товаров» подразумевает ведение администратором БД, обновление информации о товарах в наличии.

Вариант использования «Просмотр заявок пользователей»: администратор автосалона просматривает занесенные в БД заявки и устанавливает статус «Одобрена» или «Не одобрена».

2. 
   Спецификация вариантов использования
   
   1. 
      Создать договор купли-продажи
      

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

Рис. 3.2.1

Краткое описание

Сценарий использования «Создать договор купли-продажи» позволяет администратору автосалона оформлять с клиентом сделку на покупку автомобиля или дополнительных аксессуаров.

---

Предусловия

БД содержит данные заявок, которые сможет одобрить администратор.

Постусловия

Программа обновила БД CD.

БД CD осталась в неповрежденном состоянии, если произошли какое-либо исключение или ошибка.

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

2. Основной поток

Функционирование сценария использования начинается, когда администратор желает просмотреть заказов пользователей и создать договора купли-продажи. (см. рис. 4.2)

Система отображает информационное сообщение и запрашивает у служащего имя пользователя (login) и пароль (password).

• Система пытается соединить служащего с БД CD.

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

1) Полная информация о клиенте (ФИО, дата рождения, паспортные данные)

2) Полная информация об автомобиле/аксессуаре, который приобретает клиент.

3) Указание способа оплаты товара (наличные средства/банковская карта/кредит)

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

2.1 Поток исключений E1 — Incorrect username or password (неправильное имя пользователя или неправильный пароль)

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

2.2 Поток исключений Е2 — Incorrect order (неправильное оформление заказа)

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

2.3. Поток исключений ЕЗ — Too many position (слишком много позиций)

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

2.3. Поток исключений ЕЗ — Too many position (слишком много позиций)

---

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

3. Временной регламент выполнения функций

Время отклика для потоков должно быть меньше 5 секунд с 90-процентной вероятностью.

3. 
   Требования к видам обеспечения
   
   1. 
      Требования к математическому обеспечению
      

Требования к математическому обеспечению не предъявляются.

2. 
   Требования к информационному обеспечению
   

Уровень хранения данных в Системе должен быть построен на платформе реляционной СУБД. Для обеспечения целостности данных должны использоваться встроенные механизмы СУБД.

База данных предназначена для хранения:

• 
  сведений о клиентах,
  
• 
  сведений об администраторов,
  
• 
  сведений о товарах,
  
• 
  сведений о заказах,
  

3. 
   Требования к лингвистическому обеспечению
   

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

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

4. 
   Требования к программному обеспечению
   

Проект должен использовать СУБД Microsoft SQL Server 2019, но он должен быть легко перестраиваемым для других реляционных БД.

Структурное     проектирование     системы     должно     соответствовать разделению на слои представления (Presentation Layer), бизнес-логики (Business Logic Layer) и доступа к данным (Data Access Layer), чтобы обеспечить надлежащее удобство сопровождения и масштабируемость.

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

Разрабатываемая Система должна быть рассчитана на функционирование в следующей программной среде:

Серверная группа

ПО, устанавливаемое на компьютеры серверной группы:

Базовая ОС – Microsoft Windows 2019 Server.

Средство для web-публикации локальных информационных ресурсов – Internet Information Server (Входит в состав базовой операционной системы).

Система управления базами данных – MS SQL Server 2019.

Firewall для защиты внутренних ресурсов системы, при наличии подключения к транзитным провайдерам услуг передачи данных – Microsoft ISA Server.

---