Hovedopgave. Master i Informationsteknologi. linien i Softwarekonstruktion. Reconstructing architectural dokumentation for BOS.

Hovedopgave Master i Informationsteknologi linien i Softwarekonstruktion Reconstructing architectural dokumentation for BOS af 15. juni 2010, studerende Kari Rye Schougård, vejleder 1

Indholdsfortegnelse INDHOLDSFORTEGNELSE...1 1. MOTIVATION...5 2. PROBLEM FORMULERING...6 3. METODE...7 3.1 Symphony processen...7 3.1.1 Faser...8 3.1.2 Designfasen...9 3.1.3 Udførelsesfasen...10 3.2 Viewpoints og mål grupper...11 3.2.1 Andre arkitekturrekonstruktionsmetoder...11 3.2.2 Opsummering...16 3.3 Tekniker og metoder...16 3.3.1 Data Gathering...17 3.3.2 Værktøjer...18 3.3.3 Opsummering...20 4. BAGGRUND AF BOS...20 4.1 Brugere af BOS....21 4.2 Ordliste...22 4.3 Opsummering...22 5 FØRSTE INTERAKTION...23 5.1 Rekonstruktion design...23 5.1.1 Problem Elicitation...23 5.1.1.1 Opsummering af Problem elicitation aktiviteten...26 5.1.2 Concept Determination...26 5.1.3 Identify Potentially Useful Viewpoints...26 5.1.4 Define Target viewpoints...27 5.1.5 Define Source viewpoints...27 5.1.6 Define mapping rules...27 5.1.7 Determine Role and Viewpoint of Hypothetical Views...28 5.1.8 Opsummering...28 5.2 Rekonstruktion udførelse...29 5.2.1 Data Gathering...29 2

Manual Inspection...29 5.2.1.1 Databasekomponent over konfigurationsdata...33 Konfigurationsdata og regler...33 Valideringformer...34 Produktvarianter...35 5.2.1.2 Server delen...35 Pakkediagram over Server delen...35 5.2.1.3 Klient delen...36 Klassediagram over BOSClient view configuration til MC402 måler...36 5.2.2 Opsummering...36 5.2.3 Observation af applikationens opførsel...37 5.2.3.1 Struktur af Configate modelkomponent...37 5.2.3.2 Interaktioner under client-side validering i BOS system...38 5.2.4 Erfaringopsamling...39 6. ANDEN INTERAKTION...39 6.1 Rekonstruktion design...39 6.1.1 Usecases...40 Usecase 1 Konfiguration af måler:...40 Usecase 2 - Gem konfiguration af måler...41 6.1.2 Concept Determination...42 6.1.2.1 Identify Potentially Useful Viewpoints...42 6.1.2.2 Define Target viewpoints...42 6.1.2.3 Define Source viewpoints...43 6.1.2.4 Define mapping rules...43 6.2 Reconstruktion execution...43 6.2.1 Data Gathering...43 6.2.2 Usecase 1 Konfiguration af måler...45 6.2.2.1 Statisk information over serverkomponent til Multical402...45 6.2.2.2 Dynamisk information over serverkomponent til Multical402...46 6.2.2.3 Statisk information over klientkomponent til Multical402...47 Struktur af den grafiske grænseflade...48 6.2.2.4 Dynamisk information over klientkomponent til Multical402...49 6.2.3 Usecase 2 - Gem konfiguration af måler...51 6.2.3.1 Validering af MC402 modul...51 Dynamisk information...53 6.2.3.2 Gem MC402 modul...53 Dynamisk information...53 Gem MC402 konfiguration i databasen...55 6.3 Information interpretation...56 6.4 Opsummering af den anden interaktion...56 6.5 Konklusion...57 3

7. REFERENCES...58 BILLAG 1 (BESKRIVELSE AF BOS ARKITEKTUR)....60 BOS Client...60 BOS Server...60 Prods Server...60 Unix Server...61 4

1. Motivation I forbindelse med mit nye arbejde på en industri virksomhed, har jeg fået ansvar for et BOS Java framework, som var lavet af et eksternt konsulent firma for flere år siden. Virksomhedens udviklingsafdeling var ikke så stor på det tidspunkt, og det var billigere at købe sig til et system hos et konsulent firma, i stedet for at implementere et selv. Som resultat af købet var der lavet et framework, og udviklet et salgs system, som er livsvigtig for virksomhedens salg og produktion. Samarbejde imellem virksomheden og konsulent firmaet fungerede rigtig godt i alle disse år, og der var stillet en konsulent til rådighed, som har været med til at udvikle frameworket, og som har fået ansvar for vedligeholdelse og videreudvikling af systemet. Det var den eneste person, som havde viden om systemet. Da han blev alvorlig syg en dag, og derefter havde glemt alt det, han havde lavet, opstod der et stort problem for virksomheden. I forbindelse med det, blev der truffet en beslutning om at ansætte sin egen medarbejder, nemlig forfatteren af denne opgave, til vedligeholdelse af frameworket, hvilket var billigere og meget mere effektivt, end at bruge en anden konsulent fra konsulent firmaet, som så skulle lære systemet fra bunden. I øjeblikket eksisterer der kun i meget begrænset omfang arkitekturdokumentation af systemet. Der er behov for løbende udvikling af nye produkter på basis af frameworket, sammen med vedligeholdelse af systemet. Min opgave er at finde ud af, hvordan jeg hurtigt og effektivt kan lære systemet at kende, for at komme i gang med mine arbejdsopgaver. Det sker tit og ofte, når man kommer i en ny virksomhed, at der ikke altid findes tilstrækkelig arkitekturdokumentation af systemet, og derfor opstår der problemer med, hvordan man griber ind. Hvis det er et meget komplekst system, kan det meget nemt tage lang tid at finde ud af det. Det kunne være meget interessant at finde ud af, hvilke videnskabelige metoder vedr. rekonstruering af arkitekturdokumentation der findes til rådighed, hvordan de kan anvendes, og hvor effektive de er. Denne interesse har affødt formuleringen af denne opgaves problemformuleringen som er: En arkitektonisk rekonstruktion af BOS frameworket ved hjælp af Symphony processen. Arkitektur rekonstruktionen drives af behovet for udvikling af et nyt konfigurationsmodul, som skal anvendes ved salg af en ny varmemåler. Erfaringerne med anvendelsen af Symphony processen opsamles og analyseres med henblik på en evaluering." Dette dokument vil fokusere på: anvendelse af Symphony processen til software arkitektur rekonstruktion præsentation af lessons learned evaluering af Symphony processen Denne undersøgelse kan komme til gavn for mange virksomheder, udviklere og studerende, og give gode håndtag til en effektiv løsning af flere udviklings opgaver. 5

2. Problem formulering Der er behov for en arkitektonisk rekonstruktion, som kan give mulighed for at få overblik over BOS frameworkets arkitektur med henblik på udvikling af nyt konfigurationsmodul, som vil muliggøre salg af ny varmemåler. Arkitektur dokumentation er en abstrakt beskrivelse af et system, som gør det muligt for systemets interessenter at få et indblik i systemet. Arkitektur dokumentationen indeholder design beslutninger, som er baseret på krav, omgivelserne, teknisk og domain viden, og som tydeliggør forbindelser imellem lavt niveau oplysninger, som udtrækkes af systemet, og den abstrakte arkitekturbeskrivelse. Dokumentation af disse beslutninger gør det muligt at lave modifikationer i de senere faser af et projekts livscyklus, og vurdering af risici, som er forbundet med disse modifikationer. I den virkelige verden er arkitektur dokumentation ikke altid komplet, eller overhovedet eksisterende. Kun kode af systemet kan ikke altid fortælle om designbeslutninger. I disse tilfælde er der behov for arkitektonisk rekonstruktion af systemet. Software architecture reconstruction is a process of obtaining the documented architecture of an existing system [Rainer Koschke]. Det er en proces til analyse af systemet, som giver mulighed for at identificere systemets komponenter og deres relationer, og skabe en højniveau repræsentation af systemet. Arkitektur rekonstruktion skaber arkitektoniske view for et eksisterende system. Anvendelse af arkitektoniske viewpoints og views er et nøgle aspekt i Symphony. Deursen et al. beskriver i [van Deursen et al., 2004] en generel metode til at bestemme target view til et system. Denne metode er view-drevet, og det er indledt af en specifik problemformulering som kunne komme fra diverse ledergrupper. Metoden introducerer tre viewpoints, der bruges ved genopbygningen af arkitekturen. Et viewpoint kommer til at udgøre en højniveau repræsentation af målet (Target viewpoint), mens en anden vil være en lav niveau repræsentation (Source viewpoint). De view, der svarer til disse viewpoints vil primært blive skabt ved at indsamle data fra systemet. Det tredje viewpoint (Hypotetisk set) bygger på oplysninger fra personer, som har udviklet systemet. Indsamling af data fra systemet kan gøres på flere måder. Manuel inspektion og leksikalsk analyse blandt andet, bruges til at indhente de ønskede oplysninger fra systemet. Fælles for disse er, at de alle er relateret til statisk analyse af systemet. En anden måde at indsamle oplysninger fra systemet er at observere systemets runtime adfærd (dynamisk analyse af systemet). Tidlige tilgange til arkitektur rekonstruktion adskiller sig fra Symfoni i, at de tager et bestemt mål, konkrete teknikker, og en vist fast sæt af view, der skal rekonstrueres, mens Symphony er en proces, der giver en generel genopbygnings model til at definere rekonstruktions aktiviteter, og rapportere erfaringer ved rekonstruktion. De andre teknikker beskriver hvordan man genopbygger bestemte arkitektoniske views, hvor Symphony også beskriver hvordan man udvælger views til rekonstruktion. En af ulemperne ved at bruge Symphony metode til rekonstruktion er at det er et højniveau præsentation af rekonstruktionsprocessen, som kan være svært at konkretisere især første gang man udfører en arkitektur rekonstruktion. Konkretiseringsprocessen kræver meget arbejde. Dette dokument vil beskrive en rekonstruktion af arkitektur dokumentationen for BOS med anvendelse af de principper, der er beskrevet i [van Deursen et al., 2004], med både statiske og dynamiske analyser som en del af processen. 6

Målet for denne genopbygning er at producere (eller gengive) den arkitektoniske dokumentation for systemet i form af arkitektoniske views, som formaliseres igennem viewpoints, hvilket specificerer den slags informationer som views skal indeholder. For at finde ud, hvilke viewpoints systemet skal repræsenteres med, vil jeg tage udgangspunkt i de anbefalinger som [Christensen et al, 2004] opstiller for arkitekturbeskrivelse. Det betyder, at jeg som udgangspunkt vil benytter 3 viewpoints Module, Component & Connector og Allocation view. Jeg vil naturligvis benytte UML til at beskrive de konkrete target views i form af modul og klassediagrammer, sekvensdiagrammer samt deployment diagrammer [Erikson et al., 1998]. Udover de enkelte viewpoints anbefaler [Christensen et al, 2004] også at de mest betydende krav til arkitekturen defineres og beskrives, svarende til mission i [IEEE 1471, 2000]. Disse krav vil også være defineret og beskrevet i dette projekt. I processen vil jeg fokusere på at bygge nogle arkitektoniske views. Derudover indeholder dokumentet en opsamling af de indsigter (lessons learned), der er fremkommet ved anvendelse af Van Deursens arkitekturrekonstruktionsproces. Endvidere indeholder dokumentet en evaluering af Van Deursens arkitekturrekonstruktionsproces baseret på disse indsigter. 3. Metode Dette afsnit vil give definitionen af Symphony processen, sammen med beskrivelsen af 3 typer views, som er forbundet med den. Afsnittet vil beskrive: hvordan Christensen og IEEEs views forholder sig til Deursens views, de overordnede faser i Symphony processen, som er Designfasen og Udførelsen fasen, udvalg af views ud fra systemets interessenter, samen med opsummering af udvalg af de relevante views, de teknikker, som views kan konstrueres med; de datalogiske værktøjer, der er anvendt som en del af arkitektur rekonstruktions, og som bruges ved statisk og dynamisk analyse. 3.1 Symphony processen [van Deursen et al, 2004] beskriver Symphony processen som a common framework for reporting reconstruction experiences og a vehicle for exposing and demarcating research problems in a software architecture reconstruction. Artiklen beskriver, ud over selve processen, også forfatternes erfaringer med at anvende processen. Dette afsnit beskriver Symphony i korte træk. Symphony følger basalt set en data gathering, knowledge inference and information presentation model, hvor man indsamler forholdsvis rå information omkring et system, destillerer denne information til noget mere brugbart, hvorefter man kan præsentere denne information til de relevante interessenter. Symphony er, som beskrevet i [van Deursen et al, 2004], problem-driven and uses a rich set of architecture views hvilket passer godt ind i øvrige artikler omkring arkitekturbeskrivelser, specifikt [Christensen et al, 2004], og [IEEE Computer Society, 2000]. 7

