Szoftvertechnolgia s Grafikus Felhasznli Fellet Tervezse UML viselkedsi

Szoftvertechnológia és Grafikus Felhasználói Felület Tervezése UML viselkedési és implementációs diagramok Nem-UML diagrammok http: //users. nik. uni-obuda. hu/prog 4/ 1

UML • Előzmény: RUP (Rational Unified Process) 2

UML • Források – Cseri Eszter „Car. Shop” példa projekt képei – Miskolci Egyetem open jegyzet https: //www. tankonyvtar. hu/hu/tartalom/tamop 425/0046_szoftverfejlesztes/index. html – https: //docs. microsoft. com/en-us/visualstudio/modeling/create-models-for-your-app – https: //sparxsystems. com. au/resources/tutorials/uml/part 1. html – https: //www. uml-diagrams. org/ • UML "The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. The UML offers a standard way to write a system's blueprints, including conceptual things such as business processes and system functions as well as concrete things such as programming language statements, database schemas, and reusable software components. " 3

UML • UML Alapvető elvek – Kifejező vizuális modellező nyelv biztosítása – Lehetőség az alap koncepció bővítésére és specializálására – Programozási nyelvtől és módszertantól független legyen – Biztosítson formális alapot a modellező nyelv megértéséhez – Támogatja az objektum orientált eszközök fejlesztését – Az eddigi gyakorlati tapasztalatok ("best practices") integrálása 4

UML alternatívák • "UML is the worst possible notation. . . except for all the others" (Forrás: C 2 Wiki) • Saját megközelítés létrehozása? Az UML szigorú (elvileg…) – Elhagyható minden, ami nem szükséges (agilissé tétel) – Saját igényekhez jobban illeszkedik – A kódolástól távolabbi, az egyedi valósághoz jobban illeszkedő – A modellező nyelvnek és a problématerületnek minél közelebbinek kell lennie kódgenerálás? • Rengeteg különféle megközelítés https: //en. wikipedia. org/wiki/Modeling_language – Folyamatábrák (…) – Domain-Specific Modeling, Domain-Specific Languages – Jackson Structured Programming – Sys. ML 5

UML tool • Rengeteg lehetséges eszköz – Microsoft Visio – Visual Paradigm for UML (elérés kérhető!) – Rational Rose • Enterprise Architect – Talán legelterjedtebb, de fizetős (vagy: Trial változat) – /technology/ -n van fenn egy változat… ; ) • DIA (dia-installer. de ) – dia-setup-0. 97. 2 -2 -unsigned. exe /S – cd "c: Program Files (x 86)Diabin" – SET LANG=en – diaw --integrated • https: //en. wikipedia. org/wiki/List_of_Unified_Modeling_Language_tools 6

UML Diagram Típusok 7

Viselkedési diagramok • Használati eset diagram (Use case diagram) • Aktivitás diagram (Activity diagram) • Állapotgép diagram ( (Finite) state machine diagram ) • Kölcsönhatás diagramok (Interaction diagrams): Sequence, Communication, Timing Nem UML diagram, de a kész termék viselkedését és kinézetét írja le: • Kinézet terv (Wireframe ) 8

Use case diagram • Aktor, Használati eset • Kapcsolatok – Egyszerű (aktor és használati eset között) – Általánosítás/pontosítás; öröklődés (Inherits) (Két aktor VAGY két használati eset között) – Számosság (aktor és használati eset között) – Tartalmazás (Includes, csak használati esetek között) – Kibővítés (Extends, csak használati esetek között) • A nagyon bonyolult programok kivételével talán túl bonyolult (személyes vélemény: feleslegesen túlméretezett) – Táblázattal egyszerűbben leírható – Hierarchikus vagy role-based authorizationt is támogat, de mindkettő ugyanolyan jól leírható táblázattal 9

Use case diagram 10

Activity diagram • Az egyes használati esetek belső folyamatainak, vagy a használati esetek egymás után következésének leírása – Alap kiindulópont: 1 use case = 1 activity diagram – Egy diagramon belül egyéb use case-ek is előjöhetnek • Alapelemei – Tevékenységek (lekerekített sarkú téglalap) – Átmenetek (nyíl) – Döntési pont (rombusz) – Kezdőállapot: ebbe kerül a rendszer/modul/use case, amikor létrejön, ebbe az állapotba nem vezethet átmenet (kitöltött kör) – Végállapot: az rendszer/modul/use case befejező állapota, ebből az állapotból nem indulhat ki átmenet (körbe rajzolt pont) 11

Activity diagram 12

13

Activity diagram 14

