Ohjelmistoarkkitehtuurit harjoitustyö 2008

Transkriptio

1 Ohjelmistoarkkitehtuurit harjoitustyö Johdanto Harjoitustyönä toteutetaan viestipohjaiseen kommunikointiin perustuva simulointi tuotantoketjusta tilauksen saapumisesta tuotteen valmistumiseen. Työn nimi on Tuotantoprosessin simulointiympäristö eli TPS. Tehtävänä on vastaanottaa tilauksia asiakkaalta, ja hoitaa tilauksen valmistamisen. Tämä tapahtuu lähettämällä ohjaavia viestejä eri yksiköille, jotka hoitavat näiden perusteella oman osuutensa prosessista. Prosessin peruskuvaus 1. Asiakkaalta tulee tilaus 2. Järjestelmä tarkistaa että tilaus voidaan valmistaa ja toimittaa asiakkaalle ok-viestin 3. Järjestelmä käsittelee ja valmistaa tilauksen Simulointinäytöllä näkyy mm. trukkien liikkumiset ja tilauksen edistyminen 4. Asiakas saa tiedon valmiista tuotteesta Kuvassa 1 on esitetty järjestelmän arkkitehtuuri korkealla tasolla. Viestiväylä kuvaa järjestelmää johon järjestelmän eri osat liittyvät ja joka kytkee ne yhteen. Yksiköt kuvaavat järjestelmään liittyviä toiminnallisia yksiköitä. Simulointinäyttö puolestaan näyttää konkreettisten yksiköiden aktiviteetteja simuloinnin edetessä. Harjoitustyön rajallisten resurssien vuoksi yksinkertainen on kaunista, ja apuna voi hyödyntää annettua JGame-moduulia. Perustoiminnot täyttävä järjestelmä toimii automaattisesti, mutta lisäominaisuutena voi toteuttaa järjestelmään vuorovaikutteisuutta (tästä lisää luvussa 4. Lisäominaisuudet). Simulointinäyttö Yksikkö Yksikkö2 Viestiväylä Kuva 1: Korkean tason arkkitehtuuri Harjoitustyö tulee toteuttaa Java-kielellä ja sen tulee perustua viestinvälitysarkkitehtuuriin. Viestien välitys toteutetaan käyttäen Java Message Serviceä (JMS, JMS toteutuksena käytetään OpenJMS:ä ( Vaikka kyseessä on hajautettu järjestelmä, niin harjoitustyön puitteissa järjestelmää tullaan testaamaan vain siten, että OpenJMS-palvelin ja kaikki suoritettavat yksiköt sijaitsevat samalla koneella. Kurssin sivuilta löytynee joitakin tutustumisen arvoisia linkkejä JMS:n hyödyntämiseen. 1

2 Taulukko 1: Dokumentissa käytettäviä termejä Termi Yksikkötyyppi Yksikkö Konfiguraatio Tuote Raaka-aine Tilaus Konkreettinen BSEyksikkö [KBy] Kuvaus Tietyn tyyppisen yksikön kuvaus, esimerkiksi varasto Jonkin yksikkötyypin ilmentymä, esimerkiksi tarvikevarasto Tietyistä yksiköistä koostuva ajettava kokoonpano. Esimerkiksi peruskonfiguraatio tai testikonfiguraatio Valmistusprosessin tuotos. Asiakkaat tilaavat tuotteita. Käytetään tuotteiden valmistamiseen. Asiakkaan lähettämä tieto tuotteista ja niiden määristä jotka tulee valmistaa. Kaikki järjestelmään liittyvät konkreettiset käsitteet eli ainakin varastot, tehtaat ja trukit. Nämä visualisoidaan simulointinäytöllä. 2 Perusvaatimukset 2.1 Toteutettava peruskonfiguraatio Järjestelmän peruskonfiguraatio on seuraava: Tehdasyksiköt Yksi tehdas kaikkien eri tuotteiden valmistamiseen Tuotteiden valmistusreseptit luodaan Javan reflektiota käyttäen Varastoyksiköt 2 kpl varastoyksiköitä Trukit 2 kpl Yksinkertainen raaka-aine varasto Valmiiden tuotteiden varasto Trukkien avulla raaka-aineita ja tuotteita liikutetaan varastojen ja tehtaiden välillä Konfiguraation näyttöpaneeli Yksikön käynnistys lisää yksikön konfiguraatiopaneeliin. Maailman simulointinäyttö Näyttää kaikki konkreettiset yksiköt, eli varastot, tehtaat ja trukkien liikkumisen (Voidaan toteuttaa annetulla JGame-komponentilla) Viestimonitori Lisäksi asiakas lähettää järjestelmälle tilauksia ja ottaa vastaan tiedon tilauksen valmistumisesta 2

3 2.2 Järjestelmän liittyminen asiakkaaseen. Kaikki kommunikaatio asiakkaan kautta tapahtuu JMS:n TextMessage tyyppisten viestien avulla. Näiden sisältö on tässä tapauksessa XML:ää. Harjoitustyössä saa olettaa, että tulevat viestit ovat juuri annetun muotoisia ja virheettömiä, eli virheentarkistusta ei ole pakko tehdä. Asiakkaalta tuleva informaatio tulee järjestelmälle JMS:n customer-queueincoming nimiseen jonoon, josta järjestelmän tulee lukea ja käsitellä se. Viestit lähettää valmiina annettu asiakas-komponentti. Mahdolliset viestit ovat tyyppiä: Uusi tilaus <neworder> </neworder> <id>tilauksen id. Juokseva numero.</id> <productname>haluttu tuote</productname> <quantity>kpl määrä</quantity> Asiakkaalle menevä informaatio lähetetään customer-queue-outgoing nimiseen jonoon, josta valmiina annettu asiakas-komponentti lukee sen. Mahdollisia viestejä ovat Tilaus vastaanotettu Tilausta ei voida toimittaa Tilatut tuotteet valmistettu <orderreply> </orderreply> <type>orderconfirmed/orderfailed/orderdone</type> <id>tilauksen id. Juokseva numero.</id> <specification> Voi olla tyhjä. Mielivaltainen merkkijono. Käytetään ainakin kun tilausta ei voitu toimittaa ilmoittamaan syy. </specification> 2.3 Prosessin peruskuvaus. 1. Asiakkaalta tulee tilaus 2. Järjestelmä tarkistaa että tilaus voidaan valmistaa ja toimittaa asiakkaalle ok-viestin 3. Kun jokin tehdas, joka pystyy valmistamaan kyseistä tuotetta, on valmis ottamaan tilauksen vastaan tilaus lähetetään tälle (toteutuksesta riippuen, tehdas voi olla varattu esim. jos siellä tällä hetkellä on jo jokin tilaus käsittelyssä). Jos tehdas alkoi valmistamaan kyseistä tilausta, niin simulointinäytölle tulee näkyviin tehtaan 3

4 kohdalle tämän tilauksen id. 4. Tilauksen vastaanottanut tehdasyksikkö tarvitsee raaka-aineita. Raaka-aineet toimitetaan varastosta tehtaalle. Trukin liikkuminen varaston ja tehtaan välillä näkyy simulointinäytöllä. 5. Tehdasyksikkö valmistaa tilauksen. Tilauksen valmistumisen edistyminen näkyy simulointinäytöllä. 6. Valmis tuote toimitetaan varastoon. Trukin liikkuminen näkyy simulointinäytöllä. 7. Asiakas saa tiedon valmiista tuotteesta. (Tuotetta ei kuitenkaan toimiteta asiakkaalle peruskonfiguraatiossa) (jos vapaita trukkeja ei ole, niin tehdas joutuu odottamaan kohdan 4. tai 6. aluksi.) Huomioitavaa: Tästä tarkennettu sekvenssikaavio osaksi suunnittelua välipalautukseen. 2.4 Yleisiä vaatimuksia Taulukossa 2 kuvattujen perusyksiköiden toteuttaminen Työn arkkitehtuuria suunnitellessa tulee kiinnittää huomiota muunneltavuuteen Järkevien muutosten tekeminen tulevaisuudessa tulee onnistua kohtuullisella vaivalla. Järkeviksi ominaisuuksiksi lasketaan ainakin lisäominaisuudet Yksiköt toteutetaan itsenäisinä prosesseina ja kaiken prosessien välisen kommunikoinnin tulee tapahtua viestiväylän välityksellä. Yksittäiset trukit saavat olla omia prosessejaan, mutta sitä ei vaadita Järjestelmässä on järkevä tapa löytää siihen kiinnitetyt yksiköt, ts. kun uuden yksikön lisää viestiväylälle niin se myös näkyy konfiguraation näyttöpaneelissa. Kaikki peruskonfiguraatioon kuuluvat yksiköt käynnistävä skripti. Esim. build.xml tiedoston avulla. Tämä on oleellinen vaatimus, jotta työ saadaan testattua. Yksiköitä käynnistettäessä voidaan olettaa että JMS palvelin on päällä Hallittu toiminta JMS palvelimen kaatuessa tai sulkeutuessa 2.5 Tekninen ympäristö Pääasia on, että yksiköt eivät saa kaatua vaikka JMS palvelimen kaatuisikin Järjestelmä vaatii JMS:n toteuttavan komponentin. Vaihtoehtoisia toteutuksia on useita, joista työhön on valittu OpenJMS. Kehitysympäristö Java ajoympäristö: Java SDK 5.0 tai Java SDK 6.0 [projekti toimitetaan 5.0 projektina] Kehitysympäristö: Eclipse [tai 3.3.0], Eclipse IDE for Java Developers versiota Eclipsen sivuilta suositellaan 4

5 2.6 Käsitteisiin liittyviä tarkennettuja vaatimuksia Taulukko 2: Eri kuvaukset Käsitteet Maailman simulointinäyttö Tilaus Toimitus Trukit Tehdasyksikkö Kuvaus Maailman simulointinäyttö näyttää ruudulla kaikki konkreettiset yksiköt (KBy:t) eli tehtaat, varastot ja trukit. Simulointinäytöstä ei ole tarkoitus muuttaa simuloitavien yksiköiden tilaa, vaan sen on vain tarkoitus näyttää näiden sijainti ja mahdollinen tila. Varasto Näytetään sijainti, nimi ja raaka-aineiden/tuotteiden saldo. Tehdas Näytetään sijainti, nimi, tällä hetkellä valmistuksessa olevan tilauksen ID ja tämänhetkisen valmistuserän tila (valmistuserästä näytetään kokonaismäärä ja jo valmistuneiden osuus siitä) Trukki Näytetään sijainti, nimi ja tämän hetkiseen liikkumiseen liittyvän tilauksen ID. Liikkuu varastojen ja tehtaiden välillä KByjen tilan muuttuminen saadaan reaaliaikaisesti näkyviin käyttöliittymässä ilman käyttäjän vuorovaikutusta, esim. kun varaston raaka-aine saldo vähenee. Asiakkaalta JMS:n customer-queue-incoming nimiseen jonoon saapuva määrämuotoinen teksti. Ks. tarkempi kuvaus perusvaatimuksista. Asiakas voidaan luoda lisäominaisuutena, jolloin tälle voi tehdä toimituksen. Trukit kuljettavat raaka-aineita varastoilta tehtaisiin. Peruskonfiguraatioon trukkeja 2 kpl. Visualisoinnissa täytyy trukit erottaa toisistaan jollakin tunnisteella. Uusia tuotteiden valmistusohjeita voi ladata tehtaaseen plugineina, eli tehdas ei ennalta tiedä valmistettavia tuotteita eikä aseta keinotekoisia rajoituksia tuotteiden määrälle tai raaka-aine vaatimuksille. Tehtaan tulee ladata valmistusohjeet Javan reflektiota käyttäen. Java reflectio-tutoriaali Pakkauksen luokkien listaaminen (reflektiolla) Valmistusohjeen rajapinta (esim): String GetProductName() Map<String, Int> GetNeededRawMaterials() 5

6 Käsitteet Kuvaus Tehtaaseen toteutetaan seuraavat valmistusohjeet: Teekeitin-ohje: Vaaditut raaka-aineet: 1kpl Keitin. 1kpl Teepannu. Varastoyksikkö Kahvinkeitin-ohje: Vaaditut raaka-aineet: 1kpl Keitin. 1kpl Kahvipannu. 10kpl suodatin. Varastot säilyttävät tyypistä riippuen erilaisia raaka-aineita tai valmiita tuotteita. Varastoihin voidaan lähettää niiden hyväksymiä materiaaleja ja niistä voidaan myös hakea näitä. Peruskonfiguraation varastotyypit ovat yksinkertainen raakaainevarasto ja valmiiden tuotteiden varasto. Yksinkertainen raaka-ainevarasto Toteutus osa peruskonfiguraatiota Yksinkertaisesta raaka-ainevarastosta löytyy kaikkia tarvikkeita mitä sieltä haetaan. Materiaalia haettaessa näytöllä näytetään laskurin pieneneminen raaka-aineelle joka sieltä haetaan, aloittaen tuhannesta kappaleesta. Toisin sanoen, ennen ensimmäistä hakua näytöllä ei tarvitse näyttää ainuttakaan raaka-ainetta. Valmiiden tuotteiden varasto Toteutus osa peruskonfiguraatiota Varasto on aluksi tyhjä. Varastoon voidaan tuoda mitä tahansa tuotetta, jolloin varaston saldo päivittyy. Konfiguraation näyttöpaneeli Viestimonitori Näyttöpaneeli näyttää listauksen ja kuvauksen kaikista järjestelmään kytkeytyneistä yksiköistä. Listauksessa näkyy sekä konkreettiset että virtuaaliset järjestelmään liittyneet yksiköt. Laite on tarkoitettu järjestelmän toiminnan seuraamiseen. Se näyttää ruudulla, pitää kirjaa ja sillä voi halutessaan tallentaa tiedostoon kaikki järjestelmän välittämät viestit helposti tulkittavassa muodossa. Viestimonitori tulee toteuttaa siten, että siihen olisi myöhemmin helppo lisätä ominaisuus, jossa viestiväylässä välitettyjä viestejä voi myöhemmin kysyä monitorilta. Tätä ominaisuutta ei harjoitustyössä kuitenkaan tarvitse toteuttaa. 6

7 3 Lisäominaisuudet Lisäominaisuuksia ei ole pakko toteuttaa, mutta toteuttamalla vain perusominaisuudet on mahdollista saada vain osa täysistä pisteistä. (ks. luku 6). Lisäominaisuuksia saa toteuttaa 0-4(+)kpl. Maksimipisteet on mahdollista saada kun toteuttaa neljä lisäominaisuutta. Toteutettavat lisäominaisuudet ovat vapaasti valittavissa taulukosta 3: Yksi vaihtoehto on myös oman lisäominaisuus. Voit halutessasi ehdottaa omaa/omia lisäominaisuuksia assarille. (Mieluiten suunnitteluvaiheessa) 7

8 Taulukko 3: Lisäominaisuudet Lisäominaisuus Useita raaka-ainevarastoja ja tehtaita Laaduntarkastamo Tyhjät varastot XML-konfigurointi Vikasietoisuus Järjestelmä ei tuhlaa verkkokaistaa Virheellisten viestien käsittely Viestihistoria Kuvaus Järjestelmään voi liittyä useita erilaisia varastoja ja tehtaita, joita järjestelmä osaa hyödyntää. Järjestelmä huolehtii tilausten suhteellisen järkevästä ( =jonkinlaisesta) jakamisesta tehtaiden kesken. Erillinen konkreettinen yksikkö. Tuotteille voi määrätä laaduntarkastuksen, jonne tuote siirretään tehtaalta. Tarkastuksessa on 5% mahdollisuus, että tuote huomataan tarkastuksessa vialliseksi. Tällöin järjestelmä valmistaa tuotteen uudestaan. Aluksi tyhjä(t) varasto(t) ja uutena yksikkönä raakaaineiden tuotantopaikka, josta haetaan raaka-aineita järjestelmään lisätyillä rekoilla. Yksiköiden nimet, yms. konfigurointitieto annetaan XML:nä Yksiköt toipuvat JMS palvelimen uudelleenkäynnistyksestä ja jatkavat toimintaansa sen jälkeen normaalisti Järjestelmä ei tuhlaa verkkokaistaa, ts. viestien karsinta suoritetaan lähettävässä päässä ja/tai JMS-serverillä eikä vasta vastaanottavassa päässä Järjestelmässä on yhtenäinen järkevä tapa käsitellä virheelliset viestit. Esimerkiksi väärälle vastaanottajalle lähetetty, mutta muuten oikeellinen viesti osataan ohjata jollekin vastaanottajalle joka osaa käsitellä viestin. Viestihistoria kulkee viestien mukana prosessin läpi. Esim. olisi mahdollista selvittää missä tehtaassa tilaus on valmistettu ja mistä varasto(i)sta raaka-aineet ovat tulleet. 8

9 4 Vaatimukset palautuksiin 4.1 Välipalautus Annetun dokumenttipohjan mukaan seuraavat kohdat soveltaen: Vaatimukset järjestelmälle (luvut 1 ja 2) Yleinen kuvaus järjestelmästä ja sen vaatimuksista Harjoitustyöohjeeseen viitaten (eli toistoa välttäen) Muunneltavuusvaatimukset, eli minkälaiseen muunteluun toteutettavan järjestelmän tulee varautua Yleinen arkkitehtuuri (luku 3 ja erityisesti sen kohta 3.1. Kohtaa 3.2 ei vaadita välipalautukseen, mutta siihen kannattaa kiinnittää huomiota) Korkean tason arkkitehtuuri (luokkakaaviot ja sekvenssikaaviot mahdollisia) Käytetyt suunnittelumallit (mm. luokkakaavio) Kohta 3.4 alustavasti muutaman yksikkötyypin osalta Arkkitehtuurin arviointi, eli dokumentin luku 4 Työnjako ja aikataulu, eli dokumentin luku 7 Hylätyt ratkaisuvaihtoehdot, mikäli niitä on Välipalautuksen palautus Välipalautuksessa palautetaan alustava versio dokumentaatiosta yliopistokohtaisten käytäntöjen mukaisesti. 4.2 Lopullinen työ Korjattu/päivitetty versio välipalautuksessa annetusta dokumentista, johon on täydennetty loputkin dokumenttipohjan kohdat. Harjoitustyön lähdekoodit, ks alla Lopullinen palautus Harjoitustyön lähdekoodit (EI binääreitä!) palautetaan zip paketissa sisältäen seuraavat hakemistot ja tiedostot: / /src/ /lib/ Harjoitustyön lähdekoodit Tyhjä hakemisto käytettyjä kirjastoja varten (laita siis käyttämäsi kirjastot tähän hakemistoon, mutta älä palauta niitä) 9

10 /readme.txt /build.xml /.project /.classpath Tekstitiedosto, jossa on kirjattu ryhmäläisten nimet ja lyhyt käyttö/asennusohje Ant-scripti joka sisältää vähintään tehtävän run harjoitustyön ajamiseen. Eclipsen projektiasetukset Eclipsen classpath asetukset Harjoitustyösivustolla on saatavilla em. hierarkian mukainen projektipohja jossa on myös tarvittavat kirjastot valmiina. Palautuspaketti nimetään seuraavan mallin mukaisesti: ohar_2008-group<ryhmän numero>.zip eli esim. ohar_2008-group1.zip Ryhmän numero annetaan välipalautuksen yhteydessä. Muistakaa testata ennen palautusta palautuspaketin (ja sen ohjeiden) toimivuus tyhjässä hakemistossa tai workspacessa! Lähdekoodin ja dokumentaation palauttaminen tapahtuu kurssin sivuilla mainittujen yliopistokohtaisten käytäntöjen mukaan. 5 Aikataulu ti 16.9 kello 10:15 Harjoitustyön esittely luennolla pe Välipalautus oltava suoritettuna ( = ohjauspalaveri mukaan lukien) Dokumentti palautettava vähintään edeltävä arkipäivänä klo 9.00 mennessä ennen ohjauspalaveria. Esim. palaveri pe => dokumentti viimeistään to palautettuna ja ma => dokumentti pe pe 5.12 klo 16:00 Lopullinen palautus klo mennessä 6 Alustavat arvosteluperusteet Tarkoituksena ei ole toteuttaa myyntivalmista simulointijärjestelmää, vaan pikemminkin hyvä pohja sellaiselle. Arvostelussa kiinnitetään erityisesti huomiota seuraaviin asioihin: Järjestelmän arkkitehtuuri Mm. laajennettavuus ja ylläpidettävyys Dokumentaatio Selkeys, kattavuus Yleinen toimivuus, koodin selkeys yms. Harjoitustyö arvostellaan seuraavasti: välipalautus 0-2p perusominaisuudet 0-4p lisäominaisuudet 0-4p. 10