AKADEMIA EKONOMICZNO-HUMANISTYCZNA W WARSZAWIE

KIERUNEK STUDIÓW: INFOMATYKA

Mykola Chavhun

studia stacjonarne

nr albumu: 36084

TEMAT PRACY

Tworzenie komercyjnej aplikacji dla zwierząt domowych "Petsy",

z wykorzystaniem architektury zorientowanej na usługi (SOA) i

stosu nowoczesnych technologii.

Praca licencjacka

napisana pod kierunkiem

Dra Feliksa Kurpa

WARSZAWA, 2020


 
SPIS TREŚCI 
SPIS TREŚCI .................................................................................................................................. 2 
ZYCIORYS ..................................................................................................................................... 4 
WSTĘP ............................................................................................................................................ 5 
ANALIZA OBSZARU TEMATYCZNEGO ............................................................................... 8 
1 ARCHITEKTURA ZORIENTOWANA NA USŁUGI ................................................... 8 
1.1 USŁUGI INTERNETOWE (Web services) ................................................................... 8 
1.2 KOLEJKA WIADOMOŚCI (MQ) ............................................................................... 10 
1.3 ENTERPRISE SERVICE BUS (ESB). ........................................................................ 11 
1.4 MIKROUSŁUGI .......................................................................................................... 12 
1.5 PORÓWNANIE ZALET I WAD WZORCÓW ........................................................... 14 
2 ARCHITEKTURA NOWOCZESNEJ APLIKACJI MOBILNEJ ...................................... 16 
2.1 WPROWADZENIE...................................................................................................... 16 
2.2 Z CZEGO SKŁADA SIĘ APLIKACJA SERWEROWA? .......................................... 17 
2.3 Z CZEGO SKŁADA SIĘ APLIKACJA KLIENCKA? ............................................... 18 
3 BADANIE STOSU TECHNOLOGII UBER ...................................................................... 22 
3.1 BOTTOM: PLATFORM .......................................................................................... 22 
3.2 MIDDLE: MARKETPLACE ................................................................................... 26 
3.3 TOP: WEB AND MOBILE ...................................................................................... 27 
WYBÓR METOD PROJEKTOWANIA I MODELOWANIE SYSTEMU ............................. 30 
1 PROJEKT GRAFICZNY APLIKACJI ............................................................................... 30 
2 WYMOGI FUNKCJONALNE I NIEFUNKCYJNE .......................................................... 34 
2 PROJEKT ARCHITEKTURY SYSTEMU Z UŻYCIEM UML ........................................ 36 
2.1 PRZYPADEKI UŻYCIA: ............................................................................................ 37 
2.2 DIAGRAM DZIAŁANIA ............................................................................................ 41 
2.3 DIAGRAM SEKWENCJI ............................................................................................ 42 
3 OPIS STOSOWANYCH TECHNOLOGII. ........................................................................ 43 
WDROŻENIE APLIKACJI I DOKUMENTACJI ................................................................... 49 
1 APLIKACJA SERWEROWA ........................................................................................ 50 
2 APLIKACJA KLIENTA ................................................................................................ 58 
WDROŻENIE SYSTEMU I WSPARCIE ................................................................................. 68 
1 PROBLEM Z HOSTOWANIEM USŁUGI WCF REST W SYSTEMIE UBUNTU ........ 69 
2 ROZWIĄZYWANIE PROBLEMÓW ................................................................................ 69 
CZĘŚĆ 5. WNIOSEK ................................................................................................................... 73 

5.1 DALSZY ROZWÓJ PROJEKTU ....................................................................................... 73

LISTA SKRÓTÓW ....................................................................................................................... 75

BIBLIOGRAFIA ........................................................................................................................... 76

LISTA IUSTRACJI ....................................................................................................................... 78

DODATEK .................................................................................................................................... 81

ZYCIORYS

Urodziłem się 14.06.1997 w małym miasteczku Ukrainy o nazwie Szostka. Uzyskałem

wykształcenie podstawowe i średnie w tym samym mieście.

Od dzieciństwa interesowałem się inżynierią, miałem lutownicę, rozbierałem zabawki i

tworzyłem z nich coś nowego. W wieku 13 lat w 2010 roku miałem pierwszy komputer i od tego

momentu zacząłem interesować się technologią komputerową. Ale nigdy nie myślałem, że

inżynieria stanie się moim zawodem, to było Moje hobby. W rzeczywistości, w dzieciństwie

chciałem być biznesmenem.

Po szkole otrzymałem wykształcenie medyczne w moim mieście. Ponieważ nie

widziałem siebie w medycynie, zacząłem rozważać dalszą edukację i otworzyłem dla siebie

studia w Warszawie, a mianowicie WSFiZ. Podobał mi się Wydział Zarządzania i podobał mi

się Wydział Informatyki. Myślałem przez około miesiąc, ważyłem plusy i minusy i

postanowiłem uczyć się informatyki, motywując to tym, że jest to bardziej złożona i użyteczna

specjalność, a zarządzanie można nauczyć się samodzielnie.

Na drugim roku byłem bardzo zaangażowany w rozwój Javy i wszystkie powiązane

technologie. Na trzecim roku w poszukiwaniu pracy jako programista java, podjąłem pracę w

firmie Nielsen jako deweloper .NET. Pracowałem tam przez 6 miesięcy. Teraz programuję w

Javie i. NET, uczę się także metody projektowania oprogramowania i wzorców programowania.

Uważam, że nie należy ograniczać się do jednego języka lub technologii, o wiele ważniejsze jest

poznanie całego cyklu rozwoju oprogramowania jako całości, wtedy nie ograniczasz się do

określonego języka lub technologii. A jeśli chce i ma Bazę Wiedzy, dobry specjalista jest w

stanie nauczyć się nowej technologii w ciągu miesiąca.

WSTĘP

Cel pracy dyplomowej:

 Tworzenie komercyjnej aplikacji „Petsy”

 Opis pełnego cyklu tworzenia aplikacji komercyjnej z wykorzystaniem najnowszych

technologii dostępnych dla zwykłego programisty.

 Zbadanie możliwości stworzenia pełnoprawnego projektu od jego zaprojektowania, do

uruchomienia systemu na własnym serwerze, mając jedną osobę w zespole.

Opis projektu:

Z badan (www.rmf24.pl/fakty/polska/news-sondaz-ponad-polowa-polakow-ma-w-domu-

jakies-zwierze,nId,2396840

), wynika ze 52% polaków mają zwierzęta domowe.

„Uber dla zwierząt!” –

Idea projektu:

Połączyć między sobą ludzi którzy mają zwierzęta i ludzi, którzy proponują następne usługi -

wyprowadzanie oraz niania dla zwierząt.

Stworzyć wygodny serwis dla:

 Wyszukiwania

 Opinii

 Opłaty usług

 Komunikacja (chat dla obu stron)

 Efektywnego monitoringu wykonywania zamówienia (np. Zdjęcie/ Film zwierzątka)

Aplikacja będzie dostępna dla: Android, IOS, WEB.

Dlaczego SOA?

Artykuł o badaniu odsetka Polaków, którzy mają zwierzęta domowe. Adres: www.rmf24.pl/fakty/polska/news-

sondaz-ponad-polowa-polakow-ma-w-domu-jakies-zwierze,nId,2396840 [Data uzyskania dostępu: 06.09.2020r.]

Przy wykorzystaniu przestarzałej monolitnej architektury wynika następujący problem:

trzeba tworzyć oddzielne aplikacje dla każdej platformy oraz tworzyć synchronizację danych. To

powoduje wzrost kosztów.

Natomiast SOA daje możliwość podzielenia aplikacji na konsumenta i producenta.

Producenci odpowiadają za logikę aplikacji i chronione dany (biznes logika, autoryzacja,

uwierzytelnianie). Konsument - interfejs, który może być otworzony na dowolnej platformie,

która ma dostęp do Internetu: Android, IOS, WEB.

Takie podejście, wraz z możliwością wieloplatformowego rozwoju na wielu systemach,

takich jak Xamarin, pozwala zmniejszyć koszty pracy w rozwoju o rząd wielkości. Co daje

możliwość rozwijania podobnych systemów jednej osobie.

Zakres pracy

Struktura mojej pracy odpowiada modelowi rozwoju oprogramowania typu kaskadowego

lub „Model wodospadu” i wygląda następująco:

Rysunek 1 „Waterfall model”

Każda część pracy odpowiada każdemu etapowi tego modelu.

Część pierwsza (Preparation) - „ANALIZA OBSZARU TEMATYCZNEGO”

poświęcona jest badaniu tematu i obszaru przedmiotowego. Badanie architektury SOA. Obecnie

istniejące technologie tworzenia aplikacji mobilnych. Studium aplikacji UBER, jej architektury i

zastosowanych technologii.

Część druga (Information system design) - „WYBÓR METOD ROZWOJU I

MODELOWANIE SYSTEMU” poświęcona jest projektowaniu systemu. Projekt aplikacji.

Wymagania funkcjonalne i niefunkcjonalne, projektowanie systemu z wykorzystaniem grafów

UML. Istniejące technologie wdrażania podobnych aplikacji. Języki programowania,

architektura, wzorce, protokoły itp. Ich badanie i dobór niezbędnych technologii do wykonania

aplikacji, a także uzasadnienie tego wyboru. Bezpieczeństwo aplikacji, uwierzytelnianie i

autoryzacja. Technologie zapewniające bezpieczeństwo: szyfrowanie, protokoły bezpieczeństwa,

ich opis.

Część trzecia (Creation) - „WDROŻENIE APLIKACJI I DOKUMENTACJI”

implementacja aplikacji, jej dokumentacja, fragmenty kodu, zdjęcia, diagramy, opisy

interfejsów.

Czwarta część (Operation and deployment) - „WDROŻENIE I WSPARCIE

SYSTEMU” wdrożenie systemu na serwerze, konfiguracja sprzętu, systemu operacyjnego, sieci.

Testowanie systemu gotowego.

1 ANALIZA OBSZARU TEMATYCZNEGO

Programowanie opiera się na dokładnie tej samej rygorystycznej nauce, co produkcja

aspiryny. Informatyka jest typowym przedstawicielem nauk formalnych, ma ten sam zestaw i

strukturę metod formalnych

oznacza to, że ucząc się nowych rzeczy, stosuje się wypróbowane i

przetestowane podejścia i naturalnie wykorzystuje się ich własny bagaż wiedzy akademickiej.

Podejście naukowe gwarantuje uzyskanie wysokiej jakości wyników, a znajomość i

zastosowanie podstawowych zasad projektowania oprogramowania ułatwi obsługę produktu.

1.1 ARCHITEKTURA ZORIENTOWANA NA USŁUGI

Krótka historia

Architektura zorientowana na usługi (SOA) została wynaleziona pod koniec 1980. Ma

swoje korzenie w pomysłach przedstawionych w CORBA, DCOM, DCE i innych dokumentach.

SOA można sprowadzić do kilku pomysłów, a architektura nie dyktuje, jak je wdrożyć:

 Zgodność aplikacji zorientowana na użytkownika.

 Usługi biznesowe wielokrotnego użytku.

 Niezależność technologiczna.

 Autonomia (niezależna ewolucja, skalowalność i możliwość wdrażania).

SOA - To zbiór zasad architektonicznych, które są niezależne od technologii i produktu,

podobnie jak polimorfizm czy hermetyzacja.

Wzorce SOA:

 Usługi internetowe.(Web services)

 Kolejka wiadomości.(MQ)

 Enterprise Service Bus (ESB).

 Mikrousługi. (Microservices)

1.1.1 USŁUGI INTERNETOWE (Web services)

Pod koniec lat 90. zaczęły pojawiać się usługi sieciowe.

 Był potrzebny niezawodny kanał komunikacji, dlatego:

 Protokół HTTP działa teraz domyślnie na porcie 80.

