Download System Design - Romi Satria Wahono

Document related concepts

Entity–attribute–value model wikipedia , lookup

Relational model wikipedia , lookup

Database model wikipedia , lookup

Transcript
Systems Analysis and Design
4. System Design
Romi Satria Wahono
[email protected]
http://romisatriawahono.net/sad
WA/SMS: +6281586220090
1
Romi Satria Wahono
•
•
•
•
•
•
•
•
SD Sompok Semarang (1987)
SMPN 8 Semarang (1990)
SMA Taruna Nusantara Magelang (1993)
B.Eng, M.Eng and Ph.D in Software Engineering from
Saitama University Japan (1994-2004)
Universiti Teknikal Malaysia Melaka (2014)
Research Interests: Software Engineering,
Intelligent Systems
Founder dan Koordinator IlmuKomputer.Com
Peneliti LIPI (2004-2007)
Founder dan CEO PT Brainmatics Cipta Informatika
2
Course Outline
1. Introduction
2. Project Planning
3. System Analysis
4. System Design
5. System Implementation
3
4. System Design
4.1 Object-Oriented Paradigm
4.5 Data Model
4.2 Class Diagram
4.6 Deployment Diagram
4.3 Package Diagram
4.7 Nonfunctional Requirements
4.4 User Interface Design
4
SDLC and Deliverables
Planning
(System Proposal)
Implementation
Analysis
(New System)
(System Specification)
Design
(System Specification)
5
System Analysis and Design with UML
1. System Analysis
1.
Business Process Identification
•
2.
Use Case Diagram
Business Process Modeling
•
3.
Activity Diagram or Business Process Modeling Notation (BPMN)
Business Process Realization
•
Sequence Diagram
(Buat untuk setiap use case dengan menggunakan pola Boundary-Control-Entity)
2. System Design
1.
Program Design
1. Class Diagram (Gabungkan Boundary-Control-Entity Class dan susun story dari sistem yang dibangun)
2. Package Diagram (Gabungan class yang sesuai, boleh menggunakan pola B-C-E)
3. Deployment Diagram (arsitektur software dari sistem yang dibangun)
2.
3.
User Interface Design (Buat UI design dari Boundary Class)
Entity-Relationship Model (Buat ER diagram dari Entity Class)
6
4.1 Object-Oriented Paradigm
7
4.1.1 Konsep Dasar Pemrograman
Berorientasi Objek
Class , Object, Method, Attribute
8
Berorientasi Objek?
Attribute:
Topi, Baju, Jaket,
Tas Punggung,
Tangan, Kaki, Mata
Behavior:
Cara Jalan ke Depan
Cara Jalan Mundur
Cara Belok ke Kiri
Cara Memanjat
9
Berorientasi Objek?
Attribute (State):
Ban, Stir, Pedal Rem, Pedal Gas,
Warna, Tahun Produksi
Behavior:
Cara Menghidupkan Mesin
Cara Manjalankan Mobil
Cara Memundurkan Mobil
Attribute  Variable(Member)
Behavior  Method(Fungsi)
10
Perbedaan Class dan Object
• Class: konsep dan deskripsi dari sesuatu
• Class mendeklarasikan method yang dapat digunakan
(dipanggil) oleh object
• Object: instance dari class, bentuk (contoh)
nyata dari class
• Object memiliki sifat independen dan dapat digunakan
untuk memanggil method
• Contoh Class dan Object:
• Class: mobil
• Object: mobilnya pak Joko, mobilku, mobil berwarna
merah
11
Perbedaan Class dan Object
• Class seperti cetakan kue, dimana kue yg
dihasilkan dari cetakan kue itu adalah object
• Warna kue bisa bermacam-macam meskipun
berasal dari cetakan yang sama (object
memiliki sifat independen)
12
Class = Method + Variable
Class Sepeda
gir
variable
kecepatan
tampilkan kecepatan
method
ubah gir
13
Object = Method + Variable Bernilai
Object Sepedaku
gir = 3
instance
variable
kecepatan = 10km/jam
tampilkan kecepatan ()
kecepatan = 10 km/jam
ubah gir (2)
gir = 5
14
instance
method
Attribute
• Variable yang mengitari class, dengan nilai datanya
bisa ditentukan di object
• Variable digunakan untuk menyimpan nilai yang
nantinya akan digunakan pada program
• Variable memiliki jenis (tipe), nama dan nilai
• Name, age, dan weight adalah atribute (variabel)
dari class Person
15
Membuat Class, Object dan Memanggil Atribut
public class Mobil {
Mobil.java
String warna;
int tahunProduksi;
}
public class MobilBeraksi{
public static void main(String[] args){
// Membuat object
Mobil mobilku = new Mobil();
MobilBeraksi.java
/* memanggil atribut dan memberi nilai */
mobilku.warna = "Hitam";
mobilku.tahunProduksi = 2006;
System.out.println("Warna: " + mobilku.warna);
System.out.println("Tahun: " + mobilku.tahunProduksi);
}
}
16
Method
• Method adalah urutan instruksi yang
mengakses data dari object
• Method melakukan:
1. Manipulasi data
2. Perhitungan matematika
3. Memonitor kejadian dari suatu event
17
Method
18
Membuat dan Memanggil Method
public class Mobil2{
String warna;
Mobil2.java
int tahunProduksi;
void printMobil(){
System.out.println("Warna: " + warna);
System.out.println("Tahun: " + tahunProduksi);
}
}
public class Mobil2Beraksi{
public static void main(String[] args){
Mobil2 mobilku = new Mobil2();
Mobil2Beraksi.java
mobilku.warna = "Hitam";
mobilku.tahunProduksi = 2006;
mobilku.printMobil();
}
}
19
Parameter
• Sepeda akan berguna apabila ada object lain yang
berinterasi dengan sepeda tersebut
• Object software berinteraksi dan berkomunikasi dengan
object lain dengan cara mengirimkan message atau pesan
• Pesan adalah suatu method, dan informasi dalam pesan
dikenal dengan nama parameter
20
Pengiriman Pesan dan Parameter
1. You
 object pengirim
2. YourBicycle
 object penerima
3. changeGears
 pesan berupa method yang dijalankan
