PROJEKTOWANIE APLIKACJI INTERNETOWYCH

Transkrypt

1 PROJEKTOWANIE APLIKACJI INTERNETOWYCH (WFAIS.IF-N016) dr inż. Marcin Zieliński Wykład dla kierunku: Informatyka Stosowana I rok, II stopień Rok akademicki: 2016/ semestr letni WYKŁAD 2

2 Przypomnienie Struktura logiczna aplikacji Model aplikacji Metodologia projektowania Przegląd obecnych technologii

3 Aplikacja internetowa Czym jest aplikacja internetowa (webowa) i czym się różni od strony internetowej? Pojęcia te są bardzo ogólne i nie są jednoznaczne!!! Strona internetowa (Web page) Kolekcja logicznie połączonych ze sobą zasobów (najczęściej dokumentów napisanych w języku HTML oraz multimediów), znajdujących się na jednym serwerze (w konkretnej kartotece) obsługującym żądania za pomocą protokołu HTTP. Po stronie hosta użytkownika, strona internetowa jest otwierana i wyświetlana za pomocą przeglądarki internetowej. Aplikacja internetowa (Web application) Program komputerowy, który pracuje na serwerze i komunikuje się poprzez sieć komputerową internet z komputerem użytkownika wykorzystując przeglądarkę internetową która jest interaktywnym klientem aplikacji internetowej. Aplikacje mogą działać za pomocą mechanizmów np. CGI, JSP, ASP.NET, Node.js lub języków np. PHP, Java, C#, JavaScript. Mechanizm prezentacji danych w przeglądarce określa się czasem mianem cienkiego klienta (ang. thin client).

4 Aplikacja internetowa Zatem jak rozróżnić co jest stroną, a co aplikacją internetową? Najlepiej rozróżnić przez kryterium technologiczne: Strona internetowa (Statyczna strona WWW) - strona taka zawiera w kodzie dane, które są wyświetlane w przeglądarce internetowej. Zawartość strony nie zmienia się pod wpływem interakcji z użytkownikiem, zawsze wyświetlane są te same treści. Każda zmiana danych (treści strony) wymaga ingerencji programisty w kod strony. Użytkownik nie posiadający wiedzy na temat struktury strony oraz języka HTML nie będzie w stanie zmienić zawartości strony. Aplikacja internetowa (Dynamiczna strona WWW) - strona dynamiczna jest generowana przez serwer HTTP pod wpływem żądań przychodzących od klienta na podstawie przesłanych parametrów i zmiennych. Strony takie dostosowują swoją zawartość w zależności od działań użytkownika w przeglądarce. W takim wypadku zmiany stanu strony mogą być wykonywane po stronie użytkownika dzięku wykorzystanie języków skryptowych np. JavaScript lub po stronie serwera wykorzystując do tego celu języki takie jak PHP, Perl, Python. W nowoczesnych aplikacjach internetowych wykorzystywane są obie metody. Dodatkowo najczęściej dane (czyli zawartość strony) jest przechowywana w bazach danych (np. SQL), z których są pobierane w zależności od wywoływanych przez użytkownika żądań.

5 Aplikacja Przykłady aplikacji: Monolityczna terminalowa Monolityczna okienkowa Monolityczna okienkowa Internetowa

6 Aplikacja internetowa Przykłady stron i aplikacji internetowych:

7 Model aplikacji (MA) APLIKACJA Użytkownik Warstwa prezentacji Widok danych Serwisy Logika biznesowa Warstwa biznesowa Logika danych Warstwa danych Baza danych

8 Projektowanie PROJEKTOWANIE I TWORZENIE APLIKACJI (INTERNETOWYCH) 1. Identyfikacja potrzeby biznesowej klienta (identyfikacja problemu/zagadnienia). 2. Określenie szczegółowych funkcjonalności produktu końcowego. Określenie wymagań technologicznych i procesowych. Ocena ryzyka projektowego Etapowa implementacja funkcjonalności i ich modyfikacja. 5. Testowanie tworzonego kodu. 6. Wdrożenie produktu. 7. Wsparcie po wdrożeniowe.

9 Przegląd technologii FRONT-END - pojęciowo odnosi się w technologiach internetowych do kodu wykonywanego po stronie użytkownika. W ogólności do tej kategorii można zaliczyć HTML, CSS oraz JavaScript. BACK-END - pojęciowo odnosi się w technologiach internetowych do kodu wykonywanego po stronie serwera. W ogólności do tej kategorii można zaliczyć PHP, Perl, CGI, Ruby, Java, C#, itp.

