Projektowanie aplikacji internetowych

Prezentacja na temat: "Projektowanie aplikacji internetowych"— Zapis prezentacji:

1 Projektowanie aplikacji internetowych
Wykład 6 Metodyki projektowania aplikacji internetowych Metodyka OOHDM Metodyka WSDM Metodyka W2000

2 Metodyka OOHDM OOHDM (ang. Object Oriented Hypermedia Design Method) – metodyka opublikowana w 1998 roku (Daniel Schwabe i Gustavo Rossi), wykorzystuje obiektowe podejście do tworzenia aplikacji webowych. Etapy tworzenia aplikacji internetowej: Zbieranie wymagań i projektowanie modelu koncepcyjnego Projektowanie modelu nawigacji Projektowanie modelu interfejsu Implementacja Założenia metodyki OOHDM: Postrzeganie obiektu nawigacyjnego jako widoku na obiekt koncepcyjny Wykorzystanie bytów abstrakcyjnych w celu uporządkowania i opisania przestrzeni nawigowania, wprowadzenie pojęcia kontekstu nawigacyjnego Oddzielenie zagadnień dotyczących interfejsu od aspektu nawigacji Ścisłe określenie i wyodrębnienie decyzji projektowych, podejmowanych dopiero w fazie implementacji. Zastosowanie: tworzenie stron internetowych, webowych systemów informacyjnych, internetowych aplikacji multimedialnych, itp.

3 OOHDM – specyfikacja wymagań
Zbieranie wymagań – odrębna faza w procesie tworzenia aplikacji internetowej (wykorzystywana notacja UML). Cele etapu zbierania wymagań: zdefiniowanie użytkowników systemu ról aktywności stworzenie scenariuszy opisujących przebieg interakcji miedzy użytkownikami a systemem

4 OOHDM - model koncepcyjny (1)
Tworzenie modelu koncepcyjnego - wykorzystywana jest notacja graficzna stworzona na potrzeby OOHDM. Opisywanie wymagań w intuicyjny i przystępny sposób. Model koncepcyjny składa się z 2 rodzajów obiektów: węzłów w modelu nawigacyjnym obiektów odpowiedzialnych np. za przetwarzanie logiki biznesowej aplikacji, czy wykonywanie obliczeń Model koncepcyjny: może posłużyć jako model bazowy dla wielu różnych aplikacji (nie zawiera żadnych szczegółów dotyczących nawigacji w obrębie aplikacji). przedstawia relacje pomiędzy obiektami oraz interakcje, jakie zachodzą miedzy nimi w ramach dziedziny aplikacji. OOHDM daje możliwość zamodelowania zarówno „statycznych” aplikacji internetowych jak i złożonych, dynamicznych aplikacji.

5 OOHDM - model koncepcyjny (2)
Model koncepcyjny składa się z: klas relacji podsystemów Klasy opisywane są podobnie jak w innych modelach zorientowanych obiektowo (notacja zbliżona do standardu UML, rozbudowana o pewne prymitywy) Klasa z perspektywą atrybutu

6 OOHDM - model koncepcyjny (3)
Końcowy produkt etapu budowy modelu konceptualnego: diagram składający się z klas połączonych relacjami. Przykładowy diagram klas

7 OOHDM – model nawigacji (1)
Produkt końcowy etapu tworzenia modelu nawigacji: diagram klas nawigacyjnych diagram kontekstów nawigacyjnych. Diagram nawigacyjny - perspektywa przedstawiająca jedno z możliwych spojrzeń na domenę aplikacji określoną w modelu koncepcyjnym. Model nawigacji jest budowany jako widok na model koncepcyjny. Czynniki, które należy brać pod uwagę podczas budowy takiego modelu, to: Obiekty pomiędzy którymi będzie odbywała się nawigacja oraz ich atrybuty Relacje występujące między obiektami modelu nawigacji a obiektami modelu koncepcyjnego Efekt przemieszczenia się użytkownika pomiędzy obiektami nawigowalnymi Wygląd obiektów w zależności od kontekstu, w jakim zostają odwiedzone (określenie różnic)