Symphony anvender 3 typer views i forbindelse med processen: Source views repræsenterer den rå information som kan udtrækkes af systemets source kode, build filer, konfiguration informationer, dokumentation, osv. Target views repræsenterer de mappede source views, som viser dele af systemets arkitektur (as-implemented). Hypothetical views repræsenterer f.eks. eksisterende dokumentation af arkitekturen, eller den information der kan findes frem gennem interviews af tilgængelige eksperter, og som beskriver arkitekturen på den måde som de husker / byggede system på. Arkitekturen i dette view bruges ofte som vejledning til at forstå den as-implemented arkitektur, eller som sammenligning til den arkitektur, som kommer fra genopbygningsprocessen. A view is a representation of a whole system from the perspective of the set of related components Such views are formalized through viewpoints. A viewpoint specifies the kind of information that can be put in the view [IEEE Computer Society, 2000]. Anvendelse af arkitektoniske viewpoints og views er et nøgle aspekt i Symphony. Anvendelse af mangeartet arkitektoniske viewpoints er til gavn for en arkitektonisk rekonstruktion, og hjælper til at afgøre hvilken information der skal rekonstrueres, for at løse et bestemt problem. I flg. [Rainer Koschke], Clements and colleagus brought some order to sea of viewpoints. They distinguish the following categories of viewpoints: Module, Component & Connector, and Allocation viewpoints. I [Christensen et al, 2004] anbefaler Christensen at benytte disse viewpoints for at gøre systemets beskrivelse godt forståelig. Udover de enkelte viewpoints anbefaler [Christensen et al, 2004] også at de mest betydende krav til arkitekturen defineres og beskrives, svarende til mission i [IEEE 1471, 2000]. I forbindelse med Symphony processen, kan disse viewpoints optræde som både source, target og hypotetisk - det kommer an på om det er koden art, der viser implementeret arkitektur eller hypotetisk arkitektur. 3.1.1 Faser Symphony processen består overordnet af to faser Reconstruction design og Reconstruction execution, hvor begge faser følger data gathering, knowledge inference and information presentation modellen som beskrevet i de efterfølgende afsnit. Designfasen består af en fastlæggelse af hvad man ønsker at opnå, herunder formulering af det problem man ønsker at løse og fastlæggelse af henholdsvis Target- og Source views samt regler for hvordan man transformerer de genererede Source views til de ønskede Target views. Udførselsfasen består i at udføre den faktiske analyse af det konkrete system og derved, som resultat, generere de ønskede Target views som blev defineret i forbindelse med designfasen. Outputtet af design fasen er således køreplanen for hvordan rekonstruktionen skal udføres, mens outputtet fra udførelsesfasen er en arkitekturbeskrivelse der løser det ønskede problem, identificeret i designfasen. 8

3.1.2 Designfasen Figur 1 herunder viser en oversigt over flowet i design fasen. Figur 1: oversigt over flow og de aktiviteter, der er involveret i Symphony processen. Det kan findes i [van Deursen et al., 2004, s. 3] Designfasen starter med en Problem Elicitation, eller problemformulering, hvor man formulerer det problem man ønsker at løse ved at udføre rekonstruktionen. Da udarbejdelsen af problemformuleringen involverer et antal forskellige interessenter, vil denne typisk ikke være i termer af softwarearkitektur. Man tager derfor i Concept Determination udgangspunkt i problemformuleringen og definerer hvilken arkitekturinformation der er nødvendig for at løse dette problem. Det er med andre ord i denne forbindelse at man definerer de ønskede Source- og Target viewpoints samt sammenhængen mellem disse. Dette danner grundlaget for de 3 sidste trin: Data Gathering, Knowledge Inference og Information Interpretation, som udgør udførelsesfasen. 9

3.1.3 Udførelsesfasen Udførelsesfasen består, som beskrevet, af de 3 trin Data Gathering, Knowledge Inference og Information Interpretation. Figur 2 herunder illustrerer flowet mellem disse trin. Figur 2 Symphony udførelsesfase. Det kan findes i [van Deursen et al., 2004, s. 3] I forbindelse med Data Gathering indsamles information omkring systemet, typisk ved at benytte værktøjer til at generere data ud fra forskellige aspekter af systemet. [van Deursen et al., 2004] beskriver et antal teknikker og værktøjer som kan benyttes i dette trin. Indsamling af data kan gøres ved at analysere både den statiske og dynamiske aspekt af applikationen. Statisk analyse Analysere applikationens artefakter som source kode, build filer osv. Dynamisk analyse Analyse af runtime opførsel af applikationen, mens det udføres. Det betyder, at de indhentede oplysninger kun er garanteret at være gyldige for den aktuelle udførelse. Værktøjer og teknikker er debugging og Profilers. Når de rå data i form af Source views er indsamlet, kan man i forbindelse med Knowledge Inference anvende de i designfasen opstillede regler for hvordan man mapper et eller flere Source views til de ønskede Target views. Det sidste trin Information Interpretation handler om at gøre den rekonstruerede arkitektur tilgængelig for systemets interessenter. Med andre ord, er det vigtigt at den generede information gøres synlig, sådan at interessenterne har mulighed at drage konklusioner på baggrund af disse informationer. 10

3.2 Viewpoints og mål grupper Som var beskrevet i kapitel 3.1, A view is a representation of a whole system from the perspective of the set of related components. Such views are formalized through viewpoints. A viewpoint specifies the kind of information that can be put in the view [IEEE Computer Society, 2000]. I [Christensen et al, 2004] anbefaler Christensen til at benytte forskellige viewpoints for at gøre systemets beskrivelse godt forståelig. Han snakker om 3 viewpoints, som er beskrevet på følgende måde: Modul viewpoint beskriver funktionalitet af systemet og mapping af funktionalitet til implementation, Component & Connector viewpoint beskriver hvordan funktionalitet af systemet kortlægges til komponenter, og interaktion blandt disse komponenter, Allocation viewpoint beskriver hvordan softwarekomponenter kortlægges ind til omgivelserne, specifikt til hardware struktur. I [IEEE Computer Society, 200] anbefales også, at viewpoints skal udvælges med interessenterne i tankerne. Systemet kan have mange forskellige interessenter, som for eks. Software arkitekt, Udvikler/Vedligeholder, Reviewer, Reviewer/Analyst, Kunder, Netværksadministrator. De opgaver, som jeg har fået i forbindelse med overtagelse af BOS frameworket er at holde styr på fejlrettelser i systemet, ombygning og tilføjelse af nye funktioner, og redesign på længere sigt. Anvendelse af Modul og Component & Connector viewpoints med disse opgaver, vil give mulighed for at arbejde mere selvstændigt og hurtigere. Andre opgaver, som jeg skal stå for, har noget at gøre med, hvordan softwarekomponenterne er fordelt under forskellige miljø, for eksempel når man skal foretage en installations setup. Her er der behov for Allocation viewpoint. 3.2.1 Andre arkitekturrekonstruktionsmetoder I dette afsnit ville jeg præsenter nogle af de arkitekturrekonstruktion metoder som findes allerede, og som fokuserer på software arkitekturrekonstruering og genopbygning. I [Claudio Riva, 2002] fortælles om arkitektur rekonstruktion nøgle rolle i produkt family udvikling, og beskrives reverse engineering (rekonstruction) metode til at begribe en aktuel implementering af et produkt. 1. I følge deres metode, sigter den første fase mod at tydeliggøre semantik af begreberne involveret i genopbygningen. 2. Metode generaliseres til hver arkitektonisk stil i form af at udføre yderligere aktivitet som er fokuseret på de vigtigste arkitektoniske aspekter til arkitekter. 3. Et nøgle aspekt af metoden er en web interface, der tillader arkitekter at offentliggøre de arkitektoniske diagrammer på intranettet. Der bliver inkluderet et Venedig webapplikation, som giver mulighed for at offentliggøre diagrammer på nettet i UML format. 4. Brugeren kan definere enhver form for mapning eller opbygning af source kode model 5. Prolog udnyttes som en mekanisme til at udføre en serie af abstrakte interaktioner. 6. Arkitektonisk koncept bygger på første klasse enheder i genopbygningsprocessen fra de meget tidlige faser. 11

7. Outputtet til rekonstruktionen præsenterer forskellige aspekter af model ved hjælp af flere arkitektoniske views (4+1 model), som er følgende: Conceptual view: beskriver de vigtigste arkitektoniske begreber, der er instantieret i andre views. Component view: beskriver de vigtigste komponenter, deres grænseflader og deres logiske relationer. Development view: beskriver tilrettelæggelsen af kildekodefilerne og deres relationer (for eksempel inkluderer afhængigheder). Task view: beskriver opgavefordeling af de arkitektoniske enheder og viser kommunikationer i indre tasks. Feature view: beskriver run-time gennemførelse af en funktion på et højt abstraktionsniveau. Disse synspunkter, er baseret på statiske aspekter (fanget uden at køre system) og dynamiske aspekter (vedrørende rine-time adfærd). De bruger 4 faser til rekonstruktionen, som de kalder for interaktiv og incremental proces: 1. Recovery of architectural concepts er den første fase, som har til formål at rekonstruere og præcisere betydelige koncepter af arkitekturen, som systemet ar bygget på. Her snakker de om begreber om hvordan udviklerne tænkte på systemet, og som bliver til terminologien til rekonstruerings processen.outputtet af denne fase er et Conceptual view, som beskriver alle de vigtige typer af arkitektoniske koncepter, og deres relationer, sammen med beskrivelse af mapninger imellem højere niveau koncepter og implementationer. Den vigtigste kilde til information er dokumentationen af systemet eller uformelle diskussioner med eksperter. 2. Model captur Her bygges en model af systemet, hvis enheder er forekomster af de begreber, som var identificeret i den foregående fase. Et korrekt valg af de begreber skal sikre, at modellen er bygget på det rigtige niveau af abstraktion. Deres kilde til den statiske analyse er et source kode. De baserer sig på ad hoc-analysatorer (for eksempel skrevet i Perl), eller på de kommertialle API. De opbevarer dokumentation, og software diagrammer (f.eks CASEværktøjer). For den dynamiske analyse, bruger de bl.and. ThirdEye. Modellen af denne fase er præsenteret ved meget lav niveau af abstraktionen. 3. Abstraction Formålet med denne fase er at berige modellen med domæne specifik viden som vil føre til et højt niveau abstraktionen af systemet. De kendte abstraktioner kan let tilføjes til modellen. De ukendte abstraktioner skal identificeres af arkitekter, kategoriseres, og derefter lagres i modellen. Arkitekter producerer manuelt abstraktionsregler, som beriger modellen. Begrundelsen er foretaget manuelt. Abstraktions regler bliver specificeret med en logisk sprog Prolog. 4. Presentation Her vælger arkitekterne en særlig arkitektonisk view, og et særlig visualiserings format: hierarkiske grafer, web-dokumenter (med hyperlinks), UML logiske diagrammer og message sekvens charts. De bruger Rigi til at visualisere hierarkisk orienterede grafer. Dette muliggør for arkitekterne at navigerer i modellen, analysere afhængigheder, og identificere nye mulige grupperinger at tilføje til modellen. De bruger Venice værktøj til at bygge de logiske views(components, packages, interfaces, inheritance and dependencies) i UML notationer. 12

