SPIS TRECI 1. MODELOWANIE OBIEKTOWE .............................................................................. 2 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.

10 1.11 2. Podstawowe informacje............................................................................ 2 Klasy i obiekty ........................................................................................ 3 Interfejs i implementacja.......................................................................... 6 Hermetyzacja (enkapsulacja) .................................................................... 7 Dziedziczenie.......................................................................................... 8 Polimorfizm ............................................................................................ 9 Asocjacja ............................................................................................... 9 Liczno (krotno)................................................................................ 10 Agregacja i kompozycja ......................................................................... 10 Zaleno............................................................................................. 11 Delegacja............................................................................................. 12

DIAGRAMY W UML .......................................................................................... 13 2.1 2.2 2.3 2.4 2.5 2.6 2.7 Klasy i diagramy klas ............................................................................. 13 Przypadki uycia i diagramy przypadkw uycia......................................... 19 Pakiety i diagramy pakietw ................................................................... 21 Komponenty i diagramy komponentw ..................................................... 23 Diagramy sekwencji............................................................................... 26 Diagramy czynnoci............................................................................... 35 Podsumowanie notacji UML..................................................................... 41

3.

PROJEKTOWANIE OPROGRAMOWANIA............................................................... 46 3.1 3.2 3.3 Fazy tworzenia oprogramowania.............................................................. 46 Architektura oprogramowania ................................................................. 49 Inne kwestie zwizane z wytwarzaniem oprogramowania ............................ 50

1. MODELOWANIE OBIEKTOWE 1.1 Podstawowe informacje Paradygmat obiektowy System zbir unikatowych obiektw (spoeczno obiektw). Obiekt w czasie swego cyklu ycia: jest nonikiem informacji (atrybuty=dane), moe wykona okrelone czynnoci (metody=przetwarzanie), moe komunikowa si z innymi obiektami, Podstawowym celem jest odzwierciedlenie struktury obiektw i relacji zachodzcych w wiecie realnym. Modelowanie obiektowe Modelowanie polega midzy innymi na zidentyfikowaniu bytw istotnych z pewnego szczeglnego punktu widzenia. Byty te skadaj si na sownictwo systemu, ktry jest modelowany. Kady byt znaczco rni si od pozostaych ma swj wasny zestaw waciwoci. Klasa to opis zbioru obiektw o tych samych atrybutach, zwizkach i znaczeniu. Jej symbolem graficznym w UML jest prostokt. Atrybut to nazwana waciwo klasy. Klasa moe mie dowoln liczb atrybutw lub nie mie ich wcale. Atrybut reprezentuje waciwo pewnego modelowanego bytu, ktra jest okrelona dla wszystkich jego wystpie. Operacja to implementacja pewnej usugi, ktrej wykonania mona zada od kadego obiektu klasy. Jest to abstrakcja, tego co mona zrobi z kadym obiektem tej klasy. Podstawowe koncepcje obiektowoci abstrakcja odfiltrowanie atrybutw i operacji nieistotnych, enkapsulacja (hermetyzacja) ukrycie nadmiernego poziomu szczegowoci, dziedziczenie generalizacja relacja hierarchiczna, oszczdno nakadw modelowania, polimorfizm wielo form operacji dla dziedziczonych klas wirtualny mechanizm wywoywania funkcji, naturalny system wyraania czynnoci, zmniejszenie nakadw programowania, komunikacja synchronizacja zdarze, wymiana danych, wspopraca midzy obiektami, asocjacja (powizanie) relacja wica klasy (obiekty), agregacja powizanie wielu komponentow w jedn cao, agregacja cakowita (kompozycja) komponenty skadowe istniej tylko jako czci caoci. Cele modelowania 1. dekompozycja 2. atwiejsze wyobraenie systemu 3. specyfikacja struktury i zachowania 4. dokumentacja decyzji podjtych w trakcie realizacji Cztery zasady modelowania 1. wybrany model determinuje rozwizanie 2. modelowa mona na rnych poziomach szczegowoci 3. najlepsze modele odpowiadaj rzeczywistoci 4. aden model nie jest wystarczajcy Jak modelowa? - Naley odnale obiekty w systemie i jego otoczeniu - Opisa ich struktur - Dokona klasyfikacji obiektw

- Opisa struktur powiza midzy klasami - Opisa dynamik systemu 10 najczciej popenianych bdw w modelowaniu obiektowym 1. Rozdzielanie atrybutw i operacji. 2. Uycie zbyt maej lub zbyt duej iloci diagramw np. wykorzystywanie tylko diagramw klas lub uywanie diagramu klas do innych celw ni ukazania statycznej struktury programu (np. do reprezentowania interakcji lub przepywu danych). 3. Ukazywanie zbyt duej iloci szczegw (np. zbyt rozbudowany diagram sekwencji). Zawierania zbyt duej iloci szczegw mona unikn dziki stwierdzeniu, czy istnieje ryzyko projektowe w przypadku niepokazania danego detalu na diagramie. Jeeli nie, to nie trzeba umieszcza tego szczegu. 4. Uywanie niejasnych sformuowa (np. w nazwach klas lub metod). 5. Wielokrotne definiowanie tej samej rzeczy zdarza si to czsto, gdy okazuje si, e np. dwie klasy maj praktycznie takie same operacje, atrybuty i asocjacje. 6. czenie wszystkiego razem np. na diagramie klas. Znacznie utrudnia to zrozumienie oraz pniejsz konserwacj, gdy kade utworzenie asocjacji powoduje zaleno pomidzy klasami i gdy jedna z nich si zmieni, druga rwnie moe wymaga zmiany. Aby unikn takiej sytuacji, trzeba okrela, ktre asocjacje s faktycznie wymagane, a ktre istniej tylko po to, by przekaza dane z jednej klasy do drugiej. 7. Tworzenie zbyt duej iloci przypadkw uycia bardzo czsto jest to wynikiem CRUD (Create, Read, Update, Delete). Jako, e tego typu zachowania dotycz kadej klasy, prowadzi to do olbrzymiej iloci przypadkw uycia. Jeeli zostanie rozpoznane CRUD, wwczas naley zczy te przypadki uycia w jeden i nazwa go np. Maintain. Jednake gdy poszczeglne zachowania CRUD reprezentuj rne cele uytkownika, to warto je opisywa osobno. Aby zidentyfikowa CRUD, naley sprawdzi, czy: - kilka przypadkw uycia skupia si tylko na jednej klasie - przypadki uycia dotycz wzgldnie mao wanej klasy - nazwy przypadkw uycia zawieraj sowa Create, Read, Update, Delete - kady przypadek uycia jest prosty i atwy w opisaniu - kilka przypadkw uycia zawiera przypadek uycia typu Read Naley jednoczenie pamita, by nie popa w skrajno i nie tworzy jednego przypadku uycia, ktry bdzie opisywa wszystko. Objawia si to zwykle zbyt du iloci skomplikowanych alternatywnych scenariuszy. 8. Kompletne ukoczenie jednego diagramu przed zajciem si kolejnymi (np. skupienie si na wszystkich moliwych przypadkach uycia i kompletnym opisaniu ich z uwzgldnieniem wszystkich alternatywnych scenariuszy). Praca nad jednym diagramem pomaga w tworzeniu innych diagramw, wic warto rozway rwnolege tworzenie kilku diagramw np. prbowa tworzy jednoczenie diagram przypadkw uycia i diagram klas. 9. Cykle na diagramie klas mamy z nimi do czynienia, gdy s niespjnoci w licznoci (krotnoci). Cyklem jest sytuacja, gdy cieka asocjacji zaczyna si od pewnej klasy, przechodzi przez szereg powizanych klas i wraca do klasy pocztkowej. Aby wykry takie niespjnoci, naley pody ciekami asocjacji w obu kierunkach i sprawdzi, czy w obu przypadkach wnioski dotyczce licznoci si pokrywaj. 10. Niesuchanie uytkownika naley sucha uwanie uytkownika, przekada jego terminologi na klasy, przekada wymagane przez niego interakcje na przypadki uycia i diagramy sekwencji, a nastpnie projektowa i kodowa na bazie tego, co powiedzia uytkownik. 1.2 Klasy i obiekty Obiekt: reprezentacja konkretnego elementu wiata, posiadajca pewne cechy i oferujca pewne usugi Klasa: zbir obiektw podobnych lub o wsplnych cechach Operacje to usugi oferowane przez klas argumenty i typ wartoci interfejs i deklaracja a definicja operacje statyczne: ich zakres obejmuje klas a nie obiekt

operacje abstrakcyjne: posiadaj tylko deklaracj operacji, definicje s w klasach potomnych

Atrybuty to informacje zawarte w klasie/obiekcie cechy klasy/obiektu relacje z innymi klasami/obiektami atrybuty statyczne atrybuty wywiedzione typy atrybutw Jeli atrybut jest wielowartociowy, to dane przez niego reprezentowane s kolekcj. Cechy wielowartociowe wymagaj innego typu interfejsu ni jednowartociowe. W wikszoci przypadkw cechom wielowartociowym nie nadaje si wartoci za pomoc operatora przypisania, lecz uywa si w tym celu metod dodajcych i usuwajcych wartoci. Powinno si unika klas niebdcych niczym wicej, jak kolekcj atrybutw i metod dostpowych. Projektowanie obiektowe dotyczy obiektw charakteryzujcych si bogatym zachowaniem, wic nie powinny si one ogranicza zaledwie do dostarczania danych do innych obiektw. Jeli czsto dobieramy jakie dane za pomoc metod dostpowych, to jest to znak, e pewne zachowania powinny zosta przeniesione do obiektu majcego te dane. Kady obiekt jest tworzony osobno i zostaje mu przydzielone osobne miejsce w pamici. Tym niemniej niektre atrybuty i metody, jeli dobrze zaprojektowane, mog by wspdzielone przez wszystkie obiekty nalece do danej klasy. Dziki temu wszystkie te obiekty korzystaj z tego samego obszaru pamici przydzielonego wspdzielonym skadowym. 3 rodzaje atrybutw: lokalne, obiektowe i klasowe Atrybut lokalny jest wasnoci metody. Dostp do niego jest moliwy tylko wewntrze metody, czyli tylko w zakresie tej metody, zaznaczonym klamrami {}. Wywoanie metody powoduje utworzenie kopii atrybutu, za gdy metoda zakoczy dziaanie, kopia ta zostaje usunita. Atrybut obiektowy jest dostpny dla kilku metod w obrbie obiektu. Musi on zosta zadeklarowany poza zakresami metod, ale w zakresie klasy. Kada z metod danej klasy ma wasny egzemplarz takiego atrybutu (zmiana wartoci tego atrybuty w jednej z metod nie wpywa na warto atrybutu w drugiej z metod). Atrybut klasowy jest wspdzielony przez wiele obiektw tej samej klasy. Aby taki by, naley go poprzedzi sowem kluczowym static. Zadeklarowanie atrybutu jako statycznego spowoduje, e zostanie mu przydzielony jeden obszar pamici, z ktrego bd korzysta wszystkie obiekty nalece do danej klasy. Wikszej globalizacji danych w programowaniu obiektowym nie da si osign. Jeeli atrybut jest statyczny (klasowy) i zostanie napisana metoda suca do zmiany jego wartoci, to kady obiekt, ktry j wywoa, zmieni warto tego atrybutu i zmiana ta bdzie widoczna we wszystkich obiektach. Chocia z konceptualnego punktu widzenia mona traktowa obiekty jako zupenie niezalene byty, ktre maj wlasne metody i atrybuty, to w rzeczywistoci nie jest tworzona osobna fizyczna kopia kadej niestatycznej metody dla kadego obiektu. Atrybuty w UML oznacza si jako statyczne poprzez podkrelenie ich. Operacje pobierajce lub ustawiajce atrybut statyczny rwnie powinny by oznaczone jako statyczne. Modelowanie sownictwa systemu Naley dy do tego aby klasy miay rwnomierny rozkad zobowiza (optymalnie jeden dobrze okrelony), w tym celu naley: - Zidentyfikowa klasy wsppracujce ze sob w celu wykonania poszczeglnych czynnoci - Okreli rodzaj zobowiza kadej klasy - Rozway zbir klas jako cao. Podzieli te klasy, ktre maj za duo zobowiza, scali te ktre maj ich zbyt mao, przenie zobowizania midzy klasami tak aby kada bya w peni samodzielna - Rozpatrzy sposoby wzajemnej kooperacji klas i porozdziela ich zobowizania tak aby adna klasa nie bya zbyt zoona ani zbyt prosta.

