Object Oriented Analysis and Design Using UML

1
Object Oriented Analysis and Design Using UML
2
Course description

• OBJECTIVE
• The understand the Unified Modeling Language and
  orient towards Object Oriented methodology using
  UML for modeling software systems.
• TARGET AUDIENCE
• In particular, it is intended for software
  professionals who have sound knowledge of object
  concepts and some experience towards analysis and
  design.
• PREREQUISITES
• Good understanding of object concepts.
• Sound knowledge of any object oriented language.
• Knowledge of software engineering process.

3
Course description

• TABLE OF CONTENTS
• Module1 Introduction
• Module2 Use case diagram
• Module3 Flow of events
• Module 4 Realization of the class diagram
• Sequence diagram and Collaboration Diagram
• Module5 Class diagram and refinement attributes
• Module6 State transition and activity diagram
• Module7 Implementation diagram
• Component diagram and Deployment diagram
• Module8 Understanding project culture
• Appendix-A

4
Module-1
5
Importance of modeling

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

6
4 Principles of Modeling

• 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

7
What is Software Engineering?

• DEFINITIONThe 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

REQUIREMENT
ANALYSIS
DESIGN
IMPLEMENTATION
TESTING
8
Effort Distribution for each stage

• 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

9
Major benefits of OOAD

• 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

10
Elements of OO Methodology

• Following are three elements for every OO
  methodology
• Notation
• Process / Method
• Tool

11
What is Notation?

• 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.
• This brings end of the method wars as far as
  notation is concerned
• with adoption of the language UML
• 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

12
What is UML?

• 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
• UML is not a radical departure from Booch, OMT,
  OOSE notations but rather legitimate successor to
  all three.
• 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.

13
Where can you use the UML?

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

14
The Evolution of the UML
OMG vote97 Submission to OMG, sept97

• Public Feedback

UML1.1
Submission of OMG group
UML1.0
Beta version OOPSLA96
UML0.9
Unified Method 0.8
Booch
OMT
OOSE
Other method
15
Advantages of UML

• 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

16
UML refers to

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

17
What is Process?

• 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.

18
More about Process?

• Guidance as to the order of teams activities
• It specifies what artifacts should be developed
• It directs the task of individual developers and
  team as a whole
• It offers criteria for monitoring and measuring
  project activities
• The selection of particular process will vary
  greatly depending upon things like problem
  domain, implementation technology and skills of
  team
• Booch,OMT,OOSE and many other methods have well
  defined process and UML supports almost all
  methods
• There has been some convergence on development
  process practices but there is no consensus for
  standardization.
• Framework for the every stage of software
  development life cycle.

19
Best Practices followed by Rational Unified
Process

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

20
What is a tool?

• 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

21
Why Tool?

• 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.
• Round trip engineering
• Conversion from SSAD to OOAD
• Quick documentationetc

22
Triangle for Success

• All three components play equally important role
  towards the success of the project.

Notation
Tool
Method
23
Objective of the first module

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

24
Module-2
25
OO model
DYNAMIC MODEL
STATIC MODEL
LOGICAL MODEL
PHYSICAL MODEL
The models of Object Oriented Development
26
Models and Views

• 41 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 systems model.
• The use case view is central since its contents
  drive the developments of other views.

27
UML diagrams

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

28
Semantics of Diagrams

• Use case diagrams represent the functions of a
  system from the users 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.

29
Semantics of Diagrams

• 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.

30
What is USE CASE diagram?

• 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.

31
ACTOR

• 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.

32
ACTOR

• 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,

33
ACTOR

• 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.

34
ACTOR

• 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.

35
ACTOR

• 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 of
  application
• domain and must be used.
• Other system The other system with which the
  system must
• interact.

36
ACTOR

• 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.

37
USE CASE

• 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

Withdrawal of cash from ATM
Open new account
38
USE CASE

• 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.

39
USE CASE

• 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.

40
USE CASE

• 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?

41
USE CASE

• 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.

42
USE CASE

• 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.

43
Grouping USE CASES

• 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

44
OOAD --- USE CASE driven
Analysis
Design Implementation
Test
Use cases make up the glue
Implement use cases
Verify that use cases are satisfied
Capture,clarify validate use cases
45
SYSTEM BOUNDARY

• 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.

46
RELATIONSHIP

• What is Relationship?
• Relationship between use case and actor.
• Communicates
• Relationship between two use cases
• Extends
• Uses
• Notation used to show the relationships
• ltlt gtgt

47
RELATIONSHIP

• Relationship between use case and actor is often
  referred as communicates .
• Relationship between two use cases is refereed as
  either uses or extends.
• USES
• - Multiple use cases share a piece of same
  functionality.
• - This functionality is placed in a separate use
  case rather than
• documenting in every use case that needs
  it.

48
RELATIONSHIP

• Contd...
• A uses relationship shows behavior that is
  common to one or
• more use cases.
• EXTENDS
• It is used to show optional behavior, which is
  required only
• under certain condition.

49
USE CASE diagram
Use case diagram for the shown functionality.
Balance status report
extends
Withdraw cash
Clerk
Customer
uses
Validation
ATM
Manager
50
Objective of the second module

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

