Hovedoppgave

 

Anvendelse av UML til dokumentering av generiske systemer

 

Morten Østbø

 


Høgskolen i Stavanger
Sivilingeniørstudiet retning datateknikk

 

wpe1.jpg (9817 bytes)


________________
STAVANGER 2000

 

Oppgavetekst

Oppgaveteksten slik den er formulert av veilederne i Statoil, Oral Sjøflot og Harald Rønneberg:

Tittel: Anvendelse av UML til dokumentering av generiske systemer

I forbindelse med Prosty prosjektet satses det på omfattende gjenbruk av kode og dokumentasjon. På dokumentasjonssiden har ikke prosjektet lykkes med å finne en god måte for å få til gjenbruk. Det blir mye kopiering som resulterer i mye redundans som krever oppdatering på flere steder. UML har blitt lansert som en kandidat for å få til mer gjenbruk av dokumentasjon i Prosty.

Oppgaven går ut på:

  • å sette seg inn dokumentasjonsbehovet til Prosty og på det grunnlaget komme opp med hvilket krav som stilles til et modelleringsspråk for at prosjektet skal lykkes med gjenbruk av sin dokumentasjon
  • å sette seg inn i UML og på det grunnlaget avgjøre om UML tilfredstiller kravene Prosty stiller
  • å, hvis svaret på forrige punkt er ja, sette seg inn i minst to verktøy som støtter UML for å identifisere det best egnede verktøyet

 

Sammendrag

Dokumentasjon i form av tekst, figurer og modeller er en viktig del av en programvareleveranse. I vedlikeholdsfasen er det viktig å ha oppdatert dokumentasjon som både kan gi oversikt og detaljer omkring systemet. I en systemportefølge hvor en felles del går igjen fra system til system, er det i tillegg viktig å unngå redundans i dokumentasjonen, samtidig som man er i stand til å tegne et komplett bilde for hvert system.

Denne hovedoppgaven fokuserer på hvordan man kan anvende modelleringsspråket UML og UML verktøy til å visualisere en systemportefølge grafisk for å dokumentere systemene uten redundans i modeller og tilhørende tekstbasert dokumentasjon.

Oppgaven benytter et konkret prosjekt som eksempel og rettesnor. Den starter med å fastslå prosjektets dokumentasjonsbehov. Dokumentasjonsbehovet er grovt sett å presentere en oversikt over systemet, både overordnet og detaljert, uten å skape redundans i dokumentasjonen. Dette som et utgangspunkt for gjenbruk ved spesifikasjon av nye systemer i samme portefølge.

Ut i fra dokumentasjonsbehovene fastsettes krav til modelleringsspråk. Språket må kunne gi en overordnet og detaljert presentasjon av systemet, samtidig som man unngår redundans i diagramtegning. Dette oppnår språket i stor grad ved å kunne uttrykke begrepene brukt innenfor objekt-orientert teknologi, med andre ord støtte av et objekt perspektiv.

UML gjennomgås med fokus på hvordan gjenbruk kan uttrykkes ved hjelp av modelleringsspråket. Deretter foretas en vurdering av UML opp mot fastsatte krav. UML er funnet til å støtte godt opp omkring et objekt-orientert perspektiv. Språket er vurdert til å ha godt potensiale til å kunne uttrykke gjenbruk uten å skape redundans i dokumentasjonen.

Neste del av oppgaven ser på hvordan UML verktøy håndterer en systemfamilie, - generiske systemer. Et viktig krav til verktøyet er å kunne presentere et komplett bilde av et system, både felles del og spesiell del, uten redundans i modeller og tekstbasert dokumentasjon.

Ingen av de to vurderte UML-baserte verktøyene, Select fra Princeton Software, eller Rational Rose fra Rational Corporation er i stand til å ivareta dette viktige generiske aspektet. Det er mulig å få til deler i verktøyene, men man må sette sammen modellene for hvert system i portefølgen. Dermed får man redundans i diagramtegning.

Likevel kan man med verktøyene ivareta andre viktige sider ved dokumentasjonen av et system, nemlig å få presentert en oversikt over systemet, og man får et verktøy hvor det er mulig å samle all dokumentasjon tilhørende et system, både modeller og tekstbasert dokumentasjon. Rational Rose er vurdert til å være det verktøyet som har kortest vei til å imøtekomme fastsatte krav. Min anbefaling til prosjektet blir derfor (i prioritert rekkefølge):

  1. Innkalle begge leverandørene til møte for å se hva som er mulig å oppnå av forpliktende avtaler omkring fremtidig utvikling. Det er essensielt å få avtalefestet en gjennomføringsplan for implementasjon av ikke-oppfylte absolutte krav.
  2. Dersom punkt 1 av forskjellige årsaker ikke ønskes gjennomført, anbefaler jeg å utnytte de mulighetene som eksisterer i Rational Rose.

Det kan se ut som om prosjektet blir nødt til å leve med redundans i dokumentasjonen i en tid til, men har nå mulighet til å få på plass en overordnet og detaljert oversikt over systemene.

 

Definisjon "generisk system"

Booch definerer en generisk klasse som: "En klasse som opptrer som en mal for andre klasser, og hvor malen kan parameteriseres av andre klasser, objekter og/eller operasjoner. En generisk klasse må instansieres (med utfylte parametre) før objekter kan opprettes." [Booch 94]. Booch definerer også en generisk funksjon som: "En operasjon på et objekt. En generisk funksjon i en klasse kan redefineres i subklasser. Dvs. For et gitt objekt er dette implementert gjennom et sett av metoder deklarert i forskjellige klasser relatert gjennom deres arvehierarki." [Booch 94].

Egen definisjon på generisk system: Et generisk system er et programsystem bygget opp av parameteriserte moduler/komponenter og som har den fordelen at det lett lar seg tilpasse ulike og nye brukerkrav ved å sette sammen eksisterende komponenter med nye parameterverdier.

Generiske systemer er typisk systemer hvor visse deler av systemet går igjen fra en implementasjon til en annen, mens det også eksisterer spesielle biter for hver implementasjon. Utfordringen for utviklerne blir å maksimere gjenbruksgraden både av kode og dokumentasjon.

Prosty systemet er et generisk system. Statoil benytter konsulenter fra TietoEnator under utviklingen av systemet. TietoEnator har kommersialisert systemet under et annet navn, Energy Components, og fra deres internettsider kan en lese hvilke fordeler komponent-basert utvikling gir:

  • Tilbyr et felles teknologisk fundament for hele industrien.
  • Gir høyere gjenbruksnivå.
  • Gir mekanismer for sømløs integrasjon med andre forretningsapplikasjoner.
  • Forbedrer produktiviteten.
  • Forbedrer kvaliteten (utvikles og testes en gang, brukes om igjen). [TietoEnator 00]

 

Bøker

Linker