UML Untuk Analisis dan Disain Sistem
1
Pokok Bahasan
System Choice
Overview,
principles
techniques
Rich Picture
FACTOR
Perbandingan antara Metoda terstruktur dan metoda berorientasi object
• Pengenalan Analisa dan Desain berorientasi object
2
The computerized System’s Context System
user Problem Domain
Application Domain
System choice is about determing the system’s context 3
Step back! What are the developers to do? What is this about?
System
user
Principles: • Memahami situasi • Menumbuhkan gagasan baru • Menggambarkan alternatif sistem
Problem Domain
Application Domain
4
Activities in ’System System Choice’ Choice Ideas
Situation
Creates anchoring for
Requirements for use
Problem Domain Analysis
Systems
Model
System definition
Application Domain Analysis
Component Design Specifications of components
Specifications of architecture
System definition: Suatu uraian ringkas dari suatu sistem terkomputerisasi y dalam bahasa alami dinyatakan
Architectural Design
5
Describe the sitaution in a rich picture Memusatkan pada stabilitas atau perubahan Memproses seperti pekerjaan, produksi, pengolahan informasi, perencanaan, kendali, k d li pengembangan, dll. Struktur seperti produksi, aplikasi, lik i komunikasi, k ik i persetujuan, kepemilikan, keanggotaan, kuasa, dll. Ri h pictures, Rich i t bukan b k gambaran kacau (tidak beraruturan).
#1 Tradition vs. change Individual info.
#2
#3 Pool Standard info.
#4
Reorganizing Personnel info.
Resources
#5
Plans
#6
Report
Coordinating New entity y
6
Rich picture showing stability reception of calls
dispatcher
tasks
customers
Where is it? When are they ready?
50 cars
h hospital it l
emergency vehicle
7
Create new ideas Contoh z
Lihat didalam sistem akuntansi z
z
z
z
Pelajari sistem yang berjalan Memperhatikan spreadsheets Memperhatikan paket standard Belajar j ERP sistem seperti SAP
Mengadakan percobaan dengan prototipe: z z z z z
Perencanaan Pengembangan Persiapan Test Peringkasan
Metaphor z
For a library: y z z z
Store Shop School
8
Example of a prototype’s prototype s contents Focus
Limitations Prerequisites
Interface
Hanya satu gambar-dan lapisan berhubungan dengan peserta
Full Layout of participant picture with all keys y and fields included
Functions
Pembaharuan data No other functions peserta
Model
Semua kunci memberikan jjawaban yang y g informatif Pendaftaran partisipan harus dikerjakan Harus bisa g mengatasi sedikitnya 10 peserta berikut pembayarannya
9
System definition (FACTOR) Functionality: Fungsi sistem yang mendukung tugas application-domain. Application domain: Bagian dari suatu organisasi yang administrate, monitor, atau mengendalikan problem domain. Conditions: Dengan kondisi yang bagaimana sistem akan dikembangkan dan digunakan. Technology: Semua Teknologi yang digunakan untuk mengembangkan dan menjalankan sistem. Objects: object Yang utama didalam problem domain. p Responsibility: tanggung jawab sistem (kegunaan) secara keseluruhan dalam hubungannya dengan konteks sistem.
F: Support for program design. Automate participant registration. A: Administration of speakers p and participants. Control of conference papers. Program design. Participant registration. C: Volunteer labor has widely varying administrative d i i t ti experience. i Development to proceed despite contradictory and missing requirements. T: Cheap PC platform with current tools. O: Speakers and participants. Conference papers and program program. R: Administrative tool and communication medium.
10
Define systems Functionality 1: Daftar gp peserta dan Informasi tentang menghasilkan daftar peserta (lengkap). Responsibility 1: Mendukung program Disain dengan menghasilkan overview dan mengijinkan pemakai untuk menambahkan komentar serta disimpan pada versi yang berbeda. Mendukung operasional konferensi dengan menekankan pada potensi permasalahan regular interval.
Functionality 2: Untuk peserta seperti p mendaftarkan p pengarang, pembicara, atau penulis resensi buku. Mendukung administrasi pembayaran dan undangan. undangan Mendukung pengembangan program konferensi, mencakup pendaftaran, penerimaan paper, dan sesi. Responsibility 2: Menyusun Rencana Konferensi secara otomatis Menghasilkan otomatis. program dari sesi yang diusulkan dan meninjau ulang paper yang masuk. 11
Overview of ‘System Choice’ Purpose
•
Untuk menentukan (menyepakati) karakteristik sistem secara menyeluruh.
Concepts
•
System y definition: Suatu uraian ringkas g dari suatu sistem terkomputerisasi dinyatakan dalam bahasa alami.
Principles
Memahami situasi • Menumbuhkan gagasan baru • Menggambarkan alternatif sistem
Results
•
•
Suatu definisi sistem yang memenuhi ukuran FAKTOR
12
Perkembangan Metode Analisis dan Desain Sistem
• • •
Metode Tradisional Metode Terstruktur M t d berorientasi Metode b i t i objek bj k (Object Oriented)
Metode Tradisional • Berkembang dari pemrograman tradisional • Kontrol Alur (urutan, keputusan, loop) • Sistem Flow Chart • Hampir selalu dimulai dengan pemikiran t t tentang file fil secara fisik fi ik • Tidak berorientasi pada kebutuhan informasi
Metode Terstruktur • Dimulai pada tahun 1977 • Dimulai dengan mencoba melihat pandang g logical g sistem dari sudut p • Melihat data sebagai sumber proses
Metode DFD (control flow, State Transistion diagram) Normalisasi E-R Diagram
Normalisasi
Normalisasi Normalisasi
Keterangan
1 NF
Any Relation
2 NF
All non key attributes are dependent on all of the keys
3 NF
There are no transitive dependencies
BCNF
E er determinant is a candidate Key Every Ke
4 NF
There are no multivalue dependencies
5 NF
Th are no Joint There J i t dependencies d d i
DK/NF
All constraints on relation are logical consequences of domain and Keys
Metode Terstruktur Invoice Invoice_no Cust_name Date_Purchase Item_no Description Unit_Price Quantity Total Total_amount Invoice Invoice_no Cust_no Date Purchase Date_Purchase Total_amount
Customer Cust_no Cust_name Cust_address Balance
Inv_detail Invoice_no Item_no Unit_Price Quantity Total
y Inventory Item_no Item name Unit_price Qty_on_hand Qty_purchased Amnt_purchased Qty sold Qty_sold Amnt_sold
Activity Breakdown by Size Activity Architecture/Design D t il d d Detailed design i Code/debuging Unit Test I t Integration ti System Test
Small Project (2.500 lines of Codes) 10% 20% 25% 20% 15% 10%
Large Project (500.000 lines of Codes) 30% 20% 10% 5% 20% 15%
Mengapa perlu membuat rencana gambar yang jelas dalam pembuatan sistem software ft ?
Metode Object O t Oriented d • Mulanya dari Oriented OOPi(Object Programming) yang berkembang menjadi OOD (Object Oriented Design) dan akhirnya menjadi OOA (Object Oriented Analysis) • Berhubungan erat dengan E-R Model • Keuntungannya K t d darii analisa, li design d i sampaii ke implementasi menggunakan notasi yang sama • Makin banyak organisasi yang mengimplementasikan metoda OO
B b Beberapa Metode M t d OO • • • •
Booch Coad/Yourdon Schaler-Mellor Object Modeling Technic
• • • •
Nassi-Schneiderman Gane-Sarson Jackson Jacobson Use case
Konsep Object • Encapsulation • Polymorphism • Inheritance
Keuntungan dari OO •
Merupakan konsep yang umum yang dapat digunakan untuk memodel hampir semua phenomena dan dapat dinyatakan dalam bahasa umum (natural language)
– Noun menjadi object atau class – Verb menjadi behaviour – Adjective menjadi attributes •
Memberikan informasi yang jelas tentang context dari system
•
Mengurangi biaya maintenance
– Memudahkan untuk mencari hal yang akan diubah – Membuat perubahan menjadi local, tidak bepengaruh pada modul yang lainnya
System Context System
user Problem Domain
Application Domain
Model Problem Domain
Payroll System
Air Traffic
Telephone Si l Signal
• Employee • Contracts • Work Schedule • • • • •
Plane Flight Departure Flight Corridors Runaway Flight Position
• • • •
Signal Line T Transmitter itt Receiver
Application Domain
Personal Office
Part of the air traffic controller’s job
Part of the technical jjob
System Kumpulan dari komponen yang mengimplementasikan i l t ik model d l dari d i requirement, function dan interface
System Architecture user Other system Interface Function Model
system
• Mudah dimengerti • Tidak Tid k ada d keraguan k
Air Traffic Controller Model Component
Function Component
Interface Component
Planes, flight departures, flight corridors, position, and the relation among them
Plane change position, system t update d t function, f ti and change the model componen’s state
• Monitors, Printouts, other facilites to interact w/ users • Connect to other system
Siklus Pengembangan Dengan OOAD
Requirements for use
Problem Domain Analysis
Model
Application Domain Analysis
Component Design Specifications of components
Specifications of architecture Architectural Design
Siklus Pengembangan d dengan OOAD Application Domain analysis Usage Functions Interface
Problem Domain analysis •Classes •Structure •Behavior Component design •Criteria •Component Component s •Processes Architecture Design •Model Component •Function Component •Connected Components
Problem Domain Analysis Ada 3 kegiatan • Mencari elemen dari Problem Domain yaitu Objects, classes, dan events • Buat model berdasarkan hubungan strutural antara class dan objects yang dipilih • Interaksi antar object dan class serta behaviour dari object dan class
Analisis Problem Domain System Definition
System definition: Suatu uraian ringkas dari suatu sistem terkomputerisasi yang dinyatakan dalam bahasa alami
Behaviour
Classes Iterate
Structure Model
Analisis Problem Domain Activity Classes Structure
Content
Concepts
Which objects and part of events are p the object system?
• Class • Object j • Event
How are classes and objects conceptually tied together?
• • • • • • •
Behaviour Which dynamic
properties do the objects have?
Generalisation Aggregation Association Cluster Event sequence Behavioural pattern Attribute
Basis Analisis Problem Domain • Memodel dunia nyata seperti yang akan dilihat oleh pemakai • Buat dahulu secara umum baru ke detil
35
