Page History

                                            Figur 8: Tre parallelle tilstander

Aktivitetsdiagrammer kan oppfattes som en variant/utvidelse av tilstandsdiagrammer. Som nevnt i innledningen om tilstandsdiagrammer kunne vi inni en tilstandsboks navngi selve tilstanden og/eller den aktiviteten som foregikk i tilstanden. Aktivitetsdiagrammer vil altså være tilstandsdiagrammer der man kun, eller i hovedsak, opererer med aktivite- ter. I den grad man fortsatt ønsker å inkludere selve tilstandsendringene i diagrammet, vil disse nå være vist som rektangler (med objektnavn, [tilstand]), koblet med stiplede piler til de aktiviteter som forårsaker tilstandsendringene. I tillegg har man en del andre konstruksjoner, f.eks. for å vise valgmuligheter, synkronisering og parallellprosessering.

For valg har man rombesymboler à la hva man vil være kjent med fra algoritmiske flytdiagrammer. I flytdiagrammer har man ofte bare to veier ut fra romben (f.eks. J og N, alt etter om betingelsen er sann eller usann), men i UMLs aktivitetsdiagrammer kan man ha piler ut, hver annotert med betingelsen for at denne skal velges, f.eks. [x<0], [x=0], [x>0]. Synkronisering og splitting vises begge ved en tykk stolpe som piler går inn til og ut fra. Flere piler inn og en ut betyr synkronisering – flere parallelle aktivitetstråder fortsetter i en felles. En pil inn og flere ut betyr splitting – en aktivitetstråd videreføres i flere parallelle aktiviteter. Denne symbolikken er vist i Figur 9.

Image Added

                                            Figur 9Figur 24: Notasjon for aktivitetsdiagrammer

Man trenger ikke ha med objekt/tilstandsbokser for hver aktivitet, bare hvis man fin- ner dette nødvendig for diagrammets forståelighet. Hvis man bare bruker aktiviteter, vil diagrammet minne mye om tilstandsdiagrammer, piler indikerer overganger på sam- me måte, og man har samme symbolikk for start og stopp. For eksempler på bruk av aktivitetsdiagrammer, se nedennevnte støttelitteratur eller forelesning om tilstandsdia- grammer.A.11.

Referanser

Dette korte notatet har bare kunnet gi en rask innføring i UML, med det som er mest nød- vendig for å komme i gang med prosjektet. For alle diagramtypene som er nevnt her, fins det mer avanserte muligheter som kunne ha vært nevnt i tillegg, ikke minst det formelle språket OCL, som kan brukes til tekstlige presiseringer i forhold til diagrammene, med formler, variabeltilordninger, betingelser o.l. Det fins dessuten en del diagramtyper som ikke er vist, f.eks. samarbeidsdiagrammer (collaboration diagrams), pakkediagrammer (package diagrams) og realiseringsdiagrammer (deployment diagrams). Pakkediagram- mer, som viser hvordan store systemer er delt opp i moduler, vil man se et eksempel på i kravspesifikasjonen for prosjektet. For mer detaljer henviser vi til forelesninger og den nedennevnte støttelitteraturen.

1. MartinFowler,KendallScott:UMLDistilled:applyingthestandardobject-oriented modelling language, 1997, 179 s. (ordet distilled = destillert hentyder på en rask innføring, så kan man bare tenke seg hvor destillert dette lille notatet da må være).

2. Rob Pooley, Perdita Stevens: Using UML: software engineering with objects and components, 1999, 254 s.

3. Bernd Oesterreich: Developing Software with UML: object-oriented analysis and design in practice, 1999, 321 s.

4. Charles Richter: Designing Flexible Object-Oriented Systems with UML, 1999, 404 s.

5. Ivar Jacobson, Grady Booch, James Rumbaugh: The Unified Software Development Process, 1999, 463 s. (en bok av metodens/språkets opphavsmenn)

   52

1. Desmond F. D’Souza, Alan C. Wills: Objects, Components, and Frameworks with UML: the Catalysis Approach, 1999, 785 s.