SW Design Principles and Techniques, Soo Dong Kim

Software Design
Principles and Techniques
Fall 2016
Soo Dong Kim, Ph.D.

Professor, Department of Computer Science
Software Engineering Laboratory
Soongsil University
Office 02-820-0909 Mobile 010-7392-2220 Lab. 02-824-0909
sdkim777@gmail.com
http://soft.ssu.ac.kr
1
Copyright Notice
All materials contained in this document are protected by copyright laws and
may not be reproduced, distributed, transmitted, displayed, published or
broadcast without the prior written permission of the author or in the case
of third party materials, the owner of that content. You may not alter or
remove any trademark, copyright or other notice from copies of the content.
Copyright 2016 by Soo Dong Kim, All Rights Reserved.
2016 Soo Dong Kim

Software Design Principles and Techniques
Contents
Unit
Title
Slide#
Nature of Software Design
Principles of Software Design
42
Designing Software Architecture
53
Designing User Interface
123
Designing Components
149
Designing Database
189
Design with Patterns
226
Design with Traceability
263
Concluding Remarks
281
2016 Soo Dong Kim

Unit 1.
Nature of Software Design
SW Design (1)
[SWEBOK 2014]
The process of defining the architecture, components,

interfaces, and other characteristics of a system or component
and the result of [that] process
[ISO/IEC/IEEE Standard 12207], Software Life Cycle Processes
Software design consists of two activities that fit between

software requirements analysis and software construction.
Software Architectural Design

Software Detailed Design
2016 Soo Dong Kim

SW Design (2)
Analysis
Comprehension and Representation

AS-IS vs. TO-BE
Design
Refinement of Analysis Model
Invention
Design-level Decisions
Implementation in Mind
Implementation
Transforming Design into Code

Conformance to Design Model
2016 Soo Dong Kim

System Modeling (1)

What is a model?
A model is an abstraction of reality.

Abstraction is a process of capturing key and essential features
while ignoring less important details.
Models in Daily Life
Map, Organization Chart, Home Pages, Model House for

Apartments, etc.
Models in System Development
User Interface, Flow Chart, ER Diagram, Gantt Chart, etc.
Modeling = Analysis + Preliminary Design

2016 Soo Dong Kim
System Modeling (2)

Purpose
To understand the target system clearly, and specify the

understanding precisely
The resulting model becomes the basis for detailed design and
implementation.
Benefits
To elicit requirements
To visualize the system
To specify the system precisely
To document the decisions made on the system
To provide templates for guiding implementation
2016 Soo Dong Kim

3Views of Systems (1)

Complexity and Uncertainty of Target System
Modeling 3 views of the system
Dynamic View
Functional View
2016 Soo Dong Kim

Target
System
9
3Views of Systems (2)

Functional View
Observes the functionality to be delivered.

Consider menu.
Structural View
Observes the data and information manipulated by the

functionality.
Consider objects and database.
Dynamic View
Observes the runtime behavior, i.e. sequence of executions.

Consider function calls and message passing.
2016 Soo Dong Kim

10
Design Artifacts
Analysis
Preliminary
Design (PIM)
Detailed
Design (PSM)
Implementation
2016 Soo Dong Kim
Software Design
System Modeling
Requirement
Definition
Architecture
Architecture Styles
Views and Perspectives
Non-Functional Requirements
User Interface
Conventional UI
UI for Embedded Systems
Components for Control Layer
Use Cases
Workflow
Algorithms, Parallelism
State Behavior, Realtime
Hardware Interface, HAL
Components for Model Layer
(Encapsulated) Objects
Database
Database Schema
11
Design Artifacts and UML

Diagram
Structural
Diagram
Class
Diagram
Component
Diagram
Composite
Structure Diag.
Profile
Diagram
Behavior
Diagram
Object
Diagram
Deployment
Diagram
Activity
Diagram
Package
Diagram
Use Case
Diagram
Interaction
Diagram
Sequence
Diagram
Interaction
Overview Diag.
Communication
Diagram
2016 Soo Dong Kim
State Machine
Diagram
Timing
Diagram
12
Software Quality
Definition
Degree of conformance to explicitly stated functional and

performance requirements, explicitly documented development
standards, and implicit characteristics that are expected of all
professionally developed software.
Three Emphases
Requirements are the foundation from which quality is

measured.
Lack of conformance to requirements is lack of quality.
Developers should follow the specified standards for

development.
Software must conform to its implicit requirements as well.
2016 Soo Dong Kim

13
Organization of ISO 9126 (ISO 25010:2011)

Part 1
Quality Model
Part 2
External Metrics
Part 3
Internal Metrics
Part 4
Quality In Use Metrics
2016 Soo Dong Kim

14
Types of Quality in ISO 9126 (1)

Process Quality
Quality of Life-cycle Process

Process quality contributes to improving product quality.
Product Quality
Can be evaluated by measuring internal attributes or measuring

external attributes.
Internal quality
External quality
is evaluated by the static measure of intermediate products.

View at Technical Level
is evaluated by measuring the behavior of the code when executed.
View of User/Management
Product quality contributes to improving quality in use.
2016 Soo Dong Kim

15

Quality In Use
Users view of the quality of an environment containing

software, and is measured from the results of using the
software in the environment.
Rather than properties of the software itself.
Users environment may be different from development

environment.
2016 Soo Dong Kim

16

Process
Software Product
Influences
Influences
Internal
Quality
Attributes
Process
Quality
Influences
External
Quality
Attributes
Depends on
Depends on
Effect of Software
Product
Quality
in Use
Attributes
Depends on
Contexts
of Use
Process
Measures
2016 Soo Dong Kim

Internal
Measures
External
Measures
Quality in Use
Measures
17
Quality Model of ISO 9126

Level 1.
Characteristic
Level 2.
Sub-characteristic
Level 3.
Metrics
Formula
2016 Soo Dong Kim

18
Quality Model of ISO 9126

Quality Model for External and Internal Quality
External &
Internal Quality
Functionality
Reliability
Usability
Efficiency
Maintainability
Portability
Suitability
Accuracy
Interoperability
Security
Functionality
Compliance
Maturity
Fault Tolerance
Recoverability
Understandability
Time Behavior
Analysability
Changeability
Stability
Testability
Maintainability
Compliance
Adaptability
Installability
Co-Existence
Replaceability
Portability
Compliance
Reliability
Compliance
2016 Soo Dong Kim

Learnability
Operability
Attractiveness
Usability
Compliance
Resource
Utilization
Efficiency
Compliance
19
Six Characteristics
1. Functionality
Capability of software product to provide functions which meet

stated and implied needs
2. Reliability
Capability of software product to maintain a specified level of

performance
3. Usability
Capability of software product to be understood, learned, used

and attractive to user
2016 Soo Dong Kim

20
Six Characteristics
4. Efficiency
Capability of software product to provide appropriate

performance, relative to the amount of resources used
5. Maintainability
Capability of software product to be modified
6. Portability
Capability of software product to be transferred from one

environment to another
2016 Soo Dong Kim

21
Sub-characteristics of Functionality
Suitability
Capability of the software product to provide an appropriate set

of functions for specified tasks and user objectives
Accuracy
Capability of the software product to provide the right or

agreed results or effects with the needed degree of precision
Interoperability
Capability of the software product to interact with one or more

specified systems
2016 Soo Dong Kim

22
Sub-characteristics of Functionality
Security
Capability of the software product to protect information and

data so that unauthorised persons or systems cannot read or
modify them and authorised persons or systems are not denied
access to them
Functionality Compliance
Capability of the software product to adhere to standards,

conventions or regulations in laws and similar prescriptions
relating to functionality
2016 Soo Dong Kim

23
Sub-characteristics of Reliability
Maturity
Capability of software product to avoid failure as a result of

faults in the software
Fault Tolerance
Capability of software product to maintain a specified level of

performance in cases of software faults or infringement of its
specified interface
2016 Soo Dong Kim

24
Sub-characteristics of Reliability
Recoverability
Capability of software product to re-establish a specified level

of level of performance and recover the data directly affected in
the case of a failure
Reliability Compliance
Capability of software product to adhere to standards,

conventions or regulations relating to reliability
2016 Soo Dong Kim

25
Sub-characteristics of Usability
Understandability
Capability of the software product to enable the user to

understand whether the software is suitable, and how it can be
used for particular tasks and conditions of use
Learnability
Capability of the software product to enable the user to learn

its application
Operability
Capability of the software product to enable the user to operate

and control it
2016 Soo Dong Kim

26
Sub-characteristics of Usability
Attractiveness
Capability of the software product to be attractive to the user
Usability Compliance
Capability of the software product to adhere to standards,

conventions, style guides or regulations relating to usability
2016 Soo Dong Kim

27
Sub-characteristics of Efficiency
Time Behavior
Capability of the software product to provide appropriate

response and processing times and throughput rates when
performing its function, under stated conditions
Resource Utilization
Capability of the software product to use appropriate amounts

and types of resources when the software performs its function
under stated conditions
Efficiency Compliance
Capability of the software product to adhere to standards or

conventions relating to efficiency
2016 Soo Dong Kim

28
Sub-characteristics of Maintainability
Analyzability
Capability of the software product to be diagnosed for

deficiencies or causes of failures in the software, or for the
parts to be modified to be identified
Changeability
Capability of the software product to enable a specified

modification to be implemented
Stability
Capability of the software product to avoid unexpected effects

from modifications of the software
2016 Soo Dong Kim

29
Sub-characteristics of Maintainability
Testability
Capability of the software product to enable modified software

to be validated
Maintainability Compliance

conventions relating to maintainability
2016 Soo Dong Kim

30
Sub-characteristics of Portability
Adaptability
Capability of the software product to be adapted for different

specified environments without applying actions or means
other than those provided for this purpose for the software
considered
Installability
Capability of the software product to be installed in a specified

environment
Co-existence
Capability of the software product to co-exist with other

independent software in a common environment sharing
common resources
2016 Soo Dong Kim

31
Sub-characteristics of Portability
Replaceability
Capability of the software product to be used in place of

another specified software product for the same purpose in the
same environment
Portable Compliance

conventions relating to portability
2016 Soo Dong Kim

32
Quality In Use
Quality Model for Quality in Use
Quality In Use
Effectiveness
2016 Soo Dong Kim

Productivity
Safety
Satisfaction
33
Four Characteristics
1. Effectiveness
Capability of the software product to enable users to achieve

specified goals with accuracy and completeness in a specified
context of use
2. Productivity
Capability of the software product to enable users to expend

appropriate amounts of resources in relation to the
effectiveness achieved in a specified context of use
2016 Soo Dong Kim

34
Four Characteristics
3. Safety
Capability of the software product to achieve acceptable levels

of risk of harm to people, business, software, property or the
environment in a specified context of use
4. Satisfaction
capability of the software product to satisfy users in a specified

context of use
2016 Soo Dong Kim

35
Software Reviews
Concept
Reviews are a Filter for software engineering process.

Applied at various points during software development and
serve to uncover errors.
To purify the work products that occur at analysis, design and
coding.
Types of review
Informal Review
Formal Technical Review (FTR)
Walkthrough
2016 Soo Dong Kim

36
Cost Impact of Software Defects

Terms
Defect (Fault)
Quality problem that is discovered after release
Error
Quality problem that is discovered by engineers before release
Objective of Review
To find errors during the process that become defects after

release of the software.
Benefit: Early Discovery of Errors
Industry Studies
Design activities introduce 50-65% of all errors.

Formal review techniques have been shown to be up to 75%
effective in uncovering design errors.
2016 Soo Dong Kim

