Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 1 marzec 2001 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta Instytut Podstaw.

Podobne prezentacje


Prezentacja na temat: "E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 1 marzec 2001 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta Instytut Podstaw."— Zapis prezentacji:

1 E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 1 marzec 2001 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta Instytut Podstaw Informatyki PAN, Warszawa Polsko-Japońska Wyższa Szkoła Technik Komputerowych, Warszawa Wprowadzenie do UML Wykład 3

2 E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 2 marzec 2001 Zagadnienia Cykl życiowy produktu informatycznego Modelowanie pojęciowe Metodyka UML: Krótka charakterystyka Modele i diagramy Mechanizmy rozszerzalności

3 E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 3 marzec 2001 Cykl życiowy produktu informatycznego Faza strategiczna Faza specyfikacji i analizy wymagań --> projektowanie (modelowanie) pojęciowe Faza projektowania --> projektowanie logiczne Faza konstrukcji (implementacji) --> projektowanie fizyczne Faza testowania Faza konserwacji czas Fazy cyklu życiowego produktu informatycznego:

4 E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 4 marzec 2001 Modelowanie pojęciowe Pojęcia: modelowanie pojęciowe (conceptual modeling) oraz model pojęciowy (conceptual model) odnoszą się do procesów myślowych, do wyobrażeń towarzyszących pracy nad oprogramowaniem. Projektant, programista, itd. muszą dokładnie wyobrazić sobie problem oraz metodę jego rozwiązania. Zasadnicze procesy tworzenia oprogramowania zachodzą więc w ludzkim umyśle i nie są związane z jakimkolwiek językiem programowania czy jakimkolwiek narzędziem w ogóle. Modelowanie pojęciowe może być (i powinno być) wspomagane przez środki wzmacniające ludzką pamięć i wyobraźnię, służące do opisu odwzorowywanej rzeczywistości w postaci: struktur danych, operacji na danych czy zachodzących procesów.

5 E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 5 marzec 2001 Metodyka (1) Metodyka (metodologia) – w inżynierii oprogramowania – jest zestawem pojęć, oznaczeń, języków, modeli, diagramów, technik i sposobów postępowania wspierających proces konstruowania systemu (realizacji projektu). Metodyka jest wykorzystywana zarówno do projektowania pojęciowego, jak i logicznego czy fizycznego. role uczestników projektu, scenariusze postępowania, reguły przechodzenia do następnej fazy, modele, które powinny być wytworzone, dokumentację, która powinna powstać, język/notację, którą należy używać. Metodyka ustala fazy realizacji projektu, a ponadto dla każdej z faz projektu wyznacza:

6 E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 6 marzec 2001 Metodyka (2) Dana notacja może być wykorzystywana w wielu metodykach. Szczególne znaczenie mają notacje graficzne, ich zalety potwierdzają badania psychologiczne. Inżynieria oprogramowania wzoruje się tu na innych dziedzinach techniki, takich jak np. elektronika czy mechanika. Rodzaje notacji: tekstowa specyfikacje - ustrukturalizowany zapis tekstowy i numeryczny notacje graficzne Notacja, czyli zbiór oznaczeń, jest wykorzystywana do dokumentowania wyników poszczególnych faz projektu – pośrednich i końcowych. Notacja służy jako środek wspomagający ludzką pamięć i wyobraźnię, a także jako środek ułatwiający komunikację zarówno między członkami zespołu projektowego, jak i między zespołem projektowym a klientem.

7 E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 7 marzec 2001 Język do modelowania Język do modelowania, jak każdy inny język, oprócz notacji, semantyki i składni posiada jeszcze jeden ważny aspekt: pragmatykę. Semantyka określa, co należy rozumieć pod przyjętymi oznaczeniami (notacją). Pragmatyka określa, w jaki sposób należy używać przyjętych oznaczeń, jak do konkretnej sytuacji dopasować pewien wzorzec notacyjny – zgodnie z intencją autorów języka. Składnia określa, jak wolno łączyć ze sobą przyjęte oznaczenia. Język niewiele znaczy bez znajomości sposobów wykorzystywania go w procesie wytwarzania produktu programistycznego. W metodykach pragmatyka stosowanego języka jest sprawą podstawową. Jest ona zazwyczaj trudna do objaśnienia: można to robić wyłącznie na przykładach przypominających realne sytuacje. Niestety, realne sytuacje są zazwyczaj bardzo skomplikowane, czego efektem jest pewien infantylizm przykładów zamieszczanych w podręcznikach.