8 OOHDM – model nawigacji (2)
Obiekty nawigowalne aplikacji definiowane są poprzez diagram klas nawigacji (odzwierciedlają wybrany widok domeny aplikacji). Zbiór typów obiektów nawigowalnych: klasy, odnośniki, struktury dostępu (np. indeksy), przewodniki (możliwe sposoby dostępu do węzłów nawigacyjnych). OOHDM z wykorzystaniem transformacji nawigacyjnych opisuje dynamiczne zmiany w aplikacji poprzez reprezentacje zmian stanu aplikacji w wyniku nawigacji (przejścia z jednego węzła do drugiego - węzeł źródłowy jest deaktywowany, a węzeł docelowy aktywowany). Węzeł nawigacyjny - połączenie atrybutów różnych, powiązanych ze sobą klas z diagramu koncepcyjnego. Odnośniki odzwierciedlają relacje, po których może nawigować potencjalny użytkownik (widoki na relacjach opisanych w diagramie koncepcyjnym).

9 OOHDM – model nawigacji (3)
Kontekst nawigacyjny - zbiór odnośników, obiektów nawigowalnych, klas kontekstowych, zagnieżdżonych kontekstów nawigacyjnych. Definiowany jest poprzez podanie właściwości, która ma wspólną wartość dla wszystkich odnośników i obiektów nawigowalnych lub poprzez wyliczenie wszystkich elementów w nim występujących. Kontekst dynamiczny - elementy kontekstu nawigacyjnego mogą się zmieniać dynamicznie (np. zawartość koszyka). Konteksty nawigacyjne pozwalają na uporządkowanie przestrzeni nawigacji i pogrupowanie jej w spójne zbiory (wspomaganie użytkownika w wykonaniu zadania). Przykładowy diagram nawigacyjny na podstawie diagramu klas fazy koncepcyjnej

10 OOHDM – model nawigacji (3)
Kontekst nawigacyjny - zbiór odnośników, obiektów nawigowalnych, klas kontekstowych, zagnieżdżonych kontekstów nawigacyjnych. Definiowany jest poprzez podanie właściwości, która ma wspólną wartość dla wszystkich odnośników i obiektów nawigowalnych lub poprzez wyliczenie wszystkich elementów w nim występujących. Kontekst dynamiczny - elementy kontekstu nawigacyjnego mogą się zmieniać dynamicznie (np. zawartość koszyka). Konteksty nawigacyjne pozwalają na uporządkowanie przestrzeni nawigacji i pogrupowanie jej w spójne zbiory (wspomaganie użytkownika w wykonaniu zadania). Przykładowy diagram kontekstów nawigacyjnych

11 OOHDM – model interfejsu (1)
Budowa modelu interfejsu - zdefiniowanie sposobu prezentacji użytkownikowi obiektów nawigowalnych, wskazanie obiektów interfejsu aktywujących te obiekty i funkcje aplikacji oraz przedstawienie transformacji interfejsu. Oddzielenie modelu interfejsu od modelu nawigacji pozawala na budowę kilku modeli interfejsu na podstawie jednego modelu nawigacji. OOHDM wykorzystuje Abstrakcyjne Widoki Danych (ang. Abstract Data View - ADV) do opisu i zamodelowania interfejsu aplikacji. ADV: są definiowane jako obiekty, które posiadają swój stan oraz interfejs. zawierają zbiór atrybutów, które definiują jego właściwości percepcji oraz zbiór wydarzeń, które jest w stanie obsłużyć (np. klikniecie myszą, najechanie kursorem) określają strukturę interfejsu użytkownika przy użyciu agregacji i dziedziczenia jako mechanizmów abstrakcji. Definiują wygląd interfejsu obiektów nawigacji i innych obiektów, np. przycisków, itd. określają relacje, jakimi powiązane są z obiektami nawigacji określają ich zachowanie w odpowiedzi na zdarzenia zewnętrzne

12 OOHDM – model interfejsu (2)

