7. Proces tworzenia aplikacji Kurs WebML 7. Proces tworzenia aplikacji Copyright © Politecnico di Milano March 2003 Translation: Kamil Żyła, Politechnika Lubelska

Translation: Kamil Żyła, Politechnika Lubelska Plan Cykl życia aplikacji Specyfikacja wymagań Projektowanie modelu danych Projektowanie modelu hipertekstowego Poniższy moduł zawiera przegląd zagadnień związanych z projektowaniem aplikacji, modelami WebML oraz narzędziami. Translation: Kamil Żyła, Politechnika Lubelska

Translation: Kamil Żyła, Politechnika Lubelska Cykl życia aplikacji Translation: Kamil Żyła, Politechnika Lubelska

1.1. Zbieranie wymagań 1.2. Analiza wymagań 1. Specyfikacja wymagań 1.1. Zbieranie wymagań 1.2. Analiza wymagań Translation: Kamil Żyła, Politechnika Lubelska

Translation: Kamil Żyła, Politechnika Lubelska 1. Specyfikacja wymagań WEJŚCIE: wymagania biznesowe WYJŚCIE: zorientowana na użytkownika, łatwa do zrozumienia, precyzyjna specyfikacja Dwie główne czynności 1. Zbieranie wymagań: określenie dziedziny i oczekiwań wobec aplikacji na podstawie rozmów z jej przyszłymi użytkownikami oraz istniejącej dokumentacji 2. Analiza wymagań: rewizja i formalizacja zebranych w poprzedniej fazie informacji (wymagań) Efekt specyfikacji jest użyteczny dla Projektantów: zrozumienie, co aplikacja ma robić Zleceniodawców: sprawdzenie zgodności specyfikacji z wymaganiami biznesowymi Translation: Kamil Żyła, Politechnika Lubelska

Translation: Kamil Żyła, Politechnika Lubelska 1.1. Zbieranie wymagań Nieustrukturyzowana czynność polegająca na zbieraniu informacji Identyfikacja użytkowników: podział użytkowników na grupy Wymagania funkcjonalne: identyfikacja funkcjonalności realizowanej przez aplikację (diagram przypadków użycia i scenariusze) Istotne obiekty (core concepts): identyfikacja najistotniejszych obiektów z dziedziny aplikacji, które będą zarządzane i przetwarzane Wymagania personalizacyjne: formalizacja potrzeby przyporządkowania treści i funkcjonalności do różnych aktorów, bazującego na ich preferencjach i prawach dostępu Wymagania sprzętowe: dla aplikacji obsługujących różne rodzaje urządzeń dostępowych Wymagania niefunkcjonalne: ergonomiczność, wydajność, dostępność, skalowalność, bezpieczeństwo, zarządzalność Translation: Kamil Żyła, Politechnika Lubelska

1.1. Zbieranie wymagań niefunkcjonalnych Ergonomia: wygoda używania aplikacji Wydajność: wydajność, z jaką aplikacja wykorzystuje dostępne zasoby, w sensie przepustowości (liczba żądań, które mogą zostać obsłużone w jednostce czasu) i czasu odpowiedzi Dostępność: dopuszczalna częstotliwość występowania błędów i awarii Skalowalność: zdolność do zwiększania wydajności aplikacji w odpowiedzi na zwiększenie liczby żądań Bezpieczeństwo: ochrona integralności i poufności informacji, autentykacja użytkowników, ochrona informacji przekazywanych pomiędzy użytkownikami i aplikacją Zarządzalność: łatwość usuwania błędów oraz przystosowanie aplikacji do zmieniających się wymagań Translation: Kamil Żyła, Politechnika Lubelska

Translation: Kamil Żyła, Politechnika Lubelska 1.2 Analiza wymagań Rewizja i formalizacja zebranych wymagań, której efektem jest zbiór półformalnych specyfikacji, którymi zazwyczaj są a. Specyfikacja grup użytkowników b. Specyfikacja przypadków użycia c. Specyfikacja słownika obiektów d. Specyfikacja widoków stron e. Specyfikacja wyglądu aplikacji f. Specyfikacja testów akceptacyjnych Translation: Kamil Żyła, Politechnika Lubelska