37
Defect Amplification Model

Errors may be inadvertently generated.
Illustrates the generation and detection of errors during each
of developing software.
Analysis, Preliminary Design, Detailed Design, Coding
Review may fail to uncover newly generated errors and
errors from previous steps, resulting in some errors that are

passed through.
Defects
Errors from
previous step
Errors passed through

Amplified Errors 1:x
Newly generated errors
2016 Soo Dong Kim

Detection
Percent
efficiency
for error
detection
A Development Step
Errors passed
to next step
38

No Reviews applied
Preliminary design
0
0
10
0%
10 6
Detail design
4 X 1.5
x = 1.5
0%
25
Code/unit test
37
10
27 X 3
x =3
20%
94
25
94
Integration test
To Integration
47
0
0
50%
Validation test
0
0
50%
24
System test
0
0
50%
12
Latent errors
2016 Soo Dong Kim
39

Reviews applied
Preliminary design
0
0
10
70%
3 2
24
Integration test
12
0
0
50%
Detail design
2
1 X1.5 50% 15 5 Code/unit test
5
25
24
10
X
3
60%
10
25
To Integration
Validation test
0
0
50%
System test
0
0
50%
3
Latent errors
2016 Soo Dong Kim

40
Defects on SRS
Typical Problems in SRS
Incompleteness
Inconsistency
Redundant
Ambiguity
Irrelevant
Software Requirement
Specification (SRS)
Incompleteness
Inconsistency
Real
Requirement
X
Y
Z
Q
Redundant
Ambiguity
2016 Soo Dong Kim

Irrelevant
41
Unit 2.
42

P1. Abstraction
P2. Refinement
P3. Separation of Concerns
P4. Modularity
P5. Functional Independence
P6. Information Hiding
2016 Soo Dong Kim

43
Principle 1. Abstraction
Many levels of abstraction
At the highest level of abstraction, a solution is stated in broad

terms using the language of the problem environment.
At lower levels of abstraction, a more detailed description of
the solution is provided.
Procedural Abstraction
A sequence of instructions that have a specific and limited

function.
Example) open for a door
Data Abstraction
A named collection of data that describes a data object

Example) Door
It would encompass a set of attributes that describe the door.
2016 Soo Dong Kim

44
Principle 2. Refinement
Refinement
A program is developed by successively refining levels of

procedural detail. A hierarchy is developed by decomposing a
macroscopic statement of function in a stepwise fashion until
programming language statements are reached.
A Process of Elaboration
Abstraction and refinement are complementary concepts.
2016 Soo Dong Kim

45
Principle 3. Separation of Concerns (1)

Separation of Concerns (SoC)
Any complex problem can be more easily handled if it is

subdivided into pieces that can each be solved and/or
optimized independently.
A concern is a feature or behavior that is specified as part of the
requirements model for the software.
For two problems, p1 and p2,
their complexities are C(p1) and C(p2).
If C(p1) > C(p2), the effort required to solve p1 is greater than

the effort required to solve p2.
It follows that;
C(p1 + p2) > [C(p1) + C(p2)]
2016 Soo Dong Kim

46
Principle 3. Separation of Concerns (2)

Separation of Concern A and Concern B
Examples)
Separation of Functionality
Device and Conquer, Composition
Separation of Layers
3 Layers of MVC Architecture
Separation of Interface and Implementation

Separation of Device Driver and Physical Device
2016 Soo Dong Kim

47
Principle 4. Modularity
Modularity
The most common manifestation of separation of concerns.

Software is divided into separately named and addressable
components, sometimes called modules, that are integrated to
satisfy problem requirements.
2016 Soo Dong Kim

48
Principle 5. Functional Independence (1)

Functional Independence
is a direct outgrowth of separation of concerns, modularity, and

the concepts of abstraction and information hiding.
Functional independence
is achieved by developing modules

with singleminded function and an aversion to excessive
interaction with other modules.
Independence
is assessed using two qualitative criteria
Cohesion is an indication of the relative functional strength of a

module.
Coupling is an indication of the relative interdependence among
modules.
A cohesive module performs a single task, requiring little interaction with

other components in other parts of a program.
2016 Soo Dong Kim

49

Coupling between Modules A and B
Form
Features
Data Coupling
A & B communicate
by simple data only.
High (Use parameter passing & only

pass necessary info.)
Stamp Coupling
A & B use
a common type of data.
Okay (Desirable to group them in a

data abstraction)
Control Coupling
A transfers control to B
by procedural call.
Necessary
Common Environment Coupling
A passes a flag to B
to tell it how to behave.
Content Coupling
A changes Bs data, or passes

control to the middle of B.
2016 Soo Dong Kim

Desirability
Undesirable
To Avoid
50

Cohesion if a Module A
Form
Features
Desirability
Data Cohesion
All part of a well defined data abstraction
Very High
Functional Cohesion
All part of a single problem solving task
High
Sequential Cohesion
Outputs of one part from input to the next
Okay
Communicational Cohesion
Operations that use the same input or

output data
Moderate
Procedural Cohesion
A set of operations that must be executed

in a particular order.
Low
Temporal Cohesion
Elements must be active

around the same time.
Low
Logical Cohesion
Elements perform logically

similar operations.
To Avoid
Coincidental Cohesion
Elements have no conceptual link

other than repeated code
To Avoid
2016 Soo Dong Kim

51
Principle 6. Information Hiding

The principle of information hiding suggests that modules be
characterized by design decisions that (each) hides from all

others.
Information Hiding in Object-Oriented
Paradigm
private visibility vs. public visibility
2016 Soo Dong Kim

52
Unit 3.
Designing Software Architecture
53
Collapse of Bridges (1)

35W Bridge, Mississippi River, USA
Built in 1967, Collapsed in 2004

Poor Architecture Design
2016 Soo Dong Kim

54
Collapse of Bridges (2)

Bay Bridge
Built in 1936, Collapsed in 1989

6.9 Earthquake
2016 Soo Dong Kim

55
Golden Gate Bridge

Construction
January 5, 1933: Construction begins

May 27, 1937: Bridge opens to pedestrians
May 28, 1937: Bridge open to automobiles
Architecture
Suspension, Truss Arch & Truss Causeways
Total length: 1.7 miles

746 feet (227 m)
above the water
2016 Soo Dong Kim

56
World Trade Center

Build in 1973, Collapsed in 2001 (9.11)
Impact of the Architecture
Due to Tube-Frame Structural System
2016 Soo Dong Kim

57
Software Architecture
Definitions
Architecture is defined by the recommended practice as the

fundamental organization of a system, embodied in its
components, their relationships to each other and the
environment, and the principles governing its design and
evolution. [ISO/IEC 42010]
Structure or structures of the system, which comprise software elements, the externally
visible qualities of those elements, and the relationships among them [Bass et el]
Elements + Form + Rationale [Perry and Wolf]
Design that involves the description of elements from which systems are built,
interactions among those elements, patterns that guide their composition, and constraints
on these patterns [Shaw and Garlan]
Software architecture deals with the design and implementation of the high-level
structure of software. Architecture deals with abstraction, decomposition, composition,
style, and aesthetics [Kruchten]
2016 Soo Dong Kim

58
Requirements and Architecture

Specification (SRS)
Functional
Requirement
OOAD
Non-Functional
Requirement
SW Architecture
Architecture is effective in realizing non-functional
requirements.
Reusing architectural knowledge for productivity and quality
2016 Soo Dong Kim
59
Architecture Styles
60
Styles for Bridges

Beam Style
Cantilever Style
2016 Soo Dong Kim

Arch Style
Suspension Style
61
Styles for Software Systems (2)

A style consists of:
A set of component types (e.g. process, procedure) that

perform some function at runtime
A set of connectors (e.g. data streams, sockets) that mediate
communication among components
A topological layout of the components showing their runtime
relationships
A set of invariants (i.e. constraints)
e.g. direction of data-flow, dynamism, concurrency
2016 Soo Dong Kim

62
Styles in [Rozanski 2005]
Pipes and Filters
Client/Server
Tiered Computing
Peer-to-Peer
Layered Implementation
Publisher/Subscriber
Asynchronous Data Replication
Distribution Tree
Integration Hub
Tuple Space
2016 Soo Dong Kim

63
Styles in[Taylor 2009]

Traditional Language-
Influenced Styles
Main program and
subroutines
Object-oriented
Layered
Virtual machines
Client-server
Dataflow Styles
Batch-sequential
Pipe-and-filter
Shared Memory
Interpreter
Interpreter
Mobile code
Implicit Invocation
Publish-subscribe
Event-based
Peer-to-Peer
Complex Styles
C2 (Components and
Connectors)
Distributed Objects
Blackboard
Rule-based
2016 Soo Dong Kim
64
Balanced MVC
When an application consists of two types of functionality;
one functionality requiring only a local computation, and the

other requiring a remote computation which is resource
intensive or demands a shared information/database.
When utilizing both the computing power of a mobile device
and that of a more powerful server, as an effort to increase

the overall performance through parallelism.
2016 Soo Dong Kim

65
Structure (1)
Partitioning Functionality & Dataset into two parties.
Mobile Device
Server
View Layer
(C.View)
Control Layer
(C.Control)
Internet
Control Layer
(S.Control)
Model Layer
(C.Model)
Model Layer
(S.Model)
Local
DB
Master
DB
Mobile Device
2016 Soo Dong Kim

Server
66
Structure (2)
Mobile device may maintain a local cache DB for benefits,
but with a synchronization effort.

Control and model layers are deployed and executed on both
mobile device and server.

The server side typically does not have a view layer.
2016 Soo Dong Kim

67
Structure (3)
C.Control vs. S.Control
C.Control carries out the business process logics for a userspecific system.
S.Control implements common business logics that can be
reused by multiple users.
C.Model vs. S.Model
C.Model manages data for a specific user.
Stored on the secondary database or cache
S.Model manages persistent data for all the users.
Stored on the database in a secondary storage
2016 Soo Dong Kim

68
Structure (4)
Mobile Device
C.View
Server System
Internet
C.View
C.Control
C.View
C.Control
C.View
C.Control
S.Control
Internet
Internet
S.Control
Internet
S.Model
Type #1
S.Model
Type #2
S.Model
Type #3
S.Model
Type #4
S.Model
Type #5
C.Model
C.View
C.Control
Internet
S.Control
C.Model
2016 Soo Dong Kim
69
Structure (5)
Type 1
Only S.Control and S.Model exist.
Realizing thin client side for resolving resource constraints
Always needs network capability
Type 2
Only C.Control and S.Model exist.
Applicable situations
Low interaction between C.Control and S.Model
Type 3
Both C.Control and S.Control, and also S.Model exist.
Intensive interaction between C.View and C.Control, and S.Control and S.Model
Low interaction between C.Control and S.Control
A high parallelism on C.Control and S.Control
2016 Soo Dong Kim

70
Structure (6)
Type 4
C.Control, and also C.Model and S.Model exist.

Intensive interaction among C.View, C.Control and C.Model

Low interaction between C.Control and S.Model
High parallelism on C.Model and S.Model
Type 5
Both C.Control and S.Control, and also C.Model and S.Model

exist.
Integrated version of Pattern 3 and 4
Applicable Situation
High coupling/dependency between each pair of Control and Model.
2016 Soo Dong Kim

71
Structure (7)
Type
Computation
on Client Side
Network Overhead
Parallelism
Low
Low
Low
Middle
High
Low
Middle
Low
High
High
High
Middle
High
Low
High
2016 Soo Dong Kim

