Understanding Quality in Conceptual Modeling

Presentasjon om: "Understanding Quality in Conceptual Modeling"— Utskrift av presentasjonen:

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

2 Innhold Modelleringsspråk; eksempler Hva er en god modell ?
Egenskaper og Perspektiver Hva er en god modell ? Hva er ”De Gode Egenskaper” Et rammeverk for kvalitetsbetraktninger Kvalitetsrammeverket Kvalitetskrav og utsagn Virkemidler og teknikker for forbedret kvalitet Kvalitetstyper Eksempler på teknikker og verktøy

3 Modelleringsspråk, variasjoner, eksempler

4 Referentmodellering Basert på elementær sett-teori og lingvistikk.
Modellering av: Referent-sett, Referent-Elementer, Attributter, Relasjoner, CAGA Til bruk i Informasjonsforvaltning Navn TelefonNr. PostAdresse Besøksadresse Kunde F.Meldt av Kontrakt. gjelder for Feilmelding K.Mottar F.Fører til Bakgrunns informasjon Annet Kontrakt Inngår i Hastesak Planlagt vedlikehold Driftssjef D.Overvåker Opprettet dato Frist Jobb O.utfører Avtalt service Ikke påbegynt Aktiv AnsattNr. Ansatt Ferdig Pågår Venter GSM Telefon Operatør Kundekontakt + Õ {} Konrad Kabel

5 ER modellering ”Towards a unified view of Data”, Chen, 1976
Konseptmodellering ”skreddersydd” mot DB design Entiteter: Konsepter, ”Svake” entiteter, avhengige av andre (slags aggregering) Attributter (Nøkler, Flerverdier, Avledede) Relasjoner (M. attributter) pNr # biler (1,1) person (0,N) bil eier BilNr navn adr tlf kjøpsdato

6 Enhanced ER (EER) Modellering
Sub-klasser (Generalisering/Spesialisering) Kategorier kule raske o (1,1) eier (0,N) kjøretøy BilNr person u d pNr firma lastebil personbil bank FirmaNr Lastevekt passasjerplasser BNavn

7 ”Clawfoot” notasjon Min, Max angivelse vha. ”kråketær” Subsett
En bil kan ha 1 (min) eller mange (max) passasjerer bil passasjer En bil kan ha hatt 0 (min) eller mange (max) førere fører bil En bil kan ha 1 (min) og bare 1 (max) eier bil eier Subsett bil bil person laste kule raske

8 NIAM Introdusert 1970, Nijssen & Halpin
Fokusert mot mere detaljer enn ER Grunnlag for autogenerering av DB definisjoner i flere SQL dialekter Ønske om forklaringsgenerering person bil eier Eies av Per Kari LS 12345 ND 54321 VE 23456 person PNo har identifiserer

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

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

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

12 T-merking Entiteter der instansene varierer over tid
Subsett, der delmengden ”lever kortere” enn hovedmengden Relasjoner, der deltakelse varierer over tid firma ansatte p2 f3 firma firma person f2 f2 p2 f1 f1 p1 p3 arb.ledige person person by p1 p1 p1 p3 p3 p3 b2 b1 b3 by by tid b2 b2 b1 b1 b3 b3 t3 t2 t1

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

14 DFD Detaljering Tidsperspektiv Formalisering av inn/utgang
Start/Stopp Sekvens Hendelser Formalisering av inn/utgang Grunnlag for spesifisering av regler Markering av ”ressurser” Personer Datakraft Verktøy/hjelpemidler prosjektleder Prosjektstyrings verktøy Siste statusrapport Lag styringsrapport A2.1 T

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

16 Arbeidsflyt: TeamWare
Visuell definisjon av arbeidsprosess Oversikt over hele prosessen m. statusoppfølging Oversikt over ”personlig” arbeid, TO DO lister Definisjon av data og meldinger vha. ”Forms” Kopling til ”gruppevare” TeamWARE Office Microsoft Exchange Lotus Notes Integrert mot Web

17 TeamWare eksempel

18 PetriNett Formell prosessmodell, ”streng” matematisk definisjon
Opprinnelig brukt for modellering av Distribuerte systemer mhp Ressursbruk og Samtidighet Fokus på Simulering av modellen, Eksekverbar modell Spesielt populær for Arbeidsflyt BASIS: plasser plasser kan merkes med ”tokens”, indikerer ressurser transisjoner ”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

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

20 Modellkvalitet - hva er en god modell ?

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

22 Some common quality properties of information system specifications
appropriate - ability to capture germane concepts complete - everything the software shall do is included in the specification conceptually clean - simplicity, clarity, ease of understanding consistent - no requirement is in conflict with other requirements constructable - there is a systematic approach to formulating specifications executable - automatic execution of specifications expressive - everything relevant may be expressed without too much effort formal - specification in formal language permitting formal analysis of spec. precise - can find whether some realization does not meet some requirement testable traceable - the origin of each requirement statement is clear unambiguous, understandable, verifiable, minimal, modifiable,…..

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

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

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

26 Kvalitetskrav Syntaktisk kvalitet: Semantisk kvalitet:
Krav: ”At modellen er korrekt ihht. modelleringsspråkets syntaks” Utsagn: M \ L = ∆ Semantisk kvalitet: Krav: ”At modellen inneholder alle relevante begrep og at disse er korrekt representert ihht. domenet. Utsagn: Korrekt: M \ D = ∆ , Komplett: D \ M = ∆ Pragmatisk kvalitet: Krav: ”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 , Mi = Ai

27 Kvalitetstyper og virkemidler

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

29 Modellkvalitet, Virkemidler

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

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

32 Virkemidler/Teknikk-eksempler
Hvorfor var ordren Ugyldig ? Forenkling Forklaring P1.2 P1.1 P1.3 P1.4 T P1.1 P1.3 P1.2 P1.4 T Flyten Ugyldig ordre ble sendt av P1 fordi Kundedata ikke var gyldige P1.1 P1.3 P1.2 P1.4 T Kodegenering Simulering P1.1 T P1.3 T T T P1.4 T T P1.2 T T T

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

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

35 Statisk konsistenstest i PrM
I/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 Syntakssjekking Sjekkliste: Navn Flyter Triggere/Terminering Porter
A priori regler : Aldri lov inn-ordrer ut-ordrer Sjekkliste: Navn Flyter Triggere/Terminering Porter Flytinnhold Prosessalgoritmer Datalagerinnhold A posteriori regler : Ikke lov i en ferdig modell Navn ? P1

39 Forklaring av modellen
Forklaring av syntaks P1 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 Forklaring av feil Motta Ordre P1 Diagrammet er ulovlig siden P1 ikke produserer noen ut-flyt. Alle prosesser må generere minst 1 ut-flyt En data-flyt kan ikke gå direkte mellom 2 datalagre inn-ordrer ut-ordrer

40 Forklaring av modellen (2)
Hvorfor ble ordren avslått ? Hvorfor ble ordren avslått ? P1 Ugyldig ordre ble sendt av prosess P1 fordi kundedata var ugyldig Motta ordre Hvorfor var kundedata ugyldig ? P1 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

41 Oppsummering Modeller varieres etter behov Hva er en god modell ?
Skreddersys ofte til konkrete bruksområder Tilpasses til verktøystøtte Hva er en god modell ? Det kommer an på … Domenet (D), Språket (L), Aktørene (A) Syntaktisk kvalitet Semantisk kvalitet Pragmatisk kvalitet Gode verktøy tilbyr virkemidler for forbedret kvalitet