Object Oriented Analysis & Design
With Visio
Dibawakan oleh
Indra Sosrodjojo
1
Indra@andalsoftware.com
Analisis Application Domain
Requirements
for use
Problem
Domain
Analysis
Model
Application
Domain
Analysis
Component
Design
Specifications of
components
Specifications of
architecture
Architectural
Design
2
Application Domain
User
Computerised
System
User
Application Domain
3
(Mathiassen et al, 2000)
Relative Stability of
System Components
Stable properties
Model
Problem
Domain Analysis
Transient properties
Function
Interface
Application
Domain Analysis
The relative stability is why we analyse the problem domain
before the application domain.
4
Aktivitas utama dalam
Analisis Application Domain
System Definition
and model
Interfaces
Usage
Iterate
Functions
Requirements
(adapted from Mathiassen et al, 2000)
5
Analisis Application Domain
Activity
Usage
Content
How does system interact  Use Case
with people and other
 Actor
systems?
Functions What are the system’s
information processing
properties?
Interfaces What are the target
system’s interface
requirements?
6
Concepts
 Function
 Function type
 User interface
 System
interfaces
 Usage context
Prinsip dari
Analisis Application Domain
 Tentukan application domain dengan use cases.
 Kolaborasi dengan users.
7
Usage Analysis
8
Aktivitas utama didalam
Analisis Application Domain
System Definition
and model
Interfaces
Usage
Functions
Requirements
(Mathiassen et al, 2000)
9
Sub-activitas didalam
Usage Analysis
System definition
Use cases
and actors
Evaluate
systematically
Find actors
and use cases
Explore
patterns
(Mathiassen et al, 2000)
10
Actors dan Use Cases
 Actor: abstraksi dari user atau sistem lain yang berinteraksi
dengan target sistem
 Actors adalah orang yang mengerjakan pekerjaan
 Use case: pola interaksi antara sistem dan aktor didalam
application domain
 Ikuti proses bagaimana pekerjaan akan dilakukan
11
Contoh Actor Table
Use Cases
Actors
Account
owner
Creditor
Payment
X
X
Cash Withdrawal
X
Money transfer
X
Account information
X
Credit Information
X
Administrator
X
X
X
X
Registration
X
Monitoring
X
Fault processing
X
12
Liquidity
Monitor
X
Actors vs Classes
Use Cases vs Events
 Apakah actor sama dengan class ?
 Apakah use case sama dengan event ?
 Tidak! Class dan event ada didalam problem domain - sedangkan
Actors dan use case ada didalam application domain.
 Apakah actors juga class didalam the model?
 Apakah events juga use case ?
13
Dasar Usage Analysis
 Tentukan application domain dengan use cases.
 Evaluasi use case bekerja sama dengan users.
 Perhatikan perubahan organisasi yang dapat mengubah
application domain
14
Menentukan Actors dan Use Cases
 Berdasarkan pekerjaan dan pembagian pekerja
 Identifikasikan actors
 Perhatikan seseorang yang berperan dengan peran yang sama
 Terapkan pada sistem seperti pada orang atau user
 Menerangkan actor
 Masukan tujuan actor, karakteristik dan contoh
 Jelaskan use cases
 Gunakan statecharts dan atau dengan kalimat
 Buatlan sederhana dan tanpa detil yang tidak diperlukan
15
Analisis Pekerjaan
 Perlu mengerti hubungan dari sistem pada application
domain
 Pekerjaan apa yang ada didalam application domain?
 Bagiaman pembagian pekerjanya?
 Bagaimana pekerjaan yang berbeda dapat dihilangkan ?
 Jangan terlalu menekankan cara kerja sekarang
 Hasil utama adalah daftar yang lengkap dari pekerjaan di
application domain
16
Contoh Penjelasan tentang Actor
Account Owner
 Goal: A person who owns an account. The account owner’s basic
need is to make payments with their plastic card.
 Characteristic: The system’s users include many and very different
account owners.
 Examples: Account owner A is insecure in the use of a plastic card
as a form of payment. A only withdraws money from the ATM in
emergency situations.
 Account owner B is technologically curious and uses the system
