ATiSA H3: Beer Web Store

Størrelse: px
Starte visningen fra side:

Download "ATiSA H3: Beer Web Store"

Transkript

1 ATiSA H3: Beer Web Store Gruppe: Hotel Christer Vindberg, Anders Kabell Kristensen, Bo Sunesen og Anders Viskum , , og {chrisv10, dalko, sunesen, cs.au.dk december 2008

2 Indholdsfortegnelse 1 Software Architecture Beer Web Store Architectural Description - Beer Web Store Quality Attributes Beer Web Store Architectural Design Beer Web Store...11 Performance tactics...11 Availability tactics...11 Layered architectural style...12 Major elements in component and connector structure...12 Connector types Architectural Prototyping Beer Web Store...15 Types of architectural prototyping...15 Choosing programming language/framework...15 Architectural prototype for testability...15 Benefits and liabilities of using ArchJava...16 Service-Oriented Architecture Architectural Evaluation Beer Web Store...18 Beskrivelse af ATAM-processen...18 Identificering af sensitivity points, tradeoff points og risks...20 Fordele og svagheder ved ATAM i forbindelse med Beer Web Store...20 At bruge DiscoTect til evaluering af Beer Web Store...20 Sammenligning af ATAM og architectural prototyping...21

3 1 Software Architecture Beer Web Store Outline how you would approach the tasks of creating the architecture for the BeerWeb Store. Consider, e.g., which steps would you takes and in which order? I den meget simplificerede udviklingsproces som er vist på nedenstående figur undersøges de ønsket krav til systemet. Udviklingsprocessen undersøger både kvalitet og funktionelle krav. Ud fra disse opbygger man så systemets arkitektur krav, som så ledere os til software arkitektur kravene. Hvor ud fra vi kan gå i gang med at implementere et system. Figur 1 : The (Very) Simplified Development Process For at designe vores arkitektur har vi valgt at gøre brug af følgende punkter: Quality attributes: Her vil vi definere både kvalitets og funktionelle krav, og vi vil finde frem til de attributter der er vigtig for vores system, avalibility, security, usability er f. eks nok nogen vi vil fokusere meget på i vores Beer Web Store (BWS), men andre attributter som performance og modifiability vil nok også spille væsentlig rolle. Architectural Description: I dette punkt vil vi beskrive systemets arkitektur, vi vil også definere nogle viewpoints og forkellige views for dem. Efter som systemet kan være kompleks kan det være nødvendigt at have flere forskellige views. Vi vil nok også lave nogle tegninger over de forskellige views for at øge forståelsen. Architectural Design: Her vil vi designe de forskellige elementer og relationerne mellem disse, dette design skal opfylde de fundne kvalitets attributter. Vi kan her evt. også ligge os fast på et eller flere patterns som vi ønsker at gøre brug af. Architectural Evaluation: Her vil vi evaluere den fundne software arkitektur. Vi kunne f. eks vælge at strukturere vores evaluering som en Quality Assurance Workshop (QAW) som beskrevet i [Bass et. al. 2003] eller bruge ATAM [Kazman et al. 2000]. I begge disse scenarier vil vi nok ikke udføre alle skridt men tilpasse dem til vores ønsker og interesser. Vi vil nok udføre punkterne i den listet orden, men det kan meget vel være nødvendigt at besøge nogen af dem igen. Så en iterativ proces over punkterne er nok den bedste løsning.

4 Relate the definition of software architecture in [Bass et al., 2003] to the elements of your design as outlined above. Give concrete examples of elements, relations, and structures. Strukturen er vores lagdelte Client - Server arkitektur, som består af elementerne Client, Server og Database. Relationen mellem Client og Server er et web-baseret request/response pattern mens relationen mellem Server og Databasen følger Facade pattern et. De eksterne synlige egenskaber for Databasen er dem der er synlige gennem Facaden. Som en konsekvens af den lag delte struktur er klientens egenskaber ikke synlige for serveren, og serverens egenskaber kan heller ikke tilgås fra databasen. Apply [Perry and Wolf, 1992] s model of software architecture as Software Architecture = {Elements, Form, Rationale} to the Beer Web System I artiklen deler de elementerne op i 3 kategorier: processsing, data og connecting. Processing er transformationer af data, data er information der kan blive ændret på og connecting er den måde vi forbinder de forskellige elementer i arkitekturen på. Vi definere Client, Server, Database, Client - Server relationen og Facade relationen til at være elementer i systemet. Databasen er et Data element da det eneste den skal er at send og modtag data. Server, Client og Facade er Processing elementer da de har til opgave at processer den information de modtager også at sende den videre. Forbindelsen mellem Client og Server er vores Connection element som bruger en form for internet kommunikation til at kommunikere over. Form beskriver de relationer der binder systemet sammen, i BWS s tilfælde er det vores Client Server relationen der tydeligvis er en rationale for systemet, da det er et krav at vores BWS system fungere på tværs af internettet. Da facade pattern et abstrahere den konkrete database kunne det meget vel tyde på at abstraktion af databasen også er et rationale for systemet. Discuss how the intentionality/locality thesis relates to the example Den givne specifikation for vores BWS er bevidst, da den ikke beskriver en specifik implementering, men bare en general arkitektur. Denne arkitektur kan man implementere på mange forskellige måder. Lokaliteten for arkitekturen er non-local, da vi sagtens kan tilføje elementer til den nuværende struktur der vil bryde strukturen. Vi kan f. eks tilføje et element der muliggøre kommunikation op i gennem vores lag og derved bryde den lag delte struktur vi har i vores BWS system. Reflect on what happens if the words software and computing are removed from the definition of software architecture in [Bass et al., 2003] Hvis vi fjerne de to ord bliver definitionen meget mere general. Den kan nu bruges på et hvert system, hvilket gør definitionen meget bred. Det er nu mere en general beskrivelse af at der kan identificeres som elementer og egenskaber. Selvom man nok kan beskrive et hvilket som helst system på denne måde, er det ikke sikkert at det er ønskværdigt. Der er situationer i den rigtige verden og sikkert også nogen i den digital, hvor man sikker godt kan beskrive den på denne måde. Men det vil nok være mere praktiske og hensigtsmæssigt at gøre det på en anden.

5 The architect decides to create a full architecture description before embarking on any implementation of the system. Discuss pros and cons of taking that approach I software arkitektur er tid ofte en af de vigtigste ting for stakeholders, ofte vil stakeholders gerne have produktet/systemet ud på markedet så hurtigt som muligt, et for at sikrere at andre ikke frigiver et lignende produkt og for det andet for at de kan begynde at promovere produktet og potentielt tjene penge på det. Så selvom man nok for et bedre og mere stabilt produkt ved at finpudse arkitekturen, så koster det flere penge og kan gøre udviklingsprocessen længere. Modsat er der også problemer med at frigiver et ufærdig eller ikke ordentlig gennemtænkt produkt, da det meget vel kan øge maintenance, ikke ordentligt supportere modifiability, produktet kan have problemer med performance, og hvis der er bugs kan det påvirke avalibility. Valget af hvad man gør, afhænger af hvad stakeholders krav til systemet er. Der er dog vigtigt at man ittrere hen over processen og ikke bare løser den slavisk trinvis. Det er f. eks vigtigt at man bliver klar over om de valgte kvalitets attributter er mulig at implementere, enten teoretisk eller inden for den givne tidsramme.

6 2 Architectural Description - Beer Web Store Which structures does a system such as the above exhibit? Give examples of elements and relations pertaining to each structure Ifølge [Bass et al., 2003] er en arkitektur-struktur en samling af elementer og deres forbindelser. Et view er en repræsentation af en sådan struktur. Artiklen beskriver også hvordan systemer ofte er alt for komplekse til at beskrive og forstå på en gang. En beskrivelse af et system består derfor af flere views, der hver repræsenterer en bestemt struktur i systemet. Som vist på tegningen i opgaven består Beer Web Store systemet af et antal brugere, en webserver og en database. Der er ikke specificeret noget viewpoint, og vi ved derfor ikke præcist hvordan tegningen skal analyseres. Et viewpoint er en generel måde at lave et view på og specificerer altså hvilken struktur man har valgt at beskrive et view med. [Bass et al., 2003] har lavet tre inddelinger af disse strukturer: Module: Fokuserer på implementationdelen af systemet. Et system kan være delt op i et antal moduler, der logisk adskiller forskellige dele af systemet. Disse moduler kan deles om i mindre komponenter/moduler. Der er altså tale om en beskrivelse af de statiske dele af systemet. Component and Connector: Fokuserer på de elementer der eksisterer når systemet afvikles. Allocation: Fokuserer forskellige software elementer i forhold til det environment det afvikles i. I Beer Web Shop kan man vælge at tolke systemet sådan at der findes tre hoved elementer; brugere, webserver og databasen. Her vil webserveren og databasen være modulopbygget. Hvert af disse moduler definerer en afgrænset rolle/opgave. Webserveren er i dette tilfælde delt op i tre undermoduler (decomposition), der hver afgrænser bestemte opgaver indenfor webserverens opgaver. Brugerene kan ses som værende en del af environmentet. Dvs. at de ville høre en under strukturen Allocation. Which viewpoints are relevant when describing the example? Give examples of partials views for each viewpoint For at gøre tegningen i opgaven mere sigende, kunne man vælge at bruge viewpoints. Her ville et sekvensdiagram eksempelvis kunne illustrere hvordan brugerne interagere med systemet og hvordan kommunikationen mellem webserveren og databasen foregår. Her ville et deploymentdiagram (allocation viewpoint) hjælpe med til at beskrive de konkrete valg af database og webserver. For at beskrive skrukturen af webserveren yderligere, kunne module viewpointet bruges. Her kunne der gives en uddybning af hvordan webserveren er delt op (udover "overview", "basket" og "data") i forskellige moduler og klasser. Dette ville give et større indblik i hvordan den statiske struktur af systemet ville se ud. Til sidt ville et C&C viewpoint kunne føre til forskellige views, der beskrev flowet i systemet.

7 Argue for benefits and liabilities of describing software architecture via a boxand-line drawing such as the above Tegningen i opgaven er en såkaldt box-and-line tegning. Her er fokus ikke nogen dybere indsigt i systemet eller strukturen, men derimod at give overblik. Der bliver ikke fulgt nogen fast standard i udarbejdelsen af en sådan tegning. Fordelen er at der ikke kræves nogen særlig (computer-) forståelse når en sådan tegning skal diskuteres mellem flere parter. Her vil alle kunne være med til at diskutere. Dette ville højst sandsynligt ikke være tilfældet hvis man diskuterede views ud fra eksempelvis allocation viewpoint. Ulempen er selvfølgelig at en sådan tegning ikke er ret konkret og specielt sigende når man kommer udover en generel diskussion af systemet. Discuss how architectural reflection could be used on the final running system Når et system er færdigudviklet er det selvfølgelig interessant at se på om den oprindelige arkitekturbeskrivelse stemmer overens med det færdige system. Ved at bruge refleksion kan man danne en arkitekturbeskrivelse ud fra et færdigudviklet system. Her vil den statiske del kunne genereres via UML-programmer direkte ud fra source-koden. Hvis man ønsker sekvens diagrammer skal man selvfølgelig analysere programmet mens det kører. Det samme gør sig gældende med views lavet ud fra C&C viewpointet. Til sidst vil man så kunne sammenholde de to arkitekturbeskrivelser og se om de er ens. Discuss what architectural description would be needed if the system was to be written using ArchJava Her ville man skulle opdele systemet i component and connectors, dvs. ud fra C&C viewpointet. Samtidig skal alt kommunikation der sker mellem de forskellige connectors beskrives. Når dette er gjort kan man begynde implementationen i ArchJava.

8 3 Quality Attributes Beer Web Store Describe technique(s) for architectural requirements capture that are applicable to the above case I dette kursus har vi anvendt Bass et al. måde at beskrive kvalitet på. Her anvendes betegnelsen kvalitetsattributter, der beskriver kvalitative egenskaber ved et system. Bass et al. mener at følgende seks kvalitetsattributter er de vigtigste. Availability Modifiability Performance Security Testability Usability For at kunne anvende ovenstående attributter giver Bass et al. en måde at beskrive disse på; Kvalitetsscenarier. Disse anvendes til at repræsentere de forskellige krav. Give feasible architectural requirements for availability and performance for the Beer Web Store using such techniques (at least one for each quality attribute) Til Beer Web Store har vi lavet følgende scenarier: Performance Source Stimulus Artifact Enviroment Response Response Measure Databasen får 100 forespørgsler på et sekund. Internt Webserver kommer med dataforespørgsel System Normal Databasen returnerer de ønskede oplysninger En forespørgsel svares på 1/100 sekund

9 Performance Source Stimulus Artifact Enviroment Response Response Measure brugere tilgår webserveren i timen Eksterne brugere Sidernes indhold sendes tilbage til brugerne System Normal Siderne sendes/vises til brugerne En bruger skal have vist sin side indenfor 2 sekunder Avalibility Source Stimulus Artifact Enviroment Response Response Measure Databasen er blevet utilgængelig Intern Databasen har ikke svaret indenfor en fastlagt tidsperiode System Normal Ansvarshavene underrettes Backupserver tilsluttes indenfor 2 min. Argue how tactics and/or styles may be used to resolve the requirements Tactics beskriver hvordan bestemte kvaliteter opnås. Ved performance er målet at give svar på en forespørgsel inden for en given tid. Der er flere faktorere der spiller ind når man snakker om performance. Eksempelvis vil resourceforbruget have indvirkning. Resourcer kunne være CPU, hukommelse, plads på disk, båndbredde mm. Herudover er blokkeringer af resourcer også en faktor der spiller ind. Man vil f.eks. kunne komme ud for at vente på en ressource hvis en anden forspørgsel er i gang med at skrive til den. Sandsynligheden for at sådanne situationer opstår stiger i takt med at der kommer forespørgsler til ressourcen og tiden det tager at behandle en sådan forespørgsel. Dvs. problemet kan reduceres ved at gøre behandlingstiden mere effektiv. Dette kan gøres ved f.eks. benytte bedre algoritmer. I Availability er målet at undgå at fejl opstår og i tilfælde af at de gør, få dem rettet. Her deles taktikkerne op i forskellige kategorier; Fault Detection, Fault Recovery og Fault Prevention. I Fault Detection taktikken har man metoder til at se om der er noget galt. Dette kan f.eks. ske ved jævnligt at sende heartbeat signaler ud, der indikerer at serveren er i live. På samme

10 måde kunne der også kommunikeres ved ping/echo i faste tidsintervaller for at holde øje med om serveren var i live. Disse to taktikker opererer i forskellige processer. Hvis der er tale om komponenter i én proces, kan man bruge exceptions til at fange fejl. Ved Fault Recovery prøver man at forberede/lave et repair af systemet. Bass et al. beskriver flere måder at gøre dette på. Ved Voting-taktikken stemmer flere processer om hvad outputtet fra en algoritme er. Denne information sendes til en voter. De processer der ikke er enige med de andre markeres som fejlbehæftet. I Shadow Operation kan en proces der tidligere have fejlet køres i skygge. Her prøver processen at efterligne en normal proces før den igen selv bliver en aktiv service. Fault Prevention. Her kan man igen bruge forskellige taktikker. Removal from Service fjerner komponenten fra systemet for at undgå at den forventede fejl opstår. I Process Monitor kan man have en proces der overvåger andre processer. Hvis en fejl opstår slås processen ihjel og et nyt instans oprettes. Discuss where Service-Oriented Architecture can play a role with respect to the Beer Web Store? Consider the quality implications Nogle funktioner i Beer Web Store vil sagtens kunne flyttes ud af huset. F.eks. vil betalingsdelen af Beer Web Store godt kunne flyttes til et eksternt sted. Her skal man selvfølgelig være sikker på at det ikke går ud over ens kvalitetsattributter. På den anden side vil visse funktioner i Beer Web Store også kunne bruges af andre. Man kunne igen forestille sig betalingsdelen og f.eks. Basket delen af webserveren. Begge kunne være self contained og samtidig opfylde de to krav om at være Stateless og Context Independent. Reflect upon what the role of quality attributes in software architecture is Forskellige deltagere i en udviklingsproces har ofte mange forskellige holdninger til hvad kvalitet er. Det er da også rimelig klart at en udvikler ikke altid vil definere kvaliteten af noget software på samme måde som eksempelvis en grafiker. De kvalitetsattributter vi har kigget på, forsøger at lave en standard for hvordan kvalitet i software skal opfattes. Ved at have en sådan standard skulle det være muligt at træffe fælles beslutninger og konklusioner i forhold til hvilke kvaliteter der er vigtige i det konkrete system.

11 4 Architectural Design Beer Web Store Performance tactics Der er ifølge [Bass et al., 2003] tre kategorier af performance taktikker: Resource Demand Til det givne scenarie giver det mest mening at bruge taktikkerne increase computational efficiency og reduce computational overhead. Alternativt kan man prøve at reducere antallet af events der skal processeres, men da det er brugeren der styrer hvor mange events der kommer til systemet, ville det resulterer i at nogle events blev ignoreret, hvilket ville være meget uheldigt. Taktikken er altså at forbedre de algoritmer man bruger til at håndtere brugerens input, der består af betalingsoplysninger i det konkrete scenarie, samt minimere overhead i forbindelse med processeringen af disse input. Man skal dog være opmærksom på at hvis man reducerer overhead ved at fjerne abstraktionslag, hvilket medfører tab i modifiability. Resource Management Den nemmeste taktik at bruge her er increase available resources, men denne taktik har en klar ulempe; det koster penge. Desuden tilføjer den ikke nogen skaleringsmuligheder, hvis der kommer for mange samtidige brugere af systemet må man i ud og investere i endnu dyrere hardware. Det vil formegentlig være billigere at bruge de to andre nævnte teknikker til resource management: Introduce concurrency og maintain multiple copies of either data or computations. Det er dog vigtigt at man holder styr på sine kritiske regioner, og sikrer at man ikke for eksempel sælger en vare som lagervare hvis den i virkeligheden er udsoglt. Resource Arbitration Denne kategori omhandler scheduling, og der kan være fordele at hente ved at prioritere requests forskelligt, hvis krav til processeringstid ikke er proportional med den forventede processeringstid. Man kan for eksempel have et andet request end det i scenariet hvor den forventede processeringstid er lavere end det der er givet i scenariet, men kravet til processeringstiden af dette request er længere end de 10 sekunder fra scenariet; i dette tilfælde vil man kunne prioritere scenariets request højere, og på den måde tilfredsstille de ønskede krav. Availability tactics Der er ifølge [Bass et al. 2003] tre kategorier af availability taktikker: Fault detection Man kan gøre brug af alle tre taktikker fra [Bass et al., 2003] (ping/echo, heartbeat, exceptions) på følgende måde: Betalingsservicen kommunikerer med webserveren jævnligt; enten fordi den rent faktisk sender et heartbeat eller fordi den sender en log over aktivitet eller lignende, der så anvendes som heartbeat. Hvis webserveren opdager at der er gået for lang tid siden sidste heartbeat, kalder den en intern metode i webserverens fault detection system, der så sender et ping til servicen. Hvis servicen ikke returnerer et echo til det afsendte ping indenfor rimelig tid, kaster fault detection systemet en exception.

12 Fault recovery Den taktik der er lagt op til er at en administrator kontaktes og retter fejlen. Hvilket ikke har så meget med de taktikker der er angivet i [Bass et al., 2003] at gøre. Alle de taktikker der er angivet i [Bass et al., 2003] er forskellige grader af redundancy, på nær checkpoint/rollback. Checkpoint/rollback taktikken ville være meget passende til et betalingssystem, idet at hvis der går noget galt under en bataling, skal man sikrer sig at når betalingsservicen reintroduceres til systemet, så er der foretaget rollback til før eventuelle igangværende/ufærdige transaktioner. Fault prevention Der er i scenariet lag op til at anvende taktikken removal from service; hvis betalingsservicen går ned, kan man altså ikke fortaget et checkout af de varer man har tilføjet sin indkøbskurv, før betalingsservicen er reintroduceret, dette gøres for at undgå at yderligere fejl opstår i interaktionen med en defekt eller ikke-eksisterende betalingsservice. Taktikken transactions kan også anbefales, af samme grunde som checkpoint/rollback taktikken. Layered architectural style En layered architectural style medfører modifiability, idet et lag kun kommunikerer med det over-/under-liggende lag. Den modifiability taktik der bruges kaldes i [Bass et al., 2003] restrict communication paths. Desuden vil det i implementationen af den lagdelte arkitektur være oplagt at anvende flere modifiability taktikker som maintain semantic coherence, hide information, maintain existing interfaces og use an intermediary. Generelt set går en lagdelt arkitektur imod performance taktikken reduce computational overhead, da man ved at afgrænse kommunikationen vil komme til at forlænge den. Major elements in component and connector structure

13 Components og deres ansvar Database Persistent lagring af information omkring varer, for eksempel: antal, pris, URL til billede, beskrivelse Persistent lagring af ordrer Lagerstyring Varernes repræsentation på webserveren Holde styr på reserverede varer Opdatering af produktkataloger i tilfælde af reserverede eller solgte varer Opdatering af database i tilfælde af nye ordrer Produktkatalog Indkøbskurv Startpunkt for interaktion med brugeren Præsentation af de tilgængelige varer Udvælgelse af varer til indkøbskurv Holde styr på de varer kunden vil købe Præsentation af de varer kunden vil købe Fjerne varer fra indkøbskurv Betalingsservice Indsamle betalingsoplysninger Gennemføre betaling af ordre Annullere ordren hvis brugeren fortryder Connectors Når webserveren starter indhenter lagerstyringen information fra databasen via SQL query Et nyoprettet produktkatalog indhenter oplysninger omkring varer fra lagerstyring i XML Produktkataloget sender forespørgsler til lagerstyringen om at reservere en vare som kunden vil købe Lagerstyring er subject og produktkataloger er observer i et observer pattern, hvor der observeres på antalet af de enkelte varer Produktkataloget er producer og indkøbskurven er consumer af varer som kunden vil købe Produktkataloget og indkøbskurven kan overføre kontrol af brugergrænseflade til hinanden Indkøbskurven er subject og betalingssystemet er observer i et observer pattern, hvor der observeres på prisen af den aktuelle ordre Indkøbskurven og betalingssystemet kan overføre kontrol af brugergrænseflade til hinanden

14 Betalingsservice informerer indkøbskurven om at betalingen er gennemført Betalingsservice informerer indkøbskurven om at ordren er fortrudt Indkøbskurven er producer og produktkataloget er consumer af varer der er fortrudt Indkøbskurven er producer og produktkataloget er consumer af ordrer der er betalt Produktkataloget er producer og lagerstyringen er consumer af varer der er fortrudt Produktkataloget er producer og lagerstyringen er consumer af ordrer der er betalt Lagerstyringen sender databaseopdatering til databasen via SQL update Connector types Ved at brug connector types kan man opnå større modifiability, idet koden bliver delt op i mindre bider med semantic coherence. Prisen for denne modifiability er, som det ofte er tilfældet, performance på grund af computational overhead.

15 5 Architectural Prototyping Beer Web Store Types of architectural prototyping I [Christensen and Hansen, 2008] er architectural prototypes delt op i tre kategorier: Exploratory Denne type af prototyper er beregnet til at finde frem til forskellige arkitektoniske løsninger, da der allerede er fastsatte rammer (deployment strukturen) for arkitekturen er denne type mindre relevant, men kan stadig bruges til at udforske forskellige arkitektoniske valg indenfor de fastsatte rammer; for eksempel om man kan bruge et observer pattern til at holde browseren opdateret i tilfælde af ændringer så som en udsolgt vare. Experimental Denne type af prototyper er beregnet til at at måle og evaluere en arkitektur. Det ville være oplagt at anvende en experimental prototype til at vurdere om den angivne deployment arkitektur er fornuftig. Evolutionary En evolutionary prototype er en prototype som man iterativt modificerer, i håb om at forbedre den. Et prototype forløb kunne for eksempel være at have bygget exploratory prototyper, og kommet frem til en fornuftig arkitektur indenfor de rammer deployment strukturen angiver. Herefter har man udviklet en lidt tungere experimental prototype. Efter at have målt på denne og vurderet at arkitekturen lever op til de kvalitetsattributter der er stillet op har man iterativt videreudviklet denne experimental prototype via evolutionary prototyper, og kommet frem til en endelig arkitektur. Choosing programming language/framework Man kan bygge en ekperimental prototype i begge sprog og måle på prototypens kvalitetsattributter. Disse måldte kvalitetsattributter sammenholdes med de ønskede kvalitetsattributter for systemet, og ud udfra denne sammenholdning kan man så vælge programmeringssprog. Architectural prototype for testability I [Bass et al.] er der nævnt fire taktikker til testability: Record/playback Via en arkitektonisk prototype kan man undersøge muligheden for at bygge arkitekturen op så den understøtter at man kan optage den information der under kørsel bliver sendt fra en component over connector(s) til et andet component. Hvis man kan: Optage information der kommer som input til en komponent Optage den information der efterfølgende kommer som output Afspille optaget input til komponenten Så kan man skifte implementationen af en komponent ud, og sikre at den information der bliver optaget som output ikke er uhænsigtsmæssigt ændret siden det sidst optagede output.

16 Seperate interface from implementation Ved at lave en arkitektonisk prototype der helt konkret specificerer de interfacesc som implementationen skal opfylde sikrer man at man kan skifte implementationen af komponenter ud, og komponenten vil stadig kunne tale med andre komponenter, uden at skulle modificere disse. Dette gør også at man kan udskifte komponenter med stubløsninger, for at have fuld kontrol over komponentens handlinger. Specialize access routes/interfaces Specialized access routes/interfaces specificeres i den arkitektoniske prototype, så de ikke bliver glemt under implementationen. Build-in monitors Build-in monitors er ikke så egnet til at blive udforsket i en arkitektonisk prototype, da det handler om at aflæse tilstande internt i en komponent. Disse tilstande vil ofte ikke være til stede i de stub implementationer man benytter sig af i en arkitektonisk prototype. Benefits and liabilities of using ArchJava Benefits I ArchJava vil det være muligt at specificere opførelsen af connectors mere præcist, så man ved præcis hvilken type information der kan komme over en connector, or dermed sikre at alle disse typer kan testes jævnfør en eller flere af taktikkerne overnfor. I exploratory prototyping vil det være muligt at skifte connectors ud, for at afprøve hvilken effekt det har på de ønskede kvalitetsattributter; testability i denne case. Liabilities Der er ummiddelbart tre ulemper ved at bruge ArchJava: Det tager længere tid at udvikle Det medfører et computational overhead, og dermed performance tab og usikkerheder, hvilket medfører at man ikke kan regne med sine performance test. Hvis ikke implementationen skal være i ArchJava, skal de connectors der er specificeret i prototypens connectors oversættes til et andet programmeringssprog hvilket kan medføre nye fejlkilder.

17 Service-Oriented Architecture På slidesne fra forelæsningen om SOA er følgende guidelines for services beskrevet: Self-contained Service should have coarse-grained functionality Context-independence Service should not depend on other services Stateless Aka loose coupling Service should not retain client state between invocations Ved at benytte en service-oriented architecture opnår man et meget højt niveau af modifiability, idet man opfylder modifiability taktikker som maintain semantic coherence, generalize the module, hide information, maintain existing interfaces og ikke mindst runtime registration. Desuden vil det medfører at man kan samarbejde med andre webservices hvis det skulle være ønsket, også kaldet interoperability. Ulemper Som så ofte, er ulempen ved modifiability en risiko for at computational overhead bliver stort, hvilket vil medføre et performance tab.

18 6 Architectural Evaluation Beer Web Store Beskrivelse af ATAM-processen Architecture Tradeoff Analysis Method (ATAM), er et værktøj til at evaluere en arkitektur. Først og fremmest er ATAM et middel til at få indsigt i, hvorvidt den pågældende arkitektur opfylder forskellige kvalitetsmål, men den giver desuden et billede af, hvilke sammenhænge der er, disse kvaliteter imellem. Vi vil her antage, at læseren har kendskab til ATAM og blot opridse hvert trin i processen, som beskrevet i [Kazman et al., 2000]. På samme tid vil vi løbende forsøge at påpege, hvordan den kan benyttes til at evaluere Beer Web Store-systemet (BWS). Vi ved ikke meget om denne, men i og med at ATAM benyttes til at evaluere en arkitektur, bliver vi nødt til at antage, at der allerede eksisterer et forslag til én. Step 1 Present the ATAM Her klargøres selve metoden for alle de deltagende parter, ved en orientering fra de folk der leder processens afvikling, samt mulighed for at deltagerne kan stille spørgsmål. Dette indebærer både en præsentation af de ni forskellige trin i processen, en beskrivelse af de teknikker der benyttes (f.eks. utility tree generation), samt en beskrivelse af det forventede resultat af processen (f.eks. de tradeoffs, der identificeres). For Beer Web Store, kunne man forestille sig, at deltagerne ville bestå af en arkitekter (som typisk afvikler ATAM), projektledere, forretningsfolk, udviklere, driftstab og kommende kunder/brugere. Step 2 Present Business Drivers Målet med dette trin er at sikre, at alle deltagere har en ordentlig forståelse for det overordnede mål med systemet. Dette foregår igennem en beskrivelse, der foretages af projektlederen. Denne beskrivelse har en forretningsorienteret vinkel og kan blandt andet klargøre ting som; hvordan ser markedet ud, hvem er interessehavere i projektet, hvad er tidsbegrænsningerne, hvad er kundernes behov, hvad er budgettet, hvad er det tekniske fundament og begrænsninger, hvilke kvalitetsattributter skal der tages hensyn til og hvorfor. Her kunne projektlederen udover de ovennævnte ting f.eks. præsentere allerede eksisterende alternativer på markedet. Desuden ville de kvalitetsattributter der er nævnt i opgaveformuleringe, nemlig performance og modifiability, blive bragt på bane. Her ville main use case også blive fremlagt. Step 3 Present Architecture Her vil softwarearkitekten give en præsentation af arkitekturen. Denne er selvfølgelig direkte afhængig af, hvilke beslutninger der hidtil er taget om systemets arkitektur. Som en del af dette trin bidrager deltagerne desuden, ved at definere yderligere arkitektonisk information om systemet, som skal tages op til overvejelse i analysen. De dele af arkitekturen der dækkes, omfatter; tekniske begrænsninger helt ned til hardware-niveau, andre systemer som det pågældende system skal gøre brug af, samt de arkitektoniske tiltag der allerede er blevet overvejet til at imødekomme de opstillede kvalitetsmål. Vi ved ikke meget om arkitekturen for Beer Web Store, men i dette trin ville arkitekten præsentere sin deployment structure. Da web-serveren er en helt central komponent, ville det være naturligt, at diskutere den arkitektoniske struktur for denne og samspillet med de andre komponenter. Browser og database ville ikke kræve så meget tid, da de er temmelig veldefinerede, men man ville også diskutere valget af payment service man kunne forestille sig at dette ville være et eksternt system,

19 som BWS skal kommunikere med. Step 4 Identify Architectural Approaches Her identificeres de Architectural Approaches og Architectural Styles, der definerer de vigtige strukturer i systemet. Dette er vigtigt, fordi det er dem, der skal sikre at de krav og forventninger der er til systemet overholdes. For BWS-systemet ved vi som sagt ikke så meget konkret, men det ville f.eks. blive identificeret, at vi bruger client-server arkitektur og ikke eksempelvis en layered arkitektur. Step 5 Generate Quality Attribute Utility Tree I dette trin benytter man et Utility Tree til at finde ud af, hvilke kvalitetsattributter der ligger til grund for de væsentligste kvalitetsmål. Når de er blevet identificeret, prioriteres og forfines de og der genereres kvalitetsscenarier til at repræsentere de højest prioriterede. På denne måde indskrænkes antallet af områder, hvor resten af processen skal fokusere, til de vigtigste. Dette er essentielt, fordi det hjælper alle deltagerne til at opnå en form for konsensus, så de kan arbejde sammen, i stedet for at fokusere på deres personligt højest prioriterede områder. Dette handler altså udelukkende om at fastslå indsatsområder og ikke om at analysere systemet for at finde de arkitektoniske løsninger på problemstillingerne. Det utility tree der ville blive genereret her, ville give os nogle højt prioriterede scenarier, der ville afspejle de nævnte quality attributes, performance og modifiability. Ikke nødvendigvis de eneste, men vi ved fra opgaveformuleringen at de er vigtige, så man må antage, at i hvert fald nogle scenarier ville indfange disse. Step 6 Analyze Architectural Approaches Her benyttes kvalitetsscenarierne fra trin 5 til, igennem en dybdegående analyse, at finde frem til mulige Architectural Approaches og Styles for systemet. Resultatet er altid en liste af disse vigtige arkitektoniske beslutninger, men man sørger også for, på samme tid, at identificere en række risks (og non-risks), sensitivity points og tradeoff points. Samtidig sørger man for, på en struktureret måde, at dokumentere resultaterne igennem Architectural Approach Descriptions. Resultatet af dette vil blive præsenteret senere i afsnittet om Identificering af sensitivity points, tradeoff points og risks. Step 7 Brainstorm and Prioritize Scenarios I dette trin af ATAM-processen genereres der en række nye scenarier, igennem en brainstorming, foretaget af alle deltagere. Der søges to typer af scenarier, nemlig use case scenarios og change scenarios. Change scenarios kan opdeles i to kategorier; growth scenarios, som benyttes til at forudsige systemets styrker og svagheder i situationer hvor det udsættes for moderate ændringer, som f.eks. ændring af den underliggende platform, og exploratory scenarios, som benyttes til at beskrive situationer hvor systemet udsættes for drastiske ændringer, som f.eks. en omstrukturering af infrastrukturen. De forskellige scenarier prioriteres igennem en afstemning blandt deltagerne. For BWS ville man kunne finde begge typer af scenarier. Use case scenarier ville nok hovedsagligt beskæftige sig med brugerens oplevelse og have kvalitetsattributter som performance og (mindre arkitektonisk) usability i højsædet, mens change scenarier f.eks. kunne omhandle udvidelse af server delen, således at systemet ville kunne håndtere mange flere brugere, måske ved at lade flere servere dele arbejdet, i stedet for som deployment diagrammet antyder kun at have én.

20 Step 8 - Analyze Architectural Approaches Her foretages, i bedste fald, endnu en iteration af trin 6 og altså en knytning imellem hvert scenarie og en af de Architectural Approaches, som tidligere er blevet identificeret i systemet. Hvis det er tilfældet, at der ikke kan findes et arkitektonisk tiltag, som varetager det givne scenarie - hvilket betyder at vi i trin 7 har fundet et scenarie, som ingen af vores Architectural Approach Descriptions indfanger - så skal vi helt tilbage til trin 4 og gennemgå proceduren endnu en gang, indtil vi når til trin 8, uden at afsløre nogen problematiske brist i den samling af arkitektoniske tilgangsvinkler vi har samlet sammen. Her ville man, som sagt, i bedste fald ikke opdage noget nyt. Step 9 Present Results Her foretages en grundig rapportering af resultaterne fra hele processen. Identificering af sensitivity points, tradeoff points og risks Sensivity points Sensitivity points gør det klart, hvor der skal lægges særlig fokus, for at opnå et kvalitetsmål. Et eksempel kunne være, kommunikationen mellem serveren og de andre komponenter. Dette er et sensitivity point, der er væsentligt for at nå målet om modifiability og performance. At gøre det nemt at udvide (modify) systemet til at benytte mange servere, for at opnå bedre responstider (performance). Tradeoff points Et tradeoff point er et punkt, hvor man ved at varetage ét kvalitetsmål, tilsidesætter et andet. Lad os sige at man lavede en meget specifik implementering af kommunikationen mellem server og database, som er spredt rundt i hele server-implenteringen, med det mål at gøre kommunikationen hurtig, så tilgodeser man performance, men på samme tid tilsidesætter man modifiability, fordi det bliver meget sværere at skifte til en anden database. Havde man i stedet lavet et lag / interface imellem disse to komponenter, ville man situationen være omvendt. Fordele og svagheder ved ATAM i forbindelse med Beer Web Store Fordelen ved at bruge ATAM til at evaluere arkitekturen af Beer Web Store er begrænsede. ATAM er en langsommelig process, der kræver mange involverede, men kan til gengæld identificere nogle vigtige indsatsområder. Dog er BWS et forholdsvist simpelt system og måske ville tiden være givet bedre ud med andre evalueringsmetoder. At bruge DiscoTect til evaluering af Beer Web Store DiscoTect benyttes jo til at overvåge systemets runtime adfærd. I forbindelse med BWS-systemet, kunne man f.eks. benytte DiscoTect til at sikre, at tilgangen til databasen kun sker fra nogle bestemte software-komponenter i web-server-delen.

21 Sammenligning af ATAM og architectural prototyping ATAM er en mere teoretisk analyse, hvor man finder potentielle risici og beslutter hvilke arkitektoniske metoder, der er passende til det givne system. Derimod kan man med prototyping lave faktiske tests på systemet og finde ud af om der virkelig er tale om en risiko eller hvornår man når en grænse for hvad systemets arkitektur kan klare. Det idelle er kombinationen af de to metoder, hvor man først kunne lave en ATAM til at finde sensitivity points osv., for dernæst at lave prototypen til at teste dem. Når man tager Beer Web Store-systemets størrelse i betragtning, er det ikke sikkert at det vil være tiden og pengene værd at benytte en ATAM, men i stedet få nogle hurtige prototyper op i stedet. BWS er et forholdsvist simpelt system, der ideelt skal kunne håndtere mange brugere. Derfor ville de stress-tests som prototyping giver mulighed for være meget værdifulde.

Mandatory Project: Software Architecture of the TM12 System

Mandatory Project: Software Architecture of the TM12 System Mandatory Project: Software Architecture of the TM12 System Morten Mackenhauer og Kim Kokholm Department of Computer Science, University of Aarhus Aabogade 34, 8200 Å rhus N, Denmark 20108038, 20024448

Læs mere

Kapitel 21: Softwarearkitektur designprincipper

Kapitel 21: Softwarearkitektur designprincipper Kapitel 21: Softwarearkitektur designprincipper Miriam Tang Jacob Jensen Lars Christensen Jacob Atzen Onsdag 9/3 Dagens program Definitioner Analyseværktøjer Designprocessen Raffinering Afrunding Design

Læs mere

System Arkitekt Practitioner

System Arkitekt Practitioner System Arkitekt Practitioner Kompetencebeskrivelsee DISAC Danish IT Society s Architectural Certification DANSK IT 2012 1 IT arkitekt Practitioner System Arkitekt Denne certificering repræsenterer det

Læs mere

SOFTWARE PROCESSES. Dorte, Ida, Janne, Nikolaj, Alexander og Erla

SOFTWARE PROCESSES. Dorte, Ida, Janne, Nikolaj, Alexander og Erla SOFTWARE PROCESSES Dorte, Ida, Janne, Nikolaj, Alexander og Erla Hvad er en software proces? Et struktureret sæt af AKTIVITETER, hvis mål er udvikling af software. En software proces model er en abstrakt

Læs mere

Byg din informationsarkitektur ud fra en velafprøvet forståelsesramme The Open Group Architecture Framework (TOGAF)

Byg din informationsarkitektur ud fra en velafprøvet forståelsesramme The Open Group Architecture Framework (TOGAF) Byg din informationsarkitektur ud fra en velafprøvet forståelsesramme The Open Group Framework (TOGAF) Otto Madsen Director of Enterprise Agenda TOGAF og informationsarkitektur på 30 min 1. Introduktion

Læs mere

Hand in H5. Software Architecture in Practice. Architecture design methods. Architecture design decisions

Hand in H5. Software Architecture in Practice. Architecture design methods. Architecture design decisions Hand in H5 Software Architecture in Practice Architecture design methods Architecture design decisions Department of Computer Science, University of Aarhus Aabogade 34, 8200 Århus N, Denmark Gruppe: Bravo

Læs mere

Software Design (SWD) Spørgsmål 1

Software Design (SWD) Spørgsmål 1 Spørgsmål 1 Unified Process Du skal give en beskrivelse af Unified Process. Beskrivelsen skal indeholde forklaring på følgende begreber: Phase Iteration Discipline Artifact Milestone Du skal relaterer

Læs mere

Reliable Architecture Ved Henrik Bærbak Christensen. Emne: Kritiske systemer Overvågning og kontrol system for et kemisk produktions anlæg CP09

Reliable Architecture Ved Henrik Bærbak Christensen. Emne: Kritiske systemer Overvågning og kontrol system for et kemisk produktions anlæg CP09 Reliable Architecture Ved Henrik Bærbak Christensen Emne: Kritiske systemer Overvågning og kontrol system for et kemisk produktions anlæg CP09 03. december, 2009 Gruppe 5 Thomas Mollerup Lanng, 20070583

Læs mere

OpenTele3. Michael Christensen! Chef Softwarearkitekt, Alexandra Instituttet,! Koordinator for Softwaregruppen i 4S!

OpenTele3. Michael Christensen! Chef Softwarearkitekt, Alexandra Instituttet,! Koordinator for Softwaregruppen i 4S! 4S OpenTele3 Michael Christensen! Chef Softwarearkitekt, Alexandra Instituttet,! Koordinator for Softwaregruppen i 4S! Vision Muliggøre udvikling af! bedre og mere effektive løsninger! til brugerne!! via!!

Læs mere

Hassansalem.dk/delpin User: admin Pass: admin BACKEND

Hassansalem.dk/delpin User: admin Pass: admin BACKEND Hassansalem.dk/delpin User: admin Pass: admin BACKEND 1/10 Indledning Dette projekt er den afsluttende del af web udvikling studiet på Erhvervs Lillebælt 1. semester. Projektet er udarbejdet med Del-pin

Læs mere

Sikkerhed & Revision 2013

Sikkerhed & Revision 2013 Sikkerhed & Revision 2013 Samarbejde mellem intern revisor og ekstern revisor - og ISA 610 v/ Dorthe Tolborg Regional Chief Auditor, Codan Group og formand for IIA DK RSA REPRESENTATION WORLD WIDE 300

Læs mere

Software Design (SWD) Spørgsmål 1

Software Design (SWD) Spørgsmål 1 Spørgsmål 1 Unified Process Du skal give en beskrivelse af Unified Process. Beskrivelsen skal indeholde forklaring på følgende begreber: Phase Iteration Discipline Activity Milestone Artifact Spørgsmål

Læs mere

Hand in H6. Software Architecture in Practice. Book Swap Case

Hand in H6. Software Architecture in Practice. Book Swap Case Hand in H6 Software Architecture in Practice Book Swap Case Department of Computer Science, University of Aarhus Aabogade 34, 8200 Århus N, Denmark Gruppe: Bravo 20074842, Lars Kringelbach, lars@kringelbach.com

Læs mere

WINDCHILL THE NEXT STEPS

WINDCHILL THE NEXT STEPS WINDCHILL THE NEXT STEPS PTC/user, 4. marts 2015 Jens Christian Jensen, Econocap Agenda Windchill the next steps Bliv opdateret og inspireret til at se hvor Windchill kan hjælpe dig med andet end blot

Læs mere

Seminar d. 19.9.2013. Klik for at redigere forfatter

Seminar d. 19.9.2013. Klik for at redigere forfatter Seminar d. 19.9.2013 Klik for at redigere forfatter M_o_R En risiko er en usikker begivenhed, der, hvis den indtræffer, påvirker en målsætning Risici kan dele op i to typer Trusler: Der påvirker målsætningen

Læs mere

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB

KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB KURSER INDENFOR SOA, WEB SERVICES OG SEMANTIC WEB Det er Web Services, der rejser sig fra støvet efter Dot Com boblens brag. INTRODUKTION Dette dokument beskriver forslag til fire moduler, hvis formål

Læs mere

Succesfuld implementering af automatiseret test

Succesfuld implementering af automatiseret test Succesfuld implementering af automatiseret test Forudsætningerne og faldgruberne John Fodeh john.fodeh@hp.com 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject

Læs mere

Indholdsfortegnelse for kapitel 1

Indholdsfortegnelse for kapitel 1 Indholdsfortegnelse for kapitel 1 Forord.................................................................... 2 Kapitel 1.................................................................. 3 Formål............................................................

Læs mere

PROJECT PORTFOLIO MANAGEMENT ARTEMIS 7

PROJECT PORTFOLIO MANAGEMENT ARTEMIS 7 PROJECT PORTFOLIO MANAGEMENT ARTEMIS 7 Udfordringen Udfordringerne skabt af den globale økonomiske situation, kræver ansvarlighed for og overblik over investeringer som aldrig før. IT styring, investeringsplanlægning

Læs mere

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0

SmartFraming Et vindue til nationale sundhedssystemer. Version 3.0 SmartFraming Et vindue til nationale sundhedssystemer Version 3.0 Infrastruktur i dagens sundheds IT Det sundhedsfaglige personale benytter sig i dag af en række forskellige systemer i forbindelse med

Læs mere

Sikkerhedsanbefaling. Forholdsregler ved ophør af serviceopdateringer til Windows XP Embedded

Sikkerhedsanbefaling. Forholdsregler ved ophør af serviceopdateringer til Windows XP Embedded Sikkerhedsanbefaling Forholdsregler ved ophør af serviceopdateringer til Windows XP Embedded Juli 2014 Indledning Microsoft har annonceret, at selskabet den 31. december 2016 frigiver den sidste serviceopdatering

Læs mere

Dagens program. Domæner. change log- screen shots hver gang I har arbejdet med themet. Arkitekturen bag en wp blog. Hvad er widgets.

Dagens program. Domæner. change log- screen shots hver gang I har arbejdet med themet. Arkitekturen bag en wp blog. Hvad er widgets. Dagens program Har alle fået? Har nogen betalt for meget? Hav jeres koder klar Domæner change log- screen shots hver gang I har arbejdet med themet. Arkitekturen bag en wp blog Hvad er widgets Hvad er

Læs mere

OpenTele Server Performance Test Rapport

OpenTele Server Performance Test Rapport OpenTele Server Performance Test Rapport 17. marts 2015 Side 1 af 22 1Indholdsfortegnelse Indholdsfortegnelse Indledning Test forudsætning Beskrivelse af testscenarier Test af OpenTele kliniker web interface

Læs mere

Database for udviklere. Jan Lund Madsen PBS10107

Database for udviklere. Jan Lund Madsen PBS10107 Database for udviklere Jan Lund Madsen PBS10107 Indhold LINQ... 3 LINQ to SQL og Arkitektur... 3 O/R designere... 5 LINQ Den store introduktion med.net 3.5 er uden tvivl LINQ(udtales link): Language-INtegrated

Læs mere

DE BEAR TECHNOLOGY. o Processer, metoder & værktøjer. e-mail: info@dbtechnology.dk WWW.DBTECHNOLOGY.DK

DE BEAR TECHNOLOGY. o Processer, metoder & værktøjer. e-mail: info@dbtechnology.dk WWW.DBTECHNOLOGY.DK Mission Critical o Projekt Information management o Processer, metoder & værktøjer. Side 1 of 11 Projekt information Projekt information management inkluderer alle de processer, som er nødvendige for at

Læs mere

SPØRGSMÅL TIL UDBUD AF SYSTEMUNDERSTØTTELSE AF GEODANMARK PRÆKVALIFIKATIONSFASEN

SPØRGSMÅL TIL UDBUD AF SYSTEMUNDERSTØTTELSE AF GEODANMARK PRÆKVALIFIKATIONSFASEN SPØRGSMÅL TIL UDBUD AF SYSTEMUNDERSTØTTELSE AF GEODANMARK PRÆKVALIFIKATIONSFASEN EU-UDBUD NR. 2016/S 089-156404 (Version 5 af 1. juni 2016) Page 1 of 6 1 ESPD, Teknisk og faglig formåen I ESPD punkt IV,

Læs mere

Lovkrav vs. udvikling af sundhedsapps

Lovkrav vs. udvikling af sundhedsapps Lovkrav vs. udvikling af sundhedsapps Health apps give patients better control User Data Social media Pharma Products User behaviour Relatives www Self monitoring (app) data extract Healthcare specialists

Læs mere

EA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning:

EA3 eller EA Cube rammeværktøjet fremstilles visuelt som en 3-dimensionel terning: Introduktion til EA3 Mit navn er Marc de Oliveira. Jeg er systemanalytiker og datalog fra Københavns Universitet og denne artikel hører til min artikelserie, Forsimpling (som også er et podcast), hvor

Læs mere

2 Moduler Tilbud på betalingsmodul til Facecv.dk

2 Moduler Tilbud på betalingsmodul til Facecv.dk 2 Moduler Tilbud på betalingsmodul til Facecv.dk 1 Overblik Et eksisterende Codec9 baseret websted skal udvides til at understøtte dankortbetaling via en betalingsgateway. Webstedet er i opstartsfasen,

Læs mere

Da beskrivelserne i danzig Profile Specification ikke er fuldt færdige, foreslås:

Da beskrivelserne i danzig Profile Specification ikke er fuldt færdige, foreslås: NOTAT 6. juni 2007 J.nr.: 331-3 LEA Bilag A danzig-møde 15.6.2007 Opdatering af DAN-1 og danzig Profile Specification Forslag til opdatering af Z39.50 specifikationerne efter udgivelse af Praksisregler

Læs mere

Modul 2 Database projekt Multimediedesign 3. semester Gruppe 3 IRF/TUJE

Modul 2 Database projekt Multimediedesign 3. semester Gruppe 3 IRF/TUJE Modul 2 Database projekt Multimediedesign 3. semester Gruppe 3 IRF/TUJE Fact sheet Indholdsfortegnelse Fact Sheet Gantt kort Valgt af virksomhed Brainstorm Attribut tabel ER-diagram Skitse MySQLWorkbench

Læs mere

Data Warehouse Knowledge is Power - Sir Francis Bacon -

Data Warehouse Knowledge is Power - Sir Francis Bacon - Data Warehouse 4. sem. datamatiker uddannelse Tietgen Skolen Odense Skrevet af Troels Markvard Andersen (DM08228) Knowledge is Power - Sir Francis Bacon - Troels Markvard Andersen Side 1 af 8 Forord /

Læs mere

Enterprise Strategy Program

Enterprise Strategy Program Enterprise Strategy Program Putting Business Before Technology Anders Bonde Enterprise Strategy Lead, Microsoft Services Denmark Er Enterprise Strategy noget for dig? Det ultimative spørgsmål... Måske

Læs mere

CASE: Royal Copenhagen

CASE: Royal Copenhagen When Your Website Goes Shopping CASE: Royal Copenhagen v/mads Gustafsen & Line Ghisler, Creuna Sitecoreseminar 6. februar 2008 CASE Royal Copenhagen præsenteret af Creuna Royal Copenhagen Kongelig Hofleverandør

Læs mere

Hvor er mine runde hjørner?

Hvor er mine runde hjørner? Hvor er mine runde hjørner? Ofte møder vi fortvivlelse blandt kunder, når de ser deres nye flotte site i deres browser og indser, at det ser anderledes ud, i forhold til det design, de godkendte i starten

Læs mere

HACKERNE BLIVER BEDRE, SYSTEMERNE BLIVER MERE KOMPLEKSE OG PLATFORMENE FORSVINDER HAR VI TABT KAMPEN? MARTIN POVELSEN - KMD

HACKERNE BLIVER BEDRE, SYSTEMERNE BLIVER MERE KOMPLEKSE OG PLATFORMENE FORSVINDER HAR VI TABT KAMPEN? MARTIN POVELSEN - KMD HACKERNE BLIVER BEDRE, SYSTEMERNE BLIVER MERE KOMPLEKSE OG PLATFORMENE FORSVINDER HAR VI TABT KAMPEN? MARTIN POVELSEN - KMD HVILKEN BIL VIL DU HELST KØRE GALT I? Bemærk at brug og antal Bemærk at brug

Læs mere

Security as a Service hvorfor, hvornår og hvordan. Gorm Mandsberg, gma@dubex.dk Aarhus, 13.06.2013

Security as a Service hvorfor, hvornår og hvordan. Gorm Mandsberg, gma@dubex.dk Aarhus, 13.06.2013 Security as a Service hvorfor, hvornår og hvordan Gorm Mandsberg, gma@dubex.dk Aarhus, 13.06.2013 SecaaS hvorfor, hvornår og hvordan hvad Hvorfor.. Hvornår.. Hvordan.. Disclamer: Dubex er MSSP og leverer

Læs mere

Design til digitale kommunikationsplatforme-f2013

Design til digitale kommunikationsplatforme-f2013 E-travellbook Design til digitale kommunikationsplatforme-f2013 ITU 22.05.2013 Dreamers Lana Grunwald - svetlana.grunwald@gmail.com Iya Murash-Millo - iyam@itu.dk Hiwa Mansurbeg - hiwm@itu.dk Jørgen K.

Læs mere

It-sikkerhedstekst ST9

It-sikkerhedstekst ST9 It-sikkerhedstekst ST9 Single Sign-On og log-ud Denne tekst må kopieres i sin helhed med kildeangivelse. Dokumentnavn: ST9 Version 1 Juli 2015 Single Sign-On og log-ud Betegnelsen Single Sign-On (SSO)

Læs mere

IT projekt. sæt et mål og nå det med omtanke!

IT projekt. sæt et mål og nå det med omtanke! IT projekt sæt et mål og nå det med omtanke! Det overordnede FORMÅL med dias-showet er at fortælle hvordan vi gennemfører IT projekter med succes ved hjælp af Microsoft Solutions Framework MSF modeller:

Læs mere

EG Data Inform. Byggebasen. WCF og webservices. Jens Karsø

EG Data Inform. Byggebasen. WCF og webservices. Jens Karsø EG Data Inform Byggebasen WCF og webservices Jens Karsø 10 Indholdsfortegnelse Byggebasen Services indledning... 2 Målsætning... 2 Valg af teknologier... 3 Kommunikationsmodel for byggebasen... 3 Services.byggebasen.dk...

Læs mere

Opgrader til nyeste Dynamics AX version og profiter af løbende opdateringer

Opgrader til nyeste Dynamics AX version og profiter af løbende opdateringer INDLÆG 13 : DYNAMICS AX Opgrader til nyeste Dynamics AX version og profiter af løbende opdateringer Tonny Bybæk, Lau Bøgelund Larsen Opgrader til nyeste Dynamics AX version og profiter af løbende opdateringer

Læs mere

Projektledelse i praksis

Projektledelse i praksis Projektledelse i praksis - Hvordan skaber man (grundlaget) for gode beslutninger? Martin Malis Business Consulting, NNIT mtmi@nnit.com 20. maj, 2010 Agenda Project Governance Portfolio Management Project

Læs mere

DATABASE - MIN MUSIKSAMLING

DATABASE - MIN MUSIKSAMLING DATABASE - MIN MUSIKSAMLING I dette forløb skulle vi lære om databaser, som bruger sproget SQL. SQL står for Structured Query Language. Det bruges til at vise og manipulere data, gemt i en database. I

Læs mere

Managing stakeholders on major projects. - Learnings from Odense Letbane. Benthe Vestergård Communication director Odense Letbane P/S

Managing stakeholders on major projects. - Learnings from Odense Letbane. Benthe Vestergård Communication director Odense Letbane P/S Managing stakeholders on major projects - Learnings from Odense Letbane Benthe Vestergård Communication director Odense Letbane P/S Light Rail Day, Bergen 15 November 2016 Slide om Odense Nedenstående

Læs mere

Shooting tethered med Canon EOS-D i Capture One Pro. Shooting tethered i Capture One Pro 6.4 & 7.0 på MAC OS-X 10.7.5 & 10.8

Shooting tethered med Canon EOS-D i Capture One Pro. Shooting tethered i Capture One Pro 6.4 & 7.0 på MAC OS-X 10.7.5 & 10.8 Shooting tethered med Canon EOS-D i Capture One Pro Shooting tethered i Capture One Pro 6.4 & 7.0 på MAC OS-X 10.7.5 & 10.8 For Canon EOS-D ejere der fotograferer Shooting tethered med EOS-Utility eller

Læs mere

Anvendelse af BPT til manuel test

Anvendelse af BPT til manuel test DIAS 1 Konference HP Test brugergruppen Anvendelse af BPT til manuel test Agenda DIAS 2 _ Præsentation af mig selv _Manuel BPT _ Manuel BPT i KMD _Konklusion _ Diskussion og spørgsmål Præsentation DIAS

Læs mere

PS102: Den menneskelige faktor og patientsikkerhed

PS102: Den menneskelige faktor og patientsikkerhed IHI Open School www.ihi.org/patientsikkerhed PS102: Den menneskelige faktor og patientsikkerhed (1 time) Dette modul er en introduktion til emnet "menneskelige faktorer": Hvordan indarbejdes viden om menneskelig

Læs mere

Bilag 2 og 3 og værktøjer

Bilag 2 og 3 og værktøjer Bilag 2 og 3 og værktøjer Lars Erik Storgaard Geodatastyrelsen, laers@gst.dk Program for workshop Geodatastyrelsen Formål hvorfor workshop? Kvalificering af listen over myndigheder Temakammerater Opmærksomhed

Læs mere

APPLIKATIONSARKITEKTUR ERP INFRASTRUKTUR. EG Copyright

APPLIKATIONSARKITEKTUR ERP INFRASTRUKTUR. EG Copyright APPLIKATIONSARKITEKTUR ERP INFRASTRUKTUR EG Copyright Infrastruktur er mere end nogle servere... Den Mentale Infrastruktur Den Fysiske Infrastruktur Den Mentale Infrastruktur Vi vil jo gerne have vores

Læs mere

STS Designdokument. STS Designdokument

STS Designdokument. STS Designdokument STS Designdokument i STS Designdokument STS Designdokument ii REVISION HISTORY NUMBER DATE DESCRIPTION NAME 0.3 2013-01 N STS Designdokument iii Indhold 1 Introduktion 1 2 Arkitekturoverblik 1 2.1 Eksterne

Læs mere

Hassansalem.dk/delpin User: admin Pass: admin INTERFACE DESIGN

Hassansalem.dk/delpin User: admin Pass: admin INTERFACE DESIGN Hassansalem.dk/delpin User: admin Pass: admin INTERFACE DESIGN 1/20 Indledning Dette projekt er den afsluttende del af webudvikling-studiet på Erhvervs Lillebælt 1. semester. Projektet er udarbejdet med

Læs mere

Undervisningsplan. Side 1 af 17. Termin Rybners Tekniske Gymnasium. Uddannelse. Fag og niveau. Informationsteknologi B

Undervisningsplan. Side 1 af 17. Termin Rybners Tekniske Gymnasium. Uddannelse. Fag og niveau. Informationsteknologi B Undervisningsplan Termin 2014-2016 Institution Uddannelse Fag og niveau Lærer(e) Hold Rybners Tekniske Gymnasium HTX Informationsteknologi B Jeppe Moritz Led, Jens Ahlmann Hansen E13 Oversigt over undervisningsforløb

Læs mere

Udfordringer og problemstillinger. En liste over de udfordringer og problemstillinger, der er ved Java og JEE udvikling

Udfordringer og problemstillinger. En liste over de udfordringer og problemstillinger, der er ved Java og JEE udvikling Java og JEE 1 2 Udfordringer og problemstillinger En liste over de udfordringer og problemstillinger, der er ved Java og JEE udvikling 3 Generelt om Java og JEE 4 Generelt, I Man undervurderer hvor mange

Læs mere

OPC ACCESS HEARTBEAT 1

OPC ACCESS HEARTBEAT 1 OPC Access Heartbeat Dette dokument gennemgår i et kort eksempel, hvordan OPC Access konfigureres til at anvende Heartbeat funktionen til at dokumentere kontinuerlig forbindelse mellem SQL Server og OPC

Læs mere

Design by Contract. Design and Programming by Contract. Oversigt. Prædikater

Design by Contract. Design and Programming by Contract. Oversigt. Prædikater Design by Contract Design and Programming by Contract Anne Haxthausen ah@imm.dtu.dk Informatics and Mathematical Modelling Technical University of Denmark Design by Contract er en teknik til at specificere

Læs mere

Skabeloner for forretningsmodellering

Skabeloner for forretningsmodellering Skabeloner for forretningsmodellering En kreativ proces for generering af forretningsmodeller Søren Eskildsen, Forretningsudvikler, Alexandra Instituttet A/S Hvad er en forretningsmodel? En beskrivelse

Læs mere

Database "opbygning"

Database opbygning Database "opbygning" Dette områder falder mest under en DBA's ansvarsområde. Det kan sagtens tænkes at en database udvikler i nogle situationer vil blive nød til at oprette produktions og test) databaser,

Læs mere

OIOREST webservice design. Guideline til design af REST-baserede webservices. Udgivet af: IT- & Telestyrelsen

OIOREST webservice design. Guideline til design af REST-baserede webservices. Udgivet af: IT- & Telestyrelsen > OIOREST webservice design. Guideline til design af REST-baserede webservices. Udgivet af: IT- & Telestyrelsen Publikationen kan også hentes på IT- & Telestyrelsens Hjemmeside: http://www.itst.dk ISBN

Læs mere

Availability og reliability i softwarearkitektur

Availability og reliability i softwarearkitektur Availability og reliability i softwarearkitektur Gruppe 2 Jørgen Vrou Hansen 20042728 Marjus Nielsen 20064684 Said Shah Alizadeh 19963592 19. marts 2010 Abstract Dette papir omhandler arkitektoniske discipliner

Læs mere

Load Test. Projektet afgår om få minutter fra SPOR 3

Load Test. Projektet afgår om få minutter fra SPOR 3 Load Test Projektet afgår om få minutter fra SPOR 3 Vision Testforberedelse Testens troværdighed afhænger meget nøje af den overensstemmelse der er mellem testen og virkeligheden, eller sagt på en anden

Læs mere

Usability-arbejde i virksomheder

Usability-arbejde i virksomheder Usability-arbejde i virksomheder Jan Stage Professor, PhD Forskningsleder i Information Systems (IS) og Human-Computer Interaction (HCI) Aalborg University, Department of Computer Science jans@cs.aau.dk

Læs mere

Dell Cloud Client Computing Hvordan virtualisere vi de tunge grafisk applikationer?

Dell Cloud Client Computing Hvordan virtualisere vi de tunge grafisk applikationer? Dell Cloud Client Computing Hvordan virtualisere vi de tunge grafisk applikationer? Christian Eilskov Sales Engineer, christian_eilskov@dell.com +45 40 60 13 92 Dell Cloud Client Computing Dell lever produkter

Læs mere

Samspillet mellem databaser og kort styres af GeoCAD programmet GeoDB.

Samspillet mellem databaser og kort styres af GeoCAD programmet GeoDB. GeoCad modul GeoDB I GeoCAD er det muligt at koble relationsdatabase til GeoEDIT. Her igennem er det muligt at lagre forskellige oplysninger i databasen og koble disse oplysninger til objekter i kortet.

Læs mere

DM531 - Softwarearkitektur Projekt - TaxaTracer, Statisk Kort. Martin Dissing-Hansen 251088 Alexander Poopeiko 090288 Jens Riise Danielsen 100267

DM531 - Softwarearkitektur Projekt - TaxaTracer, Statisk Kort. Martin Dissing-Hansen 251088 Alexander Poopeiko 090288 Jens Riise Danielsen 100267 DM531 - Softwarearkitektur Projekt - TaxaTracer, Statisk Kort Martin Dissing-Hansen 251088 Alexander Poopeiko 090288 Jens Riise Danielsen 100267 December 17, 2009 3.1 Valg at brugsmønster til udvidelse

Læs mere

GUIDE TIL BREVSKRIVNING

GUIDE TIL BREVSKRIVNING GUIDE TIL BREVSKRIVNING APPELBREVE Formålet med at skrive et appelbrev er at få modtageren til at overholde menneskerettighederne. Det er en god idé at lægge vægt på modtagerens forpligtelser over for

Læs mere

PERFORMANCE DokumentBrokeren

PERFORMANCE DokumentBrokeren PERFORMANCE DokumentBrokeren Copyright 2012 INDHOLDSFORTEGNELSE 1 Målinger og analyse...1 1.1 Kørsler på Amazon-serveren...1 1.1.1 PDF...1 1.1.2 ODF...2 1.2 Kørsler på PC med 2 kerner og 12 GB RAM...2

Læs mere

Tietgenskolen - Nørrehus. Data warehouse. Database for udviklere. Thor Harloff Lynggaard DM08125

Tietgenskolen - Nørrehus. Data warehouse. Database for udviklere. Thor Harloff Lynggaard DM08125 Tietgenskolen - Nørrehus Data warehouse Database for udviklere Thor Harloff Lynggaard DM08125 Juni 2010 Indhold Beskrivelse... 3 Data warehouse... 3 Generelt... 3 Sammenligning... 3 Gode sider ved DW...

Læs mere

Projekt DATA step view

Projekt DATA step view Projekt DATA step view Af Louise Beuchert Formål Formålet med dette projekt, er at sammenligne tid/ressourcekonsekvenser ved at køre SASjobs på data hentet som henholdsvis en fysisk kopi af data filen

Læs mere

FRA USECASE TIL TESTCASE HP TEST BRUGERKONFERENCE, 10. APRIL 2014

FRA USECASE TIL TESTCASE HP TEST BRUGERKONFERENCE, 10. APRIL 2014 FRA USECASE TIL TESTCASE HP TEST BRUGERKONFERENCE, 10. APRIL 2014 LIDT OM MIG SELV Erfaring NIELS-HENRIK HANSEN 35+ års samlet IT erfaring 15+ år som test manager Certificeret Inspection Leader ISEB Foundation

Læs mere

Modul 5. Practice. PositivitiES. On-line-kursus. Engagement og mening. Applied Positive Psychology for European Schools

Modul 5. Practice. PositivitiES. On-line-kursus. Engagement og mening. Applied Positive Psychology for European Schools PositivitiES Applied Positive Psychology for European Schools ES Positive European Schools On-line-kursus Modul 5 Practice Engagement og mening This project has been funded with support from the European

Læs mere

Hovedopgave MASTER I INFORMATIONSTEKNOLOGI LINIEN I SOFTWAREKONSTRUKTION

Hovedopgave MASTER I INFORMATIONSTEKNOLOGI LINIEN I SOFTWAREKONSTRUKTION DATALOGISK INSTITUT DET NATURVIDENSKABELIGE FAKULTET AARHUS UNIVERSITET Hovedopgave MASTER I INFORMATIONSTEKNOLOGI LINIEN I SOFTWAREKONSTRUKTION Evaluering af udbud og modenhed af cloud computing software

Læs mere

Assignment #5 Toolbox Contract

Assignment #5 Toolbox Contract Assignment #5 Toolbox Contract Created by: René Kragh Trine Randløv E mail address cph rk70@cphbusiness.dk 23 11 2014 1 Introduktion Dette dokument indeholder en vertikal kontrakt for et system som skal

Læs mere

Software Design (SWD) Spørgsmål 1

Software Design (SWD) Spørgsmål 1 Spørgsmål 1 Unified Process Du skal give en beskrivelse af Unified Process. Beskrivelsen skal indeholde forklaring på følgende begreber: Phase Iteration Discipline Activity Milestone Artifact Spørgsmål

Læs mere

Tidsregistrering. Jacob E., Jacob H., Mathias, Mads H., Jonatan og Dan 3.4. Informationsteknologi B. Roskilde Tekniske Gymnasium 25-11-2014

Tidsregistrering. Jacob E., Jacob H., Mathias, Mads H., Jonatan og Dan 3.4. Informationsteknologi B. Roskilde Tekniske Gymnasium 25-11-2014 2014 Tidsregistrering Jacob E., Jacob H., Mathias, Mads H., Jonatan og Dan 3.4 Informationsteknologi B Roskilde Tekniske Gymnasium 25-11-2014 Indholdsfortegnelse 1 Indledning... 3 2 User stories... 3 3

Læs mere

Citrix CSP og Certificate Store Provider

Citrix CSP og Certificate Store Provider Project Name Document Title TDC Citrix Citrix og Certificate Store Provider Version Number 1.0 Status Release Author jkj Date 5-10-2006 Trademarks All brand names and product names are trademarks or registered

Læs mere

BibDok. Guide til BibDok. En metode til at dokumentere effekt af bibliotekets indsatser

BibDok. Guide til BibDok. En metode til at dokumentere effekt af bibliotekets indsatser BibDok En til at dokumentere effekt af bibliotekets er Guide til BibDok BibDok understøtter en systematisk refleksiv praksis. Det er derfor væsentligt, at I følger guiden trin for trin. 1. Sammenhæng mellem

Læs mere

Engelsk. Niveau C. De Merkantile Erhvervsuddannelser September 2005. Casebaseret eksamen. www.jysk.dk og www.jysk.com.

Engelsk. Niveau C. De Merkantile Erhvervsuddannelser September 2005. Casebaseret eksamen. www.jysk.dk og www.jysk.com. 052430_EngelskC 08/09/05 13:29 Side 1 De Merkantile Erhvervsuddannelser September 2005 Side 1 af 4 sider Casebaseret eksamen Engelsk Niveau C www.jysk.dk og www.jysk.com Indhold: Opgave 1 Presentation

Læs mere

Digital Kommuneplan. Kravsspecifikation gennem brugerinvolvering

Digital Kommuneplan. Kravsspecifikation gennem brugerinvolvering Digital Kommuneplan Kravsspecifikation gennem brugerinvolvering Indhold Introduktion Afklaring af behov: Hvad skal digitale kommuneplaner kunne? Udarbejdelse og test af løsning: Hvordan skal digitale kommuneplaner

Læs mere

PHP Quick Teknisk Ordbog

PHP Quick Teknisk Ordbog PHP Quick Teknisk Ordbog Af Daniel Pedersen PHP Quick Teknisk Ordbog 1 Indhold De mest brugte tekniske udtryk benyttet inden for web udvikling. Du vil kunne slå de enkelte ord op og læse om hvad de betyder,

Læs mere

Undervisningsbeskrivelse

Undervisningsbeskrivelse Undervisningsbeskrivelse Termin 2013-2015 Institution Rybners Tekniske Gymnasium Uddannelse Fag og niveau Lærer(e) HTX Informationsteknologi B Jeppe Moritz Led Hold 3.E, Årgang 2012 Oversigt over undervisningsforløb

Læs mere

Hvem er vi? Kursus Introduktion. Kursuslærerne. Agenda for i dag

Hvem er vi? Kursus Introduktion. Kursuslærerne. Agenda for i dag Hvem er vi? Kursus Introduktion Anne Haxthausen ah@imm.dtu.dk Informatics and Mathematical Modelling Technical University of Denmark 100 studerende med forskellig baggrund: software teknologi It og Kom

Læs mere

Møder til glæde og gavn i Vesthimmerlands Kommune

Møder til glæde og gavn i Vesthimmerlands Kommune Møder til glæde og gavn i Vesthimmerlands Kommune Møder til glæde og gavn? Møder, møder, møder Du kan sikkert nikke genkendende til, at en betragtelig del af din arbejdstid bruges på forskellige møder.

Læs mere

Skriftlig Eksamen Kombinatorik, Sandsynlighed og Randomiserede Algoritmer (DM528)

Skriftlig Eksamen Kombinatorik, Sandsynlighed og Randomiserede Algoritmer (DM528) Skriftlig Eksamen Kombinatorik, Sandsynlighed og Randomiserede Algoritmer (DM58) Institut for Matematik og Datalogi Syddansk Universitet, Odense Torsdag den 1. januar 01 kl. 9 13 Alle sædvanlige hjælpemidler

Læs mere

Bedømmelse af klinisk retningslinje foretaget af Enhed for Sygeplejeforskning og Evidensbasering Titel (forfatter)

Bedømmelse af klinisk retningslinje foretaget af Enhed for Sygeplejeforskning og Evidensbasering Titel (forfatter) Bedømmelse af klinisk retningslinje foretaget af Enhed for Sygeplejeforskning og Evidensbasering Titel (forfatter) Link til retningslinjen Resumé Formål Fagmålgruppe Anbefalinger Patientmålgruppe Implementering

Læs mere

Standardiseret tilgang til Software Asset Management. ISACA Medlemsmøde 2013 Jan Øberg ØBERG Partners

Standardiseret tilgang til Software Asset Management. ISACA Medlemsmøde 2013 Jan Øberg ØBERG Partners Standardiseret tilgang til Software Asset Management ISO19770 ISACA Medlemsmøde 2013 Jan Øberg ØBERG Partners 1 WG21 historien ISO19770 arbejder i WG21 under ISO Etableret i 2001 Første standard 19770-1

Læs mere

DESIGN TIL DIGITALE KOMMUNIKATIONSPLATFORME. 10. Oktober 2013 #6 Designproces + Projektstart

DESIGN TIL DIGITALE KOMMUNIKATIONSPLATFORME. 10. Oktober 2013 #6 Designproces + Projektstart DESIGN TIL DIGITALE KOMMUNIKATIONSPLATFORME 10. Oktober 2013 #6 Designproces + Projektstart DAGEN I DAG Designprocessen [Pause] Om delaflevering Gruppedannelse [Pause] Gruppeøvelse og projektstart DESIGNPROCESSEN

Læs mere

Video, workshop og modellering - giver bæredygtig innovation

Video, workshop og modellering - giver bæredygtig innovation Video, workshop og modellering - giver bæredygtig innovation Program Kl. 13:00-13:40 Kl. 13:40-14:55 Kl. 14:55-15:40 Kl. 15:40-16:00 Hvordan og hvornår anvender vi video til indsamling af data inkl. observation-,

Læs mere

make connections share ideas be inspired

make connections share ideas be inspired make connections share ideas be inspired Integration af prædiktive analyser og operationelle forretningsregler med SAS Decision Manager Kristina Birch, chefkonsulent Professional Services, Banking & Mortgage

Læs mere

Softwaretest. - også af "ikke testbar" software. DAPUG erfamøde 7. marts 2012 Thomas Vedel, Thomas Vedel Consult email: thomas@veco.

Softwaretest. - også af ikke testbar software. DAPUG erfamøde 7. marts 2012 Thomas Vedel, Thomas Vedel Consult email: thomas@veco. Softwaretest - også af "ikke testbar" software DAPUG erfamøde 7. marts 2012 Thomas Vedel, Thomas Vedel Consult email: thomas@veco.dk Hvorfor softwaretest? Software er sjældent fejlfri Test sikrer at softwaren

Læs mere

Rx: Treating bugs as allergies a safe method to survive software failures. DIKU, Datalogisk Institut, Københavns Universitet 04/01/2006

Rx: Treating bugs as allergies a safe method to survive software failures. DIKU, Datalogisk Institut, Københavns Universitet 04/01/2006 Rx: Treating bugs as allergies a safe method to survive software failures DIKU, Datalogisk Institut, Københavns Universitet 04/01/2006 Præsentation af Jacob Munk-Stander & Lauge Wulff Rx Grund-ide: Hvis

Læs mere

Appendix 1: Interview guide Maria og Kristian Lundgaard-Karlshøj, Ausumgaard

Appendix 1: Interview guide Maria og Kristian Lundgaard-Karlshøj, Ausumgaard Appendix 1: Interview guide Maria og Kristian Lundgaard-Karlshøj, Ausumgaard Fortæl om Ausumgaard s historie Der er hele tiden snak om værdier, men hvad er det for nogle værdier? uddyb forklar definer

Læs mere

SA@Work. Softwarearkitektur i Praksis i Danske Virksomheder. Klaus Marius Hansen Henrik Bærbak Christensen Datalogisk Institut, Aarhus Universitet

SA@Work. Softwarearkitektur i Praksis i Danske Virksomheder. Klaus Marius Hansen Henrik Bærbak Christensen Datalogisk Institut, Aarhus Universitet SA@Work Softwarearkitektur i Praksis i Danske Virksomheder Klaus Marius Hansen Henrik Bærbak Christensen Datalogisk Institut, Aarhus Universitet {klaus.m.hansen,hbc}@cs.au.dk Præsentationen i dag SA@Work

Læs mere

Emergency call button. Stabilt og simpelt

Emergency call button. Stabilt og simpelt Emergency call button Stabilt og simpelt 1 Agenda Områder af speciel interesse Gennemgang Hvad har jeg lært? Spørgsmål 2 Områder af speciel interesse Domæne, Krav, Use Cases, Kvalitetsattributter Arkitektur

Læs mere

2. Systemarkitektur... 2

2. Systemarkitektur... 2 Indholdsfortegnelse 2. Systemarkitektur... 2 2.1 Præsentationsserverarkitektur... 3 2.2 Applikationsserverarkitektur... 7 Version 7.0 Side 1 af 7 5. Systemarkitektur Arkitekturen for Nyt BBR bygger på

Læs mere

Undervisningsbeskrivelse

Undervisningsbeskrivelse Undervisningsbeskrivelse Termin 2014-2015 Institution Rybners Tekniske Gymnasium Uddannelse Fag og niveau Lærer(e) HTX Informationsteknologi B Jeppe Moritz Led Hold 2.E, Årgang 2013 Oversigt over undervisningsforløb

Læs mere

Specialiseringen Rapport Lavede Af Rasmus R. Sørensen Side 1 af 6

Specialiseringen Rapport Lavede Af Rasmus R. Sørensen Side 1 af 6 Side 1 af 6 Indholdsfortegnelse INDHOLDSFORTEGNELSE 1 INTRO 3 STARTEN AF SPECIALISERINGEN 3 ANKOMST TIL SKOTLAND 4 DATABASER 5 NETVÆRK 5 INTERAKTION 5 AFSLUTNING AF SPECIALISERINGEN 5 KONKLUSION 6 Side

Læs mere

Timeout-politik for den fællesoffentlige føderation

Timeout-politik for den fællesoffentlige føderation Side 1 af 8 7. november 2012 Timeout-politik for den fællesoffentlige føderation Dette dokument beskriver en politik for timeout af brugersessioner i den fællesoffentlige føderation, der er obligatorisk

Læs mere

Accelerace og Green Tech Center kommer nu med et unikt tilbud om udvikling af din virksomhed Green Scale Up

Accelerace og Green Tech Center kommer nu med et unikt tilbud om udvikling af din virksomhed Green Scale Up Accelerace og Green Tech Center kommer nu med et unikt tilbud om udvikling af din virksomhed Green Scale Up Accelerace har gennem de seneste 7 år arbejdet tæt sammen med mere end 250 af de mest lovende

Læs mere

Fart på SAP HANA. Sådan laver du analyser direkte på dine data i realtid. Copyright 2012 FUJITSU. Fujitsu IT Future, København, den 16.

Fart på SAP HANA. Sådan laver du analyser direkte på dine data i realtid. Copyright 2012 FUJITSU. Fujitsu IT Future, København, den 16. Fart på SAP HANA Sådan laver du analyser direkte på dine data i realtid 0 Flemming Grand Saphira Consulting Mobile: +45 30 78 45 86 Email: flemming.grand@saphiraconsulting.com Allan Christiansen Fujitsu

Læs mere