1.2.a Specyfikacja grup użytkowników Podział użytkowników na grupy (formalnie opisany) Product News. Obiekty – tryb zapisu: Product i Product News. tryb odczytu: “Login”, “Add a news item”, “Modify a news item”, “Delete a news item”, “Add a news category”, “Modify a news category”, “Delete a news category”, "Modify profile data". Powiązane przypadki użycia: Brak. Podgrupy: Corporate. Nadgrupa: First name, last name, email, office address. Dane grupy są jawnie wprowadzane przez użytkownika. Dane grupy: Personel odpowiadający za marketing i komunikację oraz zarządzający materiałami marketingowymi Opis: Mar-Com Manager Nazwa grupy: Opis Grupy: Hierarchia Grup: Translation: Kamil Żyła, Politechnika Lubelska

1.2.b Specyfikacja przypadków użycia Formalny opis sposobów interakcji z aplikacją przez użytkowników należących do wyróżnionych grup (np. postać tabelaryczna lub diagramów UML) Lista przypadków użycia dla użytkownika (diagram przypadków użycia) Translation: Kamil Żyła, Politechnika Lubelska

1.2.b Specyfikacja przypadków użycia Specyfikacja pojedynczego przypadku użycia (tabela lub diagram aktywności) Muszą zostać wykonane poniższe kroki: Użytkownikowi zostaje wyświetlony formularz logowania; Użytkownik wprowadza swoje dane logowania; Jeśli dane są poprawne, użytkownik jest autentykowany, jest określana lista grup, do których należy użytkownik oraz lista nazw i adresów URL do stron domowych widoków stron, do których użytkownik może uzyskać dostęp; Użytkownik wybiera jedną pozycję listy i zostaje przeniesiony do wybranego widoku stron. Przebieg Użytkownik pomyślnie loguje się do aplikacji i uzyskuje dostęp do widoku stron przypisanego do jednej z jego grup. Warunki końcowe Użytkownik jest zarejestrowany i należy do wielu grup. Każda grupa ma dostęp do odpowiedniego widoku stron. Warunki początkowe Przedstawia, w jaki sposób użytkownicy należący do więcej niż jednej grupy uzyskują dostęp do funkcjonalności aplikacji Cel Logowanie użytkownika należącego do wielu grup Nazwa Translation: Kamil Żyła, Politechnika Lubelska

1.2.c Specyfikacja słownika obiektów Lista najważniejszych obiektów zidentyfikowanych w trakcie analizy zebranych wymagań Każdy wpis w słowniku jest charakteryzowany przez: Nazwę Synonim Opis Przykładowe instancje Właściwości Relacje Komponenty Generalizację Specjalizacje NewsItem Piece of news A corporate or product piece of news TravelMate 610 launched, 20th June 01 Title, Body, Image, Date, … NewsToProduct None Highlighted news Translation: Kamil Żyła, Politechnika Lubelska

1.2.d Specyfikacja widoków stron (site map) WEJŚCIE: lista grup użytkowników, lista przypadków użycia, słownik obiektów WYJŚCIE: lista widoków stron o cechach Nazwa Opis Docelowe grupy użytkowników Realizowane przypadki użycia Mapa widoku stron: tabela ilustrująca obszary składające się na widok stron. Każdy obszar jest określany przez Nazwę obszaru Opis obszaru Obiekty dostępne do odczytu i zapisu Priorytet Translation: Kamil Żyła, Politechnika Lubelska

1.2.d Site view specification example Wysoki NewsCategory NewsItem Na stronie domyślnej użytkownik otrzymuje listę krajów, dla których administruje informacjami marketingowymi. Na stronie News Category użytkownik otrzymuje listę kategorii newsów dla wybranego kraju. Tutaj użytkownik ma dostęp do funkcjonalności realizowanej przez przypadki użycia “Add a news category”, “Edit a news category”, “Remove a news category”. Ma możliwość wybrania kategorii i uzyskania dostępu do listy newsów w wybranej kategorii. Na stronie News page, użytkownik ma dostęp do funkcjonalności realizowanej przez przypadki użycia “Add a news item”, “Edit a news item”, “Remove a news item”. News Content Management Priorytet Obiekty Opis obszaru Nazwa obszaru Mapa widoku stron “Login”, “Add a news category”, “Edit a news category”, “Remove a news category”, “Add a news item”, “Edit a news item”, “Remove a news item”. Przypadki użycia Mar-Com Managers Grupy użytkowników Zawiera strony, przy użyciu których Managerowie Mar-Com uzyskają dostęp do funkcji zarządzania treścią (dodawanie, aktualizowanie informacji o produktach) Opis Widok stron 1.2.d Site view specification example Translation: Kamil Żyła, Politechnika Lubelska