often, optimally, and to the limit of its abilities.
17
Contoh Statechart for ‘Cash
Withdrawal’ Use Case
Insert
card
Card inserted
Prompt
for
code
Awaiting code
Enter code
Rejected
Code entered
Code accepted
Cancel
Awaiting amount
Payment
Amount approved
Approve amount
Choose amount
Amount not approved
Amount chosen
(Mathiassen et al, 2000)
18
Example Text Description for ‘Cash
Withdrawal’
 Use Case: cash withdrawal is started by the account owner, when they wish to use
their credit card to withdraw cash from an ATM. The account owner inserts their
card into the ATM, and are then requested via the screen to type their PIN code. The
screen will either show a polite denial, the card will be ejected from the ATM and
the process will be canceled; or the screen will show a menu requesting the account
owner to choose an amount of money by typing on the ATM’s keyboard. A new
screen picture requests the account owner to approve the transaction. If the
transaction is not approved the account owner is again requested to type an amount.
Otherwise the use case ends by the ejection of the card, and the desired amount of
money being paid.
 Objects: (to be added later)
 Functions: (to be added later)
19
Use Case dan Struktur Actor
 Perlu menghubungkan use case dan actor satu sama lain
 Dapat dilakukan dengan ‘Actor table’, tetpai hanya untuk
associations
 Dapat juga dilakukan dengan ‘Use Case Diagrams’
 Mempunyai actors dan use cases
 Gunakan structure untuk menghubungkan antara actor seperti
pada ‘Class Diagram’
20
Contoh Actor Table
Use Cases
Actors
Account
owner
Creditor
Payment
X
X
Cash Withdrawal
X
Money transfer
X
Account information
X
Credit Information
X
Administrator
X
X
X
X
Registration
X
Monitoring
X
Fault processing
X
21
Liquidity
Monitor
X
Groups of Use Cases
Customer
involved in all
deposit use
cases
Deposit
Get customer
information
Bank employee involved in
2 of 3 deposit use cases
Deposit
Loan
Bank Employee
Cash withdrawal
Customer
Customer involved in only
payment loan use case
22
Establishment
Maintain
Payments
Bank employee
involved in all
loan use cases
Explore Use Case Patterns
 The procedural pattern
 General pattern for insuring that steps in a process or a
sequence of rules are followed
 The material pattern
 General pattern when there are few rules to follow, i.e. actions
can be taken in any order
 May possibly have some small action sequences specified as side
patterns
23
Pola Procedural
action 1
State 1
action 2
State n
action n+1
24
Can’t do action 2 unless
action 1 is already done
The Material Pattern
start action
Material pattern is
for ‘artisan like’
materials that can be
manipulated in any
desired order.
E.g. diagrams, text,
drawings being
constructed.
action 1
action 2
General
State
final action
25
Actions 1 & 2 can be
done in any order
Process n
Process n+1
Processes must be
completed before returning
to general state
Evaluate Systematically
 Carefully study descriptions for mistakes and inconsistencies.
 Test use cases to see if true in practice, e.g. using prototypes
to experiment.
 Evaluate the social changes in the application domain.
26
Evaluation Criteria
 Use cases should be simple, constitute a coherent whole.
 The description of actors and use cases should provide
understanding and overview.
 Use cases should be described in enough detail to enable
identification of functions and interface elements (our
next topic in application domain analysis!).
27
Experimenting with Prototypes
 Notation of use cases doesn’t allow successful verification by
the users
 Construct experiments so that
 Use future users for testing
 Make environment as realistic as possible
 Be sure to follow five phases covered earlier: planning,
development, preparation, test, and summarising
28
Principles of Usage Analysis
 Determine the application domain with use cases.
 Need cooperation between users and developers.
 Both an analytical and a creative activity.
 Evaluate use cases in collaboration with users.
 Best way is with prototypes.
 Can be paper and pencil exercises.
 Assess social changes in the application domain.
 Rethink the business processes.
 Avoid work-related problems and unnecessary human adjustments.
29
Tutorial: Usage Analysis
 Individually, brainstorm a list of use cases and actors for the
Paul’s Pools example.
 As a class, compare and discuss your lists and agree on a
refined list.
 Identify which use cases are performed by which actors.
 With the rest of the class, choose one use case and specify it.
30
Function Analysis
31
Aktivitas utama didalam
Application Domain Analysis
System Definition
and model
Interfaces
Usage
Next, we’ll look
at this activity
Functions
Requirements
(Mathiassen et al, 2000)
32
Functions
“A facility for making a model useful for actors.”
 Express the intent of the system
 Express what is going to happen, but not how
 Need to find the right level of detail,
 Too general is too uncertain
 Too detailed is inefficient
 Inexperienced developers need more detail
