Three days workshop on Basics of Software Engineering at Thapar University, Patiala on 7th-9th, 2013. Workshop on Basics of Software Engineering (DFD, UML and Project Culture)

1. 1

2. Module 1 Introduction
Module 2 Use case diagram
Module 3 Flow of events
Module 4 Realization of the class diagram
Module 5 Sequence diagram and Collaboration Diagram
Module 6 Class diagram and refinement attributes
Module 7 State transition and activity diagram
Module 8 Implementation diagram
Module 9 Component diagram and Deployment diagram
Module 10 Understanding project culture
2

3. 3

4.  What is a model?
◦ A model is a simplification of reality
 Why do we model?
◦ help visualizing
◦ permit specification
◦ provides a template
◦ document decisions
4

5.  Choose your models well
 Every model may be expressed at various
levels of precision
 The best models are connected to reality
 No single model is sufficient
5

6.  DEFINITION:The application of systematic, disciplined and
qualifiable approach to the development, operation and
maintenance of a software system is software engineering.
 Software development life cycle has following stages:
6
REQUIREMENT
ANALYSIS
DESIGN
IMPLEMENTATION
TESTING

7. Analysis & design 40 %
Development 20 %
Testing 40 %
Analysis - What is to be done ?
Design - How it is to be done ?
Two Popular methodology approaches are:
 Structured Analysis & Design
 Object Oriented Analysis & Design-OO model
7

8. The object oriented approach is a way of thinking about a
problem using real world concepts instead using adhoc function
concepts.
We intent to learn OOAD approach for the following reason:
◦Promotes better understanding of user requirements
◦Leads cleaner design
◦Design flexibility'
◦Decomposition of the system is consistent
◦Facilitates data abstraction & information hiding
◦Software reuse
◦Easy maintenance
◦Implementation flexibility
8

9. Following are three elements for every OO methodology:
 Notation
 Process / Method
 Tool
9

10.  Notation:
It is collection of graphical symbols for expressing model of
the system.
The Unified Modeling Language [UML] provides a very
robust set of notation which grows from analysis to design.
By unifying the notations used by these object oriented
methods, the unified modeling language provides the basis
for a de facto standard in the domain of object oriented
analysis and design founded on a wide base of user
experience.
10

11.  It is a Unified Modeling Language, which is mainly a collection
of graphical notation that methods use to express the
designs.
 The UML is language for visualizing, specifying, constructing
and documenting the artifacts of software system.
 UML is visual modeling language for modeling systems and
is non proprietary.
 It is an evolutionary step, which is more expressive and more
uniform than individual notations.
 Whitehead says
“ By relieving the brain of unnecessary work, a good notation,
sets it free to concentrate on more advance and creative
problems “ UML is not a method or process but is the means
to express the same.
11

12.  System of several different kinds, absolutely anywhere
everywhere.
 Primarily for software intensive systems like:
Systems software
Business processes
12

13.  Captures business processes
 Enhance communication and ensures the right
communication
 Capability to capture the logical software architecture
independent of the implementation language
 Manages the complexity
 Enables reuse of design
13

14.  UML things:
Class, component, node, relationship, package etc..
 UML diagrams:
Use case diagram, interaction diagram, class diagram, State
diagram, deployment diagram
14

15. What is Process?
 It is an extensive set of guidelines that address the technical
and organizational aspects of software development focusing
on requirements, analysis and design.
 Process basically encapsulates the activities leading to the
orderly construction of system model.
 OO model supports the iterative and incremental model for
the process.
15

16.  Develop software iteratively
 Manage requirements
 Use component based architectures
 Visually model software
 Verify S/W quality
 Control changes to software.
16

17.  It is automated support for every stage of software
development life cycle.
 Since we are concentrating on requirement, analysis and
design phase, following are the names of few tools which are
greatly in use:
1. Rational Rose
2. Cayenne
3. Platinum
4. Select
5. RSA
17

18.  Helps designer for creating designs much more quickly.
 Supports validations like:
Consistency checking
Completeness checking
Constrain checking.
 Time required for certain operation could be predicted .
 Code generation
 Reverse engineering.
 Conversion from SSAD to OOAD
 Quick documentation…etc
18

19.  All three components play equally important role towards the
success of the project.
19
Notation
Method
Tool

20.  Get introduced with Unified Modeling Language and know
the basic components of software development life cycle.
20

