I programvareutvikling er domenemodellen konseptuell. Det inkluderer både atferd og data. I en teknikkontologi er en domenemodell en formell representasjon av et domene med konsepter, svermer, datatyper, individer og regler som vanligvis brukes for å beskrive logikk.
Generell informasjon
En domenemodell er et system av abstraksjoner som beskriver spesielle aspekter ved et domene med kunnskap, innflytelse eller aktivitet. Deretter kan den brukes til å løse problemer knyttet til dette området. En domenemodell er en representasjon av meningsfulle konsepter fra den virkelige verden knyttet til materielle aspekter som må modelleres i programvare. Konsepter inkluderer dataene som brukes i virksomheten og reglene som organisasjonen bruker for disse komponentene.
Domenemodellen bruker vanligvis et profesjonelt vokabular. Dette erlar deg kommunisere synspunkter til interessenter. Den må ikke referere til noen tekniske implementeringer.
Bruk
En domenemodell implementeres vanligvis som et objektrike i et lag som bruker lavere verdier for å lagre og publisere APIer på et høyt nivå for å få tilgang til dataene og oppførselen til riket.
The Unified Modeling Language (UML) bruker et klassediagram for å representere et system.
Funksjoner og nøkkelfunksjoner
En domeneinformasjonsmodell gir en representasjon av et helt domene, for eksempel klinisk forskning, helsevesen eller sykepleie. DIM-er lages vanligvis ved hjelp av UML-klassediagrammer (Unified Modeling Language) for å representere semantikken til hele faget ved å bruke et språk som er forståelig av fagfolk. Disse mønstrene viser vurderinger som mennesker, steder og aktiviteter, og hvordan de forholder seg til hverandre.
Applikasjoner, APIer, bedriftstillegg og andre elektroniske systemer kan utvikles ved hjelp av DIM. Selv om de er implementert med forskjellige programmeringsspråk, har alle sfærer som bruker DIM samme semantikk. Det gir et kritisk rammeverk for programvareinteroperabilitet og meningsfull datautveksling. Applikasjoner bygget ved hjelp av BRIDG har et felles konsept for "embedded", som sikrer kompatibilitet mellom slike heterogenesystemer.
Ingen av programmene som brukes vil implementere alle objektene i domenemodellen. Omfanget lar imidlertid sluttbrukere bla gjennom universet av BRIDG-semantikk og velge de spesifikke ressursene som trengs for å implementere enhver løsning. BRIDG bruker domenemodellkonsepter og eksempler som gir mening for eksperter, slik at de kan jobbe tett med programvareutviklere og analytikere for å validere DIM og velge objekter som er passende for prosjektet deres.
I tilfeller der ingen av elementene i BRIDG dekker den nødvendige semantikken til et nytt prosjekt, kan sluttbrukere jobbe med analyser. Et slikt samarbeid vil bidra til å identifisere disse hullene, gi brukstilfeller for å beskrive dem, og deretter fylle ut alle nyansene med ny semantikk. Domeneinformasjonsmodellen basert på BRIDG kan deretter brukes av utviklingsteamet. Dette er for eksempel relevant for å lage andre systemer.
Den logiske domenemodellen fra eksisterende prosjekter kan også brukes til å forbedre interoperabiliteten. Den fysiske utformingen er utviklet på bakgrunn av ovenstående. Den inkluderer systemspesifikke detaljer som programmeringsspråkspesifikke datatyper, tilgangsbegrensninger osv. Alle konkrete implementeringer vil lett kunne spores til referansestandarden.
Av Bruce Johnson
Den infologiske domenemodellen er en nøkkelkomponent for en vellykketutviklet datalagringsprogram eller deres arkitektur. Ofte, når den er opprettet, brukes den bare for segmentering. Enten noen utvikler den selv eller kjøper en løsning, kan det å ha en applikasjon hjelpe med mange operasjoner. Når den brukes effektivt, støtter og hjelper den også med utvikling og distribusjon.
Det er nødvendig å ta en dypere titt på konseptet med en domenemodell. Det er viktig for brukerne å forstå hvordan de får mest mulig ut av det.
Hva er SAM
En infologisk domenemodell er mest effektivt definert for å bryte ned forretningsdefinisjoner. Dette er høynivådomenene til løsningen, selv om de oftest brukes til å definere datadomener i en ny organisasjon eller en som utvikler et formelt arkitekturprogram.
Modellen skal legges til grunn for kartlegging av alle områder i organisasjonen. Nøkkelen til enhver vellykket domenemodell er å sikre at terminologien og definisjonene knyttet til den er forretningsspesifikke og forståelige med et øyeblikk. Det er ulike krav til antall varer som er effektive eller ønskelige. Som regel bør det være minst 6 og ikke mer enn 20.
Det generelle konseptet bak å lage en verdifull modell er at varer ikke skal endres. Etter hvert som virksomheten utvikler seg, kan den øke i karakter, men den bør ikke endre seg vesentlig.
Ulike metoder og tilnærminger for å definere domenemodellen for lydfor mange og for lange til å dekkes i én kort artikkel.
Hvordan du kan bruke SAM
En veldefinert applikasjon trenger ikke å være noe som er bygget og lagt på hylla. Dette er noe som må integreres i en dataarkitektur som samsvarer med årsaken til opprettelsen. Å definere forretningstilsyn og styringsmodell sikrer at virksomheten ikke bare er aktivt involvert, men hjelper til med å administrere og realisere verdien som oppnås. Mye av IT-støtten etter den første opprettelsen involverer visning og modellering av komponentene i det detaljerte dataområdet som utgjør den komplekse delen.
Hvordan får du det maksimale
Når SAM er opprettet, er det flere måter å bruke det på for å få mest mulig ut av det. Her er kategoriene du kan finne nyttige:
- Planlegging. Siden behov er prioritert og planlagt, kan SAM gi et rammeverk for å kommunisere prosjekter som skal utvikles og distribueres. Bedriftsledelse kan bidra til å gi en kobling mellom planlegging og datahandling for å skape felles terminologi som passer til entreprenørskaps natur.
- Etabler kontroll. Å bestemme hvordan en virksomhet kontrollerer innsamling, kvalitet og bruk av data er en viktig fordel med SAM. Ofte gjøres separasjonen av kontroll best av hvert fag separat. Dette kan bety tilstedeværelsen av offisielle forv altere, som hver er ansvarligfor en vare eller tilstedeværelsen av en person som er ansvarlig for dem.
- Planlegging for datainnsamling eller integrasjon. For å bygge domenemodeller og praksis for en domeneorientert designdefinisjon, kan systemet bidra til å logisk skille komponentene. Ved å gjøre det gir det fragmentering som lar ressurser fokusere på kvaliteten og integriteten til spesifikke områder og knytte dem til de riktige depotmottakerne.
- Kommunikasjon. En effektiv handlingsplan reduserer ofte hindringene som bremser prosjekter og leveranser. Å dele felles databehandling som en ressurs for en organisasjon kan gi flere fordeler. For det første vil det bidra til å lindre bekymringer om beskyttelse. For det andre kan du se hvordan utviklingen av systemene korrelerer med ressursene deres, samt hvordan dette vil påvirke den generelle suksessen til virksomheten. Planen kan brukes til å beskrive hvorfor dataene er nødvendige for å utføre analysearbeid.
- Definer krav. I enkeltprosjektdata er det nyttig å ha en høynivåmodell som du kan bruke for raskt å finne komponenter. I dette tilfellet brukes SAM til å kommunisere og verifisere hvordan behovene til enhver innsats passer inn i den overordnede arkitekturen. I informasjonslagringsarbeid gir dette grunnlaget for sortering og bestilling av kilden til målvisningen.
Utvikling av datamodell
Den vanligste bruken av SAM er å la simuleringsteamet fokusere ogprioritere når du lager et arkitekturprosjekt. Det kan deretter bli grunnlaget for å bygge den overordnede modellen, slik at flere ressurser kan jobbe med brikkene, og skape et bedriftsdatarike på samme tid.
En domenedatamodell er et verktøy som, når den er opprettet, kan og bør brukes til ulike formål. Ideelt sett blir sfæren hjørnesteinen i et veldefinert dataarkitekturprogram. Det viktigste er at det må brukes sammen for å lage et integrert program. Å samkjøre virksomhet og IT, en modell innen utvikling og tilsyn kan bidra til å bygge bro mellom innsats og planlegging.
Datakvalitet
Databasen som domenemodell spiller en av hovedrollene i en vellykket virksomhet. Informasjon er en viktig ressurs for en bedrift. Derfor er kvaliteten av avgjørende betydning. Individuelle redundante data er en av de viktigste medvirkende årsakene til lave rater. EDM er viktig for datakvaliteten fordi den oppdager inkonsekvenser som er iboende i redundante sfærer. Eksisterende problemer kan identifiseres ved å sammenligne systemer med EDM. Siden de nye områdene bygges på toppen av bedriftsdatamodellen, vil mange potensielle kvalitetsproblemer bli identifisert og løst før implementering.
besittelse
Eierskap til bedriftsdata er viktig på grunn av deres delte natur, spesielt i vedlikehold og administrasjon. EDM brukes som et eierskapsstyringsverktøy,identifisere og dokumentere relasjonene og avhengighetene til informasjon som krysser forretnings- og organisasjonsgrenser. Dette støtter konseptet med delt eierskap som finnes i Corporate Spheres Initiative.
Utvidbarhet for datasystem
EDM støtter voksende arkitektur. Utvidbarhet er muligheten til å skalere funksjonaliteten til et system for å effektivt møte behovene til et skiftende brukermiljø. Utvidbare systemer har muligheten til å legge til eller øke funksjonalitet med få bivirkninger. EDM, basert på et teknologiuavhengig strategisk forretningskonsept, støtter utvidbarhet, og muliggjør overgang til nye mulighetsområder med minimale IT-endringer.
Integrasjon av bransjedata
Ingen virksomhet opererer i et vakuum. Siden EDM inkluderer utseende, forbedrer det muligheten for en organisasjon til å dele felles data på tvers av bransjen. Organisasjoner i samme felt bruker ofte de samme underliggende dataene (for eksempel kunder, lokasjon, leverandører). Organisasjoner kan også dele informasjon med relaterte bransjer eller forretningspartnere. For eksempel, innen luftfart, integrerer fagfolk ofte med bilutleiefirmaer. EDM fra sitt industriperspektiv inkluderer en strukturell domenemodell for datainteraksjon.
Integrasjon av pakkede applikasjoner
EDM kan brukes til deres støtte, planlegging og kjøp,samt for gjennomføring. Dette oppnås ved å kartlegge den pakkede applikasjonen til EDM, og etablere dens intra-enterprise mapping. Siden eksisterende systemer også er korrelert, kan integrasjonspunkter mellom den pakkede applikasjonen og eksisterende systemer identifiseres, og gir et veikart for flyten av konsistente kvalitetsdata gjennom produktet.
Strategisk systemplanlegging
EDM definerer dataavhengigheter. Fordi eksisterende domenemodellsystemer er kartlagt til EDM, kan en gapanalyse utføres for å bestemme informasjonsbehovet til virksomheten. Fra å analysere hull og dataavhengigheter kan systemutgivelser prioriteres.
Enterprise Data Modeling-domeneprosessmodellen bruker en top-down-bottom-up-tilnærming for alle systemdesign. EDM er en artefakt avledet fra nedstrøms trinn. Oppstrøms er også viktige fordi de bruker eksisterende kilder for å lage prosjekter effektivt og praktisk.
Et domenedomene (ESAM) blir først opprettet og deretter utvidet til å basere Enterprise Conceptual Model (ECM). Mens modellene henger sammen, har hver sin unike identitet og formål. Å lage EDM er mer kunst enn vitenskap.
Hva er ESAM
La oss vurdere hva en bedriftsdomenemodell (ESAM) er. Bedriftsområder er all informasjon som er viktig for virksomheten og oppbevart for ytterligere bruk. Data vil ikke bli lagret med mindretrenge. Dermed kan de fleste områder betraktes som en bedrift, noe som gjør omfanget enormt. Dette gjelder selv for sterke team som er nesten umulige å designe, utvikle og vedlikeholde uten å bryte opp i mer håndterbare deler.
Hovedmålet med bedriftsdomenemodellen er ideen om "del og hersk". ESAM dekker hele organisasjonen. Alle data produsert og brukt av virksomheten er representert i fagområdet. Gjennomsnittlig antall for en organisasjon er 10 til 12. Ytterligere fagområder kan være nødvendige for mer komplekse systemer. ESAM er grunnlaget for bedriftsinformasjon.
Beskrivelse av domenemodellen
Hvert område er en klassifisering av data på høyt nivå, som representerer en gruppe konsepter relatert til hovedtemaet. Det gjenspeiler interessen til organisasjonen. Domenerelasjonsmodeller kan representere generelle forretningskonsepter (kunde, produkt, ansatt og økonomi) så vel som bransjekonsepter.
Tematiske områder kan grupperes i tre forretningskategorier på høyt nivå: inntekt, aktiviteter og støtte. Disse grupperingene er viktige fordi hver av dem representerer et tydelig forskjellig forretningsfokus. Inntektstyper fokuserer på profitt, inkludert planlegging, regnskap og ansvarlighet. Driftstyper representerer de viktigste forretningsfunksjonene som er involvert i daglige aktiviteter.
Støtteenheter bistår forretningsaktiviteten, representerer ikke kjernevirksomheten. Alle organisasjoner deler disse forretningsgruppene på høyt nivånivå. For eksempel er flyselskapets emneområder gruppert som følger:
- Inntektsbillett, booking, salg, inventar, priser.
- Operasjon: flyreise, plassering, utstyr, vedlikehold, tidsplan.
- Støtte IT, økonomi, ansatte, kunder.
Dataemneområde
Taxonomi er vitenskapen om å navngi, kategorisere og klassifisere ting i en hierarkisk rekkefølge basert på et sett med kriterier. Data Taksonomi er et klassifiseringsverktøy som brukes på data for å forstå, designe, vedlikeholde og bygge en domenemodell. Taksonomi inkluderer flere hierarkiske nivåer av klassifisering. På høyeste nivå kan all data plasseres i ett av tre systemer: grunnleggende, transaksjons- eller informasjonssystemer. De er forskjellige i produksjonsmodeller og konsept, så vel som livssykluser.
Underliggende data brukes til å definere, støtte eller opprette andre områder. De inkluderer informasjon om referansetype, metadata og lister som kreves for å utføre forretningsoperasjoner. Transaksjonsdata er data opprettet eller oppdatert som et resultat av forretningstransaksjoner i systemet. De er dynamiske og relevante for operativsystemer.
Informasjonsdata er historisk, aggregert eller avledet. De er vanligvis laget av intelligens som finnes i beslutningsstøttesystemer.
Fagområder kan klassifiseres i henhold til deres dominerende gruppering. På detaljnivåfagområder inneholder alle tre dataklassene. Systematisering er basert på størrelse, bruk og gjennomføring. For eksempel kan de 14 flyselskapstemaene klassifiseres som følger:
- Basic class - utstyr, IT, ansatt, salg, plassering, kunde.
- Transaksjoner – billett, bestilling, flyreise, økonomi, service.
- Informasjon - priser, beholdning, diagrammer.
Opprette en strukturell modell av fagområdet
ESAM er utviklet i nært samarbeid med forretningseksperter og veiledet av eksisterende bedriftskunnskap. Organisasjonsstrukturene til domenemodellen og forretningsfunksjonen må defineres og forstås. All informasjon er felles for de fleste organisasjoner (kunde, ansatt, lokasjon og økonomi). Det bestemmes først. Ytterligere fagområder blir deretter utpekt, og avsluttes med en fullstendig liste over offisielle områder. De blir deretter gjennomgått med forretningseksperter.
Prosessen med å definere og navngi hvert fagområde er viktig fordi det gjør det mulig å oppnå konsensus på tvers av forretningsgrenser om emner som er avgjørende for organisasjonen. Dersom det kan oppnås enighet på et høyt nivå, vil de mer detaljerte begrepene være mye lettere å definere. Denne prosessen prioriterer den detaljerte analysen som kreves for den påfølgende utviklingen av EDM.
Spørsmål kan oppstå angående informasjonstype fagområder, siden de vanligvis består av generaliserte og historisketransaksjonsdata. Å definere et informasjonsdomene kan føre til at det ser ut som det hører hjemme i det opprinnelige transaksjonsdomenet. Vurder dette med et flyselskapseksempel:
Bestilling er et transaksjonsdomene, beholdning er en informasjonskilde.
Hovedkonseptet heter Booking History. Den inneholder dataene som trengs for å få den tilgjengelige listen over steder. Reservasjon og inventar er viktige, men separate fagområder for flyselskapet.
Titler bør være veldig klare, konsise og konsise. Ideelt sett består fagområdet av ett ord. Der det er mulig, brukes industristandard firmanavn (klient, ansatt og økonomi). Definisjonene er formulert fra et horisont alt perspektiv da all relevant informasjon vurderes. De er viktige fordi de studeres av hele organisasjonen. Derfor bør definisjoner være så enkle og klare som mulig. Teoretisk, akademisk eller proprietært språk bør aldri brukes.
Relasjoner mellom fagområder representerer betydelige forretningsinteraksjoner og avhengigheter. Det er ingen valgmuligheter eller vareantall på dette nivået. Alle mulige relasjoner er ikke representert på grunn av praktiske forhold. ESAM er ikke designet for å vise hvert fagområde som en slags silo. Det kan tenkes på som et diagram med overlappinger som slutter på bare ett emneområde.
Farge spiller en viktig rolle i ESAM så vel som i hele EDM. Hverfagområdet, dets påfølgende konsepter og dataobjekter har sin egen konnotasjon. Én farge brukes for alle konsepter, objekter og tabeller knyttet til et bestemt område. Å bruke fargetone gir umiddelbar innsikt når du ser på noen av organisasjonens modeller.
Building ESAM følger bedriftens standarder, navnemetodikk og analyseprosess. Databasen som domenemodell er nøkkelen, fordi med dens hjelp vil alle objekter være knyttet til ett enkelt område.
