alain hsiung

Greenhorn
+ Follow
since Jan 28, 2003
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
In last 30 days
0
Forums and Threads

Recent posts by alain hsiung

Originally posted by Hafizur Rahman:
Hi Alain Hsiung
Thanks for ur nice comments & insight and sharing ur experience.
I am already going on with ur suggested path. I feel glad that I am on the right way.
You have a long successful career.CONGRATULATIONS. But I just started(2yr.). Suppose I have passed the exam. Can it help me to be a J2EE architect immidiately? I know that Architect is more a strategic position than a technical one in some companies even today. So taking the exam is not a good choice for me, but the preparing is. BUT I AM EAGER TO TAKE. HOW CAN I JUSTIFY?
How about this?
I need more 3/4 months for Part I.
+ 6/8 months for Part II/III.
---------------------------------
More one year of experience.
I can study some open source projects and get idea about architectural considerations for medium/big projects. I am a SCJP with 94%. I have some general/hands on practising experience for J2EE platform [architecture and API]. Does it look sound 3+yr. experience for a J2EE architect? I am already leading some projects.
Again thanks.


Hi Hafizur
As with every exam you need some experiences, not just exam preparation. You know that already with your SCJP. SCEA needs certainly more experience because the knowledge required cannot be put in 1 book (like programming).
Your question is difficult to answer. I know people with only 2 years J2EE experience who passed the SCEA exam. But others who worked on J2EE somehow during 4 years will not yet try because they feel they would fail.
I recommend you to read the SCEA study guide and try to get a feeling of your level and how long would it take to prepare. You know it best.
The other thing is REAL-WORLD EXPERIENCE. I think that certification is only good with real-world experiences. You can learn quite a lot by looking at open-source project but the experience in doing projects is extremly important. I would say that one have to participate in a least 3 J2EE projects during 2 years.
Taking the exam after 2, 4 or whatever years of experiences is a matter of compromise with your time, your need to earn money, your opportunity to work on projects, and so many thinks.
My recommendation:
Don't prepare the exam during 1 year but think of the stuff you want to learn during this year. Prepare the exam in less than 3 months.
Regards
Alain Hsiung
Ideartis

Originally posted by sh yh:
Hi Alain,
One question for your: Did you show any Entity EJBs in your Component Diagram(s)?
TIA.


Yes sure!
Congratulation Tom!
What a wonderful score!
Cheers
Alain

Originally posted by Hafizur Rahman:

Congratulations. GREAT SCORE.
I m planning to prepare for the exam. My professional experience is little. But I am confident that I can overcome. However, would u plz briefly let me know ur insight about taking the exam without having much experience?
If u don't mind, would u let us know ur experience? Hope I get some light.


Hi Hafizur
1. If you have only little professional experience, the best thing to do is learn OOA-OOD. Object-oriented analysis and design is the basis for any architecture, like capturing the business requirement, understanding and creating use-cases, creating the business object model and interaction diagram. To understand what to do to create the component diagram is more difficult (see my previous post in this thread). I would recommend OOA-OOD also for people with great experience who did not yet learned it. I know people with quite a lot of experience who didn't know the basis of OOA-OOD and had difficulties to process the exam part II. They lost a lot of time in going round in circles without methodology. For part I you have to read the many articles and perhaps some books (design patterns), read the recommendations of Bruce Yu'site (http://www.bm-one.com/Se/scea1.html and
http://www.bm-one.com/Se/scea2.html), this newsgroup and do the whizlabs mock tests.
2. My background: bachelor and master degree in computer science from the swiss federal institute of technology (ETH -where Nicklaus Wirth is professor), phd in computer science, certified IT project manager (IT project+ certified professional), java programming trainer, OOA-OOD and design patterns trainer, 14 years software engineering experience (Java since december 1995, 8 years also as software architect, 2 years also as methodology consultant). 8 years as consultant. 4 years experiences with app servers (Ejipt -in 1998, Weblogic, Websphere, JBoss, Silverstream). Lead developer or architect in 20 e-business projects since 1998 for 6 international companies. Co-founder of the Java Users Group Switzerland in 1997. Practicing member of the Worldwide Institute of Software Architect (wwisa). Founder of Ideartis inc. in 1998.
Regards
Alain Hsiung
Ideartis inc.

Originally posted by Raj Raj:
Hi Alian thaks for your answer ....
Have got more questions on Component Diagram ... Am not able to find much of the material on that ...Also lot of material gives wrong information ...
-- Did you showed component Diagram with Nodes ?
-- I am bit confused how to show the protocols like TCP/IP,JAX-RPC etc... Do we need to show that in component Diagrams, because that is the part of the Deployment Diagram. Did you showed all that stuff ? I am asking that because Fowler Book example (UML Distelled) showed in that form. So am bit confused ....
-- Also I have component e.g Business Delegate ... Which I want to show as a component of web container and at the same time as a component of application client. How to depict that behavior in the component Diagram...
Thank you in advance you r really helpful...
Raj


Hi Raj
1. I didn't show nodes in the component diagram. I did show big packages like web container and decide to show a component only once. The semantic of my packages is a "deployment" semantic. I.e. a package is similar to a node but do not use the node syntax (we are not showing the physical diagram here).
2. I didn't show protocols either
3. I didn't worry about duplicating the business delegate in the web container and the application client.
Regards
Alain Hsiung
Ideartis Inc.

Originally posted by Raj Raj:
Congrats Alain
Have got questions ...
1) What level of details are need in the class diagram. Is it necessary to show all the attributes/operation for the class.
2) Do the class diagram needs to be J2EE dependent (means show the EntityEJBs,SessionEJBs,etc). If it is J2EE independent then do we need to show the command classes as simple classes and make that SessionEntityEJBs in the component Diagram.
3) JSPs can be a different component but how about the application client. Can the application client be shown as a component or need to create a Class Diagrams for that too.
4) Do we need to create the package diagram
5) In sequence diagram for each different type of client do we need to show the different sequence diagram or can be represented as a "Client".
6) Can class diagram and component diagrams can be broken into multiple diagrams or needs to be shown as single diagram.