I [Kazman et al. 12] beskrives hvordan en kode niveau abstraktion kan fodre en pattern baseret analyse. Her presenters et ARM (Arkitectur Reconstruktion method), som er en iterativ genopbygningsproces, hvor de historiske design beslutninger er opdaget ved at formulere / validere arkitektoniske hypoteser. De påpeger endvidere, betydningen af modelleringen af ikke kun oplysninger om systemet, men også en beskrivelse af den underliggende semantik. De præsenterer Software Arkitektur Rekovery med to faser: Identificering og udtrækning af source kode artifakter, som inkluderer arkitektoniske elementer, og analyse af de udtrækkende source kode artefakter til at beskrive view af den implementerede arkitektur. De udtrækkende source kode artefakter formerer en sourse model, som består af elementer, (d.v.s. funktioner, variabler, objekter), relationer imellem elementer (funktion kalder funktion, objekt A har en enstance), og et set af attributter af disse elementer og relationer (funktion kalder funktion N flere gange). I artiklen repræsenteres ARM som semi-automatic analyse metode til rekonstruering af arkitekturen, som baseres på genkendelse af arkitektoniske pattern. Figur 3. præsenterer de fire største faser i form af en pattern i genkendelses processen flowchart: Figur 3. Pattern genkendelse proces flowchart. Hentet fra [Kazman et al. 12] Konstruering af den konkrete pattern genkendelses plan består af 3 trin. Det første trin er at udvikle den instantierede pattern beskrivelse, som er konkrete pattern beskrivelser med alle pattern elementer, og deres relationer. Man starter med et design dokument, manuelt bestemt patern som er brugt i designet. Her kan udtrækkes de abstrakte pattern regler design regler, som definerer strukturelle og opførsels properties. Pattern 13

beskrivelser kan findes i design pattern literature, eller udtrukket af de mennesker, som kender systemet design, og kan bruges som supplerende regler. Ved hjælp af disse abstrakte pattern regler, kan man undersøge source kode af flere forskellige potentiale patern instanser til at beskrive konkrete pattern regler. Disse konkrete pattern regler kan genkendes ved navne konversioner og nogle ord af programmerings sprog, eller analyse af data access og kontrol flow. De bruger Rigi Standard Format (RSF) til at skrive specificationer af de konkrete pattern beskrivelser. Det anden trin af ARM er at udtrække source model, som repræsenterer systemets source elementer og relationer mellem dem. Outputtet af denne fase er en source model, som indeholder informationen, der skal bruges til opdage de nødvendige regler. Her præsenteres mulighed for at opdage pttern instanser ved hjælp af Dali, som er en automatisk process, hvor der bruges query værktøjer til at opdage alle pattern instanser. Som det sidste trin, som bruges ved analyse er Reconstruction and analysis af arcitecture. I forbindelse med dette trin bruges visualiserings værktøjet, som Rigi. Og den retter de fundne arkitektoniske pattern instanser mod de designede pattern instanser, organiserer andre elementer i source code model rund omkring de detekterede instanser. I [L.Ding and N. Medvidovic] beskriver Ding og Medvidovic om Focus metode til genoprettelse af arkitekturen. Arkitekturen genoprettes trinvis, og her fokuseres på genoprettelse kun af de deller af systemet, som bliver påvirket af en given ændring. Genoprettelse af et ekstra system arkitektur opstå som en ny modifikation. Focus tilgang er enestående på den måde, at: der genoprettes alle basale byger blokker af arkitekturen (data komponenter, processing komponenter og connectors), den skelner imellem systemets logisk og fysisk arkitektur, og giver muligheden at rekonstruere at system under udvikling. Dette afskiller Focus fra en del af andre relaterede tilgange, som går ud på at genoprettelse af arkitekturen fra systemets source code. Focus tilgang et baseret på antagelse om der er meget lidt eller ikke pålidelig dokumentation der findes for et system, som bliv modificeret. Sammen med det, i fokus laves der et minimale set af krav om, at der er kendskab til: detaljer om den ønskede modifikation, Bruger-niveau properties af applikationen, De basale karakteristikker af arkitekturen. Det første krav er ikke Focus specifikt, og er relevante til hvilken som helst software modifikation arbejde. Det anden krav kan udføres ved at observerer applikation udførelsen. Den tredje krav kan være forbundet med støre udfordringer til de udvikler, som har ingen kendskab til en given implementering platform.der er to interaktioner i Focus som er sammensat af to trin: Architectural recovery og System evolution. Architektur recovery trin sammensættes af seks aktiviteter, som er vist i figur 4. Disse aktiviteter er opdelt i to kategorier: logisk og fysisk arkitektur recovary. Man begynder med en idealiseret, højere niveau model af arkitekturen, som er gættet fra de udvalgte arkitektoniske stiler, et brugerniveau opførsel, og som fokuserer på specifikke deller af arkitekturen, som er påvirket af en krævende ændring, og efterfølgende forfines modellen ved at integrere flere højere niveauer af detaljer. Her starter man mad kildekoden, og abstrakter den til de faktiske komponenter og deres interaktioner. Målet med denne proces er at nå frem til en arkitektur, der giver mening for det pågældende system, d.v.s at den er delvis rigtig.. 14

Figur 4. Architektur recovery trin af Focus. Hentet fra [L.Ding and N. Medvidovic]. System Evolution dette skridt anvendes efter arkitektur genoprettelse er gennemgået, og bruges til at modificere applikationen med de ændringer, som passer til ny krav. Dette skridt udføres også trinvis, sådan at de vigtigste ændringer gennemføres først. Som vist i figur 5. System Evolution er sammensæt af følgende 5 store aktiviteter. Figur 5. Aktiviteter af System evolution. Hentet fra [L.Ding and N. Medvidovic]. Ved den første aktivitet, som er Propose idealized arch evolution bliv lavet et højt niveau arkitektur evolution plan. Den anden aktivitet er Add/Modify Components, og er afhængige af den første aktivitet. Her skal ingeniørerne afgøre, om tilføjelsen af nye eller ændre eksisterende komponenter, eller begge dele. 15

Den tredje aktivitet er Update Component Interactions, og er afhængige af den anden aktivitet. Her opdateres kontrol flow bland de komponenter, som er tilføget eller ændret. Næste aktivitet er Generate Evolved Architecture, og er afhængige af den første og tredje aktivitet. Her alle de ovennævnte ændringer til den oprindelige system integreres i den oprindelige arkitektur, og dette vil danne grundlag for den detaljerede udformning og gennemførelse af ændringer. Den sidste aktivitet er Set the New Focus, og er afhængige af den foregående aktivitet. Hvis arkitekturen genereret i den foregående aktivitet er stadig ikke detaljeret nok til, at gennemførelsen af de nødvendige ændringer, en ny interaktion af de to store skridt i Focus er påkrævet. Her, under efterfølgende interaktioner, setes fokus på de komponenter, der påvirket af ændringer, hvor resten af arkitektur vil forblive upåvirket af ændringer, og er dermed ignoreres i denne proces. Hver efterfølgende interaktion er at yde supplerende lavere niveau detaljer i påvirket komponenter. 3.2.2 Opsummering I dette afsnit er det blevet beskrevet, hvordan det er muligt at rekonstruere softwarearkitektur. Dette gøres ved hjælp af Symphony proces som udgangspunkt. Der bliver også beskrevet 3 viewpoints som er Module, Component & Connector og Allocation viewpoints. Modulet viewpoint er at præcisere det domæne, og den statiske struktur, Component & Connector viewpoint er at tydeliggøre samspillet og indbyrdes kommunikation mellem komponenter, og endelig Allocation viewpoint er at skitsere, hvordan komponenterne er fordelt på de fysiske noder. Den sidste type af view er især relevant, når ingeniører ønsker at konfigurere et testmiljø, som de kan udføre forskellige former for test, dvs. i forhold til applikationen udførelse. Nogle viewpoints er desuden blevet knyttet til deres rette målgrupper, og i forhold til den valgte målgruppe for dette dokument, de relevante viewpoints er blevet udvalgt på baggrund af denne. Det ender med tre viewpoints som måtte være interessant for målgruppen. Det sidste underafsnit om Andre arkitektur rekonstruktionsmetoder bliv gennemgået nogle af de eksisterende rekonstruerings metoder. Efter at målgruppen og viewpoints er blevet defineret, er det næste skridt at tage et kig ind i de teknikker, som disse viewpoints kan konstrueres med. Disse teknikker er beskrevet i det følgende afsnit 3.3 Tekniker og metoder Med genopbygningen af software-arkitektur, er det vigtigt at arkivere korrekt information af systemet. Oplysninger, der er nemme at indhente, ville være information om koden struktur, biblioteker og pakker blandt andre. Oplysninger, som blandt andre, er vanskeligere at udtrække er brug af mønstre og kontrol flow. De nemt hentede oplysninger kontrolleres ofte manuelt, mens forskellige former for værktøjer anvendes, når de mere komplekse oplysninger skal udtrækkes fra applikationen, men ofte afhænger det af de tilgængelige værktøjer. 16

3.3.1 Data Gathering Indsamling af data kan opdeles i flere kategorier, nogle af dem er: Statisk analyse baseres på systemets artefakter (source kode, dens struktur, og anden information), som kan indhentes fra ikke udførende applikation. Hvert af disse artefakter hører indirekte til deres egne views sammen med de oplysninger, der kan udledes af dem. Certain components or subsystems may be stored in particular directories, and capturing relations such as dir_contains_file and dir_contains_dir can help to identify components later in the reconstruction process. [Rick Kazman et al., 2002 s. 7] Ved strukturering af kildekoden til en applikation, en software arkitekt ofte inddeler hver komponent eller modul i separate mapper. Disse mapper er nemme at identificere, og det gør det ofte lettere at identificere komponenter på denne måde. Forbindelserne mellem de forskellige komponenter kan identificeres ved at iagttage overskrifter, der bruges i komponenterne ved opsporing af de respektive header filer tilbage til deres oprindelses kilder. Fra en fil kan det yderligere blive udtrukket, hvilke funktionsdefinitioner den indeholder, og kald til disse kan yderligere hentes. Dette vil skitsere interfaces, relationer, og identificerer interaktion, eksterne synlige egenskaber og relationer. En endnu tættere analyse af filerne kan hente information om, hvor variablerne er skrevet og læst. Dette beskriver, hvordan data bliver transporteret ind i applikation, som giver mulighed til at identificere hvilke typer af connectors, som bruges imellem komponenterne. Forskellige slags værktøjer anvendes til at indhente de statiske oplysninger som beskrevet ovenfor. Kategorier, som af disse værktøjer kan inddeles i, er beskrevet nedenfor og beskrevet i [Rick Kazman et al., 2002 s. 8] 1. Parsere, som analyserer koden og genererer typisk interne repræsentationer, der anvendes til generering af maskinens kode. 2. Abstract syntaks træ baseret analysator, som analyser kode til det formål at generere eksplicitte træ repræsentationer, og output udvalgte stykker af arkitekturen. 3. Leksikale analysatorer, som analyserer kilden artefakter som strenge af leksikalske elementer. Når de korrekte statiske oplysninger er hentet fra artefakter, der tilhører applikationen, bør det, hvis de korrekte oplysninger er blevet fanget, være muligt at gøre de første udkast til de views, som er baseret på biblioteker og kildekode struktur. Næste view fra de første udkast kan suppleres med oplysninger om adfærdsmønstre, call grafer og kode instrumentering etc. Dymanisk analyse indsamling af informationer fra systemet på run time, som giver et indblik i de dynamiske aspekter ved systemet, dvs. hvad der sker når systemet kører, hvilke elementer der samarbejder og hvordan de samarbejder. Ved en dynamisk analyse, kommer de udtrækkende oplysninger fra den kode, som er ved at blive udført. Dette kan gøres ved hjælp af debugging. Mange programmer har debugger indbygget, som giver mulighed for at se på systemets tilstand, mens den udføres. Fordele med debugging er at det er muligt at se koden under udførelsen, og indhente nyttig (statisk) information samtidig. Ulempen er håndtering af multitrådet og real-time events, når debugger stopper. 17