21. 21

22. 22
STATIC MODEL
DYNAMIC MODEL
PHYSICAL MODEL
LOGICAL MODEL
The models of Object Oriented Development

23.  4+1 view of OO model.
◦ Process view
◦ Deployment view
◦ Logical view
◦ Dynamic view
+
◦ Use case view
 As shown in the model , for each dimension we define a
number of diagrams that denote a view of the system’s
model.
 The use case view is central since its contents drive the
developments of other views.
23

24. 1. Use case diagram
2. Class Diagram
3. Behavioral diagrams
- State chart diagrams
- Activity diagrams
- Interaction diagrams
- Sequence diagrams
- Collaboration diagrams
4. Implementation diagrams
- Component diagram
- Deployment diagram
24

25.  Use case diagrams represent the functions of a system from
the user’s point of view.
 Sequence diagrams are a temporal representation of objects
and their interactions.
 Collaboration diagrams are a spatial representation of
objects, links, and interactions.
 Object diagrams represent objects and their relationships,
and correspond to simplified collaboration diagrams that do
not represent message broadcasts.
 Class diagrams represent the static structure in terms of
classes and relationships.
25

26. Contd...
 State chart diagrams represent the behavior of a class in
terms of states
 Activity diagrams are to represent the parallel behavior of an
operation as a set of actions.
 Component diagrams represent the logical components of an
application.
 Deployment diagrams represent the deployment of
components on particular pieces of hardware.
26

27.  A use case diagram establish the capability of the system as a
whole.
 Components of use case diagram:
Actor
Use case
System boundary
Relationship
Actor relationship
 Semantic of the components is followed.
27

28. What is an actor?
 An actor is some one or something that must interact with
the system under development
 UML notation for actor is stickman, shown below.
28
Customer Manager Cashier

29. More about an actor:
 It is role a user plays with respect to system.
 Actors are not part of the system they represent anyone or anything
that must interact with the system.
 Actors carry out use cases and a single actor may perform more
than one use cases.
 Actors are determined by observing the direct uses of the system.
29

30. Contd…
 Those are responsible for its use and maintain as well as
other systems that interact with the developed system.
 An actor may
- input information to the system.
- receive information from the system.
- input to and out from the system.
30

31. How do we find the actor?
 Ask following questions to find the actors:
◦ Who uses the system?
◦ Who installs the system?
◦ Who Starts up the system?
◦ What other systems use this system?
◦ Who gets the information from the system?
◦ Who provides information to the system?
 Actor is always external to the system. They are never part of
the system to be developed.
31

32. 4-Categories of an actor:
 Principle : Who uses the main system functions.
 Secondary : Who takes care of administration & maintenance.
 External h/w : The h/w devices which are part application
domain and must be used.
 Other system: The other system with which the system must
interact.
32

33. Note:
 If newly identified actor is using a system in a same way like an
existing actor, then new actor can be dropped.
 If two actors use system in the same way they are same actors.
33

34. What is USE case?
 A use case is a pattern of behavior, the system exhibits
 Each use case is a sequence of related transactions performed
by an actor and the system in dialogue.
 USE CASE is dialogue between an actor and the system.
 Examples:
34
Open new account Withdrawal of cash
from ATM

35. More about USE CASE:
 It is a snapshot of one aspect of system.
 They model a dialog between actor and system.
 A use case typically represents a major piece of functionality that is
complete from beginning to end.
 Most of the use cases are generated in initial phase, but you find
some more as you proceed.
 A use case may be small or large. It captures a broad view of a
primary functionality of the system in a manner that can be easily
grasped by non technical user.
35

36. Contd…
 A use case must deliver something of value to an actor.
 The use cases may be decomposed into other use cases.
 Use cases also present a good vehicle for project planning.
36

37. How do we find the use cases?
 What functions will the actor want from the system?
 Does the system store information? What actors will create,
read, update. Or delete that information?
 Does the system need to notify an actor about changes in its
internal state?
37

38.  Generic format for documenting the use case:
- Pre condition: If any
◦ Use case : Name of the case.
◦ Actors : List of actors(external agents), indicating who
initiates the use case.
◦ Purpose : Intention of the use case.
◦ Overview : Description.
◦ Type : primary / secondary.
◦ Post condition: If any
 Typical Course of Events:
