Presentasjon lastes. Vennligst vent

Presentasjon lastes. Vennligst vent

Understanding Quality in Conceptual Modeling Odd Ivar Lindland, Guttorm Sindre, Arne Sølvberg IEEE Software, March 1994.

Liknende presentasjoner


Presentasjon om: "Understanding Quality in Conceptual Modeling Odd Ivar Lindland, Guttorm Sindre, Arne Sølvberg IEEE Software, March 1994."— Utskrift av presentasjonen:

1 Understanding Quality in Conceptual Modeling Odd Ivar Lindland, Guttorm Sindre, Arne Sølvberg IEEE Software, March 1994

2 Innhold zModelleringsspråk; eksempler zEgenskaper og Perspektiver zHva er en god modell ? zHva er ”De Gode Egenskaper” zEt rammeverk for kvalitetsbetraktninger zKvalitetsrammeverket zKvalitetskrav og utsagn zVirkemidler og teknikker for forbedret kvalitet zKvalitetstyper zEksempler på teknikker og verktøy

3 Modelleringsspråk, variasjoner, eksempler

4 Referentmodellering zBasert på elementær sett-teori og lingvistikk. zModellering av: zReferent-sett, Referent-Elementer, Attributter, Relasjoner, CAGA zTil bruk i Informasjonsforvaltning

5 ER modellering z”Towards a unified view of Data”, Chen, 1976 zKonseptmodellering ”skreddersydd” mot DB design zEntiteter: Konsepter, ”Svake” entiteter, avhengige av andre (slags aggregering) zAttributter (Nøkler, Flerverdier, Avledede) zRelasjoner (M. attributter) pNr personbil eier navn adrtlf BilNr (0,N) (1,1) kjøpsdato # biler

6 Enhanced ER (EER) Modellering zSub-klasser (Generalisering/Spesialisering) zKategorier eierkjøretøy BilNr (0,N) (1,1) lastebilpersonbil d kule raske o person bank firma u pNr BNavn FirmaNr Lastevektpassasjerplasser

7 ”Clawfoot” notasjon zMin, Max angivelse vha. ”kråketær” bilpassasjer fører bileier z En bil kan ha 1 (min) og bare 1 (max) eier z En bil kan ha hatt 0 (min) eller mange (max) førere bil z En bil kan ha 1 (min) eller mange (max) passasjerer zSubsett bil personlaste bil kuleraske

8 NIAM zIntrodusert 1970, Nijssen & Halpin zFokusert mot mere detaljer enn ER zGrunnlag for autogenerering av DB definisjoner i flere SQL dialekter zØnske om forklaringsgenerering person eierEies av bil Per Kari LS ND VE person haridentifiserer PNo

9 UML Klassediagram navn attributter operasjoner z UML klasse definisjon kjøretøy id personbil Reg.Nr. person P.Nr hjul dimensjon motor motornummer chassis id (3..4) (1) (0..*) (1) < P.eier z I tillegg: z Datatyper z Private, Protected, Public z Operasjons-signaturer

10 UML Notasjon (detaljer) z Fra: “UML Notation Guide” -

11 ERT - ER modellering med Tid zTidsperspektivet av datamodellering er generelt dårlig dekket z”Data”-Tid; zOfte diskrete-tidsintervall zHendelses-tid (i virkelig verden) zTransaksjons-tid (i databaseverden) zOfte vanskelig å få med seg i designet zGir spesielle tabeller/attributter èØnskelig å skille ut tidsavhengige entiteter è Bruker ’T’ og ’H’ merking av Entiteter og Relasjoner

12 T-merking zEntiteter der instansene varierer over tid zSubsett, der delmengden ”lever kortere” enn hovedmengden zRelasjoner, der deltakelse varierer over tid firma tid person zp1 zp3 firma zf1 zf2 by zb1 zb2 zb3 person zp1 zp3 firma zf1 zf2 by zb1 zb2 zb3 person zp1 zp3 zf3 by zb1 zb2 zb3 zp2 ansatte zp2 arb.ledige zp1 zp3 zt1zt1 zt2zt2 zt3zt3

13 Eksempel, ERT modell person by ansatte arb.ledige firma T T T T T H T Har bestefar

14 zTidsperspektiv zStart/Stopp zSekvens zHendelser zFormalisering av inn/utgang zGrunnlag for spesifisering av regler zMarkering av ”ressurser” zPersoner zDatakraft zVerktøy/hjelpemidler prosjektleder Prosjektstyrings verktøy Siste statusrapport Lag styringsrapport A2.1 TT T DFD Detaljering