Answer to above questions are truely appreciated. Do not need the specifics but any suggestions will be helpful.

Thanks in advance for the help

Raj


Hi Raj
1. show all the "relevant" attributes and operations. Relevant means that they somehow support the use-cases. It helps you (and the examiner) to be convinced that the class is really needed and which role it plays. On the other side it doesn't matter if you ommit some of them. In reality you won't be able to specify all of them in a first design. The goal is to have a stable class diagram.
2. No J2EE specific construct in the class diagram. The class diagram contains only business classes. Yes the command class and J2EE specific classes are shown in the component diagram.
3. I chose to show the classes of the application client in the component diagram. These components are all "normal" java classes. So it is semantically equivalent to a class diagram. You could choose to show the application client as separate class diagram. But the requirement specify to have 1 class diagram and 1 component diagram. I stick to it.
4. Not necessary to show package diagram. I chose to show packages to group components in the component diagram.
5. Yes you can choose to show a generic "Client" as you mentioned. This is in case a good idea to reduce the complexity of the interaction diagram. It is not wrong because I got 100% on this.
6. I chose to have 1 class diagram and 1 component diagram. The component diagram is quite big but the exminer has perhaps a A1 plotter. I think it's not wrong to split the component diagram, in say 4-5 subdiagrams, but be careful to represent *all* the relationships between the components of separate subdiagrams.
Regards
Alain Hsiung
Ideartis Inc.

Originally posted by allison ai:
Hi Alain, Thanks so very much for your reply! I got too busy with other stuff and had not checked the forum for a couple of days. Your reply has clarified things for me. One more question, could you please point to a source, with a component diagram example would be ideal, that illustrates (at least to a certain degree if not completely) your understanding of component diagrams, which seems to be in accordance with that adopted by the assignment. Thanks again!


Hi Allison
- the book "developing enterprise java applications with J2EE and UML" p.166-172 + p.268-171, presents components diagrams: web components diagram with JSP, Servlets, HTML pages components and their relationship, as well as EJB components diagram with xxHome, xxRemote, xxEJB classes (which is IMHO too fine grained). The book is really bad (nothing I could learn or use anyhow) but the example of the web components diagram gives an idea of how to make it for the exam (this is the only appropriate diagram I've seen and it's only a few components). On the other hand the EJB components diagram gives you an example of how not to do it.
- UML component diagram guidelines http://www.modelingstyle.info/componentDiagram.html is misleading because the components of the component diagram are in fact packages. So this is an example of wrong granularity (too coarse grained) for components.
- I don't know of any other resources, unfortunately. I've never seen a big picture of a components diagram for J2EE at the right granularity.
- What is important (beside the granularity) is to represents all the (directional) relationhips and to label (consistantly) the semantic of those relationships. E.g. "build" (between a JSP and a HTML page), "submit" between a form and a servlet, "use bean", "has", "call", etc.
Regards
Alain Hsiung
Ideartis inc.