State diagram • Állapotok egymás után következésének leírása – Rendszer- és objektum-állapotra is használható • Alapelemei – Állapot (kerekített sarkú téglalap, név kötelező) – Kezdőállapot: ebbe kerül a rendszer/objektum, amikor létrejön, ebbe az állapotba nem vezethet átmenet (kitöltött kör) – Végállapot: az rendszer/objektum befejező állapota, ebből az állapotból nem indulhat ki átmenet (körbe rajzolt pont) • „Finite state machine” reprezentálására nem az egyetlen eszköz – State transition table (első oszlop: állapotok; első sor: események; minden cella: feltételek+új állapot) – Petri hálók (feltételekhez vagy számossághoz kötött, eseményvezérelt állapotváltozások) – SDL state machine, stb… 15

State diagram • Az állapotoknál problémás lehet a „minden eshetőség” lekezelése (pl. ’=’ gomb operand 2 -től eltérő státuszban? ) • Probléma: sok egymást keresztező nyíl, könnyen átláthatatlan 16

Interaction diagrams • Az interakciós diagramok közül mindhárom (sequence, communication, timing) ugyanarra használható – Egy folyamat résztvevőinek jelölése (aktorok, modulok, layerek) – A résztvevők közötti kommunikációs folyamatok jelölése – Timing: időzítési információk, megkötések, állapotok is jelöltek – Sequence: ciklusok, feltételek, élettartamok is jelöltek – Communication: cask a résztvevők és a sorrend – Minden interakciós diagram átkonvertálható szekvencia diagramba; fordítva ez csak a komplex interakciókat nem tartalmazó szekvencia diagramokra igaz 17

Interaction diagrams • Communication diagram – Csomópontok (aktorok / téglalapok) – A csomópontok között átvezető élek = kommunikáció – Az éleken esetleg sorrend jelezhető • Timing diagram – A sorokban találhatóak a kommunikációs felek (aktorok/modulok/alrendszerek) – Minden sorban idővonal – Jelezhetőek az állapotváltozások és a kommunikáció • Sequence diagram – Az oszlopokban találhatóak a kommunikációs felek – Minden oszlopon jelölt az adott szereplő élettartama – Az oszlopok közötti vízszintes, egyirányú nyilak jelzik a kommunikációt; fentről lefelé haladó sorrendben 18

Communication diagram 19

Timing diagram 20

Sequence diagram 21

Sequence diagram 22

Sequence diagram 23

Wireframe • Az UML létrehozásánál nem gondoltak arra, hogy a megjelenítés a modell része lehet – A gyakorlatban kihagyhatatlan lépés – A legelső prototípus, amit a felhasználónak oda tudunk adni • Létrehozása – Konkrétan a fejlesztőeszközzel, funkcionalitással és eseménykezelőkkel nem rendelkező ablakok összerakása – Külön wireframe eszközzel (vezérlők helyett csak placeholderek) – Rajzprogrammal (Concept Art, a dizájner sokszor „elszáll”) • Folyamatok előrejelzése kötelező – Use case/activity felület kapcsolatok meghatározása – Felületek közötti átvezetések meghatározása (pontosan melyik vezérlővel lehet átugrani, anélkül a projekt nagyon könnyen követhetetlenné válik) 24

Wireframe 25

UML Diagram Típusok 26

Strukturális UML diagramok • Telepítési diagram (deployment diagram) • Komponens diagram (component diagram) • Csomag diagram (package diagram ) • Összetett struktúra/architektúra diagram (composite structure diagram, csak belső asszociációk áttekintésére, ritkán használt) • Osztály/objektum diagram (class/object diagram) • Nem UML, de fontos fejlesztési diagramok (Implementation diagrams): – Tábla struktúra diagram (table structure diagram) – Egyed-Kapcsolat diagram (entity-relationship diagram) – Fejlesztési időbeosztás (gantt diagram) 27

Deployment diagram • A rendszer futásának körülményeit/elemeit bemutató diagram • A szoftver elemei – Végrehajtható program modulok – Beállítások, konfigurációs file-ok – Adatok, adatbázis • A működtető elemek lehetnek – Számítógépek – Hálózati csomópontok – Végrehajtási környezetek (virtuális gép, alkalmazás szerver stb. ) • Sorrendileg a LEGELSŐ diagram is lehet – Akár a viselkedési diagramok előtt is hasznos lehet – A fejlesztési folyamat legelején tisztázni kell a rendszer futtatásának / használásának körülményeit 28

Deployment diagram 29