33
Sub-activities didalam
analisa Function
System
Definition
Evaluate
critically
Find
functions
Use Cases
34
Specify
complex
functions
Function list
Contoh Function List
Planning
35
Make schedule
Very complex
Update
Query possible
reservations
Make reservation
Complex
Read
Medium
Update
Cancellation
Simple
Update
Tipe dari Functions
 Ada 4 tipe function utama AD
I
F M
I
AD
*
 Tipe Function : Kalsifikasi
dari suatu function
berdasarkan interaksi
antara component dan
context dari sistem
*
PD *
Update
I
AD
F M
PD
Signal
I
AD
F M
*
*
PD
Read
PD
Compute
Effect of processing
* Initiative
36
F M
Mencari Functions
 Mencari functions dengan memeriksa classes, events, and
use cases
 Analisis secara sistematis dengan menggunakan empat
tipe function
 Hasil dari sub aktivitas adalah daftar kebutuhan function
dari system
 Termasuk didalamnya name, type, dan assessment dari
kompleksitas dari setiap function : simple, medium, complex,
or very complex
37
Update Functions
I
AD
F M
*
PD *
Update
 Activated as a consequence of an
event in the problem domain
 Results in a change in the state of
the model
38
 How is the event observed and
registered? In which use cases?
 How can the use cases be
supported by updating functions?
 Which objects, attributes, and
structures are affected by the
event? What requirements for
update functions?
Read Functions
I
AD
F M
*
PD
Read
 Activated by a need for
information by an actor
 As a result, computerised system
displays parts of the model to the
actor
39
 What do the actors need to
know about the state of the
model (represents the problem
domain)?
 About which objects and
structures in the model do the
actors need information?
 What ‘readings’ do these give
rise to?
Compute Functions
I
AD
F M
*
PD
Compute
 Activated by a need for
information by an actor
 The computerised system
computes and displays results to
the actor
40
 Which computations, not
necessarily based on the model,
do the actors need to have
carried out?
 Does the computational basis
come from the actors, the
model, or both?
 Which computations form
complete wholes in the use
cases?
Signal Functions
AD
I
F M
*
PD
Signal
 Activated by a change of state in
the model
 Results in either displaying the
signal to the actors or
automatically intervening in the
problem domain
41
 What are the critical states for the
model?
 What is their significance? What
are the consequences when they
occur?
 How should the function identify
that a critical state has been
reached?
 How should the signal be reported
to the AD or PD? How reliable and
strong?
Example Function List
Planning
42
Make schedule
Very complex
Update
Query possible
reservations
Make reservation
Complex
Read
Medium
Update
Cancellation
Simple
Update
Menentukan Complex Functions
 Yang termasuk complex function melibatkan beberapa tipe
function
 Beberapa format :
 mathematical expression
 algorithm in structured language
 functional partitioning in the function list
43
Contoh
Algorithmic Specification
Query possible reservations:
given time or date or employee-name
search objects in time period-available and select those
who belong to employee-name, if known
have date, if known
cover point in time, if known
result objects of time period-available that fulfill the
criteria
44
Contoh Functional Partitioning
Planning
Make schedule
Create six-week period
Create standard distribution
for employee
Use standard distribution for
an employee
Adjust the distribution of
employees in a week
45
Very complex
Simple
Medium
Simple
Medium
Update
Evaluate Systematically
 Work with the function list itself
 Functions must be mutually consistent
 Each function must be at an appropriate level of abstraction
 Ensure total functionality is consistent with the list
 prototype the usage - experiment
 review questions above for each type of function
 compare with system definition and models
 Ensure functions are not to general/vague or too detailed
46
Prinsip dari analisis Function
 Identify all functions.
 A complete list is very important
 Specify only complex functions.
 Check consistency with use cases and the model.
 Checking this can reveal insufficient analysis
47
Interface Analysis
48
Aktivitas utama dalam
Analisis Application Domain
System Definition
and model
Interfaces
Usage
Functions
Requirements
(Mathiassen et al, 2000)
49
Terminologi
 Interface: Fasilitas yang membuat model sistem dan function
dapat berinteraksi dengan actors.
 User interface: Interface untuk users.
 System interface: interface ke sistem lain.
 Usage context: The application domain characterized by actors