4. lowerGear
parameter yang dibutuhkan method
(pesan) untuk dijalankan
21
22
Sepeda.java
public class Sepeda{
int gir;
// method (mutator) dengan parameter
void setGir(int pertambahanGir) {
gir= gir+ pertambahanGir;
}
// method (accessor)
int getGir() {
return gir;
}
}
23
SepedaBeraksi.java
public class SepedaBeraksi{
public static void main(String[] args) {
// Membuat object
Sepeda sepedaku = new Sepeda();
// Memanggil method dan menunjuk nilai parameter
sepedaku.setGir(1); // menset nilai gir = 1
System.out.println(“Gir saat ini: “ + sepedaku.getGir());
sepedaku.setGir(3); // menambahkan 3 pada posisi gir saat ini (1)
System.out.println(“Gir saat ini: “ + sepedaku.getGir());
}
}
24
4.1.2 Karakteristik Pemrograman
Berorientasi Objek
Abstraction, Encapsulation, Inheritance, Polymorphism
25
Abstraction
• Cara kita melihat suatu sistem dalam bentuk yang
lebih sederhana, yaitu sebagai suatu kumpulan
subsistem (object) yang saling berinteraksi.
• Mobil adalah kumpulan sistem pengapian, sistem kemudi,
sistem pengereman
• Alat meng-abstraksikan sesuatu adalah class
• Object bersifat modularity. Object dapat ditulis dan
dimaintain terpisah (independen) dari object lain
26
27
28
Encapsulation
• Mekanisme menyembunyikan suatu proses dan data
dalam sistem untuk menghindari interferensi, dan
menyederhanakan penggunaan proses itu sendiri
• Tongkat transmisi (gigi) pada mobil
• Tombol on/off/pengaturan suhu pada AC
• Class access level (public, protected, privat) adalah
implementasi dari konsep encapsulation
• Enkapsulasi data dapat dilakukan dengan cara:
1. mendeklarasikan instance variable sebagai private
2. mendeklarasikan method yang sifatnya public untuk
mengakses variable tersebut
29
30
Encapsulation dan Access Modifier
Modifier
Dalam
Dalam Class
Package yang
yang Sama
Sama
Dalam
Dalam
SubClass Package Lain
private

tanpa
tanda


protected



public



31