Belső struktúra • Component diagram vs Package diagram majdnem ugyanaz – „In UML, components are groups of classes that are deployed together and packages are a general grouping device for model elements. – Packages can group any model elements, even things like use cases, but in practice they usually group classes, so components and packages tend to be synonymous. „ (Michael Feathers; "Working Effectively with Legacy Code”) • Egy lehetséges megkülönböztetés – Package: felépítés, tartalmazás, függőségek (Packageable elements: Type, Class, Use Case, Component, Package, Constraint, Dependency, Event) – Component: egymással való kapcsolódások/interfészek (Subsystems, Service-Oriented-Architecture, SOA) (A komponens szempontjából mindegy, hogy egy alrendszer helyi vagy távoli) 30

Package diagram 31

Component diagram 32

Component diagram 33

Class/Object diagram • Osztályok vagy konkrét objektumokról szólnak – Class diagram: osztályok adattagjai, metódusai – Sokkal a fejlesztés előtt nem kell feltétlenül pontos kép az elkészülő osztályokról – A korai tervezési fázishoz elég, ha megvannak a package diagram interfészei – Pregroom során az architect feladata is lehet akár: a feladatok modulok/osztályokra bontása, a többi fejlesztő így már konkrét elkészítendő osztályokat kap • Object diagram – A futtatás közben létrehozott példányok kapcsolatai – UML 1. 4. 2. : „a class diagram with objects and no classes. ” – UML 2. 4 & 2. 5: Minimális említés, de „UML 2. 5 specification simply provides no definition of object diagram. ” 34

Öröklés / Specializáció (ismétlés) 35

OO Kapcsolatok • Dependency: Típus közvetlen/ közvetett használata • Asszociáció: Esetleges, teljesen különálló objektumok • Aggregáció: Tartalmazás, különálló élettartam • Kompozíció: Tartalmazás, függő élettartam 36

Class diagram 37

38

Class diagram (Visual Studio) 39

Code map (VS) • Solution explorer / jobb katt / Show on code map • Minden node és él kattintható, zoomolható, kifejthető • Meg lehet találni azokat az osztályokat, amik rétegsértést követnek el • Az aktuális projektben: UI Data kapcsolat • Model kapcsolat: nem jó, de Prog 3 -ban is engedélyezve volt, hogy a Data osztályait használjuk felsőbb rétegekben (csak az adat entity osztályokat!) 40

Spagetthi code • A model osztályok használata így érthető / többékevésbé elfogadható, viszont ott van egy hivatkozás a Db. Context leszármazottra • Ez óriási baj, elvégre korlátlan hozzáférést jelent a DB felé a GUI rétegből (a Logic megkerülhető) • A Logic létrehozásához kell Factory pattern 41

Table structure diagram • Ez a három nem UML diagram • Viszont szinte minden szoftverfejlesztési projektben használtak 42

Entity-relationship diagram • Általában megelőzi a tábla struktúra diagramot • A mezők ekkor még nem annyira fontosak • Relation + Entities • Attribute • Relation-attribute • Primary key 43

ER diagram 44

Gantt diagram 45

Software tervezés (egy lehetséges) menete 1. Deployment diagram – A rendszer milyen körülmények között, hogyan lesz használva 2. Behavioral diagrams – A rendszernek milyen működési feladatokat kell ellátnia – Use Case Activity Wireframes 3. Structural diagrams – A működést milyen modulokkal/felbontással lehet megoldani – Component Sequence (behavioral!) – Class diagram (ez akár már fejlesztés közben is lehet) (Lista Kapcsolatok Attribútumok, Műveletek Öröklés) 4. Implementation diagrams – Hogyan tudom implementálni a rendszert Gantt – Adatbázis: ER Table structure 5. Kód írása 46

FF Diagramok • Use Case Diagram (Ki ér el és milyen funkciókat ) • Activity diagram (Minimum egy folyamat a felhasználó nézőpontjából ) • Component diagram (Milyen részei lesznek a rendszernek ) • Sequence diagram (Minimum egy folyamat a kód nézőpontjából ) • Interfaces (IGame. Model, IGame. Logic, IStorage. Repository ) • Class Diagram (a végén, auto-generált + osztály relációk) 47

A féléves feladat komponensei • Elkülönült feladatkörökkel rendelkező komponensek – Model: minden adat (vagyis: tulajdonság), ami a játék egyetlen állapotához tárolni kell (NEM View. Model!!!) – Logic: feladata a Model módosítása metódusokon keresztül (időzített és user interakciótól függő módosítások) – Renderer: feladata a Model megjelenítése (6 -8. gyakorlat) – Repository: feladata a highscore kezelése + a model (a játék egyik állapotának) betöltése/mentése (DB vagy XML) – Tests: a logika AAA egységtesztjei, mockolt függőségekkel • Elkülönült fejlesztési feladatok – Master+Develop git branch; feature-branch javasolt – A: interfészek (IModel, ILogic) + Logic + Tests – B: Model + Repository + Renderer – Egy személyes projekt esetén nem kell Tests és Repository 48

Hogyan tovább…? • • Programozás 1: C# szintaxis, Osztály alapok, kompozíció Programozás 2: Gyűjtemények, Öröklés Programozás 3: GIT, LINQ, ORM, rétegzés Programozás 4: Osztály & architekturális tervezési minták • https: //github. com/Moien. Tajik/Asp. Net. Core-Developer. Roadmap 49

50

Köszönöm a figyelmet! UML viselkedési és implementációs diagramok Nem-UML diagrammok http: //users. nik. uni-obuda. hu/prog 4/ 51