21. Objektorientert Analyse (OOA) Kap. 21 Objektorientert Analyse (OOA) Når vi skal lage en OO analysemodell, bruker vi 5 hovedprinsipper: 1. Lag en modell av informasjonsdomenet. 2. Beskriv modul-funksjonene 3. Beskriv hvordan modellen virker. 4. Modellene deles opp for å vise større grad av detaljering. 5. De første modellene representerer det sentrale i problemet, mens de senere modellene gir detaljer for implementasjonen. I OOA skal en definere alle klasser og forbindelsene mellom dem som er relevante for å løse problemet. Systemutvikling Kap.21 Objektorientert analyse 1 Systemutvikling Kap.21 Objektorientert analyse 2 21. Objektorientert Analyse (OOA) Når vi utfører OO analyse, må vi utføre følgende oppgaver: 1. Fundamentale brukerkrav må formidles mellom kundene og systemutviklerne. 2. Klasser må identifiseres, og attributter og metoder må defineres. 3. Et klassehierarki må spesifiseres. 4. Objekt-til-objekt relasjoner (objektforbindelser) må representeres (defineres). 5. Objektoppførsel (virkemåte) må modelleres. 6. Oppgavene 1 til 5 gjentas (iterativt) til modellen er komplett. Det er en rekke forskjellige metoder for OO analyse. Metodene er oppkalt etter de som har utviklet dem. Systemutvikling Kap.21 Objektorientert analyse 3 Systemutvikling Kap.21 Objektorientert analyse 4 Boochs metode har utviklingsprosess både på mikro- og makronivå. Mikronivået definerer en rekke analyseoppgaver som anvendes om igjen for hvert steg i makroprosessen. Metoden støttes også av en rekke automatiske verktøy. Hovedpunktene i metoden på mikronivå er: Identifiser klasser og objekter Identifiser betydningen til klasser og objekter. Identifiser relasjoner mellom klasser og objekter Utfør ei rekke av forbedringer (refinements) Implementer klasser og objekter (fullføring av analysemodellen) Rambaughs metode, også kjent som Object Modeling Technique (OMT) for analyse, system design og objektnivå design. Det lages tre modeller: 1. Objektmodell (objekter, klasser, hierarkier og relasjoner) 2. Dynamisk modell (objekter og systemoppførsel) 3. Funksjonell modell (DFD-liknende representasjon av info-flyt i systemet) Systemutvikling Kap.21 Objektorientert analyse 5 Systemutvikling Kap.21 Objektorientert analyse 6 1
Jacobsons metode, også kalt OOSE - OO Software Engineering er en forenklet versjon av Objectory - metoden som også er utviklet av Jacobson. Det spesielle med metoden er utstrakt bruk av use case som er en beskrivelse eller scenairo som viser hvordan brukerne kommuniserer med produktet eller systemet. Hovedtrekkene i Jacobsons metode er: Identifiser brukerne av systemet og deres overordnende ansvarsområder. Bygg en kravmodell Definer aktørene og deres ansvarsområder Identifiser use cases for hver aktør. Lag første versjon av systemobjektene og relasjonene. Gå gjennom (review) modellen der du bruker use cases som scenarier for å bestemme gyldigheten (validiteten). Bygg en analysemodell. Identifiser grensesnitt-objekter ut fra brukerkommunikasjon. Lag en struktur for grensesnitt-objektene. Representer objekt-virkemåte. Isoler subsystemer og submodeller. Gå gjennom modellen ved bruk av use cases som scenarier for å bestemme gyldigheten. Systemutvikling Kap.21 Objektorientert analyse 7 Systemutvikling Kap.21 Objektorientert analyse 8 Andre metoder: Coad og Yourdons metode. Wirfs-Brocks metode Metodene har mange fellestrekk. Når vi utfører OOA må vi gjennomføre følgende aktiviteter: Samle inn brukerkrav for OO systemet. Lag scenarier eller use cases Lag en kravmodell. Velg klasser og objekter ut fra fundamentale krav. Spesifiser attributter og operasjoner for hvert systemobjekt. Definer strukturer og hierarki som organiserer klassene. Lag en objekt-relasjonsmodell Lag en objekt-virkemåte-modell (object-behavior model) Gå gjennom (review) OO analysemodellen og sammenlign med use cases /scenarier. Hvert steg behandles i detalj i kap. 21.3 og 21.4. Systemutvikling Kap.21 Objektorientert analyse 9 Systemutvikling Kap.21 Objektorientert analyse 10 21.1.3 Unified Modelling Language - UML Booch, Rumbaugh og Jacobson har samarbeidet om å lage UML. Systemet representeres av 5 forskjellige views (perspektiver): 1. User model view - Brukermodell - systemet sett fra brukerens (aktørens) synspunkt. Bruker use cases. 2. Structural model view - Data og funksjonalitet sett fra innsiden av systemet. Modeller av statiske strukturer (klasser, objekter og relasjoner) 3. Behavioural model view - Viser virkemåten (dynamikken) til systemet og samarbeid mellom systemelementer fra bruker- og strukturmodellene. 4. Implementation model view. Representasjon av systemet (fra 2 og 3) slik det skal bygges. 5. Environment model view - Representasjon av systemets omgivelser. Systemutvikling Kap.21 Objektorientert analyse 11 21.2 Analyse av kontrollområde (Domain analysis) OOA anvendes på flere nivå i bedriften: Overordnet, strategisk nivå der det utvikles modeller for hele bedriften. (omtales ikke i denne boka) Laveste (detaljert) nivå som er generell OO systemutvikling. (som er tema i de andre seksjonene i dette kapittel) På middels abstraksjonsnivå foregår domain analysis (analyse av kontrollområde, domeneanalyse) som brukes når en organisasjon ønsker å utvikle et bibliotek av gjenbrukbare klasser (komponenter) som vil bli mye brukt på flere applikasjons-områder. Dette er tema i denne seksjonen. Systemutvikling Kap.21 Objektorientert analyse 12 2
21.2.1 Gjenbruk og analyse av kontrollområde OO systemutvikling vil være mye mer effektiv når det er tilgang til et godt utbygd bibliotek av gjenbrukbare klasser. Vi skal i de følgende seksjonene se hvordan klasser utvikles for biblioteket. 21.2.2 Prosess for analyse av kontrollområde Domain analyse er identifisering, analyse og spesifisering av felles gjenbrukbare muligheter innen et spesielt applikasjonsområde i form av felles objekter, klasser, moduler og rammeverk. Applikasjonsområde kan være flyteknologi, bankvirksomhet, multimedia video spill osv. Det gjelder altså å finne eller lage klasser som er anvendelige for området. Domain analyse er en kontinuerlig (paraply)aktivitet som ikke er knyttet til et spesielt prosjekt. Fig. 21.1 viser de viktigste input og output for domain analyse. Systemutvikling Kap.21 Objektorientert analyse 13 Systemutvikling Kap.21 Objektorientert analyse 14 21.2.2 Prosess for analyse av kontrollområde Kilder for kunnskaper om domenet Teknisk litteratur Eksisterende applikasjoner Kundeoversikt Ekspertråd Aktuelle og fremtidige krav Fig. 21.1 Input og output for domain analyse. Klasse taksonomi Gjenbruksstandarder Funksjonell modell Domenespråk Domensanalyse Analysemodell av domenet 21.2.2 Prosess for analyse av kontrollområde Aktivitetene i domain analyse: Definer området som skal undersøkes. Klassifiser (sorter) elementene som er funnet. Finn et representativt utvalg av applikasjoner i domenet. Analyser hver applikasjon i utvalget. Identifiser kandidater til gjenbrukbare objekter Begrunn hvorfor objektet er valg ut. Definer tilpasninger til objektet som også kan gjenbrukes Estimer prosentvis antall applikasjoner som kan bruke objektet. Identifiser objektene med navn, og bruk konfigureringsadministrasjon for å kontrollere objektene. I tillegg bør det estimeres hvor stor del av en typisk applikasjon som kan konstrueres fra gjenbrukte objekter. Utvikle en analysemodell av objektene. Modellen tjener som basis for konstruksjon av domene objekter. Systemutvikling Kap.21 Objektorientert analyse 15 Systemutvikling Kap.21 Objektorientert analyse 16 21.3 Generiske komponenter i OO analyse modellen OO analyse prosess er lik den vanlige analyseprosessen som vi har sett tidligere, og den har de samme mål... Statiske komponenter er strukturelle av natur, og indikerer karakteristikker som gjelder gjennom applikasjonens levetid. Dynamiske komponenter fokuserer på kontroll, og er følsomme for timing og prosessering av hendelser (events). De definerer hvordan et objekt kommuniserer med andre objekter over tid. 21.4 OOA prosessen OOA prosessen starter med å kartlegge hvordan systemet skal brukes: Er det en (interaktiv) applikasjon med personer som brukere, er det et prosesskontrollsystem som brukes av maskiner, eller brukes det av andre programmer ved at systemet koordinerer og kontrollerer applikasjoner? Når en slik kartlegging ( scenarier ) av bruken er definert, starter modelleringen av systemet. De følgende avsnitt viser teknikker for å samle inn brukerkrav, og deretter definere en analysemodell for et objektorientert system. Systemutvikling Kap.21 Objektorientert analyse 17 Systemutvikling Kap.21 Objektorientert analyse 18 3
20.4.1 Use cases Innsamling av krav er alltid første steg i alle analyseaktiviteter. Ut fra kravene lager systemutviklerne et sett med scenarier som hver viser en sammenhengende bruk av systemet som skal lages (en tråd gjennom systemet). Disse scenariene som kalles use cases, gir en beskrivelse av hvordan systemet vil bli brukt. Første steg i å lage use cases, er å identifisere de forskjellige typer av personer som bruker systemet. Disse kalles aktører og representer roller som personer (eller enheter) har i forhold til systemet når det brukes. En aktør er altså alt eksternt som kommuniserer med systemet. NB: En bruker er ikke det samme som en aktør. En bruker kan ha flere aktør-roller. 21.4.1 Use cases Det er mulig å skille mellom primæraktører som en finner i første analyserunde, og sekundære aktører som en finner senere. De primære aktørene bruker systemet regelmessig til de oppgaver som systemet primært skal utføre. De sekundære aktørene utfører støttefunksjoner i forhold til systemet. Systemutvikling Kap.21 Objektorientert analyse 19 Systemutvikling Kap.21 Objektorientert analyse 20 21.4.1 Use cases UML: Use-Case Diagram Når aktørene er definert, starter utviklingen av use cases. En use case beskriver hvordan en aktør bruker (kommuniserer) med systemet. Jacobson foreslår følgende spørsmål som skal besvares av en use case: Hvilke hovedaktiviteter eller funksjoner utføres av aktøren? Hvilken systeminformasjon vil aktøren spørre om, produsere eller endre? Må aktøren informere systemet om endringer i de eksterne omgivelser? Hvilken informasjon ønsker aktøren å få fra systemet? Ønsker aktøren å bli informert om uventede endringer? Systemutvikling Kap.21 Objektorientert analyse 21 Systemutvikling Kap.21 Objektorientert analyse 22 21.4.1 Use cases Når use case ene er laget, må de gjennomgås (reviews) grundig for å fjerne eventuelle tvetydigheter. Det er også mulig å legge inn tidskrav og andre begrensninger (rammebetingelser) i scenariet. Use cases oppfattes forskjellig av forskjellige aktører. Det er derfor hensiktsmessig å prioritere dem (på en skala 1-10) for hver aktør, og beregne et gjennomsnitt for hver. Dermed bestemmes hvilke use cases som er viktigst, og dette brukes til å prioritere hvilke systemdeler som leveres først. 21.4.2 Klasse-Ansvar-Samarbeids modellering CRC - Class-Responsibility-Collaborator Modeling CRC er en enkel teknikk for å identifisere og organisere klassene som er relevant for systemet eller kravene til produktet. En CRC-modell er en samling av indekskort som representer klasser. Kortet er delt i tre deler (se fig. 21.3): Navnet på klassen (toppen) Klasse ansvar (class responsibilities - til venstre) som er attributter og operasjoner i klassen Samarbeidspartnere (Collaborators - til høyre) som er de klasser som kreves for at klassen skal få det den trenger for å oppfylle sitt ansvarsområde. Systemutvikling Kap.21 Objektorientert analyse 23 Systemutvikling Kap.21 Objektorientert analyse 24 4
CRC Modeling class name: class type: (e.g., device, property, role, event,...) class characterisitics: (e.g., tangible, atomic, concurrent,...) responsibilities: collaborators: 21.4.2 Klasse-Ansvar-Samarbeids modellering CRC - Class-Responsibility-Collaborator Modeling Samarbeid (collaborators) identifiserer relasjoner mellom klasser. Når et sett klasser samarbeider om å oppfylle et krav, kan de samles i et subsystem. Samarbeid bestemmes av om en klasse kan oppfylle sitt ansvar selv. Hvis ikke, må den samarbeide (kommunisere) med en annen klasse. Til hjelp med å identifisere samarbeid, kan en undersøke 3 generelle relasjoner mellom klasser: 1. Er-del-av (is-part-of) relasjon 2. Har-kunnskap-om (has-knowledge-of) relasjon 3. Avhenger-av (depends-upon) relasjon Systemutvikling Kap.21 Objektorientert analyse 25 Systemutvikling Kap.21 Objektorientert analyse 26 21.4.3 Definering av strukturer og hierarkier UML: Class Diagrams Når klassene og objektene er definert, ved bruk av CRC modellen, må det lages en struktur i modellen, med hierarki av klasser og subklasser. Først bør en (i følge Coad Yourdon) lage en generaliseringspesialisering (gen-spec) struktur. Fig. 21.4 viser sensor objektet, der sensor er det generelle, og hver sensor er det spesielle (røyksensor). Vi får dermed et enkelt klassehierarki. I andre tilfeller kan et objekt som er representert i den opprinnelige modellen bestå av flere komponenter (deler) som selv skal kunne defineres som objekter. En slik struktur kalles hel-del-(whole-part)-struktur og defineres med en notasjon som vist i fig 21.5. Generalizationspecialization Generalisering-spesialisering Klasse - subklasse Composite Agregat (består av) aggregates Systemutvikling Kap.21 Objektorientert analyse 27 Systemutvikling Kap.21 Objektorientert analyse 28 21.4.4 Definering av subjekter og subsystemer Et subjekt eller et subsystem er en gruppe klasser som samarbeider for å oppfylle et sett med sammenhengende ansvarsforhold. Både et subjekt og et subsystem er abstraksjoner som gir en referanse eller peker til flere detaljer i analysemodellen. Sett utenfra kan et subjekt eller subsystem ses på som en svart boks som inneholder et sett ansvarsforhold som har egne samarbeidspartnere utenfor. Et subsystem implementer en eller flere kontrakter med sine utenforstående samarbeidspartnerne. En kontrakt er en spesifikk liste av forespørsler som samarbeidspartnere kan utføre. I CRC-modellen er det mulig å lage indekskort for subsystemer, med navn på subsystemet, kontraktene det imøtekommer, og klassene eller andre subsystem som støtter kontraktene. Pakke (subsystem) refaranse UML: Package Reference Systemutvikling Kap.21 Objektorientert analyse 29 Systemutvikling Kap.21 Objektorientert analyse 30 5
Relationships between Objects 21.4.4 Definering av subjekter og subsystemer Fig. 21.6 viser flere detaljer i kontrollpanelet fra fig.21.5 som er en assembly struktur (består av). Hele strukturen kan refereres med subjekt som vises bokser. Vi lager subjekt referanse av hver struktur som har mer enn 5-6 objekter. På det mest abstrakte nivå vil OOA modellen inneholde bare subjekter (subsystemer, referanser). Hver referanse vil bli ekspandert i en struktur Fig. 21.7 viser referanse til kontrollpanel og sensorer. Systemutvikling Kap.21 Objektorientert analyse 31 Systemutvikling Kap.21 Objektorientert analyse 32 21.5 Objekt-relasjonsmodell (the object-relationship model UML: State Transition Fig. 21.8 viser eksempel på en objekt-relasjonsmodell der kardinaliteten er definert. 21.6 Objekt oppførselsmodell (The object-behavior model) Systemets oppførsel må representeres som funksjoner av spesielle hendelser og tid. Modellen viser hvordan systemet reagere på eksterne stimuli. Modellen kan lages ved å utføre 5 trinn, se s. 577. Systemutvikling Kap.21 Objektorientert analyse 33 Systemutvikling Kap.21 Objektorientert analyse 34 UML: Event Trace Systemutvikling Kap.21 Objektorientert analyse 35 6