13 OOHDM - implementacja Faza implementacji - przeniesienie obiektów koncepcyjnych wygenerowanych w poprzednich fazach do środowiska implementacyjnego. W fazie implementacji należy zdecydować: w jaki sposób projekt interfejsu oraz jego zachowanie zostanie zaimplementowane w danym środowisku implementacyjnym o sposobie przechowywanie wszystkich obiektów zdefiniowanych w modelach zbudowanych w poprzednich fazach.

14 WSDM (1) WSDM (Web Site Design Method, 1998 r.) - metodyka silnie ukierunkowana na projektowanie stron internetowych. Zorientowanie na użytkownika i jego potrzeby. Punktem wyjściowym jest zdefiniowanie wymagań potencjalnych użytkowników. WSDM: dzieli potencjalnych użytkowników na klasy użytkowników i modeluje dostępne dane z punktu widzenia każdej z klas użytkowników. zakłada rozgraniczenie fazy projektu koncepcyjnego od projektu prezentacji, co pozwala na zaprojektowanie stron WWW bez narzuconych ograniczeń wynikających z konkretnej techniki implementacji. pozwala wytwarzać strony internetowe bardziej dopasowane do potrzeb potencjalnego użytkownika, co ma bezpośrednie przełożenie na ich użyteczność oraz satysfakcje osób korzystających z projektowanej aplikacji.

15 Metodyka WSDM jest niezależna od użytej notacji do modelowania danych.
WSDM zakłada trzy kolejne etapy: Stworzenie modelu użytkowników Określenie modelu koncepcyjnego Stworzenie modelu implementacji Cykl życiowy aplikacji według WSDM

16 WSDM - model użytkowników (1)
Pierwsza faza metodyki WSDM koncentruje się na potencjalnych użytkownikach. Z projektowanego serwisu korzysta wiele różnych grup użytkowników, często o innych potrzebach. Przykład: Serwis wydziału uniwersytetu. Typowi użytkownicy serwisu: Kandydaci na studentów Studenci Kadra naukowo dydaktyczna Pracownicy administracyjni uniwersytetu

17 WSDM - model użytkowników (2)
Kandydaci na studentów poszukują ogólnych informacji o uczelni, oferowanych kierunkach i warunkach rekrutacji. Studenci potrzebują informacji na temat przedmiotów, warunków zaliczeń, planów zajęć, danych kontaktowych prowadzących zajęcia. Kadra naukowo – dydaktyczna poszukuje informacji o projektach badawczych. Każda z grup ma inne potrzeby, jeśli chodzi o poszukiwane na stronie informacje. Student powinien mieć możliwość przejścia jasno określonej ścieżki nawigacyjnej, w celu uzyskania potrzebnych informacji, np. przedmiotu, wykładowcy. Zazwyczaj informacje dotyczące, np. wykładowców znajdują się na ich stronach domowych. Student np. poszukujący informacji dotyczących godzin dyżurów wykładowcy musi przeszukać całą stronę domowa wykładowcy w celu wyszukania pożądanej informacji (co nie jest wygodne). Różne grupy użytkowników mogą mieć różne wymagania, co do sposobu prezentacji informacji. Kandydaci na studia mogą nie znać specyficznych terminów dlatego informacja powinna być podana w zrozumiałej dla tej grupy formie z objaśnieniem terminów.

18 WSDM – klasyfikacja użytkowników (1)
Identyfikacja i podział potencjalnych użytkowników na grupy jest istotnym elementem tworzenia modelu użytkowników i determinuje kierunek budowy serwisu WWW. Należy zastosować całościowe spojrzenie na kształt organizacji lub przebieg procesu dla którego budowana będzie strona. Przykłady procesów (uniwersytet): Kształcenie Przeprowadzanie badan Publikowanie prac Identyfikacja grupy/klasy osób zaangażowanych w poszczególne aktywności: Kandydaci na studia Studenci Kadra naukowo-dydaktyczna Pracownicy Administracyjni

19 WSDM – klasyfikacja użytkowników (2)
Zależności miedzy poszczególnymi procesami a klasami użytkowników. Metoda pozwala podzielić cały zbiór potencjalnych użytkowników na podzbiory reprezentowane przez poszczególne klasy użytkowników. Klasy użytkowników i procesy WSDM