10 Przegląd technologii: Front-End Podstawowe technologie: HTML 5 CSS 3 (z Mediaqueries) JavaScript (ECMA6) Biblioteka jquery wraz dodatkowym pakietem jqueryui (User-Interface) Środowisko wprowadzające MVC i podejście Single Page Application (SPA) Biblioteka do tworzenia UI i zarządzania VDOM

11 Przegląd technologii: Back-End Podstawowa technologia serwerowa PHP oraz zintegrowane środowiska programistyczne: Symfony 2 Zend Framework 2 Środowisko Node.js do uruchamiania aplikacji na serwerze napisanych w języku JavaScript. Środowisko Ruby on Rails do tworzenia aplikacji klient-serwer w języku Ruby. Rozbudowane środowisko tworzenia aplikacji w języku C#. Rozbudowane środowisko tworzenia aplikacji w języku Java.

12 Podstawowa architektura: klient-serwer Klient (Przeglądarka internetowa) Serwer aplikacji oraz danych Podstawowe składniki niezbędne do komunikacji: - klient (przeglądarka www) - serwer (serwer www) - protokół (np. HTTP) Przykład: Kliknięcie na hiperpołącze na stronie powoduje, że komputer-klient (host) wysyła do serwera żądanie. Serwer po otrzymaniu żądania i po przeszukaniu swoich zasobów, wysyła do klienta jeśli to możliwe stosowną zasób np. dokument HTML, a następnie na jego podstawie przeglądarka renderuje widok strony internetowej.

13 Podstawowa architektura: klient-serwer Klient (Przeglądarka internetowa) Inicjowanie połączenia HTTP Pobieranie interfejsu użytkownika Prezentacja interfejsu użytkownika Interakcja z użytkownikiem Buforowanie odpowiedzi Kryptografia Serwer aplikacji oraz danych Protokół HTTP Oparty na TCP Komendy tekstowe Transmisja 8-bitowa Bezstanowy, bezsesyjny Obsługa żądań HTTP Rejestracja żądań Uwierzytelnianie i kontrola dostępu Kryptografia Wybór wersji językowej wysyłanych plików

14 Podstawowa architektura: klient-serwer Klasyczny model komunikacji synchronicznej HTTP: Serwer Żądanie HTTP Komunikacja bazodanowa Dane Klient Odpowiedź HTTP: HTML, CSS etc Jest to model synchronicznej komunikacji HTTP, gdzie klient wysyła żądanie, serwer je odbiera następnie przetwarza (np. komunikuje się z bazą danych) i na końcu generuje odpowiedź. W sytuacji takiej klient musi czekać z kolejnym żądaniem do momentu kiedy nie dostanie odpowiedzi od serwera. W modelu synchronicznym mamy bardzo mały poziom aktywności oraz interaktywności strony, strona musi być przeładowana (pobrana) po każdym żądaniu klienta, jeżeli strony są złożone to proces ten jest długi.

15 Podstawowa architektura: klient-serwer Klasyczny model komunikacji synchronicznej HTTP:

16 Podstawowa architektura: klient-serwer Model komunikacji asynchronicznej HTTP: Serwer Żądanie HTTP JavaScript Klient Dane AJAX HTML, CSS Komunikacja bazodanowa Odpowiedź HTTP: XML Jest to model asynchronicznej komunikacji HTTP, gdzie klient (przeglądarka) nie czeka na przyjście odpowiedzi na żądanie serwera, a wykonuje dalsze żądania. Pośredniczy w tym wbudowany w przeglądarkę mechanizm silnika AJAX. W takim modelu nie ma konieczności przeładowania strony przy każdej operacji klienta, wystarczy, że zostaną odczytane brakujące dane, a dzięki odpowiednim narzędziom zmodyfikowana zostanie zawartość strony.

17 Podstawowa architektura: klient-serwer Model komunikacji asynchronicznej HTTP:

18 Podstawowa architektura: klient-serwer Architektura monolityczna: Użytkownik Interfejs użytkownika Aplikacja Dane Architektura klasyczna klient-serwer: Użytkownik Interfejs użytkownika Aplikacja Sieć Dane Architektura klient-serwer w modelu WWW: Użytkownik Interfejs użytkownika Sieć Aplikacja Sieć Dane

19 Podstawowa architektura: klient-serwer Architektura klient-serwer w modelu WWW: Serwer HTTP Użytkownik Serwer aplikacji Sieć Aplikacja Sieć Dane Interfejs użytkownika Widok danych Logika biznesowa Logika danych VIEW CONTR OLLER MODEL