Sortowanie rzeczownikw i odpowiadajce im fragmenty kodu: rodzina rzeczy klasa nazwa wasna obiekt cecha, waciwo czego (np. wiek, kolor) atrybut warto lub dane (np. 27, czerwony) warto atrybutu status jakiej rzeczy (np. dorosy, nowy) stan pojawienie si, wydarzenie lub czas operacja Rzeczowniki, ktre nie kwalifikuj si jako obiekty, czsto s atrybutami, stanami, operacjami lub zdarzeniami. Jedn z najwaniejszych czynnoci, ktre naley wykona przy projektowaniu klasy, jest zidentyfikowanie jej grupy odbiorcw, czyli uytkownikw tej klasy. Konstruktory Konstruktor nie ma wartoci zwracanej. Jeli warto ta zostanie zdefiniowana, kompilator nie potraktuje takiej metody jako konstruktora. Konstruktor powinien ustawi nowo utworzony obiekt w pocztkowym bezpiecznym i stabilnym stanie (zainicjowa atrybuty odpowiednimi wartociami pocztkowymi). Jeli klasa zostanie napisana bez konstruktora, to i tak dostpny bdzie konstruktor domylny. Jednake dobrym zwyczajem programistycznym jest umieszcza w kadej klasie przynajmniej jeden konstruktor. W jzyku UML wszystkie metody poza konstruktorami musz mie zdefiniowany typ zwrotny. Przecianie metod to technika umoliwiajca utworzenie wielu wersji metody o tej samej nazwie, pod warunkiem, e kada z tych metod ma inn sygnatur (nazw metody i list parametrw). Stosuje si to rwnie do konstruktorw. W wielu jzykach programowania dostpna jest warto null, ktra reprezentuje brak wartoci. Mimo, i wydaje si to osobliwe, ustawianie wartoci atrybutu na t warto jest bardzo wan technik programistyczn. Sprawdzajc, czy zmienna ma warto null, mona okreli czy zostaa ona poprawnie zainicjowana. W ten sposb mona zaoszczdzi sobie wielu kopotw, jeli atrybut lub obiekt nie zosta waciwie zainicjowany. Klasa abstrakcyjna Klasa abstrakcyjna to taka ktra nie posiada swoich obiektw. Tworzymy j po to eby bya ona przodkiem (uoglnieniem) dla innych klas, ktrych obiekty bd wystpoway w systemie. W UML klas abstrakcyjn oznaczamy uywajc kursywy w nazwie tej klasy. Jeli metoda zostanie zdefiniowana jako abstrakcyjna, musi zosta zaimplementowana w podklasie. Klasa abstrakcyjna to taka, ktra zawiera przynajmniej jedn niezaimplementowan metod. Nie mona utworzy jej egzemplarza (obiektu tej klasy). Jednoczenie nic nie stoi na przeszkodzie, by klasa abstrakcyjna posiadaa jak implementacj; podkalsa musi implementowa we wasny sposb tylko te metody, ktre s abstrakcyjne w nadklasie. Operacje abstrakcyjne i klasy abstrakcyjne s w UMLu opisywanie kursyw. Klasy abstrakcyjne s wietn form wymuszania dziedziczenia interfejsu. Klasa asocjacyjna Jeeli okae si, e w systemie istnieje atrybut, ktrego warto zaley od wicej ni jednej klasy, potrzebna jest kolejna klasa, ktra bdzie ten atrybut zawiera. Jest to klasa asocjacyjna, na diagramie klas podpina si j przerywan lini do asocjacji, ktrej dotyczy. W UMLu ta linia przerywana oznacza zaleno (dependency). Nazwa klasy asocjacyjnej musi by taka sama, jak nazwa asocjacji. Klasa asocjacyjna wnosi dodatkowe ograniczenie moe istnie tylko jedna instancja klasy asocjacyjnej midzy dowolnymi dwoma obiektami poczonymi asocjacj. Implementowanie klas asocjacyjnych nie jest zbyt oczywiste. Warto implementowa klasy asocjacyjne tak, jakby byy one samoistnymi klasami, ale zapewni klasom poczonym przez klas asocjacyjn metody pobierajce informacje. Wie si to z tym, e trzeba rejestrowa kade utworzenie obiektu klasy asocjacyjnej przez ktrkolwiek z metod. Tworzenie klas asocjacyjnych moe sprawi, e model stanie si zbyt zawiy i przesunie implementacj w jakim nieodpowiednim kierunku.

Jeeli obiekt nie zwolni prawidowo pamici, ktr zaj w czasie dziaania, bdzie ona nie dostpna dla caego systemu tak dugo, a zostanie zamknita aplikacja, ktra ten obiekt utworzya. Zatem jeeli obiekty nie bd odpowiednio zwalnia zajmowanej przez siebie pamici, pula dostpnej pamici systemowej bdzie si kurczy (jest to zjawisko zwane memory leak). Kady obiekt powinien reprezentowa pojedyncz koncepcj i powinien wykonywa obowizki cile z nim samym zwizane. Sowo kluczowe this jest referencj do biecego obiektu. W UML obiekty s czone linkami, a klasy asocjacjami. Przy porwnywaniu i kopiowaniu obiektw naley zwrci uwag na nastpujc kwesti: zoone struktury danych mog zawiera referencje. Zwykle utworzenie kopii referencji nie powoduje skopiowania wskazywanej przez ni struktury lub obiektu. Analogicznie wyglda sprawa porwnywania obiektw zwykle porwnanie wskanika z innym wskanikiem powoduje, e porwnane zostaj tylko referencje, a nie to, na co wskazuj. Nieuywane atrybuty wskazuj, e prawdopodobnie obiekt wykonuje niepotrzebne zadania. Jeeli istnieje zestaw waciwoci, ktre s rne dla rnych obiektw, naley uy kolekcji by przechowywa je dynamicznie. Pozwoli to na usunicie duej iloci metod i uniknicie koniecznoci zmiany kodu, gdy do programu dodawane s nowe waciwoci. Kady obiekt powinien realizowa jedno zadanie (moe ono by zoone). Najprostsz metod uczynienia oprogramowania odpornym na zmiany jest upewnienie si. e kada klasa ma tylko jeden powd do zmiany. Jeli klasa ma wicej ni jeden powd do zmiany, to prawdopodobnie prbuje ona robi zbyt wiele rzeczy. Klasy powinny by otwarte na rozszerzanie, lecz zamknite na modyfikacj nie powinno si zatem dopuszcza zmian w implementacji, lecz tworzy podklasy i przesania metody. 1.3 Interfejs i implementacja Poprawnie skontruowana klasa dzieli si na interfejs i implementacj. Interfejs jest zbiorem operacji, ktore okrelaj pewien aspekt zachowania klasy i ktore s udostpniane innym klasom. Jest to klasa, ktora moe mie operacje, lecz nie moe mie atrybutow, asocjacji ani metod. Interfejs jest elementem abstrakcyjnym, nie ma zatem swoich instancji. Takie instancje maj zatem elementy, ktre realizuj interfejsy. Kada prawidowo zaprojektowana klasa ma interfejs do tworzenia obiektw i wykonywania na nich rnych dziaa. Interfejs powinien dokadnie opisywa, w jaki sposb uytkownicy klasy mog si z nim komunikowa. Interfejs skada si z usug, z ktrych moe korzysta uytkownik kocowy. W idealnej sytuacji udostpniane s tylko te usugi, ktre s konieczne i niezbdne uytkownikowi. Jedn z najwaniejszych zasad tworzenia klas jest tworzenie jak najmniejszego interfejsu publicznego. Nawet jeli interfejs publiczny klasy jest niewystarczajcy do niektrych zastosowa, technologia obiektowa umoliwia jego rozszerzenie i adaptacj za pomoc dziedziczenia. Projektujc z myl o dziedziczeniu mona odziedziczy funkcjonalno po istniejcej klasie i utworzy now klas z rozszerzonym interfejsem. Jeli klasa jest poprawnie zaprojektowana, wszystkie zmiany systemowe powinny by dokonywane wycznie w implementacji obiektw. Modyfikowania interfejsu publicznego naley unika za wszelk cen, poniewa moe spowodowa to lawin problemw we wszystkich korzystajcych z niego systemach.

Aby ukrywanie danych byo moliwe, wszystkie atrybuty powinny by zadeklarowane jako prywatne. Dziki temu nigdy nie bd one czci interfejsu. W skad interfejsu klasy wchodz wwczas tylko jej publiczne metody. Atrybut zadeklarowany jako publiczny stanowi zamanie zasady ukrywania danych. Do interfejsu zalicza si tylko publiczne skadowe klasy. Uytkownik nie powinien mie dostpu do adnej czci implementacji. Pozwala to na zmian implementacji bez wpywu na interfejs, w sposb nieodczuwalny dla uytkownika. Zmiana w implementacji nie powinna powodowa koniecznoci wprowadzania zmian w kodzie, ktry z niej korzysta. Jeli interfejs jest poprawnie zaprojektowany, zmiana w jego implementacji nie powinna wymaga zmian w korzystajcym z niej kodzie. Teoretycznie powinno by moliwe dowolne zmienianie tego, co jest uwaane za implementacj i zmiany te nie powinny mie adnego wpywu na sposb komunikacji uytkownika z klas. Z technicznego punktu widzenia wszystko, co nie jest interfejsem publicznym, mona uzna za implementacj. Mona utworzy prywatn metod wykorzystywan tylko wewntrz klasy. Kada prywatna metoda jest czci implementacji klasy. Kod metod publicznych rwnie naley do implementacji, poniewa uytkownicy go nie widz. Uytkownik powinien widzie tylko fragmenty klasy suce do wywoywania interfejsu, a nie znajdujcy si we wntrzu tej klasy kod. Zadaniem metod prywatnych jest realizacja funkcji implementacyjnych. Wywouj je metody publiczne danej klasy. Kodowanie pod interfejs sprawia, e oprogramowanie jest bardziej rozszerzalne ni w przypadku kodowania pod implementacj. Dziki kodowaniu pod interfejs kod programu zawsze bdzie dziaa z interfejsami wszystkich podklas nawet tymi, ktre nie zostay jeszcze utworzone. Interfejs w UMLu jest oznaczany sowem kluczowym interface. Interfejs nie ma implementacji. W C++ tworzy si podklas klasy bdcej interfejsem. Uycie interfejsu daje bardzo podan moliwo atwej zmiany implementacji, gdyby w przyszoci zasza taka potrzeba. Programujc interfejs a nie implementacj unikamy koniecznoci zmiany caego kodu w wypadku wystpienia potrzeby uycia innej implementacji. Zawsze naley si stara programowa w ten sposb, dbajc o moliwie najwiksz elastyczno rozwizania. Na poziomie opisu interfejsw klasy powinny specyfikowa kompletne paczki wymienianych danych. Wszystkie dane niezbdne dla drugiego komponentu powinny by umieszczone w takiej paczce; trzeba przekaza ca niezbdn dla drugiego komponentu struktur danych z odpowiedni zawartoci. Struktura ta powinna oczywicie w jaki sposb odpowiada kawakowi modelu klas na poziomie wymaga. Rwnie wane, jak zdefiniowanie danych wymienianych przez interfejsy, jest zdefiniowanie operacji wymieniajcych te dane. Moliwe jest po prostu przedstawienie algorytmu realizujcego dan metod. Dobrze okrelony interfejs powinien mie dobrze okrelone operacje. Nie wystarczy poda nazw operacji i zdefiniowa wymieniane poprzez t operacj dane. Konieczne jest rwnie pokazanie skutkw, jakie powoduje uruchomienie operacji. Wane jest rwnie okrelenie warunkw, jakie musz spenia wymienione dane, aby operacja zakoczya si sukcesem. 1.4 Hermetyzacja (enkapsulacja) Hermetyzacja jest podstaw obiektowoci. Podstawowe pytanie dotyczy tego, co w klasie powinno by udostpniane na zewntrz, a co ukryte. Jednym z najwaniejszych problemw do rozwizania w programowaniu obiektowym jest wyodrbnienie cech wsplnych rnych klas. Enkapsulacja pozwala dzieli aplikacj na logiczne czci. Za kadym razem, gdy zostanie zidentyfikowany zduplikowany kod, naley