72
Interaction (1)
Diverse Interaction Paths
Client System
on Mobile Device
Server System
C.View
S.View
User
C.Control
1
S.Control
C.Model
System
Administrator
S.Model
4
C.DB
2016 Soo Dong Kim

S.DB
73
Interaction (2)
Path 1 : between C.Control and C.Model
Not requiring any communications with server system

Applicable to functionality which is invoked on the client system
without relying on the server system.
Path 2 : between C.Control
and S.Control.
Applicable to the case that the functionality of C.Control can be

fulfilled with the support of the S.Control.
C.Control provides client-specific functionality and S.Control
provides common and reusable functionality in service-based
systems.
Path 3 : between C.Control and S.Model
Without going through S.Control.

Applicable to the case that the C.Control needs to update the
objects in S.Model efficiently.
2016 Soo Dong Kim

74
Interaction (3)
Path 4: between C.Model and S.Model
To synchronize the states of two corresponding objects when

the client system maintains copies of the entity objects. This is
useful to maintain the state consistency.
Path 5: between S.Control and S.Model
To the typical invocation of entity objects on the server side.
2016 Soo Dong Kim

75
Interaction (4)
C.Control manages its business process by invoking other components.
:C.View
:C.Control
:C.Model
:S.Control
:S.Model
Users
To maximize performance, it allows

direction interaction between C.Control & S.Model.
A direction interaction between C.Model & S.Model

is used for object synchronization.
2016 Soo Dong Kim

76
Example
Mobile Mate Service
View Layer
Member
Form
ProfileForm
GroupForm
Invitation
Form
LoginForm
HelpForm
TextMessage
Form
Client Control Layer
cMemberCtrl
Functionality to manage client-specific data

is located on mobile device.
Functionality to manage interactions with users
is located on mobile devices.
Functionality to manage collaboration
among multiple users is located on server system.
Server Control Layer
cGroupCtrl
cMiscellCtrl
sGroupCtrl
sMiscellCtrl
Profile
ColleagueList
MemberSub
sMemberCtrl
Profile
Colleague
2016 Soo Dong Kim

ColleagueList
Group
Member
Colleague
Group
Invitation
TextMessage
77
Pros and Cons

Pros
Complex applications can be hosted.
Complex functionalities are deployed and run on server system.
Problems with resource limitation are resolved.
Cons
Complex and precise engineering is required.
Especially, architecture design becomes the key issue.
Network overhead
May need to synchronize replicated objects.
2016 Soo Dong Kim

78
Design Issues (1)

Criteria
To minimize the amount of dataset flown over the network

To minimize the number of messages
To maximize coupling between functional unit (control layer)
and dataset (model layer)
To minimize a cost of synchronizing states of objects on server
side and states of their clone on client side
To maximize parallelism between two nodes
2016 Soo Dong Kim

79
Design Issues (2)

Step 1. To define the most appropriate
type for the target
application
no
Classes in
Client Side?
Calculate
Depends(V, C)
yes
Calculate
Depends(C, M)
Between C.View & C.Control
Between C.Control & S.Model
High?
High?
no
Apply Pattern 1
no
yes
Calculate
Depends(C, M)
yes
Apply Pattern 4
Apply Pattern 5
Between C.Control & S.Model

High?
no
Apply Pattern 2
2016 Soo Dong Kim
Depends(A, B)
yes
Apply Pattern 3
Estimated degree of
dependency between A and B
Measured by the intensity of
message exchanges in the use
case descriptions.
80
Design Issues (3)

Step 2. Realize the pattern by deriving components
Classes in C.View
Classes in C.Model and S.Model
From interactions between actor and client system specified in use case
descriptions
Classes in the object models
Classes in C.Control and S.Control
From use case descriptions and object models

Start with checking functional groups in the use case description.
Refine the functional groups.
Derive one control class from one functional group.
Step 3. Define operations in each component
For classes in C.Control and S.Control
From interactions between actor and client system, and between client
system and service system in the use case description
2016 Soo Dong Kim

81
MVC for Car Rental System (1)

View Layer
Control Layer
Customer
Manager
Inventory
Manager
Reservation
Manager
Rental
Manager
Report
Generator
Model Layer
0..*
Reservation
0..*
0..*
1..*
AutoType
1
Customer
1
0..*
2016 Soo Dong Kim

Rental
AutoItem
82
Architecture Views &Viewpoints
83
ArchitecturalView
Definition
A representation of one or more structural aspects of an

architecture
Functional View, Information View, etc.
Analogy of Architectural View
Blueprints of Building Design
Strategy
A complex system is much more effectively described by using a

set of interrelated views, which collectively illustrate its
functional features and quality properties and demonstrate that
it meets its goals.
2016 Soo Dong Kim

84
FunctionalView
Describes systems functional elements, their
responsibilities, interfaces, and primary interactions.

Cornerstone of the Architecture
First part of AD that stakeholders try to read
Derives the shape of other views.
2016 Soo Dong Kim

85
InformationView
Describes the way that the architecture stores, manipulates,
manages, and distributes information.

High-level view of static data structure
Considers
Content, structure, ownership, latency, references, and data

migration
2016 Soo Dong Kim

86
ConcurrencyView
Describes the concurrency structure of the system.
Maps functional elements to concurrency units.
To identify the parts of the system that can execute

concurrently, and how this is coordinated and controlled.
Consider
Process, Thread structures, and Inter-Process Communication

(IPC)
2016 Soo Dong Kim

87
DeploymentView
Describes the environment into which the system will be
deployed.
Consider
Hardware Environment
Technical environment
Mapping of software elements to the runtime environment that
will execute them
2016 Soo Dong Kim

88
OperationalView
Describes how the system will be operated, administered,
and supported when it is running its production

environment.
Identifies system-wide strategy for addressing operations
concerns and their solutions.
2016 Soo Dong Kim

89
ArchitecturalView Groups
Deployment
View
defines
operation of
Operational
View
defines
runtime environment for
Context
View
defines scope,
context,
and interfaces for
Functional
View
2016 Soo Dong Kim

Software
Design
Information
View
defines
implementation
constraints for
Development
View
Concurrency
View
90
ArchitecturalViewpoint
Definition
A collection of patterns, templates and conventions for

constructing one type of view.
Provides a framework for capturing reusable architectural
knowledge.
Benefits
Separations of Concerns
Communication with Stakeholder Groups
Management of Complexity
Improved developer focus
2016 Soo Dong Kim

91
ArchitecturalView Catalog
Deployment
View
defines
operation of
Operational
View
defines
runtime environment for
Context
View
defines scope,
context,
and interfaces for
Functional
View
2016 Soo Dong Kim

Software
Design
Information
View
defines
implementation
constraints for
Development View
Concurrency View
92
Overview of FunctionalViewpoint
Functional Viewpoint
Definition
Describes the systems functional element, their responsibilities,

interfaces, and primary interactions
Concerns
Functional capabilities, external interfaces, internal structure, and

design philosophy
Models
Functional structure model
Problems and
Pitfalls
Poorly defined interface

Poorly understood responsibilities
Infrastructure modeled as functional elements
Overloaded view
Diagrams without element definitions
Difficulty in reconcile
Stakeholders
All stakeholders
Applicability
All systems
2016 Soo Dong Kim

93
Overview (2)
To define architectural elements that deliver the systems
functionality
Key functional element, their responsibilities, interfaces, and

primary interactions
The cornerstone of most ADs
The first part of the description that stakeholders try to read

Easiest view for stakeholders to read
To drive the shape of other system structures
Such as the information structure, concurrency structure, and

deployment structure etc.
2016 Soo Dong Kim

94
Concern 1. Functional Capability

To define;
What the system is required to do

What it is not required to do explicitly or implicitly
On projects
Being given an good-quality requirements specification at the

start of architecture definition can focus on showing how
architectural elements work together to provide functionality.
2016 Soo Dong Kim

95
Concern 2. External Interfaces

Data Flow between the system and others
Inward Data
Resulting in an internal change of system state
Outward Data
As a result of internal changes of system state
Control Flow between the system and others
Inbound Control Flow
A request by an external system to others to perform a task
Outbound Control Flow
A request by one system to another to perform a task
To consider both the interface syntax and semantics
The structure of the data or request

Meaning or effect
2016 Soo Dong Kim

96
Concern 3. Internal Structure

What internal elements do
How they map onto the requirements
How they interact with each other

Internal structure has a impact on
the system properties
such as;
Availability, Resilience, Scalability, Security
e.g., a complex system is generally harder to secure than a simple one
2016 Soo Dong Kim

97
Concern 4. Design Philosophy (1)

Consider different stakeholders views
What the system does and the interfaces it presents to user and
to other system
How well the architecture adheres to sound principles of design
Good architecture to build, operate, and enhance easily
In the technical stakeholders perspective
Faster, cheaper, and easier architecture to get a well-designed

system into production
In the technical acquirers perspective
2016 Soo Dong Kim

98
Concern 4. Design Philosophy (2)

Design Quality Underpinning
Design
Quality
Design Philosophy
Description
Significance
Each internal element responsible for a

distinct part of the systems operation?
Common processing performance
High separation
(+)to build, support, and enhance easier
(-)Performance and scalability
Cohesion
the functions provided by an element

strongly related to each other
High cohesions sensible and tends to result in

simpler, less error-prone design.
Coupling
How strong are the element interrelationship?
Loosely coupled system

(+)easier to build, support, and enhance
(-)poor scalability
Volume of
Interactions
What proportion of processing steps involve

interactions between elements as opposed
to within an element?
Communicating between certain types of

elements
(+)magnitude expensive, and less reliable
Functional
Flexibility
How amenable is the system to supporting

functional changes?
System designed changed easily

(-) harder to build
(+) Adaptable
Overall
Coherence
Does the architecture look right when

decomposed into elements?
Not look like

- Underlying problems and hard to understand to
stakeholders.
Specification
of concerns
2016 Soo Dong Kim

99
Concern 5. Stakeholder Concerns

Stakeholder Class
Concerns
Acquirers
Primarily functional capabilities and external interfaces
Assessors
All concerns
Communicators
Developers
System
administrators
All concerns, to some extent

Primarily design philosophy and internal structure, but also
functional capabilities and external interfaces
Primarily design philosophy and internal structure
Testers
Primarily design philosophy and internal structure, but also

functional capabilities and external interfaces
Users
Primarily functional capabilities and external interfaces
2016 Soo Dong Kim

100
Systems Elements
Functional Elements
A well defined part of the runtime system that has particular

responsibilities and expose defined interfaces
Interfaces
A well defined mechanism that the functions of an element can be

accessed by other elements
Defined by inputs, outputs, and semantics of each operation
Connectors
Pieces of architecture that link the elements together to allow them

to interact
Software code module, Application package, Data store.
To define the interaction between elements that use it
External entities
Other system such as software programs, hardware devices
2016 Soo Dong Kim

101
Functional Structure Model (1)

UML Component Diagram
To show a systems elements, interfaces, and inter-element

connections
Example of a Functional Structure in UML
Variable
Reporting
Variable Capture
Component interface
and use by another
component
{type=XML RPC,
protocal=HTTP,
number = 10 concurrent}
external
Temperature Monitor
Limit Condition
Tagged values used

to make interface
characteristics clear
Alarm Initiator
Stereotype used
to indicate an
external entity
UML component
represents system
element
2016 Soo Dong Kim

102
Functional Structure Model (2)
Example of UML Component Diagram