ACTOR ACTION : Numbered actions of the actor.
SYSTEM RESPONSE : Numbered description of system responses.
38

39. USE CASE documentation example:
 The following use case describes the process of opening a
new account in the bank.
Use case :Open new account
Actors :Customer, Cashier, Manager
Purpose :Like to have new saving account.
Description :A customer arrives in the bank to open the new
account. Customer requests for the new account
form, fill the same and submits, along with the
minimal deposit. At the end of complete successful
process customer receives the passbook.
Type :Primary use case.
39

40.  Those use case functionality which are directly dependent on
the system environment are placed in interface objects
 Those functionality dealing with storage and handling of
information are placed in entity objects
 Functionality's specific to one or few use cases and not
naturally placed in any of the other objects are placed in
control objects
By performing this division we obtain a structure which helps
us to understand the system from logical view
40

41. 41
Capture,clarify
& validate use cases
Analysis Design &
Implementation
Implement
use cases
Use cases make up the glue
Test
Verify that use cases
are satisfied

42. What is System Boundary?
 It is shown as a rectangle.
 It helps to identify what is external verses internal, and what the
responsibilities of the system are.
 The external environment is represented only by actors.
42

43. What is Relationship?
 Relationship between use case and actor.
Communicates
 Relationship between two use cases
Extends
Include
 Notation used to show the relationships:
<< >>
43

44.  Relationship between use case and actor is often referred as
“communicates” .
 Relationship between two use cases is refereed as either include or
extends.
EXTENDS:
 It is used to show optional behavior, which is required only
under certain condition.
INCLUDE:
 It is used to show mandatory behavior, which is required
under every condition.
44

45. Example:
Use Case
Diagram
45

46. 46

47. 47

48.  To understand and capture the detailed specification of a
system to be developed, from user perspective.
48

49. 49

50.  Completion of first version of use case diagram initiates the
processes of analysis and design.
 UML provides the framework to carry out the process of
analysis and design in form of set of diagrams.
 Every diagram and notation used in the diagram carries the
semantics.
 First step towards analysis and design is to specify the flow of
events.
50

51.  A flow of events document is created for each use case.
 Details about what the system must provide to the actor when
the use is executed.
 Typical contents
◦ How the use case starts and ends
◦ Normal flow of events
◦ Alternate flow of events
◦ Exceptional flow of events
 Typical Course of Events has:
Actor Action (AA)
System Response (SR)
51

52. For withdrawal of cash:
 1.(SR) The ATM asks the user to insert a card.
 2.(AA) The user inserts a cash card.
 3.(SR) The ATM accepts the card and reads its serial number.
 4.(SR) The ATM requests the password.
 5.(AA) The user enters 1234.
 6.(SR) The ATM verifies the serial number and password with
the bank and gets the notification accordingly.
 7.(SA)The ATM asks the user to select the kind of transaction.
 8.(AA)User selects the withdrawal.
52

53. Contd...
 9.(SR)The ATM asks for the amount of cash; user enters Rs.
2500/-
 10.(SR)The ATM verifies that the amount of cash is within
predefined policy limits and asks the bank, to process the
transaction which eventually confirms success and returns the
new account balance.
 11.(SR) The ATM dispenses cash and asks the user to take it.
 12.(AA) The user takes the cash.
 13.(SR) The ATM asks whether the user wants to continue.
 14.(AA) The user indicates no.
53

54. Contd...
 15.(SR) The ATM prints a receipt, ejects the card and asks the
user to take them
 16.(AA) The user takes the receipt and the card.
 17.(SR) The ATM asks a user to insert a card.
54

55. For withdrawal of cash use case:
 9. The ATM asks for the amount of cash; the user has change
of mind and hits the “cancel”.
55

56. For withdrawal of cash use case:
 3 Suspicious pattern of usage on the card.
 10 The machine is out of cash.
 11 Money gets stuck in the machine.
56

57.  It helps in understanding the functionality of a system to be
developed.
 Flow of events helps in finding objects of the system to be
developed.
 Happens to be most important and very first step towards
analysis and design.
57

58.  The functionality of the use case is captured in flow of the
events.
 A scenarios is one path through the flow of events for the use
case.
 Scenarios are developed to help identify objects, classes and
object interactions for that use case.
58

59. 59
Example:
0 Level DFD

60. 60
Example:
Level 1 DFD

