Cleared Part II with 93/100

[kaiser eblovich]

Today I've got my result for part II, in approximately two and a half weeks.

While 93 points definitely hurt my sense of perfectionism, I am still happy. After all it was second attempt and I guess I couldn't survive third.

Class diagram 42/44
Component diagram 42/44
Sequence diagrams 9/12

Class diagram was 12 classes: domain classes from original diagram plus some more classes. Here was a mistake I've made first time: don't think it's a Class diagram. It is not. It is Business Domain Object diagram. Don't put any controllers, view helpers, external systems and other stuff into it. Put all that in the component diagram instead.

Component diagram was about 20 components, with all system tiers and external subsystems shown. Don't show all your domain objects, screens or business logics chunks here, it's architecture, not design. Just draw everything conceptually: here's my ScreenFlowManager and there's my DomainEntityBean. And don't forget to show external subsystems, they belong to component diagram too!

Sequence diagrams were fairly simple: I've shown layers rather than classes, and only basic interactions were shown there, without any fancy stuff.

Assumption document was rather brief. I've documented extensions to domain model (class diagram) and described layers and patterns in component diagram.

Oh yes, I've written some notes on diagrams here and there.

I didn't record my efforts but it was not more than 15-20 hours to finish all that. I do have industry experience: Java since 1999 and J2EE since 2001, so it wasn't all new to me. And if someone cares, I've also done SCJP, SCWCD, SCBCD before that.

I wish you all success, my fellow SCEA-wannabies

* * *

Now the ranting part. I claim that SCEA is the most obscure and stupid certification I ever did. The class diagram isn't class diagram here, the component diagram must show what always belongs to class diagram and sequence diagrams show everything from such a bird eye point of view that nothing is clear at all. I always felt utmost disgust to 'paper architects', you know, someone who says 'we have to use EJBs because it's an industry standard'. And for SCEA I had to play one. Yuck.
The 'architecture' I produced (and which got me proud SCEA title) in fact doesn't make much sense to developer either. If the poor guy who has to implement it isn't that poor and does have J2EE experience, he doesn't need this 'architecture'. If the poor guy never done J2EE, the architecture won't help him at all.
Considering all I said above I claim that sort of paper architecture to be completely worthless. I would never do any real project with this sort of approach.

Why I did it? Well, for a couple of reasons:
1. My employer likes to show off to its customers. Yes they employ real architects and that could justify costs that they put into their bills: EUR 100+ per hour. I wish I could earn it just for myself... but that's another story.
2. It shows my motivation to the employer, so that I'm going to get higher salary raise on the next review.
3. If I quit (who knows?) and have to apply for another position in another company, my proud 'Sun! Certified! Enterprise! Architect!' title makes salary negotiations a bit more on the easy side ("I'm <beep>ing Architect, not just code monkey - can't you see _that_?!")
4. Now when interviewing someone with SCEA certification I know what he really worth.
[ July 13, 2005: Message edited by: kaiser eblovich ]

[kaiser eblovich]

Just forget to add one thing.
In my first attempt I got 10/12 for sequence diagrams, in the second it was 9/12. No diagrams or assumptions/comments related to them were changed between these attempts. I couldn't figure that out, and probably can only assume these diagrams are like cash, you know, inflation and all that...
[ July 13, 2005: Message edited by: kaiser eblovich ]

[Arfoo Huang]

Congrats..

They really gave you hard time to pass it. Could you share with us why did you fail the first time? I think this info could help us a lot to avoid big mistakes. Thanks.

[Marcelo Sousa Ancelmo]

Congrats great job!



Regards,

[kaiser eblovich]

As I said I thought that the class diagram must contain what the class diagram supposed to contain - classes. I mean all those Actions, Sessions, CommandHandlers and other stuff which according to Sun belongs to _component_ diagram. That was my fault. I've redrawn the class diagram into absolutely stupid thing with domain entities and got 42 points.

[Arfoo Huang]

Interesting to know, as petstore class diagram shows all those classes. Is there any resource from SUN that says what elements should go to class diagram and/or component diagram?

[vu lee]

Congratulation, Kaiser

[kundan varma]

Hi kaiser
SCEA is a begining not the end. It helps you(atleast non-architects) to get something to work on architect part rather than just coding. Its like just MCA/BE doesnt make you professional, it shows you a light to go to a particular direction. Scea shows/opens path for change/added responsibility.

Thanks
kundan

[Theodore Casser]

Well, your rant aside, congrats nonetheless. It's still, as you pointed out, an impressive sounding certification at the very least.

[Jeremy Hsu]

Good to hear your successful story on your second attempt. I must say thanks to the people like you who passed it. Because my first design of class diagram was basically what you did on your first attempt, then I was shocked to hear from people who passed that it is actually wrong doing this.

Also, for the sequence diagram, my first attempt was to including every classes used, and then I modified it to show component interactions instead.

I do not think SCEA is that useless because it really puts you into a different approach when designing a system. For example, Sun's approach to the architecture class diagram is definitely a useful skill to master. Because all the entity object will eventually be translated to database tables, if anything wrong with this, application will be forced to work with a very werid database schema and that will lead to a lot of problems.

Also, the component diagram is useful too because we can then assign different tasks much easier. For example, A handles coding this component, and B handles that component etc. Therefore, besides showing it proudly to employeer, I know I am on right path to architect software.

[David Follow]

Originally posted by Jeremy Hsu:

Also, for the sequence diagram, my first attempt was to including every classes used, and then I modified it to show component interactions instead.

