«проектування та розробка програмної системи з web-інтерфейсом на платформі. Net»

1 2 3 4 5

Ім'я файлу: Курсова.docx
Розширення: docx
Розмір: 761кб.
Дата: 13.10.2022
скачати
Пов'язані файли:
Хімія.pptx
аня.docx
РЕФЕРАТ.docx
KURSOVA_POJDA.docx
b37d3668f20a04e6bc0c2e89681aaeee.ppt
кандидоз.pdf
Правила безпечної роботи 5-Аклас С. Коржан.docx
Конспект уроку 5 клас (Виготовлення ялинкової прикраси).doc
urok_67.docx
філософія 2 тема 9 пит..docx
Презентация 1 (1).pptx
реферат електронна спектроскопія.docx
школа.docx
1 ал.docx
Мирнi_Мет.doc

НАЦІОНАЛЬНИЙ АВІАЦІЙНИЙ УНІВЕРСИТЕТ

Факультет кібербезпеки, комп’ютерної та програмної інженерії

Кафедра інженерії програмного забезпечення

Курсова робота

з дисципліни «архітектура програмного забезпечення»

на тему: «ПРОЕКТУВАННЯ ТА РОЗРОБКА ПРОГРАМНОЇ СИСТЕМИ З WEB-ІНТЕРФЕЙСОМ НА ПЛАТФОРМІ .NET»

Виконав студент: групи ПІ-228Б

Перевірив викладач:

Київ 2022

Зміст

Факультет кібербезпеки, комп’ютерної та програмної інженерії 1

Вступ 5

1. Аналіз предметної галузі 7

1.1 Виділення бізнес-процесів 7

1.2 Реінжиринг бізнес-процесів 11

2. Постановка задачі 16

2.1Визначення цілей та завдань та функцій ІС 16

3. Створення концептуальної моделі бази даних 22

3.1 Сутності 23

3.2 Атрибути 24

4. Створення прототипу системи 30

Висновок 32

Список використаних джерел: 33

Завдання

1. Спроектувати Web-застосування у відповідності з принципами багатошарової архітектури програмних систем та скласти проектну документацію.

1.1. Описати загальну архітектуру застосування, призначення її шарів та зв’язки між шарами (рівнями).

1.2. Вихідний код програмної системи представляє сукупність проектів різного типу, поєднаних одним рішенням. Описи типів розташовуються в окремих файлах. При необхідності бажано створити додаткові папки проекту, щоб код проекту був логічно структурований.

1.3. Представити діаграми класів кожного рівня, використовуючи UML-нотації.

2. Розробити застосування на мові C#, яке відповідає вимогам у варіанті. Відокремити рівні доступу до даних, бізнес-логіки та представлення.

2.1. Верхній рівень – представлення (UI), призначений для взаємодії з користувачем. Реалізувати окремим проектом. Для створення Web-інтерфейсу використати технологію ASP.NET WebAPI. На рівні UI повинні бути тільки операції взаємодії з користувачем. Код UI повинний бути максимально простим, неперевантаженим великою кількістю операцій. Ця частина системи (Front End) може бути реалізована будь-яким способом (для стилістичного оформлення допускається використання будь-яких фреймворків та бібліотек, наприклад, Bootstrap). Дані, з якими працює рівень представлення, повинні зберігатись в окремих моделях цього рівня (маються на увазі власні класи (типи) рівня, не запозичені з інших рівнів). Передбачити контроль\перевірку даних, введених користувачем (обов’язково заповнені текстові поля, довжина введених даних, тощо).

2.2. Проміжний рівень – бізнес-логіка, реалізований як динамічна бібліотека. На цьому рівні реалізується саме функціонал застосування, описаний у варіанті. Доречним буде застосувати відомі принципи та шаблони проектування. Для виконання операцій бізнес- логіки передбачити перевірку виняткових ситуацій - виключень. При необхідності створити власні класи виключень.

2.3. Нижній рівень – шар доступу до даних у вигляді бібліотеки. Збереження даних програмної системи виконується у реляційній БД під керуванням СУБД MS SQL. Для взаємодії зі сховищем даних використати ORM ADO .Net Entity Framework (code first). Доступ до даних для шару бізнес-логіки організувати через репозиторії, поєднані у одиницю роботи (їм відповідають шаблони проектування Repository та Unit of Work (UoF). Репозиторії надають доступ до набору сутностей (entities) певного типу. Одиниця роботи (UoW) є точкою єдиного доступу до репозиторіїв та контексту Entity Framework.

3. Шари взаємодіють між собою за наступним принципом: представлення використовує бізнес- логіку, бізнес-логіка – рівень доступу до даних. Для передачі даних крізь шари використовується технологія відображення (mapping).

4. При необхідності для більшої ізоляції основних рівнів можуть вводитися додаткові рівні (наприклад, винесення Repository та UoW).

5. Для ізоляції рівнів використати DI (Ninject чи Autofac).

6. Створити модульні тести для перевірки працездатності коду

6.1. За допомогою бібліотек NUnit чи XUnit написати модульні тести до бізнес логіки. Мінімальне покриття тестами – 50%. Покриття продемонструвати відповідними засобами, наприклад AxoCover, CodeCoverage та ін. Модульні тести повинні бути окремим проектом в рішенні.

6.2. Для оформлення коду модульних тестів овоб’язково застосовувати принцип Triple A.

6.3. За допомогою DI забезпечити, щоб тести для перевірки методів роботи з даними, ніяким чином не впливали на ці дані, використавши для даних об’єкти-емулятори чи замінювачі реальних даних (mock, stub).

7. Для визначення об’єму робіт та декомпозиції задач використати систему розподілу (відслідковування) задач. Це може бути Visual Studio Online/ Team Foundation Server online, Jira, Trello чи інша система. Для комплексної ітеративної розробки окремих компонентів застосування та спільного їх збору використовувати Visual Studio Online/ Team Foundation Server online або/ і GitHub.

8. Діаграма(-и) та вихідний код повинні відповідати основним принципам проектування: OOP, SOLID, Law of Demeter (LoD), DRY, YAGNI, KISS, cohesion – coupling, inheritance with caution. За невідповідність принципам оцінка за курсову може бути знижена.

9. При написанні коду притримуватися C#/.NET Code Conventions та кращих практик написання коду: іменування класів, об’єктів, властивостей, методів, інші назви повинні бути зрозумілими та відповідати їх задачам, форматувати код, не використовувати magic numbers, а також ставити мінімально необхідний модифікатор доступу (public повинен бути обґрунтований, а не використаний для всіх членів класу та класів проектів без виключення). За неохайне оформлення коду можливе зниження оцінки.

Варіант 2
(Номер студентського квитка, за яким розраховувався варіант: 13418031)

Номер варіанту	Предметна область	Вимоги та компоненти
2	Туристична агенція	Складається з підсистем: 1) підсистема додавання/ редагування турів, 2) підсистема виводу (гарячі тури, екскурсійні тури, країни/ регіони, по типу і т.д. – з фільтрами, пошуком), 3) підсистема бронювання туру, 4) підсистема бронювання квитка на певний вид транспорту чи номер во готелі. Ролі користувачів: адміністратор, менеджер, зареєстрований, незареєстрований. Менеджер може змінювати інформацію про тури. Зареєстрований користувач – бронювати. Незареєстрований – тільки переглядати.

1 2 3 4 5

скачати