Filosofier for implementeringstilgang
vandfaldstilgang
Vandfaldstilgangen til implementering af en applikation kræver, at en designer rådfører sig med en eller flere repræsentanter for slutbrugerorganisationen og skriver alle applikationens specifikationer ned. Typisk kommer specifikationer i et sæt funktionelle dokumenter eller use cases, skrevet på en sådan måde, at slutbrugeren nemt kan læse og forstå dokumenterne.
Slutbrugeren underskriver disse dokumenter, og dokumenterne indsamles derefter af det tekniske designteam, der designer applikationen, og skaber forskellige artefakter såsom klassemodeldiagrammer, tilstandsdiagrammer, aktivitetsdiagrammer og datamodeller. Målet med denne fase er at skrive alt så detaljeret, at en udvikler ikke vil have problemer med at skabe den nødvendige kode. Der er en formel overdragelse af designet til udviklingsteamet og til testteamet. Efter levering starter udviklingsteamet kodning og testteamet bruger det tekniske design i kombination med use cases til at skabe testcases og testscenarier.
Efter at udviklingsteamet er færdig med kodningen, overdrages koden til testteamet. Testteamet udfører de test, det har designet ud fra kravene og det detaljerede design. Eventuelle problemer vil blive løst af udviklingsteamet. Når test- og fikseringsprocessen er afsluttet, leveres applikationen til slutbrugeren til accepttest. Slutbrugeren udfører en sidste kontrol for at se, om applikationen overholder de oprindelige krav. Hvis han bliver godkendt, godkender han det færdige produkt, og projektet er afsluttet. Efter at udviklingsteamet er færdig med kodningen, overdrages koden til testteamet.
Testteamet udfører de test, det har designet ud fra kravene og det detaljerede design. Eventuelle problemer vil blive løst af udviklingsteamet. Når test- og fikseringsprocessen er afsluttet, leveres applikationen til slutbrugeren til accepttest. Slutbrugeren udfører en sidste kontrol for at se, om applikationen overholder de oprindelige krav. Hvis han bliver godkendt, godkender han det færdige produkt, og projektet er afsluttet. Efter at udviklingsteamet er færdig med kodningen, overdrages koden til testteamet. Testteamet udfører de test, det har designet ud fra kravene og det detaljerede design.
Eventuelle problemer vil blive løst af udviklingsteamet. Når test- og fikseringsprocessen er afsluttet, leveres applikationen til slutbrugeren til accepttest. Slutbrugeren udfører en sidste kontrol for at se, om applikationen overholder de oprindelige krav. Hvis han bliver godkendt, godkender han det færdige produkt, og projektet er afsluttet.
Slutbrugeren udfører en sidste kontrol for at se, om applikationen overholder de oprindelige krav. Hvis han bliver godkendt, godkender han det færdige produkt, og projektet er afsluttet. Slutbrugeren udfører en sidste kontrol for at se, om applikationen overholder de oprindelige krav. Hvis han bliver godkendt, godkender han det færdige produkt, og projektet er afsluttet.
Et projekt kan have flere eller færre faser, når man bruger vandfaldstilgangen, men nøglefunktionen er en meget formel start og afslutning på hver fase med meget formelle leverancer.
Fordelen ved vandfaldstilgangen er, at ansvaret for det team, der er ansvarligt for hver fase, er større. Det er klart, hvad de skal levere, hvornår de skal levere det, og hvem de skal levere det til. Ofte behøver udviklingsteamet ikke at interagere med brugeren. Dette kan være meget nyttigt, når du outsourcer udvikling til et andet land.
Den største ulempe ved vandfaldstilgangen er, at i et miljø, hvor alt er organiseret på en meget formel måde, falder fleksibiliteten til at reagere på ændringer. Selv flytning skal organiseres. Meget få virksomheder ser ud til at gøre dette effektivt, hvilket ofte resulterer i en betydelig stigning i faste omkostninger. For at styre omkostningerne ved et projekt forsinker nogle virksomheder endda eventuelle ændringer af kravene, indtil den første applikationslevering, hvilket effektivt leverer en applikation, der ikke opfylder slutbrugerens behov.
agil udvikling
Mange langvarige softwareudviklingsprojekter gik over budgettet og leverede ikke produktet til tiden. Udgangspunktet for den agile softwareudviklingsfilosofi er at minimere risikoen ved at udvikle software i korte tidsbokse, kaldet iterationer, som typisk varer fra en til fire uger. Hver iteration er som sit eget miniaturesoftwareprojekt og inkluderer alle de opgaver, der er nødvendige for at frigive tilvæksten af ny funktionalitet: planlægning, kravanalyse, design, kodning, test og dokumentation. Selvom en iteration muligvis ikke tilføjer nok funktionalitet til at garantere produktfrigivelse, sigter et agilt softwareprojekt på at kunne frigive ny software i slutningen af hver iteration. I slutningen af hver iteration revurderer teamet projektets prioriteter.
Målet med agil softwareudvikling er at opnå kundetilfredshed gennem hurtig og kontinuerlig levering af nyttig software; altid tilstræbt at bygge det, kunden har brug for; byder velkommen i stedet for at modsætte sig sene ændringer af kravene; regelmæssigt tilpasse sig skiftende omstændigheder; at have et tæt og dagligt samarbejde mellem iværksættere og udviklere, hvor ansigt-til-ansigt samtale er den bedste kommunikationsform.
Den største fordel ved agil softwareudvikling er fleksibiliteten i håndteringen af ændringer, der altid sigter mod at levere i overensstemmelse med virksomhedens behov. Ulempen er selvfølgelig en stigning i kompleksiteten af styring af omfang, planlægning og budgettering. En anden almindelig risiko er begrænset opmærksomhed på (teknisk) dokumentation.
Inkrementel udvikling
Inkrementel softwareudvikling er en blanding af agil og vandfaldsudvikling. En applikation er designet, implementeret og testet trinvist, så hvert trin kan leveres til slutbrugeren. Projektet er ikke afsluttet, før det sidste trin er afsluttet. Det sigter mod at forkorte kaskaden ved at definere mellemliggende trin og bruge nogle af fordelene ved agil udvikling. Baseret på feedback modtaget på en tidligere stigning, kan der foretages justeringer ved levering af den næste stigning. Den næste stigning kan bestå af ny kode samt ændringer af tidligere tilvejebragt kode.
Fordelen er, at formaliteterne forbliver på plads, men forandringsledelse bliver lettere. Omkostningerne ved at teste og implementere en applikation flere gange vil være større end at gøre det én gang.
Program Flow Control
At vælge en tilgang til programflowstyring er en meget arkitektonisk opgave. Målet er at skabe en blueprint af din applikation, hvor alt ser ud til at have sin egen plads, når du først begynder at tilføje funktionalitet og kode. Hvis du nogensinde har gennemgået eller skrevet kode af høj kvalitet, forstår du dette princip.
Organisator kode
Det første trin i design af programflow er at organisere koden ved at etablere et sæt regler for at hjælpe med at skabe en blueprint eller skitse af applikationen. Vedligeholdelse, fejlretning og fejlretning bliver nemmere, fordi koden er placeret på et logisk sted. Når du har gjort det grundlæggende, kan du vælge en tilgang til implementering af din applikations logik.
Designmønstre bør spille en vigtig rolle i design af programflowkontrol. I årenes løb er der skrevet meget kode, og mange løsninger er designet til tilbagevendende problemer. Disse løsninger er lagt i designmønstre. Anvendelse af et designmønster på et almindeligt softwaredesignproblem vil hjælpe dig med at skabe løsninger, der er let genkendelige og kan implementeres af dine kolleger. Unikke problemer vil stadig kræve unikke løsninger, men du kan bruge designmønstre til at guide dig til at løse dem.
Oprettelse af projektet
lag
Det første skridt er at overveje logiske lag. Bemærk, at lag ikke er det samme som lag, ofte forvirrede eller endda betragtes som det samme.
lag kontra lag
Lag handler om at skabe grænser i din kode. Det øverste lag kan have referencer til kode i lag under, men et lag kan aldrig have reference til kode i et lag over. Niveauer refererer til den fysiske fordeling af niveauer på tværs af flere computere. For eksempel, i en tre-lags applikation er brugergrænsefladen designet til at køre på en stationær computer, applikationslogikken er designet til at køre på en applikationsserver, og databasen kører på en databaseserver med dedikerede data og koden i hver lag kan bestå af flere lag.
Figur 8-1: Grundlæggende tre-lags organisation
Lag refererer til abstraktionsniveauer. Lagene vist i figur 8-1 gælder for de fleste applikationer. Disse niveauer omtales også som de tre hovedlag og kan have forskellige andre navne. Som regel kan kode i præsentationslaget kalde tjenester i applikationslogiklaget, men applikationslogiklaget må ikke kalde metoden i præsentationslaget. Præsentationslaget bør aldrig direkte kalde dataadgangslaget, da dette ville omgå ansvaret implementeret af applikationslogiklaget. Dataadgangslaget bør aldrig kalde applikationslogiklaget.
Lag er blot en abstraktion, og sandsynligvis den nemmeste måde at implementere lag på er at oprette mapper i dit projekt og tilføje kode til den relevante mappe. En mere nyttig tilgang ville være at placere hvert lag i et separat projekt og dermed skabe separate samlinger. Fordelen ved at placere din applikationslogik i en bibliotekssamling er, at den giver dig mulighed for at oprette enhedstests ved hjælp af Microsoft Visual Studio eller NUnit for at teste logikken. Det skaber også fleksibilitet til at vælge, hvor hvert lag skal installeres.
Fysiske lag
I en virksomhedsapplikation vil du forvente at have flere klienter til den samme logik. Faktisk er det, der gør en applikation til en virksomhedsapplikation, at den vil blive implementeret i tre lag: klient, applikationsserver og databaseserver. Microsoft Office Access-applikationen, der er oprettet af din virksomheds salgsafdeling, er, selvom den er meget vigtig for salgsafdelingen, ikke en virksomhedsapplikation.
Bemærk, at applikationslogik og dataadgangslag ofte implementeres sammen på applikationsserveren. En del af udformningen af projektet er at vælge, om man vil få adgang til applikationsserveren ved hjælp af eksterne .NET- eller webtjenester. Uanset hvad du vælger, tilføjer du noget kode for nemt at få adgang til fjerntjenester i præsentationslaget. Hvis du bruger webtjenester til at få adgang til tjenester på din applikationsserver, vil Visual Studio .NET gøre arbejdet for dig og generere proxykoden, hvilket automatisk giver en implementering af fjernproxymønsteret.
Tilføjelse af mønstre til lag
De tre grundlæggende lag giver et overblik på højt niveau. Lad os tilføje nogle strukturelle mønstre for at skabe en robust virksomhedsarkitektur. Resultatet er vist i figur 8-2.
Fokuser på applikationslogiklaget. Figur 8-2 viser, at adgang til applikationslogik bruger facademønsteret. En facade er et objekt, der giver en forenklet grænseflade til en større krop af kode, såsom et klassebibliotek. En facade kan reducere ekstern kodeafhængighed af den indre funktion af et bibliotek, fordi det meste kode bruger facaden, og dermed tillader mere fleksibilitet i systemudvikling. For at gøre dette vil facaden give en grovkornet grænseflade til en samling af finkornede genstande.
beslutningsflow
Programflowkontrol, også kendt som beslutningsflow, vedrører, hvordan du designer tjenesterne i dit applikationslogiklag eller, som du så i det foregående afsnit, hvordan du designer metoderne i din facade.
Der er to tilgange til at organisere dine tjenester:
- handlingsorienteret
- statsdrevet
Handlingsorienteret tilgang
Ved at organisere tjenester baseret på brugerhandlinger implementerer du applikationslogik ved at tilbyde tjenester, som hver håndterer en specifik anmodning fra præsentationslaget. Dette er også kendt som transaktionsscriptmønsteret. Denne tilgang er populær, fordi den er enkel og ser meget naturlig ud. Eksempler på metoder, der følger denne tilgang, er BookStoreService.AddNewOrder(Order order) og BookStoreService.CancelOrder(int orderId).
Den logik, der er nødvendig for at udføre handlingen, implementeres meget sekventielt i metoden, hvilket gør koden meget læsbar, men også sværere at genbruge. Brug af yderligere designmønstre, såsom bordmodulmønsteret, kan hjælpe med at øge genanvendeligheden.
Statsdrevet tilgang
Det er også muligt at implementere ansøgningens beslutningsflow på en langt mere statsorienteret måde. Tjenester, der tilbydes af applikationsserveren, er mere generiske, for eksempel BookStoreService.SaveOrder(Ordreordre). Denne metode vil undersøge status for ordren og beslutte, om der skal tilføjes en ny ordre eller annulleres en eksisterende ordre.
Datastrukturprojekter
Du skal træffe flere valg, når du designer dine datastrukturer. Det første valg er datalagringsmekanismen, det andet er den tilsigtede brug af dataene, og det tredje er versionskrav. Der er tre måder at se på design af datastrukturer:
- Tjenesterne tilbyder data; data er en afspejling af relationsdatabasen.
- Data skal kortlægges til objekter, og tjenester giver adgang til objekter.
- De data, der tilbydes af tjenester, skal være skemabaserede.
At vælge en af de tre som grundlag for din dataflowstruktur bør ske på et tidligt stadium af designprocessen. Mange virksomheder har en virksomhedsretningslinje, der påbyder en af tre muligheder på alle projekter, men hvor det er muligt, bør du revurdere mulighederne for hvert projekt og vælge den optimale tilgang til det aktuelle projekt.
Valg af en datalagringsmotor
Når du designer din applikation, skal du uden tvivl designe en form for datalager. Følgende lagre og former for datalagring er tilgængelige:
- Optage
- app.config-fil
- xml-filer
- almindelige tekstfiler
- Database
- beskedkø
Hver butik har sine egne unikke karakteristika og kan skræddersyes til specifikke krav.
Design af dataflowet
Dataflow ved hjælp af ADO.NET
Ved at implementere datacentrerede tjenester i applikationslogiklaget vil du designe dit dataflow ved hjælp af ADO.NET. Klassebiblioteket .NET Framework giver et omfattende applikationsprogrammeringsgrænseflade (API) til at manipulere data i administreret kode. Benævnt ADO.NET, kan API'en findes i System.Data-navneområdet. Fuldstændig adskillelse af databærere og datalagre er en vigtig designfunktion i ADO.NET. Klasser som DataSet, DataTable og DataRow er designet til at gemme data, men bevarer ingen viden om, hvor dataene kom fra. De betragtes som datakildeagnostiske. Et separat sæt klasser, såsom SqlConnection, SqlDataAdapter og SqlCommand, sørger for at oprette forbindelse til en datakilde, hente data og udfylde DataSet, DataTable og DataRow. Disse klasser er placeret i undernavneområder som System.Data.Sql, System.Data.OleDB, System.Data.Oracle og så videre. Afhængigt af hvilken datakilde du vil oprette forbindelse til, kan du bruge klasser i det rigtige navneområde, og afhængigt af omfanget af det produkt, du bruger, vil du opdage, at disse klasser tilbyder mere eller mindre funktionalitet.
Da datasættet ikke er forbundet til datakilden, kan det bruges med stor succes til at styre datastrømmen i en applikation. Figur 8-5 viser dataflowet, når du gør dette.
Lad os tage et kig på dette projekt og forestille os, at nogen har logget ind på din boghandel og bestilt tre bøger. Præsentationslaget administrerede indkøbskurvens tilstand. Kunden er klar til at afgive ordren og har givet alle nødvendige data. Han vælger at sende ordre. Websiden transformerer alle data til et datasæt, der indeholder to datatabeller, en for ordre og en for ordre; indsætter en DataRow for ordren; og indsætter tre DataRows for ordrelinjerne. Websiden viser derefter disse data tilbage til brugeren igen, binder datakontroller mod datasættet og spørger Er du sikker? Brugeren bekræfter anmodningen, og den sendes til applikationens logiske lag. Applikationslogiklaget tjekker datasættet for at se, om alle påkrævede felter har en værdi, og udfører en kontrol for at se, om brugeren har mere end 1000 US$. 00 på udestående regninger. Hvis alt går vel, sendes datasættet til dataadgangslaget, som forbinder til databasen og genererer indsæt-sætninger fra datasætoplysningerne.
At bruge datasættet på denne måde er en hurtig og effektiv måde at bygge en applikation på og bruge kraften i Framework Class Library og ASP.NET's evne til at binde data til forskellige kontroller såsom GridView mod et datasæt. I stedet for at bruge simple DataSet-objekter kan du bruge Typed DataSet-objekter og forbedre kodningsoplevelsen ved at implementere kode i præsentationslaget såvel som applikationslogiklaget. Fordelen ved denne fremgangsmåde er også ulempen ved fremgangsmåden. Små ændringer i datamodellen fører ikke nødvendigvis til, at mange metoder skal ændre deres signaturer. Så med hensyn til vedligeholdelse fungerer dette rigtig godt. Hvis du husker, at præsentationslaget ikke nødvendigvis er en brugergrænseflade, kan det også være en webservice. Og hvis du ændrer definitionen af datasættet, måske fordi du omdøber et felt i databasen, så ændrer du den kontrakt, som webtjenesten abonnerer på. Som du kan forestille dig, kan dette føre til nogle væsentlige problemer. Dette scenarie fungerer godt, hvis præsentationslaget kun er en brugergrænseflade, men for grænseflader til eksterne systemer eller komponenter vil du gerne skjule din applikations indre funktion og transformere data til noget andet end en direkte klon af din datamodel og du vil oprette dataoverførselsobjekter (DTO'er).
Dataflow ved hjælp af objektrelationel mapping
Dataflow ved hjælp af ADO.NET er en meget datacentreret tilgang til styring af dataflow. Data og logik er diskrete. Den anden ende af spektret tager en mere objektorienteret tilgang. Her oprettes klasser for at gruppere data og adfærd. Målet er at definere klasser, der efterligner de data og adfærd, der findes i det forretningsdomæne, som applikationen blev oprettet for. Resultatet omtales ofte som et forretningsobjekt. Samlingen af forretningsobjekter, der udgør applikationen, kaldes domænemodellen. Nogle udviklere hævder, at en rig domænemodel er bedre til at designe mere kompleks logik. Det er svært at bevise eller modbevise en sådan påstand. Bare vid, at du har et valg, og det er op til dig at træffe det.
Figur 8-6 viser et dataflow svarende til figur 8-5, bortset fra at du nu har tilføjet det relationelle kortlægningslag for objekter og erstattet DataSet-objekterne med forskellige databærere.
Gør nu det samme trin for trin som før; forestil dig, at nogen havde forbindelse til din boghandel og bestilte tre bøger. Præsentationslaget administrerede indkøbskurvens tilstand. Kunden er klar til at afgive ordren og har givet alle nødvendige data. Han vælger at sende ordre. Websiden omdanner alle data til en DTO, der indeholder data for én ordre og med tre ordrelinjer, der skaber objekterne efter behov. Websiden viser disse data tilbage til brugeren igen, databinding kontrollerer mod DTO'en ved hjælp af ObjectDataSource i ASP.NET 2.0 og spørger Er du sikker? Brugeren bekræfter valget, og DTO'en sendes til ansøgningens logiske lag. Applikationslogiklaget transformerer DTO'en til et forretningsobjekt af typen Order med en egenskab til at indeholde tre OrderLine-objekter. Ordremetoden. Validate() kaldes for at validere ordren og verificere, at alle påkrævede felter har en værdi, og der foretages en kontrol for at identificere, om brugeren har mere end R$ 1.000,00 i afventende sedler. For at gøre dette vil ordren kalde Order.Customer.GetOutstandingBills(). Hvis alt er godt, kaldes Order.Save() metoden. Forespørgslen vil passere gennem det objektrelationelle kortlægningslag, hvor forespørgslen og rækkerne af forespørgslen er afbildet til en datatabel i et datasæt, og datasættet videregives til dataadgangslaget, som forbinder til databasen og genererer insert-sætninger fra oplysningerne i datasættet. Der er selvfølgelig mange måder, hvorpå objektrelationel kortlægning kan forekomme, men ikke alle vil inkludere transformation til et DataSet. Nogle vil oprette insert-sætningen direkte, men stadig bruge dataadgangslaget til at udføre denne sætning.
Som du kan se, finder nogle transformationer sted. Brugen af DTO'er er nødvendig, fordi et forretningsobjekt implementerer adfærden, og adfærden kan ændres. For at minimere indvirkningen af disse ændringer på præsentationslaget skal du transformere dataene ud af forretningsobjektet og til et dataoverførselsobjekt. I Java omtales dataoverførselsobjektet ofte som værdiobjektet.
En stor fordel ved at arbejde med forretningsobjekter er, at det virkelig hjælper at organisere din kode. Hvis du ser tilbage på et stykke kompleks logik, er det normalt meget læsbart, fordi der er meget lidt VVS-kode. Ulempen er, at de fleste datalagre stadig er relationelle, og at kortlægge forretningsobjekter til relationelle data kan blive ret komplekst.
skemabaserede tjenester
Du har lige set to modsætninger, når det kommer til at styre datastrømmen. Mange variationer er mulige. En almindelig variant er den variant, hvor et datasæt bruges som den grundlæggende databærer af brugergrænsefladen til lagring af data, men separate skemaer (DTO'er) bruges til webtjenester kaldet fra andre systemer. Applikationslaget transformerer relationelle data til et foruddefineret skema. Den største fordel ved dette er, at enhver applikation, der refererer til tjenesten, ikke afhænger af nogen form for intern implementering af komponenten. Dette giver mulighed for mere fleksibilitet i versionering, bagudkompatibilitet af grænseflader og mulighed for at ændre komponentens implementering uden at ændre tjenestens grænseflade.
Du kan selvfølgelig bruge forretningsobjekter i webapplikationen og omgå DTO-transformationen, men dette fungerer normalt kun godt, hvis applikationslogikken implementeres sammen med webapplikationen. Husk at for at kalde Order.Save() skal du have en databaseforbindelse. Om dette er ønskeligt er op til dig og sandsynligvis din sikkerhedsdirektør.