and use cases.
50
User Interface
 Are very important: they can make or break system use
and benefit realisation.
 Needs to carefully fit the usage context.
 Need to be designed carefully - small details multiply
difficulties with usage.
 Need to account for the different kinds of users with
different skills and capabilities.
 Very difficult to design without feedback -generally must
be tested with users.
51
Systems Interface(s)
 May need interfaces for non-human actors, i.e. other
systems
 Not commonly used for administrative systems
 More common for monitoring & control systems
 direct sensors in the environment - e.g. temperature
 direct intervention, e.g. motors, switches
 may also input or output from other computer systems
 Need to design and make sure that these technical
connections can be realised
52
Sub-activities in
Interface Analysis
Function
list
Class
diagram
Explore
patterns
Determine
interface
elements
Use cases
Evaluate interface
elements
Describe interface
elements
Description of
interfaces
(Mathiassen et al, 2000)
53
Tailor Usability to Context
 Usage is relative to usage context
Usage context
54
Desired
properties
Technology
 Routine tasks
 Efficient
 Fixed, well Reliable
structured tasks
 Activation of functions
 Fixed defined dialogue
 Menu and command
driven manipulation
 Non-routine
 Flexible to use
tasks
 Easy to learn
 Varying problem new functions
solving tasks
 Manipulation of objects
 Loosely defined dialogue
 Direct manipulation
Study the Usage Context
 Study both human actors and use cases
 Does the individual user solve several tasks in parallel?
 Does the user move physically while working?
 Is the work often interrupted?
 Are certain use cases significantly different from the typical use
cases?
 Do certain work tasks require a quick response from the
computerized system?
 How is it ensured that the users notice when the computerized
system performs a signal function?
55
Explore User-Interface Patterns
 A user interface usually mixes several patterns or styles
 Four main patterns/styles
 menu
 form filling
 command language
 direct manipulation
 (also natural language)
56
Menu Selection
 Advantages
 Shortens learning
 Risk of too many menus
 Reduces key-strokes
 Slows the frequent user
 Structures decision making
down
 Consumes screen space
 Requires rapid display rate
 Allows easy support of
error handling
 High level tools allow for
easy programming
57
 Disadvantages
Form Filling
 Advantages
 Simplified data entry
 Requires modest training
 Makes assistance convenient
 High level tools allow for
easy programming
58
 Disadvantages
 Consumes screen space
Command Language
 Advantages Flexible
 Appeals to “power” users
 Poor error handling
 Supports user initiative
 Requires extensive training
 Convenient for creating
user-defined macros
59
 Disadvantages
Direct Manipulation
 Advantages
60
 Disadvantages
 Immediately visible result
 Effort required to develop
of interaction
 Useful for both casual and
frequent users
 Can be extremely efficient
 Difficult to invent
meaningful icons, symbols,
etc., unless can rely on
standard objects
Dialog Style: Function-Oriented vs
Object-Oriented
 Is the interface primarily based on functions or objects? Need
both, but which choose first?
 I.e., does the user choose the function first, then choose the object or
vice versa?
 Function-oriented dialogues are better for routine,
automated work
 Object-oriented ones are better for varied individual work
tasks as they give more flexibility
 But, usually require more development time and effort
61
Some Guidelines
 A dialogue needs to be simple, natural, and consistent.
 Requirements placed on the users’ memory need to be
minimal.
 Feedback must be informative and constructive.
 Errors must be prevented.
 Detailed discussion is beyond the scope of this unit.
62
Determine User-Interface Elements
 Representations of objects in the model
 Many possibilities: icons, fields, tables, diagrams, windows
 Need a clear & consistent system of representations
 Activation of functions
 Buttons, menu screens, pull-down/pop-up menus
 Also need support for visualisation and feedback
 Needs to be consistent and fit within the dialog pattern/style
 Result is a list of user-interface elements
63
Describe Interface Elements
 User Interface:
 General effect: colours, fonts, types of menus, types of icons,
default positions
 Navigation: dialog linkages between buttons, menus, screens,
windows, etc.
 Computer screens/windows/forms, etc.: layout, interactivity,
consistency
 Outcome of activity is screen/form designs, navigation diagram
and other descriptions
64
Example Navigation Diagram
(Partial)
Start
Miniature
of screen
or window
65
Exit
Commands,
menu
selections,
or buttons to
change
screens
or windows
Evaluate the User Interface
 A User Interface cannot be constructed bottom up without