1.2.e Specyfikacja wyglądu aplikacji Wytyczne tworzenia wyglądu strony Specyfikacja siatki stron: układ wierszy, kolumn i komórek Specyfikacja rozmieszczenia treści: pozycja banerów, logo i menu Wytyczne wyglądu elementów: krój czcionki, kolory, obramowania i marginesy Wytyczne specyficzne dla przeglądarek i urządzeń dostępowych Przykład: Szkice (Mockups): przykładowa reprezentacja (szkic) kilku typowych stron aplikacji (dla specyficznego urządzenia i języka) Translation: Kamil Żyła, Politechnika Lubelska

1.2.e Specyfikacja wyglądu aplikacji - przykłady Content positioning: Pozycjonowanie treści Siatka strony Wytyczne stylów Translation: Kamil Żyła, Politechnika Lubelska

1.2.f Specyfikacja testów akceptacyjnych Formalizacja testów akceptacyjnych dotyczących wymagań niefunkcjonalnych Wydajność Dostępność Skalowalność Bezpieczeństwo Zarządzalność Translation: Kamil Żyła, Politechnika Lubelska

2. Projektowanie modelu danych 2.1. Podschemat szkieletowy 2.2. Podschemat dostępowy 2.3. Podschemat połączeń 2.4. Podschemat personalizacji Translation: Kamil Żyła, Politechnika Lubelska

2. Projektowanie modelu danych WEJŚCIE: słownik obiektów, mapa aplikacji, wymagania funkcjonalne, wymagania użytkownika WYJŚCIE: formalny model danych (diagram ERD) Model danych Systematyzuje wymagania aplikacji Jest podstawą dla modelu hipertekstowego Uwzględnia istniejące źródła danych Mogą zaistnieć dwie różne sytuacje Źródło danych nie istnieje i musi zostać zaprojektowane razem z aplikacją Źródło danych istnieje w całości lub częściowo Translation: Kamil Żyła, Politechnika Lubelska

2. Model danych: klasyfikacja encji (1) Obiekty szkieletowe Najważniejsze zasoby zarządzane przez aplikacją Stanowią kręgosłup diagramu ERD Mogą być reprezentowane przez więcej niż jedną encję (ze względu na atrybuty złożone i komponenty) Podschemat szkieletowy, to zbiór encji powiązanych relacjami i wspólnie reprezentujących jedną klasę obiektów szkieletowych Obiekty połączeń Semantyczna asocjacja pomiędzy obiektami szkieletowymi Są używane do konstruowania linków i indeksów służących do nawigacji Składają się z relacji Translation: Kamil Żyła, Politechnika Lubelska

2. Model danych: klasyfikacja encji (2) Obiekty dostępowe Są obiektami pomocniczymi wykorzystywanymi do klasyfikowania i specjalizowania obiektów szkieletowych, w celu ułatwienia dostępu do nich poprzez Kategoryzację obiektów szkieletowych Precyzyjne mechanizmy wyszukiwania Kolekcje najbardziej reprezentatywnych obiektów Są mapowane jako encje połączone z encjami szkieletowymi Podschemat dostępowy: te same obiekty szkieletowe mogą być kategoryzowane lub specjalizowane na wiele sposobów Obiekty personalizacyjne Informacje o użytkowniku potrzebne do personalizacji Encje mogą być użyte żeby modelować dane użytkownika oraz dane grup, których jest członkiem Użytkownicy i ich grupy mogą być połączone relacjami (własności, preferencji, …) z innymi encjami Translation: Kamil Żyła, Politechnika Lubelska

2. Model danych: klasyfikacja encji (3) Translation: Kamil Żyła, Politechnika Lubelska

2.1. Podschemat szkieletowy Identyfikacja encji szkieletowych: ze słownika obiektów i innych wymagań Szczegółowy projekt podschematu: atrybuty, komponenty i relacje Translation: Kamil Żyła, Politechnika Lubelska

Translation: Kamil Żyła, Politechnika Lubelska 2.2. Podschemat dostępowy Może zostać zaprojektowany na podstawie przypadków użycia i innych mechanizmów dostępu do treści Translation: Kamil Żyła, Politechnika Lubelska

Translation: Kamil Żyła, Politechnika Lubelska 2.3. Podschemat połączeń Semantyczne połączenie pomiędzy encjami podschematu szkieletowego Translation: Kamil Żyła, Politechnika Lubelska