8 E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 8 marzec 2001 RATIONAL SOFTWARE CORPORATION UML , styczeń wrzesień 1996 UML 1.0, styczeń 1997, przesłany do OMG UML 1.1, koniec 1997, zatwierdzony jako składnik standardu OMG UML 1.3, kwiecień 1999 UML 1.4 listopad 2000 UML UML 1.6 ? UML 2.0 ? Połączone siły trzech znanych metodologów oprogramowania: Grady Booch Ivar Jacobson James Rumbaugh (dokumentacja on line) Unified Modeling Language (UML)

9 E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 9 marzec 2001 UML: Krótka charakterystyka (1) Notacja UML, która opiera się o podstawowe pojęcia obiektowości może być wykorzystana w dowolnej metodyce. Pojęcia UML, wynikające z doświadczenia jej twórców, mają w założeniu przykrywać większość istotnych aspektów modelowanych systemów. UML jest składową standardu OMG (CORBA). Nie wszyscy są zachwyceni UML. Niektórzy specjaliści uważają go za twór przereklamowany: niestabilny, zbyt ciężki, źle zdefiniowany. UML ma konkurentów w postaci metodyki i notacji OPEN, design by contracts oraz innych. UML cieszy się aktualnie bardzo dużą popularnością. Prawdopodobnie przez wiele najbliższych lat będzie dominował w obszarze analizy i projektowania. UML jest metodyką projektowania ? Definicja podana przez Rational: "The Unified Modeling Language (UML) is a language for specifying, constructing, visualizing, and documenting the artifacts of a software-intensive system."

10 E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 10 marzec 2001 UML: Krótka charakterystyka (2) OOSE (Jacobson): dobrze podchodzi do kwestii modelowania użytkowników i cyklu życiowego systemu. Nie przykrywa dokładnie ani aspektu modelowania dziedziny przedmiotowej ani aspektu implementacji (konstrukcji). OMT (Rumbaugh): dobry do modelowania dziedziny przedmiotowej. Nie przykrywa dostatecznie dokładnie ani aspektu użytkowników systemu, ani aspektu implementacji (konstrukcji). OOAD (Booch): zajmuje się kwestią modelowania dziedziny przedmiotowej, implementacją (konstrukcją) i związkami ze środowiskiem implementacji. Nie przykrywa dostatecznie dobrze fazy rozpoznania i analizy wymagań użytkowników. Wady i zalety metodyk, których autorami są twórcy UML: Istnieje wiele aspektów projektowania systemów, które nie zostały przykryte przez żadną z wyżej wymienionych metodyk, np. włączenie prototypowania w cykl życiowy, rozproszenie i komponenty, przystosowanie notacji do preferencji projektantów i inne. Celem UML jest przykrycie również tych aspektów.

11 E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 11 marzec 2001 Diagramy definiowane w UML Diagramy przypadków użycia (use case) Diagramy klas Diagramy dynamiczne (behavior): Diagramy stanów Diagramy aktywności Diagramy interakcji: Diagramy sekwencji Diagramy współpracy (collaboration) Diagramy implementacyjne: Diagramy komponentów Diagramy wdrożeniowe (deployment) Diagramy te zapewniają uzyskanie wielu perspektyw projektowanego systemu w trakcie jego budowy. Diagramy pakietów

