Klik her for at komme til forsiden
Projektet Om forfatterne Kontakt os Gæstebog
Indholdsfortegnelse
» Indledning
» Metode
Baggrund for valg af ekspertsystemtilgang
Valg af afhandlingens metode
Valg af system-ekspertsystemtilgang
Brug af metode
Opsummering og oversigt
» Identifikationsfasen
» Konceptualiserings-fasen
» Formaliseringsfasen
» Validering
» Konklusion
» Perspektivering
» Appendiks 1 - Ekspertsystemers opbygning
» Appendiks 2 - Unified Modeling Language (UML)
Appendiks 2 - Unified Modeling Language (UML)
Eftersom det er valgt at lave den indledende modellering af systemet vha. UML er det væsentligt at redegøre kort for hvad UML er og hvordan det kan bruges, såfremt læseren ikke er bekendt med dette.

2.1 Baggrund for UML

UML er et visuelt systemmodelleringsværktøj, der er designet på baggrund af best-practice i modelleringsteknikker og softwareudvikling. UML er desuden designet til at blive implementeret af CASE (Computer-Assisted Software Engineering) værktøjer, hvilket gør UML særdeles velegnet til modellering af store softwaresystemer.
UML bliver vedligeholdt og opdateret af OMG (Object Management Group) og dets medlemmer. Det kan nævnes om OMG at det er en neutral non-profit organisation der har specialiseret sig i at udarbejde og vedligeholde specifikationer til computerindustrien.
Hvis man kigger på nedenstående Figur 22 kan man få et overblik over den udvikling UML har været igennem.

Figur 22 - UML's Historiske udvikling.
UML historie
Kilde: Arlow & Neustadt (2002), side 6.

Som man kan se af ovenstående figur var der mange modelleringsteknikker på markedet før 1994 og hver af dem havde deres svagheder og styrker. Der blev dog satset på at lave en standardisering, som forsøgte at tage de enkelte modelleringsteknikkers styrker og lave en ny og forbedret udgave. Det var primært Rumbaugh og Booch, der stod bag det første standardiseringsforsøg, hvor Jacobsen kom på i 1995 , og hvor det egentlige UML arbejde blev påbegyndt. Rumbaugh, Booch og Jacobsens modelleringsteknikker var også klart de teknikker der var mest anvendt og det var derfor naturligt at det var disse personer der skulle samarbejde om den nye teknik.
Tilbage til indholdsfortegnelsen    Til starten af afsnittet

2.2 Diagrammeringsformer

Der er ni diagrammer i UML, som kan opdeles i statiske og dynamiske. De statiske diagrammer afbilder strukturen, dvs. opbygningen af systemet, men de dynamiske afbilder, hvorledes systemet opfører sig. De ni diagrammeringsformer kan man også se af nedenstående Figur 23.

Figur 23 - Diagrammeringsformer.
Diagrammeringsformer
Kilde: Arlow & Neustadt (2002), side 11.

Der er dog også tre yderligere diagrammer end de ni der er vist i ovenstående Figur 23, men som ikke falder under de to hovedkategorier. Disse diagrammer omhandler selve modellen og OMG kalder dem overordnet set for Model Management Diagrams. De tre diagrammer er packages, Subsystems og models, men vil ikke blive gennemgået nærmere her, da de ikke er relevante i forhold til det omfang UML er brugt i indeværende afhandling.
I det efterfølgende vil de ni diagrammeringsformer vist i Figur 23, blive gennemgået, hvor der fokuseres på de værktøjer der er benyttet i afhandlingen.
Tilbage til indholdsfortegnelsen    Til starten af afsnittet

2.3 De benyttede diagrammer