Encapsulation
Enkapsulasi data juga dapat dilakukan dengan cara:
1. mendeklarasikan instance variable sebagai private
2. mendeklarasikan method yang sifatnya public untuk
mengakses variable tersebut
32
Sepeda.java
public class Sepeda{
int gir;
void setGir(int pertambahanGir) {
gir= gir+ pertambahanGir;
}
int getGir() {
return gir;
}
}
33
SepedaBeraksi.java
public class SepedaBeraksi{
public static void main(String[] args) {
Sepeda sepedaku = new Sepeda();
sepedaku.setGir(1);
/* Variabel bisa diubah atau tidak sengaja diubah.
Hal ini berbahaya dan sering menimbulkan bug.
Berikan access modifier private pada instance variable */
sepedaku.gir = 3;
System.out.println(“Gir saat ini: “ + sepedaku.getGir());
}
}
34
Sepeda.java
public class Sepeda{
private int gir; // access modifier private pada instance variable
void setGir(int pertambahanGir) {
gir= gir+ pertambahanGir;
}
int getGir() {
return gir;
}
}
35
Inheritance (Pewarisan)
• Suatu class dapat
mewariskan atribut dan
method kepada class
lain (subclass), serta
membentuk class
hierarchy
• Penting untuk
Reusability
• Java Keyword:
extends
36
Sepeda.java
public class Sepeda{
private int gir;
void setGir(int pertambahanGir) {
gir= gir+ pertambahanGir;
}
int getGir() {
return gir;
}
}
37
Class SepedaGunung Mewarisi Class Sepeda
public class SepedaGunung extends Sepeda{
public class SepedaGunungBeraksi {
public static void main(String[] args) {
private int sadel;
SepedaGunung sg=new SepedaGunung();
void setSadel (int jumlah) {
sg.setGir(3);
System.out.println(sg.getGir());
sadel = getGir() - jumlah;
}
sg.setSadel(1);
System.out.println(sg.getSadel());
}
int getSadel(){
return sadel;
}
}
}
SepedaGunung.java
38
SepedaGunungBeraksi.java
Polymorphism
• Kemampuan untuk memperlakukan object
yang memiliki perilaku (bentuk) yang
berbeda
• Implementasi konsep polymorphism:
1. Overloading: Kemampuan untuk menggunakan
nama yang sama untuk beberapa method yang
berbeda parameter (tipe dan atau jumlah)
2. Overriding: Kemampuan subclass untuk menimpa
method dari superclass, yaitu dengan cara
menggunakan nama dan parameter yang sama
pada method
39
Polymorphism – Overloading
class Mobil {
public class MobilKonstruktor{
public static void main(String[] args){
String warna;
Mobil mobilku = new Mobil(“Merah”, 2003);
int tahunProduksi;
mobilku.info();
public Mobil(String warna, int tahunProduksi){
Mobil mobilmu = new Mobil();
mobilmu.info();
}
this.warna = warna;
this.tahunProduksi = tahunProduksi;
}
}
public Mobil(){
}
void info(){
System.out.println("Warna: " + warna);
System.out.println("Tahun: " + tahunProduksi);
}
}
40
Polymorphism – Overloading
class Lingkaran{
void gambarLingkaran(){
}
void gambarLingkaran(int diameter){
...
}
void gambarLingkaran(int diameter, int x, int y){
...
}
void gambarLingkaran(int diameter, int x, int y, int warna, String
namaLingkaran){
...
}
}
41
Polymorphism - Overriding
public class Sepeda{
protected int gir;
void setGir(int pertambahanGir) {
gir= gir+ pertambahanGir;
}
int getGir() {
return gir;
}
}
42
Polymorphism - Overriding
public class SepedaGunung extends Sepeda{
public class SepedaGunungBeraksi {
public static void main(String[] args) {
void setGir(int pertambahanGir) {
SepedaGunung sg=new SepedaGunung();
super.setGir(pertambahanGir);
sg.setGir(2);
System.out.println(sg.getGir());
gir = 2*getGir();
}
}
sg.setGir(3);
System.out.println(sg.getGir());
}
}
SepedaGunung.java
43
SepedaGunungBeraksi.java
Matematika.java
public class Matematika{
void pertambahan (int a, int b){
int hasil= a + b;
System.out.println(“hasil:” + hasil);
}
void pertambahan (double a, double b, double c){
int hasil= a + b + c;
System.out.println(“hasil:” + hasil);
}
...
}
44
4.2 Class Diagram
45
4.2.1 Class Diagram Elements
46
Class Diagram Elements
1.
2.
3.
4.
Classes
Attributes
Operations
Relationships
47
Classes
• Templates for creating instances or
objects
• All objects of a class have same structure
and behavior, but contain different
attributes
1. Concrete: used to create actual objects
2. Abstract: extended to create other classes
48
Attributes
• Units of information relevant to the
description of the class
• Only attributes important to the task
should be included
• Attributes should be primitive types
(integers, strings, doubles, date, time,
Boolean, etc.)
49
Operations (Methods)
• Defines the behavior of the class
• Action that instances/objects can take
• Focus on relevant problem-specific
operations (at this point)
50
Relationships
• Generalization
• “Is-A” relationship
• Enables inheritance of attributes & operations
• Subclasses and superclasses
• Aggregation
• “Has-A” relationship
• Relates parts to wholes
• Uses decomposition
• Composition
• “Has-A” relationship
• Similar but stronger than Aggregation
• Association
•
•
•
•
Relationships that don't fit “Is-A” or “Has-A”
Often a weaker form of “Has-A”
Miscellaneous relationships between classes
Example:
• Patient schedules an appointment
• So the appointment has a patient
51
Example Class Diagram
52
More on Attributes
• Derived attributes
• /age, for example can be calculated from birth
date and current date
• Visibility of attributes
• +Public: not hidden from any object
• #Protected: hidden from all but immediate
subclasses
• –Private: hidden from all other classes
• Default is private
53
More on Operations
• Constructor: creates object
• Query: see class state
• Update: change attribute values
• Operations can also be
public, protected, or private
• Default for operations is public
54
More on Relationships
• A primary purpose of class diagrams is
to show relationships, or associations,
between classes
• Class can be related to itself (role)
• Use a "+" sign to show it's a role and not the
name of a relationship
55
Relationship Multiplicity
Exactly one
1
Boss
Employee
0..*
Child
Boss
1..*
Employee
Employee
0..1
Spouse
Specified
range
Employee
2..4
Vacation
Disjoint
ranges
Employee
1..3, 5
Zero or more
One or more
Zero or one
Dept
56
Committee
Class
57
Class with Attribute and Method
58
Class Association
59
Multiplicity
60
Inheritance
61
Interface
62
Class Diagram: Internet Order Project
63
Class Diagram: Sistem ATM
class CD - Sistem ATM
ProsesValidasiAccount
KotakUang
Login
mengakses
KotakKuitansi
mengakses
memiliki
melakukan
memiliki
ProsesMengecekSaldo
MenuMengecekSaldo
melakukan
MenuPIN
SistemATM
+
Account
lihatSaldo() : void
memiliki
mewarisi
menampilkan
Balance
MenuMentransferUang
ProsesMentransferUang
memiliki
melakukan+
+
+
mewarisi
MenuUtama
m_Account: Account
m_Balance: Balance
m_Transaksi: Transaksi
KotakKartu
mewarisi
MenuMengambilUang
melakukan
+
+
ProsesMentransferUang()
transferUang() : void
mewarisi
melakukan
ProsesValidasiKartu
ProsesMengambilUang
MenuLogout
melakukan
ProsesLogout
64
+
+
+
m_Account: Account
m_Balance: Balance
m_Transaksi: Transaksi
+
+
ambilUang() : void
ProsesMengambilUang()
Transaksi
Exercise: Class Diagram
1. Lihat kembali System Request yang sudah anda
buat
2. Pahami kembali Activity Diagram, Use Case
Diagram, dan Sequence Diagram yang telah
anda buat
3. Lanjutkan dengan membuat Class Diagram
4. Masukkan method (message di Sequence
Diagram) ke dalam setiap class
5. Generate code secara otomatis dari Class
Diagram tersebut
65
Exercise: Systems Analysis and Design
• Lakukan sistem analysis and design yang menghasilkan diagram:
1.
2.
3.
Use Case Diagram
Activity Diagram
Sequence Diagram
4.
Class Diagram
• Pilih salah satu aplikasi di bawah:
1.
Aplikasi Rental Mobil
7.
Aplikasi Penjualan Buku Online
2.
Aplikasi Pengelolaan Klinik
8.
Aplikasi Penjualan Tiket Kereta Online
3.
Aplikasi Pengelolaan Apotik
9.
Aplikasi Manajemen Universitas Online
4.
Aplikasi Pengelolaan Service Mobil
10. Aplikasi Penjualan Laptop Online
5.
Aplikasi Penjualan Motor
11. Aplikasi Perpustakaan Digital
6.
Aplikasi Pengelolaan Perpustakaan
12. Aplikasi Pengelolaan Project Software
66
4.2.2 Class and Method Design
67
Levels of Abstraction
68
Elements
1.
2.
3.
4.
5.
6.
Classes
Objects
Attributes
States
Methods
Messages
69
Encapsulation
• Combine attributes and methods into a
single object
70
Information Hiding
• Only information needed to use the object is
available outside the object
• This is the Public Interface
• Everything else is hidden
• Communication only through object’s methods
• Key to reusability
71
Polymorphism
• Same message triggers different methods in
different objects
• Dynamic binding means specific method is
selected at run time
• Implementation of dynamic binding is
language specific
• Need to be very careful about run time
errors
• Need to ensure semantic consistency
72
Inheritance
1. Single inheritance -- one parent class
2. Multiple inheritance -- multiple parent
classes
• Redefinition and inheritance conflict
• Most inheritance conflicts are due to poor
classification
73
Coupling
• The interdependence or
interrelationships of the modules
• Interaction coupling
• Relationships with methods and objects
• through message passing
74
Types of Interaction Coupling
Level
Good
Bad
Type
Description
No Direct
Coupling
Methods don't call each other
Data
Calling method passes object, called method uses the
entire object
Stamp
Calling method passes object, called method uses only
part of the object
Control
Calling method passes a control variable whose value
controls the execution of the called method
Common or
Global
Methods refer to a "global data area" that is outside of
the individual objects
Content or
Pathological
A method of one object refers to the hidden part of
another object.
75
Cohesion
• “Single-mindedness of a module”
• Method cohesion
• A method should do just a single task
• Class cohesion
• A class should represent just one thing
• Generalization/specialization cohesion
• Addresses inheritance
• Should represent "a-kind-of" or "is-a"
76
Types of Method Cohesion
Level
Type
Description
Good
Functional
A method performs a single task
Sequential
Method performs two tasks, the output of the first is the
input of the second
Communicational
Method combines two functions that use the same
attributes (calc current and final GPA)
Procedural
Method supports many loosely related functions (calc
current GPA, print, calc final GPA, print)
Temporal or
Classical
Method supports multiple functions related in time
(initialize all variable, print all reports)
Logical
Method supports many functions controlled by a passed
control variable
Coincidental
Method's purpose cannot be determined, or it supports
multiple unrelated functions
Bad
77
Connascence
• Literally means "born together"
• Generalizes the ideas of cohesion and
coupling
• Two modules are so intertwined that a
change to one automatically means a change
to the other
78
Types of Connascence
Type
Description
Name
Method refers to an attribute by name
If the name changes, the method must change
Type or
Class
Class has an attribute of a given type.
If the type changes, the attribute declaration must also
change
Convention If the range of values of a class's attribute has some
meaning, and that meaning changes, all methods that use
that attribute must also change (part numbers have
meaning)
Algorithm
If two methods rely on the same algorithm and that
algorithm changes, the methods must change (insert and
sort)
79
Identify Opportunities for Reuse
• Frameworks:
•
•
•
•
A set of implemented classes
Can be reused to implement an app
Allows you to create subclasses from the classes in the framework
Tend to be domain specific, for example
• Object Persistence Framework
• User Interface Framework
• Class libraries:
•
•
•
•
A set of implemented classes
Can be reused to implement an app
Tend not to be domain specific
Rather, provide some functionality, for example:
• Statistical library
• File management library
• Components:
•
•
•
•
Self-contained piece of Software
Can be "plugged" into your app
Has a well-defined API
Often Active-X or JavaBeans
80
Restructuring the Design
1. Factoring
• Separate aspects of a method or class into a new
method or class
2. Normalization
• Identifies classes missing from the design
3. Challenge inheritance relationships to
ensure they only support a generalization or
specialization semantics
81
Optimizing the Design
• Now, think about performance
• Review access paths
• If there is a long access path through many objects,
provide a direct path
• Review attributes of each class
• Which classes use the attributes
• If only one class uses it, and it only reads and updates
• Move the attribute to the calling class
• Review direct and indirect fan-out
• Fan-out is number of messages sent
• If high compared to other methods
• Consider optimization of the method
• Avoid re-computation by creating derived attributes
and triggers
• Update when "ancestor" attributes are updated
• Update when derived attribute
is used
82
4.3 Package Diagram
83
Package
• A general construct that groups units
together
• A package can contain
1. Collaborations
2. Partitions
3. Layers
• Used to reduce complexity of models
84
Package Diagrams
• A package diagram shows packages only
• Like a class diagram but shows only packages
• Packages can have different relationships,
depending on what's in them
• Also, define a new relationship called a
"dependency relationship"
85
Modification Dependency
• A change in one package requires a change
in another package
• Example:
• A change in one method
 Causes a change in the interface for all objects of the class.
 Causes change in all classes that send messages to the