szuka moliwoci enkapsulacji. Naley unika zduplikowanego kodu poprzez wyabstrahowanie tego, co wsplne i umieszczenie tego w jednej lokacji. Warto zaczyna od enkapsulacji, a dopiero potem stosowa dziedziczenie i polimorfizm. Naley poddawa enkapsulacji te czci kodu, ktre si czsto zmieniaj, by odseparowa je od czci kodu, ktre zmieniaj si rzadko. Podstaw hermetyzacji jest ukrywanie danych (atrybutw). W poprawnie zamodelowanym modelu obiektowym nie istnieje pojcie danych globalnych. Aby jedne obiekty nie manipuloway danymi innych obiektw, dane (atrybuty) s ukrywane (prywatne), a dostp do nich jest moliwy dziki publicznym metodom get/set. Obiekty nie powinny udostpnia wszystkich swoich atrybutw i zachowa. Obiekt w dobrze zaprojektowanym systemie powinien udostpnia tylko te interfejsy, z ktrymi musz si komunikowa inne obiekty. Szczegy implementacyjne, ktre nie s niezbdne do korzystania z obiektu przez inne obiekty powinny zosta ukryte. Ograniczenie zakresu idzie w parze z abstrakcj i ukrywaniem implementacji. Chodzi o to, by atrybuty i zachowania miay jak najmniejszy zasig dostpnoci. Znacznie uatwia to konserwacj, testowanie i rozszerzanie klas. Jednym z najczciej spotykanych bdw jest tworzenie klas, ktre maj zachowania, ale nie maj danych. Takie podejie nie pozwala wykorzysta siy hermetyzacji. 1.5 Dziedziczenie Zasad dziedziczenia jest przechodzenie od najbardziej oglnego przypadku do najbardziej specyficznego poprzez wyodrbnianie cech wsplnych. Dziedziczenie umoliwia przejcie przez klas interfejsu innej klasy. Warto zatem wyodrbni atrybuty i zachowania wsplne dla caej grupy klas i umieci je w jednej nadklasie. Dziedziczenie jest zwizkiem typu jest, za kompozycja i agregacja s zwizkiem typu ma. Dziedziczenia naley uywa, gdy jeden obiekt zachowuje si tak jak drugi, a nie tylko spenia relacj typu jest. Przykad: kwadrat jest prostoktem, ale nie maj dla niego sensu metody ustawiajce/pobierajce wysoko i szeroko. Jeli podklasa dziedziczy metod abstrakcyjn po nadklasie, musi t metod zaimplementowa lub sama stanie si abstrakcyjna. Problem osabiania hermetyzacji przez dziedziczenie polega na tym, e jeli podklasy odziedzicz po nadklasie implementacj, ktra zostanie pniej zmieniona, zmiany te widoczne bd take we wszystkich podklasach. Aby zmniejszy ryzyko zwizane z tym zjawiskiem, naley cile trzyma si zasady relacji jest w dziedziczeniu. Jeli podklasa rzeczywicie jest wyspecjalizowan wersj swojej nadklasy, zmiany w tej nadklasie powinny mie taki wpyw na podklas, jakiego naleaoby si spodziewa i jaki jest naturalny. W hierarchii dziedziczenia podklasy dziedzicz po swoich nadklasach interfejsy, jednak kada klasa moe na komunikaty odpowiada we wlaciwy sobie sposb dziki zastosowaniu polimorfizmu. Nastpuje przesanianie, czyli zastpowanie implementacji odziedziczonej po nadklasie wasnym kodem. Dziedziczc po nadklasie, musi by moliwo zmiany podklasy na nadklas bez powodowania znacznych problemw. Jeeli takowe wystpuj, sygnalizuje to powane problemy zwizane z nieprawidowym uyciem dziedziczenia. Jeeli zamiast dziedziczenia stosowana bdzie delegacja, kompozycja i agregacja, oprogramowanie bdzie bardziej elastyczne, atwiejsze do konserwacji, rozszerzania i ponownego uycia. Agregacji lub delegacji warto uy zamiast dziedziczenia, gdy podklasa nie jest podmienialna na nadklas.

Generalizacja odnosi si do dziedziczenia i jest oznaczana lini z pust strzak w kierunku nadklasy. Generalizacja polega na tym, e zaczynasz od podklas i tworzysz nadklas, za specjalizacja jest wwczas, gdy zaczynamy od nadklasy i tworzymy podklasy. Gdy podklasa dziedziczy ograniczenia, musza one by co najmniej tak rygorystyczne jak te w nadklasie. Jeeli nadklasa jest powizana asocjacj z inn klas, to dziedziczona jest ta asocjacja rola, liczno innej klasy oraz wszelkie ograniczenia i kwalifikatory. Nie jest dziedziczona liczno nadklasy. Oczywicie mona przesoni w podklasie atrybuty, metody i ograniczenia. Atrybut w podklasie moe zredefiniowa w UML atrybut nadklasy poprzez sowo redefines i nazw redefiniowanego atrybutu. Typ danych odziedziczonego atrybutu musi by taki sam lub bardziej wyspecjalizowany ni typ danych tego atrybutu w nadklasie. 1.6 Polimorfizm Przesanianie (overriding) oznacza zastpowanie w podklasie implementacji elementu odziedziczonej po nadklasie. Polimorfizm polega na tym, e taki sam komunikat mona wysa do wielu rnych obiektw, a kady z nich odpowie we wlaciwy sobie sposb. Domylna warto atrybutu w podklasie moe przesania domyln warto atrybutu nadklasy. 1.7 Asocjacja Asocjacje Reprezentuj relacje, w jakich znajduj si klasy/obiekty posiadaj liczno (krotno) wi 1 lub wicej klas mog by nazwane i posiada role mog mie wasnoci i ograniczenia Dobrym zwyczajem jest nazywanie asocjacji i okrelanie ich kierunku, zwaszcza jeli nie uda si przedstawi ich w ukadzie z lewej do prawej lub z gry na d. Asocjacja jest obowizkowa, gdy ma liczno o wartoci co najmniej 1. Opcjonalna jest natomiast wtedy, gdy liczno moe przyj warto 0. Liczno powinno si podawa na obu kocach asocjacji. Nawigacja midzy klasami jest pewn cech asocjacji. Asocjacja, ktra ma cechy nawigowalnoci, najczciej oznacza, e jedna z klas ma atrybut, za ktrego porednictwem moe uruchomi operacje klasy po drugiej stronie asocjacji. Nawigacj oznaczamy za pomoc strzaek z otwartym grotem. Moliwa jest nawigacja w jedn lub w obie strony. Jeeli nawigacja w asocjacji ma by tylko w jednym kierunku, naley umieci strzak na asocjacji w sposb okrelajcy kierunek od rda do celu. Jeeli asocjacja ma dwukierunkow nawigacj, to mona zaimplementowa j w ten sposb i nie trzeba nic oznacza strzakami. Asocjacja dwukierunkowa to para poczonych ze sob cech bdcych swoimi odwrotnociami.

Jeeli asocjacje midzy dwiema klasami cechuje pewna zawarto informacyjna oprcz krotnoci i rl, to do takiej asocjacji moemy przyczy klas asocjacyjn. Klasa asocjacyjna ma wszystkie elementy normalnej klasy, ale poczona jest dodatkowo z asocjacj, ktr opisuje. Notacj dla takiego poczenia jest przerywana linia, czca symbol klasy asocjacyjnej z asocjacj. Klasa asocjacyjna moe uczestniczy w relacjach z innymi elementami modelu (np. z innymi klasami) tak jak kada inna klasa. 1.8 Liczno (krotno) Liczno (krotno) Umoliwia okrelenie liczby kocu. Moliwe przypadki: -n - n..* - n..m -* - n, m, o..p, q (q > p...) elementow biorcych udzia w tej asocjacji, na kadym jej (n > 0) dokadnie n (n 0) n lub wicej (m > n 0) od n do m wiele (nieznana liczba) lista wartoci

Liczno (krotno) to liczba obiektw biorcych udzia w asocjacji oraz informacja, czy udzia ten jest dowolny czy obowizkowy. Aby okreli liczno, naley udzieli odpowiedzi na nastpujce pytania: - ktre obiekty kolaboruj z innymi obiektami? - ile obiektw bierze udzia w kadej kolaboracji? - czy kolaboracja jest dowolna czy obowizkowa? Wszystkie licznoci na diagramie klas powinny dotyczy jednego okresu czasu. Jeeli nie da si unikn na jednym diagramie klas rnych okresw czasu, naley uy rl, by zaznaczy istotno i natur tych okresw i stworzy dla nich odrbne asocjacje. Warto rwnie doda do diagramu komentarz mwicy o tym. Krotno: - opcjonalna dolna graniica wynosi 0 - wymagana dolna granica wynosi co najmniej 1 - jednokrotna grn granic jest 1 - wielokrotna grn granic jest liczba wiksz ni 1, zwykle * Jeeli porzdek elementu krotnoci ma znaczenie, to trzeba doda na kocu asocjacji ograniczenie {ordered}. Aby dopuci powtrzone wartoci, naley doda ograniczenie {nonunique}. W UML nie mona uywa krotnoci dyskretnych, np. 2, 4. Domyln krotnoci atrybutu jest 1, ale lepiej zawsze to jawnie zaznacza na diagramie. Jeeli krotno jest uporzdkowana, to i kolekcja musi by uporzdkowana. 1.9 Agregacja i kompozycja Kady obiekt skadajcy si z innych obiektw nazywa si agregatem lub obiektem zoonym. Asocjacja i kompozycja modeluj relacj cz-cao agregacja wspdzielona (shared) - cz moe nalee do wielu caoci agregacja skadowa (composition) - cz jest cile uzaleniona od caoci Kompozycja rni si od agregacji tym, e w agregacji obiekty skadowe mog istnie po skasowaniu obiektu, ktry si z nich skada. Agregacji i kompozycji nie trzeba nazywa. W przypadku agregacji i kompozycji trzeba zwrci uwag na konstruktory i destruktory obiektw, ktre s caoci. Asocjacja i agregacja rni si sposobem przedstawiania czci jako skadnika caoci. W agregacji wida tylko cao, natomiat w asocjacji wida elementy, ktre si na t cao