Originally posted by sh yh:
Hi Alain,
I have one question which would happen in a real-world application. Assume there is a LoginProcessor for processing clients' logins through different kinds of UIs. Will you present this LoginProcessor as a Session Bean or just a Plain Old Java Object? Thank you.


Login service can be considered a common service to both presentation layers (web-UI and Java-GUI) and the login UIs should be different depending on the presentation layer (web-UI should have a kind of Servlet and Java-GUI should have a kind of JPanel). There are many ways to implement the Login service (as EJB, directly as Database call through JDBC, etc.). This is up to you.
Regards
Alain Hsiung
Ideartis Inc.

Originally posted by Pijush Das:
Congrats on your great success!!
As I'm working on part 2, I've question for you.
1.How do you incorporate TransMaster(Credit Card Authentication System)into your diagram?
2.For alternative flow did you draw seperate sequence diagram?
3.What is meant by "Equipment" (Specified in the BDM) in flight?
I would be thankful for your reply.
Thanks in advance,
Pijush


Hi
1. I cannot answer this question (it's too specific).
2. I draw alternative flow on the same sequence diagram, adding a comment to make it clear.
3. sorry again, this question is too specific..
Regards
Alain Hsiung
Ideartis Inc.

Originally posted by allison ai:
Congrats, Alian!
I have been struggling with the component diagram(s) for a while. I would appreciate your comments very much and thanks in advance!
The component diagram counts a significant portion of the total score, so it should be fairly complex, at least when compared to the sequence diagrams. But my component diagrams are more like those in the Case Study chapter of Cade's Study Guide book, i.e. they look quite straightforward and simple: no specific JSPs, Servlets, or EJBs, only components (abstraction entities, each contains specific JSPs, Servlets, or EJBs). For example, my diagrams contain basic components like user view, web controller, request filter, EJB controller, session facade, etc.
What troubles me are the two generic issues regarding component diagrams in UML (I hope my questions are not revealing the specifics of the assignment too much):
1. How to include all JSPs, Servlets, and EJBs in component diagrams in general UML drawing? My reading of the requirement is to include all SPECIFIC JSP pages, Servlets, EJBs and other JavaBeans in the diagram. Am I right? But I thought a component diagram is a way of showing how the application is broken down into different components (more like sub-systems, not individual objects) and how those components interact with / depend on one another. I have been searching other books and online resources, but not found answers yet. What I have done so far is to list those individual concrete objects under the components they belong to as a note under each diagram. E.g., a search JSP page belongs to the user view component. I doubt this is the right way to do it.
2. How to show the design patterns in component diagrams? E.g. a command pattern is implemented by a couple of specific objects, which all belong to the EJB controller component in my design. Since those concrete objects are not shown in my diagram, but only listed in the note attached to the diagram, how can the command pattern be illustrated in the diagram then? Since I have included all specific objects in my class diagram, including JSPs and Servlets, the patterns are shown more clearly there. But again, I am not sure if it is acceptable.
Thanks again!


Hi Allison
1. About granularity of components. One way to see components is as sub-systems. The goal is to define a service. The other way is to see components as the (technology dependent) entities that an architect can define and a developer implement. The goal is to define the "interface" between the architect and the developer. For this goal a component "EJB" with the stereotype SFSB is the right level of granularity, as well as "JSP", "Servlet", etc. because the developer knows what to do to implement an EJB (define remote and home interface, implement the class, define XML descriptor). The component "EJB" includes 3-4 java classes and 2 descriptors (1 standard and 1 vendor specific). The developer understands the architect speeking about "EJB".
For components (as sub-systems) I used packages (not components). A packages contains many components.
A component diagram is a way to communicate the technological decision of an architect to a developer. NB: a class diagram does not do that.
Your're right, there is almost no litterature about component diagram's goal and granularity of components (of the diagram). The book "Developing enterprise application with J2EE and UML" for example is very misleading in this respect because it propose a very low level component granularity (class level). I do not agree with this view. In my understanding, the class diagram (+ sequence diagram for the dyanmic aspect) is the way to communicate the requirements from the domain expert to the architect and the component diagram is the way to communicate technical decisions from the architect to the developer.
2. Design patterns can be represented with stereotypes and/or comments.
Regards
Alain Hsiung
Ideartis inc.

Originally posted by Roger Zacharias:
Hi Alain,
concratz!!!
Concerning your class-diagram (I think this is the crux in most assignments and you have negotiated it):
- Did you show attributes and ops in the class diagram?
- How many classes do you have?
- Have you changed the BDM?
- Have you consolidated some BDM classes?
Best regards
Roger


Hi Roger
- yes, I show the attributes and ops in the class diagram
These attributes and ops cover the use cases.
- 22 classes (but you could also get 100% score with a different number of classes)
- yes and no. I started with the Business Domain Model and mainly extended it but I didn't modified it (or only very slightly). I.e. I did't remove classes and modified relationships only very slightly. I basically made the model more precise and absolutely coherent with the use cases.
- yes, I consolidate all BDM classes by taking the use cases, filling the attributes and ops of each BDM classes, eventually adding new classes (because the use case requires it), making the relationship more precise (directionality, cardinality, has-a relationship, etc.) and adding more relationships (again because the use case requires it).
Regards
Alain Hsiung
Ideartis inc.

Originally posted by sh yh:
congratulations alain!
I couldn't figure out a clean way to express the idea of scalability or performance in either a class diagram, a component diagram, or a sequence diagram. Did you stress scalability or performance in any of your diagram?
TIA.


You are right, scalability and performance are not shown in diagrams so you cannot express them in part II. The 4 questions of part III are basically questions on these topics.
Alain Hsiung
Ideartis Inc.

Originally posted by Bijan Mohanty:
Hi Alain,
Thanks again for your input. I have one last question. Did you draw all the jsps in both Component and Sequence diagrams or created one subsystem like GUI subsystem in the diagrams ? Drawing all the JSPs in the component diagram is kinda cluttering my diagram.
Thanks lot.
Bijan


Hi Bijan
- the seq diagram had one GUI subsystem, no further level of details concerning JSPs. But it is certainly allowed to go further in details. Although the examiner don't seem to expect this level of details because I got 100% on seq diagram.
- the component diagram had quite a lot of JSP,etc components but it was manageable. If you have too much of them you can try to represent similar components and relationships with a "template" component and relationship and write a little comment on the template which lists the components that follow this template. E.g. if you have a component A1 and component B1 and a relationship between the two, as well as a component A2 and component B2, A3 and B3, etc. then just represent a template A and B. The comment tells that A1, B1, etc. follows that template. This is just an example. What I mean is that you can find some ways to reduce the number of components without loosing information for the developer. As soon as your component diagram is understandable for a developer I think that the examiner will be happy.
Regards
Alain Hsiung
Ideartis Inc.

Originally posted by Bijan Mohanty:
Hi Alain,
Congratulation for your excellent score and thanks a lot for those informative replies. I have a question on your component diagram. Did you draw all the MVC2 classes in your component diagrams ? What I meant that did you just draw one Abstract Action class in your diagram or drew all the concrete Action classes(For example CreateUserAction etc.) in addition to the interfaces and the Abstract action sand the concrete actions that extends the abstract Action.
Also did you include the WAF(MVC2) classes in your class diagram or you kept it pure domain specific only.
Thanks a bunch in advance.
Bijan



Hi Bijan
excellent question!
In fact I made 2 alternatives of component diagrams: (a) with framework classes and without much domain specific classes and (b) without abstract framework classes and with the precise domain specific classes. I sent only alternative (b) to the submission. Perhaps I lost the 2% there(?)
I cannot answer your question because I was unsure myself about the expectation of the examiner. Perhaps you may begin with 2 alternatives and choose one as soon as you are more confident that one has the right level of details and architectural relevance.
- there should be no technical (MVC2) classes in the class diagram, there should be only domain classes.
Regards
Alain Hsiung
Ideartis Inc.

Originally posted by Jai Thomas:
Hi Alain,
One quick question for you. You have mentioned earlier that you did only one component diagarm. How did you manage to depict all classes in one component diagram without cluttering it? I am thinking of splitting mine into two or three. Do you see a problem with that? (I noticed that the assigment uses the singular term 'Component Diagram')
Thanks in advance
Jai


- I manage to represent all components on 1 diagram by having 4 big subsystems (and 3 very small), within these subsystems components are layouted with some logic so that only very few (4-5) relationships are crossing.
- I think there is no problem with splitting the component diagram into 2-3 subdiagrams as long as the relationships between components over 2 subdiagrams are represented (you have still to think as it would be 1 diagram and not only focus on the subdiagram's components).
Regards
Alain Hsiung
Ideartis Inc.