external
Customer
Web Browser
{type=HTML user interface,
protocol=HTTP,
number=1000 concurrent}
external
Customer Care
Interface
{number=80
concurrent}
external
Customer Admin
Web Browser
Customer Web
Interface
{type=HTML user interface,

protocol=HTTP,
number=15 concurrent}
WebShop
Customer
Management
Interface
Manage
Customer
Customer
Information
System
Employee Web
Interface
Query
Customer
Place Order
Order
Processor
Receive Message
{type=API callback}
Query
Catalog
Product
Catalog
{type=RPC,
protocol=LU6.2}
{type=API call}
Publish
Message
infrastructure
Message Bus
Manage
Catalog
checklevel
Stock
Inventory
Order message
propagated via PUR1
EAI message end point
to order fulfillment.
Receive
Message
external
Order
Fulfillment
2016 Soo Dong Kim
103
Steps in Applying FunctionalViewpoint

Identify the Elements
Walk through Common

Scenarios
Assign Responsibilities to
the Elements
Analyze the Interactions
Design the Interfaces
Analyze for Flexibility
Check the Functional

Traceability
2016 Soo Dong Kim

104
Architecture Perspectives
105
Architectural Perspective (1)

Definition
A collection of activities, tactics, and guidelines that are used to

ensure that a system exhibits a particular set of related quality
properties that require consideration across a number of
systems architectural views
Orthogonal to Viewpoints
Issues addressed by architectural perspectives are often
referred to as Non-Functional Requirement (NFR).
2016 Soo Dong Kim

106
Architectural Perspective (2)

Specification Scheme
Item
Explanation
Applicability
To explain which of the views are most likely to be affected by

applying the perspective
Concern
To define the quality properties that the perspective addresses
Activities
Steps for applying the perspective to the views

- Identifying the important quality properties
- Analyzing the views against the properties
- Making architectural decisions that modify and improve the views
Architectural Tactics
To identify and describe the most important tactics, which are

established and proven approaches architects can use to help
achieve a particular quality property
Problems and Pitfalls
To explain the most common things that can go wrong and gives
guidance on how to recognize and avoid them
Checklists
A list of questions to help architects make sure to address the most

important concerns
Further Reading
To provide a number of pointers to further information
2016 Soo Dong Kim

107
Applying Perspectives toViews (1)

To apply each relevant perspective to some or all of the
views in order to address that perspectives system-wide

quality property concerns
Security Perspective
Accessibility Perspective
Performance Perspective
Location Perspective
Availability Perspective
Regulation Perspective
etc.
Context View
Functional View
Development View
Information View
Deployment View
Concurrency View
Operational View
2016 Soo Dong Kim

108
Overview of Security Perspective

Desired Quality
Applicability
The ability of the system to reliably control, monitor, and audit who can perform
what actions on these resources and the ability to detect and recover from
failures in security mechanisms
Any systems with publicly accessible interfaces, with multiple users where the
identify of the user is significant, or where access to operations or information
needs to be controlled
Concerns
Policies, threats, mechanisms, accountability, availability, detection and recovery
Activities
Identify Sensitive Resources Define Security Policy Identify Threats to

System Design Security Implementation Assess Security Risks
Architectural
Tactics
Apply recognized security principles, authenticate the principals,

authorize access, ensure information secrecy, ensure information integrity,
ensure accountability, protect availability, integrate security technologies,
provide security administration, use third-party security infrastructure
Problems and
Pitfalls
complex security policies, unproven security technologies,

system not designed for failure, lack of administration facilities,
technology-driven approach, failure to consider time sources,
overreliance on technology, no clear requirements or models,
security as an afterthought, security embedded in the application code,
piecemeal security, ad hoc security technology
2016 Soo Dong Kim

109
Applicability toViews
View
Functional
Applicability
To allow to see which of the systems functional elements need to be
protected
The functional structure of the system may be impacted by the need to
implement security policies.
Information
To help you see what needs to be protected, i.e. sensitive data in the
system
To be modified as a result of security design (e.g. partitioning information
by sensitivity)
Concurrency
To indicate the needs to isolate different pieces of the system into

different runtime elements, which will affect the systems concurrency
structure
Development To identify guidelines or constraints that the software developers will need
to be aware of in order to ensure the security policy is enforced
Deployment
The security design may have a major impact on this view.

(e.g. security-oriented hardware or software)
Operational
How the system is operated once it is in production will have a major

affect on the security.
2016 Soo Dong Kim

110
Concerns (1)
Policies
To define the systems security needs
To define information access policy in terms of;
To define controls and guarantees that the system requires for its resources
The different types of principals the system contains
For each type of information, what sort of access each principal group
requires
To define information integrity constraints
Threats
To allow you to identify security enforcement mechanisms that

can be counter the threats
Example
password cracking, network attacks, denial-of-service attacks, socialengineering attacks
2016 Soo Dong Kim

111
Concerns (2)
Security Mechanisms
A set of technologies, configuration setting, and procedures required
to enforce the rules established by the security policy
To select the right set of technologies from the wide array available
and to apply them appropriately for the system
Accountability
Availability
A means of ensuring that every action can be unambiguously traced

back to the principal who performed it
To become more important as systems routinely connect to public
networks like the Internet
Detection and Recovery
The important security concern in the ability of the system to detect

security breaches and recover from them.
2016 Soo Dong Kim

112
Micro Process
Identify Sensitive
Resources
Define Security Policy
Identify Threats to
System
Design Security
Implementation
Assess Security Risks
Not Acceptable
Acceptable
2016 Soo Dong Kim

113
Guidelines for Identify Sensitive Resources

Decide what the sensitive resources in the system are.
By using the Functional and Information views as primary

inputs, along with any security requirements information
available
Or by using organizational security policies and relevant
external regulations, as well as the opinions of interested
stakeholders
Typically, functional operations and data items are sensitive
resources.
For each type of sensitive resource, define;
The reasons the resource is sensitive

Who should be considered as its owner
Type of access controls required for the resource
2016 Soo Dong Kim

114
Guidelines for Identify Sensitive Resources

Example of Sensitive Resource Identification
Resource
Sensitivity
Owner
Access Control
Customer account
records
Personal information of value

for identify theft or invasion of
privacy
Customer Care
Group
No direct data access
Descriptive
product catalog
entries
Defines what is for sale and its

description; if changed
maliciously, could harm the
business
Stock
Management
Group
Pricing product
catalog entries
Defines pricing for catalog

items; if maliciously or
accidentally modified, could
harm business or allow fraud
Pricing Team in
Stock
Management
Group
Business
operations on
customer account
records
Needs to be controlled to
protect data access and integrity
Customer Care
Group
Access to individual
record or all records by
authenticated principal
Descriptive
catalog operations
Needs to be controlled to
protect data access and integrity
Stock
Management
Group
Access to catalog
modification operations
by authenticated principal
2016 Soo Dong Kim

115
Guidelines for Define the Security Policy

Identify the principal classes.
To make defining the security policy more manageable, start by

grouping principals into classes you can treat as groups for
security policy purposes.
Partitions the principals into sets based on the types of access
they require to different types of sensitive resources.
Identify the resource classes.
Partition the systems sensitive resource types into groups that

you can treat together for access control purposes.
Identify the access control sets.
For each resource class, define the operations that can be

performed on members of that class and the principal classes
that should be allowed to access each operation on the class.
2016 Soo Dong Kim

116
Guidelines for Define the Security Policy

Identify the sensitive operations.
Consider any system-level operations that are independent of

the systems managed resources (s.a. administrative
operations).
Define which principal classes should be allowed to access
these operations.
Identify the integrity requirements.
Consider any situations in the system where information is or

could be changed.
Identify the set of integrity guarantees required for that
information.
2016 Soo Dong Kim

117
Guidelines for Identify Threats

Identify the threats.
Consider;
The security threats your system faces from the perspective of the
sensitive resource
The possible access to these resources that potential attackers might wish
to gain
The main characteristics of the potential attackers
The types of attacks they are likely to carry out
Characterize the threats.
Characterize each threat in terms of;
The resources that would be compromised if the attack were successful

The result of this compromise
The likelihood of the attack occuring
2016 Soo Dong Kim

118
Guidelines for Identify Threats

Example of Access Control Policy
User Account
Records
Desc. Catalog
Records
Pricing
Records
User Account
Operations
Desc. Catalog
Operations
Data
Administrator
Full with audit
Full with audit
Full with audit
Full with audit
Full with audit
Catalog Clerk
None
None
None
All
Read-only
Operations
Catalog Manager
None
None
None
Read-only
operations with
audit
All
Product Price
Administrator
None
None
None
None
Read-only
Operations
Customer Care
Clerk
None
None
None
All
Read-only
Operations
Registered
Customer
None
None
None
All on own
record
Read-only
Operations
Unknown WebSite User
None
None
None
None
Read-only
Operations
2016 Soo Dong Kim

119
Guidelines for Design the Security Impl.

Design a way to mitigate the threats.
For each of the threats to sensitive resources, design a security

mechanism.
Design a detection and recovery approach.
To include;
Technical intrusion detection solutions

Internal system checks and balances to reveal unexpected inconsistencies
A set of processes for regularly checking the system for intrusions and
reacting to any discovered
Access the technology.
To access which candidate security technologies are suitable for

addressing a particular threat in a particular context
Integrate the technology.

2016 Soo Dong Kim
120
Guidelines for Access the Security Risks

Access the Risks
For each rick in threat model;
Reevaluate its likelihood of occurrence given the planned security

infrastructure
Compare its against the security needs established earlier in the process
Estimated
Likelihood
Notional Cost
Risk
Estimated
Cost
Attacker gains direct DB access.
$8,000,000
0.2%
$16,000
Website flaw allows free order to be placed and fulfilled.
$800,000
4%
$32,000
Social-engineering attack on a customer service

representative results in hijacking of customer accounts.
$4,000,000
1.5%
$60,000
2016 Soo Dong Kim

121
Big Picture of SW Architecture

OOAD Process
SRS
Implementation
Architecture Design Process

Software
Architecture
Styles
Architecture
Viewpoints
Architectural
Tactics for NFR
2016 Soo Dong Kim

122
Unit 4.
Designing User Interface
123
Principles of User Interface Design

Learnability
User Familiarity
Consistency
Minimal Surprise
Recoverability
User Guidance
User Diversity
2016 Soo Dong Kim

124
User eXperience (UX) Design
125
User eXperience (UX)

Standards
ISO 9241-210
2016 Soo Dong Kim

126
Definition of UX
A person's perceptions and responses that result from the
use or anticipated use of a product, system or service".
ISO 9241-210
To include all the users' emotions, beliefs, preferences,
perceptions, physical and psychological responses, behaviors
ISO 9241-210
2016 Soo Dong Kim

127
Principles of UX (1)
User Experience Honeycomb
Proposed by Peter Morville
President, Semantic Studios, UX Consulting Firm,

Ann Arbor, MI, USA
2016 Soo Dong Kim

128
Useful
To have courage and creativity to ask whether products and

systems are useful
To apply deep knowledge of craft and medium
To define innovative solutions that are more useful
Usable
To ease of use remains vital
Desirable
To be tempered by an appreciation for the power and value of

image, identity, brand, and other elements of emotional design
2016 Soo Dong Kim

129
Findable
To design navigable web sites and locatable objects, so users

