Дизајн на системот

Иницијална архитектура

1. Користени технологии

Треба да имате објаснето и зошто ги користите овие рамки, а не други.

Корегирано

Laravel

Laravel е PHP рамка со отворен код, која е робусна и лесна за разбирање. Следи шема на model-view контролер. Laravel со повторување ги користи постојните компоненти на различните рамки што помага во креирање веб -апликација. На тој начин дизајнираната веб -апликација е повеќе структуирана и прагматична. Laravel нуди богат сет на функционалности што ги вклучува основните карактеристики на PHP, рамките како CodeIgniter, Yii и други програмски јазици како Ruby on Rails. Има многу богат сет на карактеристики што ќе ја зголемат брзината на веб -развој. За база на податоци се користи MySQL 5.7 [5].

Кога дизајнираме веб -апликација со Laravel, тој ги нуди следниве предности [6]:

• Веб -апликацијата станува повеќе скалабилна

• Заштедено е значително време при дизајнирање на веб -апликација, бидејќи Laravel повторно ги користи компонентите од друга рамка при развивање веб -апликација.

• Вклучува интерфејси, со што помага да се организираат и управуваат ресурсите

Blade

Blade е едноставен, но моќен engine за шаблони што е вклучен во Laravel. За разлика од некои PHP engines за шаблони, Blade не не ограничува да користиме обичен PHP код во нашите шаблони. Всушност, сите Blade шаблони се компајлираат во обичен PHP код и се чуваат во кеш додека не се изменат, што значи дека Blade во суштина додава нула трошоци на вашата апликација. Датотеките со шаблоните на Blade ја користат наставката на датотеката .blade.php и вообичаено се складираат во директориумот за ресурси. [7].

Bootstrap

Bootstrap е бесплатна рамка со отворен код за создавање веб-страници и веб-апликации. Рамката Bootstrap е изградена на HTML, CSS и JavaScript (JS) за да го олесни развојот на веб-страници и апликации за мобилни телефони.

Реактивниот дизајн овозможува веб-страница или апликацијата да ја открие големината и ориентацијата на екранот на посетителот и автоматски да го прилагоди приказот соодветно. Bootstrap вклучува компоненти на кориснички интерфејс, распоред и JS алатки заедно со рамката за имплементација.

Кај компјутерите, зборот bootstrap значи да се подигне: да се вчита програма во компјутер користејќи многу помала почетна програма за да се вчита во саканата програма (која обично е оперативниот систем) [8].

Зошто Laravel?

Одбрав да ја развијам апликацијата во Laravel затоа што е PHP рамка која обезбедува пред се лесен и едноставен начин на дефинирање на кодот со помошни класи и методи интегрирани во рамката. Исто така обезбедува Artisan CLI за едноставни и брзи команди т.е. доаѓа со сопствен интерфејс за командна линија (CLI). Ова го прави развојот на веб-апликациите многу по едноставен. Исто така убавината е во тоа што PHP е бесплатен за користење, има нај широка подршска од заедницата во споредба со другите програмски јазици. Поврзувањето со разни видови датабази, безбедноста и брзината на процесирање датотеки во Laravel сее исто така круцијални. Исто така темплејтите кои може да се креираат преку Blade прават поврзување со моделот, го обработува кодот во изворните шаблони и нуди излез во текстуална датотека. Laravel обезбедува Blade Template Engine. Blade нуди прикажување податоци и проширување на распоредот без да се наруши брзината и перформансите на апликацијата. Згора на тоа, познато е дека Blade доаѓа со своја структура и формација за креирање и прегледување датотека.

2. Архитектура

Тука имате премногу опишување на клиент-сервер архитектура. Доволно е кратко да се каже што е, да се даде референца, и да се објасни зошто сте избрале ваква архитектура.

Корегирано, текстот е скратен и наведени се причини зошто клиент-сервер наместо p2p