61. 61
Example: Level 2 DFD

62.  To understand the flow of each functionality and find out the
objects and methods required to build the system.
62

63. 63

64.  The use case diagram presents an outside view of the system
 Interaction diagrams describe how use cases are realized as
interactions among societies of objects.
 Two types of interaction diagrams
◦ Sequence diagrams
◦ Collaboration diagrams
64

65.  Interaction diagrams are models that describe how groups of
objects collaborate in some behavior
 There are 2 kinds of interaction diagrams
• Sequence diagram
• Collaboration diagram
 Sequence diagrams are a temporal representation of objects
and their interactions
 Collaboration diagrams are spatial representation of objects,
links and interrelations
65

66.  Typically these diagrams capture behaviors of the single scenario.
 Shows object interaction arranged in time sequence.
 They show sequence of messages among the objects.
 It has two dimensions, vertical represents time & horizontal
 represents objects.
 Components of sequence diagram:
-objects
-object lifeline
-Message
-pre/post conditions.
66

67. 67
 Object are represented by rectangles and name of the objects are
underlined.
 Object life line are denoted as dashed lines. They are used to
model the existence of objects over time.
Name:Class

68.  They are used to model the content of communication
between objects. They are used to convey information
between objects and enable objects to request services of
other objects.
 The message instance has a sender, receiver, and possibly
other information according to the characteristics of the
request.
 Messages are denoted as labeled horizontal arrows between
life lines.
 The sender will send the message and receiver will receive the
message.
68

69. Contd…
 May have square brackets containing a guard conditions. This
is a Boolean condition that must be satisfied to enable the
message to be sent.
 May have an asterisk followed by square brackets containing
an iteration specification. This specifies the number of times
the message is sent.
 May have return list consisting of a comma -separated list of
names that designate the values of returned by the operation.
 Must have a name or identifier string that represents the
message.
 May have parentheses containing an argument list consisting
of a comma separated list of actual parameters passed to a
method.
69

70. 70
:Customer :ATM :Bank
Request password
Verify account
Enter the password
Account o.k.
Request option
Enter option
Request amount
Enter the amount
Update transaction
Transaction commit
Insert card
Dispense cash
Request take cash
Take cash
Request continuation
Terminate
Print receipt ,eject card
Request take card
Take card
Display main screen and prompt for the card.
:Transaction
Create
Transaction
Transaction
complete
Sequence diagram [for withdrawal of cash, normal flow]

71. 71
Example:
Sequence
Diagram

72.  Collaboration diagrams illustrate the interaction between the
objects, using static structure.
 Unlike sequence diagram the time is not explicitly
represented in these diagrams
 In collaboration diagram the sequence of messages is
indicated by numbering the messages. The UML uses the
decimal numbering scheme.
 In these diagrams, an actor can be displayed in order to
represent the triggering of interaction by an element external
to the system.
 This helps in representing the interaction, without going into
the details of user interface.
72

73.  Named objects
 Links: Links are represented by a continuous line between
objects, and indicates the exchange of messages.
 Messages has following attributes:
 Synchronization --thread name, step within thread.
 Sequence number
 Message labels : The name of the message often corresponds to an
operation defined in the class of the object that is the destination of the
message. Message names may have the arguments and return values.
 *[iteration].
 It uses decimal notation.
 Message direction.
73

74.  Object names identify which objects are participating and the
links show which objects collaborate
 A link between two objects must exist for one object to send
message to another and vice a versa.
 Messages in the collaboration diagram get transformed to
more detailed signature.
 They use the decimal notation system for numbering the
messages.
 The direction of the message defines the sender and receiver
of the message
74

75.  Predecessor
 Role names
 Message qualifiers
◦ Iteration expression
◦ Parameters
◦ Return values
◦ Message stereotypes
 Concurrent thread sequencing
 Thread dependencies
 Message expression
[Pre] A1:*(expression):doIt(p,r):return value
75

76. 4:Display(x,y) Simple
message
3.3.1:Display(x,y) Nested
message
4.2:subtract[Today,Birthday]:age Nested
message with
return value
[Age >=18] 6.2:Vote() Conditional
message
4.a,b.6/c.1:Turnon(Lamp) Synchro. with
other flow of
execution
1*:wash() Iteration
3.a,3.b/4*||[i:=1..n]:Turnoff() Parallel
iteration
76

