jeanne’s SCEA/OCMJEA 5 part 2&3 experiences

Today I got word that I passed the SCEA/OCMJEA exam.  I passed part 1 in July and then took a break for the Core Spring certification.  Overall, the process is do part 2, take part 3 then e-mail part 2 and get grade in 4-6 weeks. (I got it in 18 days.)

Week by week

People often ask how long it takes to do the project.  Sun/Oracle says 40-80 hours.  Cade/Sheil says 25-35 hours.  As with part 1, here’s a sense of what I did each week and how long I spent each week.  [I’ve also added notes on what was a bad idea]

It took just over 27 hours and either 4 or 10 weeks depending on if you count weeks I didn’t work on it.  Well within the estimate by Cade/Sheil and way under the estimate by Sun/Oracle.  I think this is because Cade/Sheil assume you are already know about architecture and have some experience.

Week 1 (3 hours)

  • Bought part 2
  • Read assignment
  • Re-read chapter 9 of Cade & Sheil
  • Decided to use Visio 2002 because I bought a copy in grad school.  [I recommend not using Visio, but here’s some tips if you do.]
  • Created template for the deliverable – index.html, links, etc.  That way I exercise them as I do the assignment and know they work and are readable/usable.

Week 2 (6 hours)

  • Re-read assignment listing assumptions/risks/major architecture thoughts/major technology thoughts
  • Configured Visio to like UML and UML 2
  • Started deployment diagram and class diagram

Week 3 (2 hours)

  • Created drafts of sequence diagrams
  • Found my UML book from grad school to make sure I am getting the “academic” points of UML that we don’t use in practice into my diagram.  [I recommend using an actual UML 2 book rather than what you have laying around from years ago.]

Weeks 4-9 (0 hours)

Did nothing for six weeks dues to a series of trips during the week and catching up on other things on the weekend.  [This is a bad idea.  I completely lost my momentum and “un-loaded” all the information about the project from my mind.  I also paused right after finishing the “fun part” so it wasn’t motivating to get back to the project.]

Week 10 (16.25 hours)

Decided I was going to finish before Halloween.  This has been dragging on too long and I wanted to get it done before my next trip.

  • Finished all diagrams
  • Switched to UML 2 syntax
  • Added the stuff nobody does in real life.
  • Asked for a review from a colleague (per Cade/Sheil) to see if the problem was discernible from the diagrams
  • Make sure clear, updated formatting, spell check

What did I read?

  • Chapter 9 in the Cade & Sheil study guide
  • Questions people had in  JavaRanch/CodeRanch‘s SCEA forum
  • JEE 6 tutorial- Basic concepts because a publisher mailed it for me to review.  While it refreshed my memory about JSF, it certainly wasn’t essential for the project.
  • I used the first edition of Using UML as a reference because I had it from grad school.  The first edition covers UML 1.X so I don’t recommend it.  It is better to use a UML 2.X book since that is what the exam wants you to use.

My impressions of SCEA Part 2

Part of part 2 was fun to do.  This was the part where I created the design, thought about it how met functional/non-functional requirements, made the risk list, etc.  Then there was the tedious “do the stuff Sun/Oracle wants that nobody does in the real world”.  Like put JSPs on a class diagram.  And the time spent stressing over reading Sun/Oracle’s mind on what they want despite them not commenting on it.  Unfortunately I took a break between the fun part and the tedious part which made it seem worse because I lost flow.  My thoughts on each section are:

  1. Class diagram – I’m not a mind-reader about what they wanted.  I did what I felt was appropriate, plus a bit more detail.  I had a feeling this decision cost me $300, but it didn’t – I passed on the first shot.  Cade’s example doesn’t look like there is any way it is worth 40 pts.  I had 2 class diagrams containing 26 classes and 11 JSPs.  (I would never put JSPs in a class diagram, but I thought they wanted it.)
  2. Component diagram – I would never put this much detail in a component diagram.  Especially JSPs!  I also noticed Cade has both a UML 1 example and UML 2 example despite being supposed to use UML 2.  I have 16 boxes in my component diagram.  I didn’t go overboard here either.
  3. Deployment diagram – This was straightfoward with only 7 boxes.  It  seems like it is worth too many points for the effort.  I did put some text on suggest hardware since Cade said to.
  4. Sequence diagrams – Despite being hardly worth anything, these are useful. I didn’t go into the detail people said they did on the forums or include the design patterns because that obscures the meaning.  I did not show the flow of framework code. I had 6 sequence diagrams for the 4 use cases.
  5. Risk list – I had a blast writing this. Writing about risks you don’t have to deal with is easier than on a real project where every risk is a potential problem.
  6. Assumptions – I wrote too much because I wasn’t sure what to take for granted.  It turned out a lot of this was addressed in part 3.  I did learn that I wrote “we” much more than “I.”   I had over 34 we’s vs < 5 I’s because I felt like I was presenting an (imaginary) team design to an outsider.  I changed them all to I before submitting so the reviewer doesn’t think someone else did the work.
  7. Other documentation – I wrote some text explaining a high level overview of my design, what design patterns I used and how I met the non-functional requirements.  While “a picture is worth a thousand words”, short paragraphs describing certain things let the reviewer see my thought process without having to guess.  (I only used 4 design patterns.)

My impressions of SCEA Part 3

