Modelovanie štruktúry

Transcription

1 Modelovanie štruktúry Poznámky k prednáškam z predmetu Modelovanie softvéru Valentino Vranić vranic@stuba.sk Ústav informatiky, informačných systémov a softvérového inžinierstva Fakulta informatiky a informačných technológií Slovenská technická univerzita v Bratislave 11. október 2016

2 OBSAH i Obsah 1 Úvod 1 2 Diagram tried 2 3 Diagram balíkov Definícia požadovaného rozhrania na strane klienta Analýza architektúra návrh 15 5 Diagram kompozitnej štruktúry Kompozitná štruktúra Kolaborácia Kolaborácia ako realizácia prípadu použitia Štruktúra komponentov Spojenie komponentov assembly Spojenie komponentov delegate Príklad Príklad roly Sumarizácia 19

3 1 ÚVOD 1 1 Úvod Štruktúra softvérového systému Čo je štruktúra softvérového systému Na základe čoho ju modelovať Ako ju vyjadriť v jazyku UML Štruktúra softvérového systému Štruktúra softvérového systému: časti, z ktorých sa softvérový systém skladá Program je kód, ale aj jeho vykonávanie Štruktúra je najpresnejšie vyjadrená kódom Ale aj program vo vykonávaní má štruktúru Conwayov zákon: Organizácie, ktoré navrhujú systémy, sú ohraničené tak, aby vyrábali systémy, ktoré sú kópiami komunikačných štruktúr týchto organizácií. Conway, M. E. How do Committees Invent?, Datamation, (14) 4, April Štruktúra má byť odvodená od správania Správanie je zachytené v prípadoch použitia Zodpovedajúcu štruktúru možno spoznať priamo v tokoch prípadov použitia Vhodným medzikrokom je pokus o vyjadrenie správania technikou, ktorá vynucuje exponovanie štruktúry diagramy sekvencií Diagramy aktivít (ako alternatíva) to neumožňujú v dostatočnej miere zachytávajú (ak vôbec) len údajové objekty, prípadne naznačujú riadiace objekty prostredníctvom úsekov (partitions) Diagramy štruktúry v UML Diagram tried class diagram Diagram objektov object diagram Diagram kompozitnej štruktúry composite structure diagram Diagram rozloženia deployment diagram Diagram komponentov component diagram Diagram balíkov package diagram 1

4 2 DIAGRAM TRIED 2 Stereotypy tried podľa Unified Processu Stereotypy umožňujú rozširovať jazyk UML o nové prvky odvodené od jestvujúcich Unified Process rozlišuje: Boundary triedy rozhrania používateľské rozhranie (typicky formuláre GUI), ale aj technické rozhranie Control riadiace prvky; triedy s metódami, ktoré implementujú kľúčovú funkcionalitu Entity údajové prvky; entity, s ktorými sa v systéme pracuje väčšinou jednoduchšie metódy (zobrazené do databázových tabuliek: object-relational mapping) «boundary» FindForm «entity» ProductCategory 1 * «control» ProductManager «entity» Product «entity» Image Vzor Model-View-Controller (MVC) 2 2 Diagram tried Návrhové vzory často možno rozpoznať aj iba na základe vzhľadu diagramu (neberúc do úvahy textové označenia). 2

5 2 DIAGRAM TRIED 3 Štruktúra vzoru Visitor Štruktúra vzoru Observer 2 Podľa

6 2 DIAGRAM TRIED 4 Štruktúra vzoru Strategy Vzor Strategy vo Swingu Štruktúra vzoru Composite Client «interface» Component operation() * Leaf +operation() Composite +operation() +add(component : Component) +remove(component : Component) +getchild(i : Integer) Diagram tried Znázorňuje (predovšetkým) triedy a vzťahy medzi nimi Môže obsahovať aj rozhrania, balíky a objekty