experiments using prototypes.
 Should be a carefully controlled process using the five subactivities.
 Planning needs to lead to concrete evaluation and quick
development with efficient tools.
 Preparation needs to determine how collaborate with users,
ensure realism, and select good example tasks that enhance
feedback.
66
Explore Systems Interface Patterns
 Consider what/how data should be sent to and received from
other systems (if any)
 Other systems may be
 simple external devices: sensor, switch, or motor use simple
read or activate device patterns
 complex computer systems: need a communication protocol
which may be supplied or need to be designed
67
Read External Device Pattern
 Read either regularly or dependent on an event
Device
connection to
external device
state
read
Memory
1
1
time
value
measurement
latest-value
 Memory object can just be the model object
68
Interaction Protocol
 A protocol defines command facilities supporting the
possible use cases for a system by another
 Is agreed upon by designers of the two systems (unless
one has already been designed/built!)
 Specify a pattern for interaction using a list of commands
for each side and their expected responses
 Separate protocol item named for each command
 E.g. Request some info or Prepare to accept info
 Commands may check the state of the other system
69
Determine and Describe the
Systems Interface Elements
 What other computer systems will the system be
connected to and exchange information with?
 What protocol(s) will be needed?
 Will the system be connected directly to the problem
domain through external devices?
 What external device read or write interfaces are needed?
 Result is a list and specification of each.
70
Evaluate System Interfaces
 Protocols can be tested on pencil and paper by working
through use cases
 Ultimate test is that the physical connections actually work
 If there is any doubt, these connections need to be tested as
early as possible
 Build and test technical feasibility prototypes
71
Principles of
Interface Analysis
 Tailor usability to the application domain
 need to know who the users are and in what situations the
computerised system will be used
 Experiment and iterate
 interfaces are complex and interact with users in ways that can’t
be anticipated
 experiments need to be planned, efficient, and realistic - and
likely will be repeated
72
Principles of
Interface Analysis (2)
 Identify all interface elements
 Important not to leave anything out!
 Details can be supplied/determined later, as long as the basic
structure is clear and coherent
73
Learning Objectives
 Understand the basics of how to determine a strategy for
using OOA&D
 Understand what & how documentation should be produced
during OOA&D
 Understand what makes good analysis documents and good
design documents
74
Concrete Project Strategy
Formulation
 Development methods provide advice and ideas for work
practices on an actual (or concrete) system development
project
 Good, efficient development work requires that effort is
concentrated on the most difficult task
 To do so, you must determine a strategy that identifies
and deals with the most difficult task, and reconsiders
the strategy as the project progresses
75
Terminology
 Requirement: A system’s externally observable behavior
 Conditions: The technical, organisational, and human
opportunities and limits involved in solving a task
 Strategy: A general approach for performing a task
76
Principles
 Tailor the strategy
 Identify the difficult requirements and conditions
 Maintain degrees of freedom
77
Sub-activities in Strategy
Construction
Existing
documentation
Analysis and
design strategy
Formulate
strategy
Characterise
the task
Evaluate
difficulties
78
Guiding
Object-oriented
analysis and design
Characterise the Task
 Problem domain: Are you familiar with the type target system?
 Application domain: Are you familiar with the user organisation?
 Technical platform: Which technology will the system be implemented
on?
 Project organisation: How qualified are the developers? How good are
the development conditions?
 Special aspects:Which special conditions apply to this task?
Use the checklist in the text as inspiration for factors to consider.
79
Evaluate Difficulties
 How great are the difficulties related to analysis of the
problem domain?
 How great are the difficulties related to analysis of the
application domain?
 How great are the difficulties related to the design of the
system’s architecture?
 Use the checklist in the textbook as inspiration for ratings
areas.
80
Design the Strategy
 Put highest emphasis on areas with great difficulty.
 Initiate activities in areas with great difficulties early in the
process.
 Make critical decisions first and less critical decisions later in the
process.
 Design the strategy to ensure coordination of decisions.
 Include requirements management in the strategy.
 Possibly affect the conditions for the development in order to
enable a satisfactory strategy.
Result is a project plan including all of the above.
81
Principles of
Strategy Construction
 Tailor the strategy
 Relate the requirements to the technical and organisational
realities.
 Identify the difficult requirements and conditions
 Arising from disparities in the above.
 Maintain degrees of freedom
 Other problems are inevitable, so preserve breathing space.