Men, selv den dynamiske analyse lader til at være en nem måde til at udtrække et præcis figur af systemet, den har også ulemper, som også er beskrevet i [IBM Systems Journal, 36(4):564 593, Oct. 1997, s.20] Det er meget svært at udtrække alt opførsel fra et kompleks system Mængden af information er uhyre stor, og det kræver meget tid til analyse Men, i kombinationen med den statiske analyse, dynamik analyse kan bruges til afklare de specifikke dele af systemet. 3.3.2 Værktøjer I det foregående afsnit var nogle af de generelle teknikker, som kan bruges til at indsamle oplysninger til arkitektoniske genopbygning, nævnt. Disse teknikker er beskrevet i to kategorier: 1) en statisk analyse og 2) en dynamisk analyse. Når disse teknikker er skitseret er det på tide at tage et kig på nogle af de værktøjer, der bruges af disse teknikker. Det følgende afsnit vil indføre et par af disse værktøjer, og vil beskrive generelt, hvilke oplysninger den kan indsamle fra applikationen og dets artefakter. Det system, som jeg skal rekonstruere i dette projekt, og er udviklet i Java programmeringssprog. De værktøjer, som kan være relevant for mig at anvende, kan være: ECLIPSE, Code Visual to flowchart, og KLOCKwork insight. Eclipse is an open source community, whose projects are focused on building an open development platform comprised of extensible frameworks, tools and runtimes for building, deploying and managing software across the lifecycle. [Eclipse Foundation]. For det meste bruges Eclipse som en Java udvikling miljøer. Fordele: En fordel ved Eclipse arbejdsområdet er, at det giver et meget tilpasselig miljø, der kan skræddersys til behovene af de enkeltes software udviklere. Man kan bruge UML baserede model-driven development (MDD)sammen med Eclipse. Denne fremgangsmåde giver mulighed for at opnå fordelene ved abstraktion og automatisering fra en modellering, simulering og kodegenerering løsning med C, C++ oh Java. Som en ekstra fordel, kan automatisk MDD miljøproducere kode dokumentation og test scenarier. Samtidige modellen og kode niveau debugguing Det koster ikke noget at bruge værktøjet, og det er det værktøj, hvor det system, som jeg skal rekonstruere, var udviklet i. Jeg har kendskab til udvikling i Eclipse teknologier fra mit tidligere job. Fire vigtige teknologier kan bruges ved Eclipse: Reverse engineering af eksisterende kode i en grafisk model; Round-aktivering af ændringer i den kode, der udvikles tilbage i modellen; Automatisk generering af ny kode fra modellen; Dynamic model code associativity (DMCA), som hjælper med at sikre, at ændringer af enten koden eller model holdes synkroniseret. 18

Code Visual to flowchart Et kommerciel software produkt kaldet Code Visual til flowchart er udviklet af et selskab kaldet FateSoft eller Share-it 9. Applikationen er i stand til at analysere kildekode og konstruere et flowchart diagram baseret på flow i kildekoden. Ifølge selskabet selv har dette produkt følgende vigtige funktioner: Det kan anvende reverse engineering af et program med kode analysator, skabe programmering af flow chart fra kode, der mest bruges på flowcharting af et program, og dokumentere kildekode. Det kan generere Visio, Word, Excel, Power point, PNG og BMP flowcharts dokument fra kode. I forhold til disse centrale funktioner den kan bruges til at undersøge flow i kildenkode. En vis sekvens af kald eller en stor og kompleks funktion kan visualiseres, for at hjælpe til at forstå kildekoden. Diagrammet kan udvides med kodestumper og kommentarer fra kildekoden. Det giver en let navigering gennem flowchart diagram. Flow i kildekoden er beskrevet ved hjælp af flowcharts. Kildekoden typisk viser strukturer (dvs. hvis-sætninger, løkker osv.), og nedkaldelse. Denne information kan bruges til at rekonstruere software arkitektur som sekvens diagrammer for nogle dele af system, men ulemperne ved dette værktøj er, at det fungerer på et meget lavt niveau. Fordi denne ikke kan bruges som et stand-alone værktøj til at rekonstruere software arkitektur, men når komponenterne er identificeret, kan den bruges til at identificere, hvordan kommunikation er foretaget mellem dem, ved at analysere de metoder, som tager sig af forbindelsestrapper eller et andet konkret handling såsom at tilføje en bruger. Dette værktøj kan bruges samen med statisk og dynamisk analyse værktøjer ved rekonstruktion af sequence diagram. Fordelene ved at bruge dette værktøj er: en nem navigation gennem koden ved hjælp af automatisk genererede flowcharts, nyttigt ved diagnoser connectors og komplekse foretningsregler. Ulemperne ved at bruge dette værktøj kan være: Det fungerer på et meget lavt niveau, hvilket gør det vanskeligt at udtrække højt / arkitektonisk information. KLOCworks insight Tool KLOCworks insight Tool bruger kode analyse algoritmer til at udtrække views af softwarearkitektur, interaktioner, logik flow, og udførelse at tråde direkte fra source kode af både hele og delsystemer [Klocwork 02]. Sight angiver produkt beskrivelse for KLOCwork som følgende: allows for architektural comprehension, automatic control, and management through its graphic visualisation of software architecture, architectural rules setting, and automatic tracking capabilities. Dette værktøj tillader ikke brugeren at bygge, eller bruge pattern til abstrakt repræsentation af arkitektur fra underordnet information, som var udtrukket fra source kode. Snarere værktøjet tillader brugeren at vælge kilde elementer fra visualisering og skabe større gruppering af disse elementer ind i arkitektoniske komponenter, hvilket kan lette arkitektur rekonstruktion. 19

3.3.3 Opsummering I dette afsnit har jeg kigget på de generelle teknikker, som kan bruges i til at indsamle oplysninger til arkitektoniske genopbygning, og som er en af Symphony udførelsesfase aktiviteter. Disse teknikker var beskrevet i to kategorier: 1) en statisk analyse og 2) en dynamisk analyse. Under afsnittet Værktøjer er der beskrevet generelt nogle af de værktøjer, der kan bruges i forbindelse med disse teknikker, og hvilke oplysninger der kan indsamles fra applikationen og dets artefakter. Der blev beskrevet om ECLIPSE, Code Visual to flowchart, og KLOCKwork insight værktøjer, og der var præsenteret fordelene og ulemperne ved brug af disse værktøjer. I dette projekt har jeg valgt at bruge ECLIPSE fordi det er dette værktøj, som den eksisterende applikation var udviklet i fra staren, det dækker de behov, som jeg har i forbindelse med rekonstruktionen, som skal udføres, og som ikke er forbundet med udgifter, fordi det er gratis at bruge. 4. Baggrund af BOS BOS står for Brugevenligt ordre system. Målet med BOS var at ordresystemet på Kamstrup A/S kunne få en forbedret brugergrænseflade, en lettere indtastningsprocedure, en minimering af fejlordre og blive forbedret til benyttelse gennem Internettet. Kvalitetsfaktorer: Brugervenligt Udvidelsesvenligt Vedligeholdelsesvenligt Sikkert Minimum fejlprocent Forståeligt Korrekt Tekstbart BOS administrer indtastning, søgning og opfølgning på ordre både for Konfigurerede og Ikke Konfigurerede Varer. BOS er brugergrænseflade, som sørger for validering af de Konfigurerede varers hardware og software. Primær grund til at BOS skulle udvikles var, at Kamstrup A/S har haft store omkostninger i forbindelse med forkert konfigureret hardware. 20

BOS skulle: sørge for at forkert konfiguration ikke kunne forekomme, hardware såvel som software sørge for at gemme og hente Igangværende Ordre, så man ikke behøvede at genindtaste data sørge for at vedligeholde en prognose over hvornår den udvalgte vare kunne leveres (dette gælder konfigurerede varer) der skulle foreligge en hovedplan, så man kunne se hvor mange ikke-konfigurerede varer der er på lager sørge for at hente Gamle Ordrer, og tilrette dem, derunder skulle det være muligt at oprette, gemme og hente kundeprofiler indeholdende ordretemplates, begge skulle tilrettes sørge for mulighed for at udskrive ordrebekræftelse til kunden på e-mail, fax og print sørge for at vise oversigter over Gamle Ordrer til kunderne sørge for at man kunne fremkalde en oversigt over Afgivne Ordrer og deres status i produktionen, så kunderne kunne få at vide hvor deres varer befinder sig indeholde en administrationsdel, så systemadministrator kunne vedligeholde brugerprofiler og kundeprofiler, sammen med at det skulle være muligt for systemadministrator at slette ordre templates, leveringsadresser samt konfigurationer. Brugerfladen, inklusivt varebeskrivelser skulle forefindes på flere sprog, idet en del af Kamstrup A/S kunder er udenlandske og fordi der senere skulle være mulighed for at disse kunder selv kunne indtaste ordre over Internettet. Informationer til BOS kommer fra en Produkt Data Base (PDB). PDB består af flere databaser, der indeholder alle de data der skal bruges i BOS. Dette indeholder tabeller med oplysninger om ordre, kundeprofiler og brugerprofiler. Derunder er der tabeller der beskriver valideringsreglerne for hardware. PDB oprettes i en Progress database samt en SQL database for at lette tilgangen fra MFG til databasen (Progress delen). PKS er et system der kan validere software, og den indeholder softwarevalideringsregler i databaseform og i programmeret form. BOS bruger PKS til validering af hver eneste felt i softwarekonfiguration af en konfigureret vare. Når alle felter er udfyldt foretages en ekstra slutvalidering ned i PKS. 4.1 Brugere af BOS. De grupper af personer der benytter BOS er: Systemadministrator, som: står for oprettelse og vedligeholdelse af Brugerprofiler samt Kundeprofiler står for vedligeholdelse af sprogfunktionalitet i systemet Sælgere, som indtaster nye leveringsadresser til kundeprofiler, må ikke have adgang til systemadministratorsiderne. BOS benyttes af Kamstrups sælgere mange gange om dagen. Derfor skulle BOS have en brugervenlig grænseflade der kunne være nem at finde rund i, med mulighed for at bruge tastaturet til rokering mellem felter i indtastningsproceduren. Tastaturet skulle bruges til alle funktioner. 21

BOS blev udviklet i programmeringssprog Java og gør brug af produktet SonicMQ til kommunikation mellem de forskellige systemdele (PKS, PDB, og BOS). SonicMQ er et beskedsystem udviklet i Progress der ved hjælp af en central Broker er i stand til at håndtere meddelelser mellem vidt forskellige systemer. Der bruges så vidt muligt XML som besked-format. Der gøres desuden brug af en MS-SQL Database. 4.2 Ordliste Centrale ord Brugerprofil Broker Gammel Ordre Igangværende Ordre Indkøbsordre Konfigurerede Varer Kunde Kundeoplysninger MFG/PRO Ordretemplate Prognose Progress PKS PDB Validering Forklaring En omsætning for de brugere der benytter BOS Distributør til udveksling af beskeder mellem 2 eller flere parter. En ordre der er sendt til kunde En ordre der er ved at blive indtastet, samt en ordre der er delvis indtastet og gemt. Det nummer kunden har på ordren i sit eget system Varer der er kombineret af flere dele, eller varer med indstilleligt software. En virksomhed eller flere virksomheder der har slået sig sammen om at bestille varer. Kunders adresse, Leveringsadresse og Faktureringsadresse. Administration system a la SAP. En ofte benyttet skabelon for en ordre. Knyttet til en kundeprofil. En oversigt over hvor mange enheder af varen der kan reserveres i produktionen, på ugebasis. En database. Produkt Konfigurerings System validere Software konfigurationer. Produkt Data Base validere Hardwarekonfigurationer. En test af og godkendelse af, at delkomponenter i varen passer sammen. 4.3 Opsummering Formålet med dette afsnit var at give læseren et overblik over, hvad BOS system er, og hvad det bruges til. Her blev beskrevet: definitionen af BOS system, hvilke kvalitet faktorer BOS systemet skulle opfylde, hvilke krav der var stillet til BOS systemet, og hvem der er brugere af BOS. Under Ordliste er der beskrevet og forklaret de begreber og forkortelser, som bruges i BOS. 22

5 Første interaktion 5.1 Rekonstruktion design Som beskrevet i afsnit 3.1.2 i denne rapport, består Symphony processen af flere rekonstruktions skridt, hvor Design skridt inkluderer Problem Elicitation, hvor det problem, som sættes i gang til rekonstruktionen, skal analyseres og diskuteres med interessenterne, og Concept Determination, hvor man skal identificere arkitektonisk koncept, relateret til problemet. Disse skridt vil være beskrevet i dette kapitel i afsnittene 5.1, og 5.2. 5.1.1 Problem Elicitation Som beskrevet tidligere i problemformulering, ønsker jeg at benytte Symphony til arkitektonisk rekonstruktion af BOS, som kan give mulighed for at få overblik over BOS frameworkets arkitektur med henblik på udvikling af nyt konfigurationsmodul, som vil muliggøre salg af en ny varmemåler. For at identificere de dele af systemet, som skal bruges i forbindelse med udvikling af nyt konfigurationsmodul i BOS, har jeg haft flere møder med folk fra min arbejdsgruppe, som har relation til vedligeholdelse af konfigurationsdata, og som tidligere har været involveret i analyse i forbindelse med udvikling af BOS frameworket, og ved implementeringer af de tidligere målere. Deres opgaver var, og er at holde styr på datagrundlag og de konfigurationsparametre, som skal bruges af BOS frameworket til implementering af ny måler og andre produkter. Dette gav mig mulighed for at se hvordan datagrundlag for et ordre, sammen måler specifikke konfigurationer er designet, og implementeret i SQL database. Sammen med det, har jeg haft mulighed for at gennemgå BOS Client applikationen funktionalitet, ved oprettelse af flere ordrer på nogle af de eksisterende produkter sammen med sælgere, som er primære brugere af systemet. Dette gav mig mulighed for at identificere de skærmbilleder, som står for konfiguration af måler, sammen med validering af de komponenter, som en måler kan bygges med. Jeg har også fået mulighed for at snakke med en ekstern konsulent Ole Frederiksen, som står for ansvar for MFG og Progress systemer, som bruges af BOS frameworket til at gemme alle ordre data, som skal bruges i forbindelse med produktion af måler i MFG. Han har været med ved analyse og udvikling af BOS framework helt fra starten af. Han kunne hjælpe med at få overblik over BOS system opbygning og deployment delen. Efter alle disse interview, fandt jeg ud af: at der findes et begrænset antal af gamle dokumenter, som beskriver analyse af BOS frameworket, at der findes dokumentation vedr. konfiguration parametre til de tidligere implementerede konfigurationsmoduler, som indgår i validering af softwarekomponenter, som konfigurationsmodulet består af, at data til den ny konfigurationsmodul, som skal udvikles, skal gemmes og vedligeholdes på lignede måder, som de tidlige konfigurationsmoduler, 23