51
Module-3
52
Beginning Analysis and Design

• 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.

53
Flow of Events

• 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)

54
Normal Flow of Events

• 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.

55
Normal Flow of Events

• 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.

56
Normal Flow of Events

• 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.

57
Alternative Flow of Events

• 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.

58
Exceptional Flow of Events

• 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.

59
Why flow of events?

• 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.

60
What is Scenario?

• 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.

61
Objective of the third module

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

62
Module-4
63
USE CASE Realizations

• 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
What is Interaction diagram?

• 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
What is sequence diagram?

• 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
OBJECT OBJECT LIFE LINE

• 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.

67
MESSAGES

• 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
MESSAGES

• 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 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
Sequence diagram for withdrawal of cash, normal
flow
Customer
ATM
Bank
70
What is Collaboration diagram?

• Collaboration diagrams illustrate the interaction
  between the objects, using static spatial
  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.

71
Components of collaboration diagram

• 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.

72
Semantics of components

• 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

73
The elements of message

• Predecessor
• Role names
• Message qualifiers
• Iteration expression
• Parameters
• Return values
• Guard
• Message stereotypes
• Concurrent thread sequencing
• Thread dependencies
• Message expression
• Pre A1(expression)doIt(p,r)return value

74
The examples of message
75
Collaboration diagram for withdrawal of cash,
normal flow.
1. Insert card Enter password, Enter kind Enter
amount, Take cash, Take card cancel,Terminate,
Continue
Create Transaction Transaction complete
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
Transaction succeed Transaction failed account
o.k. bad account, bad password, bad bank code
Verify account, process transaction
76
Objective of the fifth module

• 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.

77
Module-5
78
What is Class diagram?

• 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.

79
Major Types of classes

• Concrete classes
• A concrete class is a class that is instantiable
  that is it can have different instances.
• Only concrete classes may be leaf classes in the
  inheritance tree.
• Abstract classes
• An abstract class is a class that has no direct
  instance but whose descendants classes have
  direct instances.
• An abstract class can define the protocol for an
  operation without supplying a corresponding
  method we call this as an abstract operation.
• An abstract operation defines the form of
  operation, for which each concrete subclass
  should provide its own implementation.

80
RELATIONSHIP

• Association
• Aggregation
• Composition
• Inheritance
• Dependency
• Instantiation

81
ASSOCIATION

• 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

82
AGGREGATION

• 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

83
AGGREGATION
Example
ATM card
Customer
84
COMPOSITION

• 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

Window
Client Area
85
INHERITANCE

• 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.

Account
SavingAccount
CurrentAccount
86
DEPENDENCY

• 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.

87
INSTANTIATION

• This relationship is defined between
  parameterized class and actual class.
• Parameterized class is also referred as generic
  class.
• A parameterized class cant have instances unless
  we first instantiated it
• Example

88
What is Cardinality?

• 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
• MN 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
Reaching the class diagram

• 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
Class diagram for withdrawal of cash, normal
flow
Customer
1
1
1..
1..
1..
1..
ATMSystem
0..
0..
Transaction
1
1
1
1
1..
1..
BankBranch
1
1
91
What more to the Class Diagram?

• 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
OOAD---Iterative Incremental Approach
Identify objects
Identify Messages
Validate Classes Objects
Group Objects into classes
Group classes into domains
Identify classify Class relationships
Identify class behavior
93
Refinement attributes

• Stereotypes
• Stereotypes are part of the range of
  extensibility mechanism provided by UML
• It permits user to add new model element classes
  on top of the kernel predefined by UML

94
Refinement attributes

• Contd
• Constraints
• Constraints are functional relationship between
  the entities and object
• model. The entities include objects, classes,
  attributes, association, links.
• A constraint restricts the values that entities
  can assume.
• UML doesn't specify a particular syntax for
  constraints, other than they should appear
  between braces, so they may therefore be
  expressed using natural language, pseudo code,
  navigation expression or mathematical expression
• UML1.2 does prefer the use of a constraint
  language OCL i.e. Object Constraint Language,
  which is subset of UML.

95
Refinement attributes
ExampleConstraints

• Number of withdrawal transaction should be less
  than five per day.

Constraint on the same class.
Transaction
No. of transaction lt5 /day

• No window will have an aspect ratio i.e.
  (length/width) of less than 0.8 or gt 1.5

Window length/width
A constraint between the properties of the same
object
0.8ltlength/width lt 1.5
96
Refinement attributes

• Qualifier
• UML provides a role of constraint notation to
  indicate different kind of collections that may
  be inherent in the analysis model
• Common role constraints for multi valued roles
  include
• ordered Collection is maintained in sorted
  manner
• bag Collection may have multiple
  copies of same item.
• set Collection may have at most one
  copy of given item.
• Some constraints may be combined such as
  ordered set

97
Refinement attributes

• Qualifier
• Another common design scheme is to use a key
  value to retrieve an item from the collection.
  This is called as qualified association and the
  key value as qualifier.
• A qualified association is the UML equivalent of
  a programming concept variously known as
  associative arrays, maps,dictionaries