82
Dokumentasi
83
Terminologi
 Analysis document: Presentasi yang logis dari hasil analisis
 Dapat dijadikan sebagai dasar perjanjian
 Dapat dijadikan acuan pada saat implementasi
 Design document: Presentasi yang logis dari hasil design
 Dapat dijadikan acuan pada saat implementasi
84
Pentingnya
Analysis Document
 A work tool in which sub-results can be collected and structured
as they are produced.
 A control tool that can be used to decide if the analysis work
progresses sensibly and actually leads to determination of the
requirements to the computerized system.
 A basis for the customers’ and the users’ decision about whether
they want the outlined computerized system at the expected cost.
 A baseline for the ensuing work with design and realization.
85
Pentingnya
Design Document
 A work tool in which design decisions can be collected and structured
as they are made.
 A control tool to measure the progress of the design work. Does the
document still contain essential uncertainties in relation to the
conditions for the system’s realization?
 An agreement tool that retains the agreement about the computerized
system’s design. It should retain agreements between the designers
during the design work, which should communicate all essential
decisions to the developers who will realize the system.
86
Dokumentasi yang Baik
 Harus ditulis dengan bahasa umum, dan tatabahasa yang
baik serta jelas
 Dapat dibuat dengan menambahkan gambar, daftar dll
 Gambar dan daftar tidak berdiri sendiri tetapi tidak perlu
dijelaskan terlalu detil.
 Dokumentasi harus singkat tetapi jelas
 Jangan menulis program untuk programmer atau desain untuk
desainer
87
Prinsip
Domukentasi
 Use technical prose supplemented by formalisms.
 Should be concise and of high quality
 Should only describe the essential
 Retain results and decisions continuously.
 Create documentation along the way to ensure quality and make
progress visible
 Chart progress through documented results.
 Documentation provides a basis for measurement
88
Phases of OOA&D
System Choice
(Pre-analysis)
System
Definition
Requirements
for use
Problem
domain
analysis
Model
Application
domain
analysis
Component
design
Specifications for
components
Specifications for
architecture
(adapted from Mathiassen et al, 2000)
89
Architectural
design
Now concerned
with this area of
activity and
its product
Dua bagian dari Architecture
 Component architecture: struktur sistem yang terdiri dari
componen yang saling berhubungan
 Process architecture: Struktur eksekusi dari sistem terdiri dari
interdependent processes
90
Component and Process
Architectures
Component Architecture:
Process Architecture
 Classes
 Objects
 Stable aspects
 Dynamic aspects
 Related components
 Coordination of processes
 Logical level
 Physical level
 Structure for descriptions
 Structure for execution
(Mathiassen et al, 2000)
91
Design of Architecture
Activity
Content
Concepts
Criteria
How are the conditions
and criteria for design?
Criterion
Components
How is the system
structured into
components?
Component
architecture
Component
Processes How are the system’s
processes distributed
and coordinated?
92
Process Architecture
Process
Prinsip
Architectural Design
 Define and prioritise criteria.
 various criteria besides the functional requirements
 Bridge criteria and technical platform.
 meet criteria by making use of technical facilities
 Evaluate designs early.
 eliminate ambiguity early to enhance productivity
93
Some Good Design Qualities
 The system models the parts of the problem domain that
were agreed upon.
 The system’s functions correspond to the requirements
from the application domain.
 The interface implements the described interaction.
 The technical platform is used effectively.
 The system can be adapted to new requirements and needs.
94
Design Criteria
 We don’t judge just by how well a system meets criteria;
not meeting one criterion can be critical
A good design has no major weaknesses
A good design balances several criteria
Criterion: A preferred property of an architecture
 Need to define priorities among criteria and evaluate
them
95
Component Architecture
96
Terminologi
 Component Architecture: Struktur sistem yang terdiri dari
component yang saling berhubungan
 Component: Kumpulan dari bagian program yang keseluruhan
proses terdefinisi
 Seperti cluster
 Terdiri dari classes dan atau components lain
97
Prinsip
 Reduce complexity by separating concerns
 Aids comprehendibility, maintainability
 Reflect stable context structures
 Interface at the top, model at the bottom
 Reuse existing components
 Reduces development effort
 Improves design comprehensibility