15 ARIS(EPC: Event Process Chain) Data Funksjon Aktør Funksjon hendelse Prosess kjede Materialer … zTysk ”CASE”-omgivelse siden 1985 (SAP siden ’87) zMarkedsleder på prosessmodellering, iflg. Gartner Group zFokus på integrasjon av organisatorisk informasjon og data inn i prosessen

16 Arbeidsflyt: TeamWare zVisuell definisjon av arbeidsprosess zOversikt over hele prosessen m. statusoppfølging zOversikt over ”personlig” arbeid, TO DO lister zDefinisjon av data og meldinger vha. ”Forms” zKopling til ”gruppevare” zTeamWARE Office zMicrosoft Exchange zLotus Notes zIntegrert mot Web z

17 TeamWare eksempel z

18 PetriNett zFormell prosessmodell, ”streng” matematisk definisjon zOpprinnelig brukt for modellering av Distribuerte systemer mhp Ressursbruk og Samtidighet zFokus på Simulering av modellen, Eksekverbar modell è Spesielt populær for Arbeidsflyt plasser transisjoner plasser kan merkes med ”tokens”, indikerer ressurser z ”Fyring”: Transisjonsovergang, kan skje når alle input-plasser har token ”Konsumerer” 1 token fra alle input plasser og genererer token på alle ut-plasser BASIS:

19 Behaviour Network Model zSpesifisering av ressurser. Kopling til ”datamodell” zDefinisjon av PRE og POST - betingelser for transisjoner (regler, logikk) tl timeliste ID: Ansatt Nr. Arb.Timer * Y z m z pre: m= ”lag lønns-slipp” z post: ’neste’ Y = tl z pre: Y = {} z post: z pre:  y i  Y z post: Y = Y - y i  z = y i  z.lønn = y i * timelønn Lønnsslipp

20 Modellkvalitet - hva er en god modell ?

21 Quality assessment approaches zquality of end-product depends to a great extent on the quality of early models (conceptual models, requirements) zmost quality frameworks appear as lists of desired properties of the considered systems zour framework distinguishes between goals and means, and is based on linguistic concepts

22 Some common quality properties of information system specifications zappropriate - ability to capture germane concepts zcomplete - everything the software shall do is included in the specification zconceptually clean - simplicity, clarity, ease of understanding zconsistent - no requirement is in conflict with other requirements zconstructable - there is a systematic approach to formulating specifications zexecutable - automatic execution of specifications zexpressive - everything relevant may be expressed without too much effort zformal - specification in formal language permitting formal analysis of spec. zprecise - can find whether some realization does not meet some requirement ztestable ztraceable - the origin of each requirement statement is clear zunambiguous, understandable, verifiable, minimal, modifiable,…..

23 Weaknesses of the “list-approach” to quality assessment zMany definitions are vague, complicated, undefined zList is unstructured, and properties overlap zSpecification properties, language properties and model properties are intermixed zSome properties are design/implementation directed zSome goals are unrealistic/impossible to reach, e.g., completeness

24 Kvalitetsrammeverket ModellDomene Modellerings Språk Aktører Semantisk kvalitet Syntaktisk kvalitet Pragmatisk kvalitet D M L A

25 The statements zThe language L consists of all of the statements that can be made according to the syntax zThe domain D consists of all possible statements that are both correct and relevant for the problem at hand zThe model M is the set of statements actually made zThe audience interpretation A is the set of statements that the audience thinks that the model contains

26 Kvalitetskrav zSyntaktisk kvalitet: zKrav: ”At modellen er korrekt ihht. modelleringsspråkets syntaks”  Utsagn: M \ L = ∆ zSemantisk kvalitet: zKrav: ”At modellen inneholder alle relevante begrep og at disse er korrekt representert ihht. domenet.  Utsagn:Korrekt: M \ D = ∆ , Komplett: D \ M = ∆ zPragmatisk kvalitet: zKrav: ”At modellen er forstått av de relevante aktører. En individuell aktør skal ha forstått de deler av modellen som er relevant for ham/henne.”  Utsagn:  i  M i = A i

27 Kvalitetstyper og virkemidler

28 Kvalitetstyper ModellDomene Modellerings Språk Aktører Verktøy Modell kvalitet Språk-kvalitet Prosess-kvalitet

29 Modellkvalitet, Virkemidler

30 CASE tools generelt Meta-Modell z Repository: Lagring av modeller Flerbruker-funksjonalitet z Meta-Modell: Spesifiserer modelleringsspråkene Definerer sammenhenger mellom modeller og elementer i forskjellige perspektiv z Flere integrerte modelleringsspråk z Verktøy og teknikker for bedret utnyttelse av modellene: z Syntakssjekking z Konsistenstesting z Simulering z Inspeksjon z Forklaringsgenerering z Eksekvering z Protoyping z Kodegenerering z … z Samarbeidsstøtte: Kommunikasjon Samhandling Koordinering

