Dagens tema / læremål Kravspesifisering (3): Forhold til Analyse og Design Guttorm Sindre, IDI Problemanalyse, kravspesifisering og design Forstå forskjeller mellom disse tre Forstå hvor modellering passer inn (og ikke) Forstå hva som bør modelleres i hhv A og D Bli bedre til å lage objektorienterte analysemodeller og designmodeller i praksis To artikler i pensum Davis: Requirements to Design: An Easy Transition? (995) Parsons/Wand: Using Objects for Systems Analysis, (997) Til dels overlappende, men også utfyllende Alan M. Davis Requirements to Design: An Easy Transition? Journal of Systems and Software, juli/august 995 Overgangen krav design Formålet med artikkelen Overgangen krav -- design må være vanskelig, også om man bruker samme perspektiv Reaksjon på -miljøets tese om seamless transition Rydde opp i terminologi (analyse, krav, design) Mer om Alan M. Davis Grunnlegger av firmaet Omni-Vista som lager verktøy for kravspesifisering, se http://www.omni-vista.com/davis/aldavis.htm Kjent for diverse artikler og bøker om systemutvikling, kravspesifikasjon og prosjektstyring, f.eks. 20 Principles of Software Development (995) Just Enough Requirements Management (200) Introduksjon om R vs D P (60-tallet): Innkapsling, klasser, arv D (midt 80-tallet) Gjerne basert på spesifikke P-språk R (sent 80-tallet) Vanlig term A, begrepsbruk forvirrende, jfr fotnote Mye A egentlig grovdesign R bør (som annen RE) inkludere Problemanalyse: forstå anvendelsesområdet Kravspesifisering: uttrykke systemets eksterne egenskaper teknikker hittil anvendelige for problemanalyse, ikke for kravspesifisering D, målsetning: lage en optimal arkitektur Vedlikeholdbarhet, Ytelse, Pålitelighet... I samsvar med kravene ofte lurt i design R innkapsling av data lavere kopling gjenbruk redusert arbeid, høyere pålitelighet Ikke noe mål om optimal arkitektur, men Forståelighet, kommunisere kundens behov Def. av objekt i R og D må være ulik
Objekter i kravspek vs objekter i design Eksisterende R-teknikker, kategorier Krav-objekter Representere en entitet i problemområdet Innkapsler dennes tilstand og tjenester Arver fra de klassene de er medlem av Velges / vrakes mhp forståelighet Design-objekter Innkapsler tilstand og tjenester Arver fra de klassene de er medlem av Velges / vrakes mhp ytelse, vedlikeholdbarhet e.l. I praksis er forskjellene ofte tåkelagte. Fra D R-objekt = D-objekt, forskjell bare detaljnivå 2. Fra DB-design R-objekt ~ entitet, dynamiske aspekter ignorert 3. Fra kravspek-miljøer R-objekt i tråd med Davis def. 4. Fra strukturert analyse (DFD,...) Egentlig ikke, PR-triks Transisjon fra krav til design Forskjeller på krav og design Meninger fra sentrale personer Ingen transisjon, samme slags objekter Jacobson, Embley Enkel transisjon (design mer detaljert) Coad/Yourdon, Booch, Rumbaugh et al. Kravspek hindrer fremgang (Cox) Ignorerer problemet (Meyer) The objects are there for the picking Behov for kravspek, vanskelig overgang Cherry, Lorenz, Shlaer/Mellor, Wirfs-Brock et al. ): mange A-teknikker egentlig tidlig design To vanskelige overganger: Problemanalyse krav Krav design Kan ikke trylles bort med lurt valg av språk! 7 viktige forskjeller:. Ulike objekter 2. System-objekt 3. Aggregering 4. Instansiering 5. Ulikt fokus på teknikker/tjenester 6. Generisitet, dynamisk binding 7. Verifisering, validering 7 viktige forskjeller (-3). Ulike objekter Viktig i problemdomenet, vs gunstig for designet? Eksempel, heissystem 2. Systemobjekt Passasjer et viktig objekt i problemanalyse, ikke senere Heisforespørsel viktig i design, ikke tidligere Fins ikke, men av ulike grunner 3. Aggregering Problemanalyse: løsningssystemet eksisterer ikke Krav, design: modellen er systemet Analyse, krav: ~ hel-del-forhold i domenet Design: gunstig pakking av programvarearkitekturen 7 viktige forskjeller (4-7) 4. Instansiering 5. Ulikt fokus Analyse, krav: lite bekymring for detaljene om dette Design: algoritmer for å opprette/slette obj. m.m. Analyse: Ikke detaljere oppførsel hvis forstått Krav: Ikke beskrive oppførsel internt mellom objekter Design: alle tjenester må beskrives i detalj 6. Generisitet, dynamisk binding Viktig i D, irrelevant i R 7. V & V, ulike behov Analyse: riktig modell av problemdomenet? Krav: realistiske, i samsvar med kundens/brukernes behov? Design: i samsvar med kravspek? 2
Råd for transisjon (-3). Innse at kravspek er nødvendig (jfr fig ) Kunder/brukere må vite hva de får Designere bør ikke ta krav-avgjørelser 2. Ikke forvent lett overgang Forståelighet vs smart design Avgjørelsen Hva skal automatiseres? er imellom 3. Velg passende utviklingsprosess (jfr fig 2) Komplekse produkter må analyseres i flere abstraksjonsnivåer R ikke eneste kandidat Råd for transisjon (4-6) 4. Bruk R-objekter som utgangspunkt i D Men mange må vrakes 5. Legg til andre objekter fra kravspek Automatiseringsgrense og ekstern interaksjon bestemt Mange mulige ideer til nye objekter Ikke så enkelt som å lete etter substantiv! 6. Design! Ikke lett å lage en optimal arkitektur som tilfredsstiller alle krav Ofte behov for nye design-objekter som ville vært irrelevante i krav-fasen, f.eks. stakker, køer Heis-eksempel, analysemodell Forb. Heis Trapp er_i er_i Etasje - nr Knapp..2 xor Passasjer vil_til trykker Heis-eksempel, designmodell Forespørsel Kø Heis Fordeler Etasje - nr Knapp..2 i problemanalyse Jeffrey Parsons og Yair Wand Using Objects for Systems Analysis Communications of the ACM, desember 997 Prog.konsepter sneket seg inn i analysemetoder For lavnivå for formålet Dette har redusert suksessen til A Designspørsmål forstyrrer forståelsen av problemområdet Gjør sluttproduktet dårligere Objekter i analyse bør ha Fokus på representasjon Ikke på implementasjon 3
Inspirasjonskilder Ontologisk angrepsvinkel Ontologi Et IS representerer ting i applikasjonsdomenet Se på det essensielle, ikke på overflateaspekter Kognitiv psykologi / klassifiseringsteori Et IS representerer menneskelig kunnskap om domenet Hvordan er kunnskap strukturert og organisert? Vil ta de to ovenstående angrepsmåtene for å se på ifbm analyse Og hvordan dette dermed må bli forskjellig fra design Inspirert av M. Bunge Ting og egenskaper Verden består av ting m visse egenskaper Tings tilstand vs attributter, som er hva vi vet om tingen Tings dynamikk: tilstand endres Interaksjon: ting påvirker annen ting Komposisjon: sammensatte ting Objekter: representasjoner av ting steoretisk angrepsvinkel Analyse av objektkonsepter Instans: kunnskap om en antatt eksisterende ting Egenskap: kunnskap om ting utover ren eksistens Strukturell, relasjonell eller oppførselsmessig Konsept: felles egensk. som deles av instanser Intensjonelt, dvs. definert av egenskapene Kan spesialiseres Formål: effektiv kunnskapsorganisering Komposisjon Instanser kan settes sammen av mindre del-instanser Objekter: representasjoner av kognitive instanser Ser nå på konsepter som definert i A-litteratur Sammenholder dette med ontologi og klassifiseringsteori Strukturerer diskusjonen i 4 bolker Objekter som distinkte enheter Assosiasjon og interaksjon Objektoppførsel Diskuterer flere punkt for hver av disse, ser etter Likheter og forskjeller, oppsummert tabell s. 08 Objekter som distinkte enheter Unik identitet litteratur: unik referanse Representasjon: eksistens, unikhet Innkapsling litteratur: information hiding Representasjon: struktur og oppførsel kan ikke separeres Persistens litteratur: objekters temporale dimensjon Representasjon: nominell invarians Homogenitet litteratur: Alt er objekter (elegant for prog.språk) Representasjon: ikke støtte for dette av objekter / instansiering ekstensjonelt (klasse), intensjonelt (type) Representasjon kombinert ekstensjon/intensjon (ontologi), eller Intensjon (klassifiseringsteori) Spesialisering / arv gjenbruk, deling av kode redefinering av metoder / attributter Representasjon: Subklasser må ha egenskaper som foreldre ikke har 4
Assosiasjon og interaksjon Objektoppførsel Komposisjon Reduserer kompleksitet, øker integritet, effektivitet Tilsvarer menneskelig tenkemåte Representasjon Må ha egenskaper utover delenes egenskaper (ontologi) Kommunikasjon mellom objekter : Sending av meldinger Representasjon: felles egenskap Assosiasjoner : inkludert Representasjon: felles egenskaper Polymorfisme litteratur: nyttig egenskap, men paradoks? Ontologi: presedens for egenskaper Dynamisk binding Ingen mening i representasjonsmodeller Samtidighet Ikke eksplisitt diskutert i representasjon Ingen motsigelse Implikasjoner for representasjon Oppsummering Struktur og oppførsel kan ikke separeres Ikke fulgt av f.eks Embley et al., Rumbaugh et al. Homogenitet meningsløst Multippel arv sterkt støttet Subklasser må legge til egenskaper Ikke fulgt av f.eks. Coad/Yourdon, Rumbaugh et al. Komposisjoner må legge til egenskaper Ikke vektlagt i A Meldingssending ikke relevant customer sends a message to the inventory item dette er implementasjon! A D: vanskelig overgang innimellom kommer kravspesifisering Dvs egentlig 2 vanskelige overganger Mange objekter vil være forskjellige Detaljnivå ikke hovedforskjellen En del mekanismer irrelevante på analysenivå En del A metoder designpregede ikke bevisst på representasjon av problemdomenet Mange konsepter nyttige for problemanalyse Men ikke for spesifisering av krav HVORFOR IKKE DET? 5