can find what they need
Accessible
To be accessible to people with disabilities (more than 10% of

the population
Credible
To understand the design elements that influence whether

users trust and believe
Valuable
To contribute to the bottom line and improve customer

satisfaction
2016 Soo Dong Kim

130
iOS Human Interface Guidelines
131
Overview of iOS HIG

Source
Apple
http://developer.apple.com
As of 2013.05.01
219 Pages
Guidelines
and Principles for

Designing UI and UX for iOS apps
2016 Soo Dong Kim

132
Contents of iOS HIG

9 Platform Characteristics
6 Principles of Human Interface

App Design Strategies
Transition Case Studies
27 UX Guidelines
iOS Technology Usage Guidelines
iOS UI Element Usage Guidelines
Custom Icon and Image Creation Guidelines
2016 Soo Dong Kim

133
9 Platform Characteristics
Display Is Paramount, Regardless of Its Size
Device Orientation Can Change

Apps Respond to Gestures, Not Clicks
People Interact with One App at a Time
Preferences Are Available in Settings
Onscreen User Help Is Minimal
Most iOS Apps Have a Single Window
Two Types of Software Run in iOS
Safari on iOS Provides the Web Interface
2016 Soo Dong Kim
134
6 Principles of Human Interface

Aesthetic Integrity
Consistency
Direct Manipulation
Feedback
Metaphors
User Control
2016 Soo Dong Kim

135
Principle 1. Aesthetic Integrity

To integrate the appearance
of the app and its function
A measure of how well the appearance of the app integrates

with its function
Not a measure of how beautiful an app is
Examples
An app that enables a productive task
To provide standard controls and behaviors
An app that encourages and immersive task, such as a game
To provide a beautiful appearance that promises fun and encourages

discovery
2016 Soo Dong Kim

136
Principle 2. Consistency
To allows people to transfer their knowledge and skills from
one app to another.

Not a slavish copy of other apps
An app that takes advantage of the standards and paradigms
people are comfortable with
Considerations
Consistency with iOS standards

Consistency with itself
Consistency with earlier version
2016 Soo Dong Kim

137
Principle 3. Direct Manipulation

To manipulate onscreen objects instead of using separate
controls
Examples
Tapping zoom controls

Moving and interact directly with onscreen objects
Manipulation
experience in an iOS app
To rotate or otherwise move the device to affect onscreen

objects
To use gestures to manipulate onscreen objects
To see that their actions have immediate, visible results
2016 Soo Dong Kim

138
Principle 4. Feedback
To acknowledges peoples actions and assures them that
processing is occurring
Examples
User action with some perceptible change
To highlight briefly when people tap items of list
Meaningful feedback that helps clarify the results of their

actions
To animate the addition of a new row to help people track the change
visually
2016 Soo Dong Kim

139
Principle 5. Metaphors
To suggest a usage or experience without enforcing the
limitations of the real-world or action

Examples
Tapping Music playback controls

Dragging, flicking, or swiping objects in a game
Sliding On/Off switches
Flicking through pages of photos
Spinning picker wheels to make choices
2016 Soo Dong Kim

140
Principle 6. User Control

To give people familiar and predictable actions
To give simple and straightforward actions
To give opportunity to cancel an operation before it begins
To confirm users intention to perform a potentially destructive

action
2016 Soo Dong Kim

141
App Design Strategies

Create an App Definition Statement
List All the Features Users Might Like

Determine Who Your Users Are
Filter the Feature List Through the Audience Definition
Dont Stop There
Design the App for the Device
Embrace iOS UI Paradigms

Ensure that Universal Apps Run Well on Both iPhone and iPad
Reconsider Web-Based Designs
Tailor Customization to the Task
Prototype and Iterate
2016 Soo Dong Kim

142
Transition Case Studies

Transitioning Between the Desktop and an iOS Device
From Mail on the Desktop to Mail on iPhone

From Keynote on the Desktop to Keynote on iPad
From a Desktop Browser to Safari on iOS
Transitioning Between iOS Devices
From Mail on iPhone to Mail on iPad

Running on iPhone 5
2016 Soo Dong Kim

143
32 UX Guidelines (1)
1.
Focus on the Primary Task
14. Be Succinct
2.
Elevate the Content that People Care

About
15. Use UI Elements Consistently
3.
Think Top Down
17. Delight People with Stunning Graphics
4.
Give People a Logical Path to Follow
18. Handle Orientation Changes
5.
Make Usage Easy and Obvious
19. Make Targets Fingertip-Size
6.
Use User-Centric Terminology
20. Use Subtle Animation to Communicate
7.
Minimize the Effort Required for User

Input
21. Support Gestures Appropriately
8.
Downplay File-Handling Operations
9.
Enable Collaboration and

Connectedness
16. Consider Adding Physicality and Realism
22. Ask People to Save Only When
Necessary
23. Make Modal Tasks Occasional and
Simple
10. De-emphasize Settings
24. Start Instantly
11. Brand Appropriately
25. Always Be Prepared to Stop
12. Make Search Quick and Rewarding
26. Dont Quit Programmatically
13. Entice and Inform with a Well-Written
27. If Necessary, Display a License
Description
2016 Soo Dong Kim
Agreement or Disclaimer
144
32 UX Guidelines (2)
28. For iPad: Enhance Interactivity
29. For iPad: Reduce Full-Screen
Transitions
30. For iPad: Restrain Your Information
Hierarchy
31. For iPad: Consider Using Popovers for
Some Modal Tasks

32. For iPad: Migrate Toolbar Content to
the Top
2016 Soo Dong Kim

145
iOS Technology Usage Guidelines

Routing
iAd Rich Media Ads
Passbook
Location Services and Data
Social Media
iCloud
Privacy
Quick Look Document
Preview
In-App Purchase
Sound
Game Center
VoiceOver and Accessibility
Multitasking
Edit Menu
Notification Center
Undo and Redo
Printing
Keyboards and Input Views
2016 Soo Dong Kim

146
iOS UI Element Usage Guidelines

Bars
Content Views
Alerts, Action Sheets, and Modal Views
Controls
System-Provided Buttons and Icons
2016 Soo Dong Kim

147
Custom Icon and Image Creation Guidelines
Tips for Designing Great Icons and Images
Tips for Creating Great Artwork for the Retina Display
Tips for Creating Resizable Images
App Icons
Launch Images
Small Icons
Document Icons
Web Clip Icons
Icons for Navigation Bars, Toolbars, and Tab Bars
Newsstand Icons
2016 Soo Dong Kim

148
Unit 5.
Designing Components
149
Types of Components
Components for Running Workflows
Control Layer
Components for Individual Data Objects
Model Layer
Proxy-Type Components
For External Systems
RMI
For Hardware Interface

For IoT Devices
2016 Soo Dong Kim

150
Model-Layer Components (Objects)
151
Class (1)
A class specifies related attributes and their operations.
UML Notation
Rectangle
Class Name
p1:Point
p2:Point
Attributes
Rectangle(Point p1, Point, p2)
area():Real
aspect():Real
.
move(int x, int y);
scale(float r);
Operations
2016 Soo Dong Kim

152
Class (2)
Name of Classes
Noun Phrase
Example)
Customer
Staff
Product
Rental
Reservation
2016 Soo Dong Kim

controller
PenTracker
{leaf, author = Mary Jones}
153
Class (3)
Incremental Refinement
Window
Conceptual Level
Window
size:Area
visibility:Boolean
Preliminary Design Level
display()
hide()
Window
{abstract, author=Joe}
+size:Area = (100,100)
#visibility:Boolean=true
+default-size:Rectangle
Detailed Design Level
+display()
+hide()
-attachXWindow(xwin:Xwindow*)
2016 Soo Dong Kim
154
Relationship between Classes (1)

Dependency
A temporal link between instances
Association
A persistent link between instances
Aggregation
A part-of relationship between instances
Composition
A strong aggregation
Inheritance
A parent-of relationship
2016 Soo Dong Kim

155
Relationship between Classes (2)
Weaker
Dependency
Dashed Arrow
Stronger
Association
Aggregation
Simple Connection Line Empty Diamond Arrow Filled Diamond Arrow
When objects of one

When objects of one When one class owns
class work briefly with
class work with
but shares a reference
objects of another class objects of another class to objects of another
for some prolonged
class
amount of time
2016 Soo Dong Kim

Composition
When one class

contains objects of
another class
Inheritance
Empty Arrow
When one class is a
type of another class
156
Dependency
Definition
A casual, temporal link between instances

Use invoke.
Example
Customer inquires the US Exchange Rate.

Customer
invoke
Often, the dependency
2016 Soo Dong Kim

Exchange Rate
0..*
Currency
is omitted in class diagrams.
157
Association
Definition
An association specifies a persistent link between instances.
Long-lasting or Permanent Links
Use a secondary storage to record all the links between

instances.
Typically in a Database Table
2016 Soo Dong Kim

Customer
Bank
Account
Passenger
Flight
Ticket
158
Association and Link

Association is between Classes.
Link is between Instances.

Customer
Rental
Car Item
R 21
John
R8
R7
Susan
2016 Soo Dong Kim

Ohio
E331AV
R2
R 13
Mike
CA
4AQ688
PENN
GHG529
R1
R 15
CA
7YG233
159
{xor} Constraint
Usage
Only one of several potential associations can be applied to

each instance.
Example
Person
Account
{xor}
Corporation
2016 Soo Dong Kim

160
Cardinality (1)
Semantics
To specify the number of links that can exist between instances
Notation
2016 Soo Dong Kim

Class
Exactly One
0..*
Class
Many (Zero or More)
0..1
Class
Optional (Zero or One)
m..n
Class
Numerically Specified
161
Cardinality (2)
{ordered}
To show that the end represents an ordered set

Polygon
3..*
{ordered}
p1
p2
Point
p5
p3
Person
0..*
{ordered}
Employment 1..*
1..*
p4
Company
0..*
/employer
E5
2004.9.1 ~ 2010.3.31
E 62
2010.4.1 ~ 2010.7.20
E88
2012.1.2 ~ Current
#1
John
#2
#3
2016 Soo Dong Kim

162
Cardinality (3)
Car Rental System
Person
0..*
Customer
Reservation 0..*
1
1
Car Model
1
0..1
0..*
0..*
0..1
Rental
0..*
Car Item
0..*
Staff
2016 Soo Dong Kim

163
Cardinality (4)
eCommerce System
Manufacturer
0..*
Product
Model
1
0..*
Customer
0..*
Order
1
0..*
Payment
Credit Card
Payment
2016 Soo Dong Kim

Bank
Transfer
0..1
1..*
Product
Item
1
0..1
Delivery
PayPal
164
Derived Associations and Attributes

Definition
Derived Attribute
Derived Association
Time Period
start: Date
end: Date
/duration: Date
Use a slash, /
Consideration
Redundancy
Efficiency
Person
0..*
Employment 1..*
{ordered}
1..*
Company
0..*
/employer
2016 Soo Dong Kim

165
Aggregation and Composition

Aggregation
Has, Part_of, Consist_of Relationship
Composition
A stronger form of aggregation

A part object may belong to only one whole object.
Polygon
After Deletion
{ordered} 3..*
Point
2016 Soo Dong Kim
Fill Pattern
166
Association, Aggregation, Composition

Association
p1
Independent Existence
Triangle
1
3
t7
Point
p2
p3
Aggregation
p1
Whole part exists with parts.

Triangle
Point
p1
After Deletion
t7
p2
p3
p2
p3
Composition
Parts are deleted when the whole is deleted.

p1
Triangle
1
3
Point
Their implementations are different.

2016 Soo Dong Kim
t7
p2
After Deletion
p3
167
Inheritance
Definition
A relationship between a general class and a specific class
Superclass, Subclass
A subclass inherits the features of superclass.
Account
Checking
Account
2016 Soo Dong Kim

Person
Savings
Account
Customer
Staff
168
Realization
Definition
A relationship between a specification and an implementation

Used for specifying stepwise Refinement.
Notation
Dashed line with a triangular arrowhead
MAPS API
Specification
Realizes
Google MAP
2016 Soo Dong Kim