20 WSDM – klasy użytkowników
Dalszy etap, to uszczegółowianie każdej z wyodrębnionych klas. Płaszczyzny uszczegółowiania: Wymagania dotyczących potrzebnych informacji w zależności od klasy użytkowników. W ramach danej klasy – jednakowe wymagania odnośnie udostępnianej informacji, ale mogą wystąpić zróżnicowane oczekiwania, co do sposobu prezentacji informacji. Przykład: użytkownicy z klasy „Studenci” Studenci z różnych krajów będą oczekiwać informacji podanych w różnych językach. Badanie charakterystyki użytkowników w obrębie danej klasy, określenie sposobu prezentacji informacji, uwzględnienie np. wieku, wykształcenia, itd. Jeśli w obrębie jednej klasy są zdefiniowane różne charakterystyki użytkowników, wtedy klasa ulega podziałowi na perspektywy. Przykład: podział klasy Studenci na perspektywy: Studenci miejscowi oraz Studenci zagraniczni pochodzących z wymiany.

21 WSDM – model koncepcyjny
Dwie fazy tworzenia modelu konceptualnego: faza tworzenia modelu danych faza tworzenia modelu nawigacji Tworzenie modelu danych - formalizacja opisu danych dla poszczególnych klasy użytkowników. Model nawigacji opisuje sposób nawigacji poszczególnych użytkowników na stronie. Każda perspektywa (podzbiór klasy użytkowników) będzie miała docelowo swoja własną ścieżkę nawigacyjna.

22 Budowa odrębnych modeli danych dla każdej z klas użytkowników.
WSDM – model danych (1) Budowa odrębnych modeli danych dla każdej z klas użytkowników. Modele te nazywamy Modelami Danych Użytkowników (ang. User Object Models - UOM). UOM modeluje byty biznesowe w organizacji z punktu widzenia poszczególnych klas użytkowników (opisywanie tylko części zbioru bytów biznesowych w organizacji). Model danych opisuje różne typy obiektów, relacje miedzy nimi i ograniczenia nałożone na te relacje. Model Danych Użytkowników WSDM

23 WSDM – model danych (2) W obrębie jednej klasy użytkowników możemy wyróżnić kilka perspektyw (np. Studenci miejscowi i Studenci zagraniczni pochodzący z wymiany). Perspektywa Studentów zagranicznych ma takie same wymagania jak perspektywa Studentów miejscowych (jeśli chodzi o zakres informacji), ale inne wymagania odnośnie sposobu prezentacji informacji. Tworzenie modelu danych obejmuje więc również tworzenie tzw. „wariantów perspektyw”, odzwierciedlających podział na perspektywy w ramach klas użytkowników. Dla każdego bytu w UOM oraz dla każdej perspektywy tworzony jest wariant tej perspektywy, jako wariant oryginalnego bytu przedstawionego w UOM. Przykład: Przedmiot (byt przedstawiony na UOM) - wyróżnienie dwóch wariantów perspektyw (jedne dla studentów miejscowych, drugi dla studentów zagranicznych).

24 WSDM – model danych (3) Dla atrybutów zmienianych podawana jest nazwa atrybutu w klasie użytkownika wraz z nazwą atrybutu właściwej dla danej perspektywy. Warianty perspektyw klasy WSDM Model Danych Perspektywy (ang. Perspective Object Model - POM) dla danej perspektywy uzyskujemy poprzez zastąpienie danego bytu w UOM jednym z wariantów perspektyw tego bytu. W celu uniknięcia przechowywania nadmiarowych różne POM są opisywane jako widoki na pojedynczym UOM.

