Download - SL-IV Lab Manual
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 1/35
Assignment No: 1
Purpose: Understanding the implementation details of relationshipsamong classesLab pre work: Prepare a class diagram from the given problem description usingUML2.0notations.
Laboratory work: mplement the class diagram with a suitable ob!ect orientedlanguage.
Theory:
Class Diagrams
Class diagrams are visual representations of the static structure and composition of a particular
system using the conventions set by the Unified Modeling Language (UML). Out of all the UML
diagram types it is one of the most used ones. System designers use class diagrams as a way of
simplifying how obects in a system interact with each other. Using class diagrams! it is easier to
describe all the classes! pac"ages! and interfaces that constitute a system and how these
components are interrelated. #or e$ample! a simple class diagram may be used to show how an
organi%ation such as a convenient store chain is set up. On the other hand! precisely detailed
class diagrams can readily be used as the primary reference for translating the designed system
into a programming code.
&he following figure is an e$ample of a simple class diagram'
Simple class diagram with attributes and operations
n the e$ample! a class called loan account* is depicted. Classes in class diagrams are
represented by bo$es that are partitioned into three'
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 2/35
". #he top partition contains the name of the class.
2. #he middle part contains the class$s attributes.
%. #he bottom partition shows the possible operations that are associated withthe class.
&hose should be pretty easy to see in the e$ample' the class being described is a loan account!
some of whose attributes include the type of loan! the name of the borrower+loaner! the specificdate the loan was released and the loan amount. ,s in the real world! various transactions or
operations may be implemented on e$isting loans such as renew and e$tend. &he e$ample shows
how class diagrams can encapsulate all the relevant data in a particular scenario in a very
systematic and clear way.
n obect-oriented modeling! class diagrams are considered the "ey building bloc"s that enable
information architects! designers! and developers to show a given systems classes! their
attributes! the functions or operations that are associated with them! and the relationships among
the different classes that ma"e up a system.
Relationships in Class Diagrams
Classes are interrelated to each other in specific ways. n particular! relationships in class
diagrams include different types of logical connections. &he following are such types of logical
connections that are possible in UML'
• &ssociation
• 'irected &ssociation
• (e)e*ive &ssociation
• Multiplicity
• &ggregation
• +omposition
• nheritance,-eneraliation
• (ealiation
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 3/35
Association
,ssociation
is a broad term that encompasses ust about any logical connection or relationship between
classes. #or e$ample! passenger and airline may be lin"ed as above'
Directed Association
/irected ,ssociation
refers to a directional relationship represented by a line with an arrowhead. &he arrowhead
depicts a container-contained directional flow.
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 4/35
Reexive Association
0efle$ive ,ssociation
occurs when a class may have multiple functions or responsibilities. #or e$ample! a staff
wor"ing in an airport may be a pilot! aviation engineer! a tic"et dispatcher! a guard! or a
maintenance crew member. f the maintenance crew member is managed by the aviation
engineer there could be a managed by relationship in two instances of the same class.
Multiplicity
Multiplicity
is the active logical association when the cardinality of a class in relation to another is being
depicted. #or e$ample! one fleet may include multiple airplanes! while one commercial airplane
may contain %ero to many passengers. &he notation 1..2 in the diagram means %ero to many*.
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 5/35
Aggregation
,ggregation
refers to the formation of a particular class as a result of one class being aggregated or built as a
collection. #or e$ample! the class library* is made up of one or more boo"s! among other
materials. n aggregation! the contained classes are not strongly dependent on the life cycle of the
container. n the same e$ample! boo"s will remain so even when the library is dissolved. &o
render aggregation in a diagram! draw a line from the parent class to the child class with a
diamond shape near the parent class.
Composition
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 6/35
is very similar to the aggregation relationship! with the only difference being its "ey purpose of
emphasi%ing the dependence of the contained class to the life cycle of the container class. &hat
is! the contained class will be obliterated when the container class is destroyed. #or e$ample! a
shoulder bags side poc"et will also cease to e$ist once the shoulder bag is destroyed. &o depict a
composition relationship in a UML diagram! use a directional line connecting the two classes!
with a filled diamond shape adacent to the container class and the directional arrow to the
contained class.
nheritance ! "enerali#ation
nheritance
refers to a type of relationship wherein one associated class is a child of another by virtue of
assuming the same functionalities of the parent class. n other words! the child class is a specifictype of the parent class. &o depict inheritance in a UML diagram! a solid line from the child class
to the parent class is drawn using an unfilled arrowhead.
Reali#ation
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 7/35
0eali%ation
denotes the implementation of the functionality defined in one class by another class. &o show
the relationship in UML! a bro"en line with an unfilled solid arrowhead is drawn from the class
that defines the functionality to the class that implements the function. n the e$ample! the
printing preferences that are set using the printer setup interface are being implemented by the
printer.
Conclusion $ Class diagram relationships are easy to understand
f you are a programmer or systems designer! youll be building or analy%ing class diagrams
3uite often since they are! after all! the building bloc"s of obect-oriented modeling. ,s
demonstrated by this article! class diagram relationships are fairly easy to understand. ,s a rule
of thumb! "eeping class diagrams as simple as possible allows them to be more easily understood
and appreciated by different types of audiences. #or this purpose! remember to label your classes
and relationships as descriptive as possible. Lastly! class diagrams also evolve as the real world
systems they represent change. &his implies that you dont need to put in much detail in your
first draft. ,ll the classes! interfaces and relationships that are integral to the system or
application you are designing will eventually emerge as the development process moves forward.
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 8/35
Assignment No: 2
Purpose: mplementation of a design modelLab pre work: Prepare a design model from analysis model in the form of UML 2class diagram.
Laboratory work: mplement the design model with a suitable ob!ect orientedlanguage
Overview:
&he class diagram is a static diagram. t represents the static view of an application. Classdiagram is not only used for visuali%ing! describing and documenting different aspects of a
system but also for constructing e$ecutable code of the software application.
&he class diagram describes the attributes and operations of a class and also the constraints
imposed on the system. &he class diagrams are widely used in the modelling of obect orientedsystems because they are the only UML diagrams which can be mapped directly with obect
oriented languages.
&he class diagram shows a collection of classes! interfaces! associations! collaborations andconstraints. t is also "nown as a structural diagram.
Purpose:
&he purpose of the class diagram is to model the static view of an application. &he class
diagrams are the only diagrams which can be directly mapped with obect oriented languages andthus widely used at the time of construction.
&he UML diagrams li"e activity diagram! se3uence diagram can only give the se3uence flow of
the application but class diagram is a bit different. So it is the most popular UML diagram in the
coder community.
So the purpose of the class diagram can be summari%ed as'
• ,nalysis and design of the static view of an application.
• /escribe responsibilities of a system.
• 4ase for component and deployment diagrams.
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 9/35
• #orward and reverse engineering.
How to draw Class Diagram?
Class diagrams are the most popular UML diagrams used for construction of software
applications. So it is very important to learn the drawing procedure of class diagram.
Class diagrams have lot of properties to consider while drawing but here the diagram will beconsidered from a top level view.
Class diagram is basically a graphical representation of the static view of the system andrepresents different aspects of the application. So a collection of class diagrams represent the
whole system.
&he following points should be remembered while drawing a class diagram'
• &he name of the class diagram should be meaningful to describe the aspect of the system.
• 5ach element and their relationships should be identified in advance.
• 0esponsibility (attributes and methods) of each class should be clearly identified.
• #or each class minimum number of properties should be specified. 4ecause unnecessary
properties will ma"e the diagram complicated.
• Use notes when ever re3uired to describe some aspect of the diagram. 4ecause at the end
of the drawing it should be understandable to the developer+coder.
• #inally! before ma"ing the final version! the diagram should be drawn on plain paper and
rewor" as many times as possible to ma"e it correct.
6ow the following diagram is an e$ample of an Order System of an application. So it describes a particular aspect of the entire application.
• #irst of all Order and Customer are identified as the two elements of the system and they
have a one to many relationship because a customer can have multiple orders.
• 7e would "eep Order class is an abstract class and it has two concrete classes
(inheritance relationship) SpecialOrder and NormalOrder .
• &he two inherited classes have all the properties as the Order class. n addition they have
additional functions li"e dispatch () and receive ().
So the following class diagram has been drawn considering all the points mentioned above'
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 10/35
Where to use Class Diagrams?
Class diagram is a static diagram and it is used to model static view of a system. &he static viewdescribes the vocabulary of the system.
Class diagram is also considered as the foundation for component and deployment diagrams.Class diagrams are not only used to visuali%e the static view of the system but they are also used
to construct the e$ecutable code for forward and reverse engineering of any system.
8enerally UML diagrams are not directly mapped with any obect oriented programming
languages but the class diagram is an e$ception.
Class diagram clearly shows the mapping with obect oriented languages li"e 9ava! C:: etc. So
from practical e$perience class diagram is generally used for construction purpose.
So in a brief! class diagrams are used for'
• /escribing the static view of the system.
• Showing the collaboration among the elements of the static view.
• /escribing the functionalities performed by the system.
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 11/35
• Construction of software applications using obect oriented languages.
Assignment %o:&
Purpose: mplementation of a state model from the given description'Lab pre work: Prepare a state model from the given problem description and draw astatediagram using UML2 notationsLaboratory work: mplement the state model with a suitable ob!ect oriented
language
Overview:
&he name of the diagram itself clarifies the purpose of the diagram and other details. t describes
different states of a component in a system. &he states are specific to a component+obect of asystem.
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 12/35
, Statechart diagram describes a state machine. 6ow to clarify it state machine can be defined as
a machine which defines different states of an obect and these states are controlled by e$ternalor internal events.
,ctivity diagram e$plained in ne$t chapter! is a special "ind of a Statechart diagram. ,s
Statechart diagram defines states it is used to model lifetime of an obect.
Purpose:Statechart diagram is one of the five UML diagrams used to model dynamic nature of a system.
&hey define different states of an obect during its lifetime. ,nd these states are changed by
events. So Statechart diagrams are useful to model reactive systems. 0eactive systems can be
defined as a system that responds to e$ternal or internal events.
Statechart diagram describes the flow of control from one state to another state. States are
defined as a condition in which an obect e$ists and it changes when some event is triggered. So
the most important purpose of Statechart diagram is to model life time of an obect from creationto termination.
Statechart diagrams are also used for forward and reverse engineering of a system. 4ut the main
purpose is to model reactive system.
#ollowing are the main purposes of using Statechart diagrams'
• &o model dynamic aspect of a system.
• &o model life time of a reactive system.
• &o describe different states of an obect during its life time.
• /efine a state machine to model states of an obect.
How to draw tate!hart Diagram?
Statechart diagram is used to describe the states of different obects in its life cycle. So the
emphasis is given on the state changes upon some internal or e$ternal events. &hese states of
obects are important to analy%e and implement them accurately.
Statechart diagrams are very important for describing the states. States can be identified as the
condition of obects when a particular event occurs.
4efore drawing a Statechart diagram we must have clarified the following points'
• dentify important obects to be analy%ed.
• dentify the states.
• dentify the events.
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 13/35
&he following is an e$ample of a Statechart diagram where the state of Order obect is analy%ed.
&he first state is an idle state from where the process starts. &he ne$t states are arrived for eventsli"e send request ! confirm request ! and dispatch order . &hese events are responsible for state
changes of order obect.
/uring the life cycle of an obect (here order obect) it goes through the following states and
there may be some abnormal e$ists also. &his abnormal e$it may occur due to some problem in
the system. 7hen the entire life cycle is complete it is considered as the complete transaction asmentioned below.
&he initial and final state of an obect is also shown below.
Where to use tate!hart Diagrams?
#rom the above discussion we can define the practical applications of a Statechart diagram.
Statechart diagrams are used to model dynamic aspect of a system li"e other four diagrams
disused in this tutorial. 4ut it has some distinguishing characteristics for modeling dynamic
nature.
Statechart diagram defines the states of a component and these state changes are dynamic in
nature. So its specific purpose is to define state changes triggered by events. 5vents are internal
or e$ternal factors influencing the system.
Statechart diagrams are used to model states and also events operating on the system. 7henimplementing a system it is very important to clarify different states of an obect during its life
time and statechart diagrams are used for this purpose. 7hen these states and events are
identified they are used to model it and these models are used during implementation of thesystem.
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 14/35
f we loo" into the practical implementation of Statechart diagram then it is mainly used to
analy%e the obect states influenced by events. &his analysis is helpful to understand the system behaviour during its e$ecution.
So the main usages can be described as'
• &o model obect states of a system.
• &o model reactive system. 0eactive system consists of reactive obects.
• &o identify events responsible for state changes.
• #orward and reverse engineering.
Assignment %o:(
Purpose: Preparing an interaction model from the given detailsPrepare a use case model/ seuence model and activity model from the givendescription using
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 15/35
UML 2 notations.
Use Case Diagram:
Overview:
&o model a system the most important aspect is to capture the dynamic behaviour. &o clarify a bit
in details! dynamic behaviour means the behaviour of the system when it is running +operating.
So only static behaviour is not sufficient to model a system rather dynamic behaviour is moreimportant than static behaviour. n UML there are five diagrams available to model dynamic
nature and use case diagram is one of them. 6ow as we have to discuss that the use case diagram
is dynamic in nature there should be some internal or e$ternal factors for ma"ing the interaction.
&hese internal and e$ternal agents are "nown as actors. So use case diagrams are consists ofactors! use cases and their relationships. &he diagram is used to model the system+subsystem of
an application. , single use case diagram captures a particular functionality of a system.
So to model the entire system numbers of use case diagrams are used.
Purpose:
&he purpose of use case diagram is to capture the dynamic aspect of a system. 4ut this definition
is too generic to describe the purpose.
4ecause other four diagrams (activity! se3uence! collaboration and Statechart) are also having the
same purpose. So we will loo" into some specific purpose which will distinguish it from otherfour diagrams.
Use case diagrams are used to gather the re3uirements of a system including internal and
e$ternal influences. &hese re3uirements are mostly design re3uirements. So when a system is
analy%ed to gather its functionalities use cases are prepared and actors are identified.
6ow when the initial tas" is complete use case diagrams are modelled to present the outsideview.
So in brief! the purposes of use case diagrams can be as follows'
• Used to gather re3uirements of a system.
• Used to get an outside view of a system.
• dentify e$ternal and internal factors influencing the system.
• Show the interacting among the re3uirements are actors.
How to draw "se Case Diagram?
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 16/35
Use case diagrams are considered for high level re3uirement analysis of a system. So when the
re3uirements of a system are analy%ed the functionalities are captured in use cases.
So we can say that uses cases are nothing but the system functionalities written in an organi%ed
manner. 6ow the second things which are relevant to the use cases are the actors. ,ctors can be
defined as something that interacts with the system.
&he actors can be human user! some internal applications or may be some e$ternal applications.
So in a brief when we are planning to draw an use case diagram we should have the followingitems identified.
• #unctionalities to be represented as an use case
• ,ctors
• 0elationships among the use cases and actors.
Use case diagrams are drawn to capture the functional re3uirements of a system. So after
identifying the above items we have to follow the following guidelines to draw an efficient usecase diagram.
• &he name of a use case is very important. So the name should be chosen in such a way so
that it can identify the functionalities performed.
• 8ive a suitable name for actors.
• Show relationships and dependencies clearly in the diagram.
• /o not try to include all types of relationships. 4ecause the main purpose of the diagram
is to identify re3uirements.
• Use note when ever re3uired to clarify some important points.
&he following is a sample use case diagram representing the order management system. So if weloo" into the diagram then we will find three use cases (Order! SpecialOrder and 6ormalOrder)
and one actor which is customer.
&he SpecialOrder and NormalOrder use cases are e$tended from Order use case. So they have
e$tends relationship. ,nother important point is to identify the system boundary which is shownin the picture. &he actor Customer lies outside the system as it is an e$ternal user of the system.
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 17/35
Where to "se Case Diagrams?
,s we have already discussed there are five diagrams in UML to model dynamic view of a
system. 6ow each and every model has some specific purpose to use. ,ctually these specific
purposes are different angles of a running system.
So to understand the dynamics of a system we need to use different types of diagrams. Use case
diagram is one of them and its specific purpose is to gather system re3uirements and actors.
Use case diagrams specify the events of a system and their flows. 4ut use case diagram neverdescribes how they are implemented. Use case diagram can be imagined as a blac" bo$ whereonly the input! output and the function of the blac" bo$ is "nown.
&hese diagrams are used at a very high level of design. &hen this high level design is refined
again and again to get a complete and practical picture of the system. , well structured use case
also describes the pre condition! post condition! e$ceptions. ,nd these e$tra elements are used toma"e test cases when performing the testing.
,lthough the use cases are not a good candidate for forward and reverse engineering but still
they are used in a slight different way to ma"e forward and reverse engineering. ,nd the same is
true for reverse engineering. Still use case diagram is used differently to ma"e it a candidate forreverse engineering.
n forward engineering use case diagrams are used to ma"e test cases and in reverse engineering
use cases are used to prepare the re3uirement details from the e$isting application.
So the following are the places where use case diagrams are used'
• 0e3uirement analysis and high level design.
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 18/35
• Model the conte$t of a system.
• 0everse engineering.
• #orward engineering.
)e*uence Diagram:
Overview:
#rom the name Interaction it is clear that the diagram is used to describe some type of
interactions among the different elements in the model. So this interaction is a part of dynamic
behaviour of the system.
&his interactive behaviour is represented in UML by two diagrams "nown as Sequence diagram and Collaboration diagram. &he basic purposes of both the diagrams are similar.
Se3uence diagram emphasi%es on time se3uence of messages and collaboration diagram
emphasi%es on the structural organi%ation of the obects that send and receive messages.
Purpose:
&he purposes of interaction diagrams are to visuali%e the interactive behaviour of the system.
6ow visuali%ing interaction is a difficult tas". So the solution is to use different types of models
to capture the different aspects of the interaction.
&hat is why se3uence and collaboration diagrams are used to capture dynamic nature but from adifferent angle.
So the purposes of interaction diagram can be describes as'
• &o capture dynamic behaviour of a system.
• &o describe the message flow in the system.
• &o describe structural organi%ation of the obects.
• &o describe interaction among obects.
How to draw #ntera!tion Diagram?
,s we have already discussed that the purpose of interaction diagrams are to capture the dynamicaspect of a system. So to capture the dynamic aspect we need to understand what a dynamic
aspect is and how it is visuali%ed. /ynamic aspect can be defined as the snap shot of the running
system at a particular moment.
7e have two types of interaction diagrams in UML. One is se3uence diagram and the other is acollaboration diagram. &he se3uence diagram captures the time se3uence of message flow from
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 19/35
one obect to another and the collaboration diagram describes the organi%ation of obects in a
system ta"ing part in the message flow.
So the following things are to identified clearly before drawing the interaction diagram'
• Obects ta"ing part in the interaction.
• Message flows among the obects.
• &he se3uence in which the messages are flowing.
• Obect organi%ation.
#ollowing are two interaction diagrams modeling order management system. &he first diagram is
a se3uence diagram and the second is a collaboration diagram.
$he e%uen!e Diagram:
&he se3uence diagram is having four obects (Customer! Order! SpecialOrder and 6ormalOrder).
&he following diagram has shown the message se3uence for SpecialOrder obect and the same
can be used in case of NormalOrder obect. 6ow it is important to understand the time se3uence
of message flows. &he message flow is nothing but a method call of an obect.
&he first call is sendOrder () which is a method of Order obect. &he ne$t call is confirm () which is a method of SpecialOrder obect and the last call is Dispatch () which is a method of
SpecialOrder obect. So here the diagram is mainly describing the method calls from one obect
to another and this is also the actual scenario when the system is running.
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 20/35
Where to use #ntera!tion Diagrams?
7e have already discussed that interaction diagrams are used to describe dynamic nature of a
system. 6ow we will loo" into the practical scenarios where these diagrams are used. &o
understand the practical application we need to understand the basic nature of se3uence and
collaboration diagram.
&he main purposes of both the diagrams are similar as they are used to capture the dynamic
behaviour of a system. 4ut the specific purposes are more important to clarify and understood.
Se3uence diagrams are used to capture the order of messages flowing from one obect to another.
,nd the collaboration diagrams are used to describe the structural organi%ations of the obectsta"ing part in the interaction. , single diagram is not sufficient to describe the dynamic aspect of
an entire system so a set of diagrams are used to capture is as a whole.
&he interaction diagrams are used when we want to understand the message flow and the
structural organi%ation. 6ow message flow means the se3uence of control flow from one obectto another and structural organi%ation means the visual organi%ation of the elements in a system.
n a brief the following are the usages of interaction diagrams'
• &o model flow of control by time se3uence.
• &o model flow of control by structural organi%ations.
• #or forward engineering.
• #or reverse engineering.
A!tivit& Diagram:
Overview:
,ctivity diagram is another important diagram in UML to describe dynamic aspects of thesystem.
,ctivity diagram is basically a flow chart to represent the flow form one activity to another
activity. &he activity can be described as an operation of the system.
So the control flow is drawn from one operation to another. &his flow can be se3uential! branched or concurrent. ,ctivity diagrams deals with all type of flow control by using different
elements li"e for"! oin etc.
Purpose:
&he basic purposes of activity diagrams are similar to other four diagrams. t captures thedynamic behaviour of the system. Other four diagrams are used to show the message flow from
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 21/35
one obect to another but activity diagram is used to show message flow from one activity to
another.
,ctivity is a particular operation of the system. ,ctivity diagrams are not only used for
visuali%ing dynamic nature of a system but they are also used to construct the e$ecutable system
by using forward and reverse engineering techni3ues. &he only missing thing in activity diagram
is the message part.
t does not show any message flow from one activity to another. ,ctivity diagram is some timeconsidered as the flow chart. ,lthough the diagrams loo"s li"e a flow chart but it is not. t shows
different flow li"e parallel! branched! concurrent and single.
So the purposes can be described as'
• /raw the activity flow of a system.
• /escribe the se3uence from one activity to another.
• /escribe the parallel! branched and concurrent flow of the system.
How to draw A!tivit& Diagram?
,ctivity diagrams are mainly used as a flow chart consists of activities performed by the system.
4ut activity diagram are not e$actly a flow chart as they have some additional capabilities. &heseadditional capabilities include branching! parallel flow! swimlane etc.
4efore drawing an activity diagram we must have a clear understanding about the elements used
in activity diagram. &he main element of an activity diagram is the activity itself. ,n activity is a
function performed by the system. ,fter identifying the activities we need to understand how
they are associated with constraints and conditions.
So before drawing an activity diagram we should identify the following elements'
• ,ctivities
• ,ssociation
• Conditions
• Constraints
Once the above mentioned parameters are identified we need to ma"e a mental layout of the
entire flow. &his mental layout is then transformed into an activity diagram.
&he following is an e$ample of an activity diagram for order management system. n the diagramfour activities are identified which are associated with conditions. One important point should be
clearly understood that an activity diagram cannot be e$actly matched with the code. &he activity
diagram is made to understand the flow of activities and mainly used by the business users.
&he following diagram is drawn with the four main activities'
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 22/35
• Send order by the customer
• 0eceipt of the order
• Confirm order
• /ispatch order
,fter receiving the order re3uest condition chec"s are performed to chec" if it is normal or
special order. ,fter the type of order is identified dispatch activity is performed and that ismar"ed as the termination of the process.
Where to use A!tivit& Diagrams?
&he basic usage of activity diagram is similar to other four UML diagrams. &he specific usage is
to model the control flow from one activity to another. &his control flow does not include
messages.
&he activity diagram is suitable for modeling the activity flow of the system. ,n application canhave multiple systems. ,ctivity diagram also captures these systems and describes flow from one
system to another. &his specific usage is not available in other diagrams. &hese systems can bedatabase! e$ternal 3ueues or any other system.
6ow we will loo" into the practical applications of the activity diagram. #rom the above
discussion it is clear that an activity diagram is drawn from a very high level. So it gives high
level view of a system. &his high level view is mainly for business users or any other person whois not a technical person.
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 23/35
&his diagram is used to model the activities which are nothing but business re3uirements. So the
diagram has more impact on business understanding rather implementation details.
#ollowing are the main usages of activity diagram'
• Modeling wor" flow by using activities.
• Modeling business re3uirements.
• ;igh level understanding of the system<s functionalities.
• nvestigate business re3uirements at a later stage.
Assignment %o: +
Purpose: mplement a )trategy design patternMap the participants for the strategy design pattern from a given problemdescription andimplement with a suitable ob!ect oriented language
$heor&:
n Strategy pattern! a class behavior or its algorithm can be changed at run time. &his type of
design pattern comes under behavior pattern.
n Strategy pattern! we create obects which represent various strategies and a conte$t obect
whose behavior varies as per its strategy obect. &he strategy obect changes the e$ecuting
algorithm of the conte$t obect.
mplementation
7e are going to create a Strategy interface defining an action and concrete strategy classes
implementing the Strategy interface. Context is a class which uses a Strategy.
StrategyatternDemo! our demo class! will use Context and strategy obects to demonstrate
change in Conte$t behaviour based on strategy it deploys or uses.
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 24/35
1tep "
Create an interface.
Strategy!"ava
publicinterfaceStrategy{
publicintdoOperation(int num1,int num2);
}
1tep 2
Create concrete classes implementing the same interface.
Operation#dd!"ava
publicclassOperationAddimplementsStrategy{
@Oerride
publicintdoOperation(int num1,int num2){
return num1 ! num2;
}
}
OperationSubstract!"ava
publicclassOperationSubstractimplementsStrategy{
@Oerride
publicintdoOperation(int num1,int num2){
return num1 " num2;
}
}
Operation$ultiply!"ava
publicclassOperation#ultiplyimplementsStrategy{
@Oerride
publicintdoOperation(int num1,int num2){
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 25/35
return num1 $ num2;
}
}
1tep %
Create Context Class.
Context!"ava
publicclass%onte&t{
priateStrategystrategy;
public%onte&t(Strategy strategy){
t'isstrategy strategy;
}
publicinte&ecuteStrategy(int num1,int num2){
returnstrategydoOperation(num1, num2);
}
}
1tep
Use the Context to see change in behaviour when it changes its Strategy.
StrategyatternDemo!"ava
publicclassStrategy*attern+emo{
publicstaticoid main(String-args){
%onte&tconte&tne.%onte&t(ne.OperationAdd());
Systemoutprintln(/10 ! /!conte&te&ecuteStrategy(10,));
conte&tne.%onte&t(ne.OperationSubstract());
Systemoutprintln(/10 " /!conte&te&ecuteStrategy(10,));
conte&tne.%onte&t(ne.Operation#ultiply());Systemoutprintln(/10 $ /!conte&te&ecuteStrategy(10,));
}
}
1tep 3
=erify the output.
10 ! 1
10 "
10 $ 0
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 26/35
Assignment %o: ,
Purpose: mplement a )tate design patternMap the participants for the state design pattern from a given problem description
andimplement with a suitable ob!ect oriented language
n State pattern a class behavior changes based on its state. &his type of design pattern comes
under behavior pattern.
n State pattern! we create obects which represent various states and a conte$t obect whose
behavior varies as its state obect changes.
mplementation
7e are going to create a State interface defining an action and concrete state classes
implementing the State interface. Context is a class which carries a State.
StateatternDemo! our demo class! will use Context and state obects to demonstrate change in
Conte$t behavior based on type of state it is in.
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 27/35
1tep "
Create an interface.
State!"ava
public interface State {
public oid doAction(%onte&t conte&t);
}
1tep 2
Create concrete classes implementing the same interface.
StartState!"ava
public class StartState implements State {
public oid doAction(%onte&t conte&t) {
Systemoutprintln(/*layer is in start state/);
conte&tsetState(t'is);
}
public String toString(){
return /Start State/;
}
}
StopState!"ava
public class StopState implements State {
public oid doAction(%onte&t conte&t) {
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 28/35
Systemoutprintln(/*layer is in stop state/);
conte&tsetState(t'is);
}
public String toString(){
return /Stop State/;
}
}
1tep %
Create Context Class.
Context!"ava
public class %onte&t {
priate State state;
public %onte&t(){
state null;
}
public oid setState(State state){
t'isstate state; }
public State getState(){
return state;
}
}
1tep
Use the Context to see change in behaviour when State changes.
StateatternDemo!"ava
public class State*attern+emo {
public static oid main(String- args) {
%onte&t conte&t ne. %onte&t();
StartStatestartState ne. StartState();
startStatedoAction(conte&t);
Systemoutprintln(conte&tgetState()toString());
StopStatestopState ne. StopState();
stopStatedoAction(conte&t);
Systemoutprintln(conte&tgetState()toString()); }
}
1tep 3
=erify the output.
*layer is in start state
Start State
*layer is in stop state
Stop Stat
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 29/35
Assignment %o: -
Purpose: Understand the concept of Test driven Developmentmplement a design level class diagram 4given as an input5 with #est 'riven'evelopmentapproach.
What is $est'Driven Development ($DD)?&est-driven development starts with developing test for each one of the features. &he test might
fail as the tests are developed even before the development. /evelopment team then developsand refactors the code to pass the test.
&est-driven development is related to the test-first programming evolved as part of e$treme
programming concepts.
$est'Driven Development Pro!ess:
• ,dd a &est
• 0un all tests and see if the new one fails
• 7rite some code
• 0un tests and 0efactor code
• 0epeat
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 30/35
*+ample:
Conte+t o, $esting:• =alid inputs
• nvalid inputs
• 5rrors! e$ceptions! and events
• 4oundary conditions
• 5verything that might brea"
-ene,its o, $DD:
• Much less debug time
• Code proven to meet re3uirements
• &ests become Safety 6et
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 31/35
• 6ear %ero defects
• Shorter development cycles
Assignment %o: .
/01ective: Understand and implement the Concept of a reusa0lecomponentmplement a reusable component in form of !ar 6le 4or in euivalent form for other77 languages5. Use this component in a separate client implementation byimporting the component as a !ar 6le 4or euivalent form for other 77 language5.
Theory:
What is Software Component Reuse?
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 32/35
Software component reuse is the software engineering practice of creating new software
applications from e$isting components! rather than designing and building them from scratch.0eusable components can be re3uirements specifications! design documents! source code! user
interfaces! user documentation! or any other items associated with software. ,ll products
resulting from the software development life cycle have the potential for reuse.
Business Case for Software Component Reuse
0eusable components are easier to maintain (over time) and typically have a higher 3uality value(more robust and fewer errors). &he practice of component reuse supports the motivation fordevelopment of speciali%ed 8S applications. &he business case is reduced application
development time! reduced application cost! and improved application 3uality. ,ssuming the
motivation for use and development of speciali%ed 8S application software is one or several ofthe following'
o &o reduce time
o &o reduce effort
o &o save dollars or earn dollars
o &o improve 3uality
&hen! the easiest way to accomplish these goals includes one or both of the following'
o mprove staff effectiveness (produce more with less through applied use of
technology or incentives)
o /ecrease production wor"load (produce less new output by reusing previously
produced materials to meet an e3uivalent or increased demand)
5$amples are provided below.
o 0eplace manual drafting of multiple copies of a map with reprographics
technology or create a reusable electronic map and produce copies by replotting
the data (reuse of previously produced data)
o 0eplace production of 8S application source code for multiple applications (by
potentially multiple staff) by sharing and reusing software components of previously produced applications
Obstacles to Software Reuse
• #re3uent architecture and system changes.
• Organi%ational and cultural issues> reuse re3uires a fairly drastic change.
• Lac" of automation tools to assist with specific reuse mechanisms.
• ;igher up-front investments.
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 33/35
• Organi%ation si%e and amount of application development performed will be proportional
to paybac". Smaller organi%ations will not benefit as much from code reuse.
• &oo large of a proect or effort is often attempted initially.
• 5$perience has shown that it re3uires three to five years to implement a formal reuse
program across a large corporation.
• nitially! the end-to-end software life cycle will be longer.
• Lac" of component inde$ing and searching mechanisms.
• /eveloping a componenti%ation scheme or architecture reflecting which components
need to be built and which components should be ac3uired from other providers in the
industry. f a component is e$pected or will be available soon from an outside source!then a wait versus build decision needs to be made.
Characteristics Needed for Qualification as a Reusable Component
n order for a component (specification! design! code) to be reusable! it needs to have certain3ualities that contribute to its reusability. 0eusability is defined as the e$tent to which a software
component can be used with or without changes in multiple software systems! versions! or
implementations (McClure ?@). , list of those characteristics generally sought after to promotereusability as presented by McClure are as follows'
o 8eneral with build-in adaptability+speciali%ation
o 7idely applicable
o Modular+self-contained
o Complete and consistent
o Machine independent
o mplementation+application independent
o /ata model independent
o 0eliable
o 0obust (good error+e$ception handling built in)
o Understandable+well documented
o ,daptable+e$tensible
o Standardi%ed
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 34/35
o Aortable (across hardware and operating systems)
o Certified+testable
o Maintainable
o 5ncapsulated (details are isolated and hidden from user)
uidelines for Creatin! a Reusable Component
McClure has also provided the software industry with techni3ues for building reusable
components independent of whether or not an obect-oriented language is available. &his ma"es
the techni3ue applicable to 8S applications development in the entire line of 5sri developmentlanguages! to include traditional proprietary languages! such as ,ML or ,venue! as well as the
Open /evelopment 5nvironment languages! such as =isual 4asic! C::! or &cl&". &he techni3ues
for creating components most applicable to reuse! as presented by McClure! are as follows'
B. 8enerali%e
. Standardi%e
D. ,utomate
E. Certify
F. /ocument
"ow to Build Reusable Components
Listed below are several practical guidelines and advice to assist developers in the creation ofnew reusable components'
• Collaborate with multiple software engineers throughout the design and definition
phases.
• nstall a reuse analysis stage into all detailed design wor"! so that the opportunities for
reuse can be effectively assessed.
• 4efore building a new component! always chec" to ma"e sure it does not e$ist. ,lwaysattempt reuse before creating a new component.
• Strive for a clearly defined! single purpose per component.
• /ocument all component interface re3uirements! also "nown as parameter lists or
function signatures! in the design phase. /o not attempt to start at the coding phase and
Gdesign as you go.G 0emember that component reuse re3uires much more up-front planning. More design time and less construction time should be e$pected and planned
for by proect managers.
7/17/2019 SL-IV Lab Manual
http://slidepdf.com/reader/full/sl-iv-lab-manual 35/35
• 7ith the inputs! results! or outputs and a description of a component! another software
developer should be able to use that component without ever "nowing what the code doesinside the component. &he component should pass this Gself test.G
• Strive for loosely coupled and highly cohesive components.
• /evelop components with overall future use in mind! not ust a single proect.
• ,lways put e$tra effort into error handling and ma"ing components robust.
• /evelop a certification program and communicate the certification criteria to all
component developers.
• Use consistent design styles.
• mplement and use naming conventions.
• 7hen creating documentation! thin" of e$plaining the component to a developer
unfamiliar with the internal wor"ings or a developer who will truly never loo" at the codeof the component.
• &horoughly test the component.