Artykuł na Wikipedii o metodach formalnych. Adres: https://en.wikipedia.org/wiki/Formal_methods [Data

uzyskania dostępu: 06.09.2020r.]

 Zaczęli używać języka niezależnego od platformy (takiego jak XML lub JSON)

do przesyłania wiadomości.

 Trzeba było zmniejszyć liczbę połączeń zdalnych, dlatego:

 Połączenia zdalne są jawne, więc teraz zawsze wiemy, kiedy trwa połączenie

zdalne.

 Zamiast wielu zdalnych wywołań obiektów, wykonujemy wywołania zdalnych

usług, ale znacznie rzadziej.

 Trzeba było uproszczenie specyfikacji komunikatów, więc:

 Pierwszy szkic SOAP pojawił się w 1998 roku, stał się rekomendacją W3C w

2003 roku, a następnie stał się standardem. SOAP zawiera niektóre pomysły

CORBA, takie jak warstwa do obsługi wiadomości i „dokument”, który definiuje

interfejs przy użyciu języka opisu usług sieci Web (

Web Services Description

Language, WSDL).

 Roy Fielding opisał REST w 2000 roku w swojej dysertacji «Architectural Styles

and the Design of Network-based Software Architectures».

Jego specyfikacja

okazała się znacznie prostsza niż SOAP, więc popularność REST szybko

wyprzedziła SOAP.

 Facebook opracował GraphQL w 2012 roku i udostępnił go publicznie w 2015

roku. Jest to język zapytań dla API, który pozwala klientowi ściśle określić, jakie

dane ma mu przesyłać serwer, ni mniej, ni więcej.

„Usługi internetowe można publikować, wyszukiwać i wykorzystywać w standardowy sposób,

niezależnie od technologii”. - Understanding Service-Oriented Architecture

Artykuł na Wikipedii o WSDL. Adres: https://ru.wikipedia.org/wiki/WSDL [Data uzyskania dostępu:

06.09.2020r.]

Style architektoniczne i projektowanie architektury oprogramowania opartego na sieci (DISSERTATION)

Oficjalna dokumentacja Microsoft „Understanding Service-Oriented Architecture”. Adres:

https://docs.microsoft.com/en-us/previous-versions/aa480021(v=msdn.10)?redirectedfrom=MSDN [Data uzyskania

dostępu: 06.09.2020r.]

Rysunek 2 (Web services schemat)

1.1.2 KOLEJKA WIADOMOŚCI (MQ)

Usługa kolejkowania wiadomości używa programowego brokera komunikatów

(RabbitMQ, Beanstalkd, Kafka itp.). Aby zaimplementować komunikację między aplikacjami,

możesz skonfigurować kolejkę na różne sposoby:

Zapytanie / odpowiedź

 Klient wysyła wiadomość do kolejki, zawierającą odniesienie do „konwersacji” -

(«conversation» reference). Wiadomość dociera do specjalnego węzła, który odpowiada

nadawcy inną wiadomością zawierającą łącze do tej samej konwersacji, dzięki czemu

odbiorca wie, do której konwersacji odnosi się wiadomość i może kontynuować. Jest to

bardzo przydatne w przypadku średnich i długich procesów biznesowych (łańcuchy

zdarzeń, sagi).

Publikuj / subskrybuj

 Według list

Kolejka przechowuje listy opublikowanych tematów i ich subskrybentów. Gdy kolejka

otrzyma wiadomość dotyczącą tematu, umieszcza ją na odpowiedniej liście. Wiadomość jest

dopasowywana do tematu według typu wiadomości lub przez predefiniowany zestaw

kryteriów, w tym treść wiadomości.

 Na podstawie transmisji

Gdy kolejka otrzyma wiadomość, rozgłasza ją do wszystkich węzłów nasłuchujących w

kolejce. Węzły muszą same filtrować dane i przetwarzać tylko interesujące wiadomości.

1.1.3 ENTERPRISE SERVICE BUS (ESB).

ESB powstało w czasie, gdy firmy miały oddzielne aplikacje. Na przykład jeden do pracy

z finansami, drugi do księgowości kadrowej, trzeci do zarządzania magazynem itd. I musiały być

jakoś ze sobą połączone, w jakiś sposób zintegrowane. Ale wszystkie te aplikacje powstały bez

uwzględnienia integracji, nie było standardowego języka do interakcji aplikacji (jak to jest

dzisiaj). Dlatego twórcy aplikacji udostępnili punkty końcowe do wysyłania i odbierania danych

w określonym formacie. Firmy klienckie zintegrowały aplikacje, ustanawiając między nimi

kanały komunikacji i konwertując komunikaty z jednego języka aplikacji na inny.

Kolejkowanie wiadomości może ułatwić komunikację aplikacjom, ale nie może

rozwiązać problemu różnych formatów językowych. Podjęto jednak próbę przekształcenia

kolejki komunikatów z prostego kanału komunikacyjnego w pośrednika, który dostarcza

komunikaty i konwertuje je na wymagane formaty / języki. ESB to kolejny krok w naturalnej

ewolucji prostej kolejki komunikatów.

Ta architektura wykorzystuje złożoną aplikację, zwykle zorientowaną na użytkownika,

która komunikuje się z usługami sieciowymi w celu wykonania pewnego rodzaju operacji. Z

kolei te usługi internetowe mogą również komunikować się z innymi usługami sieciowymi,

zwracając następnie niektóre dane do aplikacji. Ale ani aplikacja, ani usługi zaplecza nie wiedzą

o sobie nic, w tym o protokołach lokalizacji i komunikacji. Wiedzą tylko, z którą usługą chcą się

skontaktować i gdzie znajduje się autobus usługowy.

Klient (usługa lub aplikacja modułowa) wysyła żądanie do magistrali usług, która

konwertuje wiadomość do formatu obsługiwanego przez miejsce docelowe i tam przekierowuje

żądanie. Cała interakcja przebiega przez magistralę usług, więc jeśli spadnie, wszystkie inne

systemy upadną wraz z nią. Oznacza to, że ESB jest kluczowym pośrednikiem, bardzo złożonym

elementem systemu.

Główne obowiązki ESB:

 Śledzenie i trasowanie wiadomości między usługami.

 Konwersja komunikatów między komunikującymi się komponentami usług.

 Zarządzanie wdrażaniem i wersjonowaniem usług.

 Zarządzanie korzystaniem ze zbędnych usług.

 Zapewnienie standardowej obsługi zdarzeń, usług transformacji i mapowania danych,

usług kolejkowania wiadomości i zdarzeń, usług w zakresie bezpieczeństwa lub obsługi

wyjątków, konwersji protokołów i jakości komunikacji.

„Tworząc struktury komunikacyjne między różnymi procesami, widzieliśmy wiele

produktów i podejść, które wykorzystują bardzo zaawansowane mechanizmy komunikacji.

Dobrym przykładem są magistrale usług dla przedsiębiorstw, które często obejmują

wyrafinowany routing wiadomości, choreografię, transformację i egzekwowanie reguł

biznesowych”. - Martin Fowler

1.1.4 MIKROUSŁUGI

Architektura mikrousług jest oparta na koncepcjach SOA. Jego cel jest taki sam jak ESB:

stworzenie jednej, wspólnej aplikacji korporacyjnej z kilku wyspecjalizowanych aplikacji domen

biznesowych.

Główna różnica między mikrousługami a magistralą polega na tym, że ESB została

utworzona w kontekście integracji poszczególnych aplikacji w celu utworzenia jednej

rozproszonej aplikacji przedsiębiorstwa. A architektura mikrousług została stworzona w

kontekście szybko i ciągle zmieniających się firm, które (w większości) budują od podstaw

własne aplikacje chmurowe.

„Mikrousługi to małe, samodzielne usługi, które współpracują ze sobą i są zaprojektowane

wokół domeny biznesowej”.

- Sam Newman 2015

Główną wadą architektury ESB była bardzo złożona scentralizowana aplikacja, od której

zależały wszystkie inne aplikacje. I w architekturze mikrousług, ta aplikacja jest prawie

całkowicie usunięta.

Sam Newman, autor Building Microservices, przedstawia osiem zasad architektury

mikrousług. To: -

 Projektowanie usług wokół domen biznesowych

Artykuł “Microservices a definition of this new architectural term” Adres:

https://martinfowler.com/articles/microservices.html [Data uzyskania dostępu: 06.09.2020r.]

“Principles Of Microservices by Sam Newman” Adres:

https://www.youtube.com/watch?v=PFQnNFe27kU&feature=youtu.be&t=1m50s [Data uzyskania dostępu:

06.09.2020r.]

Może to zapewnić nam stabilne interfejsy, wysoce spójne i mało zależne moduły kodu oraz

dobrze zdefiniowane, nakreślone konteksty.

 Kultura automatyzacji

To da nam dużo większą swobodę, możemy wdrożyć więcej modułów.

 Ukrywanie szczegółów implementacji

Pozwala to usługom ewoluować niezależnie od siebie.

 Pełna decentralizacja

Zdecentralizuj podejmowanie decyzji i koncepcje architektoniczne, daj zespołom autonomię,

aby sama firma stała się złożonym systemem adaptacyjnym, który może szybko

dostosowywać się do zmian.

 Niezależne wdrożenie

Możesz wdrożyć nową wersję usługi, nie zmieniając niczego innego.

 Konsument pierwszy

Usługa powinna być łatwa w użyciu, łącznie z innymi usługami.

 Izolowanie awarii

Jeśli jedna usługa ulegnie awarii, inne nadal działają, co sprawia, że cały system jest odporny

na awarie.

 Łatwość monitorowania

W systemie jest wiele komponentów, więc trudno jest śledzić wszystko, co się w nim dzieje.

Potrzebujemy zaawansowanych narzędzi do monitorowania, aby zajrzeć do każdego zakątka

systemu i śledzić dowolny łańcuch zdarzeń ”.

„Społeczność woli inne podejście: inteligentne punkty końcowe i głupie kanały.

Mikrousługi, z których budowane są aplikacje, powinny jak najmniej zależeć od siebie

nawzajem, a jednocześnie być bardzo blisko spokrewnione - zawierają własną logikę

domeny i działają bardziej jak filtry z punktu widzenia klasycznego Uniksa: odbierają

żądania, stosują logikę i generują odpowiedzi. Są organizowane przy użyciu prostych

protokołów podobnych do REST, a nie skomplikowanych protokołów, takich jak BPEL lub

jakieś scentralizowane narzędzie.” - Martin Fowler

Książka “Building Microservices: Designing Fine-Grained Systems” - Newman, Sam

Artykuł “Microservices a definition of this new architectural term” Adres:

https://martinfowler.com/articles/microservices.html [Data uzyskania dostępu: 06.09.2020r.]

1.1.5 PORÓWNANIE ZALET I WAD WZORCÓW

Wzór

Zalety

Niedogodności

Usługi

internetowe

 Niezależność zestawu technologii,

wdrażanie i skalowalność usług.

 Standardowy, prosty i niezawodny

kanał komunikacyjny (przesyłanie

tekstu przez HTTP na porcie 80).

 Zoptymalizowana komunikacja.

 Stabilna specyfikacja wiadomości.

 Izolacja kontekstów domeny.

 Różne usługi internetowe są trudne do

zintegrowania ze względu na różnice

w językach wiadomości. Na przykład

dwie usługi internetowe

wykorzystujące różne reprezentacje

JSON tej samej koncepcji.

 Synchroniczne przesyłanie

wiadomości może przeciążać

systemy.

Kolejka

wiadomości

 Niezależność zestawu technologii,

wdrażanie i skalowalność usług.

 Standardowy, prosty i niezawodny

kanał komunikacyjny (przesyłanie

tekstu przez HTTP na porcie 80).

 Zoptymalizowana komunikacja.

 Stabilna specyfikacja wiadomości.

 Izolacja kontekstów domen.

 Łatwe podłączanie i odłączanie