skadaj. Agregacja to obiekt zoony z innych obiektw. Asocjacja to zwizek zachodzcy wwczas, gdy jeden obiekt da od innego wykonania na jego rzecz okrelonej usugi. Aby wykorzystywa zachowania innych klas do nowych celw, naley stosowa kompozycj. Od delegacji rni si ona tym, e obiekt, do ktrego delegujemy zachowanie, nigdy si nie zmienia. Kompozycj stosujemy wtedy, gdy chcemy utworzy referencj do caej rodziny zachowa. Kompozycja jest najlepszym wyborem, gdy chcesz uy zachowania zdefiniowanego w interfejsie, a nastpnie wybra jedn z wielu implementacji tego interfejsu. Jeeli obiekt jest skomponowany z innych obiektw i zostaje zniszczony, to jego obiekty skadowe rwnie zostaj usunite. Kluczem relacji kompozycji jest regua jednego waciciela chocia klasa moe by skadnikiem wielu innych klas, to instancja tej klasy moe nalee tylko do jednego waciciela. Skadnik obiektu bdcego w relacji kompozycji nie moe by jednoczenie skadnikiem innego obiektu tej samej lub innej klasy. W przypadku agregacji moliwe jest, e obiekt skadowy zawarty jest jednoczenie w kilku skadnikach klasy agregujcej. Cechy agregacji i kompozycji powoduj okrelone konsekwencje zwizane z tworzeniem diagramw klas. Krotno po stronie klasy bdcej caoci w kompozycji musi by zawsze rwna 1. Ponadto klasa bdca skadnikiem w kompozycji nie moe by w relacji kompozycji z adn inn klas. Takich ogranicze nie ma relacja agregacji. 1.10 Zaleno Zaleno Jest oglnym okreleniem zalenoci (dependency) dwch klas/obiektw od klasy zalenej do nadrzdnej czsto uywane ze stereotypem powizanie elementw na rnych poziomach abstrakcji Midzy dwoma elementami istnieje zaleno, jeeli zmiany definicji jednego elementu mog spowodowa zmiany drugiego. Powody istnienia zalenoci w przypadku klas: - jedna klasa wysya komunikat do drugiej - jedna klasa zawiera drug jako cz swoich danych - jedna klasa wymienia drug jako parametr operacji Zaleno jest jednokierunkowa i skierowana do klasy gwnej. Typy zalenoci: call - klasa rdowa wywouje czynno w klasie docelowej create - klasa rdowa tworzy instancj klasy docelowej derive - klasa rdowa jest pochodn klasy docelowej instantiate - klasa rdowa jest instancj klasy docelowej permit - klasa docelowa zezwala klasie rdowej na uzyskiwania dostpu do swoich prywatnych skadowych realize - klasa rdowa jest implementacj specyfikacji lub interfejsu zdefiniowanego przez klas docelow substitute - klasa rdowa jest substytutem dla klasy docelowej use - oznacza, e do zaimplementowania klasy rdowej wymagana jest klasa docelowa Jednym z najlepszych sposobw na uatwienie przyszych aktualizacji jest zredukowanie do minimum zalenoci w kodzie. Aby zapewni jak najwiksze moliwoci konserwacji klas, naley utrzymywa jak najmniejszy stopie sprzenia midzy nimi. Ogln zasad powinno by minimalizowanie zalenoci, zwaszcza wtedy, gdy obejmuj one due obszary systemu.

Prba uwzgldnienia wszystkich zalenoci na diagramie klas jest skazana na niepowodzenie jest ich zbyt wiele i za bardzo si zmieniaj. Naley podchodzi do tego wybirczo i pokazywa tylko zalenoci bezporednio zwizane z tematem, ktry chcemy opisa. Aby zrozumie i kontrolowa zalenoci, najlepiej uy ich wraz z diagramami pakietw. 1.11 Delegacja Delegacja polega na przekazaniu innemu obiektowi odpowiedzialnoci za wykonanie pewnego zadania (np. eby porwna obiekt, oczekujemy od obiektu, e sam dokona porwnania samego siebie z obiektem mu przekazanym). Delegacja pomaga chroni obiekty przed zmianami implementacji dokonywanymi w innych obiektach. Delegacji najlepiej uywa wwczas, gdy chce si uy funkcjonalnoci innej podklasy w takiej formie, jaka jest, bez zmiany jej zachowania.

2. DIAGRAMY W UML 2.1 Klasy i diagramy klas Wskazwki oglne Podczas pracy nad diagramami warto pamita, e: - naley unika nadmiarowych i nieistotnych diagramw zaciemniajcych obraz modelu - na kadym diagramie powinny znale si tylko te szczegy, ktre s niezbdne do wyrazenia intencji autora - nadmiar informacji odwrci uwag czytelnika od istotnych rzeczy - naley zachowa rwnowag pomidzy diagramami obrazujcymi dynamiczne i statyczne aspekty systemu - diagram nie powinien by za duy (czyli takie, ktre zawieraj wiele elementw i zajmuj wiele stron) - 10-12 elementw to granica ludzkiej percepcji - diagram nie powinien by za may - mona poczy kilka maych diagramw w jeden wikszy Diagram klas powinien: - uwypukli jeden statyczny aspekt perspektywy projektowej systemu - obejmowa tylko te byty, ktre s niezbdne do zrozumienia tego aspektu - zawiera szczegy odpowiednie do przyjtego poziomu abstrakcji, z dodatkami umoliwiajcymi zrozumienie intencji autora Uwagi graficzne: - Diagram powinien mie nazw okrelajc jego przeznaczenie - Elementy diagramu powinny by tak uozone, eby zminimalizowa liczb przecinajcych si linii - Elementy zblione znaczeniowo powinny znajdowa si blisko siebie na diagramie - Do uwypuklenia intencji autora mona uy kolorw i notatek - Naley unika umieszczania zbyt wielu rodzajw zwizkw - na jednym diagramie powinien dominowa jeden typ. Diagramy klas Symbolem klasy jest prostokt, zwykle podzielony poziomymi liniami na trzy sekcje: - nazwy - atrybutow - operacji Przykad klasy:

Mona okreli modyfikatory dostpu dla skadowych. S one cile powizane z koncepcjami programowania zorientowanego obiektowo. Moliwe rodzaje dostpu: + publiczny - prywatny # chroniony ~ pakietu Specyfikacja skadnikow Atrybuty mog mie okrelone: - Typ. Typ jest umieszczany po nazwie, oddzielony dwukropkiem - Liczebno - Warto pocztkow Operacje mog mie okrelone: - Typ zwracany. Typ jest umieszczany po nazwie, oddzielony dwukropkiem

- Argumenty. Kady argument moe by okrelony tak jak atrybut, z dodatkowym oznaczeniem kierunku przekazywania wartoci (domylnie in) Oglna deklaracja atrybutu klasy [widoczno] nazwa [liczebno] [:typ] [=warto_pocztkowa] [{okrelnie_waciwoci}] Oglna deklaracji operacji [widoczno] nazwa [(lista_parametrw)] [:typ_wyniku] [{okrelenie-waciwoci}] Skadniki mona zadeklarowa jako statyczne dziaajce na rzecz klasy, nie obiektu. Koncepcja identyczna jak w jzykach zorientowanych obiektowo. Reprezentacj graficzn jest podkrelenie. Atrybuty pochodne to atrybuty wyliczane na podstawie innych wartoci. Nazw takiego atrybutu poprzedza si znakiem /. Wyliczenia (enum) s zapisywane jako klasa ze sowem kluczowym enumeration. Przy zoonych klasach wywietlenie wszystkich atrybutow i operacji moe zabra zbyt duo miejsca. Moliwe rozwizania to: - Wywietlenie tylko nazwy klasy, bez sekcji atrybutow i operacji - Wywietlenie tylko nazwy klasy, z pustymi sekcjami atrybutow i operacji - Wywietlenie tylko czci atrybutow lub operacji, zaznaczajc kontynuacj poprzez wielokropek - Ukrycie niektorych atrybutow lub operacji Klasy - asocjacja Wszystkie 4 typy zwizkow s uywane. Gownym typem jest asocjacja. Moe mie nastpujce cechy (podkrelono nowe w stosunku do diagramow przypadkow uycia):

1. nazwa - Mona nazwa asocjacj aby doprecyzowa jej znaczenie. Nazwa moe zawiera kierunek. 2. role - Inny sposb doprecyzowania asocjacji. Rola klasy jest okrelona przez tekst umieszczony w pobliu tej klasy. Mona okreli jednoczenie nazw i role. 3. kierunek nawigacji - Domylnie asocjacja jest dwukierunkowa. Aby bya jednokierunkowa, dodaje si strzak. Oznacza to e komunikacja jest jednokierunkowa (inaczej ni diagramy przypadkw uycia). 4. liczebno - Znaczenie identyczne jak w diagramach przypadkw uycia. 5. agregacja - Okrela zwizek midzy caoci i czci. S dwa typy: cakowita (kompozycja, silna agregacja) oraz czciowa (agregacja, saba agregacja). Jest obrazowana przez romb umieszczony przy symbolu okrelajcym cao. Silna agregacja jest zobrazowana przez peen romb, saba przez pusty. W przypadku silnej agregacji czci skadowe nie mog istnie jeli symbol okrelajcy cao jest usunity - analogia do zawierania obiektu przez inny obiekt. W przypadku sabej agregacji jest to moliwe. Jeden obiekt moe by te zawierany przez wiele innych - analogia do zawierania wskanika (bd referencji) do innego obiektu.

Klasa asocjacji Kolejny sposob dokadnego okrelenia asocjacji. Jest zobrazowana przez klas umieszczon w pobliu asocjacji i poczon z ni przerywan lini.

Asocjacja wielokrotna Dwie klasy mog by w odmienny sposb zwizane ze sob w rnych kontekstach. W efekcie moe by wicej ni jedna asocjacja midzy klasami. W takim wypadku kada powinna by nazwana.

Asocjacja zwrotna

Podsumowanie asocjacji Asocjacja zwizek midzy dwiema klasami (student nauczyciel, sprzedajcy kupujcy) Saba agregacja obiekty jednej klasy nale do obiektow drugiej, ale fragmenty mog istnie bez caoci (zamowienie produkty, biblioteka ksiki) Silna agregacja (kompozycja) j. w., ale cz nie moe istnie bez caoci (wielokt jego wierzchoki, zamowienie adres dostarczenia) Klasy zaleno Oznacza e jedna klasa (klient) w jaki sposb uywa innej klasy (dostawca). Jest obrazowana lini przerywan zakoczon strzak wskazujc na dostawc.

Klasy - uoglnienie cile powizane z koncepcj dziedziczenia w programowaniu zorientowanym obiektowo. Mona stosowa m. in klasy abstrakcyjne: - nie maj one instancji (obiektw) - s wyrnione nazw pisan kursyw

Klasy - realizacja Zwizek midzy interfejsem i jego implementacj. Obrazowana lini przerywan z pust strzak wskazujc od klasy do interfejsu. Interfejs moe by zobrazowany jako prostokt z operacjami (podobnie do klasy) bd jako kko.

albo

Sygnay Sygnay modelujemy za pomoc stereotypowanych klas (signal). Mog one mie atrybuty. Do zobrazowania wysyania sygnau przez klas uywamy stereotypu send.

Sygnay s klasyfikatorami i mog by poczone zwizkami, np. uoglnienia. Przykadowe diagramy klas