Naver MAP
Implementation
169
Interface
An interface only has method signatures, not their
implementations.
An interface specifies a protocol for a class or a component.
An interface cannot be instantiated, it can only be realized.
Class GoogleMap implements MAPapi, in Java
An interface can extend other interfaces.
Use interface
Can an interface have attributes?
static and final attributes in Java.
2016 Soo Dong Kim

170
Interface Realization
Interface iSensor
interface
iSensor
- sensorID
+ start();
+ stop();
+ read(): string;
+ getStatus(): string;
Classes realize interfaces.
Proximity Sensor implements iSensor

Infrared Ray Sensor implements iSensor
Proximity Sensor
Infrared Ray Sensor

2016 Soo Dong Kim
interface
iSensor
interface
iSensor
171
Provided Interface
A provided interface of a class is an interface
that the class
realizes.
A component's provided interface describes the services
provided by the class.

interface
Proximity Sensor
iSensor
Provided Interface
Proximity Sensor
iSensor
Other classes interact with a class through its provided
interfaces.
2016 Soo Dong Kim
172
Required Interface (1)

A required interface of a class is the services that the class
needs to function.
The class needs another class that realizes that interface to

properly function.
Principle of Loose Coupling applied
The class invokes the needed services only through the required
interface.
Required Interface
Theft Alarm
iSensor
2016 Soo Dong Kim

173
Required Interface (2)

Plug-in Objects
interface
iSensor
- sensorID: integer
Role of
Service Provider
+ start();
+ stop();
+ read(): string;
+ getStatus(): string;
iSensor
2016 Soo Dong Kim