usług.

 Asynchroniczne przesyłanie

wiadomości pomaga zarządzać

obciążeniem systemu.

 Różne usługi internetowe są trudne do

zintegrowania ze względu na różnice

w językach wiadomości. Na przykład

dwie usługi internetowe

wykorzystujące różne reprezentacje

JSON tej samej koncepcji.

Enterprise

Service Bus

(ESB)

 Niezależność zestawu technologii,

wdrażanie i skalowalność usług.

 Standardowy, prosty i niezawodny

kanał komunikacyjny (przesyłanie

tekstu przez HTTP na porcie 80).

 Zoptymalizowana komunikacja.

 Stabilna specyfikacja wiadomości.

 Izolacja kontekstów domen.

 Łatwe podłączanie i odłączanie usług.

 Asynchroniczne przesyłanie

wiadomości pomaga zarządzać

obciążeniem systemu.

 Pojedynczy punkt zarządzania do

obsługi wersji i konwersji.

 Szybkość połączenia jest niższa,

zwłaszcza między już

kompatybilnymi usługami.

 Scentralizowana logika:

 Pojedynczy punkt awarii,

który może spowodować

uszkodzenie systemów

komunikacyjnych całej firmy.

 Duża złożoność konfiguracji i

wsparcia.

 Z czasem możesz

przechowywać reguły

biznesowe w ESB.

 Autobus jest tak

skomplikowany, że do jego

obsługi potrzebny jest cały

zespół.

 Duża zależność usług od ESB.

Mikrousługi

 Niezależność zestawu technologii,

wdrażanie i skalowalność usług.

 Standardowy, prosty i niezawodny

kanał komunikacyjny (przesyłanie

tekstu przez HTTP na porcie 80).

 Zoptymalizowana komunikacja.

 Stabilna specyfikacja wiadomości.

 Izolacja kontekstów domen.

 Łatwe podłączanie i odłączanie

usług.

 Asynchroniczne przesyłanie

wiadomości pomaga zarządzać

obciążeniem systemu.

 Synchroniczna obsługa wiadomości

pomaga zarządzać wydajnością

systemu.

 Całkowicie niezależne i

autonomiczne usługi.

 Logika biznesowa jest

przechowywana tylko w usługach.

 Pozwala firmie przekształcić się w

złożony system adaptacyjny

składający się z kilku małych

autonomicznych części / zespołów,

które mogą szybko dostosowywać

się do zmian.

 Wysoka złożoność operacji:

 Jest dużo do zainwestowania w silną

kulturę DevOps.

 Korzystanie z wielu technologii i

bibliotek może wymknąć się spod

kontroli.

 Musisz ostrożnie zarządzać zmianami

w wejściowych / wyjściowych

interfejsach API, ponieważ wiele

aplikacji będzie używać tych

interfejsów.

 Korzystanie z ostatecznej spójności

może mieć poważne konsekwencje do

rozważenia podczas tworzenia

aplikacji, od zaplecza po UX.

 Testowanie staje się trudniejsze,

ponieważ zmiany w interfejsie mogą

wpływać na inne usługi w

nieprzewidywalny sposób.

1.2 ARCHITEKTURA NOWOCZESNEJ APLIKACJI MOBILNEJ

1.2.1 WPROWADZENIE

Rozwój wykorzystania wzorców programistycznych, przekazał książce „ Język wzorców

”Christophera Alexandra

, został wydany w 1977 roku, a wzór Modell-View-Controller w 1979

roku. Co na zawsze zmieniło rozwój oprogramowania.

Uzbrojony w wiedzę w zakresie oprogramowania, ja Badam i buduję typową architekturę

projektową, która jest wykorzystywana w 95% przypadków tworzenia nowoczesnych aplikacji

mobilnych i nie tylko.

W rzeczywistości, biorąc pod uwagę wymagania biznesowe i ramy czasowe rozwoju,

architektura aplikacji będzie się różnić w tym czy innym kierunku. Ale rdzeń i zasady zawsze

pozostaną takie same.

Rysunek 3 “Uproszczony schemat architektury nowoczesnej aplikacji”

Każdy system składa się z:

 Serwer;

 Udokumentowane API;

 Aplikacja kliencka i kilka typów urządzeń, które ta aplikacja musi obsługiwać: tablety,

telefony, zegarki itp.

 Układy tego, jak powinien wyglądać interfejs aplikacji;

 Lista niefunkcjonalnych wymagań, które musi spełniać system.

Pierwszym krokiem jest oddzielenie modelu od kontrolera i widoku, a tym samym oddzielenie

dwóch warstw aplikacji:

Książka „A Pattern Language, with Ishikawa and Silverstein (1977)”

 „Dół” dotyczy pojemności serwera,

 „Góra” patrzy na użytkownika.

W projektach aplikacji mobilnych są to warstwy kontrolera i widoku, więc rozwój każdego

modułu można podzielić między dwóch wyspecjalizowanych programistów. W ten sposób

natychmiast zrównoleglamy proces produkcji oprogramowania na dwa niezależne wątki.

Warstwy aplikacji komunikują się ze sobą poprzez obiekty modelu - klasy z

"przezroczystą" implementacją, składające się wyłącznie z akcesorów i mutatorów (metody get i

set; w rzeczywistości klasa będzie zawierała tylko właściwości). Takie klasy nie niosą ze sobą

żadnej logiki i są przeznaczone tylko do przechowywania i przenoszenia danych.

Istotą aplikacji jest obiekt, zwany inaczej „falownikiem zależności”. Stanie się też jedyną

klasą singletonową, a na niej będzie spoczywała jedyna odpowiedzialność - obsługa „wyższych”

warstw aplikacji.

Architektura aplikacji oparta jest na trzech głównych koncepcjach programistycznych:

 MVC;

 SOA;

 Architektura wielowarstwowa;

1.2.2 Z CZEGO SKŁADA SIĘ APLIKACJA SERWEROWA?

Zawsze jest jakaś baza danych (lub może być ich kilka) w formacie, który ma tabele.

Tabele składają się z rekordów. Każdy rekord zawiera zestaw pól przechowujących informacje.

Rekordy reprezentowane są w postaci obiektów modelowych z polami, dlatego w

aplikacji powstaje logiczne rozróżnienie według typów danych: jedna tabela - jeden typ danych.

Tabela „Użytkownicy” - typ danych „Użytkownik” (pola: ID, imię i nazwisko, adres). Tabela

„Wiadomości” - typ danych „Wiadomość” (pola: ID, Temat wiadomości, Treść wiadomości, Do,

Od, Data). Itp.

Dlatego cała logika obraca się wokół tabel i typów danych:

1. Obiekt modelu reprezentujący typ danych.

2. Serializacja obiektu modelu w celu zapisania go w tabeli.

3. Deserializacja obiektu modelu z bazy danych.

4. Transformacje obiektu modelowego: obliczanie niektórych statystyk,

sortowanie danych, wyszukiwanie danych itp.

5. Serializacja obiektu modelowego do transmisji w sieci.

6. Deserializacja obiektów modelu przechodzących przez sieć.

7. Usługa sieciowa, która pasuje do tego typu

dane.

To wszystko tworzy rodzaj stosu:

Rysunek 4 (Szczegółowy stos architektury aplikacji mobilnych)

1.2.3 Z CZEGO SKŁADA SIĘ APLIKACJA KLIENCKA?

Jak widać z Obrazek 4 architektura aplikacji klienckiej składa się z następujących

warstw:

 Network Layer;

 Network Items Layer;

 Service

 Local cache layer

 UI

Network Layer:

Zapewnia podstawowe algorytmy warstwy transportowej do przesyłania wiadomości z

klienta na serwer i odbierania z niego niezbędnych informacji. Z reguły wiadomości mogą być

przesyłane w formatach JSON i Multipart, chociaż w niektórych egzotycznych przypadkach

może to być strumień XML lub nawet strumień binarny. Ponadto każda wiadomość może mieć

nagłówek z informacjami o usłudze. Na przykład, można tam opisać czas przechowywania

żądań / odpowiedzi w pamięci podręcznej aplikacji.

Zawartość tej warstwy w dużej mierze zależy od tego, która technologia transportu jest

Ci najbliższa. Najbardziej poszukiwane są następujące technologie:

 Socket - podejście najniższego poziomu, które obejmuje żądania synchroniczne i

asynchroniczne oraz ma możliwość pracy zarówno z połączeniami TCP, jak i UDP.

Pozwala zrobić prawie wszystko, ale wymaga dużej koncentracji na zadaniu, a nie dużej

wytrwałości i dużej ilości kodu.

 WebSocket- podejście oparte na wykorzystaniu nagłówków przez TCP. Nie jest często

używany w programowaniu mobilnym, ponieważ nie jest wystarczająco elastyczny i

nadal wymaga dużej ilości kodu do jego obsługi.

 WCF- chyba najdoskonalszy mechanizm, ale z tak poważną wadą, która przewyższa

wszystkie zalety. Podejście wymyślone w głębi Microsoftu polega na stworzeniu klasy

proxy, która pośredniczy w relacji między logiką aplikacji a serwerem zdalnym. Działa

"z hukiem" w przypadku, gdy istnieje możliwość wygenerowania klasy proxy na

podstawie Schematy WSDL, co, delikatnie mówiąc, nie jest prostym zadaniem. Ponadto

tę klasę należy ponownie wygenerować po każdej aktualizacji interfejsu API serwera. A

jeśli dla programistów Visual Studio odbywa się to z łatwością Zephyr, dla programistów

aplikacji mobilnych jest to absolutnie niemożliwe.

 REST - niezawodny, sprawdzony w czasie kompromis wszystkich powyższych podejść

(https://en.wikipedia.org/wiki/Representational_state_transfer

). Oczywiście część

Artykuł na Wikipedii „Representational state transfer”. Adres:

https://en.wikipedia.org/wiki/Representational_state_transfer [Data uzyskania dostępu: 06.09.2020r.]

możliwości każdego z podejść trzeba zrezygnować, ale odbywa się to szybko i niezwykle

wydajnie przy minimalnym wysiłku.

Network Items layer:

To na tej warstwie spoczywa odpowiedzialność za mapowanie danych z formatu JSON

na deserializowaną reprezentację. Ta warstwa służy do opisywania klas wykonujących

transformację obiektową lub obiektowo-relacyjną. W sieci istnieje wiele bibliotek, które

wykonują transformacje obiektowo-relacyjne. Na przykład JSON

Model(https://github.com/jsonmodel/jsonmodel

)

Co to jest mapowanie?:

Załóżmy, że istnieją dwa zapytania zwracające dane o tej samej strukturze. Na przykład

użytkownicy aplikacji i znajomi użytkownicy, którzy mają takie pola, jak „ID” i „Nazwa

użytkownika”. Problem polega na tym, że programiści po stronie serwera w jednym żądaniu

mogą przekazywać pola: „id”, „nazwa użytkownika”, aw drugim „ident”,

„nazwa_użytkownika”. Ta rozbieżność może mieć wiele problemów:

1. Deserializowany obiekt danych w Objective-C nie może mieć pola „id” podczas

korzystania z CoreData

2. Zserializowane dane w polach „identyfikator” i „identyfikator” mogą zawierać ciąg lub

liczbę. Kiedy wyprowadzasz je na konsolę, nie będzie różnicy między tymi dwoma

liczbami, ale. ich kod skrótu będzie inny, a słownik inaczej będzie postrzegać wartość tych

pól.

3. Za różnice między nazwami pól odpowiada serwer, a twórcy serwera mogą po prostu nie

kontaktować się z nimi w celu zastąpienia ich nazw jednolitymi, wygodnymi

programistami klienckimi.

Nie ma uniwersalnego rozwiązania tych problemów, ale nie są one na tyle złożone, aby

wymagały znacznego wysiłku intelektualnego.

Local cache layer:

Dokumentacja techniczna „JSONModel - Magical Data Modeling Framework for JSON” Adres:

https://github.com/jsonmodel/jsonmodel [Data uzyskania dostępu: 06.09.2020r.]

Zadania tej warstwy obejmują:

1. Buforowanie obrazów pobranych z sieci.

2. Buforowanie żądań / odpowiedzi serwera.

3. Tworzenie kolejki żądań w przypadku braku sieci, a użytkownik jest offline.

4. Monitoruj dane w pamięci podręcznej i czyść dane, które wygasły.

5. Powiadomienie aplikacji o niemożności uzyskania informacji o danym obiekcie z sieci.

1.3 BADANIE STOSU TECHNOLOGII UBER

Wprowadzenie

Istnieje wiele podobieństw między moją aplikacją a Uberem. Używają tych samych

procesów, ale do różnych celów. Nie bez powodu wprowadzenie opisuje aplikację Petsy jako

Uber dla zwierząt. Dlatego bardzo ważne jest, aby przestudiować architekturę swojego starszego

brata, aby nie „wymyślać koła na nowo”. Jako źródło materiału do tej sekcji korzystam z

artykułów na oficjalnej stronie Ubera, gdzie szczegółowo opisana jest struktura wewnętrzna:

The Uber Engineering Tech Stack, Part I: The Foundation

The Uber Engineering Tech Stack, Part II: The Edge and Beyond

Stos technologii Uber

„ Zerwaliśmy oryginalna monolityczna architektura na wiele części, aby skalować się wraz ze

wzrostem. Przy setkach mikrousług, które są od siebie zależne, rysowanie diagramu działania

Ubera w tym momencie jest niezwykle skomplikowane i wszystko szybko się zmienia.” - The

Uber Engineering Tech Stack, Part I: The Foundation

„ Zamiast wieży ograniczeń wyobraź sobie drzewo. Patrząc na technologie w Uber, widzisz

wspólny stos (jak pień drzewa) z różnymi akcentami dla każdego zespołu lub biura

inżynieryjnego (jego oddziałów). Wszystko jest wykonane z tego samego materiału, ale narzędzia

i usługi rozwijają się inaczej w różnych obszarach.” - The Uber Engineering Tech Stack, Part I:

The Foundation

1.3.1 BOTTOM: PLATFORM

Infrastructure and Storage

„Nasza firma działa w modelu chmury hybrydowej, korzystając z kombinacji dostawców

chmury i wielu aktywnych centrów danych. Jeśli jedno centrum danych ulegnie awarii,

Artykuł na oficjalnej stronie Uber o stosie technologii ich systemu. https://eng.uber.com/tech-stack-part-one-

foundation/ [Data uzyskania dostępu: 06.09.2020r.]

Artykuł na oficjalnej stronie Uber o stosie technologii ich systemu. https://eng.uber.com/tech-stack-part-one-

foundation/ [Data uzyskania dostępu: 06.09.2020r.]

przejazdy (i wszystkie usługi związane z podróżami) przejdą do innego. ”- The Uber

Engineering Tech Stack, Part I: The Foundation

Terraform narzędziami do interaktywnego zarządzania infrastrukturą. W Uberze służy do

wygodnego zarządzania zasobami w chmurze.

Schemaless (wbudowany w MySQL), Riak i Cassandra. - zbiór technologii używanych do

przechowywania danych przez firmę.

Redis - używany do buforowania danych.

Twemproxy - docker do wdrażania pamięci podręcznej.

Pracownicy selera - jako rozproszona, asynchroniczna kolejka.

Logging

Kafka - rejestrator, używany jako klaster.

Hadoop - rozproszony system magazynowy, służący do przechowywania legowiska.

ELK - wszystkie dane są również przetwarzane w czasie rzeczywistym i trafiają do stosu ELK

(Elasticsearch, Logstash i Kibana)

App Provisioning

Kontenery Docker na Mesos - do uruchamiania mikrousług ze spójnymi konfiguracjami przy

użyciu Aurora

Ringpop - Spójny poziom skrótu, umożliwia współdziałanie i samonaprawianie na poziomie

aplikacji

Thrift и Protobuf -języki definicji interfejsu.

Szablon Pub-Sub - publikowanie aktualizacji dla subskrybentów.

Routing and Service Discovery

„ Nasza architektura zorientowana na usługi (SOA) sprawia, że wykrywanie usług i routing

mają kluczowe znaczenie dla sukcesu Ubera. Usługi muszą być w stanie komunikować się ze

sobą w naszej złożonej sieci.”- The Uber Engineering Tech Stack, Part I: The Foundation

Artykuł na oficjalnej stronie Uber o stosie technologii ich systemu. https://eng.uber.com/tech-stack-part-one-

foundation/ [Data uzyskania dostępu: 06.09.2020r.]

Artykuł na oficjalnej stronie Uber o stosie technologii ich systemu. https://eng.uber.com/tech-stack-part-one-

foundation/ [Data uzyskania dostępu: 06.09.2020r.]

HAProxy i Hyperbahn - do zarządzania routingiem mikrousług w sieci.

Ringpop - Spójny poziom skrótu, umożliwia współdziałanie i samonaprawianie na poziomie

aplikacji

Development and Deploy

Phabricator -obsługuje wiele operacji wewnętrznych, od analizy kodu po dokumentację i

automatyzację procesów

OpenGrok - do przechowywania i wyszukiwania kodu.

GitHub - opracowywać rozwiązania open source.

Jenkins - serwer do wdrażania i zarządzania zespołami.

Packer, Vagrant, Boto i Unison - tworzenie narzędzi do budowania, zarządzania i

programowania na maszynach wirtualnych

Clusto - do zarządzania rozwojem

Puppet - zarządza konfiguracją systemu.

Sphinx - do przechowywania i automatycznego generowania dokumentacji z repozytoriów

Języki

Python, Node.js, Go i Java - Na niższych poziomach.

„ Przyjęliśmy Go i Javę ze względu na wydajność. ”- The Uber Engineering Tech Stack, Part I:

The Foundation

C i C ++ - w razie potrzeby (na przykład w celu uzyskania wysokiej wydajności, szybkiego

kodu na poziomie systemu)

Testowanie

Hailstorm - przeprowadza testy integracyjne i symuluje obciążenie szczytowe poza godzinami

szczytu.

uDestroy - celowo wszystko rozkłada, abyśmy mogli lepiej radzić sobie z nieoczekiwanymi

awariami.

Artykuł na oficjalnej stronie Uber o stosie technologii ich systemu. https://eng.uber.com/tech-stack-part-one-

foundation/ [Data uzyskania dostępu: 06.09.2020r.]

Niezawodność

Nagios alerting -do monitorowania. Jest powiązany z systemem alertów dla powiadomień.

Obserwowalność

M3 na Go - zbieranie i przechowywanie danych ze wszystkich części Uber Engineering

(każdego serwera, usługi hosta i fragmentu kodu).

Grafana - aby wyświetlić wykresy.

Argos -Zastrzeżone narzędzie do wykrywania anomalii bada przychodzące metryki i porównuje

je z modelami predykcyjnymi opartymi na danych historycznych, aby określić, czy aktualne

dane mieszczą się w oczekiwanych granicach.

Rysunek 5 Obserwowalność UBER„”

Storm and Spark -przekształcić strumienie danych w przydatne wskaźniki biznesowe.

JavaScript, React, SVG, Canvas 2D i WebGL - do wizualizacji danych:

Rysunek 6 „Obserwowalność UBER”

Mapowanie

Gurafu - Najbardziej rozbudowana usługa w tej dziedzinie, która zapewnia zestaw narzędzi do

pracy z danymi z mapy drogowej oraz zwiększa wydajność i dokładność,

1.3.2 MIDDLE: MARKETPLACE

The Edge

„Interfejs API pierwszej linii dla naszych aplikacji mobilnych składa się z ponad 600

bezstanowych punktów końcowych, które łączą wiele usług. Przekierowuje żądania

przychodzące od naszych klientów mobilnych do innych interfejsów API lub usług. Wszystko

jest napisane w Node.js, z wyjątkiem krawędzi, gdzie nasz interfejs NGINX obsługuje

zakończenie SSL i pewne uwierzytelnianie. Interfejs użytkownika NGINX również pośredniczy

w naszym interfejsie API za pośrednictwem modułu równoważenia obciążenia HAProxy ”. - The

Uber Engineering Tech Stack, Part II: The Edge and Beyond

Logtron - aby wejść na dysk Kafki

Uber-statsd-client -moduł do generowania statystyk.

Wysoce dostępny, samoleczący, trwały

Ringpop- biblioteka do tworzenia współpracujących systemów rozproszonych. Zapewnia dostęp

do sekcji rozproszonych baz danych, takich jak DynamoDB czy Riak.

Ringpop i Sevnup, do współpracy i przenoszenia prawa własności do obiektu, gdy jeden z

węzłów ciągów mieszających ulegnie awarii lub gdy inny węzeł przejmuje obszar kluczy.

Redis -zapewnia buforowanie.

Szybkość i przepustowość

Cassandra and Go -głównym powodem jest szybkość. Cassandra dobrze się skaluje po wyjęciu

z pudełka, a Go bardzo szybko się kompiluje.

Optymalizacja i równoważenie

Python z Flask i uWSGI -stos technologii, na którym zapisywane jest równoważenie.

Widzenie i wykorzystywanie danych

JavaScript - dla aplikacji internetowych typu front-end.

React + Flux, D3 i Mapbox to biblioteki i frameworki stojące za tą grupą.

Node.js - jako zaplecze

Produkcyjne bazy danych Kafka i Uber - Do przesyłania strumieniowego danych

Hive Web Services, MapReduce, HDFS, Elasticsearch - do przechowywania danych.

1.3.3 TOP: WEB AND MOBILE

Web

Artykuł na oficjalnej stronie Uber o stosie technologii ich systemu. https://eng.uber.com/uber-tech-stack-part-two/

[Data uzyskania dostępu: 06.09.2020r.]

„Nasi inżynierowie internetowi i mobilni współdzielą wiele elementów z dolnymi częściami

stosu, ale wiele technologii jest unikalnych na samej górze. Inżynierowie z tych gałęzi tworzą

znaną Ci aplikację wraz z bibliotekami i strukturami dla wszystkich inżynierów internetowych i

mobilnych. Zespoły w tej części organizacji priorytetowo traktują wygodę użytkownika i

dostępność ”. - The Uber Engineering Tech Stack, Part II: The Edge and Beyond

Języki

Node.js - rdzeń stosu technologii internetowych.

Browserify - do budowania pakietów po stronie klienta.

Web Server

Skała macierzysta zbudowany na bardzo popularnym frameworku sieciowym Express.js.

Renderowanie, obsługa stanu i budowanie

React.js oraz standardowy Flux do renderowania aplikacji i obsługi stanu.

Core Tasks - budować projekty

Mobile

„Uber miał kiedyś organizację ściśle mobilną. Teraz mamy wielofunkcyjną organizację dla tego,

co nazywamy zespołami programowymi. Każdy interdyscyplinarny zespół programowy składa

się z członków od zaplecza po projektowanie i naukę o danych ”. - The Uber Engineering Tech

Stack, Part II: The Edge and Beyond

Języki

Objective C i Swift, Java.

Android

Gradle to system kompilacji.

OkHttp, Retrofit and Gson - dla sieci /

Dagger - framework do wstrzykiwania zależności

Timber - logging

Artykuł na oficjalnej stronie Uber o stosie technologii ich systemu. https://eng.uber.com/uber-tech-stack-part-two/

[Data uzyskania dostępu: 06.09.2020r.]

Artykuł na oficjalnej stronie Uber o stosie technologii ich systemu. https://eng.uber.com/uber-tech-stack-part-two/

[Data uzyskania dostępu: 06.09.2020r.]

iOS

Buck - utwórz repozytorium mono.