2.2 Przypadki uycia i diagramy przypadkw uycia Przypadek uycia (use-case) jest sposobem, w jaki aktorzy uywaj (chc uywa) systemu jest podstawow jednostk funkcjonalnoci. definiuje wymagania Diagram przypadkw uycia Definiuje: granice systemu, czyli jak daleko siga model jego kontekst, czyli co pozostaje na zewntrz uytkownikw systemu, czyli aktorw funkcje systemu, zalenoci midzy uytkownikami i funkcjami Przypadek uycia opisuje, co system robi by osign okrelony cel podany przez klienta. Pojedynczy przypadek uycia dotyczy jednego celu. Kady przypadek uycia, dostarcza jednego lub wicej scenariuszy. Przypadek uycia musi: - mie oczywist warto (pomaga klientowi osiga podany cel) - mie okrelony pocztek i koniec - by zaczynany przez zewntrznego inicjatora, znajdujcego si poza systemem Rzeczowniki w przypadkach uycia s zwykle klasami, ktre naley stworzy w systemie. Analogiczna regua dotyczy czasownikw i metod. Zwykle tworzc przypadek uycia wybiera si spord wszystkich scenariuszy gwny scenariusz sukcesu, a nastpnie dopisuje si inne scenariusze jako rozszerzenia dla gwnego scenariusza. Rozszerzenie moe koczy si sukcesem lub porak. Tworzc przypadki uycia, prcz gwnej ciezki trzeba rwnie szuka scenariuszy wystpujcych w przypadku bdu, wyjtku albo scenariuszy alternatywnych. Kady etap przypadku uycia jest elementem interakcji midzy aktorem i systemem. Kady etap powinien by prost instrukcj i powinno by jasne, kto go wykonuje. Etap powinien skupia si na zamiarze aktora, a nie na szczegach jego dziaa (dlatego te w przypadkach uycia nie opisuje si np. interfejsu uytkownika). W UMLu prcz relacji zawierania (include) mona rwnie wskaza inne relacje midzy przypadkami uycia, np. rozszerzanie (extend). Jeli ktry z etapw przypadku uycia systemu jest bardzo skomplikowany, to moe si sta nastpnym przypadkiem uycia. Mwimy wwczas, e jeden przypadek uycia zawiera drugi. Oznacza si to sowem include i zalenoci zobrazowan lini przerywan z otwart strzak w kierunku przypadku zawieranego. Jeeli w rnych przypadkach uycia wystpuj identyczne kroki lub sekwencje dziaa to warto wydzieli te wsplne zachowania w przypadek uycia, a na diagramie poprowadzi do niego przerywane strzaki z relacj include, co bdzie wskazywa i ten wydzielony przypadek uycia jest niezbdn czci przypadku uycia, ktry si do niego odnosi. Przypadki uycia typu include czsto s przydatne, a wrcz potrzebne, gdy kilka przypadkw uycia wspdzieli drugoplanowego aktora. Aby rozszerzy przypadek uycia np. o opcjonalne lub alternatywne kroki, wykorzystuje si extend, kierujc przerywan lini ze strzak w stron rozszerzanego przypadku uycia. Kady przypadek uycia ma swojego gwnego aktora, ktry zamawia wykonanie przez system jakiej usugi. W przypadku uycia moe by wicej ni jeden gwny aktor. W przypadkach uycia mona uywa generalizacji tak samo, jak w diagramach klas. Przypadki uycia mona grupowa w pakiety.