• A qualified association relates two object
  classes and a qualifier
• The qualifier is a special attribute that reduced
  the effective multiplicity of an association.
• One to many and many to many association may be
  qualified.

98
Refinement attributes

• Check for many to many relationship, if any,
  normalize with qualifier or association class.
• Check for the scope forming abstract classes and
  template classes.
• Check for helper functions.
• Thought can be given for using the design
  patterns.

99
Objective of the fifth module

• 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.

100
Refined Class diagram for withdrawal of cash
Few more relationship can be further added to the
shown diagram
BatchJob
ATMSystem
Area
Cash
1..
1..
BankComputer
1
1
BankBranch
ltltabstractgtgt
AccountAccessor
1
1
ltltabstractgtgt
1
1
person
Transaction
CashierStation
1..
1..
1
1
ATMScreen
BankAssociates
Customer
Slips
1..
1..
1
1
ltltabstractgtgt
TellerScreen
Account
0..1
0..1
1
1
NoteHelpForBankCard
BankCard
1
1
SavingAccount
CurrentAccount
101
Module-6
102
What is state transition diagram?

• 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

103
Semantics of every components

• 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 statesThere 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 bulls eye.

104
Semantics of every components

• Contd...
• State transition A state transition represents a
  change from an originating to a successor state.
• Transition label event nameguard condition /
  action

105
State Transition Diagram for Account class.
request and fill the form for new saving account
validate / process
Open
transaction request validate / update()
transactionStrart / Transfer_to_main_ledger ()
Operational
Dormant
no transaction / Transfer_to_Dormant_Ledger
Fraud or authorized instructionValidate /
lockAccount()
fill_the_request_form/update()
matter_resolved validate / unlockAccount()
close
seized
fill_the_request_form / update()
NoteAccount can be closed from open state as well
106
More about State Diagram

• 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

107
What is activity diagram?

• 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.

108
Consistency Checking

• 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.

109
Objective of the sixth module

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

110
Module-7
111
What is component diagram?

• 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.

112
Component Diagram for withdrawal of cash
policy.dll
Bank
Server.exe
Branch
Bank.dll
customer.dll
Branch
Bank.exe
ATM.exe
113
What is deployment diagram?

• 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.

114
Deployment diagram
Branch
Bank_
Bank.exe
Ethernet
Ethernet
Bank_
server
ATM_
machine
BankServer.exe
ATM.exe
115
Objective of the seventh module

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

116
Module-8
117
Understanding the project culture

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

118
Understanding the projects culture

• 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
Understanding the projects culture

• Architecture driven style of development
  typically observe the following process
• 1. Specify the systems 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
OOAD---Architecture Centric

• 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
ESSENCE OF OOAD AND UML

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

122
Desire for good Architecture

• Those of us who have been trained as architects
  have this desire perhaps at the very center of
  our lives,that one day, some where somehow, we
  shall build one building which is wonderful,
  beautiful, breathtaking, a place where people can
  walk and dream for centuries.
• CHRISTOPHER ALEXANDER
• Same desire should also be applicable in
  creating software architecture as well.

123
Appendix-A
124

Strong recommendation

• Object Technology
• David A. Taylor
• Object Oriented Analysis and design with
  Applications
• Grady Booch
• UML distilled
• Martin Fowler
• Instant UML
• Pierre - Alain Muller
• Software Engineering
• Roger S Pressman

125
REFERENCES

• Contd...
• Object Oriented Modeling and Design
• James Rumbaugh
• Object Oriented Software Engineering
• Ivar Jacobson
• Clouds to code
• Jesse Liberty
• Applying use cases
• Geri Schneider
• Jason p. Winters
• UML Toolkit
• Hans-Eriksson and Magnus Penker

Version1.1
126
THANK-U!
127
Course description

• SESSION BREAKUP
• The course will be offered in series of fourteen
  hours theory session. One demonstration session
  on the tool like Rational Rose can be
  accompanied.The following is the suggested agenda
  for the course.
• Session Duration
• Module-1,2 2-hours demonstration lecture
• Module-3 2-hours
• Module-4 2-hours
• Module-5 4-hours
• Module-6 2-hours
• Module-7,8 2-hours
• Demonstration 2-hours

128
Course description

• REFERENCE AND READING MATERIALS
• Refer to Appendix-A
• EXERCISE AND HANDS ON
• One case study should be given to the group of
  four members.
• TEST
• Case study given for exercise can be evaluated
  as part of the test.

129
Course description

• INSTRUCTION TO THE FACULTY
• Course should emphasize on OO modeling.
• Focus should be primarily on understanding
  UML1.2 and UML diagrams and then applying to a
  problem.
• Several excellent references are given in
  Appendix-A. Following are strongly recommended
  reading and should be used as supplementary with
  this power point courseware.
• 1.UML toolkit by Eriksson and Magnus Penker
• 2.Object oriented analysis and design with
  applications by Grady Booch
• Note UML toolkit should be refereed for UML
  notations,their syntax and semantics.
• Object oriented analysis and design
  with applications should be refereed for OO
  concepts.