I den kommersielle verden bruker vi Java 2 Enterprise Edition (J2EE) for å løse forretningsproblemer, for å utvikle kommersiell programvare eller for å tilby kontraktstjenester til andre virksomheters prosjekter. Hvis et selskap ønsker å bygge et e-handelsnettsted ved hjelp av en flerlagsarkitektur, involverer det vanligvis ledere, arkitekter, designere, programmerere, testere og databaseeksperter gjennom hele utviklingssyklusen.
For at forskjellige parter skal jobbe effektivt og effektivt, trenger de ofte en programvareutviklingsprosess. Noen klassiske utviklingsprosesser inkluderer fossemodellen, rask applikasjonsutvikling (RAD) og ekstrem programmering. I denne artikkelen vil vi fokusere på en populær programvareteknikkprosess, Rational Unified Process (RUP). RUP gir en disiplinert tilnærming til å tildele oppgaver og ansvar til forskjellige roller. Målet sikrer at vi produserer programvare av høy kvalitet som oppfyller brukernes behov innenfor en forutsigbar tidsplan og et budsjett.
Jeg liker å bruke RUP for J2EE-utvikling av tre grunner. For det første er RUP arkitektur-sentrisk; den utvikler en kjørbar arkitekturprototype før den forplikter seg ressurser for fullskalautvikling. For det andre er RUP iterativ og komponentbasert. Arkitekturbaselinjen inkluderer ofte et rammeverk eller en infrastruktur som gjør det mulig å legge til komponenter gjennom iterasjoner for å tilpasse og utvide systemets funksjonalitet uten å påvirke resten av systemet. For det tredje bruker RUP et bransjestandard språk, UML, for å visuelt modellere systemets arkitektur og komponenter. RUP har fire forskjellige utviklingsfaser: begynnelse, utdyping, konstruksjon og overgang. Denne artikkelen dekker imidlertid åtte viktige aktiviteter involvert i J2EE-utvikling fra et teknisk perspektiv på en måte som opprettholder det arkitektoniske fokuset.
I. Kravsanalyse
Kravanalysen beskriver hva systemet skal eller ikke bør gjøre, slik at utviklere og kunder kan lage en innledende forretningskontrakt. Du kan dokumentere funksjonelle krav i forretningskonsepter, domeneglister, brukstilfeller og UI-modeller. Ikke-funksjonelle krav, som ytelse og transaksjoner, spesifiserer du i et tilleggskravdokument. Du kan lage UI-modellen på høyt nivå på papir eller i HTML, avhengig av hvor dypt du er involvert i prosjektet.
Figur 1 viser to eksempler på brukstilfeller for et typisk e-forretningssystem. De Se bestilling use case forteller oss at en bruker logger seg på et system via et webgrensesnitt, ser en ordreliste og klikker på en lenke for å se bestillingsdetaljer for en bestemt innkjøpsordre. De addLineItems use case forteller oss at brukeren blar i en produktkatalog, velger interessante produkter og legger dem til i en innkjøpsordre.
II. Objektorientert analyse
Analytikere genererer problemdomenemodeller: klasser, objekter og interaksjoner. Analysen din skal være fri for tekniske detaljer eller implementeringsdetaljer og bør inneholde en ideell modell. Objektanalyse hjelper deg med å forstå problemet og tilegne deg kunnskap om problemdomenet. Du må opprettholde en ren domenemodell uten tekniske detaljer fordi en forretningsprosess endres mye saktere enn informasjonsteknologi.
Disse to første trinnene - kravanalyse og objektorientert analyse - er ikke J2EE-spesifikke; de er ganske generiske for mange objektorienterte metoder. Figur 2 viser en høynivå objektanalysemodell for en dyrebutikk-prøveprogram. Det illustrerer hovedkonseptene vi identifiserte fra brukstilfeller for kravanalyse. Vi modellerer disse konseptene til objekter og identifiserer deres forhold.
Resultatet av krav og objektanalyser er inngangspunktet for J2EE-arkitekturutvikling. For å utvikle en arkitektur velger du et vertikalt stykke - ofte en kritisk del, for eksempel objektmodellen for bestillingsdomenet - for objektdesign, implementering, testing og distribusjon. (Et vertikalt stykke, et RUP-konsept, er en liten del av et system. Utgangspunktet er en delmengde av brukstilfeller, som vist i figur 1, og domeneanalysemodeller, som vist i figur 3. Implementeringen av et vertikalt stykke resulterer i et fullt funksjonelt minisystem som inkluderer alle nivåene, for eksempel UI-nivå JavaServer Pages (JSP), mellomnivå forretningsobjekter som Enterprise JavaBeans (EJB), og ofte backend-databaser.) Du kan bruke erfaringer fra prototype til domeneobjekter, og la den kunnskapen tjene som en designretningslinje for objektdesignfasen.
