SlideShare ist ein Scribd-Unternehmen logo
1 von 98
Downloaden Sie, um offline zu lesen
Object-Oriented Paradigm
• Object-oriented paradigm
      – Reaction to perceived shortcomings in structured
        paradigm
      – Problem of larger products
      – Data and action treated as equal partners




CS540 Software Design         1                   Lecture 14 & 15
Object-Oriented Analysis (OOA)
    •    Semi-formal specification technique
    •    Multiplicity of different methods
    •    All essentially equivalent
    •    Nowadays, we represent OOA using UML (unified
         modeling language)




CS540 Software Design         2                  Lecture 14 & 15
The Three Steps of OOA
  • 1. Use-case modeling
     – Determine how the various results are computed by the
       product (without regard to sequencing)
     – Largely action oriented
  • 2. Class modeling (“object modeling”)
     – Determine the classes and their attributes
     – Purely data-oriented
  • 3. Dynamic modeling
     – Determine the actions performed by or to each class
     – Purely action-oriented

  • Iterative process
CS540 Software Design             3                   Lecture 14 & 15
The Object-Oriented Modeling
                  Approach
      • Benefits
         1. The ability to tackle more challenging problem
            domains
         2. Improved communication among
            users, analysts, designers, and programmers
         3. Reusability of analysis, design, and programming
            results
         4. Increased consistency among the models developed
            during object-oriented analysis, design, and
            programming

A.4                   Copyright © 2009 Pearson Education, Inc.
                             Publishing as Prentice Hall
The Object-Oriented Modeling
            Approach (continued)
  • Object-Oriented Systems Development Life
    Cycle
      – Process of progressively developing
        representation of a system component (or object)
        through the phases of analysis, design, and
        implementation
      – The model is abstract in the early stages
      – As the model evolves, it becomes more and more
        detailed

A.5                  Copyright © 2009 Pearson Education, Inc.
                            Publishing as Prentice Hall
The Object-Oriented Systems
            Development Life Cycle
  • Analysis Phase
      – Model of the real-world application is developed showing
        its important properties
      – Model specifies the functional behavior of the system
        independent of implementation details
  • Design Phase
      – Analysis model is refined and adapted to the environment
  • Implementation Phase
      – Design is implemented using a programming language or
        database management system



A.6                    Copyright © 2009 Pearson Education, Inc.
                              Publishing as Prentice Hall
The Object-Oriented Systems Development Life
                    Cycle (continued)
  • Unified Modeling Language (UML)
       – A notation that allows the modeler to specify, visualize and
         construct the artifacts of software systems, as well as
         business models
       – Techniques and notations
          •   Use cases
          •   Class diagrams
          •   State diagrams
          •   Sequence diagrams




A.7                        Copyright © 2009 Pearson Education, Inc.
                                  Publishing as Prentice Hall
Use-Case Modeling
  • Applied to analyze functional requirements of the
    system
  • Performed during the analysis phase to help
    developers understand functional requirements of
    the system without regard for implementation
    details
  • Use Case
      – A complete sequence of related actions initiated by an
        actor
  • Actor
      – An external entity that interacts with the system

A.8                     Copyright © 2009 Pearson Education, Inc.
                               Publishing as Prentice Hall
Use-Case Modeling
      • Use cases represent complete functionality
        of the system
      • Use cases may participate in relationships
        with other use cases
      • Use cases may also use other use cases




A.9                Copyright © 2009 Pearson Education, Inc.
                          Publishing as Prentice Hall
11 topic 9 ooa
Elevator Problem: OOA
• 1.        Use-Case Modeling
      – Use case: Generic description of overall functionality




• Get comprehensive insight into behavior of product


CS540 Software Design             11                        Lecture 14 & 15
Normal Scenario




CS540 Software Design          12         Lecture 14 & 15
Exception Scenario




CS540 Software Design         13             Lecture 14 & 15
Use Case
•    Use Case Name
•    Actors
•    Pre-Conditions
•    Normal Flow
•    Post-Conditions
•    Exceptions or Alternate Flows



CS540 Software Design      14        Lecture 14 & 15
Class Modeling

• Extract classes and their attributes
• Represent them using an entity-relationship
  diagram
• Deduce the classes from use cases and their
  scenarios
• Often there are many scenarios
     – Possible danger: too many candidate classes


CS540 Software Design        15                      Lecture 14 & 15
Two Approaches to Class Modeling
• Noun extraction
      – Always works
• CRC classes
      – Need to have domain expertise




CS540 Software Design       16          Lecture 14 & 15
Noun Extraction

• Stage 1. Concise Problem Definition
      – Define product in single sentence
             • Buttons in elevators and on the floors control the
               motion of n elevators in a building with m floors.




CS540 Software Design                 17                       Lecture 14 & 15
Noun Extraction (contd)
• Stage 2. Informal Strategy
      – Incorporate constraints, express result in a
        single paragraph
             • Buttons in elevators and on the floors control
               movement of n elevators in a building with m floors.
               Buttons illuminate when pressed to request the
               elevator to stop at a specific floor; illumination is
               canceled when the request has been satisfied. When
               an elevator has no requests, it remains at its current
               floor with its doors closed.


CS540 Software Design                18                        Lecture 14 & 15
Noun Extraction (contd)
• Stage 3. Formalize the Strategy
   – Identify nouns in informal strategy. Use nouns as candidate
     classes