77. 77
1. Insert card
Enter password, Enter kind
Enter amount,
Take cash, Take card
cancel,Terminate, Continue
Display main screen
unreadable card message,
request password,
request kind, request amount,
canceled message, eject card, failure message,
dispense cash, request take cash
request continuation,
print receipt, request take card
bad account message,
bad bank account message
Verify account,
process transaction
Transaction succeed
Transaction failed
account o.k.
bad account,
bad password,
bad bank code
Create Transaction
Transaction complete
CUST-
OMER
BANK
ATM
TRANSA-
CTION

78. 78
Example:
Collaboration
Diagram

79.  To know the interaction among the objects in temporal and
spatial form.
 To know how objects collaborate among each other and
hence delegate the responsibility to the respective objects.
 To understand how the messages get matured with more
information.
79

80. 80

81.  A class diagram shows the existence of classes and their
relationships in the logical view of a system
 UML modeling elements in class diagrams are:
◦ Classes, their structure and behavior.
◦ relationships components among the classes like
association, aggregation, composition, dependency and
inheritance
◦ Multiplicity and navigation indicators
◦ Role names or labels.
81

82.  Association
 Aggregation
 Composition
 Inheritance
 Dependency
82

83. These are the most general type of relationship:
 It denotes a semantic connection between two classes
 It shows BI directional connection between two classes
 It is a weak coupling as associated classes remain somewhat
independent of each other
 Example:
83
CUSTOMER
ATM system

84. This is a special type of association
 The association with label “contains” or “is part of” is an aggregation
 It represents “has a “ relationship
 It is used when one object logically or physically contains other
 The container is called as aggregate
 It has a diamond at its end
 The components of aggregate can be shared with others
 It expresses a whole - part relationships
84

85. 85
Example:
Customer ATM card

86. This is a strong form of aggregation
 It expresses the stronger coupling between the classes
 The owner is explicitly responsible for creation and deletion of the
part
 Any deletion of whole is considered to cascade its part
 The aggregate has a filled diamond at its end
86
Window Client Area

87.  The inheritance relationship helps in managing the
complexity by ordering objects within trees of classes with
increasing levels of abstraction. Notation used is solid line
with arrowhead,shown below.
 Generalization and specialization are points of view that are
based on inheritance hierarchies.
87
Account
SavingAccountCurrentAccount

88.  Dependency is semantic connection between dependent and
independent model elements.
 This association is unidirectional and is shown with dotted
arrowhead line.
 In the following example it shows the dependency relationship
between client and server.
 The client avails services provided by server so it should have
semantic knowledge of server.
 The server need not know about client.
88
Client Server

89. Definition: Number of instances of each class involved in the
dialogue is specified by cardinality.
 Common multiplicity values:
 Symbol Meaning
 1 One and only one
 0..1 Zero or one
 M…N From M to N (natural integer)
 0..* From zero to any positive integer
 1..* From one to any positive integer
 Also thought can be given about navigability to every
applicable relationship.
89

90.  In collaboration diagram we have shown the objects, their
interaction and detailed message signature.
 This information is carried forward to the class diagram.
 At this point,we group the similar objects and form classes.
 Messages get mapped to responsibilities for respective
classes.
 Find the attributes for every class.
 Transform the links to appropriate relationships.
 Relationship is further refined with respect to multiplicity and
navigability.
This complete procedure brings the minimal class diagram [for
withdraw cash use case, normal flow.]
90

91. 91
Customer
Transaction
1
0..*
1
0..*
ATMSystem
1..*
1..*
1..*
1..*
Bank[Branch]
1
1..*
1
1..*
1
1
1
1

92.  Till this slide we have worked out the essentials of class
diagram for withdrawal of cash use case, normal flow of
events.
 Similar exercise required to be carried out for every scenario
and clubbed all in the class diagram.
 At this point, we refine this integrated class diagram to add
further fine details. Approximate sketch for this class diagram
has been shown at the end of this module.
 Refinement attributes should be updated right from sequence
diagram to class diagram.
 Next few slides will take into the discussion of refinement
attributes.
 This process of iterative and incremental development will
continue till there is no change in two consecutive iteration.
92

93. 93
Identify objects
Identify Messages
Group Objects
into classes
Identify & classify
Class relationships
Identify class
behavior
Group classes
into domains
Validate Classes
& Objects

