Eksempler på UML-aktivitetsdiagram Her presenteres flere eksempler på UML-aktivitetsdiagrammer. Online shopping UML aktivitetsdiagram Formål. Et eksempel på aktivitetsdiagram for online shopping. Sammendrag. Online kunde kan bla gjennom eller søke på varer, vise spesifikk gjenstand, legge den i handlekurven, se og oppdatere handlekurv, gjør kassen. Brukeren kan når som helst se på handlekurven. Billettsalgsmaskin Formål. Et eksempel på UML-aktivitetsdiagram som beskriver oppførselen til kjøpsbilletts brukstilfelle for en billettsalgsmaskin. Sammendrag. Aktiviteten er startet av Commuter skuespiller som trenger å kjøpe en billett. Billettsalgsmaskinen vil be om turinformasjon fra Commuter. Basert på info maskinen vil beregne betaling på grunn og forespørsel betalingsalternativer. Etter at betalingen er fullført, sendes billetten til pendleren. Forretningsstrøm - Prosessordre Formål. Et eksempel på virksomhetsflyt UML aktivitetsdiagram for å behandle innkjøpsordre. Sammendrag. Forespurt rekkefølge er inngangsparameter for aktiviteten. Etter bestilling er akseptert og all nødvendig informasjon er fylt ut, er betaling akseptert og bestillingen sendes. Forretningsflyt - Dokumenthåndteringsprosess Formål. Et eksempel på UML aktivitetsdiagram som beskriver en dokumenthåndteringsprosess. En form for formell og riktig kommunikert dokumentstyringsprosess er vanligvis påkrevd i alle større selskaper, spesielt under regelverksoverensstemmelse. Sammendrag. Dokumentet er opprettet, gjennomgått, oppdatert, godkjent og på et tidspunkt arkivert. Dette aktivitetsdiagrameksemplet viser ansvar for ulike roller og en strøm av dokumentendringer. Partisjoner representerer ulike roller som deltar i aktiviteten - Forfatter, Anmelder, Godkjent og Eier. Elektronisk reseptstjeneste Formål. Elektroniske resepter UML aktivitetsdiagrameksempel er basert på dokumentasjon for Electronic Prescription Service (EPS) R2 utviklet av NHS Connecting for Health (NHS CFH) i England. Sammendrag. Prescribers kan sende resepter elektronisk til et apotek av pasientens valg der pasienten kan plukke den opp. Dispenser henter elektroniske resepter fra EPS. Programvare design - Løs problem Et formål. Et eksempel på UML-aktivitetsdiagram for å løse et problem i programvareutforming. Sammendrag. Etter utstedelse eller feilbilde er opprettet av en autoritet, og problemet ble gjengitt, problemet er identifisert, oppløsning er bestemt, problemet er fast og bekreftet, og billetten er stengt hvis problemet ble løst. Aktivering av Sentinel HASP SL foreløpig produkt UML aktivitet diagram eksempel Formål. Et eksempel på aktivitetsdiagram som beskriver manuell aktivering av prøveprodukt (foreløpig) produkt som var beskyttet av Sentinel HASP SL programvare nøkkel av Sentinel HASP - programvare for beskyttelse og lisensiering av sikkerhetsløsninger. Sammendrag. Kunden har noen prøveprodukt installert, for eksempel noe spill eller verktøy, som har en bestemt prøveperiode og kan ha noen begrensede funksjoner eller alternativer. Etter bruk av produktet for en tid, bestemmer kunden å aktivere produktet ved å be om en permanent, full produktlisens. Ordrebehandling lager en ny aktiveringsnøkkel for produktet. Enkelt pålogging (SSO) for Google Apps Formål. Et eksempel på UML-aktivitetsdiagram som beskriver Single Sign-On (SSO) til Google Apps for kunder som bruker noen hostede Google-applikasjoner, for eksempel Gmail. Sammendrag. Når en bruker forsøker å bruke noen vertsbaserte Google-applikasjoner, for eksempel Gmail, genererer Google en SAML-godkjenningsforespørsel og sender omdirigeringsanmodning tilbake til brukerens nettleser. Viderekoblingspunkter til den bestemte identitetsleverandøren. Saml-godkjenningsforespørsel inneholder den kodede nettadressen til Google-programmet som brukeren prøver å nå. Legg merke til en stavelsesfeil Velg teksten med musen og trykk Ctrl Enter. Dette dokumentet beskriver UML 2.5 og er basert på OMGtrade Unified Modeling Languagetrade (OMG UMLreg) 2.5 spesifikasjon UML 2.5 FTF - Beta 1. Alle UML diagrammer ble opprettet i Microsoft Visio 2007 eller 2010 ved hjelp av UML 2.2 stenciler. Du kan sende dine kommentarer og forslag til webmaster på webmasteruml-diagrams. org. Opphavsretts kopi 2009-2016 uml-diagrams. org. Alle rettigheter reservert. Vennligst aktiver JavaScript for å se kommentarene drevet av Disqus. UML Bruk saksdiagram Eksempel Sosiale Nettverkssider Prosjekt UML Diagrammer Sosiale Nettverkssider Prosjekt. Denne prøven ble opprettet i ConceptDraw PRO-diagrammer og vektor tegneprogrammering ved hjelp av UML Bruk Case Diagram-biblioteket i Rapid UML Solution fra Software Development-området i ConceptDraw Solution Park. Denne prøven viser Facebook Socio-helse systemet og brukes til projeksjon og opprettelse av sosiale nettverk. Et eksempel scenario presenteres for å demonstrere hvordan et felles problemsporingssystem ville fungere: (1) En kundeservice-tekniker mottar en telefonsamtale, e-post eller annen kommunikasjon fra en kunde om et problem. Enkelte programmer gir innebygd meldingssystem og automatisk feilrapportering fra unntakshåndteringsblokker. (2) Teknikeren verifiserer at problemet er ekte, og ikke bare oppfattes. Teknikeren vil også sørge for at nok informasjon om problemet er oppnådd fra kunden. Denne informasjonen inkluderer generelt kundens miljø, når og hvordan problemet oppstår, og alle andre relevante forhold. (3) Teknikeren oppretter problemet i systemet, og skriver inn alle relevante data, slik den leveres av kunden. (4) Siden arbeidet er gjort på dette problemet, oppdateres systemet med nye data av teknikeren. Ethvert forsøk på å fikse problemet bør noteres i problemstillingen. Billettstatus vil mest sannsynlig bli endret fra åpen til ventende. (5) Etter at problemet er fullstendig adressert, er det merket som løst i problemsporingssystemet. Hvis problemet ikke er fullstendig løst, vil billetten bli gjenåpnet når teknikeren mottar ny informasjon fra kunden. En Run Book Automation-prosess som implementerer beste praksis for disse arbeidsflytene og øker IT-personell effektivitet, blir svært vanlig. Problemsporingssystem. Wikipedia UML bruk saksdiagrameksempel Billettbehandlingssystem ble opprettet ved hjelp av ConceptDraw PRO-diagrammerings - og vektortegningsprogrammet utvidet med Rapid UML-løsningen fra Software Development-området i ConceptDraw Solution Park. UML bruk case diagram Den aksepterte åpne standard som brukes i programvare engineering og system design, når modellering objektorientert systemer og forretningsprosesser er kjent som Unified Modeling Language (UML). UML ble opprettet for definisjon, visualisering, design og dokumentasjonssystemer. Det er ikke et programmeringsspråk, men på basis av UML-modellen kan genereres kode. UML bruker generisk sett med grafiske notasjoner for å lage en abstrakt modell av systemet kalt UML-modellen. UML-notatet lar visuelt representere krav, delsystemer, strukturelle og atferdsmønstre, logiske og fysiske elementer, etc. UML definerer 13 typer diagrammer: Klasse (pakke), Brukssak, Sequence, Object, Collaboration, Component, Timing, Interaction Overview, Statlig maskin, sammensatt struktur, aktivitet og distribusjon. Alle disse typene UML Diagrammer kan raskt og enkelt opprettes med kraftig ConceptDraw PRO-programvare utvidet med spesiell Rapid UML-løsning fra Software Development-området av ConceptDraw Solution Park. Tjenester UML Diagram. ATM-system. Denne prøven ble opprettet i ConceptDraw PRO-diagrammer og vektor tegneprogrammering ved hjelp av UML Bruk Case Diagram-biblioteket i Rapid UML Solution fra Software Development-området i ConceptDraw Solution Park. Denne prøven viser ordningen for service ved hjelp av minibankene (Automated Teller Machines) og brukes ved arbeidet med ATM banksystemer ved utførelsen av banktransaksjonene. Denne prøven ble opprettet i ConceptDraw PRO-diagrammer og vektor tegneprogrammering ved hjelp av UML Bruk Case Diagram-biblioteket i Rapid UML Solution fra Software Development-området i ConceptDraw Solution Park. Denne prøven viser hvilke typer brukerinteraksjoner med systemet og brukes ved registrering og samarbeid med databasesystemet. Bruk Case Diagrams beskriver funksjonaliteten som et system gir med hensyn til skuespillere, deres mål representert som brukstilfeller og eventuelle avhengigheter blant de brukssaken. Unified Modeling Language (abbr. UML) er et allsidig modelleringsspråk som er mye brukt innen programvareutvikling, programvare engineering, utdanning, vitenskap, industri, virksomhet. I 1997 ble UML godkjent som standard av OMG (Object Management Group) og i 2005 ble utgitt som ISO-standard av International Organization for Standardization. UML er bredt og suksessfullt søkt for optimalisering prosessen med programvare systemer utvikling og forretningssystem analyse. Det er brukt 14 typer UML diagrammer, 7 av dem skildrer strukturell informasjon, ytterligere 7 typer representerer forskjellige typer atferd og aspekter av interaksjoner. Utforming av en hvilken som helst automatisert prosess er enkel med ConceptDraw PRO og unik Rapid UML-løsning fra området Software Development, som inneholder mange UML-eksempler, maler og vektorstablettbibliotek for å tegne alle typer UML 1.x og UML 2.x diagrammer. Bruk av forhåndsdefinerte UML-diagrameksempler og maler gjør at du raskt kan tegne dine egne UML-diagrammer i ConceptDraw PRO-programvaren. Aktivitetsdiagrammer: Hva de er og hvordan du bruker dem I sin grunnleggende form er et aktivitetsdiagram en enkel og intuitiv illustrasjon av hva som skjer i en arbeidsflyt, hvilke aktiviteter kan gjøres parallelt, og om det finnes alternative baner gjennom arbeidsflyten. Aktivitetsdiagrammer som definert i Unified Modeling Language 1 er hentet fra ulike teknikker for å visuelt illustrere arbeidsflyter, se for eksempel Johansson et al. 2. Og mye av grunnlaget for definisjonen av aktivitetsdiagrammet er funnet i Martin og Odell. 3. I den rasjonelle enhetlige prosessen 4. snakker vi om hvordan du kan bruke aktivitetsdiagrammer til å visualisere arbeidsflyten i en forretningsbrukstilfelle. En komplett arbeidsflytbeskrivelse vil ha en grunnstrøm, og en eller flere alternative strømmer. Denne arbeidsflyten har en struktur som vi kan definere tekstmessig, bruker uformell hvis, om-da-annet, eller gjør-til utsagn av forskjellige slag. For en enkel arbeidsflyt med en enkel struktur kan slike tekstdefinisjoner være tilstrekkelig, men i tilfelle av mer komplekse strukturer bidrar aktivitetsdiagrammer til å tydeliggjøre og gjøre det mer tydelig hva arbeidsflyten er. Historisk har aktivitetsdiagrammeteknikker hovedsakelig vært brukt i forretningsprosessmodellasjonsdomenet, men denne artikkelen vil også kort diskutere hvordan du kan bruke den i systemmodelleringsdomenet. Formålet med denne artikkelen er å vise hvordan du kan bruke aktivitetsdiagrammer i Rational Unified Process for forretningsmodellering samt systemmodellering. Aktivitetsdiagrammer blir ofte nevnt nesten som et synonym med forretningsmodellering. For en mer komplett introduksjon til hvilken forretningsmodellering vi refererer til Kruchten, 5 og for detaljer til Jacobson et al. 6. Leseren av denne artikkelen antas å være kjent med grunnleggende om Unified Modeling Language (UML). Grunnleggende aktivitetsdiagramnotasjon Som det er vanlig for de fleste notater, har aktivitetsdiagrammet noen elementer som er nødvendige for at du skal forstå om du vil være kjent med aktivitetsdiagrammer. Disse elementene er presentert i denne delen. Det neste avsnittet snakker om flere godbiter du kan finne nyttige. Figur 1 viser et grunnleggende aktivitetsdiagram. Figur 1: Et aktivitetsdiagram for Business Use-tilfellet Individuell innsjekking i Business Use-Case Modell av Airport Check-in Klikk for å forstørre Utvikle med tillit Konsekvent levere høykvalitets programvare raskere ved hjelp av DevOps-tjenester på IBM Bluemix. Registrer deg for en gratis Bluemix Cloud-prøveversjon. og komme i gang. Aktivitetstilstander. som representerer utførelsen av et trinn i arbeidsflyten. Overganger som viser hvilken aktivitetstilstand som følger etter hverandre. Denne typen overgang kan refereres til som en ferdigstillingsovergang. Den adskiller seg fra en overgang ved at den ikke krever en eksplisitt utløserhendelse som utløses av ferdigstillelsen av aktiviteten som aktivitetsstaten representerer. Beslutninger for hvilke et sett med vaktforhold er definert. Disse beskyttelsesforholdene styrer hvilken overgang et sett med alternative overganger følger når aktiviteten er fullført. Du kan også bruke beslutningsikonet til å vise hvor trådene slås sammen igjen. Beslutninger og vaktforhold gir deg mulighet til å vise alternative tråder i arbeidsflyten i et forretningsmessig tilfelle. Synkroniseringsstenger. som du kan bruke til å vise parallelle understrømmer. Synkroniseringsfelt lar deg vise samtidige tråder i arbeidsflyten i et forretningsmessig tilfelle. Avansert notering Betingede tråder Nestede aktivitetsdiagrammer Avdelinger Betingede tråder Vaktforhold kan brukes til å vise at et av et sett av samtidige tråder er betinget. For eksempel, i det individuelle innsjekkingseksemplet fra figur 2, kan passasjerkontrollen være et hyppig flygermedlem. I så fall må du tildele passasjers hyppige flyger miles. Figur 2: Tilordne Frequent Flyer Miles: En betinget tråd i Individuell innsjekkings arbeidsflyt Klikk for å forstørre Nested Activity Diagrams En aktivitetsstat kan referere til et annet aktivitetsdiagram som viser den interne strukturen til aktivitetsstaten. En annen måte å si dette på er at du kan ha nestede aktivitetsgrafer. Du kan enten vise grafen inne i aktivitetstilstanden (Figur 3), eller la aktivitetsstatusen referere til et annet diagram (Figur 4). Figur 3: En nestet aktivitetsgraf vist innenfor en aktivitetsstat Klikk for å forstørre Figur 4: Alternativ: Sett undergrafen i et separat diagram og la aktivitetsstaten vise det Klikk for å forstørre Viser undergrafen inne i aktivitetsstatusen er praktisk hvis du vil se alle detaljer i arbeidsflyten i samme diagram. Men hvis det er noen grad av kompleksitet presentert i arbeidsflyten, kan dette gjøre diagrammet vanskelig å lese. For å forenkle arbeidsflytgrafen, kan du i stedet velge å sette grafen i et separat diagram, og la aktivitetsstatistikkgrafikkdetaljene referere til diagrammet. Partisjoner Innholdet i et aktivitetsdiagram kan organiseres i partisjoner (svømmelaner) ved hjelp av faste vertikale linjer. En partisjon har ikke en formell semantisk tolkning, men er i forretningsmodellering ofte brukt til å representere en organisasjonsenhet av noe slag (figur 5). Figur 5: Et aktivitetsdiagram Illustrere arbeidsstrømmen til et forretningsmessig brukstilfelle som representerer en (generisk) salgsprosess. I dette eksemplet representerer partisjonene avdelinger i organisasjonen. Klikk for å forstørre Dokumentasjon av forretningsmessige bruksområder Bakgrunn: En forretningsmodellmodell beskriver prosessene i en bedrift og deres samspill med eksterne parter som kunder og partnere. Forretningsprosessene er representert som forretningsmessige saker, og de eksterne partene er representert som forretningsaktører. Beskrive et forretningsmessig brukstilfelle inneholder blant annet å gi det et navn, en kort beskrivelse, definere resultatmålene og arbeidsflyten. Det mest tidsmessige og tidkrevende aspektet som beskrives er arbeidsflyten. Som kommer først, aktivitetsdiagrammet eller tekstbeskrivelsen til arbeidsflyten Dette er noe avhengig av hvordan du er vant til å jobbe, og om du tenker grafisk eller ikke. Noen foretrekker å skissere strukturen visuelt i et diagram først, og deretter utvikle detaljene i teksten. Andre begynner med en punktliste liste over aktivitetstilstandene først og er enige om dem (som en trinnvis oversikt over brukssaken), og definer deretter strukturen ved hjelp av et diagram. Et gyldig spørsmål er også om du virkelig trenger både tekstdokumentet og diagrammet. Aktivitetsdiagrammeteknikken lar deg skrive korte beskrivelser av hver aktivitetsstat, som skal gjøre tekstspesifikasjonen av arbeidsflyten utelatt. Her må du være følsom for publikum og formatet der de forventer spesifikasjonen. For å forstå hva et aktivitetsdiagram legger til forståelsen av en arbeidsflyt, presenterer vi en arbeidsflytbeskrivelse, og deretter et aktivitetsdiagram for den aktuelle arbeidsflyten (figur 6). Dette eksemplet er en forslagsprosess, hentet fra en organisasjon som selger telekomnettverksløsninger, individuelt konfigurert for hver kunde. Vi har forenklet eksemplet ved å fjerne den detaljerte teksten i de fleste av undereksjonene, men prøvde å holde nok slik at du kan forstå strukturen i arbeidsflyten. Den fullstendige teksten til dette eksemplet finner du i Den rasjonelle enhetlige prosessen, versjon 5.1.1. Figur 6: Et aktivitetsdiagram for Business Use Case-forslaget Prosess Klikk for å forstørre Prøve Grunnleggende arbeidsflyt for Business Use Case-forslagsprosessen (Figur 6) Denne prosessen starter med en første kontakt mellom kunden og selskapet. Dette kan skje på en av følgende måter: 1.2. Initial Opportunity Work 1.2.1 Samle innledende Kundekrav 1.2.2 Opprett salgsplan (valgfritt) 1.2.3 Utføre Opportunity Analysis 1.3. Opprett forslagsprosjektplan 1.4. Opprett leveringsprosjektplan 1.6. Samle tilleggsinformasjon 1.7. Analyser og fullfør forslaget 1.8. Presentere forslaget 1.9. Hent kundeavgjørelse 2.1 Forretningsmulighet avvist Hvis, i 1.2. Det viser seg at forretningsmuligheten er avvist. Følgende handlinger kan bli tatt: 2.2 Kan ikke oppfylle kundekrav Hvis selskapet ikke kan foreslå en løsning på kundens krav i forbindelse med utførelse av mulighetsanalyse eller utarbeidelse av et tilbud, må følgende handlinger kan forekomme: 2.3 Kritisk informasjon ikke kjent Hvis noen ganger i forslagsprosessen identifiserer selskapet noen kritisk informasjon som ikke er kjent eller tilgjengelig, gjør den ett av følgende: 2.4. NewIncomplete eller Feil General Customer Profile Hvis selskapet fastslår at den generelle kundeprofilen er unøyaktig av en eller annen grunn, kan følgende tiltak tas. (Se Rational Unified Process, v.5.1.1, for flere detaljer.) Et aktivitetsdiagram for arbeidsflyten er vist i Figur 6. Vi bruker bare grunnleggende notasjon i dette diagrammet. Aktivitetstilstandene tilsvarer seksjoner i arbeidsflytbeskrivelsen: Aktivitetsstaten Første mulighetsarbeid består av tre delstrinn som kan gjøres parallelt. Dette er illustrert i en underskrift til denne aktivitetsstaten. Se figur 7. Figur 7: Underdiagram til aktivitetsstaten Initial Opportunity Work. Opprettelse av en salgsplan er valgfri, som er indikert av en vakttilstand på den innkommende overgangen. Klikk for å forstørre En aktivitetsstat kan representere en ganske stor prosedyre (med understruktur), så vel som noe relativt lite. Hvis du bruker aktivitetsdiagrammer for å definere strukturen i en arbeidsflyt, bør du ikke forsøke å utforske flere nivåer av aktivitetsgrafer ned til deres mest atomnivå. Dette vil mest sannsynlig gjøre diagrammet (eller sett med diagrammer, hvis du bruker separate undergrafer) veldig vanskelig å tolke. Du bør sikte på å ha ett diagram som skisserer hele arbeidsflyten, der noen av aktivitetsstatene har undergrafer. Dokumentere virksomhetsbruksområder Realisasjoner Bakgrunn: En forretningsmessig brukstilstandsdekning beskriver hvordan en bestemt sakbrukssak realiseres innenfor forretningsmodellmodellen, når det gjelder samarbeidende arbeidstakerne og forretningsenheter. En forretningsarbeider representerer et sett ansvar som vanligvis bæres av en person. En forretningsenhet representerer en ting som er opprettet, administrert eller brukt. Realiseringen av et forretningsmessig tilfelle kan beskrives tekstmessig, men forklares mer ofte med diagrammer - samarbeidsdiagrammer, sekvensdiagrammer, aktivitetsdiagrammer eller en kombinasjon. Hvilken diagramtype du velger, avhenger av kompleksiteten til arbeidsflyten og hvor du er i prosessen. Du bruker aktivitetsdiagrammet til å dokumentere forretningsmessige tilfeller, i stedet for forretningsbruk, hvis du bruker partisjoner og partisjonene er koblet til klasser (forretningsmedarbeidere hovedsakelig) i forretningsmodellmodellen (figur 8). Sammenlignet med et sekvensdiagram, som kan oppfattes å ha en tilsvarende hensikt, fokuserer et aktivitetsdiagram med partisjoner på hvordan du deler ansvar på klasser, mens sekvensdiagrammet hjelper deg å forstå hvordan objekter samhandler og i hvilken rekkefølge. Aktivitetsdiagrammer gir fokus på arbeidsflyten, mens sekvensdiagrammer gir fokus på håndtering av forretningsenheter. Aktivitetsdiagrammer og sekvensdiagrammer kan brukes som komplementære teknikker, hvor et sekvensdiagram viser hva som skjer i en aktivitetsstilstand. Figur 8: Samme arbeidsflyt Presentert i figur 6, men med aktiviteter organisert i partisjoner Klikk for å forstørre Bare for forretningsmodellering Bakgrunn: Bruksmodellen er en modell av en systembasert oppførsel. En brukstilfelle forteller historien om hvordan en bruker (representert som en skuespiller i modellen) kan bruke systemet til å oppnå en bestemt hensikt. Beskrive et brukstilfelle inkluderer å gi det et navn, en kort beskrivelse og definere hendelsesflyten i brukstilfellet. Akkurat som du vil bruke et aktivitetsdiagram for å vise strukturen i en arbeidsflyt, kan du også bruke den til å vise strukturen i en strøm av hendelser i et systembruksfall (figur 9). Figur 9: Et forenklet aktivitetsdiagram for brukssaken Ta ut penger i brukskassen Modell av en automatisert tellermaskin (ATM) Klikk for å forstørre I de første stadiene av identifiserende objekter og klasser basert på brukstilfeller (brukstilstandsanalyse) Aktivitetsdiagrammer kan være nyttige når du utforsker ansvarsområder for analyseklasser. Du kan bruke aktivitetsdiagrammetikken til å tegne en første skisse av klassens ansvar, en skisse som du deretter kaster bort. Denne artikkelen har gitt deg oversikt over: Grunnleggende og avanserte elementer i aktivitetsdiagrammet. Grunnleggende elementer av aktivitetsdiagrammer er aktivitetsstatus, overganger, beslutninger og synkroniseringsfelt. Hvordan aktivitetsdiagrammer lar deg vise samtidige tråder og alternative tråder, samt betingede tråder i en arbeidsflyt. Hvordan kan du bruke aktivitetsdiagrammer i forretningsmodellering. Du kan illustrere arbeidsflyten i et forretningsmessig tilfelle. Du kan beskrive hvordan en forretningsmessig bruk er realisert av forretningsmedarbeidere og forretningsenheter. Hvordan kan du bruke aktivitetsdiagrammer i systemmodellering. Du kan illustrere strømmen av hendelser i et brukstilfelle. Du kan definere hvordan en brukstilfelle realiseres ved analyseklasser. Referanser 1. OMG UML-spesifikasjon. 2. H. Johansson, P. McHugh, J. Pendlebury, og W. Wheeler, III, Business Process Reengineering. Breakpoint Strategies for Market Dominance. John Wiley and Sons, 1993. 3. J. Martin og J. Odell, Objektorientert Metode: En Foundation, UML Edition. Prentice Hall, 1996. 4. Rational Unified Process. versjon 5.1.1 5. Philippe Kruchten, den rasjonelle enhetlige prosessen: En introduksjon. Addison-Wesley, 1998. 6. Ivar Jacobson, Maria Ericsson, og Agneta Jacobson, Objektfordelen: Business Process Reengineering with Object Technology. Addison-Wesley, 1994. MERK: Denne artikkelen ble opprinnelig publisert på Rational Developer Network, lærings - og støttekanalen for det rasjonelle kundesamfunnet. Rasjonalt utviklingsnettverk er nå tilgjengelig for alle rasjonelle kunder. Nedlastbare ressurserUML - Aktivitetsdiagrammer Aktivitetsdiagram er et annet viktig diagram i UML for å beskrive dynamiske aspekter av systemet. Aktivitetsdiagram er i utgangspunktet et flytskjema for å representere strømmen fra en aktivitet til en annen aktivitet. Aktiviteten kan beskrives som en operasjon av systemet. Så kontrollstrømmen er trukket fra en operasjon til en annen. Denne strømmen kan være sekvensiell, forgrenet eller samtidig. Aktivitetsdiagrammer omhandler alle typer flytkontroll ved å bruke forskjellige elementer som gaffel, delta osv. De grunnleggende formålene med aktivitetsdiagrammer ligner andre fire diagrammer. Det fanger den dynamiske oppførselen til systemet. Andre fire diagrammer brukes til å vise meldingsflyten fra ett objekt til et annet, men aktivitetsdiagrammet brukes til å vise meldingsflyten fra en aktivitet til en annen. Aktiviteten er en bestemt operasjon av systemet. Aktivitetsdiagrammer brukes ikke bare til å visualisere dynamisk karakter av et system, men de brukes også til å konstruere det kjørbare systemet ved å bruke fremover og omvendt teknikk. Det eneste manglende i aktivitetsdiagrammet er meldingsdelen. Det viser ingen meldingsflyt fra en aktivitet til en annen. Aktivitetsdiagrammet er en gang betraktet som flytdiagrammet. Selv om diagrammene ser ut som et flytskjema, men det er det ikke. Det viser forskjellig flyt som parallelt, forgrenet, samtidig og enkelt. Så formålene kan beskrives som: Tegn aktivitetsflyten til et system. Beskriv sekvensen fra en aktivitet til en annen. Beskriv parallell, forgrenet og samtidig strøm av systemet. Hvordan tegne aktivitetsdiagram Aktivitetsdiagrammer brukes hovedsakelig som et flytskjema består av aktiviteter utført av systemet. Men aktivitetsdiagrammet er ikke akkurat et flytdiagram, da de har noen ekstra evner. Disse tilleggsfunksjonene inkluderer forgrening, parallellflytning, svømmefly etc. Før du tegner et aktivitetsdiagram, må vi ha en klar forståelse av elementene som brukes i aktivitetsdiagrammet. Hovedelementet i et aktivitetsdiagram er selve aktiviteten. En aktivitet er en funksjon utført av systemet. Etter å ha identifisert aktivitetene må vi forstå hvordan de er knyttet til begrensninger og forhold. Så før du tegner et aktivitetsdiagram, bør vi identifisere følgende elementer: Når de ovennevnte parametrene er identifisert, må vi lage en mental layout av hele strømmen. Denne mentale utformingen blir så omdannet til et aktivitetsdiagram. Følgende er et eksempel på et aktivitetsdiagram for ordrehåndteringssystem. I diagrammet identifiseres fire aktiviteter som er knyttet til forhold. Et viktig punkt bør klart forstås at et aktivitetsdiagram ikke kan være nøyaktig tilpasset koden. Aktivitetsdiagrammet er laget for å forstå aktivitetsflyten og hovedsakelig brukes av bedriftsbrukerne. Følgende diagram er tegnet med de fire hovedaktivitetene: Send bestilling av kunden Mottak av bestillingen Etter mottak av bestillingsforespørselsbetingelsen utføres det kontroller for å sjekke om det er vanlig eller spesiell bestilling. Etter at type ordre er identifisert, sendes aktivitetsaktivitet og det er merket som avslutning av prosessen. Hvor å bruke aktivitetsdiagrammer Den grunnleggende bruken av aktivitetsdiagrammet ligner andre fire UML-diagrammer. Den spesifikke bruken er å modellere kontrollflyten fra en aktivitet til en annen. Denne kontrollflyten inkluderer ikke meldinger. Aktivitetsdiagrammet er egnet for modellering av aktivitetsflyten i systemet. En applikasjon kan ha flere systemer. Aktivitetsdiagrammet fanger også disse systemene og beskriver flyt fra ett system til et annet. Denne spesifikke bruken er ikke tilgjengelig i andre diagrammer. Disse systemene kan være database, eksterne køer eller andre systemer. Nå vil vi se på de praktiske bruksområdene til aktivitetsdiagrammet. Fra ovennevnte diskusjon er det klart at et aktivitetsdiagram er tegnet fra et meget høyt nivå. Så det gir et høyt syn på et system. Denne høynivåvisningen er hovedsakelig for forretningsbrukere eller enhver annen person som ikke er teknisk person. Dette diagrammet brukes til å modellere aktivitetene som ikke er forretningskrav. Så diagrammet har større innvirkning på forretningsforståelse, snarere implementeringsdetaljer. Følgende er hovedbruken av aktivitetsdiagrammet: Modellering av arbeidsflyt ved å bruke aktiviteter. Modellering forretningskrav. Høyt nivå forståelse av systemfunksjonalitetene. Undersøk virksomhetskrav på et senere tidspunkt.
No comments:
Post a Comment