20 Model aplikacji (MA) APLIKACJA Użytkownik Warstwa prezentacji VIEW Widok danych Serwisy Logika biznesowa Warstwa biznesowa CONT ROLLE R Logika danych Warstwa danych Baza danych MODE L

21 Wzorce projektowe - MVC Model-View-Controller (MVC) [Model-Widok-Kontroler] - jest to wzorzec projektowy (podejście które jest bazą w oparciu o którą tworzymy aplikację), dzielący projektowaną aplikację na trzy warstwy: - Model (dane / logika) Widok (prezentacja danych) Kontroler (interakcja z użytkownikiem + sterowanie aplikacją) MODEL VIEW CONTR OLLER Można go zaimplementować bez użycia bibliotek czy specjalistycznych platform programistycznych, stosując jasne reguły podziału na konkretne komponenty w kodzie źródłowym. W ten sposób każdy komponent aplikacji można niezależnie od siebie rozwijać, implementować i testować.

22 Wzorce projektowe - MVC Jak działa MVC? Użytkownik wykonuje (określoną) czynność w aplikacji. Wyzwalana jest procedura obsługi zdarzenia (wywołanego przez użytkownika) w kontrolerze. Kontroler pozyskuje dane z modelu i następuje przekazuje je do widoku. W widoku dane są prezentowane użytkownikowi. Przykład synchroniczny czat: Użytkownik wpisuje wiadomość na czacie. Wyzwalana jest procedura obsługi przekazania wiadomości. Kontroler komunikuje się z modelem i zapisuje nową wiadomość. Kontroler uaktualnia widok Użytkownik widzi nową wiadomość w oknie czatu. M V C

23 Wzorce projektowe - MVC Jak działa MVC? Użytkownik wykonuje (określoną) czynność w aplikacji. Synchroniczny Wyzwalana jest procedura obsługi zdarzenia czat (np. Hangout (wywołanego przez użytkownika) w kontrolerze. w poczcie GMAIL) jest również Kontroler pozyskuje dane z modelu i następuje przykładem usługi przekazuje je do widoku. push. W widoku dane są prezentowane użytkownikowi. C Przykład synchroniczny czat: M Użytkownik wpisuje wiadomość na czacie. Wyzwalana jest procedura obsługi przekazania wiadomości. Kontroler komunikuje się z modelem i zapisuje nową wiadomość. Kontroler uaktualnia widok Użytkownik widzi nową wiadomość w oknie czatu. V

24 Wzorce projektowe - MVC Model - jest odpowiedzialny za przechowywanie wszystkich obiektów danych wykorzystywanych w aplikacji. Model odwzorowuje logikę danych i fizyczność przetwarzanych danych. Model nie wie nic o widokach i kontrolerach. W modelach nie może być zapisany żaden szablon widoku warstwy prezentacji danych ponieważ jest to sprzeczne z wzorcem MVC. Przykład - baza danych: Model użytkownika (USER) może przechowywać listę użytkowników, ich atrybuty oraz wyznacza logikę powiązania tych danych z innymi modelami danych. Kiedy kontroler pobiera dane z modelu tworzy na jego podstawie nową instancję tego modelu. Tworzone modele powinny być zorientowane obiektowo!!! MODEL

25 Wzorce projektowe - MVC Model var user = Users[ Jan ]; deleteuser(user); var user = Users.find( Jan ); user.delete(); Kod po lewej nie posiada przestrzeni nazw oraz nie jest zorientowany obiektowo. Np. gdyby w tej samej aplikacji zdefiniowano w innym miejscu metodę deleteuser(), powodowałoby to konflikt nazw. W kodzie po prawej metoda delete() należy do zdefiniowanej przestrzeni nazw i może być wywołana na instancjach obiektu Users. Drugi przykład pokazuje jak zmniejszając liczbę zmiennych globalnych ograniczono możliwość wystąpienia konfliktu. Dodatkowo metoda dzięki zapisowi obiektowemu można korzystać z dziedziczenia. Dzięki temu nie trzeba np. zdefiniować oddzielnie metody delete(), dla każdego istniejącego modelu.

26 Wzorce projektowe - MVC Widok - odpowiada za prezentację danych użytkownikowi. Z reguły nie mają żadnej logiki poza kilkoma prostymi instrukcjami warunkowymi. Zgodnie z podejściem modularnym widoki powinny być całkowicie oddzielone od innych części aplikacji. W aplikacjach internetowych widok najczęściej jest formułowany przez wykorzystanie szablonów oraz języków takich jak: HTML, CSS, JavaScript. Logika prezentacji powinna być ujęta w funkcjach tzw. helperach czyli specjalnych narzędzi do obsługi widoków. VIEW

