Systems Analysis and Design in a Changing World, Fifth Edition

1

• Systems Analysis and Design in a Changing World,
  Fifth Edition

2
Learning Objectives

• Explain the purpose and objectives of
  object-oriented design
• Develop component diagrams and deployment
  diagrams
• Develop design class diagrams
• Use CRC cards to define class responsibilities
  and collaborations
• Explain the fundamental principles of
  object-oriented design

3
Overview

• This chapter is thorough explanation of how to
  design simple systems
• Architechtural design is used to define the
  structure and configuration of the new system
• Good object-oriented design is based on
  fundamental design principles
• Design classes are a fundamental element in
  systems design
• Class-Responsibility-Collaboration (CRC) cards
  are useful for designing simple systems

4
Object-Oriented DesignThe 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 require design tasks and models

5
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 systems designer provides detail for
  programmers
• Design class diagrams, interaction diagrams, and
  some state machine diagrams

6
Object-Oriented Three-Layer Program
Figure 11-1
7
Object-Oriented Design Processes and Models

• Diagrams developed for analysis/requirements
• Use case diagrams, use case descriptions and
  activity diagrams, domain model class diagrams,
  and system sequence diagrams
• Diagrams developed for design
• Component diagrams and Deployment diagrams
• Interaction diagrams and package diagrams
• Design class diagrams

8
Design Models with Their Respective Input Models
Figure 11-2
9
Object-Oriented Architectural Design

• Desktop system
• Enterprise-level system
• Network or client/server system
• Internet based system

10
Differences between network and Internet systems
Figure 11-3
11
Component Diagrams and Architectural Design

• Component Diagram
• Shows overall system architecture
• API is the set of all public methods available in
  the component
• Ports and Sockets define the interface
• Frameset notation to extend UML notation
• Used to describe web components

12
Component Diagram Notation
Figure 11-4
13
Two-layer Architectural Design of an Internet
System
Figure 11-6
14
Three-layer Architectural Design of an Internet
system
Figure 11-7
15
Sample Web Services Design
Figure 11-8
16
Deployment Diagrams

• Deployment diagram shows physical components of a
  new system
• Node is a physical component
• Artifact is an executable module
• Artifacts are components after they have been
  compiled into executables

17
Sample Deployment Diagram of an Internet System
Figure 11-11
18
Fundamental Principles of Object-oriented
Detailed Design

• Design class diagrams and detailed sequence
  diagrams
• Use each other as inputs and are developed in
  parallel
• Sequence diagrams define the interactions between
  objects in order to execute a use case.
• Interactions are called messages
• Correspond to method calls in programming
  language
• Design Classes show attributes and method
  signatures

19
Sample Sequence Diagram
Figure 11-12
20
Sample Design Class
Figure 11-13
21
Sample Java Class Definition
Figure 11-14(a)
22
Object-oriented Design Process
Figure 11-15
23
Design Class Symbols

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

24
Standard Stereotypes Found in Design Models
Figure 11-16
25
Standard Design Classes

• Entity design identifier for problem domain
  class
• Persistent class exists after system is shut
  down
• Control mediates between boundary and entity
  classes, between the view layer and domain layer
• Boundary designed to live on systems
  automation boundary, touched by users
• User interface and windows classes
• Data access retrieves data from and sends data
  to database

26
Design Class Notation

• Name class name and stereotype information
• Attribute 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
• Class-level method method associated with class
  instead of each object (static or shared method),
  denoted by an underline

27
Notation Used to Define a Design Class
Figure 11-17
28
Design Class Definitions

• Overloaded method a method with one name but
  different parameter lists
• Class-level method a method associated with the
  class rather than an object
• Class-level attribute an attribute that
  contains the same value for all objects
• Overridden method a method in a subclass that
  overrides the parents method
• Abstract class a class that is never
  instantiated
• Concrete class a normal class with objects

29
Sample Class Diagram with Design Classes and
Inheritance
Figure 11-18
30
Developing the First-cut Design Class Diagram

• Elaborate the attributes
• Visibility, Type cast, Initial values
• Navigation Visibility
• Ability to reference the methods of another object

31
Navigation Visibility
Figure 11-20
32
Navigation Visibility Guidelines

• One-to-many with superior to subordinate. The
  visibility goes from the superior to the
  subordinate
• Mandatory relationships for existence. Visibility
  goes from independent to dependent
• Object needs information from another object.
  Visibility goes to object with the information
• Navigational arrows may be bidirectional

33
First Cut Class Diagram for RMO
Figure 11-21
34
Detailed Design with CRC cards

• Class-Responsibility-Collaboration
• Design process
• Select a single use case
• Identify class with primary responsibility
• Identify other classes that collaborate with
  primary class (become requests for service to
  other classes)?
• Identify responsibilities within each class
  (these become methods)?

35
CRC Card Notation
Figure 11-22
36
CRC Card Set for Process new order
Figure 11-23
37
Updated Design Class Diagram withVisibility and
Methods
Figure 11-24
38
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

39
Some Fundamental Design Principles (continued)

• Coupling qualitative measure of how closely
  classes in a design class diagram are linked
• Number of navigation arrows in design class
  diagram or messages in a sequence diagram
• Loosely coupled 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
• Highly cohesive system is easier to understand
  and maintain and reuse is more likely

40
Some Fundamental Design Principles(continued)?

• Protection from variations parts of a system
  that are unlikely to change are segregated from
  those that will
• Indirection an intermediate class is placed
  between two classes to decouple them but still
  link them
• Object responsibility Objects are responsible
  for system processing
• Responsibilities include knowing and doing

41
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 CRC Cards
• Domain class diagrams are transformed into design
  class diagram

42
Summary (continued)?

• Object-oriented design principles must be applied
• Encapsulation data fields are placed in classes
  along with methods to process that data
• Low coupling connectivity between classes
• High cohesion nature of an individual class
• Protection from variations parts of a system
  that are unlikely to change are segregated from
  those that will
• Indirection an intermediate class is placed
  between two classes to decouple them but still
  link them
• Separation navigation access classes have to
  other classes
• Three-layer design is used because maintainable