optimér dine udviklingsprocesser med uml. semaphor uml – u nified m odeling l anguage
DESCRIPTION
Optimér dine udviklingsprocesser med UML. Semaphor UML – U nified M odeling L anguage Et standard sprog til specificering, visualisering, udvikling og dokumentation af software systemer. Præsenteret af: Ronni Kahalani, Semaphor Udviklingschef / Systemarkitekt - PowerPoint PPT PresentationTRANSCRIPT
Trekronergade 147B, 2500 Valby, telefon: 35 300 700, fax: 35 300 701, web:www.semaphor.dk, email: [email protected]
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: [email protected]: 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