Masonry i SnapKit z funkcją Auto Layout pomagają w rozmieszczaniu komponentów.

KSCrash - Wykrywanie awarii.

OCMock służy do testowania.

Przechowywanie

LevelDB, backend używa standardowych Schemaless i MySQL, stopniowo przechodząc do all-

Schemaless.

2. WYBÓR METOD PROJEKTOWANIA I MODELOWANIE SYSTEMU

2.1 PROJEKT GRAFICZNY APLIKACJI

Projekt graficzny aplikacji został opracowany przy użyciu edytora Figma

...

W tworzeniu projektu graficznego uczestniczyły dwie osoby: ja (autor pracy) jako kierownik

oraz Bogdan Pavlov

jako konsultant w kwestii projektu aplikacji oraz współautor projektu

graficznego aplikacji.

Projekt graficzny obejmuje:

Główna paleta aplikacji i czcionka

Rysunek 7 „Paleta projektowania aplikacji.”

Główne strony aplikacji

Edytor online do tworzenia projektu aplikacji - https://www.figma.com/

Strona Facebook współautora projektu graficznego - https://www.facebook.com/Pavlobd

Rysunek 8

Rysunek 9

Rysunek 10

Rysunek 13

Rysunek 12

Rysunek 11

Rysunek 14

Rysunek 17

Rysunek 15

Rysunek 16

Rysunek 20

Rysunek 19

Rysunek 21

Rysunek 18

2.2 WYMOGI FUNKCJONALNE I NIEFUNKCYJNE

Funkcjonalne

Niefunkcjonalne

 Autoryzacja i uwierzytelnianie

 Autoryzacja na kilka sposobów

(Google, Facebook, POST)

Klient

 Dodawanie informacji o

zwierzaku.

 Możliwość dodania wielu

zwierzaków do systemu

 Możliwość dodania danych

osobowych o kliencie. (zdjęcie,

imię itp.)

 Utwórzenie zamówienie

 Kilka rodzajów usług (petSittin,

spacery)

 Wyszukowanie opiekunów według

lokalizacji.

 Filtr według seterów.

 Wybór setera, wybór zwierzaka i

stworzenie zamówienia.

 Czat do komunikacji z opiekunką.

 Możliwość prowadzenia wielu

czatów

 Możliwość przesyłania

multimediów na czacie (zdjęcia i

filmy zwierzaka)

 Lista wszystkich utworzonych

zamówień i informacje o nich

 Aplikacja musi być dostępna na

Androida

 Aplikacja musi być dostępna w

systemie IOS

 Aplikacja klienta i sittera to dwie

różne aplikacje.

 Rejestracja sittera jest możliwa

tylko ręcznie, dopiero po

sprawdzeniu przez pracownika.

 Wysoka autoryzacja

bezpieczeństwa

 Wysokie bezpieczeństwo

transmisji danych osobowych i

informacji w sieci.

 Czas rejestracji poniżej 5 sekund

 Czas autoryzacji poniżej 2 sekund

 Czas odpowiedzi serwera nie

dłuższy niż 5 sekund

 100 jednoczesnych użytkowników.

 Warunki korzystania

 Preloadery podczas ładowania

danych. Wskaźniki czuwania.

 Brak pustych ekranów (w

przypadku braku wyników

wyszukiwania lub tylko pustych

list)

 Możliwość opłacenia usługi

bezpośrednio poprzez aplikację

 Powiązanie karty bankowej.

Sitter

 Dodawanie danych osobowych

(zdjęcie, opis, certyfikaty, kursy)

 Ocena na podstawie opinii

klientów.

 Wyświetlanie statusu online.

 Powiadomienie o nadejściu

nowego zamówienia.

 Możliwość zmiany statusu

zamówienia (akceptacja, w trakcie,

zakończenie)

 Śledź lokalizacje opiekunów...

 Porozmawiaj z klientem

 Możliwość prowadzenia wielu