31 EXTERNALs Infrastructure SimVision: Project Simulation METIS: Modeling and visualization Workware: Workflow, interface to work tasks XCHIPS: Synchronous cooperation

32 Virkemidler/Teknikk-eksempler P1.1 P1.3 P1.2 P1.4 T T T T T T T T T P1.2 P1.1 P1.3 P1.4 T P1.1 P1.3 P1.2 P1.4 T T T T T T T T T P1.1 P1.3 P1.2 P1.4 T T T T T T T T T Hvorfor var ordren Ugyldig ? Flyten Ugyldig ordre ble sendt av P1 fordi Kundedata ikke var gyldige zForenklingzForklaring zKodegenering zSimulering

33 Konstruktivitet i DFD Motta Ordre P1 Telefon Mottak P1.1 Fyll ut P1.3 Motta ferdig utfylt P1.2 Sjekk ordre P1.4 ordrer godkjent ugyldig Kundedata Varedata Ordre

34 Konstruktivitet i PrM Telefon Mottak P1.1 Fyll ut P1.3 Motta ferdig utfylt P1.2 Sjekk ordre P1.4 ordrer Kundedata Varedata Ordre Motta Ordre P1 Kundedata Varedata Ordre godkjent ugyldig T T T T T T T T T T T T

35 Statisk konsistenstest i PrM zI/O Matrise, Logisk uttrykk O1 = (P1:I1  P1:I2)  (P1:I3) O1 = P1.4:O1 = (P1.4:I1  P1.4:I3)  (P1.4:I2  P1.4:I3)  (P1.3:O1  (P1.3:O2  P1.2:O1))  ( P1.2:O2  (P1.3:O2  P1.2:O1))  ((P1.3:I1  P1.3:I2)  ((P1.3:I1  P1.3:I2)  I3))  (I3  ((P1.3:I1  P1.3:I2)  I3))  ((P1.1:O1  I2)  (P1.1:O1  I2))  (((P1.1:O1  I2)  (P1.1:O1  I2))  I3 )  (I3  (((P1.1:O1  I2)  (P1.1:O1  I2) )  I3))  (((I1  I2)  (I1  I2))  ((I1  I2)  (I1  I2))  I3 )  (I3  (((I1  I2)  (I1  I2))  I3))  (I1  I2)  I3

36 Dynamisk konsistenstest

37 Simulering Eksempel: AUDIWEB Informasjon om aktiv dataflyt: Varefraktspesifikasjon: Produsenten sender en varefrakt- spesifikasjon til distribusjonslageret. Denne spesifikasjonen sendes til distribusjonsterminalen ved hjelp av et elektronisk kommunikasjonsmedie og inneholder informasjon om hvilke varer som kommer fra produsenten.

38 Navn ? P1 inn-ordrer ut-ordrer z A priori regler : Aldri lov z A posteriori regler : Ikke lov i en ferdig modell Syntakssjekking Sjekkliste: zNavn zFlyter zTriggere/Terminering zPorter zFlytinnhold zProsessalgoritmer zDatalagerinnhold

39 Forklaring av modellen zForklaring av syntaks P1 Motta Ordre P1 z Dette er en prosess. En prosess er et dynamisk konsept som leser et sett med inn- flyter og genererer et sett med ut-flyter. Alle prosesser har en ID og et navn. navn zForklaring av feil inn-ordrer ut-ordrer z Diagrammet er ulovlig siden P1 ikke produserer noen ut-flyt. Alle prosesser må generere minst 1 ut-flyt z En data-flyt kan ikke gå direkte mellom 2 datalagre

40 Forklaring av modellen (2) zHvorfor ble ordren avslått ? P1 z Ugyldig ordre ble sendt av prosess P1 fordi kundedata var ugyldig Motta ordre zHvorfor ble ordren avslått ? P1 z Kundedata var ugyldig fordi kunden har mindre enn 5000,- på konto. Dette bryter med regel R3: ”Ordrer fra direkte kunder godkjennes bare dersom vedkommende har mer enn 5000,- på konto” Motta ordre zHvorfor var kundedata ugyldig ?

41 Oppsummering zModeller varieres etter behov zSkreddersys ofte til konkrete bruksområder zTilpasses til verktøystøtte zHva er en god modell ? zDet kommer an på … zDomenet (D), Språket (L), Aktørene (A) zSyntaktisk kvalitet zSemantisk kvalitet zPragmatisk kvalitet zGode verktøy tilbyr virkemidler for forbedret kvalitet


Laste ned ppt "Understanding Quality in Conceptual Modeling Odd Ivar Lindland, Guttorm Sindre, Arne Sølvberg IEEE Software, March 1994."

Liknende presentasjoner


Annonser fra Google