Trekronergade 147B, 2500 Valby, telefon: 35 300 700, fax: 35 300 701, web:www.semaphor.dk, email: info@semaphor.dk

Optimér dine udviklingsprocesser med UML.

SemaphorUML – Unified Modeling Language

Et standard sprog til specificering, visualisering, udvikling og dokumentation af software systemer

Præsenteret af:Ronni Kahalani, SemaphorUdviklingschef / Systemarkitektmail: ronni.kahalani@semaphor.dkweb: www.semaphor.dk

Agenda

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

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.

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…

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 afUML 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

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]

Demo af EMF

• Plugins– EMF - Eclipse Modeling Framework.

• Automatisk kodegenerering ud fra modeller.• PoC på Lotusscript brug af WAS webservice.

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.

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!

Appendiks

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.

Tilbage

Beskriver relationer mellem Actors (brugere) og Use Cases (handlinger).TIP: navneord=entiteter, udsagnsord=metoder

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

Sequence diagram

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

Tilbage

Collaboration diagram

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

Tilbage

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

Activity diagram

Viser handlings tilstande og overgangene.

Tilbage

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

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