Matakuliah
Tahun
Versi
: M0446/Analisa dan Perancangan Sistem Informasi
: 2005
: 0/0
Pertemuan 13
Criteria System
1
Learning Outcomes
Pada akhir pertemuan ini, diharapkan mahasiswa
akan mampu :
• Memberikan contoh tentang kriteria yang baik
untuk suatu rancangan program
2
Outline Materi
• Parameter Kualitas Desain
• General Design Criteria
• Arsitektur Diagram
3
Aktivitas Utama didalam Desain
Arsitektur
4
Beberapa kualitas desain
yang baik
• Sistem memodel bagian dari problem domain yang
sudah disetujui bersama dengan user
• Fungsi dari sistem correspond pada requirement dari
application domain
• Interface merupakan implementasi dari interaksi yang
telah di terangkan.
• Platform teknis digunakan secara efektif
• Sistem dapat diadaptasi terhadap requirement baru dan
kebutuhan.
5
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
6
Sub-activities in Criteria
7
General Design Criteria
Useable
Secure
Efficient
Correct
The system’s adaptability to its organizational, workrelated, and technical contexts
The precautions against unauthorized access to data
and facilities
The economical exploitation of the technical
platform’s facilities
The fulfillment of requirements
Reliable
The fulfillment of the required precision in function
execution
Maintainable The cost of locating and fixing system defects
8
General Design Criteria (2)
Testable
Flexible
The cost of ensuring that the deployed system
performs its intended function
The cost of modifying the deployed system
Comprehensible
Reusable
The effort needed to obtain a coherent
understanding of the system
The potential for using system parts in other related
systems
Portable
The cost of moving the system to another technical
platform
Interoperable The cost of coupling the system to other systems
9
General Design Criteria (3)
• The textbook emphasises three of these
with its Principle …
A good design is usable, flexible, and
comprehensible.
10
Analyse Specific Conditions
• Each situation is different and has different
specific requirements which constrain
design
– Technical: hardware, software, reuse,
available components
– Organisational: contracts, related plans, work
division
– Human: Staff experience and competence
11
Prioritising Design Criteria
Criterion
Very
Less
Important Important important Irrelevant
Easily
fulfilled
Useable
Secure
Efficient
Correct
Reliable
Other




12
Evaluating Design Criteria
• Two forms of evaluation
– Reviews
– Experiments (prototypes)
• Other questions need to be answered
–
–
–
–
Which parts should be reviewed?
Which parts should be prototyped?
Who will participate in evaluations?
When will the evaluations take place?
• Need to plan now for later evaluations!
13
Principles of Criteria
• A good design has no major weaknesses.
• A good design balances several criteria.
– some criteria may turn out to be conflicting!
• A good design is usable, flexible, and
comprehensible.
14
Aktifitas utama didalam Desain Arsitektur
15
Terminology
• Component Architecture: A system
structure composed of interconnected
components
• Component: A collection of program parts
that constitutes a whole and has welldefined responsibilities
– Like a cluster
– Composed of classes and/or other
components
16
Principles
• 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
17
Sub-aktifitas didalam desain arsitektur
komponen
18
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
19
Arsitektur Lapisan
20
Arsitektur Turunan (generik)
21
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
22
Arsitektur Client-Server
23
Arsitektur Client-Server (2)
• Komponen adalah server dan beberapa dari client
• Server memberikan kumpulan dari operation (atau
services!) pada client
• Client menggunakan server secara independen
• Potentially a good architecture whenever distribute a
system geographically
• Bentuk distribusi dari bagian sistem harus diputuskan
antara client dan server
24
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)
25
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
26
Example Subsystems and
(Sub)system Interfaces
«component» Subsystem A
«component» Subsystem B
«component»
«component»
«component»
«component»
User Interface
System Interface
System Interface
User Interface
«component»
«component»
Function
Function
«component»
«component»
Model
Model
(Mathiassen et al, 2000)
27
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
28
Model Design Concerns
• Responsibility: The problem domain
model
• Contextual
Incohesive or complex
issues:
problem domains
• Exemplars:
Accounting, reservations,
inventory, administration
• Special needs: databases
29
Function Design Concerns
• Responsibility: The functionality on the
model
Need for incohesive or
• Contextual
complex
functionality
issues:
Payroll, signal processing,
• Exemplars:
cruise control
Model-related functions,
• Special needs: application-related
functions, cryptography
30
Interface Design Concerns
• Responsibility: Interaction between functions
and actors
Incohesive or complex actors
• Contextual
or usage
issues:
Browsing, games,
• Exemplars:
presentation monitoring
Screens, windows, buttons,
• Special needs: print-outs, devices,
communications
31
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
32
Specifying Components
• Complex components should be specified
in detail.
• May attach supplemental notes to class
diagrams.
• Good to summarize each component’s
– Responsibility (service it provides)
– Dependency (on other components)
– Relationship to the system context
33
34