7 2 DIAGRAM TRIED 5 Vzťahy medzi triedami: Asociácia všeobecný vzťah Agregácia hodnotou (kompozícia) referenciou Generalizácia/špecializácia dedenie Závislosť Asociácia Všeobecná asociácia je zvlášť užitočná keď začíname skúmať vzťahy medzi triedami Vtedy ešte nevieme ich presný význam Viditeľnosť atribútov a operácií Viditeľnosť atribútov a operácií ako modifikátory prístupu v Jave: + public # protected private package Detaily triedy Kruh Kruh -stred : Bod -polomer : int «constructor» +Kruh(stred : Bod, polomer : double) +nakresli() : void +nakresli(farba : int) : void

8 2 DIAGRAM TRIED 6 Agregácia Agregácia plný kosoštvorec hodnotou prázdný kosoštvorec referenciou Presný význam: plný kosoštvorec agregácia, pri ktorej agregujúci objekt nesie zodpovednost za existenciu a uloženie agregovaných objektov (composite) prázdný kosoštvorec zdielaná agregácia, pri ktorej aj iné objekty môžu agregovat rovnaký objekt (shared) Kruh -polomer : int «constructor» +Kruh(stred : Bod, polomer : double) +nakresli() : void Bod -x : double -y : double «constructor» +Bod(x : double, y : double) Asociačná rola Asociačná rola (association role) rola triedy vo vzťahu k inej triede Inštancia triedy Bod v inštancii triedy Kruh hrá rolu stredu Kruh -polomer : int «constructor» +Kruh(stred : Bod, polomer : double) +nakresli() : void +vypln(farba:int) : void -stred Bod -x : double -y : double «constructor» +Bod(x : double, y : double) Násobnosť Násobnosť (multiplicity) vzťahu koľko inštancií triedy pripadá na výskyt inštancie inej triedy Kruh má práve jeden stred, a ten stred patrí len jemu Násobnosť sa často označuje ako kardinalita

9 2 DIAGRAM TRIED 7 Kruh -polomer : int «constructor» +Kruh(stred : Bod, polomer : double) +nakresli() : void 1 -stred 1 Bod -x : double -y : double «constructor» +Bod(x : double, y : double) Príklady násobností Študent študuje viac predmetov, a ten istý predmet študujú viaceri študenti Študent študuje práve v jednom ročníku, a v tom istom ročníku študujú viaceri študenti Auto má 3 až 6 kolies, a koleso patrí len jednému autu Generalizácia/špecializácia Generalizácia/špecializácia dedenie Trieda Kruh je špecializáciou triedy Utvar Trieda Utvar je abstraktná názov kurzívou Utvar -farba : int Kruh -polomer : int «constructor» +Kruh(stred : Bod, polomer : double) +nakresli() : void +nakresli(farba : int) : void

10 2 DIAGRAM TRIED 8 Značenie abstraktných tried a operácií Pre zvýšenie čitateľnosti možno použiť označenie {abstract} Utvar {abstract} -farba : int {abstract} {abstract} Kruh -polomer : int «constructor» +Kruh(stred : Bod, polomer : double) +nakresli() : void +nakresli(farba : int) : void Realizácia rozhrania Rozhrania stereotyp interface Trieda Utvar realizuje (implementuje) rozhranie Kresleny Tento vzťah tiež predstavuje formu dedenia dedenie správania Rozhrania v UML nemôžu mať atribúty (narozdiel napr. od Javy) Uvedenie atribútu v rozhraní v UML znamená, že ho rozhranie predpisuje tak ako metódu Triedy, ktoré také rozhranie realizujú, musia predpísané atribúty implementovať Utvar -farba : int #setfarba(farba : int) : void #getfarba(farba : int) : void Kruh -polomer : int «constructor» +Kruh(stred : Bod, polomer : double) +nakresli() : void +nakresli(farba : int) : void +rotuj(uhol : double) : void «interface» Kresleny nakresli() : void nakresli(farba : int) : void «interface» Rotovatelny rotuj(uhol : double) : void