12 E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 12 marzec 2001 Model a diagram; modele w UML (1) Model: pewna abstrakcja projektowanego systemu, widziana z określonej perspektywy, na określonym poziomie szczegółowości. Diagram: środek służący do opisu modelu. Dany model może być opisany przy pomocy wielu diagramów. Dany element modelu może pojawiać się na wielu diagramach jednego modelu. Dwa najważniejsze modele w UML, wykorzystywane w fazie analizy, to: Model przypadków użycia opisujący system widziany z perspektywy jego przyszłych użytkowników (za pomocą diagramów przypadków użycia). Model obiektowy przedstawiający statyczną budowę (strukturę systemu) za pomocą diagramów klas i diagramów obiektów. Diagram klas może zawierać obiekty. Diagram obiektów nie zawiera klas, ale wyłącznie obiekty. Głównym zadaniem pomocniczego modelu dynamicznego (zachowań) jest wypełnienie diagramu klas metodami wynikłymi z analizy zachowania systemu w trakcie wykonywania zadań, gdzie zadaniem może być np. realizacja przypadku użycia czy też jednego konkretnego scenariusza danego przypadku użycia.

13 E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 13 marzec 2001 Model a diagram; modele w UML (2) Główny obszar działania ModelDiagramy Podstawowe pojęcia struktura model obiektowy diagram klas diagram obiektów model przypadków użycia diagramy przypadków użycia klasa, obiekt, asocjacja, generalizacja, zależność, realizacja, interface aktor, przypadek użycia, «include», «extend», generalizacja model implementacji diagramy komponentów diagramy wdrożeniowe komponent, interface, zależność, realizacja węzeł, komponent, zależność, lokacja dynamikamodel dynamicznydiagramy stanu stan, zdarzenie, przejście, akcja, aktywność

14 E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 14 marzec 2001 Model a diagram; modele w UML (3) Główny obszar działania ModelDiagramy Podstawowe pojęcia dynamika, c.d. model dynamiczny, c.d. diagramy aktywności diagramy interakcji stan, aktywność, fork, join, romb decyzyjny interakcja, współpraca, komunikat, aktywacja model zarządzania diagramy pakietów pakiet, podsystem rozszerzalnośćwszystkie modelewszystkie diagramy stereotyp, własność etykietowana, ograniczenie zarządzanie

15 E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 15 marzec 2001 Stereotypy (1) Stereotypy stanowią pierwszy z trzech mechanizmów rozszerzalności UML. Jak każdy mechanizm rozszerzalności, dają możliwość definiowania nowych elementów, co wspomaga przystosowanie UML do modelowania specyficznych procesów, do specyficznych preferencji użytkownika czy też pozwala na uszczegóławianie semantyki modelu: Stereotypy są wyrażeniami językowymi umożliwiającymi metaklasyfikację elementów modelu. Istnieje lista stereotypów dla każdego rodzaju elementów modelu w UML. Element modelu może mieć co najwyżej jeden stereotyp (?). Są stereotypy predefiniowane, ale użytkownicy mogą też definiować własne stereotypy. Stereotypy mogą mieć implikacje semantyczne (podobnie jak ograniczenia). Notacja: « nazwa stereotypu » lub ikona.

16 E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 16 marzec 2001 Stereotypy (2) Przykłady stereotypów: P1P2 «include» P3 P4 «extend» «aktor» Klient jest równoważne

17 E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 17 marzec 2001 Wartości etykietowane Wartości etykietowane stanowią kolejny mechanizm rozszerzalności UML. Pojedynczą wartość etykietowaną stanowi ciąg znaków o postaci: słowo kluczowe = wartość. Listę wartości etykietowanych (oddzielonych przecinkami) umieszcza się w {}. Dowolny element modelu może być skojarzony z listą wartości etykietowanych. {autor = Jan Nowak, termin zakończenia = 31 Maja 1999, status = analiza} Przykład listy wartości etykietowanych: W ten sposób można na diagramach umieścić dowolną dodatkową informację. Zakłada się, że narzędzia CASE umożliwią odszukanie odpowiedniego elementu na podstawie słowa kluczowego i skojarzonej z nim wartości. Uwaga! Wartości etykietowane służą raczej do opisu pojedynczego elementu modelu niż do metaklasyfikcji (patrz: stereotypy).


Pobierz ppt "E. Stemposz, Inżynieria Oprogramowania, Wykład 3, Slajd 1 marzec 2001 Projektowanie systemów informacyjnych Ewa Stemposz, Kazimierz Subieta Instytut Podstaw."

Podobne prezentacje


Reklamy Google