25 WSDM – model nawigacji (1)
Model nawigacji składa się ze ścieżek nawigacyjnych dla każdej perspektywy (POM). Ścieżka nawigacyjna określa jak użytkownicy perspektyw mogą nawigować w przestrzeni informacyjnej. Do opisu ścieżek nawigacyjnych wykorzystywane są takie odnośniki i komponenty. Komponenty dzielimy na komponenty informacyjne, nawigacyjne oraz zewnętrzne Komponenty modelu nawigacji WSDM Każdy komponent informacyjny odpowiada obiektowi perspektywy (POT). Poszczególne obiekty różnych perspektyw mogą być ze sobą powiązane relacjami, komponent informacyjny zawiera również odnośniki, które pozwalają na nawigacje miedzy obiektami w celu uzyskania powiązanych ze sobą informacji.

26 WSDM – model nawigacji (2)
Komponenty nawigacyjne można postrzegać jako zbiory odnośników. Zewnętrzne komponenty, to referencje do komponentów umieszczonych na innych stronach. Podczas budowy modelu nawigacji dla każdego POM (Model Danych Perspektywy) tworzona jest ścieżka nawigacyjna, która się składa się z 3 warstw: Warstwa górna (kontekstowa), która jest później wykorzystywana do łączenia ścieżek nawigacyjnych. Warstwa środkowa (nawigacji), która zapewnia dostęp do danych. Warstwa najniższa (danych), która zawiera dane w postaci komponentów danych.

27 WSDM – model nawigacji (3)
Budowa ścieżek nawigacyjnych: Warstwa kontekstowa Ścieżka nawigacyjna rozpoczyna się komponentem nawigacyjnym o tej samej nazwie jak perspektywa (górna warstwa ścieżki nawigacyjnej) Warstwa nawigacji Warstwa nawigacji łączy warstwę kontekstową z warstwą informacyjną (projekt zgodnie z potrzebami użytkowników danej perspektywy). Algorytm budowy tej warstwy: Każdy komponent informacyjny powinien być osiągalny z warstwy kontekstowej, czyli dla każdego obiektu perspektywy tworzony jest komponent nawigacyjny o tej samej nazwie, dla którego dodatkowo budowany jest odnośnik do warstwy kontekstowej. Jeśli dany komponent informacyjny nie jest osiągalny w bezpośredni sposób, tworzone są pośredniczące komponenty nawigacyjne oraz odnośniki. Warstwa danych Każdy obiekt perspektywy (POT) staje się komponentem informacyjnym, lub komponentem zewn. w ścieżce nawigacyjnej. O klasyfikacji decyduje dostępność danych. Dla każdej relacji miedzy obiektami perspektywy tworzony jest odnośnik.

28 WSDM – model nawigacji (4)
Ścieżki nawigacyjne dla studentów lokalnych WSDM Ścieżki nawigacyjne dla studentów zagranicznych WSDM

29 WSDM - model implementacji (1)
Budowa modelu implementacji ma na celu zaprojektowanie właściwego kształtu strony internetowej (zgodnie z założeniami wynikającymi z poprzednich faz). Wytyczne do tworzenia modelu implementacji: Grupowanie informacji w odpowiedniej wielkości „paczki” WSDM pozwala na grupowanie komponentów połączonych odnośnikami i ich prezentacje na pojedynczej stronie. Komponenty nawigacyjne mogą być reprezentowanie przez różnego rodzaju listy (uporządkowane lub nieuporządkowane). Użycie strony indeksowej Strona indeksowa zawiera odnośniki do pozostałych stron w obrębie danego serwisu (uproszczona wersja modelu koncepcyjnego). Zalecane jest wykorzystanie modelu koncepcyjnego i stworzenie strony indeksowej jako jego uproszczonej reprezentacji (możliwość zlokalizowania dowolnej strony przez użytkownika oraz zbudowanie wysoko poziomowego obrazu całości serwisu).

30 WSDM - model implementacji (2)
Wytyczne do tworzenia modelu implementacji: Wykorzystanie kontekstu Unikanie tworzenia stron niezawierających wskazówek pozwalających użytkownikowi dokonać szybkiej oceny strony pod katem przydatności zawartych na niej informacji. Tworzenie perspektyw oraz odrębnych ścieżek nawigacyjnych dla każdej perspektywy (tworzenie stron ściśle przeznaczonych dla konkretnej grupy użytk.) Umieszczanie na stronach informacji pozwalających szybko ocenić zawarte na danej stronie informacje. Rozróżnianie odnośników Zwykle użytkownik korzystający z odnośników od początku danej ścieżki nawigacyjnej pozostaje w ramach jednej perspektywy. Zaleca się wprowadzenie na stronie rozróżnienia odnośników występujących w ramach ścieżki nawigacyjnej od pozostałych kierujących użytkownika na inne strony niezwiązane ze ścieżka, bądź też do zasobów zewnętrznych.

