11 systems analysis and design in a changing world, fifth edition
TRANSCRIPT
11Systems Analysis and Design in a
Changing World, Fifth Edition
11
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
11
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
11
4
Object-Oriented Design—The Bridge Between Analysis and Programming
Bridge between users’ requirements and new system’s 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
11
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
11
6
Object-Oriented Three-Layer Program
11
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
11
8
Design Models with
Their Respective
Input Models
11
9
Object-Oriented Architectural Design
Desktop system
Enterprise-level system
Network or client/server system
Internet based system
11
10
Differences between network and Internet systems
11
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
11
12
Component Diagram Notation
11
13
Two-layer Architectural Design of an Internet System
11
14
Three-layer Architectural Design of an Internet system
11
15
Sample Web Services Design
11
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
11
17
Sample Deployment Diagram of an Internet System
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
11
19
Sample Sequence Diagram
11
20
Sample Design Class
11
21
Sample Java Class
Definition
11
22
Object-oriented Design Process
11
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
11
24
Standard Stereotypes Found in Design Models
11
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 system’s automation boundary, touched by users
User interface and windows classes
Data access – retrieves data from and sends data to database
11
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
11
27
Notation Used to Define a Design Class
11
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
11
29
Sample Class Diagram with Design Classes and Inheritance
11
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
11
31
Navigation Visibility
11
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
11
33
First Cut Class Diagram for RMO
11
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)
11
35
CRC Card Notation
11
36
CRC Card Set for Process new order
11
37
Updated Design Class Diagram
withVisibility and
Methods
11
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
11
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
11
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
11
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
11
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