11 2 DIAGRAM TRIED 9 Detailný diagram tried «interface» Kresleny Utvar -farba : int #setfarba(farba: int) : void #getfarba(farba: int) : void nakresli() : void nakresli(farba : int) : void «interface» Rotovatelny rotuj(uhol : double) : void Kruh -polomer: int «constructor» +Kruh(stred : Bod, polomer : double) +nakresli() : void +nakresli(farba : int) : void +rotuj(uhol : double) : void 1 -stred 1 Bod -x : double -y : double «constructor» +Bod(x : double, y : double) Použitie rozhrania a väzba závislosti Použitie rozhrania predstavuje väzbu závislosti niekedy sa používa stereotyp use Pomocou tejto väzby sa dá vyjadriť hocijaká závislosť Závislý je prvok, z ktorého vychádza šípka klient (client) Zmeny klienta nemajú vplyv na prvok, ku ktorému šípka smeruje poskytovateľ (supplier) Utvar «interface» Kresleny nakresli() : void nakresli(farba : int) : void «use» GUtvary +main(args : String[]) : void Kruh «interface» Rotovatelny «use» +nakresli() : void +nakresli(farba : int) : void +rotuj(uhol : double) : void rotuj(uhol : double) : void

12 2 DIAGRAM TRIED 10 Obsah diagramu tried Diagram tried nemusí obsahovať všetky detaily V jednom diagrame nemusia byť všetky triedy Nemusíme znázorniť všetky vzťahy medzi znázornenými triedami Každý diagram má niesť istý základný odkaz Hierarchia dedenia Niekedy chceme vyjadriť len hierarchiu dedenia Možno použiť aj zdrúženú šípku Príklad s grafickými útvarmi class Bod { private double x, y; public Bod(double x, double y) {... } } interface Kresleny { void nakresli(); void nakresli(int farba); } interface Rotovatelny { void rotuj(double uhol); } abstract class Utvar implements Kresleny, Rotovatelny { private int farba; public void vypln(int farba) {... } protected void setfarba(int farba) {... }

13 3 DIAGRAM BALÍKOV 11 } protected int getfarba() {... } class Kruh extends Utvar { private Bod c; private double r; Kruh(Bod c, double r) {... } public void nakresli() {... } public void nakresli(int farba) {... } public void vypln(int farba) {... } public void rotuj(double uhol) {... } } Vhniezdené triedy UML umožňuje vyjadriť len statické vhniezdenie tried Na vyjadrenie anonymných tried v Jave (druh vnútorných tried, teda dynamické vhniezdenie) R. C. Martin navrhuje použiť stereotyp anonymous 3, ale statickosť to nezmení Diagram objektov Ďalší štrukturálny pohľad špeciálny prípad diagramu tried Znázorňuje vzťahy medzi inštanciami tried v určitom okamihu vykonávania programu Môže obsahovať hodnoty atribútov 3 Diagram balíkov Balíky Package diagram Potreba za väčšími štrukturálnymi jednotkami Každý balík predstavuje priestor názvov (namespace) Kvalifikované názvy (::) 3 R. C. Martin. UML for Java Programmers. Prentice Hall, 2003.

14 3 DIAGRAM BALÍKOV 12 Použitie: vyjadrenie hierarchie štruktúry vyjadrenie závislosti medzi štrukturálnymi jednotkami Závislosti medzi balíkmi ImageConvertors::VectorToBMPConvertor GraphicalShapes::BasicShapes::BasicShape ImageConvertors GraphicalShapes Textures FileManagement Závislosti nie sú tranzitívne A B C A C Dôsledkom netranzitívnosti závislosti je to, že ak sa rozhranie balíka C zmeni, pravdepodobne sa bude musieť zmeniť aj jadro balíka B, ale balík A sa nebude musieť meniť Cirkulárne závislosti Cirkulárne závislosti vyriešime reštrukturalizáciou balíkov Na analytickej úrovni nemusia prekážať

15 3 DIAGRAM BALÍKOV 13 A B A B A C Import BasicShapes GShape Circle Rectangle «import» CurvedShapes GShape BCurve BCurve

16 3 DIAGRAM BALÍKOV 14 Vhniezdenie a prístup GraphicalShapes BasicShapes GShape Circle Rectangle «access» «access» AdditionalShapes CurvedShapes BasicShapes::GShape BCurve BCurve Vhniezdenie vyjadrené väzbou