Мрежната инфраструктура функционира базирано на моделот клиент-сервер. Клиент-сервер архитектурата е компјутерски модел во кој серверот е домаќин (host). Тој испорачува и управува со повеќето ресурси и услуги што треба да ги потроши клиентот. Овој тип архитектура има еден или повеќе клиентски компјутери поврзани со централен сервер преку мрежа или интернет конекција. Системот прави поделба на компјутерски ресурси. Архитектурата клиент/сервер е исто така позната како компјутерски модел за вмрежување или мрежа на клиент/сервер бидејќи сите барања и услуги се испорачуваат преку мрежа. Централниот сервер е поврзан со базата на податоци, додека серверскиот оперативен систем е Linux. Клиентот треба да поседува стабилна интернет врска за да може да оствари комуникација со серверот [9].

Клиент-сервер архитектурата во споредба со peer-to-peer ја одбрав поради следните причини:

• Подобрено споделување податоци - податоците се чуваат со вообичаени деловни процеси и се манипулираат со сервер и се достапни за назначени корисници (клиенти) преку овластен пристап.
• Интеграција на услуги - на секој клиент му е дадена можност да пристапи до корпоративни информации преку работниот интерфејс, елиминирајќи ја потребата да се логира во терминален режим или друг процесор. Алатките за работна површина како табеларни пресметки, презентации на power point итн. може да се користат за справување со корпоративни податоци со помош на бази на податоци и сервери за апликации кои се наоѓаат на мрежата за да произведат значајни информации.
• Заеднички ресурси меѓу различни платформи - апликациите што се користат за моделот клиент/сервер се изградени без оглед на хардверската платформа или техничката позадина на оперативниот софтвер, обезбедувајќи отворена компјутерска околина, со што се овозможува корисниците да ги добијат услугите на клиентите и серверите (база на податоци, апликација, сервери за комуникација).
• Можност за обработка на податоци и покрај локацијата - Преку клиент-сервер, корисниците можат директно да се најават во системот и покрај локацијата или технологијата на процесорите на различните машини што се користат во денешно време.
• Лесно за одржување - Архитектурата клиент-сервер е дистрибуиран модел што претставува дисперзирани одговорности меѓу независни компјутери интегрирани низ мрежа, затоа и претставува предност во однос на одржувањето.
• Безбедност - серверите овозможуваат квалитетна контрола врз пристапот и ресурсите со што се гарантира дека само овластените клиенти можат да пристапат или манипулираат со податоците, и ажурирањата на серверот се администрираат ефикасно.

Клиент-сервер архитектура на системот

Недостасува дијаграм за внатрешната архитектура на вашата апликација. Овој дијаграм е повторување на претходниот.

Корегирано

Пред описот на вашата конкретна архитектура, треба да ги имате наведено користените технологии, бидејќи треба да е видливо каде во дизајнот на вашата архитектура влегуваат овие технологии.

Корегирано

2. Класен дијаграм

UML Class дијаграмот е графичка нотација што се користи за конструирање и визуелизација на објективно-ориентирани системи. Класен дијаграм во Унифицираниот јазик за моделирање (UML) е тип на дијаграм за статичка структура што ја опишува структурата на системот со прикажување на системот и неговите атрибути,операции (или методи) како и односите меѓу нив. [10]

Ако е класен дијаграм за објектно-релациско мапирање на базата, тогаш треба да ги прикажете само класите од Models, а гледам тука има и други, има и методи кои во класите во Models ги нема или некои методи недостасуваат. Ако не е тоа, тогаш објаснете попрецизно што прикажува дијаграмот.

Методите од тип класа се методи кои ги имам дефинирано како релации помеѓу моделите (за секој модел посебен метод во зависност од типот на релација) и затоа ги имам додадено за секој модел кој што е во релација.

На сликата подолу е прикажан класен дијаграм на базата на податоци која се користи за системот за архивско работење SaveSpace. Може да се забележи дека клучна класа е класата Folders со која се поврзани поголем дел од останатите класи. Од оваа класа се креираат повеќе видови на објекти, односно сите видови на архивски датотеки кои ќе бидат додадени на сервер. Може да се забележи дека се чуваат пoдатoци за корисникот, оддели (физичка локација), архивски број и слично што во нашиот случај се вадат како регистри и подоцна се користат за формирањее на гoлемата слика т.е. архивските документи.