98
Sub-activities in Component
Architecture Design
Explore architectural
patterns
Criteria
Identify
components
Define
subsystems
Class diagram
Component
specification
Use patterns and
components
(Mathiassen et al, 2000)
99
Explore
Architectural Patterns
 Patterns are a useful guide to design
 Some patterns have been proven useful
 Layered architecture
 idea is from the ISO OSI network model
 A generic architecture
 from the authors
 based on the Model Function Interface framework
 Client-server architecture
 should consider whenever distribute a system
100
Layered Architecture
«component»
Layer i+1
Upward interface
«component»
Layer i
Downward interface
«component»
Layer i-1
101
Generic Architecture
«component» Interface
«component»
«component»
User Interface
System Interface
«component»
Function
«component»
Model
«component» Technical platform
102
«component»
«component»
«component»
UIS
DBS
NS
Generic Architecture (2)
 Can further divide functions into two kinds and group into
components differently
 Task-related functions
 Model-related functions
 Can split functions, or place some with model component
 For very simple system, may not need the function
component at all
103
Client-Server Architecture
«component»
«component»
«component»
Client1
Client2
Clientn
«component»
Server
(Mathiassen et al, 2000)
104
Client-Server Architecture (2)
 Components are a server and a number of clients
 Server provides a collection of operations (or services!) to
the clients
 Clients use the server independently
 Potentially a good architecture whenever distribute a system
geographically
 Need to decide form of distribution of system’s parts
between client and server
105
Five Forms of Distribution
Client
Server
Architecture
U
U+F+M
Distributed presentation
U
F+M
Local presentation
U+F
F+M
Distributed functionality
U+F
M
Centralised data
U+F+M
M
Distributed data
(Mathiassen et al, 2000)
106
Define Subsystems
 For large systems, often need to split the system into
subsystems
 Allows division of work so that design and building of
subsystems is independent (except for any interfaces
between them)
 Each subsystem may be a system in its own right, with
interface, function, and model components
 Must design the architecture of each subsystem
107
Example Subsystems and
(Sub)system Interfaces
«component» Subsystem A
108
«component» Subsystem B
«component»
«component»
«component»
«component»
User Interface
System Interface
System Interface
User Interface
«component»
«component»
Function
Function
«component»
«component»
Model
Model
Identify Components
 Design the architecture for each system or subsystem by breaking
into components
 Begin with 3-tiered architecture or a pattern
 Extend basic architecture by examining model, function, and
interface design concerns
 Extend further by finding useful existing components
 Generally good to encapsulate the extended technical platform
109
Model Design Concerns
 Responsibility:
 Contextual
issues:
 Exemplars:
 Special needs:
110
The problem domain model
Incohesive or complex
problem domains
Accounting, reservations,
inventory, administration
Databases
Function Design Concerns
 Responsibility:
The functionality on the model
Need for incohesive or complex
 Contextual issues:
functionality
 Exemplars:
Payroll, signal processing, cruise
control
 Special needs:
Model-related functions,
application-related functions,
cryptography
111
Interface Design Concerns
 Responsibility:
Interaction between functions
and actors
 Contextual issues: Incohesive or complex actors or
 Exemplars:
usage
Browsing, games, presentation
 Special needs:
monitoring
Screens, windows, buttons,
print-outs, devices,
communications
112
Using Components
 Can obtain and use components from a number of sources
 Another existing system
 Earlier version of system
 Standard purchased components - software library
 Need to encapsulate these to limit impact if later change
chosen components
113
Specifying Components
 Complex components should be specified in detail.
 May attach supplemental notes to class diagrams.
 Good to summarise each component’s
 Responsibility (service it provides)
 Dependency (on other components)
 Relationship to the system context
114
Review of Principles
 Reduce complexity by separating concerns
 Aids comprehensibility, maintainability
 Reflect stable context structures
 Interface at the top, model at the bottom
 Reuse existing components
 Reduces development effort
 Improves design comprehensibility
115
Application Domain Analysis in Context of
OOA&D Activities
Requirements
for use
Analysis of
problem
domain
Model
Analysis of
application
domain
Design of
components
Specifications for
components
Specifications for
architecture
(adapted from Mathiassen et al, 2000)
116
Design of
architecture
Component and Process
Architectures
Component Architecture:
Process Architecture
 Classes
 Objects
 Stable aspects
 Dynamic aspects
 Related components
 Coordination of processes
 Logical level
 Physical level
 Structure for descriptions
 Structure for execution