27 Wzorce projektowe - MVC Widok //w widoku <script> function NewDate(date) { }; </script> <div> ${ NewDate(this.date) } </div> // w osobnym małym skrypcie var helper = {}; helper.newdate = function() {}; // w widoku <div> ${ helper.newdate(this.date) } </div> Kod po lewej definicję funkcji NewDate() umieszczono bezpośrednio w widoku (w kodzie HTML). Takie podejście jest niezgodne z regułami MVC. W kodzie po prawej stronie definicja funkcji jest wydzielona do osobnego pliku. Dodatkowo cała logika prezentacji jest wykonywana w kontekście określonej przestrzeni nazw helper. Zapobiega to wystąpieniu konfliktów z innymi definicjami oraz pozwala na łatwą rozbudowę istniejącego kodu.

28 Wzorce projektowe - MVC Kontroler - spełnia rolę pośrednika pomiędzy warstwą modelu danych, a widokami na których te dane mają zostać zaprezentowane. Przyjmują zdarzenia i dane przychodzące od użytkowników, przetwarzają je z zastosowaniem modeli i kierują do odpowiednich widoków i je zmieniają. W trakcie ładowania strony kontroler dodaje do widoków procesy nasłuchiwania zdarzeń. Dzięki temu kiedy użytkownik wykona określoną czynność (wywoła zdarzenie), w kontrolerze wyzwalana jest procedura obsługi tego zdarzenia. CONTR OLLER Do implementacji kontrolerów nie są potrzebne żadne specjalne biblioteki ani platformy programistyczne, jednak wygodniej jest z nich korzystać. Np. do implementacji tego typu architektury można wykorzystać bibliotekę jquery (

29 Wzorce projektowe - MVC Kontroler (przykład z wykorzystaniem jquery): // definicja przestrzeni nazw var Controller = {}; // enkapsulacja (Controller.users = function($){ var nameclick = function(){ //... }; // nasłuch zdarzenia $(function() { $( #name ).click(nameclick); }); })(jquery); W przykładzie stworzono kontroler users, który należy do przestrzeni nazw Controllers. Kontroler users został enkapsulowany za pomocą funkcji anonimowej, aby nie powodować konfliktów z innymi zmiennymi. Na zdarzeniu ready() - moment ładowania strony do przeglądarki do elementu widoku o identyfikatorze #name został dodany nasłuch zdarzenia click.

30 Wzorce projektowe - MVC W modelu pasywny nie ma wymiany danych pomiędzy modelem a widokiem z pominięciem kontrolera, wszystkie akcje są wywoływane i sterowane przez kontroler. CONTROL LER MODEL VIEW Model Pasywny

31 Wzorce projektowe - MVC W model aktywnym model może bezpośrednio przekazywać dane do widoku z pominięciem kontrolera. CONTROL LER MODEL VIEW service Model Aktywny

32 Architektura aplikacji Serwer HTTP Użytkownik Serwer aplikacji Sieć Aplikacja Sieć Dane Interfejs użytkownika Widok danych Logika biznesowa Logika danych VIEW CONTR OLLER MODEL

33 Protokół HTTP(S) Hyper Text Transfer Protocol (HTTP/1.1) [Protokół przesyłania dokumentów Hiper-Tekstowych] Oparty na TCP, Komendy tekstowe, Transmisja 8-bitowa, Bezstanowy i bezsesyjny. RFC 2616 (czerwiec 1999) RFC (Request for Comments) Bezstanowość (ang. stateless), co oznacza że nigdzie nie istnieje zapis stanu poprzednio wykonanych operacji, a kolejne transakcje są wykonywane niezależnie. Najważniejsze metody protokołu HTTP: HEAD - wysyła żadanie przesłania nagłówka zawierającego meta-dane (informację), bez przesyłania samego zasobu. GET - wysyła żądanie pobrania konkretnego zasobu URI (np. strony internetowej napisanej w języku HTML). POST - wysyła żądanie do serwera akceptacji zasobu dołączonego do żądania. pozostałe: PUT, DELETE, TRACE, OPTIONS, CONNECT. Zakres kodów Znaczenie Informacyjne Żądanie (od klienta) powiodło się Żądanie klienta zostało przekazane, wymagane są dalsze działania Żądanie klienta nie powiodło się Błąd serwera.

34 KONIEC WYKŁADU 2