1 / 110

Introduktion till UML

Introduktion till UML. Pether Andersson Metcon. Pether.Andersson@metcon.se +46 8 6198835 +46 8 706985735. OO. Högnivå språk. Assembler. Maskin kod. Datalogins Evolution. Hur överbrygga gapet mellan människa och maskin?. Låg Abstraktion. Hög Abstraktion.

lance-bruce
Télécharger la présentation

Introduktion till UML

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Introduktion till UML Pether Andersson Metcon Pether.Andersson@metcon.se +46 8 6198835 +46 8 706985735

  2. OO Högnivå språk Assembler Maskin kod Datalogins Evolution Hur överbrygga gapet mellan människa och maskin? Låg Abstraktion Hög Abstraktion

  3. Återanvändning-snabbare utveckling Anpassningsbart Enklare att underhålla Ökad kvalitet Fördelar med OO

  4. Simula 1967 Smalltalk 1972 C++ 1986 Java 1991 OO - Kort historik

  5. Objekt Ett objekt kan hålla information (data) Ett objekt kan göra saker (funktionalitet) Objekt tillhör en klass (är en instans av) Klass En klass definierar vilken typ av information dess objekt skall hålla (Attribut) En klass definierar vad dess objekt skall kunna göra (Metoder/Operationer) OO’s Byggstenar

  6. OO’s Byggstenar

  7. Dölja implementationen utav klasserna Endast kommunisera med objekten via specifiserade gränssnitt Qualifiers private, protected, public. geters & seters Inkapsling

  8. OO Principer - Arv

  9. OO Principer - Arv

  10. Overriding, Overloading, Polymorfism

  11. UML är ... • UML är en notation • UML är inte en utvecklingsprocess • UML är inte ett modelleringsverktyg • UML är inte lösningen på alla problem

  12. Unified Modeling Language • Standardiserad notation för att modellera system med objektorienterad teknik • Kondens av notationerna • Booch • OMT • Objectory • Shlaer/Mellor • Fusion

  13. Användningsområden • Systemutveckling • Verksamhetsmodellering

  14. UML’s mål • Enklare för anvädare och systemutvecklare att kommunicera • Möjligt att modellera komplicerade och tidskritiska system • Överskådligt • Möjligt att bygga verktygsstöd

  15. UML Historik • Metodernas krig • OOPSLA 94 Unified Method introduceras • OOPSLA 96 UML0.9 • Föreslagen som standard i september 97 (UML 1.0) • OMG utser UML (1.1) till officiell standard 17 november 97 • UML 1.2 & UML 1.3 & draft UML 1.4

  16. UML och Processen • UML har ingen associerad utvecklings process och är därför endast ett modelleringsspråk och inte en metod. • Många olika utvecklingsprocesser är applicerbarar

  17. Vattenfalls process Analysis Design Implementation Testing Maintenance

  18. Spiral process Design and build Evaluate Analysis Planning

  19. Objectory processen Product lifecycle 1st Generation 2nd Generation 3rd Generation 4th Generation 5th Generation Cycle Inception Elaboration Phase Construction Phase Transition 2nd Iteration 3rd Iteration 4th Iteration 5th Iteration 1st Iteration Analysis Design Implementation Planning Test (V&V)

  20. (R)UP Inception Elaboration Construction Transition Process workflows Business Modelling Requirements Analysis & design Implementation Test Deployment Supporting workflows Configuration and change management Project management Environment Iterations in each

  21. UML´s byggstenar • Modellartefakter • Saker • Relationer (mellan saker) • Diagram

  22. UML´s byggstenar Extensions UML kernel

  23. UML kernel • Nio olika diagram • Activity diagram • Component diagram • Collaboration diagram • Class diagram • Deployment diagram • Object diagram • Sequence diagram • State diagram • Use Case diagram

  24. UML kernel • Artefakter med speciella syften • Class • Object • UseCase • State • Association • Transition • …. • Allmänna hjälp artefakter • Package • Note

  25. UML’s Extension mekanismer • Stereotypes • Tagged values • Constraints

  26. Constraints • Grafiskt representeras ett constraint med {constraint}

  27. Constraints – OCL • OCL = Object Constraint language • Formellt språk för att bl.a. uttrycka villkor på ett stringent sätt

  28. Tagged value • Ett tagged value består av ett namn (the tag) och ett värde • Alla artefakter kan ha tagged values • Tagged values används om man vill spara ”extra information” om ett element. Ex Status = ”Approved”

  29. Stereotypes • En stereotyp är en specialicering av en artefakt • Stereotyper är i sig en artefakt • Stereotyp visas grafiskt med <<Stereotyp>> • En stereotyp kan medföra Constraints och Tagged Values • Stereotyper kan ha egna symboler

  30. Exempel på stereotyper • Stereotyper till Class • Boundery • Entity • Control

  31. Vyer av systemet Component Logical Use-Case Deployment Concurrency

  32. Vyer av systemet Component Logical Use-Case Deployment Concurrency

  33. Use-Case vyn • För vem? • Användare och andra intressenter • Systemarkitekter • Utvecklare • Testare

  34. Innan man sätter igång... • Definiera en begreppskatalog • Bestäm systemets gränser • Ambitionsnivån för första releasen • Kan några uppgifter (UseCase) lösas av andra system

  35. Use-Case vyns artefakter • Diagram • UseCase Diagram • ActivityDiagram • Övriga • UseCase • Actor • ”System”

  36. Use-Case diagram

  37. Hur hittar man aktörerna? • Vem behöver stöd av systemet för att utföra sina dagliga uppgifter • Vem skall underhålla och administrera systemet • Med vilka andra system skall systemet interagera • Vilka hårdvaru-devices skall systemet hantera • Vilka har intresse utav de resultat som systemet tar fram

  38. Aktörer kan rankas • Primära aktörer. Utnyttjar systemets huvudfunktionalitet. • Sekundära aktörer. Utnyttjar systemets stödfunktionalitet. • Backup • Underhåll • .....

  39. Aktörer kan klassas • Aktiva aktörer initierar UseCase • Passiva aktörer deltar endast

  40. Aktörer är klasser • Aktör är en s.k stereotype till Class • Aktörer kan jämföras med roller. • Aktörer kan ingå i en arvshieraki.

  41. Definition: “En sekvens av system aktiviteter som producerara ett observerbart värde för en aktör” Use Case

  42. Egenskaper hos ett Use Case • Ett use case initieras alltid av en Aktör • Ett use case levererar ett (eftersträvandsvärt) värde till Aktören • Ett use case är komplett

  43. Hur hittar man Use Case? • Vilken funktionalitet kräver aktörerna av systemet • Kan aktörens dagliga arbete förenklas eller effektiviseras genom att man inför ny funktionalitet i systemet • Behöver aktörerna läsa, skapa, uppdatera, ta bort eller lagra någon information i systemet • Behöver aktören bli uppmärksammad om händelser i systemet. Vad representerar dessa händelser för funktionalitet

  44. Hur hittar man Use Case? • Behöver aktören uppmärksamma systemet på händelser i omvärden. Vad representerar dessa händelser för funktionalitet • Frågor som inte involverar en aktör • Vilken input/output har systemet. Med vad kommunicerar systemet. • Vilka är problemen med den nuvarande implementeringen

  45. Vilka är bra användningsfall? • Order • Byta fält i skärmbilden • Registrera order • Systemet larmar användaren • Se till att systemet är uppe 95% av tiden • Registrera kund m.h.a Kund klassen

  46. Övning 1 Du äger en videouthyrningsaffär och behöver ett system som hjälper dig i det dagliga arbetet. • Identifiera aktörer. • Identifiera use case. • Rita en use case modell.

  47. Ett Use Case beskrivs i löpande text Mål och Syfte Initiering. Hur, När och av Vem “Slut villkor” och vad som levereras Huvud flödet Alternativa flöden Beskrivningarna skall vara på användarnas språk Beskrivningen skall vara implementations oberoende Use Case beskrivningen

  48. Activity diagram

  49. Activity diagram

  50. Activity diagram

More Related