Во архивското работење многу битен податок е да има увид кој корисник (референт) ги има внесено датотеките (документите) и дали се внесени во правилен формат. На сликaта подолу може да се види дека во класата Folders се чуваат податоци за корисникот кој ја додал и времето кога биле додадени датотеките. Преку класата Files се внесуваат датотеките во одреден фолдер кои подоцна ќе бидат зачувани во базата на податоци. Една датотека од класата Folder може да има неколку прилози со различни имиња. Во класата Permissions се зачувани имињата на пермисиите кои ќе се зачувуваат во класата Roles_permissions која е во релација со класата Roles каде се зачувани имињата на ролјите со цел за секоја ролја да може да се додели одредена пермисија. Класата Roles е во релација со класата User преку која се доделува ролја на корисникот. Во класата Password_resets се зачувува секој обид за промена на лозинка со цел да token-от да не важи повеќе од даденото време. Во класата File_types се зачувуваат валидациските правила за прикачувани на датотеки.

Корегирајте го класниот дијаграм. Рамките обично означуваат пакување на класите во пакет, па треба да стои името на пакетот - а тоа сигурно не е SaveSpace UML. Ако ставате име на пакет треба да е во обичен правоаголник. Кардиналноста на асоцијациите не се означува со N туку со *. Ако имате асоцијација со референца од една класа кон друга, не треба да имате и атрибут и линија, туку само линија со навигациска стрелка во насока на референцата и име на референцата на линијата.

Корегирано. Пакувањето на класите или namespace како се нарекува во laravel за апликацијата е savespace.

UML класен дијаграм на апликацијата

3. Структура на базата на податоци

Како што е напоменато и горе за базата на податоци користев MySQL 5.7. Конфигурацијата за конекцијата со базата е во .env конфигурациската датотека во главниот директориум на проектот. Базата е составена од вкупно девет табели и тоа:

• roles
• permissions
• roles_permissions
• users
• password_resets
• departments
• folders
• files
• file_types

На сликата подолу графички е прикажана структурата на базата со податоци, заедно со табелите и нивната взаемна поврзаност.

Шематски приказ на базата со податоци

3.1. Табели roles, permissions и roles_permissions

Табелата "roles" ги содржи ролјите во полето име додека "permissions" табелата името на пермисијата која се означува по тип на ролја во табелата "roles_permissions" која ги содржи ид-то на ролја и ид-то на пермисија.

Полиња во табелата "roles":

• id - идентификациски број кој е запишан при конфигурација на базата на податоци
• name - име што означува ролја

Примарен клуч: id

Полиња во табелата "permissions":

• id - идентификациски број кој е запишан при конфигурација на базата на податоци
• name - име што означува дозволена пермисија

Примарен клуч: id

Полиња во табелата "roles_permissions":

• role_id - идентификациски број за ролја
• permission_id - идентификациски број за пермисија

Примарен клуч: role_id, permission_id Надворешен клуч: role_id - референцира кон id во табелата "roles", permission_id - референцира кон id во табелата "permissions"

3.2. Табела "users"

Во табелата "users" се содржат информации за профилот на корисникот и неговите податоци. Секој корисник има можност да ги менува своите податоци како и своите сетинзи како што се корисничко име, е-адреса или лозинка.

Полиња:

• id - идентификациски број кој е генериран при регистрација на корисникот
• name - име
• surname - презиме
• username - корисничко име за најава
• email - е-адреса за добивање нотификации
• phone_number - контакт број за корисник
• avatar - патека на поставена слика за профилот
• role_id - идентификациски број за ролја
• is_active - дали профилот е активен
• is_online - дали во моментот е најавен
• is_confirmed - дали профилот е потврден
• is_forgot_password - дали е пуштено барање за промена на лозинка
• created_by - идентификациски број кој укажува од кого е креиран корисникот
• security_code - верификациски код за најава
• verify_token - хексадецимален стринг за верификација на најавата
• password - лозинка
• remember_token - хексадецимален стринг за зачување на податоците за најава
• created_at - време кога е креиран профилот
• updated_at - време кога последен пат се ажурирани податоците
• last_seen - време кога последен пат се најавил корисникот

