Dear ranchers here is another successful story. ;-)
Grade: P Score: 91 Comment: This report shows the total points that could have been awarded in each section and the actual amount of points you were awarded. This information is provided in order to give you feedback on your relative strengths on a section basis. The maximum number of points you could have received is 100, minimum to pass is 70. Class Diagram (44 maximum) .......................... 39 Component Diagram (44 maximum) ...................... 40 Sequence/Colloboration Diagrams (12 maximum) ........ 12
First and more importantly... BIG THANKS to all ranchers, everybody who has contributed to my and all other posts giving tips, hints, and suggestions.. and making Javaranch undoubtedly the best resource for preparing SCEA. My 2 cents:
- FIRST RULE OF THE SCEA CLUB: never talk about the SCEA Club ;-)
- SECOND RULE: SCEA is a huge opportunity for learning and as such should be conceived. Spend time in searching/using the material, make your own effort... looking for help for your specific assignment is really useless (I guess we all feel the same at the beginning, we want to make it quick and good, but what you actually learn at the end of SCEA is the real amazing achievement).
- Resources: JavaRanch of course, Cade book, and all other resources pointed out on this site. For PART ONE I used Whizlab simulator: my experience with Whizlab for my other certification was really positive so I decided to adopt the same approach.
- Preparation time: really depends on your background skill. Part One took me 2 weeks (over a couple of month period), Part Two took me a while (I reckon 80/100 hrs over a period of 4 months). I wasn't really familiar with EJB (where I had to invest most time) but quite good with UML and patterns.
- Part 2: I read the assignment 2/3 times, waited a little bit before starting. Try to understand the requirements and to have a clear picture of the system. I used Javaranch a lot for Part 2, following debates between candidates helped me to see new perspective, to elaborate some of my ideas.
- One component diagram (supporting both GUI and web)
- One class diagram with 18 classes, only relevant methods and attributes are displayed. I indicated multiplicity, navigation, dependency/aggregation/composition
- One deployment diagram: this is not required but I thought it would be help to understand the design.
- 4 sequence diagrams: one per requirement. For each diagram I added few notes to explain how the diagram would change to support a different front-end or an alternative path in the requirement. For instance, I designed a diagram for Web booking with user not logged on, then in my notes I added how to support the booking when the user has already logged on, or when it is the Travel Agent performing the reservation.
- Revision: I have revised the diagrams repeatedly, paying max attention to all details especially towards the end when my decisions looked convincing and I was quite confident about my design.
Ciao Beps
Beppe Catanese
Greenhorn
Joined: Nov 07, 2006
Posts: 27
posted
0
My study notes for Part One (I though they would help).
default transaction attribute - do not exist, must be specified by the deployer
EJB Message Driven - component interface in EJB 2.0
CMT: Entity bean can be either CMP or BMP. CMP Entity can only use CMT. Session bean can use either CMT or BMT. Session bean cannot be CMP, but only BMP.
patterns
## fast lane reader ############################################################################################## Obj: System accesses lists of read-only data in a tabular fashion. Solution: JDBC access to DB and provide data to clients in a tabular format Note: data might be stale, only for read-only, increases complexity (another way to access data)
## proxy pattern ################################################################################################# Obj: need a more sophisticated reference to an object than a simple pointer Solution: Control access to an object with a proxy (also known as a surrogate or placeholder). Note: hide location of the object (remote proxy). Virtual proxy: Allows the creation of a memory intensive object on demand. The object will not be created until it is really needed. Protection proxy - The proxy insures security EJBRemote Interface implements proxy pattern
## Strategy ####################################################################################################### Obj: Algorithms must be selected on the fly at run-time Solution: define a group of classes that represent a set of possible behaviors Note: The strategy pattern is useful for situations where it is necessary to dynamically swap the algorithms used in an application. The strategy pattern is intended to provide a means to define a family of algorithms, encapsulate each one as an object, and make them interchangeable. The strategy pattern lets the algorithms vary independently from clients that use them. Alternative to subclassing Each behaviour in a different class (no IF statement) Easier to extend model (adding behaviour) SSL
## Template pattern ############################################################################################### Obj: define an invariant part of an algorithm and leave sub classes to implement some parts Solution: Define skeleton (abstract class) with basic steps and defer some implentation to sub-classes Note: avoid code duplication (template stores the common its) Control subclassing Inversion of control implements template pattern
Strategy VS Template:
Strategy is used to allow callers to vary an entire algorithm, while Template Method is used to vary steps in an algorithm. Strategy is more coarsely grained (change entire structure). The Template allows finer-grained controls (change details).
## Interpreter pattern ############################################################################################ Obj: interpret language Solution: implement a specialised language to solve a defined class of problems Note: grammar of the language is simple, define specialised language (SQL)
## Mediator pattern ############################################################################################### Obj:need a unified interface to manage groups/collections of objects Solution: introduce one object in the middle to enable communications between different objects Note: promote loose coupling since classes communicate via the mediator (the only one who must know detailed methods of classes) can co-ordinate state changes between other objects by using one object (promotes centralised control) individual classes are simpler: they do not need to pass directly messages to each other
## Value List Handler ################################################################################################# Obj: client requires list of values, size is unknown and can be large Solution: create object which retrieves the data, caches the results, provide results to the clients Note: ValueListHandler implements an Iterator pattern
## Iterator ############################################################################################################## Obj: need a way to access items in a collection, must be independent from underlying collection Solution: introduce Iterator object which incapsulate the collection Note: simplify access to collection, support variations in the traversal and structure, do not expose underlying collection
## Value object pattern ################################################################################################### Similar to Transfer Object
--------------
n-tiers: client (browser, applet, application, mobile) Web (presentation & controller - jsp and servlet) EJB Tier (Business Tier, EJB and supporting classes) EIS Integration Tier (classes which integrate to the Enterprise Information System ) EIS Tier (DB, ERP, etc...)
defined and undefined primary key
Primary key: must implement java.io.Serializable (that is valid Java RMI type), must provide default constructor (for CMP), must override hashCode() and equals() all fields in the primary key class be declared public (reflection) CMP: undefined primary key (defined in ejb descriptor by deployer)
ObjectNotFoundException is an application exception: thrown when entity not found by find method CreateException, RemoveException, FindException Application exceptions are thrown in response to errors encountered in the business logic, they do not cause transactions to rollback EJBException (and RunTime exceptions) causes a transaction to be rolled back and the bean instance to be destroyed.
Passivation: ejbPassivate is invoked, the bean can close all resourses and set non-transient non-serializable fields to null
EJB: non-transient non-serializable fields
Maintainability is the ability to correct flaws in the existing system without impacting other components on the system
Manegeability is the ability to manage the system to ensure the health of the system
---------------
Primary key Class (must implement Serializable, must provide default constructor, must override hashcode/equals, can be undefined until deployment
Transactions are flat not nested, they can span multiple servers
JTA Java Transaction API (part of J2EE, supported by EJB container)
JTS Java Transaction Service: implementation of a Transaction Manager which supports JTA
Entity bean: findByPrimaryKey is the only mandatory method in the home IF
signature ejbFind, ejbCreate, ejbRemove callback methods: for each method in HOME IF (create, find, remove) define callback in BEAN class (ejbCreate, ejbRemove, ejbFind) all throw java.rmi.RemoteException ejbCreate returns: Primary Key for Entity BMP null for Entity CMP void for Session
EJB: bean class must implement methods defined in home IF, remote IF and callback methods
------------------
JMS multiple msg as part of the transaction: client is responsible for commiting/rolling back the transaction
sync entity bean state with undelying db: ejbLoad and ejbStore
services provided by JMS: persistence, transaction, verification
how do you remove an EJB: home.remove(handle), home.remove(Object), remote.remove()
Performance: RMI-JRMP vs RMi-IIOP JRMP is the native protocol for RMI and is not required to support many different data formats (JRMP more performing)
JMS: EJB for sending messages EJB 1.1 both Entity and Session beans can be used to receive sync messages EJB 2.0 introduces Message Driven Bean (can receive async messages)
UML diagrams: name in italic indicates abstract class
------------------------------------
UML for node, component, package, use case (oval)
## Composite Pattern ############################################################################## Compose objects into tree structures to represent whole-part hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly minimise the complexity of an object that consists of many objects can easily add new types of components Composite can be traversed with Iterator. when containee (individual objects) can be container too
Applet: - can never change system properties - can read system properties (depending on config user's browser) - some props can be read by signed applet, other props do not require the applet to be signed - cannot call OS (cannot change priority of the thread created to run the applet) - can create new threads - security manager do not control CPU/RAM/network bandwidth - general OS allocates memory for an applet but some OS might allocate more if the applet requests it - (security policy file) java.policy contains class permissions
DAO with Entity Bean reduces dependence on the DB
## command pattern ##################################################################### Uses objects to represent actions : a command object encapsulates an action and its parameters. can pass objects to client, queue requests Treating commands as objects supports undo-able operations, provided that the command objects are stored (stack) Usage: - multi-level Undo: if all actions are commands can be stored in a stack and recall for undo - Transaction: if you treat the Undo as Rollback then it is a transaction. Installers and DB use this - Progress bar: if each command has a getDuration then it is possible to estimate the total duration of the job (all tasks) - Wizard (installation): each page defines a command, all commands are executed after the last page - Pool of threads: if the class has addTask(Runnable task) it can accept and run any thread (command)
## prototype pattern ######################################################################## the type of objects to create is determined by a prototypical instance (cloning) - handy when the standard creation (constructor) is expensive - prototype defines clone() abstract method and subclasses implement the clone
## decorator pattern ########################################## allows new/additional behaviour to be added to an existing method of an object dynamically. Decorator is designed to let you add responsibilities to objects without subclassing (Subclassing adds behaviour at compile-time whereas decorators provide new behaviour at runtime.) Decorator wraps original object (obj passed as parameter in the Decorator constructore) and adds extra functionality Java I/O Streams implementation use decorator, servler filters Browser: displays the html page and add scrollbar (the decoration) when required
-----------------------------
JCA: While JDBC is specifically used to connect Java EE applications to databases, JCA is a more generic architecture for connection to legacy systems (including databases).
EJB deployment descriptor timeout: EJB 1.0 allows timeout in deployment descriptor, EJB 1.1 is done in a vendor-specific manner
transaction scope: defined at bean level (all methods have same scope) CMT or BMT
Memento Design Pattern used for ejb passivation
CORBA does not provide CMP (persistence), supports security, transaction, naming
HW/SW clustering: ensure scalability (easing the load) and availability (one goes down, the peer can take over - depends on the type of cluster)
B2B hub/spoke/exchange
Spoke: cheap view on the partner data - only requires browser, limited view (one spoke per business) exchange: use intermediate third-party that handles infrastructure, partners submit and access data, several partners but maybe not all Hub: company aggregates its entire data demand (partners, internal, exchanges), expensive
Hello Beppe, I have heard other successful stories of other ranchers and they have shown much no of more classes than 18 classes, as in your class diagram. As I am preparing for Step2 so kind of confused that a very high level class diagram is okay or it has to be detailed?
regards, Amit
Deiveehan Nallazhagappan
Ranch Hand
Joined: May 27, 2002
Posts: 33
posted
0
Congrats Beppe..
Deiveehan N - SCJP, SCWCD, SCBCD, IBM-484, SCEA
You may be in the right track, but if you sit there, you will get run over !!
Shashi Agrawal
Greenhorn
Joined: Aug 02, 2007
Posts: 9
posted
0
much no of more classes == much more number of classes
Beppe Catanese
Greenhorn
Joined: Nov 07, 2006
Posts: 27
posted
0
Originally posted by Shashi Agrawal: Hello Beppe, I have heard other successful stories of other ranchers and they have shown much no of more classes than 18 classes, as in your class diagram. As I am preparing for Step2 so kind of confused that a very high level class diagram is okay or it has to be detailed?
regards, Amit
Hi Sashi I think the high level class diagram is fine, as long as it fits well in your architecture and with the other diagrams. I don't think it's about providing as much details as we can, but what really matters is that the architecture addresses the requirements and the choices we make are explained. I even remember a post of somebody scoring 100% with a very high-level diagram (very few classes, no attributes/methods).
Good luck!
Beps
Shashi Agrawal
Greenhorn
Joined: Aug 02, 2007
Posts: 9
posted
0
Thanks for sharing your thoughts. and congratulations on your success
0