czatów

 Wymiana multimediów na czacie.

 Projektowanie (tworzenie projektu

aplikacji z wykorzystaniem zasad

(UX / UI).

 Przyjazny dla użytkownika

interfejs.

 Rozszerzalna architektura z

obsługą kodu.

2.2 PROJEKT ARCHITEKTURY SYSTEMU Z UŻYCIEM UML

Projektowanie architektury systemu jest ważnym etapem pomagającym uniknąć dużych

strat materiałowych i czasowych już w trakcie opracowywania aplikacji. Ponieważ w pełni

opisuje i tworzy architekturę aplikacji.

Uważa się, że opis architektury jest ważniejszym etapem niż samo wdrożenie aplikacji.

Podczas tworzenia projektu architekci systemu wykorzystują diagramy UML i opisy

tekstowe. Z oficjalnej witryny dokumentacji UML

Wziąłem tabelę z istniejącymi diagramami.

Te typy diagramów, które zostaną zaimplementowane w moim projekcie, są zaznaczone na

zielono:

Rysunek 22 “Diagram wszystkich dostępnych diagramów UML i które diagramy są używane w projekcie.”

Oficjalna dokumentacja UML - https://www.uml-diagrams.org/

2.2.1 PRZYPADEKI UŻYCIA:

Rysunek 23 „Diagram przypadków użycia”

Strumień wydarzeń

Sytuacja opisana za pomocą diagramu UML ma wysoki poziom abstrakcji i wyświetla

wszystkie przypadki użycia systemu.

Wszystkie opcje występują dopiero po autoryzacji klienta. Autoryzacja nie jest

wyświetlana na diagramie, ponieważ ma standardowy formularz. Ale tekst zawiera krótki opis

upoważnienia.

Główny przepływ zdarzeń opisuje tworzenie zamówienia na usługę, która jest główną

funkcjonalnością Aplikacje.

Struktura opisu dla każdego przypadku użycia:

1. Krótki opis każdego przypadku użycia

2. Warunki wstępne, które należy spełnić przed każdym przypadkiem użycia.

3. Główny bieg wydarzeń.

4. Alternatywne strumienie. (Co jeśli?)

5. Warunki końcowe.

Autoryzacja

1. Autoryzacja odbywa się za pomocą sieci społecznościowych lub poczty. Jeśli

użytkownik jest zalogowany za pośrednictwem poczty elektronicznej Należy

wprowadzić prawidłowy adres e-mail i hasło składające się z co najmniej 6 znaków.

2.1 W przypadku rejestracji, jeśli taki użytkownik nie istnieje w sieci, wówczas rejestruje się

i uzyskuje dostęp do swojego konta.

2.2 W przypadku autoryzacji po sprawdzeniu poprawności danych użytkownik uzyska

dostęp do systemu.

3.1 Jeżeli dane nie przeszły żadnej kontroli, użytkownik jest o tym informowany. I ponownie

próbuje wprowadzić poprawne dane.

Dodanie zwierzaka

1. Dodanie nowego zwierzaka pozwala na dodanie informacji o swoim pupilu, dzięki

czemu będziesz mógł z niego skorzystać podczas wyszukiwania odpowiedniej opiekunki

i tworzenia zamówienia. W aplikacji możesz jednocześnie dodawać kilka zwierzaków i

modyfikować istniejące.

2. Funkcjonalność dodawania zaimplementowana jest w zakładce „Moje zwierzaki”, gdzie

przechowywane są wszystkie zwierzaki dodane przez użytkownika. Po kliknięciu

przycisku „Dodaj zwierzaka” otwiera się zakładka z parametrami zwierzaka.

3. Po wprowadzeniu danych (rasa, płeć, imię, zdjęcie ...), po kliknięciu w przycisk

dodawania, na liście zwierzaków pojawia się nowy zwierzak.

Dodanie informacje o kliencie

Informacje o klientach nie są w tym przypadku obowiązkowe i opcjonalne.

Funkcjonalność dodawania i zmiany informacji znajduje się w zakładce „Profil” i zawiera takie

informacje jak: zdjęcie, imię, wiek, adres.

Pobieranie listy własnych zwierzaków (Zdobądź wszystkie zwierzęta)

Po kliknięciu pozycji menu "Moje zwierzęta" otwiera się zakładka ze wszystkimi

zwierzakami klient

Dodanie informacje o karcie bankowej

To ważna informacja, ponieważ po potwierdzeniu zamówienia przez zastępcę,

użytkownik jest obciążany kosztami korzystania z usług.

Funkcjonalność dodania karty bankowej znajduje się w profilu klienta.

Kontakt z opiekunami

1. Kontakt z ustawiającym odbywa się za pomocą zakładki czat. Gdzie możesz również

udostępniać zdjęcia i filmy. Użytkownik ma możliwość prowadzenia wielu czatów.

2. Czat z opiekunem staje się dostępny dopiero po utworzeniu zamówienia na usługę.

3. Użytkownik otwiera zakładkę z listą czatów, wybiera czat z wybranym opiekunem i otwiera

się zakładka czatu

Utworzenie zamówienie

1. Główną logiką aplikacji jest tworzenie zamówienia.

2. Przed utworzeniem zamówienia na liście musi znajdować się co najmniej jedno zwierzę oraz

podać informacje rozliczeniowe.

3. Sekwencja działań jest następująca:

 wybór punktu menu „Nowe zamówienie” ->

 strona wyboru rodzaju usługi (spacery lub opieka nad dziećmi) ->

 lista wszystkich opiekunów w najbliższej lokalizacji oraz możliwość filtrowania według

parametrów i lokalizacji. ->

 Wybór opiekuna ->

 stronę zamówienia, na której możesz dodać dodatkowe informacje i wybrać zwierzaka. -

 potwierdzenie zamówienia.

4. Jeżeli użytkownik nie podał informacji o zwierzaku lub nie posiada informacji

rozliczeniowych, nastąpi przekierowanie do stron umożliwiających dodanie tych informacji.

5. Po utworzeniu zamówienia pojawia się ono na liście wszystkich zamówień klientów, nowy

czat jest dodawany do listy rozmów klienta z wybranym opiekunem.

Zamówienie zamówienie

Po utworzeniu przez użytkownika zamówienia z wybranym opiekunem, opiekun na swojej

stronie otrzymuje powiadomienie o nowym zamówieniu i może zmienić jego status na swojej

liście wszystkich zamówień, a także uzyskuje dostęp do czatu z klientem.

Zmiana kolejność statusu

Po uzgodnieniu z klientem i realizacją zamówienia zastępca może zmienić status zamówienia na

(oczekujące na akceptację, przyjęte, w toku, niezapłacone, zrealizowane).

Dodanie informacje o kliencie.

Informacje o seterze są niezwykle ważne dla klienta. Dlatego podczas tworzenia strony

ustawiający musi podać jak najwięcej informacji o sobie, w tym (zdjęcie, wiek, umiejętności,

kursy i certyfikaty, opis). Ponadto w systemie zostaną zaimplementowane oceny i recenzje

opiekunów. A także ich poziom (początkujący, doświadczony, ekspert)

2.2.2 DIAGRAM DZIAŁANIA

Rysunek 24 „Diagram działania”

2.2.3 DIAGRAM SEKWENCJI

Rysunek 25 „Diagram sekwencji”

W tym przypadku opisujemy przypadek rejestracji, dodania nowego użytkownika do

bazy oraz dodania informacji o zwierzaku użytkownika.

Na schemacie wyświetlania wszystkich obiektów aplikacji, ja celowo nie opisuję innych

przypadków, ponieważ nie różnią się one zasadniczo od siebie.

2.3 OPIS STOSOWANYCH TECHNOLOGII.

 C #

 XAML

 .NET

 Xamarin

 Xamarin Eorms

 WCF

 Json

 FireBase Aut

 OAuth 2.0

 Entity Framwork

 Baza danych Firebase REALTIME

 SignalR

 AutoMapper

 REST

 HTTPS

 Refit

 SOA

 Newtonson.Json

 Wzory: Singlton, Wraper, MVVM

 SOLID

.NET Framework i C #

Były dwa główne powody wyboru .NET:

 Usługi WCF

 Xamarin

Xamarin

Aplikacja musi być obsługiwana na wielu urządzeniach (IOS, Android, WEB).

Xamarin pozwoli Ci stworzyć aplikację na kilku platformach jednocześnie, co oszczędza sporo

czasu. W przeciwnym razie musiałbyś nauczyć się różnych języków programowania dla różnych

platform

 IOS - Swift

 Android - Java.

Technologia Xamarin umożliwia stworzenie systemu dla wszystkich platform jednocześnie

przy użyciu języka C #, .NET i XAML (dla opisu wyglądu aplikacji).

Xamarin Forms -Technologia opisu wyglądu oparta jest na windows forms.

Umożliwia opisanie widoku aplikacji przy użyciu XAML. Następnie Xamarin kompiluje ten kod

do odpowiedniej dla każdej platformy (Java, IOS)

WCF framework

Jest to framework używany do wymiany danych między aplikacjami. W oparciu o ten

framework stworzyłem backend systemu.

Umożliwia wygodne tworzenie usługi, opisywanie interfejsów oraz automatyczne

przetwarzanie obiektów JSON.

Dane pomiędzy usługą a klientem przesyłane są protokołem REST w postaci obiektów

JSON.

REST

Użyłem protokołu REST, a nie SOA, ponieważ jest on bardziej uniwersalny, prostszy i

więcej oprogramowania zostało do niego stworzone. Protokół SOAP jest używany bardziej do

zdalnego wywoływania metod. Dlatego REST jest bardziej odpowiedni dla moich wymagań.

SOA

SOA jest niezbędna do zbudowania mojego systemu. Wraz z rozwojem projektu

potrzebuje ciągłych dodatków w postaci modułów, które zapewnia SOA. System ma również

kilka typów klientów (WEB, Android, IOS), każdy z nich ma wspólną logikę i potrzebuje

zsynchronizowanych odpowiednich informacji. Zmusza to do przeniesienia logiki aplikacji i

przechowywania danych do oddzielnej implementacji, dzieląc aplikacje na stronę serwera i

klienta.

Już sam podział systemu w ten sposób tworzy architekturę zorientowany na usługi... W

przyszłości planowane jest uzupełnienie projektu o różne moduły i przejście na architekturę

mikroserwerową.

Entity Framwork

Jest to Framework, który implementuje koncepcję ORM, która pozwala na zarządzanie

bazami danych jako obiektami i listami obiektów. Dzięki temu nie ma zasadniczej różnicy,

której bazy danych użyć do przechowywania danych. Interfejs sterowania będzie taki sam. W

moim przypadku używam MSSQLLocalDB w rozwoju. Jednak wydając aplikację do wydania,

wybiorę bardziej odpowiednią opcję, zmieniając tylko jedną linię w konfiguracji serwera.

Baza danych Firebase w czasie rzeczywistym

To jest implementacja bazy danych przez Google. Jego osobliwością jest to, że możesz

utworzyć subskrypcję, aby zmienić dowolne dane. To pozwala na wykorzystanie go do

implementacji czatu w aplikacji. (Jak tylko ktoś doda wiadomość do bazy danych, od razu

wszyscy subskrybenci otrzymają dodaną pozycję, w moim przypadku obiekt wiadomości)

SignalR

To technologia firmy Microsoft umożliwiająca „Real-time app” czyli umożliwia

wymianę danych między serwerem a aplikacją w czasie rzeczywistym. (Jeśli dane na serwerze

ulegną zmianie, to zmiany nastąpią w kliencie). Ponieważ Firebase Database Realtime ma

ograniczenie ruchu i przepustowości, a musisz zapłacić pieniądze, aby rozszerzyć jego

możliwości, będzie on używany tylko w trybie testowania aplikacji. W ostatecznej wersji usługa

implementacji wymiany komunikatów między użytkownikami zostanie zaimplementowana na

SignalR

AutoMapper

Аplikacja korzysta z wielu modułów, z których każdy ma własne dane do pracy.

(Platforma Entity używa model do pracy, kontroler REST używa obiektów DTO do opisu

protokołu interakcji i mapowania danych za pomocą formatu JSON.

Pomiędzy tymi różnymi obiektami używanymi do reprezentowania danych muszę utworzyć

konwertery, aby przekonwertować jeden obiekt na inny. Można to zrobić na dwa sposoby:

 Po zaimplementowaniu wzorca Mapper

 Skorzystaniem z gotowej biblioteki do mapowania - AutoMapper

Wzory: Singlton, Wraper

W mojej aplikacji wykorzystałem wzorzec Singlton do napisania klas implementacji i

dekompozycji usługi w oparciu o zasadę małego sprzężenia.

Wraper Kiedyś automatyczną implementację interfejsu protokołu komunikacyjnego

otoczyłem backendem, ponieważ nie byłem zadowolony z niskopoziomowej implementacji

remontu, owinąłem jego implementację własnymi metodami i uzupełniłem je.

REFIT

Jest to biblioteka używana po stronie klienta do automatycznego analizowania obiektów

JSON w zwykłe obiekty przy użyciu opisanego interfejsu przy użyciu obiektów DTO i adnotacji

pól tych klas. Ta biblioteka jest obsługiwana przez Newtonson.Json.

• HTTPS

Protokół HTTPS ma na celu zapewnienie bezpieczeństwa transmisji danych.

Szyfruje wszystkie treści wysyłane przez klienta i odszyfrowuje je po stronie serwera.

Certyfikaty szyfrujące znajdują się na oddzielnym serwerze i bez uzyskania do niego dostępu nie

można odszyfrować informacji przy użyciu nowoczesnych technologii.

Serwer i klient są skonfigurowani dla tego protokołu, a obecnie używam certyfikatu z

podpisem własnym. Po zwolnieniu będziesz musiał kupić prawdziwy certyfikat.

FireBase Aut

Do rejestracji, autoryzacji użytkowników i bezpieczeństwa informacji używam FireBase.

 Działa jako serwer JWS,

 obsługuje autoryzację u różnych dostawców,

 zapewnia wygodny interfejs zarządzania użytkownikami,

 umożliwia rejestrację po numerze telefonu poprzez wysłanie wiadomości SMS,

 automatycznie współpracuje z adresem e-mail użytkownika,

 zapewnia wygodne narzędzia do analizy użytkowników.

Rysunek 26” Dostępni dostawcy do autoryzacji”

Rysunek 27 ” Weryfikacja e-mail”

Rysunek 28 „Lista zarejestrowanych użytkowników”

OAuth 2.0

FireBase implementuje nowoczesny protokół autoryzacji OAuth2.0. Zapewnia to wysoki

poziom bezpieczeństwa autoryzacji użytkowników.

Uwierzytelnianie użytkownika na serwerze odbywa się dzięki JWT

Który użytkownik uzyskał podczas logowania do usługi autoryzacji Firebase.

Żadna aplikacja kliencka, żadna aplikacja serwerowa nie ma dostępu do autoryzacji

użytkownika.

SOLID

Architektura i rozwój systemu wykorzystuje zasady SOLID, co oznacza:

 S(pojedyncza odpowiedzialność) - każda klasa wykonuje jedną akcję

 O(otwarte-zamknięte) - klasa jest zamknięta do modyfikacji. Ale można go odziedziczyć

 L(Podstawienie Liskova) - każda implementacja abstrakcji musi być wymienna bez

łamania logiki programu.

 ja(segregacja interfejsów) - jeden interfejs - jedna funkcjonalność.

 re(inwersja zależności) - zależność tylko od interfejsów, a nie od implementacji

Oficjalna dokumentacja JWT https://jwt.io/

3. WDROŻENIE APLIKACJI I DOKUMENTACJI

Projekt składa się z dwóch głównych modułów:

 Część serwerowa.

 Strona klienta.

Moduły te wymieniają dane między sobą za pośrednictwem protokołu REST w sieci

wykorzystującej JSON.

Część serwerowa- zbudowana na frameworku WCF przy użyciu .NET. Jest to aplikacja,

która odbiera dane od klienta, przetwarza ją, zapisuje w bazie danych i wysyła wynik wykonania

do klienta, który zażądał danych. Dlatego strona serwera jest przeznaczona dla:

 Logiki biznesowej aplikacji

 Przechowywanie danych w bazie danych.

Część klienta - może być zbudowana w różnych technologiach ze względu na

wszechstronność protokołu REST:

 Web

 Android

 IOS

 Desktop

Ze względu na specyfikę logiki biznesowej istnieje dwa klienta aplikacji:

 Użytkownik - właściciel psa

 Sitter to usługa piesza i opieki nad zwierzętami.

W ramach pracy wdrożono jedynie aplikację kliencką dla właścicieli zwierząt domowych.

Dzięki wieloplatformowemu rozwojowi na XAMARIN aplikacja jest dostępna na dwie

platformy: Android, IOS.

Aby przetestować system, sittery są zamokowane po stronie serwera aplikacji:

Rysunek 29” Tworzenie (mock) siterera w systemie beckend”

W formie graficznej uproszczoną architekturę można przedstawić w następujący sposób:

Rysunek 30 „Architektura systemu”

3.1 APLIKACJA SERWEROWA

Opis interfejsu do interakcji z usługą:

Umowa serwisowa wygląda następująco. (To tylko część, ponieważ pełna umowa zajmuje 162

wiersze. Pełną wersję można wyświetlić w plikach źródłowych projektu).

Rysunek 31 „Część realizacji umowy serwisowej”

Wszystkie metody mają format żądania i odpowiedzi JSON, a styl treści wiadomości to

Wrapper, co znacznie komplikuje projekt kontraktu po stronie klienta, ale umożliwia

przekazanie kilku argumentów do metody.

Wszystkie metody implementują walidację tokenu JWT i sprawdzają zgodność między

żądanymi danymi a identyfikatorem użytkownika. Oznacza to, że użytkownik nie będzie mógł

uzyskać danych innego użytkownika.

Diagram zależności implementacji PetsyService

Rysunek 32 „diagram zależności w implementacji każdej metody w module service”

To jest diagram zależności w implementacji każdej metody w module service. Pokazuje,

że każda metoda uwierzytelnia użytkownika i wywołuje metody Repository - gdzie

zaimplementowana jest cała logika biznesowa i praca z bazą danych.

Opis metod zamówienia:

Podpis

Adres

metoda

Opis

User_x GetUserByToken ();

/ GetUserByToken

GET

Zwraca obiekt użytkownika, jeśli token

należy do użytkownika i został

zweryfikowany.

IEnumerable <Pet_x>

GetPetsByUserId (int UserId);

/ GetPetsByUserId

POST

Zwraca listę wszystkich zwierząt

domowych użytkownika

IEnumerable <Sitter_x>

GetAllSitters ()

/ GetAllSitters

GET

Zwraca wszystkich użytkowników w

systemie

IEnumerable <Order_x>

GetOrdersByUserId (int UserId);

/ GetOrdersByUserId

POST

Zwraca listę wszystkich zamówień

według identyfikatora użytkownika.

IEnumerable <Order_x>

GetOrdersBySitterId (int

SitterId);

/GetUrdersBySitterId

POST

Zwraca listę zamówień użytkowników

IEnumerable <Sitter_x>

GetSittersByLocation

(lokalizacja);

/GetSittersByLocation

POST

Zwraca listę użytkowników w określonej

odległości od lokalizacji

IEnumerable <Sitter_x>

GetSitterByFilter (filtr Filter_x);

/ GetSittersByFilter

POST

Zwraca listę opiekunów przefiltrowanych

według filtru

int CreateUser (User_x);

/ Stwórz użytkownika

POST

Tworzy użytkownika w systemie.

Zwraca stan operacji:

0 - OK.

int CreateSitter (Sitter_x sitter);

/CreateSitter

POST

Tworzy zastępcę w systemie.

Zwraca stan operacji:

0 - OK.

int CreateOrder (Order_x order);

/ CreateOrder

POST

Tworzy zamówienie w systemie.

Zwraca stan operacji:

0 - OK. Zamówienie - musi mieć obiekt

Sitter (Id) i User (Id) do utworzenia.

int CreatePet (Pet_x zwierzak);

/ CreatePet

POST

Tworzy zwierzaka w systemie,

Zwraca stan operacji:

0 - OK. Pet - musi mieć obiekt User (id)

do utworzenia.

int UpdateUser (użytkownik

User_x);

/ UpdateUser

POST

Aktualizuje użytkownika w systemie.

Zwraca stan operacji: 0 - OK

int UpdateSitter (Sitter_x sitter);

/ UpdateSitter

POST

Aktualizuje zastępcę w systemie. Zwraca

stan operacji: 0 - OK

int UpdatePet (Pet_x zwierzak);

/ UpdatePet

POST

Aktualizuje zwierzaka w systemie.

Zwraca stan operacji: 0 - OK, obiekt Pet

musi zawierać Identyfikator

użytkownika do aktualizacji...

int UpdateOrder (zamówienie_x);

/ UpdateOrder

POST

Aktualizuje kolejność w systemie.

Zwraca stan operacji: 0 - OK, obiekt Pet

musi zawierać UserId, SitterId do

aktualizacji...

string [] GetAllBreeds ();

/ GetAllBreeds

POST

Zwraca listę wszystkich ras w systemie

dostępnych podczas tworzenia zwierzaka

string IsWorking ();

/ check

GET

Sprawdzanie dostępności kontrolera.

Diagram zależności klas aplikacji serwera

Rysunek 33 „Diagram zależności klas aplikacji serwera”

Na diagramie można obserwować wszystkie moduły aplikacji, zależności między ich

obiektami, strukturę danych oraz ścieżkę życia danych.

Opis modułów:

 Service - moduł odpowiada za współpracę z serwisem aplikacji. To on odbiera i wysyła

dane z aplikacji klienckiej, zamienia je w obiekty i uwierzytelnia użytkownika za pomocą

FireBaseAut. Na tym etapie wszystkie prace wykonywane są na danych ExternalEntity.

 •ExternalEntity - określa umowę przeniesienia danych. Służy do analizowania obiektów

JSON i implementowania logiki w aplikacji, aż do poziomu ORM

 Repository -ten moduł implementuje całą logikę biznesową aplikacji. Wymienia dane

między Serwisem a modułem ORM.

 Mapers - wykonuje konwersję między obiektami zewnętrznymi - ORM.

 ORM.Model - obiekty używane do tworzenia tabel bazy danych (code first) i pracy z

bazą danych.

 ORM- moduł współpracujący z bazą danych, zbudowany w oparciu o Entity Framework.

Bezpieczeństwo

Jak opisałem w drugiej części, bezpieczeństwo aplikacji zapewnia standard OAuth 2.0,

JWT wszystko to jest realizowane przez FireBase Auth. Na schemacie

mozna zobaczyć,

jak działa JWT:

Artykuł o JWT, stąd wziąłem zdjęcie - https://habr.com/ru/post/340146/

Rysunek 34 „https://habr.com/ru/post/340146/”

Authentication Serwer to FireBaseAuth.

User - aplikacja kliencka.

Application serwer to strona serwera projektu.

Tak jest to realizowane po stronie serwera:

Rysunek 35 (Realizocja FireBaseAuth po stronie serwera)

Sprawdzanie tokena pod kątem dopasowania żądanego użytkownika:

var user = repository.GetUserByUID (UID);

Jeśli ((użytkownik == zero & user.Id! = order.Pet.UserId) && (order.Sitter == zero &

order.Sitter.UID! = UID))

rzucać Nowy Wyjątek („UidProvideUserDontMachWithAuthUid”);

Do połączenia z usługą autoryzacyjną służy plik JSON z kluczami dostępu do serwera:

Rysunek 36 „Tworzenie obiektu FirebaseApp”

3.2 APLIKACJA KLIENTA

Wprowadzenie, ogólna architektura:

W ramach pracy opracowałem stronę klienta aplikacji dla właściciela zwierzaka. Rozwój

odbywał się na podstawie Xamarin, który używa wzorca programowania MVVM. Do

autoryzacji i uwierzytelniania używam się FireBaseAuth, aby uzyskać dostęp do strony serwera,

samodzielnie utworzonego API opartego na bibliotece Refit. Aby zaimplementować czat między

użytkownikami - RealTimeDataBase z FireBase, który w przyszłości zostanie zastąpiony

własnym serwerem. Część wizualna, opisana przy użyciu XAML i Xamarin Forms, główna

logika aplikacji znajduje się w ViewModel każdej strony, z wywołaniem niezbędnych usług:

(Cache, BackEndApi, ChatApi, FireBaseAuth)

Projekt składa się z:

 Moduł wspólny (wspólny kod dla wszystkich modułów)

 Moduł Android

 Moduł IOS

Rysunek 37 „Moduły aplikacji klienta”

Ponieważ projekt jest duży, najbardziej pouczające jest użycie diagramu relacji klas i

pakietów. W tym przypadku używanie diagramu klas w ogóle nie ma sensu. Dlatego w mojej

pracy nie ma diagramów klas,

Architekturę i kompozycję wspólnego modułu można prześledzić na diagramie relacji

obiektów i pakietów aplikacji:

Rysunek 38 „Architekturę i kompozycję wspólnego modułu”

Wdrożenie API do komunikacji po stronie serwera

(APIClient)

Rysunek 39 „APIClient”

Interfejs interakcji opisano w IClientRestApiRefit i wygląda następująco (pełny plik zawiera

62 linie kodu):

Rysunek 40 „Interfejs interakcji Api clienta”

Ze względu na to, że

WebMessageBodyStyle.Wrapped jest używany po stronie serwera, wszystkie odpowiedzi i

żądania muszą być opakowane w opakowanie Respons / Request, a ich klucze muszą być

zdefiniowane z anotacjami:

Obiekty DTO (User, Pet, Sitter, Order, Filter ...) zawierają adnotacje nad każdym polem

do mapowania obiektów JSON:

Rysunek 43 „DTO object do mapowania obiektów JSON”

Rysunek 41 „Wraper Request Api”

Rysunek 42 „”Wraper Response Api

Następnie biblioteka Refit wykorzystuje wszystkie te dane do wygenerowania klasy

połączenia po stronie serwera aplikacji:

Rysunek 44 “Realizacja Refit”

Wdrażanie autoryzacji / uwierzytelniania

Implementację autoryzacji należy wykonać osobno dla każdego modułu, ponieważ jest

ona zależna od platformy. Dla tegoXamarin posiada interfejsy, które trzeba zaimplementować w

każdym module osobno, a moduł ogólny wykorzysta gotowy wynik implementacji interfejsu.

Tak wygląda implementacja interfejsu w module android:

Rysunek 45 „implementacja interfejsu autoryzacji w module android:”

A oto jak wykorzystać wynik wykonania metod interfejsu we wspólnym module, na przykładzie

użytkownika logującego się do systemu:

Rysunek 46 „Korzystanie z interfejsu autoryzacji w module wspólnym.”

Wdrożenie Cache

Implementacja Cache jest reprezentowana przez klasę, która zawiera obiekt bieżącego

użytkownika w systemie wraz ze wszystkimi jego danymi. Klasa implementuje wzorzec

Singlton, aby wszystkie klasy w systemie korzystały z rzeczywistych danych i zmieniały obiekt,

był istotny przez cały projekt:

Rysunek 47 „Wdrożenie Cache”

PRZYKŁAD NAPISANIA VIEW

View jest tworzone za pomocą XamarinForms i jest opisane w języku XAML.

Weźmy jako przykład stronę sittera, która składa się z:

 Strona, którą widzi użytkownik.

 Kod XAML opisujący stronę.

 Kod C # (ViewModel), który odpowiada za logikę i dane strony.

Rysunek 48 „Strona, którą widzi użytkownik.”

To jest interfejs, z którym współdziała użytkownik.

Rysunek 49 „Kod XAML opisujący stronę.”

Tak wygląda interfejs w projekcie.

Tutaj można obserwować wszystkie elementy znajdujące się w interfejsie, ich opisy oraz

parametry łączenia elementów z logiką strony, takie jak:

Clicked = "Back_Clicked"

x:Name= "PhotoOfSitterLayout"

x:Name= "RatingLable"

x:Name= "PriceLable

x:Name= "levelLable"

x:Name = "OpisLable

Cliked= "Contact_Clicked"

Rysunek 50 „Kod C # (ViewModel), który odpowiada za logikę i dane strony.”

Ten kod jest odpowiedzialny za wysyłanie danych do interfejsu użytkownika i

przetwarzanie jego działań.

Baza danych

Część usługowa aplikacji wykorzystuje EntityFramwork do tworzenia i zarządzania bazą

danych. Wykorzystuje technologie takie jak CodeFirst i ORM, co oznacza, że tworzenie,

konfiguracja i zarządzanie bazą danych i jej tabelami odbywa się automatycznie. Do testowania

aplikacji wykorzystałem bazę LocalDB. Tak wygląda model bazy danych:

Rysunek 51 „Diagram Bazy Danych”

Testowanie

Ze względu na szybkość rozwoju projektu zdecydowano się zbadać możliwość

porzucenia testów jednostkowych.

Wyniki rozwoju pokazały, że testy jednostkowe są konieczne nawet w przypadku jednej osoby

opracowującej tak mały projekt. Czas spędzony na tworzeniu testów jest wielokrotnie

rekompensowany czasem spędzonym na ciągłym wyłapywaniu błędów oraz wielokrotnym

uruchamianiu i budowaniu wszystkich modułów projektu.

Robiłem ręczne testy:

 Uruchomienie wielu projektów

 Debag

 Przechwytywanie ruchu pomiędzy klientem a serwerem przy pomocy programu

„Wireshark” (w tym celu zmieniłem protokół z HTTPS na HTTP)

 Mockowanie niezrealizowanych modułów

4 WDROŻENIE SYSTEMU I WSPARCIE

Do wdrożenia usługi aplikacji wymagany jest statyczny adres IP. Mam zdalny serwer

zbudowany na bazie starego netbooka „Acer aspire v5” i działający pod kontrolą systemu

operacyjnego Ubuntu. Serwer jest fizycznie zlokalizowany na Ukrainie i ma dedykowany adres

IP. Komunikuję się z serwerem za pomocą protokołów zdalnego sterowania XRDP (port 3389) i

SSH (port 22).

Adres serwera: 134.249.160.114.

Serwer wygląda następująco:

Rysunek 52 „Netbook na podstawie którego budowany jest serwer.”

Ponieważ netbook znajduje się w podsieci domowej, w NAT, porty muszą być

zarezerwowane na routerze dla tego komputera:

Rysunek 53” Ustawienia routera dla serwera Ubuntu”

Oznacza to, że wszystkie żądania przychodzące do routera na portach 1 - 5000, z

wyjątkiem 80, 443, będą kierowane do serwera o adresie w podsieci 192.168.0.100.

4.1 PROBLEM Z HOSTOWANIEM USŁUGI WCF REST W SYSTEMIE

UBUNTU

Planowałem stworzyć wykonywalny host dla usługi WCF z rozszerzeniem exe i

uruchomić go w systemie operacyjnym Ubuntu. Z .Net Core dla Ubuntu, Wine lub Mono.

Jednak wykonywalny host można napisać tylko przy użyciu technologii .NET Framework. Który

jest obsługiwany tylko w systemach operacyjnych Windows.

Po dwóch dniach nieudanych prób uruchomienia usługi WCF na Ubuntu przy użyciu

wszystkich możliwych metod doszedłem do wniosku, że nie da się uruchomić usługi WCF w

systemach Linux.

4.2 ROZWIĄZYWANIE PROBLEMÓW

1. Instalacja maszyny wirtualnej „Virtual BOX” na Ubuntu.

2. Instalowanie systemu Windows Server 2019.

3. Aktywacja usługi IIS.

4. Aktywacja .NET Framework i wszystkich komponentów do pracy z WCF.

5. Instalowanie serwera Microsoft sql

6. Utworzenie certyfikatu SSl w usługach IIS

7. Ładowanie usługi petsy na serwerze Windows, tworzenie aplikacji w IIS,

konfiguracja dwóch adresów HTTP i HTTPS, łączące certyfikat i określające

ścieżkę dostępu do usługi.

8. Uruchomienie aplikacji w IIS.

Następnie należy skonfigurować sieć tak, aby usługa była dostępna z Internetu. Aby to

zrobić, w ustawieniach sieciowych maszyny wirtualnej Virtual BOX wybierz typ sieci: „Most

sieciowy” co oznacza, że w sieci pojawi się inny host.

W moim przypadku jest to host o adresie 192.168.0.101 i poprzez ustawienia routera

mogę zarezerwować porty Http i Https (80, 443) dla IIS.:

Rysunek 54 „Ustawienia routera dla Windows Server”

Rysunek 55 „Ustawienia IIS”

Po uruchomieniu usługi jej działanie można sprawdzić z dowolnej przeglądarki na

świecie wpisując w linię przeglądarki:http://134.249.160.114/Service/PetsyService.svc/check

Odpowiedź:

Rysunek 56 „Testowanie serwera”

Testowanie dostępu do usługi przez Internet w aplikacji:

Jak widać na zdjęciach, aplikacja uzyskuje dostęp do usługi z Internetu za pośrednictwem

połączenia mobilnego.

CZĘŚĆ 5. WNIOSEK

W trakcie pracy stworzyłem i wdrożyłem pełnoprawny projekt informacyjny

wykorzystujący najnowocześniejsze technologie do wytwarzania oprogramowania. Tym samym

udowodniłem możliwość tworzenia komercyjnego oprogramowania przez jedną osobę.

Projekt realizuje wszystkie podstawowe wymagania dotyczące funkcjonalności i

bezpieczeństwa, a jego architektura i proces rozwoju są zgodne ze standardami nowoczesnego

wytwarzania oprogramowania.

Rozwój pełnoprawnego projektu na stosie używanej technologii był dla mnie absolutną

nowością. Po raz pierwszy trafiłem na wiele momentów w rozwoju.

Rezultatem pracy jest aplikacja demonstracyjna do wyprowadzania psów na

wyprowadzanie, z zaimplementowaniem podstawowej funkcjonalności. Interfejs aplikacji jest

dostępny na IOS i Android, użytkownicy mogą uzyskiwać dostęp do danych z dowolnego

miejsca na świecie. Back-end aplikacji znajduje się na serwerze, a dostęp do niego można

również uzyskać korzystając z danych opisanych w pracy, aby upewnić się, że działa.

Architektura aplikacji jest zbudowana w oparciu o zasady współczesnej architektury aplikacji i

realizuje zasadę niskiego sprzężenia, co pozwala na dalszy rozwój aplikacji, dodawanie nowych

funkcjonalności oraz zmianę istniejących bez wpływu na ogólną logikę aplikacji.

Czas poświęcony na rozwój tego systemu to około 150-200 godzin.

5.1 DALSZY ROZWÓJ PROJEKTU

Projekt jest rozwijany z myślą o stworzeniu startupu.

W tej chwili zaimplementowano ogólną architekturę systemu i podstawową logikę, aby

mieć wyobrażenie o aplikacji. W ujęciu procentowym jest to 5% całej pracy potrzebnej do

stworzenia aplikacji.

Dalej:

• Zaimplementowana zostanie cała funkcjonalność aplikacji,

• Hosting aplikacji zostanie zmieniony na bardziej produktywny.

• Zostanie dodane wyszukiwanie opiekunów według lokalizacji.

• Zostanie utworzony oddzielny serwer do obsługi czatów użytkowników,

wysyłania zdjęć, filmów i komunikacji wideo.

• Płatność za usługi za pośrednictwem aplikacji zostanie wdrożona

• Prawne aspekty projektu zostaną zbadane i wdrożone

Bezpośrednim celem projektu jest stworzenie działającego prototypu aplikacji i

poszukiwanie inwestorów.

LISTA SKRÓTÓW

SOA - Service Oriented Architecture

MQ - Messages Queue

CORBA - Common Object Request Broker Architecture

DCOM - Distributed COM

DCE - Data Communications Equipment

XML - eXtensible Markup Language

JSON - JavaScript Object Notation

HTTP - HyperText Transfer Protocol

SOAP - Simple Object Access Protocol

API - Application Programming Interface

ESB - Enterprise Service Bus

BPEL - Business Process Execution Language

MVC - Model-View-Controller

REST - Representational State Transfer

XAML - eXtensible Application Markup Language

WCF - Windows Communication Foundation

ORM - Object-Relational Mapping

JWT - JSON Web Token

IIS - Internet Information Services

SSl - Secure Sockets Layer

BIBLIOGRAFIA

1. Artykuł o badaniu odsetka Polaków, którzy mają zwierzęta domowe. Adres:

www.rmf24.pl/fakty/polska/news-sondaz-ponad-polowa-polakow-ma-w-domu-jakies-

zwierze,nId,2396840 [Data uzyskania dostępu: 06.09.2020r.]

2. Artykuł na Wikipedii o metodach formalnych. Adres:

https://en.wikipedia.org/wiki/Formal_methods [Data uzyskania dostępu: 06.09.2020r.]

3. Artykuł na Wikipedii o WSDL. Adres: https://ru.wikipedia.org/wiki/WSDL [Data

uzyskania dostępu: 06.09.2020r.]

4. Style architektoniczne i projektowanie architektury oprogramowania opartego na sieci

(DISSERTATION)

5. Oficjalna dokumentacja Microsoft „Understanding Service-Oriented Architecture”.

Adres: https://docs.microsoft.com/en-us/previous-

versions/aa480021(v=msdn.10)?redirectedfrom=MSDN [Data uzyskania dostępu: 06.09.2020r.]

6. Artykuł “Microservices a definition of this new architectural term” Adres:

https://martinfowler.com/articles/microservices.html [Data uzyskania dostępu: 06.09.2020r.]

7. “Principles of Microservices by Sam Newman” Adres:

https://www.youtube.com/watch?v=PFQnNFe27kU&feature=youtu.be&t=1m50s [Data

uzyskania dostępu: 06.09.2020r.]

