SCEA Part II and Part III 的经验谈 UMLSUNWorkflowGoYahoo
Just received my results this morning and thought I will share
my experience with those who are working towards architect
certification.
Score
Grade: P
Score: 95
Class Diagram (44 maximum) .......................... 39
Component Diagram (44 maximum) ...................... 44
Sequence/Colloboration Diagrams (12 maximum) ........ 12
My Submission:
1) One main Class diagram (25-30 classes/interfaces)which was an extension of the BDM. Besides domain entity objects, I only included objects that will handle the workflow. Diagram showed relationships (both association and aggregation), dependencies and only attribute/methods that I thought would improve clarity. I actually changed the BDM to what I thought was more logical, but I documented this down.
2) One Class diagram to show relationship between Controller/Views for the system, and how session for both Travel Agent and web client will be addressed.
3) Four component diagrams for each of the use case specified in the assignment
4) Five sequence diagrams to cover the 4 use case specified in the assignment (I had 2 diagrams for Pay Itinerary - one for Payment with credit card and one for mileage redemption)
5) 9 pages (printed HTML pages) to document:
i) My assumptions
ii) How my architecture/design will address security, session state, integration with the legacy systems , performance, scalability, maintainability,
iii) The J2EE and GOF design patterns I used in my design and how they relate back to the requirements for the assignment
My Experience:
I have been working with J2EE 1.2 (JSP, Servlets, EJB, JDBC) since 2000, and I am familiar with most of the J2EE design patterns (used some of them in one way or another). I had also passed the IBM exam on OOAD with UML just prior to Part II, so the preparation for that exam helped me alot in preparing for the Class diagram requirement for the assignment.
My Preparation actually passed Part I in May of 2001 (91%), but only signed up for Part II in Sep 2002 due to work/family commitments. I started on the assignment in early Nov 2002, finished in mid-Dec and took Part III after I submitted on 19 Dec. I spent mostly 1-2 hours per night and 4-8 hours on weekends working on the assignment. For Part III, I took the effort to explain my design decisions and how it would address the requirements - although Part III carries no marks, I believe it helped the examiner understand my solution.
I spent alot of time thinking about the problem domain, and like others before me was confused/unsure about many issues which seemed to be deliberately made unclear by SUN. I spent the longest time on the sequence diagrams, but I think this is necessary because it enabled me to refine/revise my class/component diagrams as I delve deeper into the details of the interaction for the system.
I found the books "Core J2EE Design Patterns" and "UML and the Unified Process: Practical Object-Oriented Analysis and Design" by Jim Arlow most useful to me for Part II. I only referred to the last chapter for Cade's book to get an idea of the level of details that the solution should have.
My Advice:
I would add that if you should encounter any ambuiguities in the assignment, use reasonable assumptions and justify them. I also think that how your solution addresses the
performance/scalability/security requirements are important for the assignment.
That's all I have, I am quite pleased with my results and I believe that I have learned alot by preparing for this certification.
Good Luck !
=========================
第二篇, 这个作者得到了100分
I just got back a 100% score on part II/III. Many thanks to those in this group; you¡¯ve been a great help to me.
Here¡¯s my advice.
JUST GET STARTED. Don't spend a lot of time wondering how much detail or what patterns or things like that. This is a "learn by doing experience" not "learn by thinking". Move through the complete design several times, improving it on each pass. It's OK if the first pass is awful, just keep refining it. Don't be afraid to tear it apart and start over if that is what is needed. You'll be surprised how much you will learn about design just by doing it.
Document your design clearly. I had several pages of written documentation. I included:
-- My assumptions (there were many)
-- Naming conventions (I had a clear set of conventions that I followed throughout the project)
-- Explanations of how the classes interacted and what jobs they did
-- What patterns I had used
-- Brief justifications of design decisions
Read carefully through the doc and make sure that you actually address each requirement that they give you at some point. Don't skip anything. Look over the "ilities" (Scalability, Maintainability, Reliability, Availability, Extensibility, Manageability) and see how your design addresses these.
COMMUNICATE. I spent a lot of time making the drawings look good. Use the same font family for everything and limit the number of styles and sizes that you use. Go for a simple, clean look. Make sure EVERYTHING lines up down to the pixel. (I used SmartDraw for the drawings). I didn't put a whole lot in each drawing; I broke them down into logical sections. Make sure your written docs read well, are cleanly organized and have no typos. Write, edit, re-write and edit again. Don't use any unnecessary verbiage. Make your English teacher proud. A major part of the job of an architect is to COMMUNICATE his design effectively. The person you have to communicate this design to is the examiner. MAKE THEIR JOB EASY.
Go over your materials for part I and apply them to part II. You will find a lot of things you can use.
I did everything "The Java Way," using patterns and solutions extracted from Sun documentation. I mostly did this because I treated the whole thing as a learning exercise. If I ran into a problem that I didn't know how to solve, I looked at the approaches taken in the Sun docs. I was always able to find a pattern that made sense to me (even within the Sun docs there is often more than one way to solve a problem.) Use the solutions that others have developed, don't just mis-understand what others have done and then spin off into "creative solutions."
Think things out for yourself. Can't decide whether to store client state in HTTPSession or Stateful Session Beans? How did others do it? What are the arguments for each approach? How do they affect your design? Work it out, make your decision and then put your reasons in your docs.
My best advice is to make a clear, well-organized presentation of a design that you feel confident in.
Resources
***
This was the best set of notes that I found.
http://groups.yahoo.com/group/scea_j2ee/files/arch.htm
You will probably have to join this Yahoo group to get access, it's free and it's a good group.
***
UML Distilled
Don't get too fancy with your UML. Keep it simple. Spend some time checking over the UML in your diagrams and make sure it's "by the book."
***
This is the Sun study guide. It's not everything you need but it's worth the price.
****
Core J2EE Patterns
This one was very useful. Read all the design patterns in the book and understand them. See if you can apply them to your design. Mention in your documentation that you are using the pattern. Don't just use patterns just because you feel you have to. Find patterns that actually improve the design and use them.
****
These are some very good presentation slides that outline the Pet Store Architecture. Go over these carefully and find things to apply to your design. If you get stumped as to how to solve a particular problem, take a look at these.
http://groups.yahoo.com/group/scea_prep
====================================================
这是第三篇
My advice for Part II is same as most of other people have already said and, that, is keep it simple.
They have changed the distribution just this month.
I had about 28-30 classes in my diagram, off which 22 or so were for EJB tier and remaining for web-tier. First I did not want to include web tier at all, then I decided to go for it becuase I thought it explains my architecture much better.
You can add comments in the diagram where ever possible that will save the assessor from having to read the documents.
Component Diagram was a bit tricky for me because so far I have not really seen a standard way of drawing component diagrams, and different uml tools work differently in regards to component diagrams. Plus I did not really understand Sun's expectation on this one.
My sequence diagram was not very detailed either, i just included the major flow of messages between objects.
Before I actually got started on the assignment, It took almost three weeks to put pieces together in my head, I must have changed solutions a no of times before I could finalize on what i was going to do. It needs a lot of patience too.
Don't get frustrated a lot in the beginning, because you are going to need it when you get to the sequence diagram, now it will frustrate you even more because they have lowered the score too.
Hope this helps.
All in all, it has been a good experience doing this architect certification.
上一篇： Se7en - 经典对白