• Nouns
   – button, elevator, floor, movement, building, illumination, do
     or
   – floor, building, door are outside problem boundary —
     exclude
   – movement and illumination are abstract nouns — exclude
     (may become attributes)
• Candidate classes: Elevator and Button
• Subclasses: Elevator Button and Floor Button


 CS540 Software Design              19                    Lecture 14 & 15
First Iteration of Class Diagram




    • Problem
       – Buttons do not communicate directly with elevators
       – We need an additional class: Elevator Controller
CS540 Software Design           20                      Lecture 14 & 15
Second Iteration of Class Diagram

• All relationships
  are now 1-to-n
      – Makes design and
        implementation
        easier




CS540 Software Design      21          Lecture 14 & 15
CRC Cards
• Class Responsibility Collaboration (CRC)
• Used since 1989 for OOA
• For each class, fill in card showing
    – Name of class
    – Functionality (responsibility)
    – List of classes it invokes (collaboration)
    – Now automated (CASE tool component)
• Strength
    – When acted out by team members, powerful tool for
      highlighting missing or incorrect items
• Weakness
    – Domain expertise is needed
 CS540 Software Design         22                  Lecture 14 & 15
3. Dynamic Modeling

• Produce UML state
  diagram
• State, event, predicate
  distributed over state
  diagram
• UML “guards” are in
  brackets


CS540 Software Design            23           Lecture 14 & 15
Testing during the OOA Phase
 • CRC cards are an excellent testing technique




CS540 Software Design      24              Lecture 14 & 15
CRC Cards
 • Consider responsibility
       – 1.             Turn on elevator button
 • Totally unacceptable for object-oriented
   paradigm
 • Responsibility-driven design ignored
 • Information hiding ignored
 • Responsibility
            1.          Turn on elevator button
      should be
            1.          Send message to Elevator Button to turn itself on
CS540 Software Design                       25                       Lecture 14 & 15
CRC Cards (contd)
• A class has been overlooked
      – Elevator doors have a state that changes during
        execution (class characteristic)
      – Add class Elevator Doors
      – Safety considerations
• Reconsider class model
• Then reconsider dynamic model, use-case
  model


CS540 Software Design           26                 Lecture 14 & 15
Second Iteration of CRC Card




CS540 Software Design       27                Lecture 14 & 15
Third Iteration of Class Diagram




CS540 Software Design     28              Lecture 14 & 15
Second Iteration of Normal Scenario




CS540 Software Design   29         Lecture 14 & 15
Elevator Problem: OOA (contd)
• All three models are now fine
• We should rather say:
      – All three models are fine for now
• We may need to return to the object-
  oriented analysis phase during the
  object-oriented design phase




CS540 Software Design         30            Lecture 14 & 15
Why Is All This Iteration Needed?
• Perhaps the method is not yet mature?
      – Waterfall model (explicit feedback loops)
      – Rapid prototyping model (aim: to reduce iteration)
      – Incremental model, and
      – Spiral model
• Latter two explicitly reflect iterative approach
• Iteration is an intrinsic property of all software
  production
      – Especially for medium- and large-scale products
      – Expect iteration in the object-oriented paradigm
CS540 Software Design         31                   Lecture 14 & 15
Figure 10.5 An example of a state diagram
10.32
Use case diagrams
A use-case diagram gives the user’s view of a system: it
shows how users communicate with the system. A use-case
diagram uses four components: system, use cases, actors and
relationships. A system, shown by a rectangle, performs a
function.




           Figure 10.6 An example of use case diagram
   10.33
Class diagrams
The next step in analysis is to create a class diagram for the
system. For example, we can create a class diagram for our
old-style elevator. To do so, we need to think about the
entities involved in the system.




           Figure 10.7 An example of a class diagram
   10.34
State chart
After the class diagram is finalized, a state chart can be
prepared for each class in the class diagram. A state chart in
object-oriented analysis plays the same role as the state
diagram in procedure-oriented analysis.




   10.35
Object Modeling:
                         Class Diagrams
  • Object
       – An entity that has a well-defined role in the application domain, and
         has state, behavior, and identity
  • State
       – A condition that encompasses an object’s properties and the values
         those properties have
  • Behavior
       – A manner that represents how an object acts and reacts
  • Object Class
       – A set of objects that share a common structure and a common
         behavior



A.36                         Copyright © 2009 Pearson Education, Inc.
                                    Publishing as Prentice Hall
Object Modeling:
           Class Diagrams (continued)
       • Class Diagram
         – Class is represented as a rectangle with three
           compartments
         – Objects can participate in relationships with
           objects of the same class




A.37                  Copyright © 2009 Pearson Education, Inc.
                             Publishing as Prentice Hall
Object Modeling:
                         Object Diagrams
  • Object Diagram
       – A graph of instances that are compatible with a given class diagram;
         also called an instance diagram
       – Object is represented as a rectangle with two compartments
  • Operation
       – A function or service that is provided by all the instances of a class
  • Encapsulation
       – The technique of hiding the internal implementation details of an
         object from its external view




A.38                          Copyright © 2009 Pearson Education, Inc.
                                     Publishing as Prentice Hall
A.39   Copyright © 2009 Pearson Education, Inc.
              Publishing as Prentice Hall