changed class.
86
Package Diagram of Dependency
Relationships Among Layers
87
MVC Architecture
• Model-View-Controller (MVC)
architecture
• Models = data related (file/database)
• Views = user interface logic
• Controllers = processing (business) logic
• Separating application logic from user
interface logic
• Layers are a way to add the system
environment information
88
Layers
• A Layer represents an element of the
software architecture of the new system
• There is a layer for each different element in
the system environment
1.
2.
3.
4.
5.
Foundation
Physical Architecture
Human-Computer Interaction
Data Management
Problem Domain
89
Foundation Layer
Contains basic classes needed for any
application:
1. Fundamental data types (integers, floating
points, strings, Booleans, etc)
2. Fundamental data structures (lists, stacks, sets,
trees, etc.)
3. Useful abstract classes (date, time, money,
mathematics)
90
Physical Architecture Layer
How the software will execute on
specific computers and networks
• Communication between Software and Operating
System
• Communication between Software and Network
• Classes to interact with middleware
91
HCI Layer
• Separates UI from problem domain
• Buttons, windows, scroll bars, etc.
• Makes software more portable
• Need to address
• UI consistency, user experience, help systems,
types of input/output elements
92
Data Management Layer
• Separates storage from problem domain
• How objects are stored/retrieved
• Increases portability
• Addresses
• storage format (db, client/server, etc.)
• storage optimization (clustering, indexing)
93
Problem Domain Layer
• What we have focused on so far in this
class
• Previous layers deal with the
environment
• This layer is our actual application
94
Exercise: Package Diagram
1. Lihat kembali Activity Diagram, Use Case
Diagram, Sequence Diagram dan Class
Diagram yang telah anda buat
2. Lanjutkan dengan membuat Package
Diagram
95
4.4 User Interface Design
96
4.4.1 User Interface Concepts
97
Key Definitions
• User interface
• How the system interacts with external entities
• System interfaces
• How systems exchange information with other systems
• Navigation mechanism
• How users tell the system what to do
• Input mechanism
• How the system captures information
• Output mechanism
• How the system provides information to users or other
systems
• Graphical User Interface (GUI)
• Uses graphics objects (windows, icons, buttons, etc.)
• The most common type of interface
98
Principles for User Interface Design
• Interface design is an art
• Balance between
• Making the interface useful and
• Presenting too much information
99
Principles for User Interface Design
1. Layout
•
Consistent use of screen area
2. Content awareness
•
Users know where they are
3. Aesthetics
•
White space vs. functionality
4. User experience
•
Ease of use vs. learning curve
5. Consistency
•
User can predict what will happen for each action
6. Minimal user effort
• Simple to use, three click rule
100
1. Layout Concepts
• The screen is often divided into three boxes
1.
2.
3.
Navigation area (top)
Status area (bottom)
Work area (middle)
• Information can be presented in multiple areas, like areas should be
grouped together
• Areas and information should minimize user movement from one to
another
• Ideally, areas will remain consistent in
•
•
•
•
Size
Shape
Placement for entering data
Reports presenting retrieved data
• Biggest Problem:
• Too much information to process
• Provide a logical structure
• Chronological
• Most used to least used
• General to specific
101
Layout Example
System
Navigation
Report
and
form area
102
2. Content Awareness
• Make the user aware of the content without
even knowing it
• All interfaces should have titles
• Menus should show
• where you are
• where you came from to get there
103
3. Aesthetics
• Interfaces need to be functional and inviting to use
• Pleasing to the eye
• Avoid squeezing in too much
• Particularly for novice users
• Experienced users can handle more info
• Design text carefully
• Be aware of font and size
• Avoid using all capital letters
• Colors and patterns should be used carefully
• Test quality of colors
• Try the interface on a monochrome monitor
• Use colors to separate or categorize items
• Don't rely on color alone to convey meaning
104
4. User Experience
• How easy is the program to learn?
• How easy is the program to use for the expert?
• Consider shortcuts for the expert
• Where there is low employee turnover
• Training can lessen the impact of less precise
interfaces
• Some applications are used by many people
• But not often by any of them
• Focus on easy learning
• Some apps used frequently
• By the same people
• Focus on ease of use
105
5. Consistency
• Lets users predict what will happen
• Reduces learning curve
• Considers items within an application and
across applications (Windows API)
• Pertains to many different levels
• Navigation controls
• Terminology
• Same word  same meaning
• Report and form design
106
6. Minimize Effort
• Three click rule
• Users should be able to go from the main menu to
the information they want
• In no more than three clicks or keystrokes
107
4.4.2 Process of User Interface Design
108
Five Step Process
1. Look at use cases and sequence diagrams
• Develop use scenarios:
• How will the users use the interface
• ID common user actions
2. Develop Window Navigation Diagram (WND)
3. Design Interface Standards
• Basic design elements upon which interfaces are
designed
4. Create Interface Design Prototype
• One for each interface in the system
• Use real use cases
5. Perform interface evaluations
• Are the interfaces ok?
109
Interface Evaluation
110
1. Use Scenario Development
• Outline of steps users use to perform their work
• Presented in a simple narrative tied to the related
DFD
• Document the most common cases so interface
designs will be easy to use for those situations
111
2. Interface Structure Design
• Window navigation diagram (WND)
• Shows how all screens, forms, and reports are
related
• Shows how user moves from one to another
• Like a state diagram for the user interface
• Boxes represent components
• Arrows represent transitions
• Stereotypes show interface type
112
Window Navigation Diagram
113
3. Interface Standards Design
• The basic elements that are common
across
• Screens
• Forms
• Reports
• Interface metaphor
• A concept from the real world
• Used as a model for the computer system
• Desktop, checkbook, shopping cart
114
4. Interface Elements
• Interface objects
• Building blocks of the interface
• Give each object an understandable name
• Understandable names are better than precise names
• Interface actions
• Navigation and command
• Menu, buttons, drop-down lists
• Grammar
• Buy vs. purchase
• Modify vs. change
• Interface icons
• Represent interface objects & actions
• Interface templates
• Templates for screens, forms, reports
115
4. Interface Design Prototyping
• A mock-up or simulation of screen, form, or
report
• Common methods include
•
•
•
•
Paper Forms
Storyboarding
HTML
Language
116
Storyboard Example
117
5. Interface Evaluation Methods
• Understand how to improve the interface
• Should be done before system is finished
• Heuristic evaluation
• Check the prototype
• Design by checklist
• At least three people should participate
• Walkthrough evaluation
• Walk users through the system
• Team simulates movement through components
• Interactive evaluation
• Use prototype
• User tries out the system with a team member present
• Formal usability testing
• Expensive
• Detailed use of special lab testing
118
4.4.3 Navigation Design
119
Basic Principles
• Assume users:
• Have not read the manual
• Have not attended training
• Do not have external help readily at hand
• Controls should be:
• Clear and understandable
• Placed in an intuitive location on the screen
• Anticipate what the user will do
• Prevent Mistakes
• Users may make mistakes or discard the system
entirely
• Simplify recovery from mistakes
• Use Consistent Grammar Order
120
Basic Principles
• Prevent mistakes
• Limit choices
• Never display commands that can’t be used (or "gray
them out")
• Confirm actions that are difficult or impossible to undo
• Simplify recover from mistakes
•
•
•
•
No matter how hard you try, users will make mistakes
If possible, have an "undo"
Transaction rollbacks
Automatic backups
• Use consistent grammar order
•
•
•
•
Normally specify an Action and an Object
Can use Action-Object, or Object-Action
Windows uses Object-Action (cut and paste)
Whatever you choose, it should be used consistently
121
Types of Navigation Control
• Languages
• Command language
• User enters commands using special language
• UNIX, DOS, SQL, etc.
• Hard to learn, fast and easy to use
• Natural language
• Easy to learn
• Slow and imprecise
• Menus
• Generally aim at broad shallow menus
• Consider using “hot keys”
• Direct Manipulation
• Used with icons to start programs
• Used to shape and size objects
• May not be intuitive for all commands
122
Message Tips
• Should be clear, concise, and complete
• Should be grammatically correct and free of
jargon and abbreviations (unless they are the
users)
• Avoid negatives and humor
123
An Example of Crafting an Error Message
124
4.4.4 Input Design
125
Basic Principles
• The goal is to simply and easily capture accurate
information for the system
• Reflect the nature of the inputs
• (e.g. batch input)
• Find ways to simplify their collection
126
Online versus Batch Processing
• Online processing immediately records the
transaction in the appropriate database
• Batch processing collects inputs over time and
enters them into the system at one time in a batch
• Batch processing simplifies data communications
and other processes, but means that inventory and
other reports are not accurate in real time
127
Capture Data at the Source
• Reduces duplicate work
• Reduces processing time
• Decreases cost
• Decreases probability of error
128
Source Data Automation
• Can be obtained by using the following
technologies:
• bar code readers
• optical character recognition
• magnetic stripe readers
• smart cards
• RFID
129
Minimize Keystrokes
• Never ask for information that can be obtained in
another way
• List selection is more efficient than entering
information
• Use default values where possible
130
4.4.5 Ouput Design
131
Basic Principles
• Understand report usage
• Reference or cover-to-cover?
• Frequency?
• Real-time or batch reports?
• Manage information load
• All needed information, no more
• Minimize bias
132
Bias in Graphs
133
Exercise: User Interface Design
1. Lihat kembali Activity Diagram, Use Case
Diagram, Sequence Diagram dan Class
Diagram yang telah anda buat
2. Lanjutkan dengan membuat User Interface
Design dengan menggunakan Java Frame
dengan Netbeans
3. User Interface Design diekstraksi dari Entity
Class
134
4.5 Data Model
135
4.5.1 Introduction to Database
136
What is Database
• Database system is a computer based record
keeping system
• It is a system whose overall purpose is to
record and maintain information that is
deemed important to the organization
• Database is collection of stored operational
data which can be used and shared by different
applications and users of any organization
137
Why Database
• Database system provides the organization
with centralized control of its operational
data, which is one of its most valuable assets
• This is totally opposite of the situation that is
happening in many organizations, where
typically each application has its own private
files (flat file). This makes the operational
data widely dispersed and difficult to control
138
Advantage of Centralized Database
• Redundancy can be reduced
• Inconsistency can be avoided
• Data can be shared
• Standards can be enforced
• Security restrictions can be applied
• Integrity can be maintained
• Conflicting requirements can be balanced
139
Disadvantage of Database Systems
• Database is more vulnerable to destruction thru:
• machine malfunction
• personal error
• Deliberate human tampering
• Cost: the cost of required hardware, DB development,
and DB maintenance is high
• Complexity: Due to its complexity, the user should
understand it well enough to use it efficiently and
effectively
140
Database Models - Product - Vendor
MODEL
1. Relational
2. Network
3. Heirarchical
4. Object oriented
PRODUCT
VENDOR
DB2
Ingress
Oracle
Access
PostgreSQL
MySQL
DMS100
IDMS
IMS
System 2000
Starburst
Gemstone
Orion
IBMSQL/DS
Relational Tech.
Oracle corp
Microsoft
141
Unysis
Cullinet
IBM
Intel
IBM
Relational Database
• Relational database is a collection of tables
• Formally a table is called a relation
• Database is a structure that can hold
information about tables, rows, and columns
142
Relational Database
Relational
Model
Relational
DBMS
Traditional
File System
Relation
Tuple
Attribute
Primary Key (PK)
Relationship (FK)
Table
Row
Column
Primary Key (PK)
Relationship (FK)
File
Record
Field
Search Key
Not Used
143
Relational Database
1. Primary Key (PK): An attribute which can
uniquely identify each record (tuple) of a
relation (table)
2. Foreign Key (FK): An attribute which is a
regular attribute in one table but a primary
key in another table
144
Example of a Relational Database
Relation Name
Attribute
Primary Key (PK)
Sale
SalesNO Name
Rate
City
Dept#
10
12
48
10
15
8
Dallas
Denver
WashDC
A211
F654
A211
James
Black
Black
Tuple (record)
145
Example of a Relational Database
Customer
CustID Name
132
135
198
Black
Tom
Tom
Balance
City
SaleNo
2000.00 Dallas
129.89 Denver
(132.90) Dallas
10
12
10
SalesNO is PK in Sales table
Sales
SalesNO Name
10
12
48
James
Black
Black
Rate
City
Dept#
10
15
8
Dallas
Denver
WashDC
A211
F654
A211
146
Example: Order Entry Database
Order
ONO DATE
102
199
92
11/2/94
2/15/95
10/4/94
OrderLine
CustID SalesNO
132
135
102
ONO Oline# Part#
10
12
53
102
102
199
1
2
1
Qty
12.00 10
129.89 1
32.90 3
Part#
EX454
DE012
DC810
Customer
CustID Name Balance City
SaleNo
132
Black 2000.00 Dallas
10
135
Tom
129.89 Denver 12
198
Tom
(132.90) Dallas
10
Sales
SalesNO Name
10
12
48
James
Black
Black
147
Rate
10
15
8
City
Dept#
Dallas
A211
Denver F654
WashDC A211
Functionality of a DBMS
• The programmer sees SQL, which has two
components:
1. Data Definition Language (DDL)
2. Data Manipulation Language (DML)
• Behind the scenes the DBMS has:
1.
2.
3.
4.
Query engine
Query optimizer
Storage management
Transaction Management (concurrency, recovery)
148
How the Programmer Sees the DBMS
1. Start with DDL to create tables:
CREATE TABLE Students (
Name CHAR(30)
SSN CHAR(9) PRIMARY KEY NOT NULL,
Category CHAR(20)
) ...
2. Continue with DML to populate tables:
INSERT INTO Students
VALUES(‘Charles’, ‘123456789’, ‘undergraduate’)
. . . .
149
Transactions
• Enroll “Mary Johnson” in “CSE444”:
BEGIN TRANSACTION;
INSERT INTO Takes
SELECT Students.SSN, Courses.CID
FROM Students, Courses
WHERE Students.name = ‘Mary Johnson’ and
Courses.name = ‘CSE444’
-- More updates here....
IF everything-went-OK
THEN COMMIT;
ELSE ROLLBACK
If system crashes, the transaction is still either committed or aborted
150
Transactions
• A transaction = sequence of statements that
either all succeed, or all fail
• Transactions have the ACID properties:
1. A = atomicity (a transaction should be done or undone completely )
2. C = consistency (a transaction should transform a system from one
consistent state to another consistent state)
3. I = isolation (each transaction should happen independently of other
transactions )
4. D = durability (completed transactions should remain permanent)
151
Queries
• Find all courses that “Mary” takes
SELECT C.name
FROM Students S, Takes T, Courses C
WHERE S.name=“Mary” and
S.ssn = T.ssn and T.cid = C.cid
• What happens behind the scene ?
• Query processor figures out how to answer the query
efficiently.
152
Queries, Behind the Scene
Declarative SQL query
Imperative query execution plan:
sname
SELECT C.name
FROM Students S, Takes T, Courses C
WHERE S.name=“Mary” and
S.ssn = T.ssn and T.cid = C.cid
cid=cid
sid=sid
name=“Mary”
Students
Takes
The optimizer chooses the best execution plan for a query
153
Courses
4.5.2 Introduction to SQL
154
SQL Introduction
• Standard language for querying and manipulating
data
• SQL = Structured Query Language
• Many standards out there:
•
•
•
•
•
ANSI SQL
SQL92 (a.k.a. SQL2)
SQL99 (a.k.a. SQL3)
Vendors support various subsets of these
What we discuss is common to all of them
155
SQL
• Data Definition Language (DDL)
• Create/alter/delete tables and their attributes
• Data Manipulation Language (DML)
• Query one or more tables
• Insert/delete/modify tuples in tables
• Transact-SQL
• Idea: package a sequence of SQL statements  server
156
Data Types in SQL
• Characters:
•
•
CHAR(20)
VARCHAR(40)
-- fixed length
-- variable length
• Numbers:
•
•
•
BIGINT, INT, SMALLINT, TINYINT
REAL, FLOAT
-- differ in precision
MONEY
• Times and dates:
•
•
DATE
DATETIME
-- SQL Server
• Others... All are simple
157
SQL Data Type vs Java Data Type
SQL Data Type
Java Data Type
INTEGER or INT
int
REAL
float
DOUBLE
double
DECIMAL(m, n)
Fixed-point decimal numbers with m total digits and
n digits after the decimal point; similar to
BigDecimal.
BOOLEAN
Boolean
VARCHAR(n)
Variable-length String of length up to n
CHARACTER(n) or
CHAR(n)
Fixed-length String of length n
158
Tables in SQL
Attribute names
Table name
Product
PName
Price
Category
Manufacturer
Gizmo
$19.99
Gadgets
GizmoWorks
Powergizmo
$29.99
Gadgets
GizmoWorks
SingleTouch
$149.99
Photography
Canon
MultiTouch
$203.99
Household
Hitachi
Tuples or rows
159
Tables Explained
• A tuple = a record
• Restriction: all attributes are of atomic type
• A table = a set of tuples
• Like a list…
• …but it is unorderd: no first(), no next(), no last().
• No nested tables, only flat tables are
allowed!
160
Tables Explained
• The schema of a table is the table name and its
attributes:
Product(PName, Price, Category, Manfacturer)
• A key is an attribute whose values are unique;
we underline a key
Product(PName, Price, Category, Manfacturer)
161
SQL Query
Basic form: (plus many many more bells and whistles)
SELECT attributes
FROM
relations (possibly multiple, joined)
WHERE conditions (selections)
162
Simple SQL Query
Product
PName
Price
Category
Manufacturer
Gizmo
$19.99
Gadgets
GizmoWorks
Powergizmo
$29.99
Gadgets
GizmoWorks
SingleTouch
$149.99
Photography
Canon
MultiTouch
$203.99
Household
Hitachi
PName
Price
Category
Manufacturer
Gizmo
$19.99
Gadgets
GizmoWorks
Powergizmo
$29.99
Gadgets
GizmoWorks
SELECT *
FROM
Product
WHERE category=‘Gadgets’
“selection”
163
Simple SQL Query
Product
PName
Price
Category
Manufacturer
Gizmo
$19.99
Gadgets
GizmoWorks
Powergizmo
$29.99
Gadgets
GizmoWorks
SingleTouch
$149.99
Photography
Canon
MultiTouch
$203.99
Household
Hitachi
SELECT PName, Price, Manufacturer
FROM
Product
WHERE Price > 100
“selection” and
“projection”
PName
Price
Manufacturer
SingleTouch
$149.99
Canon
MultiTouch
$203.99
Hitachi
164
A Notation for SQL Queries
Input Schema
Product(PName, Price, Category, Manfacturer)
SELECT PName, Price, Manufacturer
FROM
Product
WHERE Price > 100
Answer(PName, Price, Manfacturer)
Output Schema
165
Selections
What goes in the WHERE clause:
• x = y, x < y, x <= y, etc
• For number, they have the usual meanings
• For CHAR and VARCHAR: lexicographic ordering
• Expected conversion between CHAR and VARCHAR
• For dates and times, what you expect...
• Pattern matching on strings: s LIKE p
166
The LIKE operator
•
•
s LIKE p: pattern matching on strings
p may contain two special symbols:
•
•
% = any sequence of characters
_ = any single character
Product(Name, Price, Category, Manufacturer)
Find all products whose name mentions ‘gizmo’:
SELECT *
FROM
Products
WHERE PName LIKE ‘%gizmo%’
167
Eliminating Duplicates
Category
Gadgets
SELECT category
FROM
Product
Gadgets
Photography
Household
Compare to:
Category
SELECT DISTINCT category
FROM
Product
Gadgets
Photography
Household
168
Ordering the Results
SELECT pname, price, manufacturer
FROM
Product
WHERE category=‘gizmo’ AND price > 50
ORDER BY price, pname
Ordering is ascending, unless you specify the DESC keyword.
Ties are broken by the second attribute on the ORDER BY list, etc.
169
Ordering the Results
SELECT Category
FROM
Product
ORDER BY PName
PName
Price
Category
Manufacturer
Gizmo
$19.99
Gadgets
GizmoWorks
Powergizmo
$29.99
Gadgets
GizmoWorks
SingleTouch
$149.99
Photography
Canon
MultiTouch
$203.99
Household
Hitachi
170
?
Ordering the Results
Category
SELECT DISTINCT category
FROM
Product
ORDER BY category
Gadgets
Household
Photography
Compare to:
?
SELECT DISTINCT category
FROM
Product
ORDER BY PName
171
Joins in SQL
• Connect two or more tables:
Product
PName
Price
Category
Manufacturer
Gizmo
$19.99
Gadgets
GizmoWorks
Powergizmo
$29.99
Gadgets
GizmoWorks
SingleTouch
$149.99
Photography
Canon
MultiTouch
$203.99
Household
Hitachi
Company
CName
StockPrice
Country
GizmoWorks
25
USA
Canon
65
Japan
Hitachi
15
Japan
What is
the Connection
between
them ?
172
Joins
Join
between Product
and Company
SELECT PName, Price
FROM
Product, Company
WHERE Manufacturer=CName AND Country=‘Japan’
AND Price <= 200
173
Joins in SQL
Product
Company
PName
Price
Category
Manufacturer
Cname
StockPrice
Country
Gizmo
$19.99
Gadgets
GizmoWorks
GizmoWorks
25
USA
Powergizmo
$29.99
Gadgets
GizmoWorks
Canon
65
Japan
SingleTouch
$149.99
Photography
Canon
Hitachi
15
Japan
MultiTouch
$203.99
Household
Hitachi
SELECT PName, Price
FROM
Product, Company
WHERE Manufacturer=CName AND Country=‘Japan’
AND Price <= 200
174
PName
Price
SingleTouch
$149.99
Joins
Product (pname, price, category, manufacturer)
Company (cname, stockPrice, country)
Find all countries that manufacture some product in the ‘Gadgets’ category.
SELECT Country
FROM
Product, Company
WHERE Manufacturer=CName AND Category=‘Gadgets’
175
Joins in SQL
Product
Company
PName
Price
Category
Manufacturer
Cname
StockPrice
Country
Gizmo
$19.99
Gadgets
GizmoWorks
GizmoWorks
25
USA
Powergizmo
$29.99
Gadgets
GizmoWorks
Canon
65
Japan
SingleTouch
$149.99
Photography
Canon
Hitachi
15
Japan
MultiTouch
$203.99
Household
Hitachi
SELECT Country
FROM
Product, Company
WHERE Manufacturer=CName AND Category=‘Gadgets’
Country
What is
the problem ?
What’s the
solution ?
??
??
176
Joins
Product (pname, price, category, manufacturer)
Purchase (buyer, seller, store, product)
Person(persname, phoneNumber, city)
Find names of people living in Seattle that bought some product in
the ‘Gadgets’ category, and the names of the stores they bought such
product from
SELECT DISTINCT persname, store
FROM
Person, Purchase, Product
WHERE persname=buyer AND product = pname AND
city=‘Seattle’ AND category=‘Gadgets’
177
Disambiguating Attributes
• Sometimes two relations have the same attribute:
Person(pname, address, worksfor)
Company(cname, address)
SELECT DISTINCT pname, address
FROM
Person, Company
WHERE worksfor = cname
Which
address ?
SELECT DISTINCT Person.pname, Company.address
FROM
Person, Company
WHERE Person.worksfor = Company.cname
178
Tuple Variables
Product (pname, price, category, manufacturer)
Purchase (buyer, seller, store, product)
Person(persname, phoneNumber, city)
Find all stores that sold at least one product that the store
‘BestBuy’ also sold:
SELECT DISTINCT x.store
FROM
Purchase AS x, Purchase AS y
WHERE x.product = y.product AND y.store = ‘BestBuy’
Answer (store)
179
Tuple Variables
General rule:
tuple variables introduced automatically by the system:
Product ( name, price, category, manufacturer)
SELECT name
FROM
Product
WHERE price > 100
Becomes:
SELECT Product.name
FROM Product AS Product
WHERE Product.price > 100
Doesn’t work when Product occurs more than once:
In that case the user needs to define variables explicitely.
180
Renaming Columns
Product
PName
Price
Category
Manufacturer
Gizmo
$19.99
Gadgets
GizmoWorks
Powergizmo
$29.99
Gadgets
GizmoWorks
SingleTouch
$149.99
Photography
Canon
MultiTouch
$203.99
Household
Hitachi
SELECT Pname AS prodName, Price AS askPrice
FROM
Product
WHERE Price > 100
Query with
renaming
181
prodName
askPrice
SingleTouch
$149.99
MultiTouch
$203.99
Data Model
182
Exercise: Data Model
1. Lihat kembali Activity Diagram, Use Case
Diagram, Sequence Diagram dan Class
Diagram yang telah anda buat
2. Lanjutkan dengan membuat Data Model (ER
Diagram) dengan menggunakan EA
3. Data Model (ER Diagram) diekstraksi dari
Boundary Class
4. Generate SQL code dari ER Diagram yang
dibuat
183
4.6 Deployment Diagram
184
Deployment Diagram
• Servers
Node
• Mainframes, Minis, Micros
Artifact
• Clients
• Input/Output HW used by users
• Terminals, PCs, special purpose HW
• Network
• HW and SW to connect clients to servers
• Nodes
•
•
•
•
Node with
Deployment Artifact
Any piece of hardware in the model
A computational resource
Labeled by its name
Stereotype to label the type of node
• Artifacts
• Piece of the information system, such as software or a database table
• Node with Deployed Artifact
• Shows artifact placed on a physical node
• Good for showing distribution data or software
• Communication paths
• Links between nodes of the network
185
Communication
Path
Diagram Examples
186
Deployment Diagram (3 Tier)
deployment DD Sistem ATM
Application Serv er
Rich Client
Web Container
EJB Container
«artifact»
JSP
«artifact»
JFC
«artifact»
SessionBean
DBMS
«artifact»
MySQL
«artifact»
JSF
«artifact»
JVM
«artifact»
Zend Optimizer
«artifact»
Serv let
187
Exercise: Deployment Diagram
1. Lihat kembali Activity Diagram, Use Case
Diagram, Sequence Diagram dan Class
Diagram yang telah anda buat
2. Lanjutkan dengan membuat Deployment
Diagram
188
4.7 Nonfunctional Requirements
189
SDLC and Artifacts
1. Planning
System
Proposal
1.1 System Request
1.2 Feasibility Analysis
2. Analysis
2.1 Use Case Diagram
2.2 Activity Diagram
2.3 Sequence Diagram
System
Specification
3. Design
3.1 Class Diagram
3.2 Deployment Diagram
3.3 User Interface Design
3.4 Data Model
4. Implementation
New
Software
4.1 Program Code
4.2 Testing Plan
4.3 Documentation
190
Nonfunctional Requirements
• Operational
• Specify the operating environment
•
•
•
•
Operating system
System software
Information systems
Physical environment
• Technical Environment
• Type of hardware and software the system will require
• Focus on
•
•
•
•
Hardware platforms
Operating System
Database system
System software
191
Nonfunctional Requirements
• System Integration
• Interaction with other systems
• Both internal and external systems
• Import/export data formats
• Portability
• Response to changing environments
• New platforms
• New data formats
• Maintainability
• Expected business requirement changes
• How easily can the system be updated
192
Performance Requirements
• Speed
• Response time of the system
• Local action are faster
• Remote services are slower
• Transaction update time
• How long for a change to propagate throughout the system, e.g. Inventory updates
• Capacity
• Number of users
• Total and simultaneous
• Affects hardware specification
• Load balancing?
• Volume of data
• Availability and Reliability
• Specify available times
• When can the users count on the system
• Work week only?
• Global usage?
• Permissible failure rate
• Be realistic
• Security
• Protect from disruption and data loss
193
Identifying Threats to the System
• Threat
• Any potential adverse occurrence that can harm the application or
its data
• Threats come from
• Internal sources
• External sources
• Two categories of threats
• Disruptions, destruction and disaster
• Disruption – can't use app for awhile
• Destruction – corrupt files, crash HD
• Disaster – natural or man-made
• Unauthorized access
• Internal and external
194
Most Common Threats
195
Assessing the Risk of Each Threat
• After the threats are identified
• List threats across top of page
• List components down side
• In order of importance
• List controls in the cells created
• Control – Something that stops or mitigates the
consequences of the threat
196
Assessing the Risk of Each Threat
197
Creating Controls
• Controls for disruption, destruction and disaster
• redundancy
• Fault tolerant
• Auto transfer
• disaster recovery plans
• Virus protection
• Controls for unauthorized access
•
•
•
•
•
Security policy and training
Screen users
Use authentication and encryption
Firewalls
Physical security
198
Additional Controls Include
• Passwords and encryption
• Firewalls
199
Exercise: SAD untuk System Request
1. Lihat kembali ke System Request yang sudah dibuat
2. Rapikan kembali System Request
3. Selesaikan semua diagram untuk System Request
tersebut:
1.
2.
3.
4.
5.
6.
7.
Use Case Diagram
Sequence Diagram (untuk setiap use case diagram)
Activity Diagram (untuk setiap use case diagram)
Class Diagram
Data Model
User Interface Design
Deployment Diagram
4. Kirimkan EAP file ke [email protected]
200
Catatan Review
• Gunakan pola Subject-Verb-Object (S-V-O) untuk use case
diagram (Actor – Use Case)
• Use case diagram adalah apa yang dilakukan actor di
system, bukan apa yang dilakukan oleh system
• Pada sequence diagram perhatikan transaksi yang harusnya
datangnya dari actor, dan bukan dari object lain
• Naming untuk object dan class adalah kata benda (noun),
untuk message di sequence diagram (method) adalah
katakerja
• Class diagram tidak menunjukkan alur, tapi menunjukkan
struktur dan komposisi dari sistem yg kita bangun
• Boundary class akan menjadi UI Design, entity class akan
menjadi Data Model
201
Exercise: Systems Analysis and Design
• Lakukan sistem analysis and design yang menghasilkan:
1. Use Case Diagram
4.
Class Diagram
7.
User Interface Design
2. Activity Diagram
5.
Deployment Diagram
8.
Use Case Point (Estimation)
3. Sequence Diagram
6.
Data Model
• Generate laporan dokumen dari artifact di atas
• Pilih salah satu aplikasi di bawah:
1.
Aplikasi Rental Mobil
7.
Aplikasi Penjualan Buku Online
2.
Aplikasi Pengelolaan Klinik
8.
Aplikasi Penjualan Tiket Kereta Online
3.
Aplikasi Pengelolaan Apotik
9.
Aplikasi Manajemen Universitas Online
4.
Aplikasi Pengelolaan Service Mobil
10. Aplikasi Penjualan Laptop Online
5.
Aplikasi Penjualan Motor
11. Aplikasi Perpustakaan Digital
6.
Aplikasi Pengelolaan Perpustakaan
12. Aplikasi Pengelolaan Project Software
Kirim file EAP ke: [email protected]
202
Referensi
1. Alan Dennis et al, Systems Analysis and Design with
UML 4th Edition, John Wiley and Sons, 2013
2. Kenneth E. Kendall and Julie E Kendall, Systems Analysis
and Design 8th Edition, Prentice Hall, 2010
3. Hassan Gomaa, Software Modeling and Design: UML,
Use Cases, Patterns, and Software Architectures,
Cambridge University Press, 2011
4. Gary B. Shelly and Harry J. Rosenblatt, Systems Analysis
and Design 9th Edition, Course Technology, 2011
5. Howard Podeswa, UML for the IT Business Analyst 2nd
Edition, Course Technology, 2009
6. Jeffrey A. Hoffer et al, Modern Systems Analysis and
Design 6th Edition, Prentice Hall, 2012
203