The Object-Oriented Approach to Design: Use Case Realization - PowerPoint PPT Presentation

Loading...

PPT – The Object-Oriented Approach to Design: Use Case Realization PowerPoint presentation | free to download - id: 5d9f7d-YTNlY



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

The Object-Oriented Approach to Design: Use Case Realization

Description:

Overview Primary focus of this chapter and the next is how to develop detailed object-oriented design models Programmers use models to code the system Two most ... – PowerPoint PPT presentation

Number of Views:701
Avg rating:3.0/5.0
Slides: 63
Provided by: JeffHed4
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: The Object-Oriented Approach to Design: Use Case Realization


1
The Object-Oriented Approach to Design Use Case
Realization
2
Overview
  • Primary focus of this chapter and the next is how
    to develop detailed object-oriented design models
  • Programmers use models to code the system
  • Two most important models are design class
    diagrams and interaction diagrams (sequence
    diagrams and collaboration diagrams)
  • Class diagrams are developed for domain, view,
    and data access layers
  • Interaction diagrams extend system sequence
    diagrams

3
Object-Oriented Design The Bridge Between
Analysis and Programming
  • Bridge between users requirements and new
    systems programming
  • Object-oriented design is process by which
    detailed object-oriented models are built
  • Programmers use design to write code and test new
    system
  • User-interface, network, controls, security, and
    database requires design tasks and models

4
Overview of Object-Oriented Programs
  • Set of objects that cooperate to accomplish
    result
  • Object contains program logic and necessary
    attributes in a single unit
  • Objects send each other messages and collaborate
    to support functions of main program
  • OO system designer provides detail for
    programmers
  • Design class diagrams, interaction diagrams,
    (some) statechart diagrams

5
Object-Oriented Event-Driven Program Flow
6
Simplified Design Class for Student Class
7
Object-Oriented Design Processes and Models
  • Diagrams developed during analysis
  • Use case diagrams, use case descriptions and
    activity diagrams, domain model class diagrams,
    and system sequence diagrams
  • Diagrams developed during design
  • Design class diagrams set of object-oriented
    classes needed for programming, navigation
    between classes, attribute names and properties
    and method names and properties
  • Interaction diagrams, package diagrams

8
Design Models with Their Respective Input Models
9
Iterative Process of OO Design
  • Create preliminary design class diagrams model
  • Develop interaction diagrams for each use case or
    scenario (realization of use cases)
  • Return to design class diagram
  • Develop method names based design of interaction
    diagrams
  • Update navigation visibility and attributes
  • Partition design class diagram into related
    functions using package diagrams (subsystems or
    layers)

10
Design Classes and Design Class Diagrams
  • Design class diagrams and detailed interaction
    diagrams
  • Use each other as inputs and developed in
    parallel
  • Design class diagram first-cut is from domain
    model and engineering design principles
  • Preliminary design class diagram used to develop
    interaction diagrams
  • Design decisions are made during development of
    interaction diagrams
  • Design class diagram is refined

11
Design Classes and Design Class Diagrams
(continued)
  • Design class diagram extends domain model class
    diagram developed during OO analysis
  • Shows set of problem domain classes and their
    association relationships
  • Describes design components within the classes
  • When developers build design class diagrams, more
    classes are added

12
Design Class Symbols
  • UML does not distinguish between design class
    notation and domain model notation
  • Domain modeling shows users work environment
  • Design class design specifically defines software
    classes
  • UML uses stereotype notation to categorize a
    model element by its characteristics

13
Standard Stereotypes Found in Design Models
14
Standard Design Classes
  • Entity design identifier for problem domain
    class
  • Persistent class exists after system is shut
    down
  • Boundary designed to live on systems
    automation boundary
  • User interface and windows classes
  • Control mediates between boundary and entity
    classes, between the view layer and domain layer
  • Data access retrieve from and send data to
    database

