Ohjelmointi

Astu J2EE-arkkitehtuuriin ja prosessiin

Kaupallisessa maailmassa käytämme Java 2 Enterprise Editionia (J2EE) liiketoiminnan ongelmien ratkaisemiseen, kaupallisten ohjelmistojen kehittämiseen tai sopimuspalvelujen tarjoamiseen muiden yritysten projekteille. Jos yritys haluaa rakentaa sähköisen liiketoiminnan verkkosivuston monitasoisella arkkitehtuurilla, siihen osallistuu yleensä johtajia, arkkitehteja, suunnittelijoita, ohjelmoijia, testaajia ja tietokanta-asiantuntijoita koko kehityksen elinkaaren ajan.

Jotta eri osapuolet voivat työskennellä tehokkaasti, he tarvitsevat usein ohjelmistokehitysprosessia. Joitakin klassisia kehitysprosesseja ovat vesiputousmalli, nopea sovelluskehitys (RAD) ja äärimmäinen ohjelmointi. Tässä artikkelissa keskitymme suosittuun ohjelmistosuunnitteluprosessiin, Rational Unified Process (Rational Unified Process). RUP tarjoaa kurinalaista lähestymistapaa tehtävien ja vastuiden osoittamiseen eri rooleille. Sen tavoite varmistaa, että tuotamme korkealaatuisia ohjelmistoja, jotka vastaavat käyttäjien tarpeisiin ennustettavissa olevassa aikataulussa ja budjetissa.

Haluan käyttää RUP: ta J2EE-kehitykseen kolmesta syystä. Ensinnäkin RUP on arkkitehtuurikeskeinen; se kehittää suoritettavan arkkitehtuurin prototyypin ennen resurssien sitouttamista täysimittaiseen kehittämiseen. Toiseksi RUP on iteratiivinen ja komponenttipohjainen. Arkkitehtuurin perustaso sisältää usein kehyksen tai infrastruktuurin, joka helpottaa komponenttien lisäämistä iteraatioiden avulla järjestelmän toimintojen mukauttamiseksi ja laajentamiseksi vaikuttamatta muuhun järjestelmään. Kolmanneksi RUP käyttää alan standardikieliä UML mallinnamaan järjestelmän arkkitehtuuria ja komponentteja visuaalisesti. RUP: lla on neljä erilaista kehitysvaihetta: alku, valmistelu, rakentaminen ja siirtyminen. Tämä artikkeli kattaa kuitenkin kahdeksan keskeistä toimintaa, jotka liittyvät J2EE-kehitykseen teknisestä näkökulmasta tavalla, joka säilyttää arkkitehtonisen painopisteen.

I. Vaatimusanalyysi

Vaatimusanalyysi kuvaa, mitä järjestelmän pitäisi tai ei pitäisi tehdä, jotta kehittäjät ja asiakkaat voivat luoda alkuperäisen liikesopimuksen. Voit dokumentoida toiminnalliset vaatimukset liiketoimintakonsepteissa, toimialueiden sanastoissa, käyttötapauksissa ja käyttöliittymämalleissa. Toimimattomat vaatimukset, kuten suorituskyky ja tapahtumat, määrität lisävaatimuksia koskevassa asiakirjassa. Voit luoda korkean tason käyttöliittymämallin paperille tai HTML: ksi sen mukaan, kuinka syvällisesti olet mukana projektissa.

Kuvassa 1 on kaksi esimerkkitapausta tyypillisestä sähköisen liiketoiminnan järjestelmästä. Katso tilaus käyttötapaus kertoo meille, että käyttäjä kirjautuu järjestelmään verkkoliittymän kautta, näkee tilausluettelon ja napsauttaa linkkiä nähdäksesi tietyn ostotilauksen tilaustiedot. addLineItems käyttötapaus kertoo meille, että käyttäjä selaa tuoteluetteloa, valitsee mielenkiintoisia tuotteita ja lisää ne ostotilaukseen.

II. Kohdekeskeinen analyysi

Analyytikot luovat ongelma-alueiden mallit: luokat, objektit ja vuorovaikutukset. Analyysissä ei saa olla teknisiä tai toteutuksen yksityiskohtia, ja sen tulisi sisältää ihanteellinen malli. Kohde-analyysi auttaa sinua ymmärtämään ongelman ja hankkimaan tietoa ongelmialueesta. Sinun on ylläpidettävä puhdasta verkkotunnusmallia ilman teknisiä yksityiskohtia, koska liiketoimintaprosessi muuttuu paljon hitaammin kuin tietotekniikka.

Nämä kaksi ensimmäistä vaihetta - vaatimusten analyysi ja olio-analyysi - eivät ole J2EE-spesifisiä; ne ovat melko yleisiä monille olio-orientoiduille menetelmille. Kuvio 2 esittää lemmikkikaupan näytesovelluksen korkean tason objektianalyysimallin. Se kuvaa tärkeimmät käsitteet, jotka tunnistimme vaatimusten analysoinnissa. Mallinnamme nämä käsitteet esineiksi ja tunnistamme niiden suhteet.

Vaatimusten ja objekti-analyysien tulos on lähtökohta J2EE-arkkitehtuurin kehittämiselle. Arkkitehtuurin kehittämiseksi valitset pystysuoran kappaleen - usein kriittisen osan, kuten tilauksen toimialueobjektimalli - objektin suunnittelua, toteutusta, testausta ja käyttöönottoa varten. (Pystykappale, RUP-käsite, on pieni osa järjestelmää. Lähtökohtana on osajoukko käyttötapauksia, kuten kuvassa 1 on esitetty, ja verkkotunnusanalyysimalleja, kuten kuvassa 3 on esitetty. Pystykappaleen toteutus tuloksena täysin toimiva minijärjestelmä, joka sisältää kaikki tasot, kuten käyttöliittymän JavaServer Pages (JSP), keskitason liikeobjektit, kuten Enterprise JavaBeans (EJB), ja usein taustalla olevat tietokannat.) Voit käyttää prototyyppi verkkotunnusobjekteihin ja anna tämän tiedon toimia suunnittelun ohjeena kohteen suunnitteluvaiheessa.

$config[zx-auto] not found$config[zx-overlay] not found