(Mathiassen et al, 2000)
117
Process Architecture
118
Main Activities in
Architectural Design
Analysis
document
Component
architecture
Criteria
Process
architecture
Architectural
specification
(Mathiassen et al, 2000)
119
Introduction
 Now concentrate on objects and their involvement in
processes
 Need to coordinate when have multiple processes with
shared resources
 Processors
 Program components
 External devices
 Results:
 Deployment diagram showing processors, assigned components,
and active objects
 Outline of solutions for coordination mechanisms
120
When & Why
 Not a significant activity for a simple system with a single
process, e.g. a stand-alone system
 Critical for large systems, especially monitoring and control
systems, & embedded systems
 May wait to begin this activity until component architecture
and components are nearly complete
 May start this activity early with exploratory and
experimental work, which heavily influences components
121
Terminology
 Process Architecture: A system-execution structure
composed of interdependent processes
 Process: A collection of operations that are executed in a
bounded and linked sequence
 Processor: A piece of equipment that can execute a program
122
Terminology (2)
 Program Component: A physical module of program code
 Active object: An object that has been assigned a process
123
Processes, Active Objects, and
Shared Objects
Process
1
Object
1
o1
o2
Potential conflict
over shared
program
component
Object 3
o5
o6
Object 2
o3
Process 3
Process 2
Active object
because it starts
a new process
124
Object
4
o4
o7
o8
Object 5
o9
Process 4
o10
Concurrency
 True concurrency:When two or more events in the system’s
context can occur at the same time and processes must
support this (e.g. multiple users)
 Random concurrency:When two or more operations are
designed to be executed at the same time (e.g. print in
background)
 Don’t have any choice about the former
125
Principles
 Aim at an architecture without bottlenecks
 would slow down the system and cause problems
 Distribute components on processors
 Coordinate resource sharing with active objects
126
Sub-activities in
Process Architecture Design
Class diagram and
component specifications
Identify shared
resources
Distribute program
components
Explore distribution
patterns
127
Select
coordination
mechanisms
Deployment
diagram
Explore coordination
patterns
Distribute Program Components
 Different components need to be placed on individual
processors
 First, separate out any active objects from passive program
components
 Second, determine the available processors
 Distribute the program components and active objects onto
the processors
128
Explore Distribution Patterns
 Patterns for how components are placed on processors
 The centralised pattern: Centralised data and functionality, thin
client, but low robustness
 The distributed pattern: Replicated data, server only broadcasts
updates, robust, but potential data inconsistencies
 The decentralised pattern: Partitioned data, low inconsistencies,
more diversity/complexity
129
Identify
Shared Resources
 Processor: Two or more concurrent processes that should be
executed on the same processor
 External Devices: Two or more concurrent processes use the
same external device
 Component: Two or more concurrent processes call operations
on objects in the same component
130
Example Deployment Diagram:
Airline Check-in
Active objects
Processor
External
devices
(Mathiassen et al, 1999)
131
Finding Bottlenecks
 Processors: What is the relationship between the capacity of each processor
and the needs of the active objects assigned to it?
 External Devices: What is the accessibility, capacity, and load of the
different external devices in the interface?
 Data Storage: Which parts of the model need to be stored on which
storage media?
 System/Network Connections: What is the capacity and load of the
system’s connections?
132
Overcoming Bottlenecks
 Two options:
 Change the design and the distribution of the components onto
the available processors
 Enhance the platform with more processors or more powerful
processors
133
Select
Coordination Mechanisms
 Many operating systems and technical platforms provide
mechanisms to control sharing
 Varies substantially from platform to platform
 So need to be sure in each case!
 If not, we have to solve it ourselves by developing our
own coordination mechanisms
 Generally rely on active object that controls the sharing
 Can make use of generic patterns
134
Coordination Mechanisms
 Generalised patterns of coordination:
 Dedicated monitor ensuring atomic access to shared resources.
 Centralized task dispatching for coordination of all concurrent
processes. (e.g., event loop)
 Subscription to state changes for initiation of processes in
opportune situations.
 Asynchronous exchange of data to avoid unnecessary delays with
read and write operations.
135
Prinsip
Architecture Design
 Aim at an architecture without bottlenecks
 Slows down the system and causes problems
 Distribute components on processors
 Decision can reduce potential bottlenecks
 Coordinate resource sharing with active objects
 Use the technical platform or design your own mechanisms
136