Optimér dine udviklingsprocesser med UML. Semaphor UML – U nified M odeling L anguage

1. Optimér dine udviklingsprocesser med UML. Semaphor UML – Unified Modeling Language Et standard sprog til specificering, visualisering, udvikling og dokumentation af software systemer Præsenteret af: Ronni Kahalani, Semaphor Udviklingschef / Systemarkitekt mail: ronni.kahalani@semaphor.dk web: www.semaphor.dk Trekronergade 147B, 2500 Valby, telefon: 35 300 700, fax: 35 300 701, web:www.semaphor.dk, email: info@semaphor.dk

2. Agenda • Hvad er UML? • Hvorfor UML? • Historien bag UML • UML diagrammer • Demo EMF • Hvordan kommer man i gang? • Afslutning

3. Hvad er UML? • Et standard sprog til specificering, visualisering, udvikling og dokumentation af software systemer. • Bruger primært grafiske notationsformer til at udtrykke design af software projekter. • UML’s primære målsætning: • Give brugere et visuelt sprog så til at udvikle og udveksle meningsfulde modeller. • Tilbyde udvidelses- og specialisering mekanismer til at udvide grund koncepter. • Være uafhængige af programmeringssprog og udviklingsprocesser. • Give en formel grundsyntaks for forståelse af modelleringssproget. • Opfordre til forøgelse af OO værktøjsmarkedet. • Supportere højniveau udviklingskoncepter som collaborations, frameworks, patterns og components. • Integrere ”best practices”, så det er lettere og mere oplagt at genbruge.

4. Hvorfor UML? • Markedets mest accepterede software modelleringssprog. • Fleksibel nok til at tilgodese markedets typiske forskelligheder og behov. • Grundlag for at kunne danne mere abstrakte og uafhængige afbildninger af behov og opbygning af software. • Grafiske diagrammer er meget nemmere at debattere/informere udfra, end tonsvis af tekst formuleringer. • Stærkt kommunikationsmedie mellem arkitekter, udviklere og andre. • Færre misforståelser og derved større mulighed for succes. • Kan automatisere produktionen af software, forbedre kvaliteten, reducere omkostninger og ”time-to-market”. • Evnen til at styre kompleksiteten af systemer når de vokser i behov og størrelse. • Løsninger til typiske arkitektoniske udfordringer, som fysisk distribution, samhørighed, replikering, sikkerhed, load balancing osv. • Og 1000 andre grunde…

5. Historien bag UML 1975 – 1989: OO modellerings- teknikker og sprog starter. 1989 – 1994: Sprogene voksede fra ca. 10 til 50 i perioden 1994 – 1995: UML’s udvikles af Jim Booch & Jim Rumbaugh, fra Rational, med inspiration fra deres tidligere OO modeller såsom Booch og OMT [Object Modeling Technique]. 1995 – 1996: Ivar Jacobson (med firmaet Objectory) tilslutter sig Rational’s UML projekt, hvor OOSE (Object-Oriented Software Engineering) flettes ind i konceptet. 1995 – 1996: Ivar Jacobson (Objectory) & Richard Soley (OMG) beslutter at presse på for at opnå standardisering af UML. 1996 – 1997: UML 0.9 og 0.91 specifikationerne frigives. 1996 – 1997: Rational etablerer et UML Partners Consortium, for at få bred tilslutning til specifikationen af UML 1.0. Konsortiet bestod b.la. af: Digital EC, HP, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle og Rational Software. 1997 – 1998: IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies og Softeam deltog med ideer og specifikationen for UML 1.1

6. UML diagrammer Hvert UML diagram er designet til at give arkitekter, udviklere og kunder mulighed for at se et software system fra forskellige perspektiver og i forskellige abstraktionsniveauer. • Use Case diagram [vis diagram] • Class diagram [vis diagram] • Interaction diagrammer • Sequence diagram [vis diagram] • Collaboration diagram [vis diagram] • State diagram [vis diagram] • Activity diagram [vis diagram] • Physical diagrams • Component diagram [vis diagram] • Deployment diagram [vis diagram]

7. Demo af EMF • Plugins • EMF - Eclipse Modeling Framework. • Automatisk kodegenerering ud fra modeller. • PoC på Lotusscript brug af WAS webservice.

8. Hvordan kommer man i gang? Start med at lave et pilotprojekt • Find/tilknyt en erfaren UML mentor, som kan vejlede i startfasen. • Find det værktøj der passer bedst ind i virksomheden (økonomisk som featuremæssigt). • Implicer et par arkitekter, udviklere og kunder • Sørg for at den viden der tilløber virksomheden ikke forsvinder igen. • ”Keep it simple”! Ulemper ved overgang til UML: • Det kan blive en større investering i værktøjer, uddannelse og flere projekt aktiviteter. Fordele ved overgang til UML: • Investeringen kommer hurtigt igen da sandsynligheden for større succes internt som ekstern er meget større. • Man har implicit meget af den tekniske dokumentation på plads. • Man bruger mindre tid på forståelse i fremtiden og kan genbruge tidligere løsninger mere optimalt. • Mulighed for færre misforståelser, fejl og uforudsete behov. • De fleste mennesker har nemmere ved at fortolke komplekse situationer via grafiske afbildninger end spalte op og ned med inkonsistente og utilstrækkelige tekstbaserede formuleringer. • Nye projekt deltagere kan hurtigt få forståelse af opgaver og sammenhænge.

9. Afslutning Links: • OMG (Object Management Group) [vis] • UML Ressource Page [vis] • UML Quiz Page [vis] • IBM Rational Software [vis] • Core J2EE design patterns (Sun/Java) [vis] Tak for jeres interesse!

10. Appendiks

11. Use Case diagram Tip: Start med at liste handlinger og aktører. Bruger bestiller ordre: 1. Gennemsøger katalog og vælger produkt(er). 2. Ringer til salgskonsulent. 3. Angiver leverings information. 4. Angiver betalings information. 5. Modtager et ordrebekræftelse fra salgsperson. Disse steps vil generere dette simple diagram. Beskriver relationer mellem Actors (brugere) og Use Cases (handlinger). TIP: navneord=entiteter, udsagnsord=metoder Tilbage

12. Class diagram Beskriver de mere statiske strukturer, såsom moduler, klasser, interfaces og deres indbyrdes relationer såsom containment (det at indeholde), inheritance (arv) og associations (relationer). Tilbage

13. Sequence diagram Viser tids sekvenser mellem objekter, der deltager i en given interaktion. Dimensioner: Vertikal=tid, Horisontal=forskellige objekter. Tilbage

14. Collaboration diagram Viser en interaktion organiseret omkring objekter og deres links til hinanden. Tal bruges til at vise sekvensen af beskeder. Tilbage

15. State diagram Viser sekvensen af tilstande som et objekt, i en given interaktion, gennemgår i dets liv, i respons til et modtaget stimuli. Tilbage

16. Activity diagram Viser handlings tilstande og overgangene. Tilbage

17. Deployment diagram Viser konfigurationen af run-time elementer og software komponenter, processer og objekter, der kører på miljøets noder. Software komponent instanser repræsenterer run-time manifestationer af kode moduler. Tilbage

18. Component diagram Viser, på højt niveau, pakke strukturer af selve koden. Afhængigheder mellem komponenter vises, inklusiv: • source kode komponenter • binær kode komponenter • eksekverbare komponenter. Nogle komponenter eksisterer ved kompilerings-, link og/eller ved kørsels tidspunktet. Tilbage