INCEPTION ELABORATION TRANSITION
Iter 1 Iter 2 Iter 3 Iter 4 Iter 5 Iter 6 Construction
Inception: During the inception phase, you work out the business case for the project. You also will be making a rough cost estimate and return on investment. You should also outline the scope and size of the project.
The fundamental question you ask at the end of this phase: do you and the customer have a shared understanding of the system?
Elaboration: At this stage you have the go ahead of the project however only have vague requirements. So at this stage you need to get a better understanding of the problem. Some of the steps involved are:
What is it you are actually going to build?
How are you going to build it?
What technology are you going to use?
Analysing and dealing with requirement risks, technological risks, skill risks, political risks etc.
Develop a domain model, use case model and a design model. The UML techniques can be used for the model diagrams (e.g. class diagrams, sequence diagrams etc).
An important result of the elaboration phase is that you have a baseline architecture. This architecture consists of:
A list of use cases depicting the requirements.
The domain model, which captures your understanding of the domain with the help of UML class diagrams.
Selection of key implementation technology and how they fit together. For example: Java/J2EE with JSP, Struts, EJB, XML, etc.
The fundamental question you ask at the end of this phase: do you have a baseline architecture to be able to build the system?
Construction: In this phase you will be building the system in a series of iterations. Each iteration is a mini project. You will be performing analysis, design, unit testing, coding, system testing, and integration testing for the use cases assigned to each iteration. The iterations within the construction phase are incremental and iterative. Each iteration builds on the use cases developed in the previous iterations. The each iteration will involve code rewrite, refactoring, use of design patterns etc.
The basic documentation required during the construction phase is:
A class diagram and a sequence diagram.
Some text to pull the diagrams together.
If a class has complex life cycle behaviour then a state diagram is required.
If a class has a complex computation then an activity diagram is required.
The fundamental question you ask at the end of this phase: do you have a developed product?
Transition: During this phase you will be delivering the finished code regularly. During this phase there is no coding to add functionality unless it is small and essential. There will be bug fixes, code optimisation etc during this phase. An example of a transition phase is that the time between the beta release and the final release of a product.
The fundamental question you ask at the end of this phase: are you trying to get the customer to take ownership of the developed product or system?
Q 105: What are the characteristics of RUP? Where can you use RUP? SD A 105:
1. RUP is based on a few important philosophies and principles like planning ahead, knowing where the process is heading and capturing the project in storable and extensible manner.
2. It is largely based on OO analysis and design, and use case driven etc.
3. Iterative and incremental development as oppose to waterfall approach, which hides problems.
4. Architecture centric approach.
RUP is more suited for larger teams of 50-100 people. RUP can also be used as an agile (i.e. lightweight) process for smaller teams of 20-30 people, or as a heavy weight process for larger teams of 50-100 people.
Extreme Programming (XP) can be considered as a subset of RUP. At the time of writing, the agile (i.e lightweight) software development process is gaining popularity and momentum across organizations.
Several methodologies fit under this agile development methodology banner. All these methodologies share many characteristics like iterative and incremental development, test driven development, stand up meetings to improve communication, automatic testing, build and continuous integration of code etc.
Refer Q136 in Enterprise Java section.
Q 106: Why is UML important? SD DC
A 106: The more complicated the underlying system, the more critical the communication among everyone involved in developing and deploying the software. UML is a software blueprint language for analysts, designers and developers. UML provides a common vocabulary for the business analysts, architects, developers etc.
UML is applicable to the Object Oriented problem solving. UML begins with a model; A model is an abstraction of the underlying problem. The domain is the actual world from which the problem comes. The model consists of objects. The objects interact with each other by sending and receiving messages. The objects are characterised by attributes and operations (behaviours). The values of an object’s attributes determine its state. The classes are the blueprints (or like templates) for objects. A class wraps attributes and methods into a single distinct entity. The objects are the instances of classes.
Q 107: What are the different types of UML diagrams? SD DC
A 107: Use case diagrams: Depicts the typical interaction between external users (actors) and the system. The emphasis is on what a system does rather than how it does it. A use case is a summary of scenarios for a single task or goal. An actor is responsible for initiating a task. The connection between actor and use case is a communication association.
Capturing use cases is one of the primary tasks of the elaboration phase of RUP. In its simplest usage, you capture a use case by talking to your users and discussing the various things they might want to do with the system.
When to use ‘use case’ diagrams?
Determining user requirements. New use cases often generate new requirements.
Communicating with clients. The simplicity of the diagram makes use case diagrams a good way for designers and developers to communicate with clients.
Generating test cases. Each scenario for the use case may suggest a suite of test cases.
U s e c a s e d i a g r a m
Class diagrams: Class diagram technique is vital within Object Oriented methods. Class diagrams describe the types of objects in the system and the various static relationships among them. Class diagrams also show the attributes and the methods. Class diagrams have the following possible relationships:
Association: A relationship between instances of 2 classes.
Aggregation: An association in which one class belongs to a collection (does not always have to be a collection. You can also have cardinality of “1”). This is a part of a whole relationship where the part can exist without the whole. For example: A line item is whole and the products are the parts. If a line item is deleted then the products need not be deleted.
Composition: An association in which one class belongs to a collection (does not always have to be a collection. You can also have cardinality of “1”). This is a part of a whole relationship where the part cannot exist without the whole. If the whole is deleted then the parts are deleted. For example: An Order is a whole and the line items are the parts. If an order is deleted then all the line items should be deleted as well (ie cascade deletes).
Generalization: An inheritance link indicating that one class is a superclass of the other. The Generalization expresses the “is a” relationship whereas the association, aggregation and composition express the “has a”
relationship.
Dependency: A dependency is a weak relationship where one class requires another class. The dependency expresses the “uses” relationship. For example: A domain model class uses a utility class like Formatter etc.
C la s s D ia g ra m
Class diagrams are the backbone of Object Oriented methods. So they are used frequently.
Class diagrams can have a conceptual perspective and an implementation perspective. During the analysis draw the conceptual model and during implementation draw the implementation model.
Package diagrams: To simplify complex class diagrams you can group classes into packages.
P a c k a g e D i a g r a m
A c c o u n t i n g O r d e r i n g
C u s t o m e r d e p e n d e n c y
d e p e n d e n c y
When to use package diagrams?
Package diagrams are vital for large projects.
Object diagrams: Object diagrams show instances instead of classes. They are useful for explaining some complicated objects in detail about their recursive relationships etc.
O b j e c t D ia g r a m
D e p a r t m e n t 1
0 .. *
R e c u r s iv e c la s s d ia g r a m d if fic u lt to fu lly u n d e r s ta n d
p h y s ic s M a th s : D e p a r tm e n t
p h y s ic s : D e p a r t m e n t m a t h : D e p a r tm e n t
p u r e M a t h : D e p a r t m e n t a p p lie d M a t h : D e p a r t m e n t
O b j e c t D ia g r a m
C la s s D ia g r a m
im p r o v e c la r ity
S h o w s t h e d e t a ils o f t h e r e c u r s iv e o b je c t r e la t io n s h ip C la s s n a m e o b j e c t n a m e
When to use object diagrams?
Object diagrams are a vital for large projects.
They are useful for explaining structural relationships in detail for complex objects.
Sequence diagrams: Sequence diagrams are interaction diagrams which detail what messages are sent and when. The sequence diagrams are organized according to time. The time progresses as you move from top to bottom of the diagram. The objects involved in the diagram are shown from left to right according to when they take part.
a n O r d e r : O r d e r a n E n t r y : O r d e r E n t r y
m a k e A n O r d e r ( ) m a k e A n O r d e r ( )
i t e r a t i o n [ f o r e a c h . . . ] ( )
c o n f ir m : C o n f ir m a t io n h a s S u f f ic ie n t D e t a ils ( )
p r in t C o n f ir m a t io n ( )
c h e c k if s u f f ic ie n t d e t a ils a r e a v a ila b le f o r e a c h lin e I t e m c lie n t
S e q u e n c e D i a g r a m
N o t e : E a c h v e r t ic a l d o t t e d lin e is a l i f e l i n e . E a c h a r r o w is a m e s s a g e . T h e r e c t a n g u la r b o x e s o n t h e lif e lin e a r e c a lle d t h e a c t i v a t i o n b a r w h ic h r e p r e s e n t s t h e d u r a t io n o f e x e c u t io n o f m e s s a g e .
Collaboration diagrams: Collaboration diagrams are also interaction diagrams. Collaboration diagrams convey the same message as the sequence diagrams. But the collaboration diagrams focus on the object roles instead of the times at which the messages are sent.
The collaboration diagrams use the decimal sequence numbers as shown in the diagram below to make it clear which operation is calling which other operation, although it can be harder to see the overall sequence. The top-level message is numbered 1. The messages at the same top-level have the same decimal prefix but different suffixes of 1, 2 etc according to when they occur.
Collaboration Diagram
client
anOrder : Order
1.1 : makeAnOrder()
anEntry : OrderEntry
1
*
confirm : Confirmation
1.1.1: makeAnOrder() 1.1.1.2 : hasSufficientDetails()
1.1.1.1: for each (iteration)
object
message sequence
number
self-link
When to use interaction diagrams?
When you want to look at behaviour of several objects within a single use case. If you want to look at a single object across multiple use cases then use statechart diagram as described below.
State chart diagrams: Objects have behaviour and state. The state of an object is depends on its current activity or condition. This diagram shows the possible states of the object and the transitions that cause a change in its state.
C h e c k in g s ta te D is p a tc h in g s ta te
w a itin g s ta te D e liv e r e d s ta te
/ g e t a n ite m
/ s o m e ite m s n o t in s to c k
/ a ll ite m s a v a ila b le
/ ite m s r e c e iv e d
/ d e liv e r
S t a t e c h a r t D ia g r a m
When to use statechart diagram?
Statechart diagrams are good at describing the behaviour of an object across several use cases. But they are not good at describing the interaction or collaboration between many objects. Use interaction and/or activity diagrams in conjunction with a statechart diagram.
Use it only for classes that have complex state changes and behaviour. For example: the User Interface (UI) control objects, Objects shared by multi-threaded programs etc.
Activity diagram: This is really a fancy flow chart. The activity diagram and statechart diagrams are related in a sense that statechart diagram focuses on object undergoing a transition process and an activity diagram focuses on the flow of activities involved in a single transition process.
Activity Diagram
get first item check next item
W ait for item s to arrive in stock
dispatch all item s
/ som e item s not in stock
/ All item s in stock
place an order with the supplier receive the order and enter into stock
O rder placem ent departm ent dispatch departm ent
swim lane
start
activity
join
In domain modelling it is imperative that the diagram conveys which object (or class) is responsible for each activity. Activity diagrams can be divided into object swimlanes that determine which object is responsible for which activity. The swimlanes are quite useful because they combine the activity diagram’s depiction of logic with the interaction diagram’s depiction of responsibility. A single transition comes out of each activity, connecting to the next activity. A transition may join or fork.
When to use activity diagrams?
The activity and statechart diagrams are generally useful to express complex operations. The great strength of activity diagrams is that they support and encourage parallel behaviour. The activity and statechart diagrams are beneficial for workflow modelling with multi-threaded programming.
Component and Deployment diagrams: A component is a code module. Component diagrams are physical diagrams analogous to a class diagram. The deployment diagrams show the physical configuration of software and hardware components. The physical hardware is made up of nodes. Each component belongs to a node.
Component and Deployment Diagram
Wholesaler J2EE application server Ratailer J2EE Server
Order Component Dispatch Component
DispathIF OrderIF
Order Component
OrderIF
Q 108: What is the difference between aggregation and composition? SD DC A 108:
Aggregation Composition
Aggregation: An association in which one class belongs to another class or a collection. This is a part of a whole relationship where the part can exist without the whole. For example: A line item is whole and the products are the parts. If a line item is deleted then the products need not be deleted. (no cascade delete in database terms)
Composition: An association in which one class belongs to another class a collection. This is a part of a whole relationship where the part cannot exist without the whole. If the whole is deleted then the parts are deleted. For example: An Order is a whole and the line items are the parts. If an order is deleted then all the line items should be deleted as well (i.e. cascade deletes in database terms).
Aggregations are not allowed to be circular. In a garbage-collected language like Java, The whole has the responsibility of preventing the garbage collector to prematurely collect the part by holding reference to it.
Q 109: What is the difference between a collaboration diagram and a sequence diagram? SD DC A 109: You can automatically generate one from the other.
Sequence Diagram Collaboration Diagram
The emphasis is on the sequence. The emphasis is on the object roles
Reference: The above section on RUP & UML is based on the book UML Distilled by Martin Fowler and Kendall Scott. If you would like to have a good understanding of UML & RUP, then this book is recommended.
Enterprise - Struts
Struts is a Web-based user interface framework, which has been around for a few years. It is a matured and proven framework, which has been used in many J2EE projects. While Struts has been demonstrating its popularity, there is an emerging framework called JavaServer Faces (JSF) gaining lots of momentum and popularity. Like Struts, JSF provides Web application life cycle management through a controller servlet, and like Swing, JSF provides a rich component model complete with event handling and component rendering. So JSF can be considered as a combination of Struts frame work and Java Swing user interface framework. Refer Q19 – Q20 in Emerging Technologies/Frameworks section for JSF.
Q 110: Give an overview of Struts? SF DP
A 110: Struts is a framework with set of cooperating classes, servlets and JSP tags that make up a reusable MVC 2 design.
S T R U T S O v e r v ie w
C l i e n t ( B R O W S E R )
V i e w ( JS P )
A c ti o n (c a lls b u s in e s s lo g ic )
M o d e l ( F o r m b e a n s )
1. HT TP request 2 . D ispa tc h
3. Instantiate/ Set
5 . g e t th r o u g h T a g 6. HTT
P resp o nse
4. Foprward
F r o n t C o n tr o l l e r
(S e rvle t )
s t r u t s -c o n f ig .x m l
Client (Browser): A request from the client browser creates an HTTP request. The Web container will respond to the request with an HTTP response, which gets displayed on the browser.
Controller (ActionServlet class and Request Processor class): The controller receives the request from the browser, and makes the decision where to send the request based on the struts-config.xml. Design pattern: Struts controller uses the command design pattern by calling the Action classes based on the configuration file struts-config.xml and the RequestProcessor class’s process() method uses template method design pattern (Refer Q11 in How would you go about … section) by calling a sequence of methods like:
• processPath(request, response) Æ read the request URI to determine path element.
• processMapping(request,response) Æ use the path information to get the action mapping
• processRoles(request,respose,mapping) Æ Struts Web application security which provides an authorization scheme. By default calls request.isUserInRole(). For example allow /addCustomer action if the role is executive.
<action path=”/addCustomer” roles=”executive”>
• processValidate(request,response,form,mapping) Æ calls the vaildate() method of the ActionForm.
• processActionCreate(request,response,mapping)Æ gets the name of the action class from the “type”
attribute of the <action> element.
• processActionPerform(req,res,action,form,mapping) Æ This method calls the execute method of the Action class which is where business logic is written.
Business Logic (Action class): The Servlet dispatches the request to Action classes, which act as a thin wrapper to the business logic (The actual business logic is carried out by either EJB session beans and/or plain Java classes). The action class helps control the workflow of the application. (Note: The Action class should only control the workflow and not the business logic of the application). The Action class uses the Adapter design pattern (Refer Q11 in How would you go about … section).
ActionForm class: Java representation of HTTP input data. They can carry data over from one request to another, but actually represent the data submitted with the request.
View (JSP): The view is a JSP file. There is no business or flow logic and no state information. The JSP should just have tags to represent the data on the browser.
ActionServlet class is the controller part of the MVC implementation and is the core of the framework. It processes user requests, determines what the user is trying to achieve according to the request, pulls data from the model (if necessary) to be given to the appropriate view, and selects the proper view to respond to the user.
As discussed above ActionServlet class delegates the grunt of the work to the RequestProcessor and Action classes.
The ActionForm class maintains the state for the Web application. ActionForm is an abstract class, which is subclassed for every input form model. The struts-config.xml file controls, which HTML form request maps to which ActionForm.
The Action class is a wrapper around the business logic. The purpose of the Action class is to translate the HttpServletRequest to the business logic. To use the Action class, subclass and overwrite the execute() method.
The actual business logic should be in a separate package or EJB to allow reuse of business logic in protocol independent manner (ie the business logic should be used not only by HTTP clients but also by WAP clients, EJB clients, Applet clients etc).
The ExceptionHandler can be defined to execute when the Action class’s execute() method throws an Exception.
For example
<global-exceptions>
<exception key="my.key" type="java.io.IOException" handler="my.ExceptionHandler"/>
</global-exceptions>
When an IOException is thrown then it will be handled by the execute() method of the my.ExceptionHandler class.
The struts-config.xml configuration information is translated into ActionMapping, which are put into the ActionMappings collection.
Further reading is recommended for more detailed understanding.
Q 111: What is a synchronizer token pattern in Struts or how will you protect your Web against multiple submissions?
DC DP
A 111: Web designers often face the situation where a form submission must be protected against duplicate or multiple submissions. This situation typically occurs when the user clicks on submit button more than once before the response is sent back or client access a page by returning to the previously book marked page.
A 111: Web designers often face the situation where a form submission must be protected against duplicate or multiple submissions. This situation typically occurs when the user clicks on submit button more than once before the response is sent back or client access a page by returning to the previously book marked page.