2.4. Podschemat personalizacji Profile zarejestrowanych użytkowników i zarządzanie dostępem do treści Translation: Kamil Żyła, Politechnika Lubelska

3. Projektowanie modelu hipertekstowego 3.1. Projekt ogólny 3.2. Projekt szczegółowy Translation: Kamil Żyła, Politechnika Lubelska

3. Projektowanie modelu hipertekstowego WEJŚCIE: model danych, mapa aplikacji, wymagania funkcjonalne, wymagania użytkownika WYJŚCIE: model hipertekstowy (WebML) Dwa etapy projektowania 1. Projekt ogólny 2. Projekt szczegółowy Translation: Kamil Żyła, Politechnika Lubelska

Translation: Kamil Żyła, Politechnika Lubelska 3.1. Projekt ogólny (1) a) Identyfikacja obszarów poprzez ponowną analizę wymagań funkcjonalnych i mapy aplikacji (podział aplikacji na moduły) b) Określenie widoczności obszarów Obszar domyślny, jest otwierany automatycznie, gdy użytkownik przechodzi do zawierającego go widoku stron Obszar „strefa zrzutu” (landmark), można do niego przejść z dowolnego miejsca widoku stron, w którym się zawiera Obszar wewnętrzny, można do niego przejść tylko przy pomocy linków Translation: Kamil Żyła, Politechnika Lubelska

Translation: Kamil Żyła, Politechnika Lubelska 3.1. Projekt ogólny (2) c) Specyfikacja zawartości Hipertekst szkieletowy Core(CoreEntity,Component1,…,ComponentN) Hipertekst dostępowy Access(CoreEntity,AccessEntity1,…,AccessEntityN) Hipertekst połączeń Interconnection(Role1,…,RoleN) Hipertekst personalizacyjny Hipertekst zarządzający treścią Create&Connect(Entity1,Role1, .., RoleN) Modify(Entity1) Delete(Entity1) Connect(Role1), Disconnect(Role1) Set(ContextInformation) Translation: Kamil Żyła, Politechnika Lubelska

Translation: Kamil Żyła, Politechnika Lubelska 3.1. Projekt ogólny (3) Definicja przykładowego obszaru Translation: Kamil Żyła, Politechnika Lubelska

3.2. Projekt szczegółowy (1) a) Identyfikacja stron Podział obszarów na strony Każda strona ma przypisaną pewną treść i funkcjonalność realizowaną przez obszar, na który się składa b) Widoczność stron Strona domowa: pierwsza strona prezentowana użytkownikowi po przejściu do widoku stron Strona domyślna: pierwsza strona prezentowana użytkownikowi po przejściu do obszaru, który ją zawiera Strona „strefa zrzutu” (landmark): strona dostępna z dowolnego miejsca widoku stron, który ją zawiera Strona wewnętrzna: strona dostępna tylko poprzez nawigację odpowiednimi linkami Translation: Kamil Żyła, Politechnika Lubelska

3.2. Projekt szczegółowy (2) Przykład Translation: Kamil Żyła, Politechnika Lubelska

3.2. Projekt szczegółowy (3) c) Specyfikacja stron Szczegółowa specyfikacja komponentów i linków, niezbędna do dostarczenia treści i funkcjonalności opisanej w ogólnym projekcie modelu hipertekstowego Wykorzystanie typowych podschematów modelu hipertekstowego Podschemat szkieletowy Podschemat połączeń Podschemat dostępowy Podschemat personalizacji Translation: Kamil Żyła, Politechnika Lubelska

Translation: Kamil Żyła, Politechnika Lubelska Przykład podschematu dostępowego Translation: Kamil Żyła, Politechnika Lubelska

ProductsFull hierarchical index ProductsShort hierarchical index Country Change Country ProductsFull hierarchical index ProductsShort hierarchical index ProductGroup Translation: Kamil Żyła, Politechnika Lubelska

Translation: Kamil Żyła, Politechnika Lubelska Przykład podschematu szkieletowego Translation: Kamil Żyła, Politechnika Lubelska

Products hierarchical index CurrentCountry Products hierarchical index Change Country Product Benefits To TechSpecs Page Translation: Kamil Żyła, Politechnika Lubelska

3.2. Projekt szczegółowy (5) Przykład: podschemat personalizacji Wyświetlenie informacji o preferowanym mieście Translation: Kamil Żyła, Politechnika Lubelska