at der findes kilde kode af hele frameworket, som kunne sættes ind i Eclipse udvikling miljø, så det er muligt at afvikle frameworket lokalt på min maskine, at alle de tidligere implementerede konfigurationsmoduler var implementeret som add-on til BOS systemet, at der findes et højniveau deployment diagram over hele BOS systemet, som viser hvordan BOS system var designet fra starten af. Ud fra interview med Ole Frederiksen, fandt jeg ud af, hvilke dele af systemet der var for gamle, og skulle erstattes med de, som er aktuelle nu, hvis system skal være up to date. Jeg har lavet et revideret deployment diagram, og det er brugt som input til at konkretisere problemet. For at forklare hvilke moduler rekonstruktionen vil koncentrere sig om, kommer her en præsentation af det reviderede deployment diagram (se Figur 6). Beskrivelse til diagrammet findes i Bilag 1. Diagrammet viser, at design af BOS er tænkt som 3-lags client/server model. 24

Figur 6: BOS komponent arkitektur deployment diagram. Revideret udgave af gammelt diagram, som kommer fra [BOS]. Ud fra alt den information, som bliv opsamlet i dette skridt, kunne jeg identificere de komponenter, der indgår i en af de tidligere implementerede moduler, og som skal indgår i min rekonstruktion. Disse er: Serverkomponent, som holder styr på database og kommunikationskomponent. 25

Databasekomponent, som indeholder en række af stored procedures, der kaldes for at hente og gemmer informationer, og som er defineret på SQL server. Klientkomponent, som er en grafisk brugegrænseflade, og som giver mulighed at gennemgår Hardware vælg og software konfiguration af en konfigurationsmodul. 5.1.1.1 Opsummering af Problem elicitation aktiviteten I dette afsnit ville jeg beskriver de opsamlede erfaringer med at udføre Problen elicitation aktivitet, som er en af de første aktiviteter under designfase af Symphony processen. Som første trin af denne aktivitet, har jeg formuleret det problem, som skulle løses ved udførelsen af rekonstruktionen. I efterfølgende trin har jeg identificeret de deler af systemet, som skulle bruges i forbindelse med at løse problemet. Dette bliv gjord ved hjælp af møder og interviews med de forskellige mennesker, som havde relationen til systemet., sammen med gennemførsel af forskellige scenarier, som sælgere bruger BOS system til. Som resultatet af opsummering af alle disse trin bliv der produceret en liste over dokumentation, og de resurser, som jeg skal bruger under rekonstruktionen. 5.1.2 Concept Determination Som beskrevet tidligere i afsnit 3.1.2 handler Concept Determination om at raffinere problemformuleringen til det sæt Source, Target og Hypotethical views, som kan vise den information, man ønsker for at løse problemet med. De efterfølgende afsnit svarer til de 5 trin indenfor Concept Determination, som [van Deursen et.al.,2004] beskriver. 5.1.3 Identify Potentially Useful Viewpoints Når man dokumentere softwarearkitektur, er det gavnligt at benytte forskellige viewpoints til et system, til at gøre beskrivelsen af systemet forståelig. Som det også var beskrevet i afsnit 3.2, ønsker jeg at tage afsæt i de anbefalinger, som [Cristensen et al, 2004] opstiller for arkitekturbeskrivelser. Det betyder at jeg som udgangspunkt skal benytte 3 viewpoints Modul, Component & Connector og Allocation. Definitionen og beskrivelse af de udvalgte til første interaktions viewpoints kommer i afsnit 5.2.3. Jeg vil naturligvis benytte UML til at beskrive de konkrete target viewpoints i form af modul- og klassediagrammer, sekvencediagrammer samt med deploymentdiagrammer [Eriksson et al, 1998]. Udover de enkelte viewpoints anbefaler [Cristensen et al, 2004] også, at de mest betydelige krav til arkitekturen defineres og beskrives, svarende til mission i [IEEE 1471, 200]. Tidligere i afsnit 4, var der angivet beskrivelse af BOS system, sammen med alle de krav, der var stillet til BOS system helt fra starten af. I forbindelse med implementering af den ny konfigurationsmodul stilles der følgende krav til BOS: at der skal udvikles BOS system, som skal søge for validering af den nyudviklede konfigurationsmodulets hardware og software; at forkert konfiguration ikke kunne forekomme, hardware såvel som software; 26

at det skal være muligt at gemme og vedligeholde de konfigurerede data til den pågældende konfigurationsmodul Det er nødvendigt at implementere en databasekomponent til konfigurationsmodul fordi: Det er forskellige informationer der skal hentes/gemmes for hvert produkt. Det er forskellige Stored Procedure (SP) der skal kaldes pr. produkt. De SP er der skal kaldes kan ligge på forskellige databaser. 5.1.4 Define Target viewpoints Som beskrevet i [van Deursen et al., 2004], er target views outputtet fra rekonstruktionsprocessen. Som tidligere beskrevet ville jeg tage udgangspunkt i [Christensen et al., 2004], når jeg udarbejder arkitekturbeskrivelse. Jeg vælger også at tage udgangspunkt i en af de identificerede til rekonstruktion komponenter fra afsnit 5.1, som er Klientkomponent, og som er en grafisk brugegrænseflade. Her kam man gennemgår Hardware vælg og Software konfiguration af en konfigurationsmodul. Jeg har med udgangspunktet heri, opstillet følgende target viewpoint. Module viewpoint Formålet med dette viewpoint er at give en indsigt i hvordan funktionalitet mapper til implementeringsenhederne for de pakker og klasser som indgår i at foretage et Hardware valg og Software konfiguration af et konfigurationsmodul. Module viewpoint vil blive beskrevet med en pakke og et klassediagram (Klientkomponent). Component & Connector (C&C) viewpoint - formålet med dette viewpoint er at give en indsigt i hvordan funktionalitet på run-time mapper til implementeringsenheder (componenter), som er ansvarlige for udførelse, sammen med hvordan disse enheder udveksler kontrol og data i at foretage et Hardwarevalg og Software konfiguration af et konfigurationsmodul. C&C viewpoint bliver beskrevet med et sekvensdiagram. 5.1.5 Define Source viewpoints Som beskrevet i afsnit 3.1, er en af de typer af view, som Symphony anvender, et source view. Her repræsenteres den rå information som kan udtrækkes af systemets source kode, build filer, konfiguration informationer, dokumentation, osv. Denne proces er tæt forbundet med at definere mapping regler til at mappe source views til target views. En indledende analyse af strukturen af BOS kildekoden viser at Moduldiagrammet kan baseres på den. Dette kan gøres i form af reverce reingenering i Eclipse udviklingmiljø, ved hjælp af UML tools, som er integreret ind i Eclipse. Component og Connector viewpoints er et højniveau view, som er svært at automatisere genereringen af, og derfor vil den ikke laves her. 5.1.6 Define mapping rules Tabel 1 viser opsamling af de mapping regler, der ville anvendes ved den første interaktion. 27

Vedr. Modul diagrammer: UML værktøj, som er integreret i Eclipse, giver mulighed at generere Modul diagrammer fra kildekoden, som jeg har fuld adgang til, og derfor behøver jeg ikke at opstille regler for mapping af data mellem source- og target views. Target Viewpoint Source Viewpoint Mapping Klasser genererede fra den del af koden, som findes i.jar fil.jar fil, Dir struktur; Package struktur; Java regler om packages Package diagram Klasse diagram Fil Navne Type referencer mellem klasser Automatisk Java regler om pakker fra Eclipse Model Klasse diagram Sekvens diagram Database diagram Relationer mellem tabellerne Implementering klasser Automatisk MC SQL server regler om tabeller og relationer mellem tabeller Førsteklasses repræsentation af kommunikation sti imellem komponenter Tabel 1. Viewpoints og Mapping Rules til den første interaktion. 5.1.7 Determine Role and Viewpoint of Hypothetical Views Ifølge [van Deursen et al., 2004] er hypotetiske views mest anvendt til at guide rekonstruktionen eller som grundlag for sammenligning af arkitekturer f.eks. om en arkitektur rent faktisk er blevet implementeret som det var designet. I mit tilfældet vil de hypotetiske views blive anvendt til at guide rekonstruktionen. Som tidlige beskrevet er det lykkes for mig at finde et begrænset antal af gamle dokumenter, som beskriver arkitektur ag BOS ved opstart af udvikling af dette system. Ved hjælp af interview med Ole Frederiksen, har jeg også fået et up to date figur over de komponenter, som BOS består af, sammen med ansvar fordeling og relationer mellem dem i form af det overordnede deployment diagram over hele BOS system. Denne figur kan danne grundlag for det ønskede deployment diagram. 5.1.8 Opsummering I denne afsnit ville jeg beskrive de opsamlede erfaringer ved brugen af Concept determination trin af Symphony processen, og som bruges til at bestemmer, hvilken information af arkitekturen er nødvendig til at løse problemet, sammen med den måde, som dette informationen skal præsenteres på. I den foregående afsnit har jeg beskrevet 5 trin indenfor Concept Determination. 28

Under det første trin, som er Identify Potentially Useful Viewpoints, har jeg besluttet om at benytte 3 viewpoints Modul, Component & Connector og Allocation til at arkitekturbeskrivelser under min rekonstruktion. Sammen med det var truffet beslutninger om at bruge UML til at beskrive de konkrete target viewpoints, sammen med hvilke typer af diagrammer, der skal anvendes. Her bliv også defineret og beskrevet de mest betydelige krav til arkitekturen. Under afsnittet Define Target viewpoints har jeg defineret og beskrevet de target viewpoints, som er relevante til Klientdelen af systemet. I afsnittet Define source viewpoints, har jeg truffet beslutninger om hvilke sourse viewpoints bliv bygget under rekonstruktionen. I afsnittet Define/Refine Mapping rules har jeg opsamlet de mapping regler, der skulle anvendes ved den første interaktion. Det er disse mapping regler, som jeg skal anvender til at bygger target views ud fra sourse views. I den sidste afsnit har jeg truffet beslutninger om at jeg ville bruge hypotetiske view til at guide rekonstruktionen. 5.2 Rekonstruktion udførelse 5.2.1 Data Gathering De følgende afsnit beskriver hvordan de udvalgte til rekonstruktion af BOS system delkomponenter blev analyseret for at danne de beskrivende source views. I denne første iteration er det source kode analyse. De data gathering ekstraktion teknikker, som jeg vil anvende i første interaktion er: Manual Inspection af direktory struktur af BOS (pakker struktur, verifikation af clientserver separation); Gennemgang af klasse hierarki og andre konstruktioner ved brug af Eclipse UML. Observerer applikationens opførsel ved udførelsen; læse kilde kode; læse diagrammer fra BOS dokumentation. Manual Inspection Som var beskrevet i afsnittet 5.1, findes der source kode af hele frameworket, som kunne sættes op i Eclipse udvikling miljø. Dette giver mulighed for at afvikle frameworket lokalt på min maskine. Ud fra system opsætning kan jeg se de projekter og pakke strukturer, som frameworket er opdelt i. Se figur 5.1. Ud fra figuren kan man se, at frameworket er opdelt i to forskellige projekter: BOSServer og Client, som svare til den opdeling for Server og Klient komponenter, som man kan se fra den overordnede deployment diagram (figur 6). 29