Role of
Service Consumer
Theft Alarm
Proximity Sensor
Class ProximitySensor
implements iSensor; {
Role of
Standardization
iSensor
Class TheftAlarm {
TheftAlarm (iSensor s, ) { };
check( ) {
s.read( );
}
}
ProximitySensor ps =
new ProximitySensor ();
TheftAlarm myAlarm =
new TheftAlarm (ps, );
myAlarm.check( );
174
Required Interface and Reusability (1)

Product Line Engineering
Commonality and Variability (C&V) Analysis
Variability Modeling
Required Interface, i.e VP
Variation Point (VP)

Variants
Standardization
Control for
Powered or Manual
Control for
Forward or Backward
2016 Soo Dong Kim

Control for
Move or Stop
Plug-in Objects,
i.e. Variants
175
Required Interface and Reusability (2)

Reusability-based
Technologies
Design Patterns
Component-based Development (CBD)
Product-Line Engineering (PLE)
Service-Oriented Architecture (SOA)
Cloud Computing
Model-Driven Architecture (MDA)
Related Terms
Plug-n-Play Scheme
Mix-n-Match Scheme
Mash-up Service Composition
Service Dynamic Adaptation
2016 Soo Dong Kim

Building System by
Assembling Software Parts
Maintaining System by
Exchanging Software Parts
176
Utility
A class that has no instances, but rather specifies a named
collection of non-member attributes and operations.

Visibility of the attributes
and operations of a utility class are
global, i.e. public.

Use Utility
Utility
MathPak
+ Sin(Angle) : Real
+ cos(Angle): Real
+ Sqrt(Real): Real
+ Random():Real
2016 Soo Dong Kim

177
Using Component Diagram
178
Overview
Shows the definition, internal structure, and dependencies
of component types.
Necessity
To divide a System into Components

To show Interrelationships between Components through
Interfaces
To show Breakdown of Components into Lower-level Structure
2016 Soo Dong Kim

179
Elements of Component Diagram

Component
Interface
Port
Connector
2016 Soo Dong Kim

180
Component
Definition
A modular unit with well-defined interfaces that is replaceable

within its environment
A physical and replaceable part of a system
Independently purchasable and upgradeable pieces
Notation
Keyword <<component>>
A component icon in the right hand corner
<<component>>
Order
Semantic
Be a self contained unit that encapsulates the state and

behavior of a number of classifiers.
A component has an external view by means of its publicly
visible properties and operations.
2016 Soo Dong Kim

181
Component Description
Basic Components
A subtype of class that has an external specification in the form

of one or more provided and required interfaces, and an
internal implementation
A set of realizingClassifiers that realize its behavior
A component has a number of provided and required
Interfaces.
Packaging Components
An extended concept to define the grouping aspects of

packaging components
A namespace aspects of a component through its inherited
ownedMember and elementImport associations
2016 Soo Dong Kim

182
Interface
Provided Interface
An interface that the component provides as a service to other
components
To be realized directly by the component
Provided Interface
<<component>>
Required Interface
Provided Port
Order
The specification of external services required by the current

component
To be designated by a Usage Dependency from the component
Required Interface
Required Port
2016 Soo Dong Kim
<<component>>
Order
183
Connector
Definition
An extended concept in the Components package to include
contracts and notation
A link that enables communication between two or more
instances
Two Types of Connectors
Delegation Connector
Assembly Connector
2016 Soo Dong Kim

184
Delegation Connector
Definition
Notation
A connector links the external contract of a component (as specified

by its ports) to the internal realization of that behavior.
Forwarding of signals from a port to an internal part or to another

port
Semantics
To specify a declaration that behavior is not actually realized by a

component itself, but by another instance that has compatible
capabilities
To model the hierarchical decomposition of behavior
2016 Soo Dong Kim

185
Example of Delegation Connector

OrderEntry
<<component>>
Order
:OrderHeader
:LineItem
2016 Soo Dong Kim

Person
186
Assemble Connector
Definition
Notation
A connector between two components that one component

provides the services that another component requires
Wiring between interfaces using Dependecies
Semantics
Be notated by a ball-and-socket connection between a

provided interface and a required interface.
2016 Soo Dong Kim

187
Example of Assembly Connector

OrderEntry
<<component>>
:Order
OrderableItem
OrderableItem
<<component>>
:Product
2016 Soo Dong Kim

188
Unit 6.
Designing Database
189
Object-Relational (OR) Mapping
190
Object Relation (OR) Mapping

Problem
How to manage persistent objects in a relation database.
3 Types of Instantiations
Using only transient objects
Using only persistent objects
Instances in main memory

Each instance in main memory must map to a record in a database table.
Using both transient and persistent objects
A mixture of objects in main memory and/or in database table.
2016 Soo Dong Kim

191

Using only transient objects
No need to store object states in database

Use the conventional mechanism of creating instances by
invoking constructors.
2016 Soo Dong Kim

192

Using only persistent objects
Define CRUD operations to manage object-to-relation mapping.
Inside constructors, invoke dbCreateObj ( );
dbCreateObj ( );
dbRetrieveObj ( );
dbUpdateObj ( );
dbDeleteObj ( );
Creating a new record in the database table.
Inside finder methods, invoke dbRetrieveObj ( );
Create an instance in main memory,

retrieve the object from the table, then
restore the state of the object.
Inside set methods, invoke dbUpdateObj ( );

Inside destructors, invoke dbDeleteObj ( );
2016 Soo Dong Kim

193

Class Name
Attributes
Constructors & Destructors
A ( x, y );
A ( x, y, flag );
~A ( );
Client
Program
Business Methods
getMethod-1 ( );
setMethod-2 ( );
Database Operations
private dbCreateObj ( _);
private dbRetrieveObj ( _);
private dbUpdateObj ( );
private dbDeleteObj ( );
2016 Soo Dong Kim

Database
194

Using both transient and persistent objects
Need to distinguish two types of constructors.

Use polymorphic constructors.
Using a flag
A (x, y);
A (x, y, db);
// Creates transient instance

// Creates persistent instance
Invoke database operations directly.
myA := A (x, y);

myA . dbUpdateObj ( );
myA . dbRestoreObj ( );
2016 Soo Dong Kim

195
Mapping Inheritance
Horizontal Partitioning
Vertical Partitioning
Unification
2016 Soo Dong Kim

196
Entire object within one table
Only one table required to activate object

No unnecessary fields in the table
Must search over multiple tables for common properties
2016 Soo Dong Kim

197
Each concrete class is mapped to a table
Account
Owner
name_ : String
taxId_ : String
id_ : String
balance_ : double
owner_
1
OwnerTable
name
taxId
InterestBearingAccount
rate_ : double
termDays_ : int
CheckingAccount
checkFee_ double
CheckingAccountTable
id
balance
ownerID
checkFee
InterestBearingAccountTable
id
balance
ownerID
2016 Soo Dong Kim

rate
termDays
198
Good strategy when changing types is rare
Advantages
Easy to do Ad-hoc reporting

Good performance
Disadvantages
Change to a class will affect its table and the table of its
subclasses
Whenever an object changes its role, you need to copy data into
the appropriate table
2016 Soo Dong Kim

199
Object spread across different tables
Must join several tables to activate object

No unnecessary fields in each table
Only need to search over parent tables for common
properties
2016 Soo Dong Kim

200
Each class is mapped to a table
Account
Owner
name_ : String
taxId_ : String
id_ : String
balance_ : double
owner_
1
OwnerTable
name
taxId
AccountTable
id
balance
ownerID
rate_ : double
termDays_ : int
CheckingAccount
checkFee_ double
InterestBearingAccountTable
id
rate
termDays
CheckingAccountTable
id
2016 Soo Dong Kim
checkFee
201
Good strategy when types change often
Advantages
Easy to understand because of one-to-one mapping

Supports polymorphism easily each type in a separate table
Changes to subclass and addition to superclass affect
addition/modification of one table
Disadvantages
Extra joins are needed to get to a subclass could lead

performance issue
Ad-hoc reporting is difficult unless you add views
2016 Soo Dong Kim

202
Unification
Entire object within one table
Only one table required to activate object

Unnecessary fields in the table
All sub-types
2016 Soo Dong Kim

will be located in a search of the common table
203
Unification
Each sub-class is mapped to the same table
Owner
name_ : String
taxId_ : String
Account
owner_
id_ : String
balance_ : double
rate_ : double
termDays_ : int
OwnerTable
name
CheckingAccount
checkFee_ double
taxId
AccountTable
id
accType
balance
2016 Soo Dong Kim

ownerId
rate
termDays
checkFee
204
Unification
Advantages
Simple
Easy to add classes
Easy support for polymorphism
Single table leads to good data access performance
Disadvantages
Changes to any class will affect schema

Space wasted in database
Table size can grow significantly with herirarchies
2016 Soo Dong Kim

205
Database Design Space
206
Types of Databases
Relational Database
Object-Oriented Database
NoSQL Database
Key-Value Stores
Document-Oriented Databases
Column-Oriented Databases
Graph Databases
2016 Soo Dong Kim

207
Relational Database (1)

A database based on the relational model
The relational model is the primary model for database

management during the past few decades.
Predominant technology for storing structured data
Web and business applications
Pros
To use a standard data access language, Structured Query

Language (SQL)
To have sound theoretical foundation
Cons
Lack of supporting complex types
2016 Soo Dong Kim

208
Relational Database (2)

Representative Products
MySQL
MariaDB
Oracle Database
IBM DB2
2016 Soo Dong Kim

209
NoSQL (1)
Not no to SQL
Another option, not the only one
Not not only SQL
Oracle DB or PostgreSQL would fit the definition
Next Generation Databases mostly addressing some of the
points
being non-relational, distributed, open-source and horizontally
scalable.
Often more characteristics apply as: schema-free, easy
replication support, simple API, eventually consistent (BASE,
not ACID), a huge data amount, and more
2016 Soo Dong Kim

210
NoSQL (2)
Main objective: implement distributed state
Different objects stored on different servers

Same object replicated on different servers
Main idea: give up some of the ACID
To improve performance
Simple interface:
Write (=Put): needs to write all replicas

Read (=Get): may get only one
Strong consistency eventual consistency
2016 Soo Dong Kim

211
Revisiting Relational Database

Relational databases are not going away.
Compelling arguments for most projects
Familiarity, stability, feature set, and available support
Relational databases as one option for data storage
Polyglot persistence using different data stores in different

circumstances
Search for optimal storage for a particular application
2016 Soo Dong Kim

212
Motivation for NoSQL Databases

Huge amounts of data are now handled in realtime.
Both data and use cases are getting more and more dynamic.
Social networks (relying on graph data) have gained
impressive momentum.
Special type of NoSQL databases: graph databases
Full-texts have always been treated shabbily
2016 Soo Dong Kim

by RDBMS.
213
5 Advantages of NoSQL (1)

Elastic Scaling
Classical database administrators scale up buy bigger

servers as database load increases
Scaling out distributing the database across multiple hosts as
load increases
Big Data
Volumes of data that are being stored have increased massively

Opens new dimensions that cannot be handled with RDBMS
2016 Soo Dong Kim

214
5 Advantages of NoSQL (2)

Goodbye DBAs (see you later?)
Automatic repair, distribution, tuning, vs. expensive, highly

trained DBAs of RDBMS
Economics
Based on cheap commodity servers less costs per

transaction/second
Flexible Data Models
Non-existing/relaxed data schema structural changes cause

no overhead
2016 Soo Dong Kim

215
5 Challenges of NoSQL (1)

Maturity
Still in pre-production phase

Key features yet to be implemented
Support
Mostly open source, result from start-ups
Enables fact development
Limited resources or credibility
Administration
Require lot of skill to install and effort to maintain
2016 Soo Dong Kim

216
5 Challenges of NoSQL (2)

Analytics and Business Intelligence
Focused on web apps scenarios
Modern Web 2.0 applications

Insert-read-update-delete
Limited ad-hoc querying
Even a simple query requires significant programming expertise
Expertise
Few number of NoSQL experts available in the market
2016 Soo Dong Kim

217
Types of NoSQL Databases

Core:
Key-value databases
Document databases
Column-family (column-oriented/columnar) stores
Graph databases
Non-core:
Object databases
XML databases
2016 Soo Dong Kim

218
Key-value Database
The simplest NoSQL data stores
A simple hash table (map), primarily used when all access to the
database is via primary key
A table in RDBMS with two columns, such as ID and NAME

ID column being the key
NAME column storing the value
A BLOB that the data store just stores
Basic operations:
Get the value for the key
Put a value for a key
Delete a key from the data store
Simple great performance, easily scaled
Simple not for complex queries, aggregation needs
2016 Soo Dong Kim

219
Column-family Database (1)

Also columnar or column-oriented
Column families
Rows that have many columns associated with a row key
Column families are groups of related data that is often

accessed together.
e.g., for a customer we access all profile information at the

same time, but not orders
2016 Soo Dong Kim

220
Column-family Database (2)

Example
2016 Soo Dong Kim

221
Document Databases (1)
Documents are the main concept

Stored and retrieved
XML, JSON,
Documents are
Self-describing
Hierarchical tree data structures
Can consist of maps, collections (lists, sets, ), scalar values, nested
documents,
Documents in a collection are expected to be similar
Their schema can differ
Document databases store documents in the value part of the

key-value store
Key-value stores where the value is examinable
2016 Soo Dong Kim

222
Document Databases (2)

Example
2016 Soo Dong Kim

223
Graph Databases (1)

To store entities and relationships between these entities
Node is an instance of an object.

Nodes have properties.
e.g., name
Edges have directional significance.

Edges have types.
e.g., likes, friend,
Nodes are organized by relationships.
Allow to find interesting patterns

e.g., Get all nodes employed by Big Co that like NoSQL Distilled
2016 Soo Dong Kim

224
Graph Databases (2)

Example
2016 Soo Dong Kim

225
Unit 7.
Design with Patterns
226
Principles of Design Patterns
227
Motivation
Software Cost
& Productivity
Reusable
Software Assets
Software
Quality
Library
Design
Patterns
Components
Services
Process
2016 Soo Dong Kim

228
Design Patterns
To represent solutions to problems that arise when
developing software within a particular context
Pattern = Problem/Solution pair in a Context
To capture the static and dynamic structure and
collaboration among key participants in software designs

To facilitate reuse of successful software architectures and
designs
2016 Soo Dong Kim

229
Design Pattern Description

Main parts
Name and intent

Problem and context
Force(s) addressed
Abstract description of structure and collaborations in solution
Positive and negative consequence(s) of use
Implementation guidelines and sample code
Known uses and related patterns
Pattern descriptions are often independent
of programming
language or implementation details.
Contrast with frameworks
2016 Soo Dong Kim

230
Classifications of Design Patterns

Creational Patterns
Deal with initializing and configuring classes and objects
Structural Patterns
Deal with decoupling interface and implementation of classes

and Objects
Behavioral Patterns
Deal with dynamic interactions among societies of classes and

objects
2016 Soo Dong Kim

231
5 Creational Patterns
Factory Method
Abstract Factory
Builder
Prototype
Singleton
2016 Soo Dong Kim

232
7 Structural Patterns
Adapter
Bridge
Composite
Decorator
Faade
Flyweight
Proxy
2016 Soo Dong Kim

233
11 Behavioral Patterns
Chain of Responsibility
Command
Interpreter
Iterator
Mediator
Memento
Observer
State
Strategy
Template Method
Visitor
2016 Soo Dong Kim

234
Key Principles
Successful patterns and frameworks can be boiled down to a
few key principles:

Separate interface from implementation
Determine what is common and what is variable with an
interface and an implementation
Common Stable
Variable Unstable, To be resolved
Allow substitution of variable implementations via a common

interface.
Dividing commonality from variability should be goal-
oriented rather than exhaustive.
2016 Soo Dong Kim

235
Open/Closed Principle
Determining Common vs. Variable Features
Insufficient variation makes it hard for users to customize

framework components.
Dependency should always be in the direction of stability.
A software component should not depend on any component

that is less stable than itself .
Open/Closed principle
allows the most stable component to be extensible.
2016 Soo Dong Kim

236
Open/Closed Principle (contd)

Components should be:
Open for Extension

Closed for Modification
For Common?
For Variable?
Impacts
Abstraction is good
Inheritance and polymorphism are good
Public data members and global data are bad
Run-time type identification can be bad
2016 Soo Dong Kim

237
Proxy Pattern
238
Intent
Provide a surrogate or placeholder for another object to control access

to it.
A proxy is
a person authorized to act for another person

an agent or substitute
the authority to act for another
There are situations in which a client does not or can not reference an
object directly, but wants to still interact with the object.
A proxy object can act as the intermediary between the client and the
target object.
The proxy object has the same interface as the target object.
The proxy holds a reference to the target object and can forward requests to
the target as required (delegation!).
In effect, the proxy object has the authority the act on behalf of the client to
interact with the target object.
2016 Soo Dong Kim

239
Types of Proxy
Remote Proxy
Virtual Proxy
To allow creation of a memory intensive object on demand

The object will not be created until it is really needed.
Protection (Access) Proxy
To provide a reference to an object located in a different address space on

the same or different machine
To provide different clients with different levels of access to a target object

Useful when objects should have different access rights.
Smart Reference Proxy
To provide additional actions whenever a target object is referenced such as;
Counting the number of references to the object

Loading a persistent object into memory when it's first referenced
Checking that the real object is locked before it's accessed to ensure that no other object
can change it.
2016 Soo Dong Kim

240
Structure
Subject
+ request() : void
RealSubject
realSubject
+ request() : void
aClient
subject
Proxy
+ request() : void
public void request() {

realSubject.request();
}
aProxy
aRealSubject
realSubject
2016 Soo Dong Kim

241
Participants (1)
Proxy (ImageProxy)
To maintain a reference that lets the proxy access the real

subject
Proxy may refer to a Subject if the RealSubject and Subject interfaces are
the same.
To provide an interface identical to Subject's so that a proxy can

by substituted for the real subject
To control access to the real subject and may be responsible for
creating and deleting it
Other responsibilities depending on the kind of proxy
Remote Proxies To encode a request and its arguments and send the
encoded request to the real subject in a different address space
Virtual Proxies To cache additional information about the real subject so
that they can postpone accessing it
Protection Proxies To check that the caller has the access permissions
required to perform a request
2016 Soo Dong Kim

242
Participants (2)
Subject (Graphic)
To define the common interface for RealSubject and Proxy so

that a Proxy can be used anywhere a RealSubject is expected
RealSubject (Image)
To define the real object that the proxy represent
2016 Soo Dong Kim

243
State Pattern
244
Intent
Allow an object to alter its behavior when its internal state
changes.
The object will appear to change its class.
Use the State pattern whenever:
An object's behavior depends on its state, and it must change

its behavior at run-time depending on that state.
Operations have large, multipart conditional statements that
depend on the object's state.
The State pattern puts each branch of the conditional in a separate class.
2016 Soo Dong Kim

245
Motivation
A TCPConnection object receives requests from other
objects, it responds differently depending on its current

state.
TCPConnection
state
+ open() : void
+ close() : void
+ acknowledge() : void
public void open() {

state.open();
}
2016 Soo Dong Kim

TCPState
+ open() : void
+ close() : void
TCPEstablished
TCPListen
TCPClosed
+ open() : void
+ close() : void
+ open() : void
+ close() : void
+ open() : void
+ close() : void
246
Structure
Context
+ request() : void
public void request() {

state.handle();
}
2016 Soo Dong Kim

State
state
+ handle() : void
ConcreteStateA
+ handle() : void
ConcreteStateB
+ handle() : void
247
Participants
Context (TCPConnection)
To define the interface of interest to clients

To maintain an instance of a ConcreteState subclass that defines
the current state
State (TCPState)
To define an interface for encapsulating the behavior associated

with a particular state of the Context
ConcreteState subclasses (TCPEstablished, TCPListen,
TCPClosed)
Each subclass implements a behavior associated with a state of

the Context.
2016 Soo Dong Kim

248
Template Method Pattern
249
Intent
Define the skeleton of an algorithm in an operation,
deferring some steps to subclasses.

Template Method lets subclasses redefine certain steps of an
algorithm without changing the algorithm's structure.

Consider this situation
1) you want to specify (or fix) the order of operations that a

method uses.
2) but, you want to vary some of these operations to meet
subclasses needs.
2016 Soo Dong Kim

250
Motivation (1)
Consider an application framework that provides Application
and Document classes:

Application class for opening existing documents
Document class for representing the information in a document
Document
+ save() : void
+ open() : void
+ close() : void
+ doRead() : void
Application
docs
*
MyDocument
+ doRead() : void
2016 Soo Dong Kim

+ addDocument() : void
+ openDocument() : void
+ docreateDocument() : void
+ canOpenDocument() : void
+ aboutToOpenDocument() : void
MyApplication
create
+ doCreateDocument() : void
+ canOpenDocument() : void
+ aboutToOpenDocument() : void
public void doCreateDocument() {

return new MyDocument();
}
251
Motivation (2)
The OpenDocument() method might look like this:

public void OpenDocument (String name) {
if (!CanOpenDocument(name)) { return; }
Document doc = DoCreateDocument();
if (doc != null) {
docs.AddDocument(doc);
AboutToOpenDocument(doc);
doc.Open();
doc.DoRead();
}
}
The OpenDocument() method is a Template Method.
The template method fixes the order of operations, but allows