15
Design Class Notation
  • Name class name and stereotype information
  • Attributes visibility (private or public),
    attribute name, type-expression, initial-value,
    property
  • Method signature information needed to invoke
    (or call) the method
  • Method visibility, method name, type-expression
    (return parameter), method parameter list
    (incoming arguments)
  • Overloaded method method with same name but two
    or more different parameter lists

16
Internal Symbols Used to Define a Design Class
17
Student Class Examples for the Domain Diagram and
the Design Class Diagram
18
Some Fundamental Design Principles
  • Encapsulation each object is self-contained
    unit that includes data and methods that access
    data
  • Object reuse designers often reuse same classes
    for windows components
  • Information hiding data associated with object
    is not visible to outside world
  • Navigation visibility object is able to view
    and interact with another object

19
Navigation Visibility Between Customer and Order
20
Coupling and Cohesion
  • Coupling qualitative measure of how closely
    classes in a design class diagram are linked
  • Number of navigation arrows on design class
    diagram
  • Low system is easier to understand and maintain
  • Cohesion qualitative measure of consistency of
    functions within a single class
  • Separation of responsibility divide low
    cohesive class into several highly cohesive
    classes

21
Developing the First-Cut Design Class Diagram
  • Extend domain model class diagram
  • Elaborate attributes with type and initial value
    information
  • Add navigation visibility arrows
  • Detailed design proceeds, use case by use case
  • Interaction diagrams implement navigation
  • Navigation arrows are updated to be consistent
  • Method signatures are added to each class

22
RMO Domain Model Class Diagram
23
First-cut RMO Design Class Diagram
24
Interaction Diagrams Realizing Use Case and
Defining Methods
  • Realization of use case done through interaction
    diagram development
  • Determine what objects collaborate by sending
    messages to each other to carry out use case
  • Sequence diagrams and collaboration diagrams
    represent results of design decision
  • Use well-established design principles such as
    coupling, cohesion, separation of responsibilities

25
Partial Design Class Diagram for the Look Up Item
Availability Use Case
26
Object Responsibility
  • Objects responsible for system processing
  • Knowing about objects own data and other classes
    with which it collaborates to carry out use cases
  • Doing activities to assist in execution of use
    case
  • Receive and process messages
  • Instantiate, or create, new objects required to
    complete use case
  • CRC cards class-responsibility-collaboration

27
A CRC Card
28
Back of CRC Card
29
Use Case Controller
  • System sequence diagram (SSD) shows input
    messages from external actors within use case
  • Only indicates that messages go to system
  • Use case controller classes are designed as
    collection point for incoming messages
  • Artifact class invented to handle needed system
    function
  • Use case controller acts as intermediary between
    outside world and internal system

30
Designing with Sequence Diagrams
  • Sequence diagrams used to explain object
    interactions and document design decisions
  • Documents inputs to and outputs from system for
    single use case or scenario
  • Captures interactions between system and external
    world as represented by actors
  • Inputs are messages from actor to system
  • Outputs are return messages showing data

31
SSD for the Look Up Item Availability Use Case
32
First-Cut Sequence Diagram
  • Start with elements from SSD
  • Replace System object with use case controller
  • Add other objects to be included in use case
  • Select input message from the use case
  • Add all objects that must collaborate
  • Determine other messages to be sent
  • Which object is source and destination of each
    message?

33
Objects included in Look Up Item Availability
34
First-Cut Sequence Diagram for the Look Up Item
Availability Use Case
35
Guidelines for Preliminary Sequence Diagram
Development
  • Take each input message and determine internal
    messages that result from that input
  • For that message, determine its objective
  • Needed information, class destination, class
    source, and objects created as a result
  • Identify complete set of classes affected by each
    input message
  • Select objects from domain class diagram
  • Flesh out components for each message

36
Developing a Multilayer Design for Look up item
availability
  • First-cut sequence diagram classes in domain
    layer
  • Add design for user-interface classes view
    layer
  • Forms added as windows classes to sequence
    diagram
  • Add design for data access classes data access
    layer with separate classes for database
  • Tools build GUI and problem domain classes
  • Java and Visual Studio.NET