Wskazwki przy modelowaniu przypadkw uycia kady przypadek uycia powinien opisywa istotn cz uytkowania systemu, ktora jest zrozumiaa zarowno dla programistow jak i ekspertow dziedziny, definiujc przypadki uycia tekstowo naley odpowiednio i spojnie uywa rzeczownikow i czasownikow, eby atwo utworzy obiekty i komunikaty dla modeli behawioralnych (diagramy sekwencji i kolaboracji), znale wspolne funkcje, ktore s wymagane przez rone przypadkow uycia: include ), o jeeli funkcja jest wymagana, zastosowa zawieranie ( o jeeli przypadek uycia jest kompletny, a dana funkcja moe by opcjonalna, zastosowa rozszerzenie ( extend ), diagram przypadkow uycia powinien: o zawiera tylko przypadki uycia na tym samym poziomie abstrakcji, o docza tylko aktorow, ktorzy s niezbdni, dua liczba przypadkow uycia powinna by zorganizowana w pakiety. Diagram przypadkw uycia najlepiej traktowa jako graficzny spis treci zbioru przypadkw uycia. Diagramy przypadkow uycia umoliwiaj: - Identyfikacj i dokumentacj wymogw - Analiz zakresu aplikacji - Komunikacj pomidzy tworcami, wacicielami, klientami itd. - Opracowanie projektu przyszego systemu, organizacji - Okrelenie procedur testowych dla systemu Dokumentowanie przypadkow uycia Diagram przypadkow uycia sam w sobie jest bardzo ogolnikowy. Aby precyzyjnie okreli podane zachowanie systemu, kady przypadek uycia powinien posiada dodatkowa informacj, tzw. scenariusz. Scenariusz jest sekwencj akcji, okrelajca zachowanie. Dla zoonych przypadkow mona zdefiniowa gowny oraz alternatywne scenariusze. Scenariusz moe zosta zapisany w jzyku naturalnym, pseudo-kodzie, tabeli itp. Aktorami mog by: - Osoby (pojedyncza osoba, grupa, organizacja itp.) - Zewntrzne systemy (programowe bd sprztowe) - Czas Klasyczny symbol aktora moe by stereotypowany, aby rozroni midzy ronymi typami aktorw.

Zwizek Wie ze sob elementy diagramu (np. aktorw i przypadki uycia). S 4 rodzaje zwizkw: 1. Asocjacja (association) - opisuje zwizek pomidzy (dwiema lub wicej) wystpieniami klasyfikatorow. W diagramie przypadkow uycia reprezentuje dwukierunkow komunikacj pomidzy aktorem i przypadkiem uycia. Jej reprezentacj graficzn jest ciga linia. 2. Uoglnienie (generalisation) - jest taksonomiczn relacj pomidzy ogolnym i specjalizowanym klasyfikatorem. Specjalizowany klasyfikator dziedziczy wszystkie cechy klasyfikatora ogolnego. Jest obrazowana lini zakoczon zamknit strzak, wskazujc w stron klasyfikatora ogolnego.

3. Zaleno (dependence) - jest zwizkiem pomidzy dwoma elementami modelu gdzie zmiana w jednym elemencie (niezalenym) ma wpyw na drugi element (zaleny). Jest obrazowana jako linia przerywana zakoczona otwart strzak. W diagramach przypadkow uycia zaleno jest stereotypowana w: - zaleno include - zwizek midzy przypadkiem zawierajcym i zawieranym. Przypadek zawierany jest wykonywany zawsze gdy wykonywany jest przypadek zawierajcy i tylko wtedy. Jest przydatna gdy kilka przypadkow uycia zawiera t sama wspoln cz. Strzaka skierowana jest od przypadku zawierajcego do zawieranego.

- zaleno extend - zaleno midzy przypadkiem podstawowym i przypadkiem ktory opcjonalnie moe wprowadzi dodatkow funkcjonalno do przypadku podstawowego. Jest przydatna gdy przypadek moe, w pewnych warunkach, by uzaleniony od innych przypadkow. Strzaka wskazuje od rozszerzenia do przypadku podstawowego

4. Realizacja (realisation) 2.3 Pakiety i diagramy pakietw Diagram pakietw umoliwia porzdkowanie i grupowanie elementw modeli. Gwne elementy to pakiety, zalenoci i zawieranie pakietw. Kady element modelu moe by umieszczony w pakiecie. Nazwa pakietu jest umieszczona w symbolu pakietu, w zakadce (jeli elementy s umieszczone w symbolu pakietu) lub w zakadce ramy (jeli rama jest stosowana jako oznaczenie pakietu). Pakiety mog zawiera inne pakiety. Mona to zobrazowa poprzez umieszczenie pakietu w pakiecie, lub poprzez zwizek zawierania. Pakiety mog by stereotypowane, typowe stereotypy to model, subsystem, framework. Mona okreli poziom dostpu do elementw pakietu.

W UML kada klasa jest skadnikiem jednego pakietu. Pakiety mog by skadnikami innych pakietw. W UMLu klasy w pakietach mog by publiczne lub prywatne. Klasa publiczna jest czci interfejsu pakietu i moe by uywana przez inne pakiety. Klasa prywatna jest ukryta. Dobr praktyk jest ograniczenie interfejsu pakietu do niewielkiego podzbioru operacji klas publicznych. Mona to osign nadajc wszystkim klasom prywatny zasig widocznoci, tak aby byy one widziane tylko przez inne klasy tego pakietu, i dorzucajc do pakietu dodatkowe klasy publiczne dla definicji zachowania publicznego. Klasy te, zwane fasadami, zlecaj wykonanie operacji publicznych ich prywatnym partnerom w ramach pakietu. W jaki sposb zdecydowa, ktre klasy umieci w poszczeglnych pakietach? Dwie przydatne reguy to: - zasada wsplnego domknicia klasy znajdujce si w tym samym pakiecie powinny wymaga zmian z podobnych powodw - zasada wsplnego powtrnego uycia klasy w pakiecie powinny by ponownie uywane razem Diagram pakietw przedstawia pakiety i zalenoci midzy nimi. Dobra struktura pakietw cechuje si przejrzystym przepywem zalenoci. Czsto przejrzysty przepyw zalenoci mona pozna po tym, e wszystkie zalenoci podaj w jednym kierunku. Im wicej zalenoci dochodzi do pakietu, tym stabilniejszy musi by interfejs tego pakietu, poniewa kada zmiana w interfejsie przeniesie si na wszystkie zalene pakiety. Bardzo czst praktyk jest umieszczanie interfejsu i jego implementacji w osobnych pakietach. Przykadowe diagramy pakietw

2.4 Komponenty i diagramy komponentw Do organizowania wyszych poziomw abstrakcji w UML su diagramy pakietw i diagramy komponentw. Pakiet stanowi zbir klas, asocjacji lub innych elementw modelowania, moe rwnie zawiera inne pakiety. Suy do podziau caego modelu na mniejsze logiczne fragmenty i dostarcza mechanizmu organizowania elementw modelu w grupy. Pakiety mog by zorganizowane w drzewo, podobnie jak ma to miejsce w przypadku struktury katalogw w systemie operacyjnym. Specjalnym rodzajem pakietw s komponenty. Komponent oprcz grupowania rnych elementw modelu dostarcza funkcjonalnoci innym elementom (zwaszcza innym komponentom). Pojedynczy komponent stanowi zatem jeden z podsystemw dziaajcego systemu. Komponent komunikuje si z innymi komponentami za pomoc interfejsw. Komponent to samodzielny podsystem, autonomiczny i modularny. Komponenty dziaaj jak czarne skrzynki mona zamieni jeden komponent na inny bez zmiany czegokolwiek w systemie. Komponent mona traktowa jako podsystem z wewntrznymi klasami, ktre wsppracuj, by zrealizowa publicznie zadeklarowany interfejs. Komponent jest rodzajem klasy, tylko e na wyszym poziomie abstrakcji. Komponentem moe by rwnie klasa z wieloma wewntrznymi czciami i zewntrznymi interfejsami. Komponent uywa stereotypu component i czsto posiada zaznaczone interfejsy te, ktre s udostpniane na zewntrz, s reprezentowane przez okrg poaczony lini z komponentem, za te interfejsy, ktrych komponent wymaga, s reprezentowane przez pokrg poczony lini z komponentem. Konstruujc komponenty naley ostronie definiowa ich granice poprzez czytelne opisanie odpowiedzialnoci i interfejsw komponentu. Aby komponenty byy zamienialnymi czciami, musz one spenia nastpujce kryteria: - ukrywa implementacj, by bya niedostpna dla obiektw spoza komponentu; nie wolno dopuci, by wystpoway zalenoci midzy implementacj komponentu a innymi obiektami - dostarczy interfejsy maj one opisywa, jakich operacji na komponencie mona dokona, lecz nie w jaki sposb operacje te s dokonywane. Obiekt znajdujcy si poza komponentem musi wiedzie jedynie, czy uywa odpowiedniego interfejsu (czyli musi korzysta z jego sygnatury) - wewntrzne czci komponentu rwnie nie mog mie wiedzy nt. zewntrznych obiektw, gdy wwczas zamiana komponentu zepsua by system - wyspecyfikowa wymagane interfejsy obiekty wewntrz komponentu musz czasami uzyska dostp do obiektw poza komponentem; naley zatem uywa interfejsw zewntrznych obiektw, by nie prbowa uzyska bezporedniego dostpu do tych obiektw Aby pokaza, w jaki sposb wewntrzne klasy s poczone z interfejsami komponentu, uywa si nastpujcych terminw i notacji: - porty punkty interakcji pomidzy wntrzem i tym co na zewntrz komponentu. Dostarczone i wymagane interfejsy s przyczepione wanie do nich. Port jest reprezentowany przez may kwadrat na krawdzi komponentu. Poprzez doczepienie interfejsw do portu specyfikuje si usugi, ktre komponent dostarcza lub ktrych wymaga przez ten port. - delegacja gdy danie usugi trafia do komponentu poprzez port, naley pokaza, kto obsuy to danie. Aby to zrobi, tworzy si link midzy portem a jedn z wewntrznych klas. Link powinien by lini ze strzak wskazujc na kierunek dania z umieszczonym przy linii stereotypem delegate. Stereotypy dla implementacji: focus wykonuje cz lub cao logiki biznesowej wewntrz komponentu process wykonuje transakcj; musi si upewni, e wana sekwencja zachowa (czyli wanie transakcja) zostaje ukoczona. Gdy transakcja nie jest kompletna, process musi rwnie cofn wszelkie zachowania, jakie zostay wykonane, by dokona transakcji. service nie ma stanw, sluy do obliczania wartoci

entity to cz, ktra jest trwaa. Jej zachowania, wartoci i stan s zachowywane po zakoczeniu runtimeu programu. auxiliary asystuje focus przy implementacji logiki biznesowej Diagramy komponentw opisuj interakcje midzy komponentami (moduami) systemu. Komponent jest czci systemu ktra wchodzi w interakcje z innymi komponentami poprzez interfejsy. W stosunku do interfejsw wystpuje zwizek dziedziczenia (realizacji). Komponent jest zwizany z pojciem wielouywalnoci. Komponenty sa obrazowane symbolem podobnym do symbolu klasy, mog by stereotypowane. Typowe komponenty to: - Pliki wykonywalne - Biblioteki - Bazy danych - Podsystemy - Usugi Notacja ball-and-socket (kko-gniazdo) pokazuje czenia wewntrz komponentu. Jeeli jedna klasa wymaga interfejsu, a druga go dostarcza, naley je poczy przy uyciu balland socket.

Najprostszy sposb powizania komponentw to zaleno. Jest obrazowana strzak z przerywan lini skierowan od komponentu zalenego (uytkujcego pewne usugi) do niezalenego (zapewniajcego pewne usugi).

Interfejsy Wicej szczegw o komponentach i ich zwizkach mona poda zaznaczajc ich interfejsy. Dwie odrbne sytuacje s moliwe: - Komponent realizuje interfejs, czyli implementuje funkcjonalno zwizan z interfejsem i moe j zaoferowa innym komponentom. Jest to obrazowane przez kko - Komponent jest zaleny od interfejsu, czyli potrzebuje usug innego komponentu, implementujcego interfejs. Jest to obrazowane przez gniazdo (poowa okrgu)

Poczenia koko-gniazdo s stosowane aby precyzyjnie okreli zaleno.

Struktura wewntrzna Wicej szczegw mona przekaza prezentujc struktur wewntrzn subkomponenty. W takim przypadku mona pokaza ktre subkomponenty uywaj interfejsw gwnego komponentu. Do tego celu stosuje si porty. Obrazowane s maymi kwadratami na krawdzi komponentu.

Zawsze, gdy projektuje si komponent, warto stworzy diagram komponentw ukazujcy wewntrzn struktur komponentu oraz diagram komponentw ukazujcy komponent jako czarn skrzynk i otoczony przez klasy interfejsu wraz ze szczegowymi sygnaturami.

Podstawowy widok diagramu komponentw

Diagram komponentw z wyranie wyspecyfikowanymi interfejsami Na diagramie powyej zaleno realizes jest przedstawiona lini przerywan z pust strzak na kocu, za zaleno uses w ten sam sposb z tym, e dodany jest stereotyp uses przy linii przerywanej. Przykadowy diagram komponentw

2.5 Diagramy sekwencji Zwykle diagram sekwencji przedstawia zachowanie si systemu dotyczce jednego przypadku uycia. Diagram pokazuje kilka przykadowych obiektw i komunikaty przez nie wymieniane w ramach przypadku uycia. Diagram sekwencji naley traktowa jako sposb wizualnego przedstawienia, w jakie interakcje wchodz ze sob obiekty, a nie jako sposb modelowania logiki sterujcej systemem.

Diagram sekwencji opisuje interakcje midzy obiektami przy pomocy sekwencji wiadomoci. Dobrze nadaje si do dokumentowania przypadkw uycia. Diagram jest zorientowany w dwu wymiarach: - O pozioma zwizana jest z kolejnymi obiektami biorcymi udzia w wymianie wiadomoci - O pionowa zwizana jest z upywem czasu Jego gwne elementy to: obiekt, linia ycia, wiadomo, specyfikacja wykonania. Na diagramie sekwencji moemy umieszcza klasy, interfejsy, komponenty i aktorw. W diagramach sekwencji mog wystpowa nastpujcy uczestnicy: aktorzy, systemy, podsystemy, obiekty, czci i komponenty. Obiekt - Obiekty klas s podstawowymi elementami w diagramie sekwencji. Diagram moe rwnie zawiera instancj innych klasyfikatorw: przypadkw uycia, aktorw, sygnaw itp. Obiekt jest przedstawiany jako prostokt z nazw (niekiedy podkrelon). W prostych diagramach wszystkie obiekty umieszczone s przy grnej krawdzi diagramu. Linia ycia - Reprezentuje przedzia czasu w ktrym obiekt istnieje. Jest zobrazowana przez przerywana pionow lini, zaczynajc si na obiekcie i idc w d. Wiadomoci - Wiadomoci reprezentuj przepyw informacji midzy obiektami. Wiadomo jest poleceniem dla obiektu aby wykona pewne operacje. Kompletna skadnia jest nastpujca: predecessor/sequence_expression signature. Najwaniejszym (i koniecznym) skadnikiem opisu wiadomoci jest sygnatura. Specyfikacja wykonania - Obrazuje okres aktywnoci obiektu (obliczenia, przekazywanie wiadomoci z/do). Jest przedstawiana jako prostokt umieszczony na linii ycia, jego wysoko okrela okres aktywnoci. Pocztek jest zwizany z aktywacj obiektu (zwykle wiadomoci przekazan od innego obiektu).

Rodzaje wiadomoci - Synchroniczna - Asynchroniczna - Zwrotna - Zgubiona - Znaleziona Wiadomo synchroniczna - Sterowanie jest przekazane do obiektu wywoywanego. Przetwarzanie w obiekcie wywoujcym jest wstrzymywane do momentu zakoczenia wywoanej czynnoci. Jest obrazowane pen strzak. Jest odpowiednikiem wywoania funkcji. Wiadomo asynchroniczna - Przetwarzanie w obiekcie wywoujcym nie jest przerwane. Jest obrazowane otwart strzak. Moliwe jeli wywoujcy i wywoywany s w rnych wtkach (procesach itp.). W diagramie sekwencji strzaki z penym grotem oznacza komunikat synchroniczny, a z pustym grotem komunikat asynchroniczny. Jeli obiekt wysya komunikat synchroniczny, to musi czeka na jego zrealizowanie, np. na wykonanie podprocedury, za jeli wysya komunikat asynchroniczny, to moe kontynuowa przetwarzanie nie czekajc na odpowied.

Asynchroniczno umoliwia szybsze reagowanie i redukuje wystpowanie sprze czasowych, ale utrudnia wykrywanie bdw w kodzie programu.

Wiadomo zwrotna - Obrazuje oddanie sterowania do obiektu wywoujcego. Jest opcjonalna. Jest przedstawiona jako strzaka z lini przerywan.

Tworzenie i niszczenie obiektw Tworzenie i niszczenie s powodowane przez odpowiednie wiadomoci Jeeli uczestnik nie istnieje przez cay czas trwania interakcji, to trzeba go stworzy / usun przy uyciu stereotypw create i destroy. Na kocu wiadomoci create umieszcza si tworzony obiekt (co powoduje e znajduje si on poniej innych obiektw). Po otrzymaniu wiadomoci destroy linia ycia obiektu koczy si. Jest to dodatkowo wyrnione umieszczeniem znaku X na kocu linii.

Wiadomoci warunkowe Mona okreli warunek ktry warunkuje przekazanie wiadomoc. S umieszczane w kwadratowych nawiasach przed specyfikacj wiadomoci. Mona okreli wicej ni jeden warunek. Jeli warunek nie jest speniony, wiadomo nie zostanie przekazana.

Fragmenty zoone S to wybrane fragmenty diagramu sekwencji, do ktrych odnosi si odpowiedni operator interakcji. S zobrazowane ram otaczajc wybrany region. Rama ma nagwek w lewym grnym rogu zawierajcy operator interakcji. Niektre operatory wymagaj wyodrbnienia podfragmetw regionu. S one wyodrbniane lini kropkowo-kreskow. Najczstsze operatory ramek interakcji w diagramach sekwencji: alt alternatywa; zostaje wykonany tylko ten fragment, ktrego warunek jest prawdziwy. opt opcja; fragment zostaje wykonany tylko wwczas, gdy zawarty w nim warunek jest prawdziwy. Jest to odpowiednik operatora alt z jednym wyjciem. par wspbieno; kady fragment jest uruchamiany rwnolegle. loop ptla; fragment moe by wykonywany kilka razy, a warunek okrela podstaw iteracji. neg negacja; fragment przedstawia niepoprawn interakcj. ref referencja; odwouje si do interakcji zdefiniowanej na innym diagramie. Operator alt - alternatywa Oznacza, e tylko jeden z podobszarw (operandw) obszaru objtego ram moe by wybrany. Wybr ten zaley od od warunkw umieszczonych w podfragmentach. Podobszar bez warunku jest wyborem domylnym. Moe by uywany zamiast rozgazienia.

Operator opt fragment opcjonalny Cz diagramu zostanie wykonana tylko jeli speniony bdzie warunek. Odpowiada operatorowi alt z pustym domylnym operandem. Moe by uyty zamiast wiadomoci warunkowej.

Operator break przerwanie wykonania Pozwala zdefiniowa fragment wykonany przy spenieniu warunku. Jeli fragment jest wykonany, reszta specyfikacji wykonania jest pomijana.

Operator neg - bdne zachowanie Wskazuje na fragment, ktry nie powinien by wykonany (jeli jest wykonany, jest to bdne zachowanie)

Operator loop - iteracja Umoliwia wielokrotne powtrzenie wybranego fragmentu. Liczba interacji moze zosta okrelona.

Operator par wykonanie rwnolege Oznacza, e podfragmenty fragmentu objetego ram s wykonywane rwnolegle.

Operator assert wymagana sekwencja Pozwala okreli sekwencj wiadomoci ktra musi pojawi si w systemie dokadnie tak, jak okrelono. Operatory ignore i consider Ignore wskazuje wiadomoci, ktre nie s istotne dla wykonywanego procesu. Consider wskazuje na operacje istotne. Operator critical - fragment o wysokim priorytecie Wskazuje fragment ktry, w momencie wykonania, zablokuje obiekty uczestniczce w wykonaniu, a do zakoczenia operacji.Operacje dotyczce innych obiektw mog by kontynuowane.

Poddiagramy sekwencji Due diagramy wygodnie jest dzieli na mniejsze fragmenty. Takie poddiagramy mog by zobrazowane na diagramie gwnym poprzez tzw. Wystpienie interakcji. Ma ono posta ramy z nagwkiem ref.

Bramy Su komunikacji pomidzy diagramami (fragmentami diagramw). Reprezentowane przez mae kwadraty na krawdzi diagramu.

W UML nie istinieje graficzne narzdzie do przedstawienia przekazywania danych. Przekazywanie to jest zapisywane za pomoc parametrw w nazwie komunikatu i strzaek zwrotnych. Przykadowe diagramy sekwencji

DNS

Wybieranie numeru

2.6 Diagramy czynnoci Diagram czynnoci jest odmian diagramu stanu i opisuje interakcje midzy obiektami. jak pobierane s operacje, co operacje wykonuj (zmiana stanu obiektu), kiedy operacje s wykonywane (sekwencje czynnoci lub akcji) gdzie s wykonywane. Diagramy czynnoci opisuj dynamik systemu. Prezentuj przepyw danych i sterowania. Mog by stosowane do modelowania: - Procesw biznesowych - Scenariuszy przypadkw uycia - Algorytmw - Operacji Diagramw czynnoci warto uywa w nastpujcych przypadkach: - operacje wysokiego poziomu - szczegy przypadkw uycia - workflow (modelowanie procesw biznesowych) - podsumowanie wielu diagramw sekwencji W diagramach czynnoci wystpuj akcje i czynnoci. Akcja jest niepodzielna, za czynnoci skadaj si z akcji i/lub innych czynnoci. Akcja to niepodzielny zestaw dziaa, ktre nie mog zosta przerwane oraz zajmuj niewiele czasu. Moe to by wywoanie operacji pewnego obiektu, obliczenie wartoci wyraenia, wysanie sygnau. Czynno to bardziej skomplikowany zestaw akcji, mog one by przerwane, dekomponowane. Stan czynnoci moe posiada dodatkowe atrybuty, ktrych nie ma stan akcji. Akcj mog by np. metody get/set, wywoanie operacji innej klasy, wysanie sygnau/notyfikacji o zdarzeniu do grupy obiektw. Elementy skadowe: - Czynno - Akcja - Przepyw sterowania - Pocztek - Koniec - Zakoczenie przepywu Czynno - Reprezentuje zoony proces, algorytm. Aby poprawi czytelno, nie wszystkie elementy musz by przedstawione. Moe zosta (na osobnym diagramie) doprecyzowana, poprzez kolejny diagramczynnoci, opisujcy jej wntrze powstaje struktura hierarchiczna. Dekompozycja moe przebiega do poziomu akcji najmniejszej, niepodzielnej jednostki. Symbolem czynnoci jest prostokt z zaokrglonymi rogami. Czasem czynnoci posiadajce powizane z nimi poddiagramy posiadaj specjalny znacznik. Akcje maj podobny symbol (cho moe si roni wielkoci). Przepyw sterowania - Jest to zwizek midzy dwiema czynnociami/akcjami mowicy, e po zakoczeniu jednej sterowanie bdzie przekazane do drugiej. Symbolem jest strzaka.

Pocztek, koniec, zakoczenie przepywu - Pocztek okrela pocztek przepywu sterowania. Zwykle jeden na diagram. Symbolem jest pene kko. - Koniec oznacza zakoczenie wszystkich przepyww w diagramie. Moe by wicej ni jeden. Symbolem jest mae pene kko wewntrz wikszego pustego. - Zakoczenie przepywu oznacza koniec jednego przepywu. Moe by wicej ni jedno. Symbolem jest kko z krzyykiem (X).

Decyzja i zczenie Alternatywne cieki przepywu sterowania mog zosta opisane przy pomocy wzw decyzji i zczenia. Wze decyzji ma jeden przepyw wejciowy i wiele wyjciowych. Tylko jedno wyjcie moe by wybrane w danej chwili. Wze zczenia ma wiele wej i jedno wyjcie. Symbolem obu wzw jest romb. Decyzja: - Wybr wyjcia nastpuje na podstawie warunku - Warunek jest umieszczany przy wyjciu, w nawiasach kwadratowych - Wszystkie warunki musz si wzajemnie wyklucza - Jeden z warunkw moe zosta zastpiony sowem kluczowym else Zczenie: - Kady przepyw pojawiajcy si na wejciu zostanie natychmiast przekazany na wyjcie (brak synchronizacji) Przepywy rwnolege Przepywy mog by wykonywane rwnolegle. Umoliwiaj to wzy rozwidlenia i scalenia. Rozwidlenie ma jedno wejcie i wiele wyj przepyw wchodzcy jest rozdzielany. Scalenie ma wiele wej i jedno wyjcie. Przepyw zostanie przekazany do wyjcia tylko jeli przepywy dotary do wszystkich wej nastpuje synchronizacja. Mona te uy specyfikacji zczenia - przepyw dotrze na wyjcie jeli bdzie speniony okrelony warunek.

Do modelowania procesw rwnolegych na diagramie czynnoci uywamy belek synchronizacji, ktre s rodzajem wzw sterujcych. W jzyku UML istniej 2 podstawowe rodzaje belek synchronizacji: rozwidlenia oraz zczenia. Przepyw obiektw - Jako uzupenienie mona zaznaczy przepyw obiektw - Moe by przydatny np. kiedy obiekt jest tworzony i przekazywany dalej do przetwarzania - Obiekt musi by poczony z czynnoci/akcj - Symbolem jest prostokt z nazw - Mona te uy tzw. przekanikw danych

Diagramy czynnoci mwi, co si dzieje, ale nie mwi, kto co robi. Nie ma na takim diagramie informacji, ktra klasa jest odpowiedzialna za dan czynno. Aby pokaza, kto co robi, mona podzieli diagramy czynnoci na partycje, ktre pokazuj czynnoci wykony-

wane przez dan klas lub jednostk organizacyjn. Partycje nazywa si czsto torami (swimlane). Na diagramie czynnoci mona umieszcza nastpujce rodzaje sygnaw: - czasowe

- wysane - odebrane

Na diagramie czynnoci nie trzeba umieszcza informacji o parametrach, ale jeli zachodzi taka potrzeba, to mona je pokaza za pomoc wtykw. Trzeba wwczas zapewni, by parametry wyjciowe jednej czynnoci pasoway do parametrw wejciowych nastpnej czynnoci. Jeli parametry nie pasuj do siebie, to mona napisa przeksztacenie pozwalajce na przejcie od jednej czynnoci do drugiej. Przeksztacenie to powinno by wyraeniem niewywoujcym skutkw ubocznych. Przeksztacenie opisywane jest sowem transformation. Parametr czynnoci - Mona okreli, e obiekt jest parametrem czynnoci - Jest to obrazowane prostoktem na krawdzi czynnoci

Wytyczne dla tworzenia diagramw czynnoci 1. Naley ustali najwaniejsze czynnoci - nie mona przedstawi na jednym diagramie wszystkich czynnoci 2. Naley wybra obiekty przedsibiorstwa, ktre s zobowizane do realizacji bardziej oglnego przepywu. Mog to by elementy rzeczywiste, istniejce w sownictwie systemu, lub elementy abstrakcyjne. W obu przypadkach naley utworzy tor dla kadego wybranego obiektu. 3. Naley zidentyfikowa stan pocztkowy i kocowy modelowanego przepywu. 4. Przechodzc od stanu pocztkowego do kocowego naley modelowa kolejne stany czynnoci lub stany akcji. 5. W przypadku zoonych akcji lub czsto wystpujcych zbiorw akcji naley je poczy w stany czynnoci. Z kadym stanem skojarz oddzielny diagram czynnoci, ktry przedstawia zebrane nim akcje. 6. Naley zobrazowa przepywy czynnoci midzy stanami akcji i stanami czynnoci. Pierwsze powinny by brane pod uwag przepywy sekwencyjne, potem rozgazienia, na kocu rozwidlenia i scalenia. 7. Jeli w modelowanym przepywie czynnoci bior udzia istotne obiekty, naley je umieci na diagramie. Naley uwzgldnia zmieniajce si atrybuty i stany tych obiektw, jeli jest to konieczne do zrozumienia przepywu tych obiektw. Czynno na diagramie czynnoci moe skada si z podczynnoci i metod klas. Diagram podczynnoci mona oznaczy uywajc wideek. Wywoanie metody mona opisa za pomoc skadni nazwa-klasy::nazwa-metody.

Obsuga wyjtkw Pozwalaj modelowa czynno wykonywan w przypadku wystpienia bdu. W przypadku bdu sterowanie jest przekazywane do procedury obsugi wyjtku Procedura musi by nazwana.

Region rozszerzenia Pozwala okreli cz diagramu wykonywan wielokrotnie, w zalenoci od liczby elementw wejciowych. Wejcia i wyjcia nazywane s wzami rozszerzenia. Wykonanie regionu okrela acuch pisany kursyw, umieszczony wewntrz regionu: iterative, parallel, streaming.

Diagramami sekwencji czsto opisuje si przypadki uycia, a diagramami czynnoci - interfejsy. Diagramy sekwencji warto stosowa do przedstawiania komunikacji midzy obiektami, a diagramy czynnoci do przedstawiania algorytmw. Przykadowe diagramy czynnoci

2.7 Podsumowanie notacji UML Zawarto klas

Asocjacje na diagramie klas

Interfejsy, porty i poczenia na diagramie komponentw

Realizacja interfejsu

Ikony diagramu przypadkw uycia

Diagram przypadkw uycia

Ikony na diagramie czynnoci

Diagram czynnoci

Rodzaje wiadomoci na diagramie sekwencji

Diagram sekwencji

3. PROJEKTOWANIE OPROGRAMOWANIA 3.1 Fazy tworzenia oprogramowania Cykl ycia rozwoju systemu: 1. definicja wymogw systemu, 2. analiza - zrozumienie i sprawdzenie poprawnoci wymogw, 3. projektowanie - ustalenie architektury systemu, 4. implementacja - budowanie systemu, 5. testowanie - weryfikacja wymogw, 6. wdroenie. Dobre oprogramowanie powstaje iteracyjnie. Naley pracowa majc na wzgldzie oglny widok systemu i wwczas iterowa po fragmentach aplikacji, dopki nie bdzie ona ukoczona. Udany, pomylny projekt oprogramowania zaspokaja lub przekracza oczekiwania klienta, jest rozwijany w terminowy i ekonomiczny sposb oraz jest elastyczny pod ktem zmian i adaptacji. Cykl ycia rozwoju projektu musi promowa kreatywno i innowacj. Jednoczenie musi on by kontrolowany i mierzony by zapewni, e projekt jest kompletny. Proces obiektowego wytwarzania oprogramowania: - stwrz list featurew - stwrz diagram przypadkw uycia (istotne procesy wykonywane przez aplikacj oraz czynniki zewntrzne) - rozbij program na moduy funkcjonalnoci i nastpnie zdecyduj, w jakiej kolejnoci si nimi zaj - okrel pojedyncze wymagania dla kadego z moduw i upewnij si, e wpasowuj si one w oglny widok systemu - analiza domeny okrel, jak przypadki uycia mapuj si na obiekty w Twojej aplikacji i upewnij si, e zgadza si to z pogldem klienta - wstpny design uzupenij szczegy dot. obiektw, okrel zwizki pomidzy obiektami, zastosuj reguy obiektowoci i wzorce projektowe - implementacja pisz kod, testuj go i upewnij si, e wszystko dziaa jak naley - dostarczenie Waciwoci dobrych wymaga brak elementw nieistotnych, poprawno, kompletno, zwizo, precyzja, jasno, jednoznaczno, spjno, moliwo ledzenia, atwo modyfikacji, moliwo testowania (weryfikacji), wykonalno Dobry opis wymaga powinien: - By kompletny oraz niesprzeczny - Opisywa zewntrzne zachowanie systemu a nie sposb jego realizacji - Obejmowa ograniczenia przy jakich musi pracowa system - By atwy w modyfikacji - Bra pod uwag przysze moliwe zmiany wymaga wobec systemu - Opisywa zachowanie systemu w niepodanych sytuacjach Czynniki sukcesu w definiowaniu wymaga Zaangaowanie odpowiednich osb ze strony klienta Pene rozpoznanie wymaga, wykrycie sytuacji szczeglnych i nietypowych Sprawdzenie kompletnoci i spjnoci wymaga Okrelenie wymaga niefunkcjonalnych w sposb moliwy do weryfikacji Zmiany wymaga i bdce ich efektem zmiany w oprogramowaniu s permanentne i nieuniknione. System powinien by zawsze ulepszony wskutek wprowadzonej zmiany i pracy nad nim.

Aby podzieli duy problem na mniejsze funkcjonalnoci, ktrymi atwiej zarzdza, trzeba grupowa funkcjonalnoci w pakiety. Dekompozycji systemu mona dokona na diagramie pakietw i diagramie komponentw.

Definiowanie systemu 1. okrel priorytety projektu (wymagania funkcjonalne i niefunkcjonalne, skalowalno, osigi, koszt, terminarz) 2. zrewiduj istniejcy system (np. okrel, czy jego architektura lub cechy mog mie wpyw na projektowany system) 3. zdekomponuj system (rozbij go na mniejsze podsystemy) 4. okrel architektur (czyli jak podsystemy s ze sob powizane) oraz jaki sprzt jest wymagany 5. podejmij decyzje odnonie trwaoci obiektw (po wyczeniu systemu niektre z obiektw bd musiay by przechowywane). Mona wykorzysta relacyjne bazy danych, obiektowe bazy danych, pliki 6. okreli interfejsy podsystemw potraktuj podsystemy jak klasy. Kady podsystem jest odpowiedzialny za jakie istotne operacje. Zdecyduj, co to za operacje i opisz je jako interfejsy. 7. wybierz komponenty (modularne, samowystarczalne, wymienialne jednostki pracujce w systemie jak czarne skrzynki) 8. wybierz strategie systemu (jak jest wczany i wyczany, jak obsuguje bdy), jak radzi sobie z bezpieczestwem informacji, integralnoci danych, prywatnoci uytkownika 9. przeprowad kilkukrotnie kroki 2-8 (min. 2-3 razy) Projekt systemu - Oszacowa wymagania systemu oraz moliwo ponownego uycia kodu oraz wynik jego dziaalnoci - Podzieli system na podsystemy - Zaplanowa ponowne uycie kodu (biblioteki, struktury, poprzednie programy) - Zanalizowa problem wspbienoci - Zaplanowa uycie zasobw - Zaplanowa sposb skadowania danych - Zaplanowa sposb uruchamiania i wyczania systemu oraz radzenia sobie z awariami - Rozway optymalizacj systemu Jeli w projektowanym systemie konieczne jest uycie nieprzenonego kodu (np. takiego, ktry bdzie dziaa tylko na jednej konkretnej platformie sprztowej), naley go wyodrbni i usun z klasy, tj. umieci w osobnej klasie lub przynajmniej w metodzie, ktr bdzie mona przesoni. Nie naley umieszcza kodu zalenego od konkretnej platformy w gwnej klasie. Podczas projektowania systemu naley odracza wgbianie si w szczegy tak dugo, jak jest to moliwe, by nie straci szerokiego spojrzenia na caoksztat projektu. Projekt klas W duym projekcie tworzenie jednego wielkiego diagramu klas dla caego projektu nie jest pomocne diagram staje si mao czytelny i konsternujcy. Warto go podzieli na atwiejsze w zarzdzaniu czci. W przypadku duego projektu: - stwrz jeden diagram top-level zawierajcy max 15 kluczowych klas. Ma on dostarcza oglny widok aplikacji bez wnikania w szczegy. Musi on zawiera kluczowe klasy dla tych grup obiektw, ktre s najistotniejsze. - stwrz diagramy second-level z jedn kluczow klas w centrum diagramu, otoczon przez 5-10 klas uzupeniajcych i ich asocjacje z kluczow klas. Dodaj szczegy ukazujce atrybuty i operacje. - jeeli wystpuje istotna agregacja lub kompozycja, poka j i jej czci skadowe na osobnym diagramie - jeeli wystpuje istotna hierarchia dziedziczenia, umie nadklas i jej podklasy na osobnym diagramie

- jeeli ktry z diagramw second-level jest zbyt zloony i wystpuje na nim ponad 10 klas uzupeniajcych, rozwa stworzenie diagramu third-level Na adnym poziomie diagramu nie powinno si znale wicej ni 20 klas. Kady diagram klas powinien mie jeden motyw przewodni. Czasami na diagramie second-level warto umieci dodatkowe klasy diagramu toplevel, bo w ten sposb wida jak kluczowa klasa diagramu second-level wpisuje si w oglny zarys systemu. Projekt obiektw - Wystartowa z modelu klas z etapu analizy i doda elementy odpowiedzialne za implementacje - Znale informacje ktre musz by przechowywane pomidzy wykonaniem rnych operacji - Podzieli wiksze operacje na prostsze pod-operacje majc na wzgldzie dobre zdefiniowanie odpowiedzialnoci kadej podprocedury - Zoptymalizowa cao - Wdroy enkapsulacje - doda metody pozwalajce na oddzielenie jdra systemu od innych obiektw - Podj decyzje co do sposobu przedstawiania asocjacji za pomoc struktury jzyka (sposb komunikowania si pomidzy klasami) - Ponownie przeanalizowa kod pod ktem ew. zwizkw dziedziczenia - Napisa kod Ponadto warto pamita o: - moliwoci obiektowego podejcia do algorytmw - moliwoci generowania kodu wprost z maszyny stanowej - hermetyzacji - ostronoci w projektowaniu operacji zmieniajcych stan obiektu - jak najpniejszym implementowaniu asocjacji Wytwarzanie oprogramowania zgodne z Rational Unified Process Struktura projektu wzgldem komponentw procesu: Modelowanie biznesowe identyfikacja podanych umiejtnoci systemu i potrzeb uytkownika Wymagania tworzenie wizji systemu wraz z zestawem wymaga funkcjonalnych i niefunkcjonalnych Analiza i projekt opis tego, jak system zostanie zrealizowany w fazie implementacji Implementacja tworzenie kodu, ktry ostatecznie stanie si dziaajcym systemem Test weryfikacja caego systemu Wdroenie dostarczenie systemu i szkolenia dot. obsugi klientowi

Struktura projektu wzgldem czasu: Incepcja okrelanie wizji projektu

Elaboracja planowanie niezbdnych czynnoci i wymaganych zasobw; okrelanie ficzerw i projektowanie architektury Konstrukcja budowanie projektu jako serii inkrementacyjnych iteracji Przekazanie zapewnienie produktu spoeczoci uytkowikw (wytworzenie, dostarczenie i szkolenie)

3.2 Architektura oprogramowania Architektura podkrela struktur projektu i uwypukla najwaniejsze czci programu oraz zwizki pomidzy tymi czciami. Te czci programu, ktre s naprawd wane pod ktem architektonicznym, powinny by brane pod uwag jako pierwsze. Prbujc ustali, czy co jest istotne architektonicznie, trzeba odpowiedzie na nastpujce pytania: - czy jest to esencjonalna cz systemu? (tj. czy mona sobie wyobrazi system bez tej funkcjonalnoci) - czy jeste pewien, co oznacza opis danego featurea? Jeli nie, to prawdopodobnie warto zwrci na niego uwag, gdy moe zaj mnstwo czasu lub stwarza problemy z reszt systemu - czy wydaje si to bardzo trudne do oprogramowania? Architektura jest modelem pokazujcym struktur i dynamik dziaania caego systemu oprogramowania. Model architektoniczny powinien jednoznacznie wynika z modelu wymaga. Jednym z typw diagramw przydatnych do tworzenia modelu architektonicznego s diagramy komponentw. Podzia na komponenty jest bardzo wan decyzj architektoniczn. Powinna by ona podjta na podstawie dobrze okrelonych przesanek. Pierwsz przesank jest konieczno zapewnienia, aby komponent realizowa dobrze zasad abstrakcji. Oznacza to, e komponent powinien grupowa w sobie elementy realizujce pewien zwarty podsystem. Dobry komponent powinien odpowiada jakiemu zbiorowi cile powizanych ze sob poj ze rodowiska lub elementw wykonawczych, realizujcych pewne cile zwizane ze sob przypadki uycia systemu. Ze zwartoci komponentw czy si druga przesanka podziau na komponenty realizacja zasady zamykania informacji. Oznacza ona, e podsystem realizowany przez komponent powinien by ukryty przed wiatem zewntrznym. Jednoczenei komunikacja z pozostaymi komponentami powinna si odbywa przez jak najwszy styk. W ten sposb wizy midzy komponentami s stosunkowo sabe. Wikszo komunikacji odbywa si wewntrz komponentw. Komunikacja midzy komponentami odbywa si tylko wtedy, gdy jest to niezbdne. Dobra architektura definiuje podzia systemu na komponenty o wysokiej zwartoci, majce jednoczenie sabe wizy z innymi komponentami. Architektura podzielona na dobrze wydzielone komponenty moe by atwo rozszerzana o nowe skadniki, a take atwiej poddaje si zmianom. Znaczna czc wspczesnych wzorcwe architektonicznych opiera si na modelu warstwowym. W modelu tym system jest podzielony na kilka warstw. Warstwa najwysza jest warstw styku z uytkownikiem. Umieszczone s w niej komponenty odpowiedzialne za bezporednie porozumiewanie si z uytkownikiem. W nastpnej warstwie znajduj si komponenty odpowiedzialne za logik dziaania aplikacji. To one powinny wiedzie, w jaki sposb ma si zachowywa system we wsppracy z uytkownikiem. Realizuj one wszystkie scenariusze przypadkw uycia systemu. Trzecia warstwa zawiera logik rodowiska. W tej warstwie wykonywane s przez system czynnoci zwizane z realizacj procesw biznesowych czy te operacja definiowane przez analitykw w modelu klas na poziomie wymaga. Najnisza warstwa jest warstw przechowywania danych. W tej warstwie wszystkie dane, ktre przetwarzane s w warstwach wyszych, umieszczane s w sposb trway. Najczciej na tym poziomie znajduj si komponenty bazy danych. Wszystkie te warstwy s od siebie zalene komunikuj si midzy sob. Zasad jest, e komunikacja nastpuje tylko pomidzy warstwami ssiadujcymi. Wany jest rwnie kierunek komunikacji. Warstwa styku z uytkownikiem i warstwa logiki rodowiska komunikuj si tylko z warstw nisz od siebie, a warstwa logiki aplikacji komunikuje si z obiema tymi warstwami.

Czasami warto wydzieli 3 gwne podsystemy: prezentacji (interakcja z uytkownikiem), aplikacji (logika biznesowa) i danych (trwao obiektw) 3.3 Inne kwestie zwizane z wytwarzaniem oprogramowania Miary powodzenia projektu informatycznego - Terminowa realizacja projektu - Realizacja projektu w ramach zaoonego budetu - Spenienie rzeczywistych potrzeb klienta (zleceniodawcy) Wraz ze wzrostem zoonoci systemu rosn zagroenia powodzenia projektu. Gwne rda zagroe - Niedostateczne zrozumienie istoty problemu przez wykonawcw (zagroenie ze strony wymaga) - Brak lub za komunikacja wewntrz zespou - Zy podzia pracy - Zagroenia techniczne - wybr niewaciwych technologii - Niedostateczne umiejtnoci zespou - Zagroenia zewntrzne (np. polityczne zmiana ustawodawstwa) Trzy kroki do tworzenia dobrego oprogramowania: - upewnij si, e oprogramowanie robi to, czego wymaga od niego klient - zastosuj podstawowe reguy obiektowoci (enkapsulacja, dziedziczenie, polimorfizm), by uzyska elastyczno - d do projektu umoliwiajcego powtrne uycie, rozszerzalnego i atwego w konserwacji