Application subclasses to vary those steps as needed.
2016 Soo Dong Kim

252
Structure
AbstractClass
+ templateMethod() : void
+ primitiveOperation1() : void
public void templateMethod() {
primitiveOperation1();
primitiveOperation2();
ConcreteClass
2016 Soo Dong Kim

253
Participants
AbstractClass (Application)
To define abstract primitive operations that concrete subclasses

define to implement steps of an algorithm
To implement a template method defining the skeleton of an
algorithm
The template method calls primitive operations as well as operations

defined in AbstractClass or those of other objects.
ConcreteClass (MyApplication)
To implement the primitive operations to carry out subclassspecific steps of the algorithm
2016 Soo Dong Kim

254
Observer Pattern
255
Intent
To define a one-to-many dependency
between objects so
that when one object changes state, all its dependents are
notified and updated automatically
2016 Soo Dong Kim

256
Motivation
Consider graphical user interface toolkits which separates
the presentational aspects of the user interface from the

underlying application data
The need to maintain consistency between related objects

without making classes tightly coupled
a = 50%
b = 30%
c = 20%
2016 Soo Dong Kim
change notification
Requests, modification
257
Applicability
Use the Observer pattern in any of the following situations:
When an abstraction has two aspects, one dependent on the

other.
Encapsulating these aspects in separate objects lets you vary and reuse
them independently.
When a change to one object requires changing others

When an object should be able to notify other objects without
making assumptions about those objects
2016 Soo Dong Kim

258
Structure
Subject
+ attach(Observer) : void
+ detach(Observer) : void
+ notify() : void
Observer
observers
* + update() : void
public void notify() {
for all o in observers {
o.update();
}
}
aConcreteObserver
aConcreteSubject
subject
+ update() : void
- subjectState
+ getState()
+ setState() : void
2016 Soo Dong Kim

- observeState
public String getState() {

return subjectState;
}
public void update() {

observeState =
subject.getState();
}
259
Participants
Subject
To keep track of its observers
To provide an interface for attaching and detaching Observer objects
Observer
To define an interface for update notification
ConcreteSubject
The object being observed
To store state of interest to ConcreteObserver objects
To send a notification to its observers when its state changes
ConcreteObserver
The observing object
To store state that should stay consistent with the subject's
To implement the Observer update interface to keep its state
consistent with the subject's
2016 Soo Dong Kim

260
Collaborations (1)
Notifying changes to observers
ConcreteSubject notifies its observers whenever a change

occurs that could make its observers' state inconsistent with its
own.
Reflecting the changes
After being informed of a change in the concrete object,

ConcreteObserver object may query the subject for
information. ConcreteObserver uses this information to
reconcile its state with that of the subject.
2016 Soo Dong Kim

261
Collaborations (2)
Object
aConcreteSubject
aConcreteObserver
anotherConcreteObserver
setState()
notify()
update()
getState(): String
update()
getState(): String
notify() is not always called by the subject.

It can be called by an observer or by another kind
of object entirely.
2016 Soo Dong Kim

262
Unit 8.
Design with Traceability
263
What is SW Traceability?
Traceability is the feasibility in defining and enforcing
mapping relationships between source elements and target

elements.
Traceability is an essential foundation for;
Model-Driven Architecture (MDA)

Verification and Validation
2016 Soo Dong Kim

264
Artifacts Transformation
Transformation from Source Artifact(s) to Target Artifact(s)
Automatic transformation is not feasible.

Often, additional Information, , is needed.
PHASEi
A i1
PHASEj
A i2
transforms
Aj1
A j2
i2
Example
Workflow in Use Case Description

Workflow in Sequence Diagram
2016 Soo Dong Kim

265
Case Study: Car Rental System

Use Case Diagram
2016 Soo Dong Kim

266
Source Artifact
Use Case Description
for Check Out
2016 Soo Dong Kim

Workflow
267
Target Artifact
Sequence Diagram
Workflow
for Check Out
2016 Soo Dong Kim

268
Gap between the 2 Artifacts

Source Artifact: Use Case Description
Workflow in Textual Form

Represents Clients View on the Workflow
Target Artifact: Sequence Diagram
Workflow in Messages Form

Represents Developers View on the Workflow
2016 Soo Dong Kim

269
Additional Information,
Control Flow of the System part
Design-level Control Flow

Consider Interaction Operators
Objects and their Methods carrying the workflow
From Class Diagram
Data Continuity through arguments of messages
2016 Soo Dong Kim

270
Category of Additional Information,
2016 Soo Dong Kim

271
Traceability Map
Showing the trace links among artifacts
Trace Link 3
Trace Link 5
Trace Link 8
Conceptual
Class Diagram (CCD)
Trace Link 2
Detailed
Class Diagram (DCD)
2016 Soo Dong Kim


(UCDesc)
Trace Link 7
Trace Link 10
Conceptual Sequence
Diagram (CSD)
Trace Link 12
Trace Link 11
Software Architecture (SA)
Use Case Diagram

(UCD)
Trace Link 9
Trace Link 1
Trace Link 6
Trace Link 4
Specification (SRS)
Trace Link 13
Detailed Sequence
Diagram (DSD)
272
Trace Link
Defines a common form of trace information between
source and target elements

L = (s, t, lType, modality, mul)
s: Source Artifact
t: Target Artifact
lType: Link Type
modality: Optionality of the Link
mul: Multiplicity of the Mapping
2016 Soo Dong Kim

273
Functions used for Trace Links
2016 Soo Dong Kim

274
Trace Links used forVerification

Verification Flow
Utilized Trace Link
VerRule4
A2. Use Case Diagram

VerRule2
(1) Verify UCD
Trace Link 1
(2) Verify UCDesc
Trace Link 2
Trace Link 3
(3) Verify SA
Trace Link 4
(4) Verify CCD
Trace Link 5
Trace Link 6
Trace Link 7
Trace Link 8
(5) Verify CSD
Trace Link 9
Trace Link 10
(6) Verify DCD
Trace Link 11
(7) Verify DSD
Trace Link 12
Trace Link 13
(8) Verify Code
Trace Link to DCD

Trace Link to DSD
VerRule8
A5. Conceptual Class

Diagram
VerRule10
A6. Conceptual
Sequence Diagram
A7. Detailed Class

Diagram
VerRule15
A9. Source Code
2016 Soo Dong Kim

VerRule14
VerRule13
A8. Detailed Sequence

Diagram
VerRule12
VerRule11
A4. Software
Architecture
VerRule7
VerRule9
A3. Use Case Description
VerRule5
VerRule1
VerRule6
VerRule3
A1.SRS
275
Artifacts in OO Projects
Requirements
Class Diagram
Architecture
Object-Relation Mapping
SRS
Sequence Diagram
UI Design
Java Code
Use Case Model

Database
Software
Product
Test Cases
2016 Soo Dong Kim
276
Trace Links in OO Projects

Requirements
Class Diagram
Architecture
Object-Relation Mapping
SRS
Sequence Diagram
UI Design
Use Case Model
Database
Java Code
Software
Product
Test Cases
2016 Soo Dong Kim
277
Consistency among 3 Diagrams

Use Case Model
Class Diagram
Use Case Diagram
Class
Actor
Class Name
Use Case
Attribute
Sequence Diagram
Object
Message Flow
Operation
Relationship between
Classes
Directly mapped to
May be mapped to
(provide information)
2016 Soo Dong Kim
A name of the
use case can
be mapped to
the operation
name.
Draw a sequence diagram

per an use case.
Flows described in
U.C. description are basis
for message flows in
sequence diagram.
Operations participated in
the message flow should
conform to the operation
declaration in class diagram.
278
Consistency among 3 Diagrams
Between Use Case Model and Object Model
The set of use cases The set of all methods of classes in C.D.
Not a complete mapping, due to coordination-related functionality
The functionality of a use case is scattered over a number of methods

which may be in different classes.
Between Use Case Model and Dynamic Model

Use Case Diagram Sequence Diagram
For each use,
Actors Actors in the 1st Column

Control Flow of UC Description Control Flow of the Controller
(1..*) Interaction in UC Desc. (1..*) messages in S.D.
Between Object Model and Dynamic Model

Objects in S.D. Corresponding Classes in C.D.
Message in S.D. Corresponding Method in the Class
Arguments of Messages in S.D. Parameters of Methods in C.D.
2016 Soo Dong Kim

279
Traceability-Centric Development
J.S.Her, H. Yuan, S.D. Kim, Traceability-Centric
Model-Driven
Object-Oriented Engineering, Information and Software
Technology, 2010.
2016 Soo Dong Kim

280
Unit 9.
Concluding Remarks
281
Future of Information Technologies

Internet of Everything (IoE)
Beyond IoT
Information of Everything (IoE)
Big Data, Big Contexts
Analytics
Big Data
Being Autonomous!
Increased
Complexity
of Systems
Towards Smart Services
Being System of Systems (SoS)!
Sys
2016 Soo Dong Kim

282
Strategies for Handling Complexity

NOT
It is not a Scaled-up Problem.
BUT
Engineering Approach
Design Principles
Reuse Engineering with Reusable Assets
Quality Engineering
Architectural Approaches
More
Increased
Complexity
of Systems
2016 Soo Dong Kim
283
Thank You !
2016 Soo Dong Kim

284

SW Design Principles and Techniques, Soo Dong Kim

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

SW Design Principles and Techniques, Soo Dong Kim

Diunggah oleh

Hak Cipta:

Format Tersedia

Software Design

Principles and Techniques

Soo Dong Kim, Ph.D.

2016 Soo Dong Kim

Nature of Software Design

Principles of Software Design

Designing Software Architecture

Designing User Interface

Design with Patterns

Design with Traceability

2016 Soo Dong Kim

The process of defining the architecture, components,

[ISO/IEC/IEEE Standard 12207], Software Life Cycle Processes

Software design consists of two activities that fit between

Software Architectural Design

2016 Soo Dong Kim

Comprehension and Representation

Refinement of Analysis Model

Transforming Design into Code

2016 Soo Dong Kim

System Modeling (1)

A model is an abstraction of reality.

Models in Daily Life

Map, Organization Chart, Home Pages, Model House for

Models in System Development

User Interface, Flow Chart, ER Diagram, Gantt Chart, etc.

Modeling = Analysis + Preliminary Design

System Modeling (2)

To understand the target system clearly, and specify the

2016 Soo Dong Kim

3Views of Systems (1)

Modeling 3 views of the system

2016 Soo Dong Kim

3Views of Systems (2)

Observes the functionality to be delivered.

Observes the data and information manipulated by the

Observes the runtime behavior, i.e. sequence of executions.

2016 Soo Dong Kim

Design Artifacts and UML

Degree of conformance to explicitly stated functional and

Requirements are the foundation from which quality is

Lack of conformance to requirements is lack of quality.

Developers should follow the specified standards for

2016 Soo Dong Kim

Organization of ISO 9126 (ISO 25010:2011)

Quality In Use Metrics

2016 Soo Dong Kim

Types of Quality in ISO 9126 (1)

Quality of Life-cycle Process

Can be evaluated by measuring internal attributes or measuring

is evaluated by the static measure of intermediate products.

Product quality contributes to improving quality in use.

2016 Soo Dong Kim

Types of Quality in ISO 9126 (2)

Users view of the quality of an environment containing

Rather than properties of the software itself.

Users environment may be different from development

2016 Soo Dong Kim

Types of Quality in ISO 9126 (3)

2016 Soo Dong Kim

Quality Model of ISO 9126

2016 Soo Dong Kim

Quality Model of ISO 9126

2016 Soo Dong Kim