31 WSDM - implementacja Implementacja zaprojektowanej strony w wybranym środowisku implementacyjnym. Implementacja w języku HTML - konwersja modelu implementacyjnego w zbiór stron napisanych w języku HTML (możliwość zautomatyzowania tej czynności). Zalecanym podejściem jest oddzielenie warstwy danych (przechowywanie w bazie danych, generowanie treści stron przy użyciu informacji pobieranych z bazy). Obiekty opisane w diagramie POM w naturalny sposób mogą być wykorzystane do stworzenia modelu takiej bazy danych. Widoki (perspektywy) tworzone dla poszczególnych obiektów mogą być użyte do wygenerowania odpowiednich zapytań do bazy danych, które pozwolą pobrać właściwe dla danej perspektywy dane.

32 W2000 W metodyka wywodząca się z HDM (pierwowzór OOHDM) obejmuje: Kompleksowe podejście do tworzenia specyfikacji aplikacji webowych. Wspiera modelowanie logiki biznesowej poprzez możliwość opisania atomowych funkcji, które może wywołać użytkownik oraz bardziej złożonych transakcji definiujących usługi aplikacji. Precyzyjne zdefiniowanie W2000 przy pomocy metamodelu MOF (uproszczona wersja diagramu klas UML). MOF pozwala na precyzyjne i elastyczne zdefiniowanie wszelkich pojęć niezbędnych do efektywnego modelowania bez angażowania skomplikowanych i sformalizowanych modeli.

33 W2000 – metamodel (1) Metamodel W zbiór pakietów identyfikujących główne modele (widok na całość specyfikacji) definiujące projekt w metodyce W2000. Pakiet Informacji definiuje podstawowe konstrukcje wykorzystywane przy projektowaniu struktury danych (paczki informacji widziane przez użytkownika, z którymi może wchodzić w interakcje). W skład pakietu wchodzą: Elementy wspólne - zbiór konstrukcji wykorzystywanych przez pozostałe pakiety Pakiet bazowy - konstrukcje służące do modelowania danych, Pakiet Struktur Dostępu - grupowanie danych tak, jak postrzega je użytkownik. Pakiet Nawigacji definiuje podstawowe konstrukcje umożliwiające zamodelowanie sposobu nawigacji miedzy danymi (podzielenie danych na części o małej granularności, połączone odnośnikami i zgrupowane w klastry). Pakiet Prezentacji zawiera konstrukcje umożliwiające definiowanie sposobu prezentacji informacji (prezentacje tego, co zostało zdefiniowane przy pomocy w/w pakietów).

34 W2000 – metamodel (2) Pakiet Dynamiki definiuje konstrukcje pozwalające na dodanie dynamicznych zachowań do stron WWW. Operacje mogące modyfikować elementy z pakietu dynamiki są zgrupowane w aktywności (możliwości przeprowadzania transakcji), możliwe do przedstawienia w formie przykładowych scenariuszy. Pakiet Dynamiki dzieli się na: pakiet diagramów stanów (łączenie bytów powstałych w fazie projektowania z diagramami stanów oraz zamodelowanie ich ewolucji) pakiet Operacji umożliwiający dodanie do projektu konstrukcji definiujących operacje pozwalające na modyfikacje przechowywanych danych Pakiet Aktywności grupujący poszczególne operacje oraz definiujący transakcje Pakiet Scenariuszy ilustrujący przebieg poszczególnych operacji poprzez diagramy interakcji