Use-case diagram
Dette diagram bliver brugt til at illustrere de primære elementer og processer i systemet, dvs. det kan bruges til en illustrering af kravene til systemet. Et use-case diagram består overordnet set af en eller flere aktører og en række use-cases. Disse aktører og use-cases kan der være relationer mellem for at illustrere de roller brugerne har i systemet, samt de processer og funktionaliteter der skal til for at systemet kan udføre det den skal. Dette gør at use-case diagrammet er særdeles velegnet til identificering af kravene til systemet.
Class diagram
Et klassediagram illustrerer de klasser der er i systemet, samt de relationer der er mellem dem. Dette betyder at den ikke direkte viser hvordan klasserne påvirker hinanden, men kun at relationen er der, hvilket også er grunden til at den hører under de statiske diagrammeringsformer. Klasserne repræsenterer en indkapslet implementering af en given funktionalitet, hvilket betyder at klassediagrammet samlet set viser, hvorledes funktionaliteterne/kravene håndteres i systemet.
Activity diagram
Et aktivitetsdiagram kan sammenlignes med et flowchart og illustrerer hvorledes en bruger kan gå igennem systemet på og dermed hvilke muligheder denne har i systemet. Et aktivitetsdiagram består af et startpunkt, en række aktiviteter, relationer mellem dem og et slutpunkt. Derudover er der i indeværende afhandling brugt beslutningsdiamanter, hvor brugeren kan vælge mellem flere veje i systemet.
Sequence diagram
Et sekvensdiagram illustrerer en sekvens af handlinger der sker i et system. Det omhandler både metodekald i hvert objekt og den rækkefølge som metodekaldene foretages. I indeværende afhandling er sekvensdiagrammerne bl.a. brugt til at illustrere en mulig sti igennem systemet, samt hvorledes systemet resonerer.
Tilbage til indholdsfortegnelsen    Til starten af afsnittet

2.4 De fravalgte diagrammer

Grunden til at de efterfølgende diagrammeringstyper er fravalgte er for komponent- og deploymentdiagrammerne fordi de relaterer sig til implementeringen af systemet. For objekt-, samarbejds- og tilstandsdiagrammerne er grunden at de er mere specifikke end formålet med indeværende afhandling. De tre diagrammeringstyper opererer alle på objektniveau, hvor man kan sige, at de hver er en objektpendant til de benyttede diagrammer.
Dette betyder at valget er stået mellem den overordnede metode, hvor der blev fokuseret på aktiviteter og klasser og den mere specifikke metode, hvor der blev fokuseret på objekter og instanser. I henhold til afhandlingens udformning er der blevet afgrænset fra de specifikke dele af modelleringsprocessen.
Object diagram
Denne diagramtype minder meget om klassediagrammet, med den store forskel at objektdiagrammet viser relationerne mellem objekter, dvs. specifikke instanser af klasser.
Collaboration diagram
Dette diagram er meget lig sekvensdiagrammet i dens formål, denne diagramtype illustrerer dog også associationerne imellem objekterne.
Statechart diagram
Et tilstandsdiagram er en illustration af objekters levetid i systemet, fra de bliver oprettet til de afsluttes. Denne diagramtype minder meget om aktivitetsdiagrammer.
Component diagram
De to sidste diagrammer hører begge under implementeringsdiagrammer. Komponentdiagrammet viser de komponenter systemet består af, samt relationerne imellem dem.
Deployment diagram
Illustrerer konfigurationen af programmet mens det kører.
Tilbage til indholdsfortegnelsen    Til starten af afsnittet

2.5 Yderligere informationer

Man kan sige at UML diagrammerne mindst har to dimensioner, en visuel del og en tekstuel del. Den visuelle del hænger naturligvis sammen med modellernes overskuelige udformning, mens den tekstuelle del supplerer hvor der kan være tvivl om hvad det er der sker i det pågældende diagram. Dette kan også tydeligt ses i den måde de er brugt på i indeværende afhandling.
Såfremt man ønsker at læse mere om UML kan man med fordel begynde på den officielle hjemmeside for UML: www.uml.org.
Tilbage til indholdsfortegnelsen    Til starten af afsnittet
------Videre til bilagsoversigten------

© (2004) Richard M. Motzfeldt & Heino L. Jensen