Matakuliah
: M0126 - Analisis dan Perancangan Sistem
Informasi Lanjut
Tahun
: 2009 - 2010
Criteria And Component Diagram
Pertemuan 0304
Learning Outcomes
Pada akhir pertemuan ini, diharapkan mahasiswa
akan mampu :
• Mahasiswa dapat membuat Criteria (C4)
• Mahasiswa dapat membuat diagram / skema component
architecture class (C4)
Outline Materi
•
•
•
•
•
Criteria
General design criteria
Reduce complexity by separating concerns
Reflect stable context structures
Reuse existing components
Criteria
• Tujuan dalam kita membuat kriteria adalah menentukan
dalam sistem yang akan kita buat memiliki kriteria apa
yang dibutuhkan oleh user
• Untuk itu diperlukan wawancara kepada user untuk
mendapatkan kriteria yang dibutuhkan oleh sistem
• Membuat Table Criteria
03 - 04 / 02 - 35
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)
Architectural
design
03 - 04 / 03 - 35
Architectural Design
Purpose

To structure a computerized system
Concepts





Criterion : a preferred property of an architecture
Component architecture : A system structure
composed of interconnected components
Process architecture : A system-execution structure
composed of interdependent process
03 - 04 / 04 - 35
Architectural Design (Cont’d)

Principles
 Define and prioritize criteria
 Bridge criteria and technical platform
 Evaluate designs early

Result
 Structures for a system’s components and
 process
03 - 04 / 05 - 35
Component and Process Architectures
Component Architecture:

Classes

Stable aspects

Related components

Logical level

Structure for descriptions
Process Architecture

Objects

Dynamic aspects

Coordination of processes

Physical level

Structure for execution
(Mathiassen et al, 2000)
03 - 04 / 07 - 35
Activities in Architectural Design
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?
 Process Architecture
 Process
03 - 04 / 09 - 35
Criteria
Purpose
– To set design priorities
Concept
– Criterion : A preferred property of an
architecture
– Conditions : The technical, organizational, and
human opportunities and limits involved in
performing a task
03 - 04 / 10 - 35
Criteria (Cont’d)
Principles
– A good design has no major weakness
– A good design balances several criteria
– a good design is usable, flexible and
comprehensible
Result
– A collection of prioritized criteria
General Design Criteria
Criterions Measure of
Usable
The system’s adaptability to the organizational, workrelated, and technical context ( Apakah sistem yang akan
Kita buat bisa beradaptasi dengan sistem yang sedang
berjalan sekarang )
Secure
The precautions against unauthorized access to data and
facilities ( Memiliki Sistem Security yang baik)
Efficient
The economical exploitation of the technical Platform’s
facilities ( Apakah Secara Teknis Platform yang dipakai
Hardware dan Software sudah mendukung )
Correct
Reliable
The fulfillment of requirement
The fulfillment of the required precision in function
execution
03 - 04 / 11 - 35
03 - 04 / 12 - 35
General Design Criteria (Cont’d)
Criterions Measure of
Maintainable
The cost of locating and fixing system defects
Testable
The cost of ensuring that the deployment system performs its
intended function
Flexible
The cost of modifying the deployed system
Comprehensible
The effort needed to obtain a coherent understanding of the
system
Reusable
The potential for using system parts in other related system
Portable
The cost of moving the system to another technical platform
Interoperable
The cost of coupling the system to other systems
Prioritising Design Criteria in VCD CASE
Criterion
Very
Important
Important
Less
important
Easily
fulfilled
Irrelevant
9
8
Useable
Secure
Efficient
2
Correct
Reliable
Maintanable
Testable
Flexible
Comprehensible
1
4
6
3
10
7
5
Reuseable
Portable
Interoperatable
11
03 - 04 / 15 - 35
Penjelasan Criteria untuk VCD CASE
•
•
•
•
Didalam kasus VCD maka yang paling penting adalah
Reliable-> Karena sistem harus digunakan sehari – hari
Correct-> Perhitungannya harus tepat
Flexible-> Harus flexible jika ada program-program
promosi
• Maintainable-> Harus mudah untuk diadakan perubahan
03 - 04 / 13 - 35
Sub-activities in Criteria
Consider
general
criteria
Prioritize
System
definition
Analyse
specific
conditions
Criteria for
design
(Mathiassen et al, 2000)
03 - 04 / 14 - 35
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
03 - 04 / 16 - 35
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!
−
03 - 04 / 18 - 35
Components
•
Purpose
 To create a comprehensible and flexible
system structure
•
Concepts
 Component architecture : A system structure
of interconnected components
 Component : A collection of program parts
that constitutes a whole and has well-defined
responsibilities
03 - 04 / 19 - 35
Components (Cont’d)

Principles
 Reduce complexity by separating concerns
 Reflect stable context structures
 Reuse existing components

Result
 A Class diagram with specifications of the
complex components
03 - 04 / 21 - 35
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
03 - 04 / 22 - 35
The Layered Architecture Pattern
«component»
Layer i+1
Upward interface
«component»
Layer i
Downward interface
«component»
Layer i-1
(Mathiassen et al, 2000)
03 - 04 / 23 - 35
The Generic Architecture Pattern
«component» Interface
«component»
«component»
User Interface
System Interface
«component»
Function
«component»
Model
«component» Technical platform
«component»
«component»
«component»
UserInterfaceISystem
DataBaseSystem
NetworkSystem
(Mathiassen et al, 2000)
03 - 04 / 24 - 35
Generic Architecture (Cont’d)



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
03 - 04 / 25 - 35
The Client-Server Architecture Pattern
«component»
«component»
«component»
Client1
Client2
Clientn
«component»
Server
(Mathiassen et al, 2000)
03 - 04 / 26 - 35
Client-Server Architecture (Cont’d)



The components in a client-server architecture are a server and several client
The server has a collection of operations that it makes available to the clients
Potentially a good architecture whenever distribute a system geographically
03 - 04 / 27 - 35
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
03 - 04 / 28 - 35
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
Centralized data
U+F+M
M
Distributed data
(Mathiassen et al, 2000)
03 - 04 / 29 - 35
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)
03 - 04 / 30 - 35
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
03 - 04 / 31 - 35
Model Design Concerns


Responsibility:
Contextual issues:

Exemplars:

Special needs:
The problem domain model
Incohesive or complex problem domains
Accounting, reservations, inventory,
administration
databases
03 - 04 / 32 - 35
Function Design Concerns

Responsibility:

Contextual issues:

Exemplars:

Special needs:
The functionality on the
model
Need for incohesive or
complex functionality
Payroll, signal processing,
cruise control
Model-related functions,
application-related
functions
03 - 04 / 33 - 35
Interface Design Concerns

Responsibility:

Contextual issues:

Exemplars:

Special needs:
Interaction between
functions and actors
Incohesive or complex
actors or usage
Browsing, games,
presentation monitoring
Screens, windows,
buttons, print-outs, devices,
communications
03 - 04 / 34 - 35
Using Components

Can obtain and use components from a number of sources
 Another existing system
 Earlier version of system
 Standard purchased components - software library
03 - 04 / 35 - 35
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
Contoh Component untuk VCD CASE
Client:Kasir
Server
User
Interface
Function
Model