Примарен клуч: id Надворешен клуч: role_id - референцира кон id во табелата "roles", created_by - референцира кон id во табелата "users"

3.3. Табела "password_resets"

Табелата "password_resets" претставува табела во која се зачува барањето кое корисникот го пушта за промена на лозинка. За барањето се чува е-адресата, токенот како и времето кога е пуштено со цел да се ограничи времетраењето на важност на барањето.

Полиња:

• email - е-адреса за испраќање на нотификацијата
• token - хексадецимален стринг за верификација на профилот
• created_at - време кога е пуштено барањето

3.4. Табела "departments"

Табелата "departments" претставува табела во која се зачувани сите оддели на компанијата кои се креирани од администраторот или референтот.

Полиња:

• id - идентификациски број кој е генериран при креирање на оддел
• name - име
• code - код
• user_id - идентификациски број кој укажува од кого е креиран одделот
• location - локација на директориумот на одделот на сервер
• no_of_folders - број на фолдери асоцирани со одделот
• created_at - време кога е креиран одделот
• updated_at - време кога последен пат се ажурирани податоците

Примарен клуч: id Надворешен клуч: user_id - референцира кон id во табелата "users"

3.5. Табела "folders"

Табелата "folders" претставува табела во која се зачувани сите фолдери т.е. документи кои се креирани од администраторот или референтот.

Полиња:

• id - идентификациски број кој е генериран при креирање на оддел
• arch_id - архивско ид на документот
• name - име
• note - текст за забелешка
• location - локација на директориумот на одделот на сервер
• no_of_files - број на датотеки асоцирани со документот
• user_id - идентификациски број кој укажува од кого е креиран фолдерот
• department_id - идентификациски број за припадност на документот во оддел
• version - верзија на документот
• created_at - време кога е креиран фолдерот
• updated_at - време кога последен пат се ажурирани податоците

Примарен клуч: id Надворешен клуч: department_id - референцира кон id во табелата "departments", user_id - референцира кон id во табелата "users"

3.6. Табела "files"

Во табелата "files" се зачувани сите датотеки т.е. податоци за локацијата на датотеките на сервер, нивното име и големина.

Полиња:

• id - идентификациски број кој е генериран при креирање на оддел
• name - име
• location - локација на директориумот на одделот на сервер
• folder_id - идентификациски број за припадност на датотеката во фолдер
• created_at - време кога е закачена датотеката
• updated_at - време кога последен пат се ажурирани податоците

Примарен клуч: id Надворешен клуч: folder_id - референцира кон id во табелата "folders"

3.7. Табела "file_types"

Во табелата "file_types" се зачувани валидациските правила поставени од администраторот за прикачување на датотеки.

Полиња:

• id - идентификациски број кој е генериран при креирање на оддел
• name - име
• mimes - типови на датотеки
• max_size - максимална дозволена големина по датотека
• user_id - идентификациски број кој укажува од кого е креиран записот
• created_at - време кога е креиран профилот
• updated_at - време кога последен пат се ажурирани податоците

Примарен клуч: id Надворешен клуч: user_id - референцира кон id во табелата "users"

Ако ставате секценцијален дијаграм воопшто, наведете го прецизно онака како што е реализирано. Значи да бидат наведени конкретните класи кои влегуваат во интеракцијата од почеток до крај, од комуникација со корисник до запишување во база и фајл систем. Означете од кои пакети се класите, бидејќи се сите од различни пакети. Пораките мора да бидат конкретните методи кои ги има во класите, кај вас не се. На пример во Folder класата немате Upload files. Ни во User немате Verify login.

Избришано