8. Książka “Building Microservices: Designing Fine-Grained Systems” - Newman, Sam

9. Artykuł “Microservices a definition of this new architectural term” Adres:

https://martinfowler.com/articles/microservices.html [Data uzyskania dostępu: 06.09.2020r.]

10. Książka „A Pattern Language, with Ishikawa and Silverstein (1977)”

11. Artykuł na Wikipedii „Representational state transfer”. Adres:

https://en.wikipedia.org/wiki/Representational_state_transfer [Data uzyskania dostępu:

06.09.2020r.]

12. Dokumentacja techniczna „JSONModel - Magical Data Modeling Framework for JSON”

Adres: https://github.com/jsonmodel/jsonmodel [Data uzyskania dostępu: 06.09.2020r.]

13. – 17. Artykuł na oficjalnej stronie Uber o stosie technologii ich systemu.

https://eng.uber.com/tech-stack-part-one-foundation/ [Data uzyskania dostępu: 06.09.2020r.]

18. – 20. Artykuł na oficjalnej stronie Uber o stosie technologii ich systemu.

https://eng.uber.com/uber-tech-stack-part-two/ [Data uzyskania dostępu: 06.09.2020r.]

21 Edytor online do tworzenia projektu aplikacji - https://www.figma.com/

22 Strona Facebook współautora projektu graficznego - https://www.facebook.com/Pavlobd