Part 3 was fun!  It was writing about the things I found fun in part 2.  My notes:

  • They gave 120 minutes instead of the 90 I thought we had. This included reading terms of agreement.
  • I spent 70 minutes on the 8 questions, but I wrote a lot.
  • Advice: read all questions before starting: some are similar.  I did not do this and wound up answering later question in earlier ones and then having to repeat because there is no copy/paste.
  • Some questions were about non-functional requirements or why you choose to do something.  Some were scenarios or why you didn’t choose certain alternatives.
  • I’m glad I was warned the score = 0 (fail) when getting printed report after taking the exam.

And the end

I think this thread summarizes the part 3/submission process well.  I got my pass in the mail along with a note to login to very my address.  Then the certification bundle will be mailed.

– finished diagrams, asked for review (per Cade/Sheil) to see if problem clear, formatting, spell check
re-did sequence diagram – much better to use – can putl ines closer together, feels more natural, right click to change

things

scea – decomposition strategies example – part 2

In part 1, I posed a question on decomposition strategies.   Before I present my answer to the example, I want to point out a few things:

  1. An experienced architect (or organizer) is going to be able to do this in one pass.  This is ok.  Even in the real world, once you’ve seen a problem before you take shortcuts to the solution and don’t think about each step.  Just like a child will count on their fingers to figure out 9 x 6 and an adult will just say 54.
  2. If you aren’t comfortable with the concept of decomposition yet, take it slower.  Force yourself to pick something that splits the list into two pieces.  Then do it again.  Or give a reason for why you are making everything into a category.

My sample solution

Here I walk through the five layers presented in Cade & Sheil (listed in part 1).

Group 1 Technique – Distribution

I choose distribution over layering as my first technique because some of the items in this list represent different subsystems.

Accounting System Food System
  • coupon
  • fork
  • gift card
  • knife
  • paper cup
  • paper receipt
  • pen
  • spoon
  • chicken
  • lettuce
  • mayonnaise
  • mustard
  • pickle
  • onion
  • roast beef
  • roll
  • rye bread
  • tomato
  • turkey
  • wheat bread
  • white bread
  • wrap
  • Group 2 Technique – Functionality

    I choose functionality over exposure and generality.  Since there are clear business groupings, it makes sense to separate on that level.

    Accounting System Food System
    Eating supply Check out item
    • fork
    • knife
    • paper cup
    • spoon
    • coupon
    • gift card
    • paper receipt
    • pen
    Bread Meat Condiments Veggies
  • roll
  • rye bread
  • wheat bread
  • white bread
  • wrap
  • chicken
  • roast beef
  • turkey
  • mayonnaise
  • mustard
  • lettuce
  • pickle
  • onion
  • tomato
  • Groups 3-5 – not needed

    The system is sufficiently decomposed.  All done.

    scea – decomposition strategies example – part 1

    Decomposition strategies are described in the Cade & Sheil Sun Certified Architect (SCEA) study guide.  Or maybe I should say the Oracle Certified Master, Java EE 5 Enterprise Architect (OCMJEA) now.  When I read the study guide and and took SCEA part 1, I found this to be very straightforward.  Then I read a thread in the CodeRanch certification forum where two people asked for tutorials or examples.  I searched online and didn’t find anything so decided to write one.

    What is decomposition?

    Decomposition is taking a big thing and turning into a bunch of smaller things.  In software architecture/design, this is used in designing a system.  Suppose you have 1000 classes.  How do you separate them into projects and packages that are manageable.  Decomposition can also be thought of as organizing or categorizing.  (Thanks Scott! This is a good way to put it.)

    Types of decomposition

    Case & Sheil list the following types of decomposition.  It is common not to use all groups in the same system.

    1. Layering or Distribution – layering refers to layering of the system and distribution refers to distribution of resources.  While the book treats these as one category a large system may do layering within a particularly large distribution area.  For example, distribution may go by database vs application server.  Then layering may happen within the application server.
    2. Exposure, Functionality or Generality – exposure refers to black box vs white box type exposure on several levels.  Functionality is about the business domain  (and something we often think about when designing packages.)  Generality is about reuse between systems.
    3. Coupling and Cohesion or Volatility – these should be familiar to any developer.  Low coupling and high cohesion insulate packages.  And keeping the things you expect to change often away from the other things makes maintenance cheaper.
    4. Configuration – when environment/outside things change independently of other things, it makes sense to isolate them.
    5. Planning and Tracking or Work Assignment – when done with everything else, further separating by project management concerns makes sense.  Especially when teams are from different organizations.

    Example

    Suppose I have the following things in my sandwich shop.  We want to decompose the list in at least two passes so we have no more than 5 items in a category at the end. How you could decompose the list. What strategy would you use first? Why? What would you do next?

    • chicken
    • coupon
    • fork
    • knife
    • lettuce
    • gift card
    • mayonnaise
    • mustard
    • pickle
    • onion
    • paper cup
    • paper receipt
    • pen
    • roast beef
    • roll
    • rye bread
    • spoon
    • tomato
    • turkey
    • wheat bread
    • white bread
    • wrap

    Answer

    Check part 2 for my answer with explanation.  If you want to take a stab at it – either before or after I’ve posted the answer – go for it.  There is more than one correct answer.  If you post your answer as a comment in this thread, I will give my thoughts on it.  If you post it in the CodeRanch/JavaRanch thread, you may get feedback from others as well.