37
Look Up Item Availability Use Case with View
Layer and User-Interface Object
Class for input message
38
Partial Three-Layer Design for Look Up Item
Availability
Class for data access
39
Developing a First-Cut Sequence Diagram for RMO
Telephone Order
  • Design for each input message in the SSD
  • Design components for all messages are combined
    to provide comprehensive sequence diagram for
    entire use case
  • Information from SSD and first-cut design class
    diagram used to develop sequence diagram
  • Which object is source and which object is
    destination?
  • Navigation visibility destination object must
    be visible to source object

40
Completed Three-Layer Design for Look Up Item
Availability
41
SSD for the Telephone Order Scenario of the
Create New Order Use Case
42
Partial Sequence Diagram for the Telephone Order
Scenario
43
Another Partial Sequence Diagram for the
Telephone Order Scenario
44
Sequence Diagram for Telephone Order Scenario of
Create New Order Use Case
45
Developing a Multilayer Design for the Telephone
Order Scenario
  • To reduce complexity of diagrams, extend use case
    scenario one message at a time
  • Add user interface view layer to scenario
  • Add single data access class
  • Add each message to extend design
  • Sequence diagrams can become complicated
  • Completed design provides foundation for
    programming the use case

46
Telephone Order Sequence Diagram for the
startOrder Message
47
Telephone Order Sequence Diagram for the addItem
Message
48
Telephone Order Sequence Diagram for the final
messages
49
Designing with Collaboration Diagrams
  • Collaboration diagrams and sequence diagrams
  • Both are interaction diagrams
  • Both capture same information
  • Process of designing is same for both
  • Model used is designers personal preference
  • Sequence diagram because use case descriptions
    and dialog follow sequence of steps
  • Collaboration diagram emphasizes coupling

50
The Symbols of a Collaboration Diagram
51
A Collaboration Diagram for Look Up Item
Availability
52
A Collaboration Diagram for Create New Order
53
Look Up Item Availability Use Case Using Iconic
Symbols
54
Updating the Design Class Diagram
  • Design class diagrams developed for each layer
  • New classes for view layer and data access layer
  • New classes for domain layer use case controllers
  • Sequence diagrams messages used to add methods
  • Constructor methods,
  • Data get and set method
  • Use case specific methods

55
Design Class, with Method Signatures, for the
Order Class
56
Updated Design Class Diagram for the Domain Layer
57
Package Diagrams Structuring the Major
Components
  • High-level diagram in UML to associate classes of
    related groups
  • Identifies major components of a system and
    dependencies
  • Determines final program partitions for each
    layer
  • View, domain, data access
  • Can divide system into subsystem and show nesting
    within packages

58
Partial Design of a Three-Layer Package Diagram
for RMO
59
RMO Subsystem Packages
60
Implementation Issues for Three-Layer Design
  • Construct system with programming
  • Java or VB.NET
  • IDE tools (JBuilder, Visual Studio) provides help
  • Integration with user-interface design, database
    design, and network design
  • Use object responsibility to define program
    responsibilities for each layer
  • (View, domain, data access)

61
Summary
  • Object-oriented design is the bridge between user
    requirements (in analysis models) and final
    system (constructed in programming language)
  • Systems design is driven by use cases, design
    class diagrams, and sequence diagrams
  • Domain class diagrams are transformed into design
    class diagrams
  • Sequence diagrams are extensions of system
    sequence diagrams

62
Summary (continued)
  • Object-oriented design principles must be applied
  • Encapsulation data fields are placed in classes
    along with methods to process that data
  • Coupling connectivity between classes
  • Cohesion nature of an individual class
  • Navigation access classes have to other classes
  • Object responsibilities which messages are sent
    and received
  • Three-layer design is used because maintainable
About PowerShow.com