Representing Associations
  • Association
       – A relationship between object classes
       – Degree may be unary, binary, ternary or higher
       – Depicted as a solid line between participating classes
  • Association Role
       – The end of an association where it connects to a class
       – Each role has multiplicity, which indicates how many
         objects participate in a given association relationship




A.40                     Copyright © 2009 Pearson Education, Inc.
                                Publishing as Prentice Hall
A.41   Copyright © 2009 Pearson Education, Inc.
              Publishing as Prentice Hall
Representing Generalization
  • Generalization
       – Abstraction of common features among multiple
         classes, as well as their relationships, into a more general
         class
  • Subclass
       – A class that has been generalized
  • Superclass
       – A class that is composed of several generalized subclasses



A.42                      Copyright © 2009 Pearson Education, Inc.
                                 Publishing as Prentice Hall
Representing Generalization (continued)
  • Discriminator
       – Shows which property of an object class is being
         abstracted by a generalization relationship
  • Inheritance
       – A property that a subclass inherits the features from its
         superclass
  • Abstract Class
       – A class that has no direct instances but whose descendents
         may have direct instances
  • Concrete Class
       – A class that can have direct instances

A.43                     Copyright © 2009 Pearson Education, Inc.
                                Publishing as Prentice Hall
A.44   Copyright © 2009 Pearson Education, Inc.
              Publishing as Prentice Hall
Representing Aggregation
       • Aggregation
         – A part-of relationship between a component
           object and an aggregate object
         – Example: Personal computer
            • Composed of CPU, Monitor, Keyboard, etc.




A.45                   Copyright © 2009 Pearson Education, Inc.
                              Publishing as Prentice Hall
Dynamic Modeling:
                        State Diagrams
  • State
       – A condition during the life of an object during which it satisfies some
         conditions, performs some actions or waits for some events
       – Shown as a rectangle with rounded corners
  • State Transition
       – The changes in the attributes of an object or in the links an object has
         with other objects
       – Shown as a solid arrow
       – Diagrammed with a guard condition and action
  • Event
       – Something that takes place at a certain point in time



A.46                         Copyright © 2009 Pearson Education, Inc.
                                    Publishing as Prentice Hall
A.47   Copyright © 2009 Pearson Education, Inc.
              Publishing as Prentice Hall
Dynamic Modeling:
                   Sequence Diagrams
  • Sequence Diagram
       – A depiction of the interaction among objects during
         certain periods of time
  • Activation
       – The time period during which an object performs an
         operation
  • Messages
       – Means by which objects communicate with each other



A.48                     Copyright © 2009 Pearson Education, Inc.
                                Publishing as Prentice Hall
Dynamic Modeling:
          Sequence Diagrams (continued)
  • Synchronous Message
       – A type of message in which the caller has to wait
         for the receiving object to finish executing the
         called operation before it can resume execution
         itself
  • Simple Message
       – A message that transfers control from the sender
         to the recipient without describing the details of
         the communication

A.49                   Copyright © 2009 Pearson Education, Inc.
                              Publishing as Prentice Hall
A.50   Copyright © 2009 Pearson Education, Inc.
              Publishing as Prentice Hall
Moving to Design
       • Start with existing set of analysis model
       • Progressively add technical details
       • Design model must be more detailed than
         analysis model
       • Component Diagram
          – A diagram that shows the software components or
            modules and their dependencies
       • Deployment Diagram
          – A diagram that shows how the software
            components, processes and objects are deployed into
            the physical architecture of the system

A.51                    Copyright © 2009 Pearson Education, Inc.
                               Publishing as Prentice Hall
A.52   Copyright © 2009 Pearson Education, Inc.
              Publishing as Prentice Hall
Summary
       • Object-Oriented Modeling Approach
         – Benefits
         – Unified Modeling Language
            •   Use cases
            •   Class diagrams
            •   State diagrams
            •   Sequence diagrams
       • Use Case Modeling

A.53                    Copyright © 2009 Pearson Education, Inc.
                               Publishing as Prentice Hall
EXAMPLE 2
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?




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


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



                                                                               57
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




                                                                             58
OOAD --- USE CASE driven


     Analysis             Design &
                          Implementation                  Test




                       Use cases make up the glue




                            Implement               Verify that use cases
Capture,clarify              use cases              are satisfied
& validate use cases




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




                                                                        60
RELATIONSHIP:
What is Relationship?

• Relationship between use case and actor.
        Communicates
• Relationship between two use cases
        Extends
        Uses
• Notation used to show the relationships:

        <<      >>


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




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




                                                                 63
USE CASE diagram:

 Use case diagram for the shown functionality.


                                                  Balance status
                                                  report
                                     extends




Clerk              Withdraw cash
                                                                   Customer
                                       uses




                                               Validation

                                                                     ATM
 Manager

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




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




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




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




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




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




                                                                            70
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”.




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




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




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




                                                                   74
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




                                                                             75
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




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




                                                                         77
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.
                      Name:Class




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



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




                                                                             80
Sequence diagram                             [for withdrawal of cash, normal flow]



:Customer                       :ATM                                       :Bank
            Insert card
        Request password
        Enter the password
                                           Verify account
                                            Account o.k.
            Request option
             Enter option              Create

            Request amount
                                       Transaction
                                                     :Transaction
            Enter the amount
                                         Update transaction
                                         Transaction commit
                                          Transaction
              Dispense cash                complete
            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.
                                                                                      81
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.




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




                                                                                               83
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




                                                                             84
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



                                                  85