35 Pakiety definiują również modele stanowiące istotę metodyki W2000.
W2000 – metamodel (3) Pakiety definiują również modele stanowiące istotę metodyki W2000. Główne modele: Model Informacji Model Nawigacji Model Prezentacji Model W2000 jako pakiet najwyższego poziomu abstrakcji

36 Pakiet bazowy (ang. Hyperbase)
W2000 – pakiet informacji Pakiet Informacji definiuje pojęcia służące do budowania modeli informacji (informacje dostępne dla użytkownika). Pakiet bazowy (ang. Hyperbase) Pakiet elementów wspólnych (ang. Common Elements) Pakiet Struktur Dostępu (ang. Access Structures) Elementem kluczowym są Encje. Pakiet bazowy reprezentuje dane, od strony koncepcyjnej Encje są zorganizowane w podgrupy semantyczne nazywane komponentami - grupowanie zawartości encji w grupy Pakiet informacji Właściwości encji

37 W2000 – pakiet nawigacji Pakiet Nawigacyjny definiuje pojęcia pozwalające na reorganizacje informacji, które przekazywać ma aplikacja pod katem nawigacji. Dane są zgrupowane w atomowe jednostki – Węzły (wywodzą się z komponentów encyjnych, asocjacji semantycznych, centrum kolekcji lub są tworzone na nowo w tylko w celach nawigacji) W tym pierwszym przypadku węzły zawierają sloty powiązane z informacjami, które maja wyświetlać, natomiast w tym drugim przypadku są pustymi węzłami. Właściwości węzła

38 Jednostki prezentacji są najmniejszymi bytami w pakiecie prezentacji
W2000 – pakiet prezentacji Pakiet Prezentacji definiuje pojęcia określające sposób umieszczania informacji na stronie oraz sposób definiowania dostępu użytkowników do informacji. Jednostki prezentacji są najmniejszymi bytami w pakiecie prezentacji Mogą być wyprowadzone z węzłów lub też stworzone jako zupełnie nowe byty. Właściwości jednostki prezentacji

39 W2000 – pakiet dynamiki (Dynamic Behavior) (2)
Pakiet dynamicznych zachowań składa się z diagramów stanów, scenariuszy, aktywności oraz operacji. Operacje nie są powiązane z obiektami przechowującymi informacje, stanowią wyodrębnione byty. Wszystkie elementy wykorzystywane do modelowania aplikacji mogą być wykorzystane jako parametry dla operacji, mogą być przez nie modyfikowane. Operacje dzielimy na: proste - kroki obliczeniowe wywoływane przez użytkownika, stanowiące część składową aktywności („czarna skrzynka”) złożone (składające się z wielu kroków) - zachowują cechę atomowości, ale z punktu widzenia użytkownika nie są juz rozpatrywane jako czarne skrzynki aktywności – transakcje, kontenery na operacje. Aktywność definiuje zbiór operacji, do których umożliwia dodanie dodatkowych atrybutów pozwalających na lepszą kontrolę efektów ich wykonania.

40 Podsumowanie OOHDM skupia się na danych oferowanych przez projektowaną aplikację, prezentacji tych danych oraz nawigację między stronami aplikacji. WSDM kładzie największy nacisk na potencjalnych użytkownikach systemu oraz na ich potrzebach. W2000 opisywanie nie tylko aspektu projektowania danych i hipertekstu ale całej aplikacji internetowej. Wszystkie metodyki zakładają powstawanie kolejnych modeli definiujących poszczególne aspekty aplikacji. Wszystkie metodyki poruszają kwestię danych, na których ma działać projektowana aplikacja, kwestię prezentacji tych danych oraz aspekt nawigacji. Wszystkie metodyki - można realizować przy pomocy cyklu życiowego aplikacji. Wszystkie metodyki zakładają użycie znanych notacji modelowania danych (UML, ER). Wszystkie metodyki oferują także nowe notacje pozwalające na przedstawienie na diagramie: obiektów publikujących dane, obiektów reprezentujących model nawigacji. Wszystkie metodyki abstrahują od konkretnych rozwiązań technologicznych, do aspektu implementacji przedstawiają jedynie zestaw wskazówek. Brakuje narzędzi wykorzystujących te podejścia.