I am SCEA and I am currently writing the PART II for SCEA 5.
I have lost some marks because I was concerned with the wrong things. For example, in SCEA 1.4, I was paying too much attention to interaction diagrams, and their value to the result was not so important.
In SCEA Beta 5 the same thing happens again, so, I would like to tell you that you must balance the effort spent in each deliverable according to its relative value.
You are required to produce a Candidate Architecture for a project, so, the requirements aren�t refined yet.
Pay attention to the right things and you will pass with a high score.
The class diagram took alot of thought, and was something I refined iteratively over the weeks.
The deployment diagram on the other hand shouldn't be too difficult to envision. I mean, what architecture doesn't need an applications server, database and client? A deployment diagram shouldn't be too difficult to come up with.
But sequence diagrams, and figuring out the interaction of objects for each use case does require quite a bit of time and thought. However, if you look at the marks, there is no minimum score required for the sequence diagram part. I did think that was strange.
Nevertheless, the sequence diagrams help you think about your class diagram, and help you subsequently refine your design - overall, that's a good think.
yes, you're right... the best way to get an accurate class diagram (with methods suggested in one of the deliverables) is to do the interaction diagrams, and do it well.
By the way, I used to create a "contract" document, with the input, output and some advices to every method, this help me out with the communication with developers, and what I'm expecting of the class to do. (off course, this is not a requirement in this certification, but it's a good practice in the real world)
from all that we conclude that either: 1) If you have a bad seq. diag., you can't (well unlikely) have a good class diag - they are related, just test the one of them.
2) As it appears that in all assignments the requisites are fuzzy, Sun is way more interested in testing if you see the domain "things" (classes, interfaces, components, patterns, tiers, etc), as opposed to how it "works" (the seq. diags, msgs, loops, if/else)
Are you guys showing interfaces on your class diagram?
my point is... for example... every SLSB or SFSB implemente a business interface, (@Remote or @Local),right?
are you guys showing those business interfaces on your class diagram? Do you believe it is necessary?
are you guys using stereotype to show if does business interface are @Remote or @Local?
Thanks for the attention!
I work with the following technologies: Webwork 2.2, Xwork, iReport 0.5.2 Jasper Reports 1.1.0, JSP 2.0, CSS, Java Script, Hibernate 3.0.5, MySQL 4.1.7, Eclipse 3.1, Tomcat 5.5.9, JBoss 4.0.2. Any Doubt? ask me, firstname.lastname@example.org
pie. tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop