Analiza i projektowanie obiektowe
Procesy budowy systemów informatycznych Fazy procesu budowy SI Specyfikacja wymagań o Analiza dziedziny modelowanie podstawowych pojęć i terminów Analiza systemowa modelowanie problemu Projektowanie modelowanie rozwiązania Programowanie budowa modelu działającego na komputerze Testowanie Integracja Wdrożenie Utrzymanie
Analiza systemowa Proje ektowanie Celem analizy jest j zbudowanie modelu składających się na dziedzinę wdrożen nia. dla pojęć Świat rzeczywisty Model Celem fazy projektowania jest zdefiniowanie pojęć niezbędnych dla implementacji budowanego systemu informatycznego. Cechy modeli: Opisowy Formalny Graficzny
Analiza systemowa Narzędzie pracy analityków i projektantów wspomagające opracowywania rozwiązań Wizualizacja wyników pracy dla zarządzania i komunikacji z innymi analitykami Współpraca z przyszłymi użytkownikami systemu informatycznego Podstawa do implementacji Dokumentowanie projektu Projektowanie modułowe Wirth 1971 Analiza strukturalna Constantine i Yourdon 1975 DeMarco 1978 Mellor, Ward Model związków-encji Chen 1976 Analiza obiektowa Shlaher, Mellor 1988 Coad, Yourdon 1991 Booch 1991 Rumbaugh, Blaha 1991
Metodyki i analizy obiektowe Świat jest modelowany jako zbiór klas i obiektów oraz związków między klasami i związków między obiektami. Diagram klas umożliwia jednoczesne modelowanie struktur danych i funkcjonalności w przeciwieństwie do klasycznej analizy funkcjonalnej diagramy: hierarchii funkcji, encji-związków, przepływów danych. Wielość modeli, notacji i metodyk obiektowych: Karty CRC Metoda Couda-Yourdona OOA/OOD Object Modeling Technique OMT Rumbaugh Object-Oriented Software Engineering OOSE lub Objectory (Object Factory) Jacobson Object-Oriented Design & Analyze OOAD Booch Język UML OMT Object Modeling Technique Rumbaugh Objectory Jacobson OODA Object Oriented Design & Analyze Booch UML Unified Modeling Language
Skąd się biorą klasy? Identyfikacja klas Klasy encyjne powstają w fazie analizy dziedziny i analizy systemowej. Służą do opisu dziedziny zastosowania. Przykłady klas encyjnych firma ubezpieczeniowa: Klient Ubezpieczenie Szkoda Odszkodowanie, Klasy interfejsu i komunikacyjne powstają w fazie projektowania. Służą do opisu implementacji systemu informatycznego. Przykłady klas interfejsu i komunikacji: Okno Przycisk Błąd
Karty CRC Class Responsibilities and Collaborators Zostały wprowadzone przez Kenta Becka i Warda Cunnighama i opisane w artykule A Laboratory for Teaching Object-Oriented Thinking przedstawionym na konferencji OOPSLA 89. Narzędzie wykorzystywane podczas burzy mózgów do identyfikowania klas. Bazując na znanych wymaganiach za pomocą kart CRC modeluje się behawioralne własności budowanego systemu informatycznego. Class name Superclasses Subclasses Responsibilities Collaborators Author
Karty CRC Klient Składa zamówienia Opłaca faktury Zna swoją nazwę Zna swój adres Zamówienie Faktura Zamówienie Zna numer Zna datę złożenia Zna wartość Zna pozycje Zna klienta Klient Faktura Pozycja
Standard języka UML Historia wersji Wersje opublikowane przez RSC i UML Partners 0.9 1995 1.0 Styczeń 1997 Wersje UML opublikowane przez OMG Wersja Data publikacji URL 1.3 Marzec 2000 http://www.omg.org/spec/uml/1.3 1.4 Wrzesień 2001 http://www.omg.org/spec/uml/1.4 1.4.2 Lipiec 2004 zobacz: ISO/IEC 19501 1.5 Marzec 2003 http://www.omg.org/spec/uml/1.5 2.0 Lipiec 2005 http://www.omg.org/spec/uml/2.0 2.1.1 Sierpień 2007 http://www.omg.org/spec/uml/2.1.1 2.1.2 Listopad 2007 http://www.omg.org/spec/uml/2.1.2 2.2 Luty 2009 http://www.omg.org/spec/uml/2.2/ 2,3 Maj 2010 Wersje UML opublikowane przez ISO Numer Data Wersja URL ISO/IEC 19501 Styczeń 2005 1.4.2 http://www.omg.org/spec/uml/iso/19501/pdf
UML - podstawowe diagramy Strukturalne Diagram klas Diagram obiektów Diagram struktury złożonej Diagram komponentów Diagram pakietów Diagram rozmieszczenia Dynamiczne Diagram przypadków użycia Diagram współdziałania Diagram stanów Diagram działania
Diagram klas Definicja diagramu klas Diagram klas jest graficzną prezentacją statycznej perspektywy kolekcji klas, typów danych i interfejsów oraz łączących je związków. Specyfikacja klas obejmuje elementy strukturalne i funkcjonalne, ale ich dynamika jest opisana poprzez inne diagramy. Zastosowanie diagramów klas specyfikacja wymagań analiza projekt generalizacja Definicja diagramu obiektów Diagram obiektów jest szczególnym przypadkiem diagramu klas. Diagram obiektów przedstawia obiekty i łączące je związki w konkretnym punkcie czasu.
Specyfikacja klasy Klasa jest abstrakcyjną reprezentacją zbioru podobnych obiektów świata rzeczywistego lub implementacji. Pojęcie klasy integruje strukturalne i behawioralne własności obiektów świata rzeczywistego. Elementy specyfikacji klasy: Nazwa służy do przypisania semantycznej informacji o klasie Cechy (properties) umożliwiają przechowywanie informacji o obiekcie: pracownik nazywa się Nowak, pracownik jest prezesem Operacje (operations) definiują funkcjonalność obiektów: pracownika można awansować, pracownika można zatrudnić imię nazwisko etat płaca zatrudnij() awansuj() przenieś() zwolnij() zmieńdane() Dopuszczalna jest również notacja niepełna:
Elementy specyfikacji klasy Nazwy proste i ścieżkowe Kadry:: Klasa abstrakcyjna - to klasa o niekompletnej implementacji Liczba wystąpień klasy Cylinder 8 Stereotypy umożliwiają rozszerzenie elementów języka UML o pojęcia wprowadzone przez użytkowników <<kolekcja>> Stos Stos Etykiety {wersja 5.1 napisana przez: M.Tarzana} Właściwości opisują dodatkową semantykę klas {leaf}
Specyfikacja klasy Dostępność cech i operacji + publiczne opisują funkcjonalność klasy (ADT) prywatne są częścią implementacji klasy # chronione - są częścią implementacji klasy dostępną w klasach pochodnych Zasięg cech i operacji obiektowe definiują własności obiektów klasowe definiują własności klas Operacje abstrakcyjne nie mają implementacji Niepełna specyfikacja klasy Typy cech i operacji <<dane personalne>> # imię # nazwisko <<dane pracownicze>> # etat - płaca... + zatrudnij() + awansuj() + przenieś() + zwolnij() + zmieńdane() + policzów() niepełna specyfikacja operacja abstrakcyjna operacja klasowa
Specyfikacja cech klasy Składnia [dostępność] nazwa [[liczebność]] [:typ] [=wartość początkowa] [{własności}] Predefiniowane własności cech: changeable modyfikowalne addonly dla cech wielowartościowych możliwe jedynie dodawanie nowych elementów frozen po inicjacji - niemodyfikowalne Przykłady: + imię :String - identyfikator [1] :Integer {frozen} # operacje [0..*] :Operacja {addonly} # dataoperacji [0..1] = '1-1-2000'
Specyfikacja operacji klasy Składnia [dostępność] nazwa [(parametry)] [:typ wyniku] [{własności}] Specyfikacja parametrów [tryb] nazwa : typ [=wartość domyślna] tryby: {IN, OUT, INOUT} Predefiniowane własności operacji: isquery zapytanie, nie zmienia stanu systemu sequential operacja nie synchronizuje współbieżności wykonania guarded operacja synchronizuje współbieżność wykonania przez sekwencyjne wykonanie jej współbieżnych wywołań concurrent operacja synchronizuje współbieżność wykonania, gwarantując atomowość jej współbieżnych wywołań Przykłady: + danepersonalne() :String {isquery} + dajpodwyżkę (IN procent:integer) + policzów () :Integer
Kompletny przykład specyfikacji klasy SystemZarządzania::Transakcja # identyfikator : Integer {frozen} # operacje [*] : Operacja {addonly} # blokady [*] : Blokada {addonly} # status : Stan = aktywna {changeable} << konstruktor >> + begin(in id : Integer) << destruktor >> + commit() : Boolean + rollback() << query >> # status() : Boolean << przetwarzanie >> - lock(blokada : Blokada) {concurrent} - akcja(in a : Operacje) {concurrent}
Związki między obiektami W świecie rzeczywistym obiekty są połączone różnymi związkami. Kowalski jest zatrudniony w Firma X jest podwładnym jest mężem Tarzan
Związki między klasami Związki między klasami są abstrakcyjnym opisem związków łączących wystąpienia klas Nazwa powiązania zatrudnia Firma Kierunek czytania nazwy zatrudnia Firma Role powiązania szef podwładny Typ powiązania unarny binarny, n-arny wymaga Projekt Aparatura jest wykorzystywana dostarcza Dostawca Krotność min max Zamówienie 1 zawiera 1..* Pozycja Opcjonalność powiązania 1..* uczestniczy 0..* Projekt
Siła powiązania Szczególnym przypadkiem powiązania jest agregacja, która opisuje relację zawierania się obiektów. Szczególnym przypadkiem agregacji jest kompozycja. Obejmuje ona dodatkową semantykę: wyłączności i zależności obiektów składowych. Powiązanie Agregacja Kompozycja Wyłączność oznacza, że obiekt składowy może należeć do tylko jednego obiektu złożonego. Zależność oznacza, że obiekt składowy może istnieć tylko jako część obiektu złożonego. Przykład List Agregacja * 1 1 Adres Treść Kompozycja Samolot 1 należydo 2,4 Skrzydło
Własności powiązań dotyczy Nawigacja Zamówienie Towar * 1..* zawiera Dostępność _-bok Wielokąt Odcinek 0..1 3..* Kwalifikacja Osoba typdokumentu posiada 1 0..1 Dowód Tożsamości Zawężenie interfejsu 0..1 szef:ikierownik 0..* podwładny:i Klasa powiązania Firma Etat odkiedy pensja 0..* 1..* Osoba zatrudnia jest zatrudniony
Własności powiązań Własności: xor dwa typy powiązań są rozłączne ordered zbiór obiektów na jednym końcu powiązania jest uporządkowany frozen - powiązania między obiektami nie mogą być modyfikowane addonly - powiązania między obiektami mogą być jedynie dodawane changeable powiązania między obiektami mogą być wstawiane, modyfikowane i usuwane Własności definiowane za pomocą stereotypów i etykiet szef * * zatrudniony {podzbiór} 1 Oddział 0..1 podwładny 1 kieruje {.zatrudniony =.szef.zatrudniony } 1
Związki generalizacji/specjalizacji Generalizacja/specjalizacja jest szczególnym rodzajem związków między klasami. Generalizacja jest abstrakcją, która pozwala pominąć mniej istotne cechy klas. Generalizacja umożliwia wyprowadzenie wspólnych cech zbioru podobnych klas. Specjalizacja (dziedziczenie) uszczegóławia zbiór cech bardziej ogólnych klas. Klasa bardziej ogólna jest nazywana nadklasą lub klasą bazową dla podklasy lub klasy pochodnej. + imię + nazwisko + etat + płaca + nazwa_związku + składka_na_związek + samochód_służbowy + zatrudnij() + awansuj() + przenieś() + zapłać_składkę() + zmień_samochód()? Kierownik + imię + nazwisko + etat + płaca + samochód + zatrudnij() + awansuj() + przenieś() + zmień_samochód() Związkowiec + imię + nazwisko + etat + płaca + nazwa_związku + składka_na_związek + zatrudnij() + awansuj() + przenieś() + zapłać_składkę()
Przykłady związków generalizacji Klasa reprezentuje wspólne cechy poszczególnych grup pracowników. imię nazwisko etat {płaca Kierownik Związkowiec Sekretarka Definicje podklas zawierają tylko różnice w stosunku do swoich nadklas. Kręgowiec płetwy skrzela Ssak Ptak Gad Płaz Ryba Generalizacja może dotyczyć również związków zawiera Lista Element Lista dwukierunkowa zawiera Element dwukierunkowy
Generalizacja jako hierarchia zbiorów obiektów Semantyka generalizacji może być opisana dodatkowo przez kilka predefiniowanych własności opisujących zależności między zbiorami wystąpień klas tworzących hierarchię generalizacji. disjoint żaden obiekt nie może być wystąpieniem jednocześnie dwóch podklas overlapping obiekty mogą być wystąpieniami dwóch podklas complete każde wystąpienie nadklasy musi być jednocześnie wystąpieniem jednej z podklas incomplete mogą istnieć wystąpienia nadklas, które nie są wystąpieniami żadnej z podklas {overlapping, incomplete} Młody- Związkowiec Sekretarka {disjoint, complete} Kręgowiec Ssak Ptak Gad Płaz Ryba
Przykładowy diagram klas +tytuł 1 Student {persistance} +nr_indeksu {key} +nazwisko +zapisz_na(kierunek) +przenieś_na(kierunek) +zalicz(przedmiot, ocena) Wykładowca {persistance} {persistance} +nazwisko +stanowisko +płaca ma_adres_domowy +zatrudnij(stanowisko) +zwolnij() 1 1 Adres +kod_pocztowy +miasto +ulica +nr_domu +nr_mieszkania 1..* studiuje_na 1 prowadzi 1..* 0..* poprzedza Kierunek {persistance} +nazwa {key} 1..* obejmuje 1..* Przedmiot {persistance} +nazwa {key} +literatura[1..*] 0..* administracyjny {persistance} +premia
Metodyka konstrukcji diagramów klas Każda klas powinna być starannie wydzieloną abstrakcją pochodzącą ze słownictwa dziedziny danego problemu lub jego rozwiązania. Powinna ona obejmować elementy strukturalne i behawioralne. Klasa powinna obejmować mały i dobrze określony zbiór zobowiązań. Rozważ możliwości: podziału klas o zbyt dużej liczbie zobowiązań, scalenia klas o zbyt małej liczbie zobowiązań lub przeniesienia zobowiązań między klasami. Klasa powinna być spójna i luźno związana z innymi klasami; w tym celu przeanalizuj diagramy współpracy klas. Definicja klasy powinna wyraźnie oddzielać specyfikację od implementacji. Powiązane klasy powinny znaleźć się na jednym diagramie klas. Na danym diagramie klasa powinna mieć ujawnione jedynie te właściwości, które są potrzebne do jej zrozumienia w danym kontekście.
Definicja klasy musi być jednoznaczna, aby wykluczyć nieporozumienia co do jej znaczenia. W tym celu należy: - określić znaczenie klasy jako całości za pomocą tekstu umieszczonego w notatce <<semantics>> - pogrupować operacje i cechy w kategorie - określić znaczenia każdej z operacji za pomocą tekstu lub kodu źródłowego programu umieszczonego w notatce - opracować maszyny stanów dla wystąpień klasy - zdefiniować warunki początkowe i końcowe dla wszystkich operacji oraz niezmiennik klasy; w tym celu można wykorzystać język definicji więzów integralności OCL
Diagramy obiektów Graficzna prezentacja obiektów: obiekty anonimowe, nazwane, zbiory obiektów i obiekty bezklasowe p1:prostokąt p2:prostokąt :Prostokąt :Prostokąt :Prostokąt :Prostokąt Własności obiektów: wartości atrybutów, stan obiektu, związki między obiektami <<isinstanceof>> x : float y : float Punkt przesuń (Wektor) 4 1 Prostokąt powierzchnia() p1:punkt x = 4.5 y = 12 p3:punkt [bieżący] p4:prostokąt p2:punkt x = 2.5 y = 8
Diagramy współpracy Diagram współpracy jest zestawem wierzchołków i krawędzi reprezentujący związki strukturalne między obiektami wysyłającymi i odbierającymi komunikaty. Wyróżnia się pięć stereotypowych powiązań między obiektami umożliwiających przesłanie komunikatu: association przez powiązanie klas self ten sam obiekt global obiekt globalny local obiekt w zasięgu lokalnym parameter parametr wejściowy #nazwisko... +awansuj(e : Etat) +podwyżka(p:float)... 1.. * 1 Firma pracuje w zatrudnia z: ZUS <<global>> prześlijskładki(suma) p : awansuj("prezes") <<association>> f : Firma
Diagramy współpracy Diagram współpracy umożliwia również określanie kolejności wysyłania komunikatów 2 : dodajstudenta() 1 : <<create>> 3 : zarejestruj() r : Rejestrator 3.1 : odczytajplan() {global} : Szkoła 3.2 : dodaj(s) s : Student zarejestrowany=false {self} s : Student zarejestrowany=true 3.4 : <<become>> 3.3 : dodaj(s) w1 : Wykład w2 : Wykład
Literatura Rozdział nr 6 (strony 265 358): Analiza obiektowa i projektowanie obiektowe w Metody obiektowe w teorii i praktyce, Iana Grahama Standard UML 1.4.2 http://www.omg.org/spec/uml/iso/19501/pdf Standard UML 2.1.2 http://www.omg.org/spec/uml/2.1.2