17 4 ANALÝZA ARCHITEKTÚRA NÁVRH 15 Viditeľnosť obsahu balíka P D A C P +A +B -C -D C 3.1 Definícia požadovaného rozhrania na strane klienta CP Client Int PP ServiceProvider package CP; class Client {... } interface Int {... } \\ klient predpisuje rozhranie package PP; \\ rozhranie implementuje \\ poskytovatel z ineho balika class ServiceProvider implements Int {... } Balík CP definuje rozhranie Int, ale ho nerealizuje (neimplementuje). Trieda Client vnútorne definuje funkcionalitu na základe objektov, ktoré zodpovedajú tomuto rozhraniu (používa/požaduje rozhranie Int). Rozhranie implementuje poskytovateľ z balíka PP a dodáva príslušné objekty, na základe ktorých sa dotvorí funcionalita triedy Client z balíka CP. Toto je typické pre rámce (frameworks), pričom balík CP predstavuje rámec, a balík PP aplikačnú funkcionalitu. 4 Analýza architektúra návrh Architektúra Čo systém je nie je bezprostredne dané prípadmi použitia

18 5 DIAGRAM KOMPOZITNEJ ŠTRUKTÚRY 16 Základnú koncepciu poznáme z aplikačnej domény daná je typom systému Tento základ je pomerne stabilný architektúra Prípady použitia vnášajú ďalšie prvky štruktúry bezprostredne potrebné pre ich zabezpečenie, ale aj v nich môžu byť viditeľné prvky, ktoré tvoria architektúru Od analýzy k návrhu Čo ďalej: detailna štruktúra a návrh Ďalší návrhový model Plynulé rozpracovanie analytického modelu do návrhové je problematické Analytický model je vysokokonceptuálny ťažko na tomto základe dosiahnuť technickú presnosť na úrovni kódu Do úvahy prichádza vytvorenie väzieb (traceability) 5 Diagram kompozitnej štruktúry 5.1 Kompozitná štruktúra Kompozitná štruktúra: štruktúra v zmysle kompozície prepojených prvkov, ktoré predstavujú inštancie v čase vykonávania Doteraz sme používali lexikálne vhniezdenie balík v balíku, triedy v balíku a pod. 5.2 Kolaborácia Kolaborácia: štruktúra spolupracujúcich (kolaborujúcich) prvkov (rolí), ktoré spoločne zabezpečujú určité správanie Takto sa napr. dajú vyjadriť návrhové vzory

19 5 DIAGRAM KOMPOZITNEJ ŠTRUKTÚRY Kolaborácia ako realizácia prípadu použitia Spravuj produkt Vyhladaj produkt productmanager ProductManager createproduct() readproduct() updateproduct() removeproduct() product productfinder Product «create» Product() read() update() remove() ProductManager findproduct() product Product find() 5.4 Štruktúra komponentov Chceme vyjadriť časti, z ktorých pozostáva komponent, ako sú prepojené a ako a ktoré sú exponované Dá sa použiť aj keď sme ešte nestanovili statickú štruktúru (diagram tried) 4 To je v duchu odvodenia štruktúry zo správania Prvky: part property port connector delegate/assembly provided/required interface 5.5 Spojenie komponentov assembly ComponentX ComponentY 4 scompositestructurediagram.pdf

20 5 DIAGRAM KOMPOZITNEJ ŠTRUKTÚRY Spojenie komponentov delegate Component1 PartA InterfaceX PartB PartB InterfaceX Component2 Component3 5.7 Príklad SpravaObjednavok :Objednavka ManazmentTransakcii :Kosik :Vyrobok ManazmentTransakcii FinancnyManazment 5.8 Príklad roly Nemusíme sa viazať na presné typy môžeme modelovať pomocou rolí Dynamická štruktúra najprv typy budú spresnené po jej preskúmaní

21 6 SUMARIZÁCIA 19 SpravaObjednavok objednavka ManazmentTransakcii kosik vyrobok ManazmentTransakcii FinancnyManazment 6 Sumarizácia Sumarizácia Architektúra je daná typom systému Ďalšia štruktúra je určená potrebami zabezpečenia správania, ktoré definujú prípady použitia Modelovanie štruktúry zvideteľňuje vzťahy