The examples of message:

   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




                                                      86
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
   CUST-                                                                                  TRANSA-
                                                       ATM                                CTION
   OMER      Display main screen
             unreadable card message,
             request password,
             request kind, request amount,
             canceled message, eject card, failure message,
             dispense cash, request take cash                       Transaction succeed
             request continuation,                                  Transaction failed
             print receipt, request take card                       account o.k.
             bad account message,             Verify account,       bad account,
             bad bank account message         process transaction   bad password,
                                                                    bad bank code

                                                       BANK



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




                                                                            88
Module-5



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




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




                                                                                    91
11 topic 9 ooa
10-3 DESIGN PHASE



The design phase defines how the system will
accomplish what was defined in the analysis phase. In
the design phase, all components of the system are
defined.




 10.93
Procedure-oriented design

In procedure-oriented design we have both procedures and
data to design. We discuss a category of design methods that
concentrate on procedures. In procedure-oriented design, the
whole system is divided into a set of procedures or modules.




    10.94
Structure charts
A common tool for illustrating the relations between
modules in procedure-oriented design is a structure chart.
For example, the elevator system whose state diagram is
shown in the previous slides can be designed as a set of
modules shown in the structure chart below




   10.95
                 A structure chart
Modularity
Modularity means breaking a large project into smaller parts
that can be understood and handled easily. In other
words, modularity means dividing a large task into small
tasks that can communicate with each other. The structure
chart discussed in the previous section shows the modularity
in the elevator system. There are two main concerns when a
system is divided into modules: coupling and cohesion.

Coupling is a measure of how tightly two modules are bound
to each other.
   i

           Coupling between modules in a software system
                        must be minimized.
   10.96
Another issue in modularity is cohesion. Cohesion is a
measure of how closely the modules in a system are related.
We need to have maximum possible cohesion between
modules in a software system.

  i

          Cohesion between modules in a software system
                       must be maximized.




  10.97
Object-oriented design

In object-oriented design the design phase continues by
elaborating the details of classes. As we mentioned in
Chapter 9, a class is made of a set of variables (attributes)
and a set of methods. The object-oriented design phase lists
details of these attributes and methods. Figure 10.9 shows an
example of the details of our four classes used in the design
of the old-style elevator.




            Figure 10.9 An example of classes with attributes and methods
    10.98

Weitere ähnliche Inhalte

Andere mochten auch

Oo Design And Patterns
Oo Design And PatternsOo Design And Patterns
Oo Design And PatternsAnil Bapat
 
Software Design Patterns in Practice
Software Design Patterns in PracticeSoftware Design Patterns in Practice
Software Design Patterns in PracticePtidej Team
 
Object Oriented Approach for Software Development
Object Oriented Approach for Software DevelopmentObject Oriented Approach for Software Development
Object Oriented Approach for Software DevelopmentRishabh Soni
 
3 - Architetture Software - Architectural styles
3 - Architetture Software - Architectural styles3 - Architetture Software - Architectural styles
3 - Architetture Software - Architectural stylesMajong DevJfu
 
A Software Architect's View On Diagramming
A Software Architect's View On DiagrammingA Software Architect's View On Diagramming
A Software Architect's View On Diagrammingmeghantaylor
 
Object oriented programming systems
Object oriented programming systemsObject oriented programming systems
Object oriented programming systemsrchakra
 
Uml Presentation
Uml PresentationUml Presentation
Uml Presentationmewaseem
 
Uml diagrams
Uml diagramsUml diagrams
Uml diagramsbarney92
 
Object Oriented Analysis and Design
Object Oriented Analysis and DesignObject Oriented Analysis and Design
Object Oriented Analysis and DesignHaitham El-Ghareeb
 

Andere mochten auch (11)

Oo Design And Patterns
Oo Design And PatternsOo Design And Patterns
Oo Design And Patterns
 
Software Design Patterns in Practice
Software Design Patterns in PracticeSoftware Design Patterns in Practice
Software Design Patterns in Practice
 
Object Oriented Approach for Software Development
Object Oriented Approach for Software DevelopmentObject Oriented Approach for Software Development
Object Oriented Approach for Software Development
 
3 - Architetture Software - Architectural styles
3 - Architetture Software - Architectural styles3 - Architetture Software - Architectural styles
3 - Architetture Software - Architectural styles
 
A Software Architect's View On Diagramming
A Software Architect's View On DiagrammingA Software Architect's View On Diagramming
A Software Architect's View On Diagramming
 
Object oriented programming systems
Object oriented programming systemsObject oriented programming systems
Object oriented programming systems
 
software architecture
software architecturesoftware architecture
software architecture
 
Uml Presentation
Uml PresentationUml Presentation
Uml Presentation
 
Uml diagrams
Uml diagramsUml diagrams
Uml diagrams
 
Layered Software Architecture
Layered Software ArchitectureLayered Software Architecture
Layered Software Architecture
 
Object Oriented Analysis and Design
Object Oriented Analysis and DesignObject Oriented Analysis and Design
Object Oriented Analysis and Design
 

Ähnlich wie 11 topic 9 ooa

Object Oriented Analysis and Design Unit-1
Object Oriented Analysis and Design Unit-1Object Oriented Analysis and Design Unit-1
Object Oriented Analysis and Design Unit-1SangeethaSubramaniam14
 
SE 1a SDLC Session BCU.ppt
SE 1a SDLC Session BCU.pptSE 1a SDLC Session BCU.ppt
SE 1a SDLC Session BCU.pptMahiDivya
 
CS6502 OOAD - Question Bank and Answer
CS6502 OOAD - Question Bank and AnswerCS6502 OOAD - Question Bank and Answer
CS6502 OOAD - Question Bank and AnswerGobinath Subramaniam
 
IT Software Development Life Cycle
IT Software Development Life CycleIT Software Development Life Cycle
IT Software Development Life CyclePreshita Chaurasiya
 
Software development Life Cycle
Software development Life CycleSoftware development Life Cycle
Software development Life CycleKumar
 
Pressman ch-3-prescriptive-process-models
Pressman ch-3-prescriptive-process-modelsPressman ch-3-prescriptive-process-models
Pressman ch-3-prescriptive-process-modelsNoor Ul Hudda Memon
 
The art of architecture
The art of architectureThe art of architecture
The art of architectureADDQ
 
Software engineering lecture notes
Software engineering lecture notesSoftware engineering lecture notes
Software engineering lecture notesSiva Ayyakutti
 
Software Development Life Cycle
Software Development Life CycleSoftware Development Life Cycle
Software Development Life CycleAashima Wadhwa
 
Machine Learning in Software Engineering
Machine Learning in Software EngineeringMachine Learning in Software Engineering
Machine Learning in Software EngineeringAlaa Hamouda
 
Offshore Software Development company India
Offshore Software Development company IndiaOffshore Software Development company India
Offshore Software Development company Indiarahulkwebvirtue
 
Iscope Digital Media Offshore Software Development Company
Iscope Digital Media Offshore Software Development CompanyIscope Digital Media Offshore Software Development Company
Iscope Digital Media Offshore Software Development CompanyIscope Digital
 
software development life cycle
software development life cyclesoftware development life cycle
software development life cycleAnanthachethan
 

Ähnlich wie 11 topic 9 ooa (20)

Object Oriented Analysis and Design Unit-1
Object Oriented Analysis and Design Unit-1Object Oriented Analysis and Design Unit-1
Object Oriented Analysis and Design Unit-1
 
DITEC - Software Engineering
DITEC - Software EngineeringDITEC - Software Engineering
DITEC - Software Engineering
 
SE 1a SDLC Session BCU.ppt
SE 1a SDLC Session BCU.pptSE 1a SDLC Session BCU.ppt
SE 1a SDLC Session BCU.ppt
 
CS6502 OOAD - Question Bank and Answer
CS6502 OOAD - Question Bank and AnswerCS6502 OOAD - Question Bank and Answer
CS6502 OOAD - Question Bank and Answer
 
Unit 2
Unit 2Unit 2
Unit 2
 
IT Software Development Life Cycle
IT Software Development Life CycleIT Software Development Life Cycle
IT Software Development Life Cycle
 
Software development Life Cycle
Software development Life CycleSoftware development Life Cycle
Software development Life Cycle
 
Pressman ch-3-prescriptive-process-models
Pressman ch-3-prescriptive-process-modelsPressman ch-3-prescriptive-process-models
Pressman ch-3-prescriptive-process-models
 
The art of architecture
The art of architectureThe art of architecture
The art of architecture
 
Software engineering lecture notes
Software engineering lecture notesSoftware engineering lecture notes
Software engineering lecture notes
 
Waterfall Model
Waterfall ModelWaterfall Model
Waterfall Model
 
Software Development Life Cycle
Software Development Life CycleSoftware Development Life Cycle
Software Development Life Cycle
 
Sdlc
SdlcSdlc
Sdlc
 
Machine Learning in Software Engineering
Machine Learning in Software EngineeringMachine Learning in Software Engineering
Machine Learning in Software Engineering
 
Session2
Session2Session2
Session2
 
SDLC
SDLCSDLC
SDLC
 
5-CEN6016-Chapter1.ppt
5-CEN6016-Chapter1.ppt5-CEN6016-Chapter1.ppt
5-CEN6016-Chapter1.ppt
 
Offshore Software Development company India
Offshore Software Development company IndiaOffshore Software Development company India
Offshore Software Development company India
 
Iscope Digital Media Offshore Software Development Company
Iscope Digital Media Offshore Software Development CompanyIscope Digital Media Offshore Software Development Company
Iscope Digital Media Offshore Software Development Company
 
software development life cycle
software development life cyclesoftware development life cycle
software development life cycle
 

Mehr von Ayesha Bhatti (20)

Ds lab handouts
Ds lab handoutsDs lab handouts
Ds lab handouts
 
Chap 5 project management
Chap 5 project managementChap 5 project management
Chap 5 project management
 
Assignment
AssignmentAssignment
Assignment
 
Aibo
AiboAibo
Aibo
 
A2
A2A2
A2
 
10 architectural design
10 architectural design10 architectural design
10 architectural design
 
10 architectural design (1)
10 architectural design (1)10 architectural design (1)
10 architectural design (1)
 
8 system models
8 system models8 system models
8 system models
 