23 Oficjalna dokumentacja UML - https://www.uml-diagrams.org/

24 Oficjalna dokumentacja JWT - https://jwt.io/

78 
 
LISTA IUSTRACJI 
Rysunek 1 „Waterfall model” ......................................................................................................... 6 
Rysunek 2 (Web services schemat) ............................................................................................... 10 
Rysunek 3 “Uproszczony schemat architektury nowoczesnej aplikacji” ...................................... 16 
Rysunek 4 (Szczegółowy stos architektury aplikacji mobilnych) ................................................. 18 
Rysunek 5 Obserwowalność UBER„” .......................................................................................... 25 
Rysunek 6 „Obserwowalność UBER” .......................................................................................... 26 
Rysunek 7 „Paleta projektowania aplikacji.” ................................................................................ 30 
Rysunek 8 – 21 „Projekt graficzny aplikacji” ............................................................................... 31 
Rysunek 22 “Diagram wszystkich dostępnych diagramów UML i które diagramy są używane w 
projekcie.”...................................................................................................................................... 36 
Rysunek 23 „Diagram przypadków użycia” ................................................................................. 37 
Rysunek 24 „Diagram działania” .................................................................................................. 41 
Rysunek 25 „Diagram sekwencji” ................................................................................................. 42 
Rysunek 26” Dostępni dostawcy do autoryzacji” ......................................................................... 47 
Rysunek 27 ” Weryfikacja e-mail” ................................................................................................ 47 
Rysunek 28 „Lista zarejestrowanych użytkowników” .................................................................. 48 
Rysunek 29” Tworzenie (mock) siterera w systemie beckend” .................................................... 50 
Rysunek 30 „Architektura systemu” ............................................................................................. 50 
Rysunek 31 „Część realizacji umowy serwisowej” ...................................................................... 51 
Rysunek 32 „diagram zależności w implementacji każdej metody w module service” ............... 52 
Rysunek 33 „Diagram zależności klas aplikacji serwera” ............................................................ 54 
Rysunek 34 „https://habr.com/ru/post/340146/” ........................................................................... 56 
Rysunek 35 (Realizocja FireBaseAuth po stronie serwera) .......................................................... 56 
Rysunek 36 „Tworzenie obiektu FirebaseApp” ............................................................................ 57 
Rysunek 37 „Moduły aplikacji klienta” ........................................................................................ 58 
Rysunek 38 „Architekturę i kompozycję wspólnego modułu” ..................................................... 59 
Rysunek 39 „APIClient” ............................................................................................................... 60 
Rysunek 40 „Interfejs interakcji Api clienta”................................................................................ 60 
Rysunek 41 „Wraper Request Api” ............................................................................................... 61 
Rysunek 42 „”Wraper Response Api ............................................................................................ 61 
Rysunek 43 „DTO object do mapowania obiektów JSON” .......................................................... 61 
Rysunek 44 “Realizacja Refit” ...................................................................................................... 62 
Rysunek 45 „implementacja interfejsu autoryzacji w module android:” ...................................... 62 

79 
 
Rysunek 46 „Korzystanie z interfejsu autoryzacji w module wspólnym.” ................................... 63 
Rysunek 47 „Wdrożenie Cache” ................................................................................................... 63 
Rysunek 48 „Strona, którą widzi użytkownik.” ............................................................................ 64 
Rysunek 49 „Kod XAML opisujący stronę.” ................................................................................ 65 
Rysunek 50 „Kod C # (ViewModel), który odpowiada za logikę i dane strony.” ........................ 66 
Rysunek 51 „Diagram Bazy Danych” ........................................................................................... 67 
Rysunek 52 „Netbook na podstawie którego budowany jest serwer.” .......................................... 68 
Rysunek 53” Ustawienia routera dla serwera Ubuntu” ................................................................. 68 
Rysunek 54 „Ustawienia routera dla Windows Server” ................................................................ 70 
Rysunek 55 „Ustawienia IIS” ........................................................................................................ 70 
Rysunek 56 „Testowanie serwera” ................................................................................................ 71 
   

DODATEK