Chapter 11 System Analysis & Design 2 (Dr. Mohamed Marie)

7/31/2019 Chapter 11 System Analysis & Design 2 (Dr. Mohamed Marie)

1/42

11Systems Analysis and Design in a

Changing World, Fifth Edition


2/42

11

Systems Analysis and Design in a Changing World, 5th Edition 2

Learning Objectives

Explain the purpose and objectives of object-orienteddesign

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/42

11


Overview

This chapter is thorough explanation of how to designsimple systems

Architechtural design is used to define the structureand configuration of the new system

Good object-oriented design is based on fundamentaldesign principles

Design classes are a fundamental element in

systems design

Class-Responsibility-Collaboration (CRC) cards areuseful for designing simple systems


4/42

11


Object-Oriented DesignThe Bridge

Between Analysis and Programming

Bridge between users requirements and new

systems programming

Object-oriented design is process by which detailedobject-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/42

11


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/42

11


Object-Oriented Three-Layer Program

Figure 11-1


7/42

11


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/42

11


DesignModels with

Their

RespectiveInput

Models

Figure 11-2


9/42

11


Object-Oriented Architectural Design

Desktop system

Enterprise-level system

Network or client/server system

Internet based system


10/42

11


Differences between network and Internetsystems

Figure 11-3


11/42

11


Component Diagrams andArchitectural Design

Component Diagram

Shows overall system architecture

API is the set of all public methods available in thecomponent

Ports and Sockets define the interface

Frameset notation to extend UML notation

Used to describe web components


12/42

11


Component Diagram Notation

Figure 11-4


13/42

11


Two-layer Architectural Design ofan Internet System

Figure 11-6


14/42

11


Three-layer Architectural Design ofan Internet system

Figure 11-7


15/42

11


Sample Web Services Design

Figure 11-8


16/42

11


Deployment Diagrams

Deployment diagram shows physical components of anew system

Node is a physical component

Artifact is an executable module

Artifacts are components after they have beencompiled into executables


17/42

11


Sample Deployment Diagramof an Internet System

Figure 11-11


18/42

11


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 betweenobjects 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/42

11


Sample Sequence Diagram

Figure 11-12

11


20/42

11


Sample Design Class

Figure 11-13

11


21/42

11


Sample JavaClass

Definition

Figure 11-14(a)

11


22/42

11


Object-oriented Design Process

Figure 11-15

11


23/42

11


Design Class Symbols

UML does not distinguish between design classnotation 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/42

11


Standard Stereotypes Found in Design Models

Figure 11-16

11


25/42

11


Standard Design Classes

Entity design identifier for problem domain class Persistent class exists after system is shut down

Control mediates between boundary and entityclasses, between the view layer and domain layer

Boundarydesigned to live on systems automationboundary, touched by users

User interface and windows classes

Data access retrieves data from and sends data todatabase

11


26/42

11


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 ormore different parameter lists

Class-level method method associated with class insteadof each object (static or shared method), denoted by anunderline

11


27/42

11


Notation Used to Define a Design Class

Figure 11-17

11


28/42

11


Design Class Definitions

Overloaded method a method with one name but

different parameter lists

Class-level method a method associated with theclass rather than an object

Class-level attribute an attribute that contains thesame value for all objects

Overridden method a method in a subclass thatoverrides the parents method

Abstract class a class that is never instantiated

Concrete class a normal class with objects

11


29/42

11


Sample Class Diagram with Design Classesand Inheritance

Figure 11-18

11


30/42

11


Developing the First-cutDesign Class Diagram

Elaborate the attributes

Visibility, Type cast, Initial values

Navigation Visibility

Ability to reference the methods of another object

11


31/42

11


Navigation Visibility

Figure 11-20

11


32/42

11


Navigation Visibility Guidelines

One-to-many with superior to subordinate. Thevisibility goes from the superior to the subordinate

Mandatory relationships for existence. Visibility goesfrom independent to dependent

Object needs information from another object. Visibilitygoes to object with the information

Navigational arrows may be bidirectional

11


33/42

11


First Cut Class Diagram for RMO

Figure 11-21

11


34/42

11


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/42

11


CRC Card Notation

Figure 11-22

11


36/42

11


CRC Card Set forProcess new order

Figure 11-23

11


37/42

11


Updated DesignClass Diagram

withVisibility and

Methods

Figure 11-24

11


38/42

11


Some Fundamental Design Principles

Encapsulation each object is self-contained unit thatincludes 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/42

11


Some Fundamental Design Principles

(continued)

Coupling qualitative measure of how closely classes ina design class diagram are linked

Number of navigation arrows in design class diagram ormessages in a sequence diagram

Loosely coupled system is easier to understand andmaintain

Cohesion qualitative measure of consistency offunctions within a single class

Separation of responsibility divide low cohesive class intoseveral highly cohesive classes

Highly cohesive system is easier to understand andmaintain and reuse is more likely


40/42

11


41/42

11


Summary

Object-oriented design is the bridge between userrequirements (in analysis models) and final system

(constructed in programming language)

Systems design is driven by use cases, design classdiagrams, and CRC Cards

Domain class diagrams are transformed into design

class diagram

11


42/42

11

Summary (continued)

Object-oriented design principles must be applied

Encapsulation data fields are placed in classes along withmethods 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

Indirectionan intermediate class is placed between twoclasses to decouple them but still link them

Separation navigation access classes have to otherclasses

Three-layer design is used because maintainable

Chapter 11 System Analysis & Design 2 (Dr. Mohamed Marie)

Documents

Transcript of Chapter 11 System Analysis & Design 2 (Dr. Mohamed Marie)