Programmering

Gå ind i J2EE-arkitekturen og processen

I den kommercielle verden bruger vi Java 2 Enterprise Edition (J2EE) til at løse forretningsproblemer, til at udvikle kommerciel software eller til at levere kontraktydelser til andre virksomheders projekter. Hvis en virksomhed ønsker at opbygge et e-handelswebsted ved hjælp af en flerlagsarkitektur, involverer det normalt ledere, arkitekter, designere, programmører, testere og databaseeksperter gennem hele udviklingslivscyklussen.

For at forskellige parter kan arbejde effektivt og effektivt, har de ofte brug for en softwareudviklingsproces. Nogle klassiske udviklingsprocesser inkluderer vandfaldsmodellen, hurtig applikationsudvikling (RAD) og ekstrem programmering. I denne artikel vil vi fokusere på en populær software engineering proces, Rational Unified Process (RUP). RUP giver en disciplineret tilgang til at tildele opgaver og ansvar til forskellige roller. Målet sikrer, at vi producerer software af høj kvalitet, der opfylder brugernes behov inden for en forudsigelig tidsplan og et budget.

Jeg kan godt lide at bruge RUP til J2EE-udvikling af tre grunde. For det første er RUP arkitekturcentreret; den udvikler en eksekverbar arkitekturprototype, inden den begår ressourcer til fuldskalaudvikling. For det andet er RUP iterativ og komponentbaseret. Arkitekturbaselinjen inkluderer ofte en ramme eller infrastruktur, der letter tilføjelse af komponenter gennem iterationer for at tilpasse og udvide et systems funktionalitet uden at påvirke resten af ​​systemet. For det tredje anvender RUP et industristandard sprog, UML, til visuelt at modellere et systems arkitektur og komponenter. RUP har fire forskellige udviklingsfaser: start, udarbejdelse, konstruktion og overgang. Denne artikel dækker dog otte vigtige aktiviteter involveret i J2EE-udvikling fra et teknisk perspektiv på en måde, der opretholder det arkitektoniske fokus.

I. Kravsanalyse

Kravsanalysen beskriver, hvad systemet skal eller ikke skal gøre, så udviklere og kunder kan oprette en indledende forretningskontrakt. Du kan dokumentere funktionelle krav i forretningskoncepter, domæne ordlister, use cases og UI-modeller. Ikke-funktionelle krav, såsom ydeevne og transaktioner, specificerer du i et supplerende kravsdokument. Du kan oprette UI-mockup på højt niveau på papir eller i HTML afhængigt af hvor dybt du er involveret i projektet.

Figur 1 viser to eksempler på anvendelse af et typisk e-forretningssystem. Det se ordre use case fortæller os, at en bruger logger ind på et system via en webgrænseflade, ser en ordreliste og klikker på et link for at se ordredetaljer for en bestemt indkøbsordre. Det addLineItems use case fortæller os, at brugeren gennemsøger et produktkatalog, vælger interessante produkter og føjer dem til en indkøbsordre.

II. Objektorienteret analyse

Analytikere genererer problemdomænemodeller: klasser, objekter og interaktioner. Din analyse skal være fri for tekniske eller implementeringsoplysninger og skal indeholde en ideel model. Objektanalyse hjælper dig med at forstå problemet og tilegne dig viden om problemdomænet. Du skal opretholde en ren domænemodel uden tekniske detaljer, fordi en forretningsproces ændrer sig meget langsommere end informationsteknologier.

Disse første to trin - kravanalyse og objektorienteret analyse - er ikke J2EE-specifikke; de er ret generiske for mange objektorienterede metoder. Figur 2 viser en objektanalysemodel på højt niveau af en prøveudtagning af en dyrebutik. Det illustrerer de vigtigste begreber, vi identificerede fra brugssager til kravanalyse. Vi modellerer disse begreber i objekter og identificerer deres forhold.

Resultatet af krav og objektanalyser er udgangspunktet for J2EE-arkitekturudvikling. For at udvikle en arkitektur vælger du et lodret stykke - ofte en kritisk del, såsom ordendomæne-objektmodellen - til objektdesign, implementering, test og implementering. (Et lodret stykke, et RUP-koncept, er en lille del af et system. Udgangspunktet er en delmængde af brugssager, som vist i figur 1, og domæneanalysemodeller, som vist i figur 3. Implementeringen af ​​et lodret stykke resulterer i et fuldt funktionelt mini-system, der inkluderer alle niveauer, såsom UI-tier JavaServer Pages (JSP'er), mellemliggende forretningsobjekter såsom Enterprise JavaBeans (EJB'er) og ofte backend-databaser.) Du kan anvende erfaring opnået fra prototype til domæneobjekter, og lad denne viden tjene som en designretningslinje for objektdesignfasen.