Oracle Certified Master, Java EE 5 Enterprise Architect läpi

Jep, aikamoinen nimeys. Tuohan tunnettiin aiemmin lyhenteellä SCEA. Nyt esim. OCEA epävirallisesti, ja versiota 6 saati sitten 7 ei ole vielä saatu aikaiseksi, joten tein tuon version 5 nyt. Serttihän muuttui juuri niin, että nyt se vaatii virallisia Oracle kursseja käydyksi, eli ehdin niukin naukin suorittaa sen vielä käymättä itse kouluttautumassa (asioita jotka jo tiedän ja joita koulutan) 😉

Kyseessä on aika rankka sertti, jossa mitataan kykyä suunnitella uskottava arkkitehtuuri annetun määrittelyn perusteella. Harjoitus ladataan verkosta, sitten toteutetaan oma dokumentaatio, joka muodostuu määrätyistä UML kaavioista ja sanallisesta dokumentaatiosta, esim. riski ja mitigaatiolista, oletukset, jne. Rankka on usein samalla hauska ja palkitseva, ja niin tässäkin tapauksessa.

Ajattelin kirjailla pari vinkkiä niille jotka kenties vielä tekevät näitä tulevaisuudessa. Paljonhan on taas netissä jo tarjolla. Oma tehtäväni oli sähkö ja vesilaitoksen järjestelmä (Utilities), ja kuten etukäteen arvasin, määrittelyssä oli (tahallisia) ristiriitoja ja virheellisyyksiä ja puutteita, jotka arkkitehdin tulee lukea rivien välistä ja tulkita halutulla tapaa, ja mikä tärkeintä, dokumentoida oletukset ja riskit.

Pientä haastetta toi uuden alustan piirteet. Toisaalta en uskaltanut käytellä liiaksi Java EE 6 piirteitä joita aidosti olen käyttänyt jo pitkään, koska sertti koski version 5 piirteitä, ja eroja on aikalailla (JSF 2, CDI, JPA 2.. 😉 – toisaalta kaikki vanhat suunnittelumallit ja arkkitehtuurit joihin aiemmin vedottiin sai heittää romukoppaan joska J2EE design patterns kirja on kirjoitettu joskus 1998, ja parhaatkin pattern opukset ovat kymmenen vuoden takaa vähintään.

Itse ratkaisun yksityiskohtiahan ei saa kommentoida, mutta tehtävästä on mahdollista keskustella noin yleisen suunnittelun tasolla.

Eli tässä niitä ohjeita:

– Lue määrittelyt useita kertoja, yritä lukea rivien välistä, ja käy läpi mitä keskusteluryhmissä puidaan, ja mitä toimialalla on yleensä tehty. On syytä ymmärtää esim. käytetyt alakohtaiset jenkkitermit oikein.

– Tee hyvä ja selkeä assumptions lista jossa perustelet miten tulkitsit ristiriitoja ja selitä miten päädyit arkkitehtuuriisi. Tässä laatu ja selkeys menee ohi määrän, arvostelijat lukevat valtavan määrän näitä ja mitä eivät ymmärrä, niin siihen eivät hyvin reagoi.

– Panosta täydelliseen UML yhteensopivuuteen, halutulla versiolla. Itse sain siitä aika helposti täydet pisteet. Käytä hyvää välinettä. Itse käytin Enterprise Architectia, mutta sinällään mikä hyvänsä muu kuin Powerpoint toiminee 😉

– Spesifi vinkki: Jostain kumman syystä arvostelijat haluavat näemmä että näyttökerros kuvataan omana kerroksenaan myös luokkakaaviossa ,eli varaudu laittamaan JSP/JSF sivut/Facelet templatet myös luokiksi. Omasta mielestäni en olisi näin luokkakaaviota sotkenut mutta näemmä oli syytä että saa hyvät/riittävät/täydet pisteet.

– Iteroi ja istu designin päällä hyvän aikaa ennen kuin lähetät sen, itsellä on ainakin malttamaton mieli ja piti pakottaa itsensä työstämään tätä vielä muutama iteraatio kun aloin olemaan varsin tyytyväinen.

– Automatisoi loppuratkaisun paketoiminen ja tuplatarkista että lähetät kaikki mitä tarvitaan ja kaikkien uusimmat versiot.

Jep, enempiä en taida uskaltaa tähän kirjotella. Mutta toki JavaRanchin forumeilta löytyy erittäin hyödyllisiä lisävinkkejä kaikkiin Java sertifikaatteihin.

Advertisements

Vastaa

Täytä tietosi alle tai klikkaa kuvaketta kirjautuaksesi sisään:

WordPress.com-logo

Olet kommentoimassa WordPress.com -tilin nimissä. Log Out / Muuta )

Twitter-kuva

Olet kommentoimassa Twitter -tilin nimissä. Log Out / Muuta )

Facebook-kuva

Olet kommentoimassa Facebook -tilin nimissä. Log Out / Muuta )

Google+ photo

Olet kommentoimassa Google+ -tilin nimissä. Log Out / Muuta )

Muodostetaan yhteyttä palveluun %s