94. 94
Example:
Class
Diagram

95.  Learn to build the architecture, which contains the entire
information of the system to be developed.
 It is this architecture which is called as BLUE PRINT is handed
over for coding.
95

96. 96

97.  A state transition diagram shows the states of a single object,
the events or the messages that cause a transition from one
state to another and the action that result from a state
change.
 A state transition diagram will not be created for every class
in the system.
Components of State Diagram:
◦ Start State
◦ Stop state
◦ State Transition
97

98.  State: A state is a condition during the life of an object
when it satisfies some condition, performs some action,
or waits for an event.
The UML notation for a state is a rectangle with rounded
corners.
 Special states: There are two special states.
Start state: Each state diagram must have one and only
one start state. Notation for start state is “filled solid
circle”.
Stop State: An object can have multiple stop states.
Notation for stop state is bull’s eye.
98

99. Contd...
 State transition: A state transition represents a change from
an originating to a successor state.
 Transition label: event name[guard condition] / action
99

100. 100
Example:
State Chart
Diagram

101. 101
Example:
State Chart
Diagram

102. 102
Example:
State Chart
Diagram

103.  A state diagram will not be created for every class.
 state diagrams are used only for those classes that exhibit
interesting behavior.
 State diagrams are also useful to investigate the behavior of
user interface and control classes.
 State diagram are used to show dynamics of a individual class
103

104. It is a special kind of state diagram and is worked out at use
case level.
 These are mainly targeted towards representing internal
behavior of a a use case.
 These may be thought as a kind of flowchart.
 Flowcharts are normally limited to sequential process; activity
diagrams can handle parallel process.
 Activity diagrams are recommended in the following
situations:
 Analyzing use case
 Dealing with multithreaded application
 Understanding workflow across many use cases.
104

105. Consistency checking is the process of ensuring that
information in both static view of the system(class
diagram) and the dynamic view of the system(sequence
and collaboration diagram) is telling the same story.
105

106. 106
Example:
Activity
Diagram

107.  Understand the dynamic behavior of a class
 Way to find the parallel processes at use case level.
107

108. 108

109. COMPONENT DIAGRAM:
Component diagrams illustrate the organizations and
dependencies among software components.
A component may be
 A source code component
 A run time components
 An executable component
 Dependency relationship.
109

110. 110
policy.dll
Branch
Bank.dllcustomer.dll
ATM.exe
Branch
Bank.exe
Bank
Server.exe

111. 111
Example:
Component
Diagram

112. 112
Example:
Modeling

113.  A deployment diagram shows the relationship among
software and hardware components in the delivered system.
 These diagram include nodes and connections between
nodes.
 Each node in deployment diagram represents some kind of
computational unit, in most cases a piece of hardware.
 Connection among nodes show the communication path over
which the system will interact.
 The connections may represent direct hardware coupling line
RS-232 cable, Ethernet connection, they also may represent
indirect coupling such as satellite to ground communication.
113

114. 114
ATM_
machine
Bank_
server
Branch
Bank_
Ethernet
Ethernet
Bank.exe
BankServer.exe
ATM.exe

115. 115
Example:
Deployment
Diagram

116.  To understand the organization of software modules and
their deployment on the respective hardware.
116

117. 117

118. It may be:
1.Calendar Centric
2.Requirement Centric
3.Documentation Centric
4.Quality Centric
5.Architecture Centric
118

119.  Architecture driven projects represent the most mature
style of development.
 These projects are characterized by a focus on creating
a frame work that satisfies all known requirement, yet is
resilient enough to adapt to those requirements, that are
not yet known or well understood.
 In every sense of the word, architect-driven policies are
in evolutionary step beyond requirement driven policies.
 Architecture driven style of development is usually the
best approach for the creation of most complex software
intensive systems
119

120. Architecture driven style of development typically observe
the following process:
1. Specify the system’s desired behavior through a
collection of scenarios. (Analysis)
2. Create, then validate, an architecture. (Design)
3. Evolve that architecture, making mid-course
corrections as necessary to adopt to new requirements as
they are uncovered.
120

121. What exactly is nature of the well structured object
oriented architecture??
1. A set of classes, typically organized into multiple
hierarchies.
2. A set of collaboration that specify how those classes
co-operate to provide various system function.
121

122. Use case driven
Architecture centric
Incremental and iterative approach.
122