Figur 5.1. En overordnede projekt opdeling for BOS framework i Eclips Pakage Explorer. Ved at analysere nærmere BOSServer projekt, kan jeg se, at serverdelen består af Database og Kommunikationskomponent. Se figur 5.2. Figur 5.2 Source view over serverdelen af BOS Framework. 30

Kommunikationskomponenten (alle pakker, som starter med bosserver.communication) indeholder et interface, som klienten anvender til at kommunikere med server modulet. Pakke bosserver.communication.produkts.pks.db indeholder klasser, som holder styr på databaseadgang til alle af de eksisterende måler. Andre pakkers navne, som starter med bosserver.communication.produkts.pks.db + måler navn (mc402, mc601, mc801 + modul + nr Findes til de måler typer, som kan konfigureres med løse moduler, og som grupperes under forskellige nr. Disse pakker indeholder klasser, som holder styr på database adgang til de løse moduler, som nogle af de eksisterende måler kan konfigureres med. Databasekomponent (alle pakker som starte med bosserver.model) tilbyder adgang til Prods og Elmåler databasen. Resterense pakker er hjælpepakker som bosserver.util og bosserver.exeption. Ved at analysere Client projektet, nærmere kan man se, af hvilke dele Client delen består af. Se figur 5.3. Jeg kan se, at Client delen er noget stører end Server delen, og logisk opdelt på følgende mode: pakker, som hører til bosclient.adminview, hvor der holdes styr på den administrative del af BOS Client, pakker, som hører til bosclient.communikation delen af BOS Client, og står for kommunikation mellem server og client delen, pakker, som hører til bosclient.view delen af BOS Client, og det er der, hvor de tidlige måler implementeringer er placeret i de relevante pakker på følgende måde: - bosclient.view.congfig.mc402 - bosclient.view.congfig.mc402.validator - bosclient.view.congfig.mc402.moduls - bosclient.view.order - de øvrige pakker Navn mc402 referer til en konkret måler type, og strukturen i form af bosclient.view.congfig + måler navn genfindes for de andre måler typer, som mc601, mc801, multical401. Navn bosclient.view.congfig.mc402.moduls referer til de løse moduler, som MC402 måler kan konfigureres med. Strukturen i form af bosclient.view.congfig + måler navn + modules genfindes også til andre måler typer, som kan konfigureres med de løse moduler, dog ikke til multical401, fordi at den ikke kan indeholder moduler. Pakke bosclient.view.order, som holder styr på implementering af Order delen, og de øvrige hjælper pakker. Ud fra denne opbygning kan man konstatere at, i dette framework er meget tæt kobling imellem den generelle del af Clinten og de specifikke implementeringer af de forskellige konfigurationsmoduler, som var implementeret ind i systemet. 31

Figur 5.3. Client view af BOS framework, som det ser ud i Eclips udvikling miljø. Ud fra den gamle dokumentation, som var fundet i forbindelse med Problem elicitation, fandt jeg ud af, at de ovenover beskrevne komponenter, som kommunication, database, og view komponenter er de samme elementer der findes i det hypotetiske deployment diagram. Figur 5.3.1 viser på et overordnet niveau de komponenter der indgår i en konfigurationsmodul. Klient Server Database gui Configate db db comm comm Figur 5.3.1. Deployment diagram over konfigurationsmodul. Kommer fra gammelt BOS dokumentation. 32

Der vil i forbindelse med udvikling af et nyt konfigurationsmodul være nødvendigt at implementere nye klient-, server- og databasekomponenter. I de følgende afsnit vil jeg analysere disse komponenter for at finde ud af, hvad der skal implementeres i de enkelte komponenter. 5.2.1.1 Databasekomponent over konfigurationsdata Selve Databasekomponent, som var udvalgt til rekonstruering under Problem elicitation, repræsenterer en af Prods databaser, der skal anvendes af konfigurationsmodulet. Databasekomponent indeholder en række af Stored Procedures (SP), der kaldes for at hente og gemme informationer, og er defineret på SQL server. Databasekomponent bliv analyseret ved hjælp af ApexSQL Edit værktøj. I det følgende beskrives, hvordan konfigurationsdata opbevares i databasen, hvilke valideringer der kan udtrykkes i databasen, samt hvordan data der gemmes i databasen. Konfigurationsdata og regler Figur 5.4 viser tabeldesign for de tabeller, der opbevarer konfigurationsparametre og regler for konfigurationsmoduler i den Generale modul (Configate - identificeret og beskrevet under Dynamisk analyse). Tabelstrukturen er så generel, at den uden videre kan anvendes til at opbevare regler og parametre for et vilkårligt antal produkter. Tabelstrukturen er oprettet i Prods databasen, hvor den pt. indeholder konfigurationsdata for alle tidligt implementerede måler og produkter. Tabellen ParamDef indeholder de parametre, der skal tildeles værdier for at konfigurere software for et produkt. Eksempler på parametre for Multical402 måler modulet er logge perioder, moduler og display opsætning. Tabellen herunder viser de informationer, der registreres for hver parameter. Figur 5.4: Database diagram for konfigurationsdata. Udtræk fra SQL Server Management Studio. Kolonne Beskrivelse Eksempel ID Et unikt parameter id. 1 ProductID Unik ID for det produkt parameter tilhører. ID for et bestemt måler modul Group ID for den gruppe parameteren tilhører. ID for konfiguration 1 Description Beskrivelse for parameter. Vælg display setup 33

Type Angivelse af type for parameter. Heltal, decimal, osv. ConstraintName Anvendes ikke. LangLabelID Tekst ID hvis der senere ønskes sprogstyring. Tabellen ParamValues indeholder de værdier, som en given parameter kan antage. Parametre kan som udgangspunkt konfigureres ved at vælge en pre-defineret værdi fra en liste eller indtaste en værdi i et felt. Liste: Tabellen indeholder en række pr. værdi, som parameteren kan antage. Indtastning: Tabellen vil indeholde præcis en række, hvor default værdi angives i pvalue. De informationer der registreres pr. værdi fremgår at tabellen herunder. Kolonne Beskrivelse Eksempel ID Et unikt id for værdien 1 paramdefid Fremmednøgle til ID feltet i ParamDef 1 pvalue Default værdi for parameter 01 pname Det navn der skal vises på skærmen 01 Cal. active energy LangLabelID Tekst ID hvis der senere ønskes sprogstyring. Tabellen ParamConstraints indeholder de egenskaber, der knyttes til en værdi for at konfiguratoren kan afgøre om en værdi er kompatibel med en given konfiguration. En egenskab består af et navn og en liste af værdier, der udtrykker at egenskaben er kompatibel med andre egenskaber med samme navn og en ikke tom fællesmængde af værdier. Hvis en egenskab er kompatibel med flere værdier adskilles disse ved en skråstreg som vist i tabellen herunder. Kolonne Beskrivelse Eksempel ID Unikt id for reglen 1 ParamValID Fremmednøgle til ID feltet i ParamValues 1 Name Navn/nøgle for egenskab LLL Properties Listen af værdier knyttet til denne egenskab 100/101/102/103 Valideringformer Tabelstrukturen i figur 5.4 kan anvendes til at udtrykke regler på følgende former: Moduler med kode 00 må kombineres med displays med koder 100, 101, 102, 103 Værdien for pulsedivisionsfaktor skal være heltal ml 100 og 10 000. Password skal bestå af mindst 6 karakter. Tabelstrukturen kan ikke anvendes til at udtrykke regler, der kræver specialbehandling i form af algoritmer til beregning, validering osv. F.eks. angivelse af skæringsdato på formen MM.DD, hvor MM=12 og DD=1-28. 34

Produktvarianter For hver produkt der skal udstyres med et software konfigurationsmodul, er der udviklet funktioner til at opfylde følgende use-cases: Opret/rediger konfiguration Slet konfiguration Hent konfiguration Hent konfigurationsdata Disse funktioner implementeres i SP, som f.eks. søger for at udtrække måler- og serienumre, samt opdatere MFG/PRO database med konfigurationsdata til ordrepreview. 5.2.1.2 Server delen Ud fra figur 5.3.1 kan jeg se, at der vil være nødvendigt at udvikle serverdelen i BOS med en kommunikations- og databasekomponent, for at understøtte et nyt konfigurationsmodul. Pakkediagram over Server delen Ved hjælp af Eclipse UML extention, kan man automatisk udtrække et pakkediagram over BOS Server kommunikation delen. Se figur 5.6. Det viser sig, at det er mange pakker, der indgår i kommunikation delen, og der er ret mange afhængigheder mellem disse pakker. Dette gøre det svært at udvælge, hvilke af disse pakker som skal indgår i en arkitektur pakkediagram. Figur 5.6 Pakkediagram over BOSServer komponent (kommunikation) delen. 35

5.2.1.3 Klient delen Klientkomponenten udgøres som vist i figur 5.3.1 af en grafisk brugergrænseflade, og en kommunikationskomponent samt konfigurator Configate. Der vil i forbindelse med implementering af et nyt konfigurationsmodul være nødvendigt at udvikle en grafisk brugegrænseflade. Jeg vil tage udgangspunkt i en af de eksisterende målere, og kigge nærmere på en pakke bosclient. view. congfig.mc402. Klassediagram over BOSClient view configuration til MC402 måler. Det automatiske udtræk af klassediagram fra Eclipse (figur 5.7) viser et meget kompleks figur, hvor der er mange forskellige klasser og afhængigheder mellem disse klasser. Figur 5.7 Klassediagram over BOS Client view configuration til MC402 måler. Udtræk fra Eclipse. 5.2.2 Opsummering Her ville beskrives de opsamlede erfaringer ved brugen af Data Gathering under analyse af den statiske del af systemet. I dette trin tog jeg udgangspunkt i opdelling af BOS system i 3 store deler, som jeg kunne identificere ud fra den hypotetiske deployment diagram. Som resultat af Manuale inspektion af source kode kunne jeg finde de relevante pakker. Indholdet af disse pakker var 36

analyseret videre for at identificere de underpakker, som skulle være relevante til rekonstruktionen. Jeg har anvendt navne konversioner til at analysere source koden af BOS systemet, for at finde de pakker og klasser, som har nogen med implementeringen af tidligere måler at gøre. Under analyse af Databasekomponent har jeg brugt Database model som min sourse viewpoint, for at danne et billede over datagrundlæget af BOS Frameworket konfigurationsdel. Pakke og klassediagrammer var buget ved hjælp af automatiske udtræk fra eklipse, og har vist sig at være alt for kompleks. På grund af de mange afhængigheder mellem klasser og pakker. Erfaringer med disse diagrammer viser, at der er behov for afgrænsninger i de udvalgte rekonstruktions områder. 5.2.3 Observation af applikationens opførsel For at danne sig et billede af hvordan konfiguration af en måler fungerer i praksis, har jeg debugget klient delen af en af de tidlige implementerede målere, for at se det tættere udspil imellem de forskellige komponenter i systemet. Det som jeg kunne observere var følgende: mange design pattern, som var brugt i koderne (Factory method, Polimorphi, Observer, Singleton, Iterator og mange flere) at arkitekturen for BOS framework er baseret på 3-lags klient/server model. at BOS frameworket løsning er baseret på klient-side validering, hvor datagrundlaget for konfigurationen indlæses i en Configurator, der efterfølgende kan validere de valg som brugeren træffer. Se sekvens diagram i figur 5.8. nogle objekter, som kommer fra en Generalt modul (Configate), og som tilknyttet til Client projekt i form af ekstern jar fil. Dette modul indgår i alle implementerede moduler. Datamodel over Generalt Configate modul var analyseret og beskrevet i form af Database diagram i 5.2.1.1. For at se på opbygning af dette modul, skulle jeg bruge et eksternt værktøj, som kunne udbakke jar fil, og viser java koden ud fra source kode. Til dette formål har jeg brugt et værktøj DJ Java Decompiler 3.1. Dette gav mig mulighed at se opbygning af dette modul. Ud fra java doc. Kan jeg læse at dette modul anvendes i forbindelse af validering af konfigurationer. 5.2.3.1 Struktur af Configate modelkomponent Klassediagram fra figur 5.8 viser de klasser, der anvendes til validering af konfigurationer i generelt Configate komponenten. Det fremgår af diagrammet, at et ItemGroup er associeret med et vilkårligt antal items, og at et item er associeret men et vilkårligt antal ItemProperties. 37

ItemGroup -id -groupid Item -id -description 1 0..* 1 0..* ItemProperty -key : String -value : String Figur 5.8 Model Klassediagram over generalt del af konfigurationsmodulet - Configate. ItemGroup Klassen ItemGroup indkapsler informationer om de parametre, der skal vælges for at konfigurere en måler. Klassen indeholder en unik id for gruppen, samt en id for den hovedgruppe, som parameteren er en del af, dvs. konfiguration 1 og 2, Variable værdier, målernummer eller logo. Eksempler på parametre er strømforsyning, display, moduler, log perioder mm. Item Klassen item modellerer en parameter, der repræsenterer en specifik værdi for den ItemGroup, den indgår i. Eksempler på parametre er 5,10 og 15 A parametre for strømforsyninger. ItemProperty Klassen ItemProperty indkapsler navn og værdi for en egenskab, der knyttes til en parameter. Klassen anvendes af Konfiguratoren til at validere konfigurationer. 5.2.3.2 Interaktioner under client-side validering i BOS system. Sekvens diagram i figur 5.9 viser interaktionerne mellem MC402 panel, ConfigurationPanel og ConfigurationComponent. Ifølge mappins reglerne, er klasserne ConfigurationPanel og ConfigurationComponent er de overordnede klasser af disse typer klasse hierarki. Metoden checkconfiguration() blive kaldt fra MC402 panelet, efter at brugeren har trykket OK til at konfigurere en MC402 måler, og den kaldes på alle de underpaneler, som indgår i MC402Panel, og som er af typen ConfigurationPanel. ConfigurationPanel kalder update() metode på alle de konfigurationskomponenter, som de lige nævnte paneler er bygget af, hvor de efterfølgende valideres efter specifikke regler, som var beskrevet i afsnit 5.2.1.1 under Valideringsregler. Figur 5.9. Sekvens diagram over client side validering af BOS system. 38

5.2.4 Erfaringopsamling I denne interaktion har jeg analyseret de komponenter, der indgår i et modul konfiguration af software for produkter hos Kamstrup A/S. Som resultat af denne analyse, fandt jeg ud af at BOS frameworket er baseret på 3-lags klient/server model, som består af 3 deler: Server, Klient og Databasedelen. Disse dele var analyseret nærmere, og ud fra dette analyse, suppleret med gammelt dokumentation, kunne jeg se hvordan disse dele er opbygget. F.eks. analyse af Databasekomponenet sammen med det Generale modul (Modulkomponent) har givet en godt billede over datagrundlæget af BOS Frameworket. De andre deler, som Server og Klient delen, var analyseret ved hjælp af automatisk udtræk af Pakke- og Klassedigram fra Eclipse, og de er svære at forstå på grund af høj detalje rigdom. De mange afhængigheder mellem klasser og pakker gør det svært at udvælge hvad der skal vises i en arkitektur klassediagram. Tabellen herunder viser de analyserede komponenter, sammen med den funktionalitet, der skal implementeres i forbindelse med udvikling af nyt konfigurationsmodul hos Kamstrup A/S. Komponent Database Server Klient Opgave 1. Definer SP 2. Impl. af SP 1. Impl. af comm og db 1. Design af GUI 2. Impl. Af comm og GUI 6. Anden interaktion Erfaringer fra den første interaktion har vist for store kompleksitet, og derfor har jeg besluttet at lave den anden interaktion, hvor jeg vil afgrænse analyse områder ved at tage udgangspunkt i usecases, som relaterer til konfiguration af en måler i BOS. 6.1 Rekonstruktion design Som resultat af Problem elicitation kunne jeg identificeres følgende funktionalitet af BOS system, som var relaterende til en overordnede funktionalitet, som er gennemførsel af en ordre, hvor der skulle gennemgås konfiguration af en af de eksisterende målere (konfigurationsmoduler): Konfiguration af hardware til en måler efter, at en bestemt måler (konfigurationsmodul) udvælges til konfiguration, så skal målerens hardware konfigureres, ud fra de udvælg, der eksistere til den pågældende måler. Konfiguration af software til en måler efter, at hardware komponenter til en måler er udvalgt, så skal software dele af måler konfigureres, ud fra de valg, der eksistere til den pågældende måler, og som afhænger af hardware valget. Gem måler data efter, at software valgt er gennemgået, så skal de valgte software data valideres i forhold til de konfigurationsregler, som findes i databasen til hver måler, og gemmes i de respektive steder i databasen. 39

6.1.1 Usecases På baggrund af denne opdeling af funktionalitet, har jeg defineret følgende usecases. Disse usecases repræsenterer den funktionalitet der ligger til grund for rekonstruktion. Usecase 1 Konfiguration af måler: Her skal man konfigurere den sammensatte måler, som skal sættes op af hardware og software delen. Denne usecase består af to usecases: 1.1 og 1.2. Usecase 1.1 - Konfiguration af hardware. (Se figur 7.1) Konfiguration af hardware til en måler giver mulighed at gennemgår et hardware konfiguration til en måler. Ud fra Typenummer til en måler, udvælges der koden for den enkelte felt fra en egenskabsliste som indeholder information om hvordan en given vare må sammensættes. Egenskabsliste viser koden og tekst for, hvad koden dækker over. Listen vedligeholdes i MFG/PRO, og rettelser og/eller ændringer til en vare skal laves der. Under oversigt område af skærmbillede kan man se hvilke valg man har foretaget i hardwarekonfigurationseditoren. Konfigurationsoversigten indeholder kode og tekst for typenummer og beskrivelse. Figur 7.1. Skærmbillede af Konfiguration af hardware til Multical402. Ved at trykke på Konfigurer knap, vil hardwarevalget være valideret i forhold de tilgængelige og valide software parametre. 40

Hvis data ikke kan valideres, præsenteres brugeren for en fejlbesked. Brugeren kan ikke komme videre før fejlene er rettet, eller hele hardwarekonfigurationen kan annulleres, ved tryk på Annuler knap. Usecase 1.2 - Konfiguration af Software. (Se figur 7.2) Konfiguration af Software til en måler giver mulighed at gennemgår et softwarekonfiguration til en måler. Gule felter viser at data kræves til dette felt. Der er nogle felter, der er pre-udfylde af BOS, og er f.eks. Multical402 type, som er taget fra hardwarekonfigurationen. Efterhånden som de enkelte felter blive udfyldt vil data blive valideret op imod Konfiguration databasen, som indeholder softwarevalideringsregler. Figur 7.2. Skærmbillede af Konfiguration af Software til Multical402 side 1. Usecase 2 - Gem konfiguration af måler. (Se figur 7.3) Fra side 2 (figur 7.3) af softwarekonfigurationen til en måler, kan man gemme måler konfiguration. De konfigurerede måler data skal valideres, til at kunne være gemt i en ordre i form af en ordre linje. Systemet vil forsøge at gemme data når brugeren forsøger at trykke på knap OK. Hvis systemet ikke kan gemme data, præsenteres brugeren for en fejlbesked. Brugeren kan ikke komme videre før fejlene er rettet, eller kan hele softwarekonfigurationen annulleres, ved tryk på Annuler knap. 41

Figur 7.3. Skærmbillede af Gem konfiguration af måler side 2. 6.1.2 Concept Determination De efterfølgende afsnit svarer til de 5 trin indenfor Concept Determination, som [van Deursen et.al.,2004] beskriver, og vil benyttes her til den anden interaktion. 6.1.2.1 Identify Potentially Useful Viewpoints I den første interaktion, for at definere target viewpoint, har jeg identificeret Modul viewpoint i form af klasse- og pakkediagrammer. Sammen med det, har jeg følt anbefalinger fra [Cristensen et al, 2004], at de mest betydelige krav til arkitekturen defineres og beskrives, svarende til mission i [IEEE 1471, 200]. Her, i den anden interaktion, vil jeg, udover Modul viewpoint, også benytte Component & Connector viewpoint, og Allocation viewpoint. Beskrivelse af disse kommer i afsnit 6.1.2.2. 6.1.2.2 Define Target viewpoints Som beskrevet i [van Deursen et al., 2004], er target views outputtet fra rekonstruktionsprocessen. Som var beskrevet i begyndelse af afsnit 6, har jeg besluttet, at afgrænse analyse områder i den anden interaktion med at tage udgangspunkt i usecases, som relaterer til konfiguration af en måler i BOS. Med udgangspunkt heri, bliver der opstillet følgende target viewpoints: Module viewpoint som var præsenteret og beskrevet under den første interaktion, se afsnit 5.1.4. 42

Component & Connector (C&C) viewpoint - som var præsenteret og beskrevet under den første interaktion, se afsnit 5.1.4. 6.1.2.3 Define Source viewpoints I den første interaktion, definition af source viewpoints var drevet af den information, som kunne udtrækkes automatisk ved hjælp af Eclipse UML værktøj, MCSQL værktøj, sammen med den Manual inspektion af source kode, og observering af system opførsel under udførelse. I den anden interaktion har jeg afgrænset rekonstruktions område til usecases, som var beskrevet og præsenteret tidligere i afsnit 6.1.1. De GUI komponenter, der repræsentere disse usecases, outputtet, som var genereret i den første interaktion i form af klasser og pakkerdiagrammer, og source kode base bliver til input til anden interaktion, og alt det er Source viewpoints her i den anden interaktion. 6.1.2.4 Define mapping rules Target Viewpoint Source Viewpoint Mapping Paskage diagram; Klassediagram Dir struktur Pakke struktur Java regler om pakker, Klasserne og pakker skal kun med, hvis de bruges af usecaserne Configuration klasser GUI klasser Projekt design konvention Simplificeret sekvensdiagram Pakke struktur, usecase implementering klasser Hierarkisk organisation af komponenter i pakker Førsteklasses repræsentation af kommunikation sti imellem komponenter 6.2 Reconstruktion execution Det følgende afsnit beskriver hvordan jeg har analyseret konfiguration af et tidlige implementerede målere. Jeg tage udgangspunkt i et Multical402 måler. 6.2.1 Data Gathering Ifølge Symphony, er formålet med Data gathering at indsamler data, som er nødvendige til rekonstruktionen fra systemets artefakter, hvor informationen om arkitekturen udtrækkes fra source kode, bygge filer, konfigurationsfiler. Disse data opsamles, og behandles i Knowledge Inference skrit. I dette skridt vil jeg lave sourcekode analyse, ud fra de usecases, som var beskrivet i 6.1.1. Jeg vil afgrænse source kode analyse område ved at kigge kun på de relevante til disse usecases paskages og klasser, som var defineret under mappings rules i afsnit 6.1.2.4. Sammen med det, vil jeg observere applikationen udførelse, læse source kode, bruge den information, som jeg har fået som input fra den første interaktion. 43

Source kode base analyse Som jeg fandt ud af i den første interaktion, består BOS framevorket af to projekter: BOS Server og Client, se figur 5.1. Jeg vil anvende reglen om navne konversioner, til at analysere Client source kode, for at finde de pakker og klasser, som hører til implementation af MC402 måler. Ved en manual analyse af Client projekt i Eclipse, fandt jeg følgende pakker, der indeholder navn mc402, og disse er: bosclent.view.congfig.mc402 bosclent.view.congfig.mc402.validator bosclent.view.congfig.mc402.modules bosclent.view.congfig.mc402.modules.modul1 Ved at ekspandere de enkelte pakker, kan jeg se indholdet af disse pakker, som det er vist i figur 7.4. Figur 7.4. Udsnit af pakkestruktur over Client delen, som er relevant til Multical402. Udtræk fra Eclipse Pakage Explorer. Ved en manuelt analysere af BOSServer projekt, kunne jeg finde de pakker, som er relevante til implementering af Multical402 måler, og som er: bosserver.communication.produkts.pks.db.mc402.module1 bosserver.communication.produkts.pks.db.mc402.modules. Sammen med det, ud fra inputtet fra den første interaktion om databasekomponent, og kommunikationskomponenten, kan jeg identificere pakker: bosserver.model.config bosserver.communication.produkts.pks.db, som initialisering af konfigurationsparametre, og implementerer databaseadgang, og. Indholdet af disse pakker vist i figur 7.5. 44

Figur 7.5. Udsnit af pakkestruktur over Server del, som er relevant til Multical402. Udtræk fra Eclipse Pakage Explorer. 6.2.2 Usecase 1 Konfiguration af måler Som var beskrevet i afsnit 6.1. konfigureres der en sammensatte måler, som skal sættes op af hardware og software delen. Følgende sammensætning er opdelt på to usecases: Konfiguration af Hardware og Konfiguration af Software til en måler. Disse var beskrevet i 6.1.1. For at finde ud af hvordan disse usecases er implementeret, har jeg manuelt analyseret de relevante dele af frameworket, som var præsenteret i afsnit 6.2.2. 6.2.2.1 Statisk information over serverkomponent til Multical402 Struktur Som resultat af den første interaktion fandt jeg ud, at det er nødvendigt at udvide serverdelen i BOS med en kommunikations- og databasekomponent, for at understøtte et nyt konfigurationsmodul. I denne interaktion har jeg udvalgt de konkrete klasser fra serverkomponenten, der indgår i database og kommunikationskomponenterne til Multacal402. Disse klasser bruges til at hente og gemme konfigurationen til Multical402, og derfor er relevant til begge usecases, som var introduceret i 6.1.1. Figur 7.6 viser et klassediagram over serverkomponent til Multical402. 45

Figur 7.6 Klassediagram over serverkomponenten (Multical402). Klasser I det følgende redegøres der kort for de enkelte klasser i klassediagrammet: ConfigurationServer interface, som definerer de metoder, som klienterne skal have adgang til i server modulet. Interfacet indeholder traditionelle Create-Update-Delete (CRUD) metoder, samt metoden getitemgroups, der returnerer en liste af parametergrupper med alle parametre og deres egenskaber. Sidstnævnte anvendes til validering af konfigurationer. ConfigurationServer_Impl klasse implementer interfacet ConfigurationServer. Klassen er associeret med ConfigurationDB klassen, der tilbyder adgang til underliggende database. Multical402DB tilbyder adgang til MC402 database kos Kamstrup, der anvendes til at gemme konfigurationer for ordrer, samt indeholder parameterstykliste mm. for konfigurationsmodulet til MC402 måler. Klassen er associeret med klassen Multical402ConfigurationTable. Multical402ConfigurationTable er en hjælpe klasse, som indeholder en Hashtable af Configuration objekter igennem nedarving fra ConfigurationTable, og metoder til at hente og sætte en liste af configurationsobjekter, som er placeret i dette Hashtable objekt. PKSServerManager opretter og styrer mc402 ConfigurationServer objekt, som handler alle forespørgsler til MC402 database. 6.2.2.2 Dynamisk information over serverkomponent til Multical402 Sekvensdiagrammet i figur 7.7 viser de overordnede interaktioner mellem objekterne i serverkomponenten, når en klient forsøger at hente en konfiguration til en Multical402 måler. Diagrammet viser kun kald imellem de overordnede klasser. Se reglerne for opbygning af dette diagram, under mapping rules. Det fremgår af diagrammet, at ConfigurationServer objekt blot forwarder kaldet til MC402DB objektet, der tilbyder adgang til Prods databasen igennem kald af superklasens BaseBD 46

getconfigparams metode. Herfra udstrækkes alle ItemGroups data til MC402 måler ved hjælp af SP BOS_GetConfigParams. Sekvence diagram viser ikke interaktionerne mellem BaseDB og det CallableStatement, der indkapsler BOS_GetConfigParams stored procedure. Til sidst gemmes de indhentede ItemsGroups data i en ItemValidator objekt på clienten, som kommer fra den generelle pakke, som var beskrevet i afsnittet 5.4.2. Figur 7.7: Simplificeret sekvensdiagram over de overordnede interaktioner mellem objekterne i serverkomponenten 6.2.2.3 Statisk information over klientkomponent til Multical402 Ud fra den første interaktion fandt jeg ud af, at klientkomponent for en konfigurationsmodul udføres, som vist i figurt 5.3.1, af en brugergrænseflade, en kommunikationskomponent og konfigurator Configate. Jeg har taget udgangspunkt i brugergrænseflade figur 7.1 fra afsnit 6.1.1. Her på skærmfigurt står, at det er Multical402 måler, der skal konfigureres. Derfor er det logisk at kigge på klasserne, som findes i bosclient.view.congfig.mc402 pakke, og bosclient.view.congfig pakke under Client delen, se figur 7.4. 47

Struktur af den grafiske grænseflade Figur 7.8: Klassediagram for brugegrænseflade Klassediagrammet fra figur 7.8 viser nogle af de klasser, der udgør den grafiske brugegrænseflade på klienten. Ved opbygning af dette diagram, anvendes reglerne om at udvalget af kun de klasser, der indgår i denne usecase til at vise på diagrammet. Her kommer hjælpeklaserne ikke med. Det fremgår af diagrammet, at ItemValidator klassen fra Configate komponenten er associeret med MC402Configurator klasse, og som instantieres af MC402Panel, dvs. validering af konfigurationer sker via MC402Configurator. Validator interfase fra bosclient.view.config.common package er associeret med MC402Configurator klasse. Klasserne CustomerLabelValidator, TarifValidator, MBUSAddressValidator, MeterNumberValidator, CustomerTextValidator, DefaultMeterNumberValidator, CustomerTextValidator er MC402 specifikke valideringsklasser. De arver fra Validator interfase, og udgør validering af den grafiske brugegrænseflade på klienten. Ud over disse klasser, er der en del af nogle generelle valideringsklasser, som anvendes ved validering af den grafiskebrugegrænseflade. Kompleksitet over disse klaser vises i figur 7.12 i form af et klassehierarki. Klassen MC402Panel udgør brugegrænseflade til Multical402, og er associeret med 8 instanser af ConfigurationPannel klassen, der generaliserer over de brugegrænsefladekomponenter, der anvendes til at konfigurere måleren. Klassen implementerer MainConfigurationPanel, som er et hoved klasse for alle konfigurations paneler, og holder styr på alle de 8 instanser, som initialiseres af MC402Panel. ConfigurationPanel klassen er en generel klasse, der specialiseres af klasserne vist i figur 7.9. 48

Hver af disse klasser udgør en brugegrænseflade komponent, der konfigurer hver deres del af MC402 måleren. Hver klasse mappes til en af de hovedgrupper, der er angivet i Item klassen i figur 5.8. Figur 7.9: Klassediagram over ConfigurationPanel. Der fremgå i figur 7.9, at ConfigurationPanel klassen indeholder metoder til at indsætte, hente, og validere konfigurationer for MC402 måler. Disse metoder er helt generelle, og behøver ikke overskrives af subklasserne. ConfigurationComponent er en abstrakte klasse, der indkapsler tilstand og adfærd for en komponent, der anvendes til at vælge parameter for en given parametergruppe. Klassen indeholder metoder til at indsætte og hente en given parameterkonfiguration, samt returnere id for gruppen der konfigureres af komponenten. De abstrakte metoder implementeres i konkrete subklasser, så disse kan anvendes til konfigurere en parameter. CompoBoxConfigurationComponent klassen anvendes til at vælge en bestemt parameter fra en compobox. Klassen udvider den generelle ConfigurationComponent klasse med de abstrakte metoder. TextFieldConfigurationComponent klassen anvendes til at angive en værdi for en bestemt parameter. Klassen implementerer, i lighed med klassen beskrevet ovenfor, de abstrakte metoder i den generelle ConfigurationComponent klasse. Feltet også acceptere heltal mellem en min og max værdi, såfremt den parameter, der skal konfigureres af komponenten indeholder egenskaber med navnet #MIN og #MAX. Der kan på parameterniveau knyttes en default værdi til feltet, ved at oprette en egenskab for parameter med navnet #DEFAULT. 6.2.2.4 Dynamisk information over klientkomponent til Multical402 Ved at afvikle BOSClient applikationen i Eclipse udvikling miljø, kunne jeg finde ud af hvordan applikationen fungerer. For at finde ud af, hvordan data til validering af skærmfigur 7.2, og 7.3 hentes, har jeg brugt debugger tools, som findes i Eclipseen. Dette har i første omgang resulteret i følgende sekvensdiagram. 49

Figur 7.10: Sekvensdiagram for MC402 klientkomponent (ind i loaddata metode på MC402Panel) Sekvensdiagram i figur 7.10 viser en delmængde af de interaktioner, der er mellem objekterne i MC402 brugergrænsefladen, når brugeren trykker på knap Konfigurer, se figurt 7.1. Når skærmfigur 7.2 skal vises frem, så kaldes der en update metode på MC402Panel objektet, som bliver kaldt videre på alle de paneler, der anvendes til at konfigurere måleren. Når update metoden invokeres på ConfigurationPanel objektet, søger dette for at opdatere alle konfigurationskomponenter, der er defineret i panelet, med de parametre, der er valide i forhold til den øjeblikkelige konfiguration. Ved styring af denne proces anvendes et Observer patern, som var identificeret tidlige under rekonstruktion, og som tillader et objekt til at uddelegere anmeldelser til andre objekter, uden at kalde direkte til disse objekter. Klassen MC402Panel er et Observer objekt (arver fra Observer interfacet), og indeholder en update metode, som kaldes når tilstanden af de observerede objekter (configurationer) ændre sig. Selve opdateringen sker, som vist i diagrammet, ved at ConfigurationPanel objektet finde id for hver komponent og efterfølgende udtrække en liste af valide parametre fra ItemValidator objektet. Denne metode sikrer, at der altid kun vises lovlige parameterværdier i de komponenter, hvor de enkelte parametre kan vælges/konfigureres. Hvis en bestemt item var tilknyttet til en af de Validator objekter, som er vist i figur 7.8, så bliver parameterværdi valideret af disse objekter i forhold til den valide visning. F.eks. formatering af double værdi, lukning eller åbning af et felt i forhold til, hvad der bliver valgt i et andet felt. Selv om sekvensdiagrammet i figur 7.10 viser interaktionerne for en specifik use-case Konfiguration af måler, er iterationerne i MC402Panel, MC402Configurator og ConfigurationPanel objekterne er så generel karakter, at de også anvendes, når der skal indsættes, hentes eller valideres konfigurationer. 50

6.2.3 Usecase 2 - Gem konfiguration af måler Som var tidlige beskrevet i afsnit 5.1.1, skal de konfigurerede måleres data valideres og gemmes i en ordre linje. Efter at man har været igennem usecase1, hvor hardware (usecase1.1) og software (usecase1.2) parametre var udvalgt, kan man gemme disse konfigurationer. Før dette kan lade sig gøre, skal alt det, der var valgt under konfigurationsforløbet valideres. 6.2.3.1 Validering af MC402 modul Tidlige i afsnittet 5.2.2.1 var der præsenteret to forskellige valideringsformer, som anvendes i BOSFameworket. Ved en af valideringsformer anvendes der tabelstrukturen (se beskrivelse i afsnittet 5.2.2.1), og ved anden, implementeres der speciale algoritmer i form af generelle valideringskomponenter, som kan genbruges af forskellige moduler. Dette vil f.eks. være gældende for algoritmerne til at validere formateringsmaske og skæringsdatoen. De valideringsklasser, som bruges af MC402 konfigurationsmodulet, findes i pakker bosclient.view.config.mc402.validator (MC402 specifikke), og i bosclient.view.config (generelle). Pakkediagram på figurt 7.11 viser de pakker der indgår i det samlede validering af MC402 modulet. Indholdet af pakken dk.unigate.configate.model er beskrevet i afsnit 5.4.2 under Struktur af Modelkomponent. Pakken bosserver.util indeholder to klasser, som holder styr på at sammenligne Hardware (ItemConfigurationComparator) og Software (SWConfigurationComparator)valgene før og efter konfigurationen. Relationerne mellem resterende pakker: bosclient.view.config.mc402.validator og bosclient.view.config er vist under klassediagrammet i figur 7.12. 51

Figur 7.11: Pakkediagram over valideringsdel af MC402 måler. Pakken bosclient.view.config.mc402 indeholder MC402 brugegrænseflade klasser, sammen med grænsefladen specifikke valideringsklaser, kontroller, og konfigurator klasse, som var nærmere beskrevet i afsnit 6.2.2.3 (se klassediagram i figur 7.8). Klassediagram i figur 6.13 viser de klasser, der udgør validering af den grafiske brugegrænseflade på klienten, i form af klassehierarki. Figur 7.12. Klassediagram over de klasser, der indgår i validering af MC402 konfigurationsmodul. Disse klasser holder styr på MC402 modul specifikke valideringer, som udføres på de forskellige felter, som indgår i software konfiguration, før de blive vist på skærmen. Fælles for disse klasser er, at de alle sammen implementer interface Validator fra bosclient.view.config.common. Denne 52