8 system models (1)
8 system models (1)8 system models (1)
8 system models (1)
 
8 bop
8 bop8 bop
8 bop
 
8 bop (1)
8 bop (1)8 bop (1)
8 bop (1)
 
7 foreign policy process
7 foreign policy process7 foreign policy process
7 foreign policy process
 
7 foreign policy process (1)
7 foreign policy process (1)7 foreign policy process (1)
7 foreign policy process (1)
 
5 cold war era 1
5 cold war era 15 cold war era 1
5 cold war era 1
 
3 national power
3 national power3 national power
3 national power
 
1 introduction
1 introduction1 introduction
1 introduction
 
1 introduction (1)
1 introduction (1)1 introduction (1)
1 introduction (1)
 
A1
A1A1
A1
 
Project final
Project finalProject final
Project final
 
Assignment 3
Assignment 3Assignment 3
Assignment 3
 

11 topic 9 ooa

  • 1. Object-Oriented Paradigm • Object-oriented paradigm – Reaction to perceived shortcomings in structured paradigm – Problem of larger products – Data and action treated as equal partners CS540 Software Design 1 Lecture 14 & 15
  • 2. Object-Oriented Analysis (OOA) • Semi-formal specification technique • Multiplicity of different methods • All essentially equivalent • Nowadays, we represent OOA using UML (unified modeling language) CS540 Software Design 2 Lecture 14 & 15
  • 3. The Three Steps of OOA • 1. Use-case modeling – Determine how the various results are computed by the product (without regard to sequencing) – Largely action oriented • 2. Class modeling (“object modeling”) – Determine the classes and their attributes – Purely data-oriented • 3. Dynamic modeling – Determine the actions performed by or to each class – Purely action-oriented • Iterative process CS540 Software Design 3 Lecture 14 & 15
  • 4. The Object-Oriented Modeling Approach • Benefits 1. The ability to tackle more challenging problem domains 2. Improved communication among users, analysts, designers, and programmers 3. Reusability of analysis, design, and programming results 4. Increased consistency among the models developed during object-oriented analysis, design, and programming A.4 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  • 5. The Object-Oriented Modeling Approach (continued) • Object-Oriented Systems Development Life Cycle – Process of progressively developing representation of a system component (or object) through the phases of analysis, design, and implementation – The model is abstract in the early stages – As the model evolves, it becomes more and more detailed A.5 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  • 6. The Object-Oriented Systems Development Life Cycle • Analysis Phase – Model of the real-world application is developed showing its important properties – Model specifies the functional behavior of the system independent of implementation details • Design Phase – Analysis model is refined and adapted to the environment • Implementation Phase – Design is implemented using a programming language or database management system A.6 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  • 7. The Object-Oriented Systems Development Life Cycle (continued) • Unified Modeling Language (UML) – A notation that allows the modeler to specify, visualize and construct the artifacts of software systems, as well as business models – Techniques and notations • Use cases • Class diagrams • State diagrams • Sequence diagrams A.7 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  • 8. Use-Case Modeling • Applied to analyze functional requirements of the system • Performed during the analysis phase to help developers understand functional requirements of the system without regard for implementation details • Use Case – A complete sequence of related actions initiated by an actor • Actor – An external entity that interacts with the system A.8 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  • 9. Use-Case Modeling • Use cases represent complete functionality of the system • Use cases may participate in relationships with other use cases • Use cases may also use other use cases A.9 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  • 11. Elevator Problem: OOA • 1. Use-Case Modeling – Use case: Generic description of overall functionality • Get comprehensive insight into behavior of product CS540 Software Design 11 Lecture 14 & 15
  • 12. Normal Scenario CS540 Software Design 12 Lecture 14 & 15
  • 13. Exception Scenario CS540 Software Design 13 Lecture 14 & 15
  • 14. Use Case • Use Case Name • Actors • Pre-Conditions • Normal Flow • Post-Conditions • Exceptions or Alternate Flows CS540 Software Design 14 Lecture 14 & 15
  • 15. Class Modeling • Extract classes and their attributes • Represent them using an entity-relationship diagram • Deduce the classes from use cases and their scenarios • Often there are many scenarios – Possible danger: too many candidate classes CS540 Software Design 15 Lecture 14 & 15
  • 16. Two Approaches to Class Modeling • Noun extraction – Always works • CRC classes – Need to have domain expertise CS540 Software Design 16 Lecture 14 & 15
  • 17. Noun Extraction • Stage 1. Concise Problem Definition – Define product in single sentence • Buttons in elevators and on the floors control the motion of n elevators in a building with m floors. CS540 Software Design 17 Lecture 14 & 15
  • 18. Noun Extraction (contd) • Stage 2. Informal Strategy – Incorporate constraints, express result in a single paragraph • Buttons in elevators and on the floors control movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator to stop at a specific floor; illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed. CS540 Software Design 18 Lecture 14 & 15
  • 19. Noun Extraction (contd) • Stage 3. Formalize the Strategy – Identify nouns in informal strategy. Use nouns as candidate classes • Nouns – button, elevator, floor, movement, building, illumination, do or – floor, building, door are outside problem boundary — exclude – movement and illumination are abstract nouns — exclude (may become attributes) • Candidate classes: Elevator and Button • Subclasses: Elevator Button and Floor Button CS540 Software Design 19 Lecture 14 & 15
  • 20. First Iteration of Class Diagram • Problem – Buttons do not communicate directly with elevators – We need an additional class: Elevator Controller CS540 Software Design 20 Lecture 14 & 15
  • 21. Second Iteration of Class Diagram • All relationships are now 1-to-n – Makes design and implementation easier CS540 Software Design 21 Lecture 14 & 15
  • 22. CRC Cards • Class Responsibility Collaboration (CRC) • Used since 1989 for OOA • For each class, fill in card showing – Name of class – Functionality (responsibility) – List of classes it invokes (collaboration) – Now automated (CASE tool component) • Strength – When acted out by team members, powerful tool for highlighting missing or incorrect items • Weakness – Domain expertise is needed CS540 Software Design 22 Lecture 14 & 15
  • 23. 3. Dynamic Modeling • Produce UML state diagram • State, event, predicate distributed over state diagram • UML “guards” are in brackets CS540 Software Design 23 Lecture 14 & 15
  • 24. Testing during the OOA Phase • CRC cards are an excellent testing technique CS540 Software Design 24 Lecture 14 & 15
  • 25. CRC Cards • Consider responsibility – 1. Turn on elevator button • Totally unacceptable for object-oriented paradigm • Responsibility-driven design ignored • Information hiding ignored • Responsibility 1. Turn on elevator button should be 1. Send message to Elevator Button to turn itself on CS540 Software Design 25 Lecture 14 & 15
  • 26. CRC Cards (contd) • A class has been overlooked – Elevator doors have a state that changes during execution (class characteristic) – Add class Elevator Doors – Safety considerations • Reconsider class model • Then reconsider dynamic model, use-case model CS540 Software Design 26 Lecture 14 & 15
  • 27. Second Iteration of CRC Card CS540 Software Design 27 Lecture 14 & 15
  • 28. Third Iteration of Class Diagram CS540 Software Design 28 Lecture 14 & 15
  • 29. Second Iteration of Normal Scenario CS540 Software Design 29 Lecture 14 & 15
  • 30. Elevator Problem: OOA (contd) • All three models are now fine • We should rather say: – All three models are fine for now • We may need to return to the object- oriented analysis phase during the object-oriented design phase CS540 Software Design 30 Lecture 14 & 15
  • 31. Why Is All This Iteration Needed? • Perhaps the method is not yet mature? – Waterfall model (explicit feedback loops) – Rapid prototyping model (aim: to reduce iteration) – Incremental model, and – Spiral model • Latter two explicitly reflect iterative approach • Iteration is an intrinsic property of all software production – Especially for medium- and large-scale products – Expect iteration in the object-oriented paradigm CS540 Software Design 31 Lecture 14 & 15
  • 32. Figure 10.5 An example of a state diagram 10.32
  • 33. Use case diagrams A use-case diagram gives the user’s view of a system: it shows how users communicate with the system. A use-case diagram uses four components: system, use cases, actors and relationships. A system, shown by a rectangle, performs a function. Figure 10.6 An example of use case diagram 10.33
  • 34. Class diagrams The next step in analysis is to create a class diagram for the system. For example, we can create a class diagram for our old-style elevator. To do so, we need to think about the entities involved in the system. Figure 10.7 An example of a class diagram 10.34
  • 35. State chart After the class diagram is finalized, a state chart can be prepared for each class in the class diagram. A state chart in object-oriented analysis plays the same role as the state diagram in procedure-oriented analysis. 10.35
  • 36. Object Modeling: Class Diagrams • Object – An entity that has a well-defined role in the application domain, and has state, behavior, and identity • State – A condition that encompasses an object’s properties and the values those properties have • Behavior – A manner that represents how an object acts and reacts • Object Class – A set of objects that share a common structure and a common behavior A.36 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  • 37. Object Modeling: Class Diagrams (continued) • Class Diagram – Class is represented as a rectangle with three compartments – Objects can participate in relationships with objects of the same class A.37 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  • 38. Object Modeling: Object Diagrams • Object Diagram – A graph of instances that are compatible with a given class diagram; also called an instance diagram – Object is represented as a rectangle with two compartments • Operation – A function or service that is provided by all the instances of a class • Encapsulation – The technique of hiding the internal implementation details of an object from its external view A.38 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  • 39. A.39 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  • 40. Representing Associations • Association – A relationship between object classes – Degree may be unary, binary, ternary or higher – Depicted as a solid line between participating classes • Association Role – The end of an association where it connects to a class – Each role has multiplicity, which indicates how many objects participate in a given association relationship A.40 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  • 41. A.41 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  • 42. Representing Generalization • Generalization – Abstraction of common features among multiple classes, as well as their relationships, into a more general class • Subclass – A class that has been generalized • Superclass – A class that is composed of several generalized subclasses A.42 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  • 43. Representing Generalization (continued) • Discriminator – Shows which property of an object class is being abstracted by a generalization relationship • Inheritance – A property that a subclass inherits the features from its superclass • Abstract Class – A class that has no direct instances but whose descendents may have direct instances • Concrete Class – A class that can have direct instances A.43 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  • 44. A.44 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  • 45. Representing Aggregation • Aggregation – A part-of relationship between a component object and an aggregate object – Example: Personal computer • Composed of CPU, Monitor, Keyboard, etc. A.45 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  • 46. Dynamic Modeling: State Diagrams • State – A condition during the life of an object during which it satisfies some conditions, performs some actions or waits for some events – Shown as a rectangle with rounded corners • State Transition – The changes in the attributes of an object or in the links an object has with other objects – Shown as a solid arrow – Diagrammed with a guard condition and action • Event – Something that takes place at a certain point in time A.46 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  • 47. A.47 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  • 48. Dynamic Modeling: Sequence Diagrams • Sequence Diagram – A depiction of the interaction among objects during certain periods of time • Activation – The time period during which an object performs an operation • Messages – Means by which objects communicate with each other A.48 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  • 49. Dynamic Modeling: Sequence Diagrams (continued) • Synchronous Message – A type of message in which the caller has to wait for the receiving object to finish executing the called operation before it can resume execution itself • Simple Message – A message that transfers control from the sender to the recipient without describing the details of the communication A.49 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  • 50. A.50 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  • 51. Moving to Design • Start with existing set of analysis model • Progressively add technical details • Design model must be more detailed than analysis model • Component Diagram – A diagram that shows the software components or modules and their dependencies • Deployment Diagram – A diagram that shows how the software components, processes and objects are deployed into the physical architecture of the system A.51 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  • 52. A.52 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  • 53. Summary • Object-Oriented Modeling Approach – Benefits – Unified Modeling Language • Use cases • Class diagrams • State diagrams • Sequence diagrams • Use Case Modeling A.53 Copyright © 2009 Pearson Education, Inc. Publishing as Prentice Hall
  • 55. 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? 55
  • 56. 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. 56
  • 57. 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. 57
  • 58. 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 58
  • 59. OOAD --- USE CASE driven Analysis Design & Implementation Test Use cases make up the glue Implement Verify that use cases Capture,clarify use cases are satisfied & validate use cases 59
  • 60. 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. 60
  • 61. RELATIONSHIP: What is Relationship? • Relationship between use case and actor. Communicates • Relationship between two use cases Extends Uses • Notation used to show the relationships: << >> 61
  • 62. 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. 62
  • 63. 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. 63
  • 64. USE CASE diagram: Use case diagram for the shown functionality. Balance status report extends Clerk Withdraw cash Customer uses Validation ATM Manager 64
  • 65. Objective • To understand and capture the detailed specification of a system to be developed, from user perspective. 65
  • 66. 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. 66
  • 67. 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) 67
  • 68. 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. 68
  • 69. 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. 69
  • 70. 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. 70
  • 71. 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”. 71
  • 72. 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. 72
  • 73. 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. 73
  • 74. 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. 74
  • 75. 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 75
  • 76. 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 76
  • 77. 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. 77
  • 78. 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. Name:Class 78
  • 79. 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. 79
  • 80. 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. 80
  • 81. Sequence diagram [for withdrawal of cash, normal flow] :Customer :ATM :Bank Insert card Request password Enter the password Verify account Account o.k. Request option Enter option Create Request amount Transaction :Transaction Enter the amount Update transaction Transaction commit Transaction Dispense cash complete 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. 81
  • 82. 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. 82
  • 83. 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. 83
  • 84. 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 84
  • 85. 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 85
  • 86. The examples of message: 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 86
  • 87. 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 CUST- TRANSA- ATM CTION OMER Display main screen unreadable card message, request password, request kind, request amount, canceled message, eject card, failure message, dispense cash, request take cash Transaction succeed request continuation, Transaction failed print receipt, request take card account o.k. bad account message, Verify account, bad account, bad bank account message process transaction bad password, bad bank code BANK 87
  • 88. 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. 88
  • 89. Module-5 89
  • 90. 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. 90
  • 91. 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. 91
  • 93. 10-3 DESIGN PHASE The design phase defines how the system will accomplish what was defined in the analysis phase. In the design phase, all components of the system are defined. 10.93
  • 94. Procedure-oriented design In procedure-oriented design we have both procedures and data to design. We discuss a category of design methods that concentrate on procedures. In procedure-oriented design, the whole system is divided into a set of procedures or modules. 10.94
  • 95. Structure charts A common tool for illustrating the relations between modules in procedure-oriented design is a structure chart. For example, the elevator system whose state diagram is shown in the previous slides can be designed as a set of modules shown in the structure chart below 10.95 A structure chart
  • 96. Modularity Modularity means breaking a large project into smaller parts that can be understood and handled easily. In other words, modularity means dividing a large task into small tasks that can communicate with each other. The structure chart discussed in the previous section shows the modularity in the elevator system. There are two main concerns when a system is divided into modules: coupling and cohesion. Coupling is a measure of how tightly two modules are bound to each other. i Coupling between modules in a software system must be minimized. 10.96
  • 97. Another issue in modularity is cohesion. Cohesion is a measure of how closely the modules in a system are related. We need to have maximum possible cohesion between modules in a software system. i Cohesion between modules in a software system must be maximized. 10.97
  • 98. Object-oriented design In object-oriented design the design phase continues by elaborating the details of classes. As we mentioned in Chapter 9, a class is made of a set of variables (attributes) and a set of methods. The object-oriented design phase lists details of these attributes and methods. Figure 10.9 shows an example of the details of our four classes used in the design of the old-style elevator. Figure 10.9 An example of classes with attributes and methods 10.98