Jeremy,

hmm, that surprises me. Becaus with the sequence diagram you show the dynamic behavior of the static class diagram. Since you don't use any classes from the class diagram in the SQD the whole idea of SQD is pointless. Well not really, coz in some why you show dynamic flow but still not using the class diagrams. Did other people pass with this approach? Please answer since this is a crucial decision!!!

D.

[kaiser eblovich]

Well, whether Sun's approach to architecture is right or not, this is a subject for separate discussion.

I've done enough real-world systems and I've never seen the system where the approach with domain object diagram was useful for anything but first analysis phase. The actual DB schema is always tuned for performance and might be anything from 5 tables per entity to 5 enitites in the same denormalized table.

with the sequence diagram you show the dynamic behavior of the static class diagram

In this case - it seems like no, you do not.
You show dynamic behaviour of your _components_, I would even say _types_ of components. The value of such diagrams is questionable, maybe just to validate that all external systems are covered in your component diagram.

[Newman Huang]

i don't agree with u it is worthless to get the certification. the result is not the most important thing but the procedure to get it. i study the GOF design patterns is to prepare the examination. but really i can apply what i learn into my work, and get happiness from it. SCEA is not only better salary.

[Jeremy Hsu]

Hi,
David, when you are developing an architecture, it is too early to have all the classes layed out. Even if you did, the diagram you came up will be too complex to be analyzed in an architectural way. Laying out all the classes like DTO, DTOFactory, and etc, those are done in the detail designs. Therefore, at this point, sequence diagram just shows dynamic interactions of your components.

I believe Kaiser did something like that as well, and he passes it. He showed interactions of layers.

However, I know some people passed it by using your approach because they might be considering those classes as very important components as well. As the definition for components is very obscure, if you read Fowler's UML distill, he said "a debate that's always ranged large in the OO community is what the difference is between a component and any regular class. This is not a debate that I want to settle here", you can see that different people think component differently. As long as your diagram is clear and meet the use case requirements and the service requirements, you will be fine.
[ July 14, 2005: Message edited by: Jeremy Hsu ]

[Jeremy Hsu]

Originally posted by kaiser eblovich:
[QB]Well, whether Sun's approach to architecture is right or not, this is a subject for separate discussion.

I've done enough real-world systems and I've never seen the system where the approach with domain object diagram was useful for anything but first analysis phase. The actual DB schema is always tuned for performance and might be anything from 5 tables per entity to 5 enitites in the same denormalized table.[QB]

Yeah, I agree. In the real world, you always are required to tune them for performance purpose. However, it is still tuned based on the one table per entity idea. Maybe we should have a separate threads discussing how practical is to apply Sun's approach in the real world. As I have only done 2 small real world systems, I am no where considering myself an expert in this area, and that is why I attempt on getting the SCEA. So far, I still find this certification really useful.

[Bharat Ruparel]

I can see both sides of the coin here. I had a similar experience as Kaiser did except that I did not fail. I got only 26 points out of 44 points in the Class Diagram though I have drawn Class Diagrams all through my professional career. Since I got full points in the Component diagram and Sequence Diagram, it didn't matter in terms of the overall result. If I had come out at the wrong end of the bargain, my views would have been much harsher. Kaiser does have a point which is: The Class Diagram that is expected here should definitely contain no more details than the most important ones here. My experience also indicates that DO NOT show any attributes in the class diagram that seems to turn the graders off and results in big time mark deductions. Another point worth remembering is that the method names also don't add much value, on the contrary, if the grader doesn't agree with your allocation of methods to the classes then you risk "big" mark deductions. On the other hand, only a token number of marks are deducted if you don't show method names. It is boiling down to be able to guess what the grader wants and present it to him/her. This is somewhat similar to the "selling" process in real-life in the sense that you are presenting what the customer wants rather than what you think he/she actually should want.
On the plus side, I didn't have much experience in drawing large scale component diagrams and I got that during this effort. It definitely made me think a lot more and be more restrained and diligent in my effort.
It seems to me that the "experience" factor could work more to your disadvantage than otherwise. Do the things by the book and the way SUN expects you to do them and you should be fine. DO NOT and I repeat DO NOT put any attributes on your Class Diagrams even if they are declare private and you explain that they are to be accessed via Java Beans style getters.

[frank fq]

Congrats!
A question: In the component diagram, did you show JSP/Servlets components in it? I am wondering is it a good way to just put a "common UI" component to interact with other business objects.

[kaiser eblovich]

Yes, I did draw an MVC pattern there.

[frank fq]

Thanks for your replying, Kaiser!
You mean put a MVC Pattern is a generic one or it's particularly for Web client? If it's for web client, how do you handle Swing client in component diagram?

Regard,

[Tinu Shroff]

Hi,
This forum is really helpful and I got an question while attempting for part 2.

I am confused about where to save Iternory when user presses confirm and save. Is it to be persisted in db or to be saved temporarily.

If saved temporary, then how to handle change iternories, because that use case tells that system load list of iternories.

Also I am not sure how seat avalibility works. Because user checks for seat avalibility at very early stage in prepare iternory. After that user has to go through few more screens till final payment happens. During this time, all seats might have been full, though there might have been few seats during prepare iternory. Not sure how to handle this?
Any ideas ?
Thank you very much

[Marius Huianu]

Kaiser,

Did you change the "Seats" from BDOM with "Seat" ?

Regards,
Marius

[Jeremy Hsu]

Hi, Kaiser.

Do you address alternative flow in your sequence diagram?