modul perkuliahan analisa perancangan...
TRANSCRIPT
MODUL PERKULIAHAN
ANALISA
PERANCANGAN BERORIENTASI OBJEK
Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana
Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh
Ilmu Komputer Teknik Informatika
01 87016 Tim Dosen
Abstract Kompetensi
SDLC, RAD, Design Tersturktur, Class dan Object
Memahami siklus pengembangan sistem, memahami metodhologi pengembangan sistem, mengenal UML
2013 2 Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Karakteristik Dasar Sistem Object Oriented
1. Pendahuluan
OOSAD (Object Oriented System Analysis and Design) merupakan paradigma
analisa dan perancangan sistem yang titik perhatiannya adalah penggambaran struktur dan
tingkah laku Teknik Informatika yang meliputi data dan process. Secara statis struktur data
dan process akan menunjukkan hubungan antar bagian dari sistem, sedangkan secara
dinamis menunjukkan bagaimana bagian-bagian sistem tersebut akan berinteraksi antara
satu dengan lainnya. Untuk penggambaran tersebut diperlukan pemahaman dasar dari
class, object, method, message, encapsulation, information hiding, inheritance,
polymorphism, dan dynamic binding.
1.1. Class dan Object
CLASS adalah template/cetakan yang digunakan untuk mendefinisikan suatu
instance/contoh kejadian yang disebut object. Object adalah contoh kejadian dari class.
setiap object pasti akan berasosiasi tepat dengan satu class.
Setiap object memiliki attributes yang berisikan informasi mengenai object tersebut. State
dari sebuah object ditentukan oleh nilai dari attributes dan relationshipnya pada suatu waktu
tertentu.
Setiap object juga memiliki behaviour yang menspesifikasikan apa yang bisan dilakukan
sebuah object.
2013 3 Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
1.2. Methods dan Messages
Method merupakan implementasi dari behaviour(kelakukan) sebuah object. Method adalan sebuah
action(tindakan) yang dapat dilakukan oleh object. Method dapat dianalogikan dengan fungsi
sebagaimana terdapat didalam bahasa C. Message merupakan informasi yang dikirimkan ke Object
yang akan menjadi pemicu dari dilakukannya sebuah tindakan.
1.3. Encapsulation dan Information Hiding
Pemikiran mengenai encapsulation dan Information hiding sudah ada sejak jaman
dahulu kala. Encapsulation adalah kombinasi dari proses dan data yang diletakkan didalam
sebuah class. Didalam OOSAD yang dimaksudkan dengan
Encapsulation adalah meletakkan attribute dan behaviour kedalam sebuah object yang
dispesifikasikan didalam class. didalam notasi yang digunakan UML 2.0 attribute diletakkan
pada bagian atas sedangkan behaviour diletakkan pada bagian bawah dari kotak.
Information hiding adalah sebuah cara berpikir dimana informasi yang diperlukan oleh
penggunalah yang akan ditampilkan sedangkan yang tidak diperlukan tidak usah
ditampilkan/diberikan. Konsekuensinya yang dapat diakses adalah bagian dari object yang
digunakan untuk menerima perintah dan memberikan informasi kepada pengguna object
tersebut. Sehingga object diperlakukan seperti sebuah kotak hitam.
The only information that an object needs to know is the set of operations, or methods, that
other objects can perform and what messages need to be sent to trigger them.
2013 4 Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
1.4. Inheritance
Inheritance atau pewarisan digunakan untuk mengidentifikasi object/class yang memiliki
tingkat yang lebih tinggi dan lebih general. Atributes dan methods yang sama
dikelompokkan menjadi sebuah superclass. Biasanya superclass diletakkan diatas dan
turunannya diletakkan dibawah. Hubungan inheritance yang terjadi adalah A KIND OF.
Subclass akan mewarisi attributes dan methods dari class yang berada diatasnya. Artinya
subclass berisi attributes dan methods dari superclass yang berada diatasnya.
Class yang berada didalam rantai hierarchy pasti akan ada yang memiliki instance/contoh
kejadian. Class yang memiliki contoh kejadian disebut concrete class. Ada juga class yang
menjadi superclass yang menjadi template bagi sebagian dari class yang berada
dibawahnya. Class tersebut merupakan abstract class.
2013 5 Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Pada contoh dibawah ini Person adalah abstract class sedangkan Doctor dan Patient
merupakan concrete class
1.5. Polymorphism dan Dynamic Binding
Polymorphism artinya message yang sama diinterpretasikan/memiliki arti/bentuk yang
berbeda. Sebagai contoh jika kita beri perintah draw kepada object segi empat, segi tiga,
dan lingkaran akan menjalankan perintah yang berbeda. Dibawah ini adalah contoh
polymorphism :
int kali(int a, int b);
int kali(int a, int b, int c);
maka fungsi mana yang akan dijalankan tergantung kepada argumen yang disertakan.
Polymorphism dapat terlaksanya karena adanya dynamic binding. Dynamic, atau, late
binding adalah teknik/cara penundaan penentuan jenis object sampai pada saat run-time.
Artinya method mana yang akan dijalankan ditunda sampai system/program berjalan.
Kontrasnya adalah static binding dimana setiap methods sudah ditentukan pada saat
kompilasi.
2013 6 Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
2. UML Versi 2.0
UML (Unified Modeling Language) versi 2 mendefinisikan sehimpunan notasi yang terdiri
dari 14 technique pembuatan diagram yang digunakan untuk memodelkan sistem. Diagram
dikelompokkan menjadi 2 yaitu :
1. Structure Modelling Diagram yang digunakan untuk memodelkan struktur sistem.
2. Behaviour Modelling Diagram yang digunakan memodelkan tingkah laku sistem.
2.1. Structure Diagram
Structure diagram menggambarkan cara untuk merepresentasikan hubungan static dan data
yang terdapat didalam Teknik Informatika. Adapun diagram yang digunakan adalah :
1. Class : relationship between classes
2. Object : Relationships between objects
3. Package : Group UML elements together to form higher level constructs
4. Deployment : Shows the physical architecture and software components of system
5. Component : Physical relationships among software components
6. Composite Structure : Illustrates internal structure of a class
2013 7 Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
2.2. Behaviour Diagram
Behaviour diagram menggambarkan aspek dinamis dari sistem, yaitu bagaimana bekerjanya
sistem. Adapun diagram yang digunakan adalah :
a. Activity : Illustrates business workflows.
b. Sequence : Time-based ordering Behavior of objects activities in a use case.
c. Communication : Communication among a set of collaborating objects of an activity.
d. Interaction Overview : Overview of flow of control of a process
e. Timing Diagram : Portray the interaction between objects along a time axis.
f. Behavioral State Machine : Examines behavior of one class.
g. Protocol State Machine : Shows dependencies of different interfaces of a class
h. Use-Case : Captures business requirements and Illustrates interaction between
system and environment
2.3. Extension Mechanism
Extension Mechanism memungkinkan perluasan model yang digunakan, karena boleh jadi
model didalam suatu aktifitas OOSAD ada notasi lain yang diperlukan. Penambahan notasi
disebut extension mechanism :
a. Stereotypes : Gives ability to incrementally extend UML
b. Tagged Values : Add new properties to base elements
c. Constraints : Place restrictions on use of model elements
d. Profiles : Group model elements into a package
3. Object Oriented Systems Analysis and Design
Pendekatan OO dapat menggunakan methodology apapun, termasuk yang terstruktur,
tetapi umumnya lebih berhubungan dengan methodology yang bersifat RAD. Yang harus
diperhatikan didalam OOSAD adalah pemodelan dunia nyata berarti memodelkan : DATA
DAN PROSES yang susah dipisahkan. UML bersifat use-case drive, architecture-centric,
iterative dan incremental.
3.1. Use-Case Drive
2013 8 Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Perangkat pemodelan utamanya adalah Use Case yang digunakan untuk menjelaskan
tingkah laku dari sistem
3.2. Architecture Centric
Architecture software yang akan dibuat haruslah mengikuti dan menghasilkan standard yang
meliputi spesifikasi, construction, dan documentation.
3.3. Itterative dan Incremental
Pengembangan dilakukan secara itterative dan incremental. Dimana setiap pengulangan
akan mendekatkan produk ke spesifikasi dari pengguna akhir.
3.4. Unified Process
Unified process mengunakan methodolgy yang secara khusus memetakan bagaimana
menggunakan perangkat methodoly yang dimiliki oleh UML. Jika UML memiliki struktur
untuk menjelaskan hubungan struktural dan behaviour dari sebuah Teknik Informatika.
RUPS menyediakan dukungan methodology penggunaan notasi UML.
Unified processadalah proses pengembangan sistem yang dijelaskan melalui tahapan-
tahapan dan workflows. Tahapannya (Phases) adalah :
1. Inception. Merupakan tahapan perencanaan. Business Case dibuat dalam tahapan
ini.
2. Elaboration. Mrupakan tahapan dimana dilakukan analisa dan perancangan sistem
secara mendalam. Pada tahapan ini dilakukan pembelajaran mengenai bagaimana
sistem yang akan dibuat. vision document, penyelesaian business case, revisi
penilaian resiko, dan menyelesaikan project plan secara terinci agar pihak-pihak
yang berkepentingan dapat setuju dengan pembuatan sistem yang final.
Deliverablesnya meliputi notasi-notasi struktur dan behaviour, executable of baseline
version. Baseline harus ditetapkan dengan baik pada tahapn ini karena merupakan
dasar bagi pekerjaan lanjutan untuk membuat sistem yang jadi.
3. Construction. Tahapan ini terfokus pada pemrogram dan pekerjaan teknis untuk
membuat sistem. Berarti merupakan implemention workflows. Disamping itu
requirement, analysis, dan design workflows juga dilibatkan dalam tahapan ini.
2013 9 Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Version control dari configuration and change management, menjadi sangat penting
dalam tahapan ini. Deliverables yang utama adalah versi alpha maupun beta dari
sistem yang dibuat.
4. Transition. Tahapan ini merupakan pemasangan dari sistem yang sudah jadi berarti
deliverablesnya adalah sistem yang sudah jadi, berikut dokumentasi-dokumentasi
pendukungtermasuk didalamnya manuals, support plan, dan upgrading plan.
Figure 2-7 The Unified Process
2013 10 Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Sedangkan workflowsnya meliputi :
1. Business modelling digunakan untuk menemukan permasalahan dan dapat
mengidentifikasi projects yang mungkin dikerjakan dalam organisasi.
2. Requirements digunakan untuk melakukan elisitasi kebutuhab baik secara fungsional
dan nonfungsional.
3. Analysis merupakan pekerjaan yang meliputi analisis dari problem/business domain.
4. Design meupakan pekerjaan yang mentransformasikan analysis model kedalam
bentuk yang daat digunakan untuk implementasi sistem yaitu : design model. Design
model merupakan peningkatan yang lebih terinci dari analysis model dengan
penambahan classes/object dan model-model lain yang akan digunakan untuk
pembuatan sistem yang nantinya akan dibangun.
5. Implementation merupakan pekerjaan pembangunan sistem. Aktifitas yang
dilakukan, sebagai contoh, adalah pemrograman.
6. Test atau pengujian bertujuan agar produk yang dibuat memenuhi kriteria kualitas
yang telah ditentukan untuk sistem yang dibuat.
7. Deployment. Bagian ini berhubungan dengan tahapan transisi pada RUP.
Aktifitasnya meliputi packaging, distribution , beta testing, dan pada akhirnya adalah
sistem yang telah jadi.
8. Project management. Merupakan cross-phase flow. Contoh dari aktifitas yang
dilakukan dalam tahap ini adalah : risk identification & management, scope
management, time estimation, cost estimation, dan tracking progress.
9. Configuration and change management bertujuan untuk menjejaki sampai sejauh
mana sistem yang sekarang sedang dibuat.
10. Environment. Dalam pengembangan sistem sudah tentu bermacam-macam
perangkat digunakan. Environmental workflows adalah kelompok perkerjaan yang
berhubungan dengan penyediaan perangkat untuk pembuatan sistem.
Tahapan-tahapan dialam RUP membantu analis dalam mengembangkan Teknik
Informatika secara itterative dan incremental. Tahapan-tahapan tersebut
menjelaskan bagaimana Teknik Informatika berevolosi. Tergantung kepada tahapan
yang mana, tingkat aktivitas dalam setiap workflows akan bervariasi.
2013 11 Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Daftar Pustaka
Alan Denis, Barbara Haley Wixon, David Tagerden, System Analys and Design : an Object –
Oriented Approach with UML 2.0, John Willey and Sons, 2005
Henry C. Lucas Jr., The Analysis, Design and Implementation of Information Systems 4th,
McGraw Hill, 1992
Satzinger, Jackson, Burd, Object-Oriented Analysis and Design with the Unified Process,
Course Technology, 2005
Simon Bennet, Steve McRobb and Ray Farmer, Object-Oriented System Analysis and
Design Using UML, McGraw Hill, 2006
Wendy and Michael Boggs, UML with Rational Rose 2002, Sibex Inc., 2002
MODUL PERKULIAHAN
ANALISA
PERANCANGAN BERORIENTASI OBJEK
Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana
Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh
Ilmu Komputer Teknik Informatika
02 87016 Tim Dosen
Abstract Kompetensi
Memahami awal dari project dan memahami data
Memahami hubungan Teknik Informatika dan kebutuhan bisnis dan pengelolaan data
2013 2 Analisa Perancangan Berorientasi Objek Modul 02 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Determinancy dan Functional Dependency Determinancy digunakan untuk menentukan “ketergantungan” sebuah attribute didalam tabel. Sebuah attribute dinyatakan sebagai determinant (penentu) attribute yang lain jika satu nilai attribute tersebut berpasangan tepat dengan attribute yang lain Definisi : Dalam Satu relation R, attribute Y dikatakan tergantung fungsional kepada attribute X jika setiap nilai X didalam R tepat berasosiasi dengan satu nilai Y, dimana X dan Y mungkin composite
Perhatikan himpunan dibawah ini :
Notasi : R.X R.Y Contoh :
1. Pada Tabel Penduduk(NoKTP, Nama, …) : Penduduk.NoKTP Penduduk.Nama Satu Nama berpasangan dengan banyak NoKTP, tetapi satu NoKTP tepat berpasangan dengan satu nama. NoKTP dinyatakan sebagai determinan dari Nama, dan Nama dinyatakan tergantung fungsional kepada NoKTP.
2. Pada Tabel Matakuliah(KodeMK, NamaMK, SKS) :
Matakuliah.KodeMKMatakuliah.SKS Satu nilai SKS berpasangan dengan banyak KodeMK, tetapi satu KodeMK tepat berpasangan dengan satu nilai SKS. KodeMK dinyatakan sebagai determinan dari SKS, dan SKS dinyatakan tergantung fungsional kepada KodeMK.
3. Perhatikan latihan normalisasi yang diberikan pada contoh Invoice : (Invoice.InvoiceNo + Invoice.ItemNo) Invoice.Qty. Pasangan Nilai InvoiceNo dan
UoD : R
Y1
Y2
X1
X2
X3
2013 3 Analisa Perancangan Berorientasi Objek Modul 02 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
ItemNo menjadi determinan bagi Qty (Jumlah barang yang dibeli yang dicatat didalam tabel invoice). Qty menjadi berarti jika dipasangkan dengan InvoiceNo dan ItemNo sekaligus.
4. Perhatikan latihan normalisasi yang diberikan pada contoh invoice : Invoice.InvoiceNoInvoice.CustomerNo. Satu InvoiceNo akan berhubungan dengan satu CustomerNo, berarti pengertian sederhananya adalah : Sebuah invoice hanya dapat diterbitkan untuk seorang customer, sedangkan seorang customer bisa diberi banyak invoice.
Penentuan ketergantungan fungsional akan mementukan tabel-tabel yang akan dibuat. Perhatikan latihan normalisasi dibawah ini : PT. Mercon Trading Indonesia Jl. Meruya Selatan No. 9000 Jakarta Barat Invoice No : 1001 Invoice Date : 29 – February – 2000 To
Customer No : 007 PT. XYZ Kaaboom Jl. Kebon Jeruk Raya No 1000 Jakarta Barat
Item No Item Description
Qty Unit Unit Price Cost
X001 Teko 20 Dozen 1,000,000 20,000,000.00X002 Kembang Api 10 Dozen 1,000,000 10,000,000.00X003 Mercon Banting 20 Kg 1,000,000 20,000,000.00 Sub Total 50,000,000.00 PPN 5,000,000.00 Total 55,000,000.00
Dari contoh invoice diatas kita dapat mulai melakukan proses normalisasi dan membuat tabel didalam Database. II. URUT-URUTAN PEKERJAAN
1. Transformasi fakta menjadi Tabel 1 NF 2. Tentukan Functional Dependencynya 3. Normalisasikan sampai bentuk normal ke 3 4. Buat SQL Script untuk medefinisikan tabel 5. Definisikan tabel didalam database
2013 4 Analisa Perancangan Berorientasi Objek Modul 02 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
III. Mentransformasi Fakta Menjadi Tabel 1 NF Fakta Invoice diatas ditransformasikan menjadi tabel 1 NF :
RUBAH ITEMS DATA YANG HARUS DIISI/DITAMPILKAN MENJADI ATTRIBUTES
Invoice akan menjadi sebuah tabel dengan attributes :
Invoice(InvoiceNo, InvoiceDate, CustomerNo, CustomerName, Address, City, ItemNo, ItemDescription, Qty, Unit, UnitPrice, Cost, SubTotal, PPN, Total)
Menentukan Functional Dependency Berdasarkan tabel tersebut, dapat dibuat functional dependency diagram sbb : Definisi : Bentuk Normal Pertama adalah bentuk tabel dimana setiap nilai-nilai setiap attribute adalah atomik, tidak terdapat pengulangan nilai. Berarti pada setiap perpotongan baris dan kolom hanya terdapat 1 nilai saja, tidak lebih tidak kurang.
Garis functional dependency dibuat dengan memperhatikan bentuk hubungan himpunan nilai antar attribute. Berdasarkan functional dependency diagram ditentukan bentuk normalisasinya IV. Mentransformasikan Sampai Ke Bentuk 3 NF Definisi : Candidate Key adalah himpunan attribute yang dapat memenuhi syarat :
Uniqueness – Tidak ada himpunan nilai attribute yang sama didalam satu tabel Minimality – Tidak ada bagian dari himpunan attribute yang dapat dihilangkan tanpa menghilangkan sifat uniqueness. Definisi : Bentuk Normal Kedua adalah bentuk dimana seluruh attribute bukan key tergantung
InvoiceNo
ItemNo
CustomerNo CustomerName
Address
City
InvoiceDate
ItemDescriptio
Qty
Unit UnitPric
SubTotal
PPN
Total
Cost
2013 5 Analisa Perancangan Berorientasi Objek Modul 02 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
fungsional kepada key
Berdasarkan definisi diatas bentuk tabel berubah menjadi :
Invoice(InvoiceNo, InvoiceDate, CustomerNo, CustomerName, Address, City) Item(ItemNo, ItemDescription, Unit, UnitPrice) InvoiceItem(InvoiceNo*, ItemNo*, Qty)
Definisi:
TransitiveDependcy adalah ketergantungan himpunan attribute non-key terhadap himpunan attribute non-key lainnya.
Definisi :
Bentuknormal ketiga adalah tabel dimanatabel sudah berada dalam bentuk normal kedua dan tidak ada transitive dependency
Transitive depedency ditemui pada attribute CustomerNo, CustomerName, Address, dan City.
Berdasarkan definisi diatas maka bentuk tabel berubah menjadi :
Customer(CustomerNo, CustomerName, Address, City) Item(ItemNo, ItemDescription, Unit, UnitPrice) Invoice(InvoiceNo, InvoiceDate, CustomerNo*) InvoiceItem(InvoiceNo*, ItemNo*, Qty)
Bentuk Entity Relationship Diagram untuk tabel tersebut adalah : V. Membuat SQL Script untuk mendefinisikan tabel create table Customer (CustomerNo char(3), CustomerName char(30) not null, Address char(30) not null, City char(30) not null, Primary Key(CustomerNo)); create table Item (ItemNo char(4), ItemDescription char(40) not null, Unit char(5) not null, UnitPrice float not null, Primary Key (ItemNo));
Customer Item
Invoice InvoiceItem
2013 6 Analisa Perancangan Berorientasi Objek Modul 02 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
create table Invoice (InvoiceNo char(4), InvoiceDate DateTime not null, CustomerNo char(3) not null, Primary Key (InvoiceNo), Foreign Key(CUstomerNo) references Customer); create table InvoiceItem (InvoiceNo char(4), ItemNo char(4), Qty float not null, Primary Key (InvoiceNo, ItemNo), Foreign Key (InvoiceNo) references Invoice, Foreign Key (ItemNo) references Item); VI. Definisikan Tabel Didalam Database SQL Script tersebut dijalankan didalam DBMS untuk dapat membuat tabel. VII. Latihan Dalam waktu 1 Minggu Anda diminta untuk membangun basis data oleh MIS manager PT. Mercon Trading Indonesia. Karena mereka ingin anda membuat database untuk keperluan bisnis mereka. Seluruh Item barang dagangan dibeli dari Supplier (diidentifikasikan dengan Supplier_No). Supplier disimpan profilnya. Informasi yang diperlukan adalah Nama Perusahaannya, Contact Person, Telpon dan Alamat lengkapnya. (Supplier adalah entity !!!) Setiap supplier dapat mengirimkan bermacam-macam Barang. Barang dagangan tersebut tidak menjadi monopoli dari setiap supplier. Sehingga setiap supplier dapat mensupply banyak barang, dan tiap – tiap barang dapat disupply oleh banyak supplier (Bentuk many to many yang harus dirubah menjadi sejumlah n one-to–many, dimana n harus anda tentukan sendiri). Informasi Barang (diidentifikasikan dengan Barang_No) yang ingin disimpan adalah keterangan mengenai barang tersebut (Item description), Unit, dan Unit Price. Setiap pengriman barang dari supplier dicatat didalam buku pembelian. Didalam buku pembelian tersebut dicatat Tanggal, Jumlah Pembelian, Supplier dan Barangnya. (Tentukan sendiri attribute yang relevan, dan keys nya ) Setiap Customer (Diidentifikasikan dengan Customer_No) dapat membeli bermacam-macam barang. Dalam Melakukan penjualan mereka mengirimkan invoice kepada pembeli. Contoh invoice diberikan dibawah ini. Sebagai seorang analis anda diminta untuk membuat tabel 3NF bagi data base tersebut. Untuk keperluan dokumentasi mereka meminta : Entity Relationship Diagram. Buatlah DDL Script untuk membuat table dengan SQL dari E/R diagram tersebut. PT. Mercon Trading Indonesia Jl. Meruya Selatan No. 9000 Jakarta Barat Invoice No : 1001 Invoice Date : 29 – February – 2000
2013 7 Analisa Perancangan Berorientasi Objek Modul 02 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
To Customer No : 007 PT. XYZ Kaaboom Jl. Kebon Jeruk Raya No 1000 Jakarta Barat
Item No Item Description
Qty Unit Unit Price Cost
1001 Teko 20 Dozen 1,000,000 20,000,000.001002 Kembang Api 10 Dozen 1,000,000 10,000,000.001003 Mercon Banting 20 Kg 1,000,000 20,000,000.00 Sub Total 50,000,000.00 PPN 5,000,000.00 Total 55,000,000.00 SYNTAX PEMBUATAN TABEL DIDALAM SQL CREATE TABLE NamaTable (
{NamaKolom TipeKolom [daftarconstraint …..] {KolomBerikut….} [Primary Key (DaftarKolom…..)] [Foreign Key (Daftar Kolom……) references TabelLain|TabelIni (DaftarKolom)
)
NamaKolom adalah nama kolom dari tabel yang dibuat TipeKolom : Data Type Kolom yang akan dibuat DaftarConstraint : Pembatasan yang akan dibuat misal Null, Not Null Primary Key : Primary Key dari tabel Foreign Key : Kolom(Kolom-kolom) yang menunjuk primary key pada tabel lain atau
tabel bersangkutan
2013 8 Analisa Perancangan Berorientasi Objek Modul 02 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
OPERASI UPDATE TERHADAP TABEL
I. Menyisipkan/Memasukkan Data Setelah selesai membuat tabel-tabel didalam database maka data dapat mulai dimasukkan. Aturan memasukkan data adalah :
1. Data yang berada pada sisi one/sisi primary key harus diisi terlebih dahulu. 2. Data yang berada pada sisi many/foreign key diisi setelah sisi primary key. 3. Pengisian data harus memenuhi aturan-aturan database yang didefinisikan sebelumnya.
Baik data yang dimasukkan dengan perintah SQL maupun dengan interface DBMS haruslah memenuhi aturan-aturan tersebut : Perhatikan tabel-tabel dibawah ini :
Customer(CustomerNo, CustomerName, Address, City) Item(ItemNo, ItemDescription, Unit, UnitPrice) Invoice(InvoiceNo, InvoiceDate, CustomerNo*) InvoiceItem(InvoiceNo*, ItemNo*, Qty)
Pada tabel-tabel diatas, sebelum dapat melengkapi sebuah Faktur secara lengkap, Tabel harus diisi dengan urutan :
1. Customer dan Item harus diisi terlebih dahulu 2. Invoice 3. InvoiceItem
Perhatikanlah urut-urutan tersebut bersesuaian dengan aturan Entity Integrity dan Referential Integrity. Sehingga untuk mengisi tabel dijalankan perintah :
1. Mengisi Customer Insert Into Customer(CustomerNo, CustomerName, Address, City) values (‘007’, ‘PT XYZ Kaaboom’, ‘Jl. Kebon Jeruk Raya No 1000’, ‘Jakarta Barat’); Insert Into Customer(CustomerNo, CustomerName, Address, City) values (‘008’, ‘PT Dor’, ‘Jl. Meruya Selatan No 1000’, ‘Jakarta Barat’);
2. Mengisi Item Insert into Item(ItemNo, ItemDescription, Unit, UnitPrice) values (‘X001’, ‘Teko’, Dozen, 1000000) Insert into Item(ItemNo, ItemDescription, Unit, UnitPrice) values (‘X002’, ‘Mbang Api’, Dozen, 1000000) Insert into Item(ItemNo, ItemDescription, Unit, UnitPrice) values (‘X003’, ‘Mercon Banting’, Kg, 1000000)
3. Mengisi Invoice Insert into Invoice(InvoiceNo, InvoiceDate, CustomerNo) values(‘1001’, ‘02/29/2000’, ‘007’)
4. Mengisi Invoice Item Insert into InvoiceItem(InvoiceNo, ItemNo, Qty) values(‘1001’, ‘X01’, 20) Insert into InvoiceItem(InvoiceNo, ItemNo, Qty) values(‘1001’, ‘X02’, 10)
Customer Item
Invoice InvoiceItem
2013 9 Analisa Perancangan Berorientasi Objek Modul 02 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Insert into InvoiceItem(InvoiceNo, ItemNo, Qty) values(‘1001’, ‘X03’, 20) PT. Mercon Trading Indonesia Jl. Meruya Selatan No. 9000 Jakarta Barat Invoice No : 1001 Invoice Date : 29 – February – 2000 To
Customer No : 007 PT. XYZ Kaaboom Jl. Kebon Jeruk Raya No 1000 Jakarta Barat
Item No Item Description
Qty Unit Unit Price Cost
X001 Teko 20 Dozen 1,000,000 20,000,000.00
X002 Kembang Api 10 Dozen 1,000,000 10,000,000.00
X003 Mercon Banting 20 Kg 1,000,000 20,000,000.00
Sub Total
50,000,000.00 PPN
5,000,000.00 Total
55,000,000.00 II. Menghapus Data Untuk menghapus data harus diperhatikan baik aturan referensial dan aturan integrity. Aturan yang harus dipenuhi untuk menghapus data didalam tabel adalah :
1. Data yang berada pada sisi many/sisi foreign key harus dihapus terlebih dahulu. 2. Data yang berada pada sisi one/primary key dihapus setelah sisi foreign key. 3. Pengisian data harus memenuhi aturan-aturan database yang didefinisikan sebelumnya.
Untuk menghapus seorang customer yang harus dilakukan adalah :
1. Menghapus InvoiceItem Delete from InvoiceItem where InvoiceNo = ‘1001’
2. Menghapus Invoice Delete from Invoice where InvoiceNo = ‘1001’
3. Menghapus Customer
4. Delete from Customer where CustomerNo = ‘007’
2013 10 Analisa Perancangan Berorientasi Objek Modul 02 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Daftar Pustaka
Alan Denis, Barbara Haley Wixon, David Tagerden, System Analys and Design : an Object –
Oriented Approach with UML 2.0, John Willey and Sons, 2005
Henry C. Lucas Jr., The Analysis, Design and Implementation of Information Systems 4th,
McGraw Hill, 1992
Satzinger, Jackson, Burd, Object-Oriented Analysis and Design with the Unified Process,
Course Technology, 2005
Simon Bennet, Steve McRobb and Ray Farmer, Object-Oriented System Analysis and
Design Using UML, McGraw Hill, 2006
Wendy and Michael Boggs, UML with Rational Rose 2002, Sibex Inc., 2002
MODUL PERKULIAHAN
ANALISA
PERANCANGAN BERORIENTASI OBJEK
Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana
Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh
Ilmu Komputer Teknik Informatika
03 87016 Tim Dosen
Abstract Kompetensi
Mengidentifikasi ukuran project, membuat dan mengelola rencana kerja pelaksanaan project
Memahami Managemen Project
2013 2 Analisa Perancangan Berorientasi Objek Modul 03 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Project Initiation dan Project Management
2.1 Project Initiation
Project adalah sehimpunan aktifitas with titik mulai dan titik akhir yang digunakan untuk
membuat suatu sistem yang akan memberikan nilai tambah. Ide dasar dari pembuatan
sebuah project adalah jika seseorang dapat melihat/menemukan kesempatan untuk
membuat business value /niai tambah dengan penerapan paradigma teknologi informasi
yang baru :
1. Studi kelayakan digunakan untuk membantu dalam menentukan untuk meneruskan
Teknik Informatika atau tidak.
2. Project sponsor adalah orang yang mengajukan pengembangan atau penerapan paradigma baru dalam teknologi informasi. Cakupan project menentukan siapa yang pantas menjadi sponsor. Jika implementasinya meliputi seluruh organisasi boleh jadi yang menjadi sponsor adalah CEO. Jika projectnya sangat spesifik misalnya pengembangan jaringan maka sponsornya adalah departemen atau bagian yang berhubungan dengan teknologi informasi.
3. Approval committee akan melakukan penilaian proposal untuk menentukan mana
yang layak untuk dikembangkan didalam organisasi.
Secara umum project akan dapat diidentifikasi ketika seseorang melihat business need
untuk membangun sebuah sistem. Business need muncul ketika dapat diidentifikasi baik
secara eksternal maupun internal. Bisa juga terjadi ketika seseorang melihat cara
penggunaan teknologi informasi dengan cara yang unik, sebagai contoh penggunaan J2EE
untuk visualisasi data GIS bagi pengambaran instalasi media iklan.
2.1.1 Identifikasi Project
Kebutuhan business akan mendorong adanya permintaan penggunaaan cara maupun
teknologi yang baru atau business requirement. Requirement adalah apa yang akan
dilakukan oleh sistem, dan fungsi apa yang dialkukannya. Project sponsor harus memiliki
pemahaman apa yang akan dilakukan oleh sistem yang akan dibuat, business value yang
akan diberikan oleh sistem yang baru. Business value yang diberikan dapat saja bersifat :
1. Tangible value merupakan nilai yang bisa dikuantifikasidan diukur dengan alat ukur
2013 3 Analisa Perancangan Berorientasi Objek Modul 03 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
numerik. Misalkan penurunan penggunaan kertas sebesar 2 persen karena tidak
perlu mencetak memo.
2. Intangible value merupakan nilai yang tidak bisa dikuantifikasi tetapi secara intuitif
bisa dirasakan manfaatnya.
Setelah project sponsor dapat mengidentifikasi project yang dapat memenuhi kebutuhan
akan business value tersebut maka dia akan dapat membuat identifikasi business
requirement dan value, maka secara formal sudah dapat melakukan inisiasi project. Project
initiation dapat dimulai dengan menggunakan System Request.
2.1.2 System Request
System request adalah dokumen yang menjelaskan alasan pembuatan system dan nilai
yang diharapkan dapat disediakan oleh system. System request paling tidak meliputi 5
elemen yaitu :
Project Sponsor : Orang yang menginiasi project dan bekerja sebagai promary point
of contact untuk project pada sisi business.
Business need : Business-related reason for initiating the need
Business requirement : Kemampuan business yang disediakan oleh sistem yang
akan dibuat
Business value : Manfaat yang akan dinikmati oleh organisasi pemilik sistem, jika
sistem dibuat.
Special Issues / constraint : Issues/batasan yang relevan untuk implementasi sistem
dan penagmbilan keputusan mengenai pelaksanaan project.
2.1.3 Feasibility Analysis
Jika kebutuhan akan sistem yang baru dan business requiremenya sudah didefinisikan,
maka studi yang lebih terinci harus dilaksanakan untuk lebih memahami kesempatan dan
batasan yang berhubungan dengan project yang akan dilaksanakan. Feasibility analysis
harus dilaksanakan, karena akan memberikan petunjuk :
Apakah harus diteruskan atau tidak.
Resiko yang harus dihadapi jika project disetujui.
2013 4 Analisa Perancangan Berorientasi Objek Modul 03 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Feasibily analysis secara umum terdiri dari 3 teknik :
1. Technical Feasibility : Dapat secara tehnik membuatnya, : faktor penilainya adalah
1. Familiar dengan aplikasinya
2. Familiar dengan tehnologinya
3. Ukuran project : Semakin besar semakin beresiko
4. Compatibility : Semakin sulit mengintegrasikan sistem dengan teknologi yang
sudah ada maka resiko akan lebih besar.
2. Economic Feasibility : Haruskah dibuat/apakah ekonomis, faktor penilainya adalah
1. Development Cost
2. Annual operating cost
3. Annual benefits (cost saving dan revenues)
4. Intangible costs and benefit.
3. Organizational Feasibility : Kelayakan organisasional, kalau sudah dibuat akankah
secara organisasional bisa dipakai :
1. Project Champion
2. Senior Management
3. Users
4. Other Stakeholders
5. Kecocokan project dengan business.
Adapun untuk urut-urutan Economic Feasibility adalah :
1. Identifikasi Biaya dan Manfaat : Membuat bdaftar seluruh tangible cost dan manfaat
dari project.
2. Memasukkan nilai kedalam biaya dan manfaat : Bekerja dengan business user dan
IT professional untuk menghiting angka bagi biaya dan manfaat. Yang intangibles
juga harus dikuantifikasikan.
3. Menentukan cash flow : Memproyeksikan apakah manfaat dan biaya yang akan
terjadi dalam suatu periode tertentu baik jangka menengah maupun panjang.
Termasuk juga memperhitungkan faktor pertumbuhan.
4. Menentukan NPV (Net Present Value) : Menghitung nilai sekarang dari biaya yang
timbul dimasa yang akan datang dihitung dengan standard hari ini. Rate of growth
2013 5 Analisa Perancangan Berorientasi Objek Modul 03 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
harus ditentukan untuk menghitung NPV
5. Tentukan ROI (Return On Investment) : Menghitung seberapa banyak organisasi
akan menerima manfaat investasi.
6. Menghitung BEP (Break-Even Point) : Digunakan untuk menentukan kapankah
sistem yang dibuat memberikan hasil yang lebih tinggi dibandingkan dengan
biayanya. Formula Break Even digunakan untuk menghitung BEP. Hal ini akan
membantu kapan organisasi akan memperoleh manfaat dari perhitungan yang
dilakukan.
7. Menggambarkan BEP : Gambarlah BEP dengan menggunakan time-graph.
Adapun biaya-biaya yang harus diperhitungkan dalam melakukanCost and Benefit Analysis
meliputi/diantaranya adalah :
1. Development Cost :
2. Development Team Salaries
2. Consultant Fees
2. Development Training
2. Hardware and Software
2. Vendor Installation
2. Office Space and Equipment
2. Data Conversion Costs
2. Operational Costs
3. Software Upgrades
3. Software Licensing Fees
3. Hardware Repairs
3. Hardware Upgrades
3. Operational Team Salaries
3. Communication Charges
3. User Training
3. Tangible Benefits
2013 6 Analisa Perancangan Berorientasi Objek Modul 03 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
4. Increased Sales
4. Reduction in Staff
4. Reduction in Inventory
4. Better Supplier Prices
4. Intangible Benefits
5. Increased Market Share
5. Increased Brand Recognition
5. Higher Quality Products
5. Improves Customer Service
5. Better Supplier Relations
Kelayakan organizational adalah penting yaitu untuk memenuhi kepentingan Stakeholders
yaitu :
1. Champion : Adalah orang yang :
2. Menginisiasi project.
2. Mempromosikan project.
2. Mengalokasikan waktunya untuk project.
2. Menyediakan resources.
2. Organizational Management : Adalah pengelolaan organisasi yang :
3. Memahami project.
3. Memberikan anggaran yang cukup bagi terlasananya pekerjaan.
3. Mendorong/memaksa pengguna untuk menerima dan menggunakan sistem.
3. System Users adalah pengguna sistem :
4. Membuat keputusan yang mempengaruhi project
4. Melakukan aktifitas( atas produk yang dihasilkan) project
4. Menentukan apakah project sukses dengan menggunakan atau tidak
menggunakan sistem.
Project dapat diklasifikasikan Penentuan klasifikasi project ditentukan dengan melihat :
1. Size. Ukuran project dapat dilihat dari seberapa banyak orang yang terlibat dalam
pengerjaannya.
2013 7 Analisa Perancangan Berorientasi Objek Modul 03 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
2. Cost. Seberapa banyak biaya yang harus dikeluarkan organisasi untuk mengerjakan
project tersebut.
3. Purpose. Apakah tujuan project. Apakah untuk meningkatkan infrastruktur teknik,
untuk mendukung strategi bisnis, ataukah untuk peningkatan inovasi baru.
4. Length. Seberapa lama project akan selesai sebelum dapat digunakan untuk
melakukan business.
5. Risk. Berapakah kemungkinan project untuk berhasil dan sukses.
6. Scope. Seberapa banyak organisasi dipengaruhi oleh sistem yang dibuat, Apakah
satu departemen, satu divisi, atau seluruh korporasi.
7. Return on Investment. Seberapa banyak organisasi mengharapkan ROI dari biaya
yang dikeluarkan.
2.2 Project Management
Perhatikanlah dua definisi dibawah ini sebelum meneruskan pembahasan selanjutnya :
1. Project Manager : A project manager has the primary responsibility for managing the
hundreds of tasks and roles that need to be carefully coordinated.
2. Project Management : Project management is the process of planning and controlling the development of a system within a specified timeframe at a minimum cost with the right functionality.
Pada tahun 1999 dari survey yang dilakukan oleh computer world separo dari 103 perusahaan yang di survey menyatakan bahwamereka menyadiakan pelatihan formal untuk project management untuk IT projects teams. Disamping itu juga disediakan perangkat untuk manajemen project seperti : Microsoft Project, Plan View, dan PMOffice yang mendukung project management. Tetapi banyak project yang tidak jadi karena tuntutan yang tidak masuk akal dan kurangnya dukungan dari management yang lebih tinggi.
Selanjutnya akan dibahas bagaimana mengidentifikasikan Ukuran project dengan Pendekatan Function Point. Adapun Pendekatan yang dilakukan adalah dengan :
1. Melakukan Estimasi Ukuran System.
2. Estimasi Effort yang diperlukan.
3. Estimasi Waktu yang diperlukan.
2013 8 Analisa Perancangan Berorientasi Objek Modul 03 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Gambar 1 Total Unadjusted Function Points
Gambar 2. Total Processing Complexity
Adjusted Project Complexity = .065 + (0.01 * Project Complexity) Total Adjusted Function Points = Adjusted Project Complexity * TUFP
2013 9 Analisa Perancangan Berorientasi Objek Modul 03 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Adapun perkiraan jumlah LOC per function points adalah : 1. C >> 130 2. COBOL >> 110 3. Java >> 55 4. C++ >> 50 5. Turbo Pascal >> 50 6. VB >> 30 7. Power Builder >> 15 8. HTML >> 15 9. Packages : Access, Excel, dll >> 10 - 40
Pengelolaan Rencana Kerja
Adapun perangkat yang digunakan didalam mengelola pekerjaan adalah :
1. Identifying Task
2. Project Workplan
3. Gantt Chart
4. PERT Chart
5. Refining Estimates
6. Scope Management
7. Time Boxing
8. Evolutionary Work Breakdown Structure and Itterative Work Plans
Perangkat/tools tidaklah cukup sehingga perlu ada :
1. Staffing Plan
2. Motivation
3. Handling Conflict
Coordinating Project Activities
1. CASE Tools
2. Standards
3. Documentation
4. Managing Risks
2013 10 Analisa Perancangan Berorientasi Objek Modul 03 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Daftar Pustaka
Alan Denis, Barbara Haley Wixon, David Tagerden, System Analys and Design : an Object –
Oriented Approach with UML 2.0, John Willey and Sons, 2005
Henry C. Lucas Jr., The Analysis, Design and Implementation of Information Systems 4th,
McGraw Hill, 1992
Satzinger, Jackson, Burd, Object-Oriented Analysis and Design with the Unified Process,
Course Technology, 2005
Simon Bennet, Steve McRobb and Ray Farmer, Object-Oriented System Analysis and
Design Using UML, McGraw Hill, 2006
Wendy and Michael Boggs, UML with Rational Rose 2002, Sibex Inc., 2002
MODUL PERKULIAHAN
ANALISA
PERANCANGAN BERORIENTASI OBJEK
Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana
Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh
Ilmu Komputer Teknik Informatika
04 87016 Tim Dosen
Abstract Kompetensi
Memahami kebutuhan sistem Menentukan kebutuhan teknik dan menganalisa kebutuhan
2013 2 Analisa Perancangan Berorientasi Objek Modul 04 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Requierment Determination
SDLC adalah proses pembuatan systems yang memindahkan keadaan sistem yang sekarang ke
sistem yang diharapkan. Output dari perencanaan adalah system request yang berisi penjelasan
umum mengenai sistem yang akan datang, cakupan project, dan menyediakan rencana kerja.
Tahapan analisis mengolah system request menjadi requirements definition, functional models,
structural models, and behavioral models yang akan menjadi bagian dari system proposal. System
proposal berisi project management deliverables seperti feasibility analysis dan rencana kerja.
System proposal akan diserahkan kepada komite yang akan menilainya. Komite akan menentukan
apakah proposal akan diteruskan atau tidak. Walkthrough terhadap proposal dilakukan secara
terperinci, yang tujuannya adalh para pengguna, manajer, dan pengambil keputusan utama dapat
memahaminya secara jelas, dapat mengidentifikasi perbaikan, dan dapat membuat keputusan
apakah project harus dilanjutkan atau tidak. Jika disetujui, system proposal akan bergerak kedalam
tahapan design, dan requirements definition, functional models, structural models, and behavioral
models akan menjadi dasar/sebagai input didalam tahapan perancangan.
Garis antara perancangan dan analisis bersifat remang‐remang. Karena deliverables yang dibuat
pada saat analysis merupakan tahap awal dari perancangan sistem yang baru. Banyak pengambilan
keputusan yang berhubungan dengan dengan perancangan ditemukan pada saat analysis. Yang
harus diingat adalah ada sebagian kecil tahapan sudah dilakukan pada tahap ini.
Requirement determination adalah langkah yang paling kritis dari SDLC, karena element dasar dari
sistem harus ditentukan pada tahapan ini. Banyak penelitian yang menyebutkan bahwa kegagalan
terjadi karena penentuan requirements. Karena itu salah satu bagian dari pendekatan dari
pendekatan OO adalah iterative.
Selanjutnya akan dijelasakan apakah yang dimaksud dengan requirement determination yang
menjadi tahapan dari analisa sistem.
Requirement Determination Tujuan dari requirement determination adalah untuk merubah very hight level explanation of
the business requirement menjadi daftar yang lebih jelas dari requirement yang dapat
digunakan sebagai input untuk analysis (membuat , functional models, structural models, and
behavioral models)
2013 3 Analisa Perancangan Berorientasi Objek Modul 04 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
PengertianRequirement
Requirement adalah pernyataan apa yang harus dilakukan oleh sistem atau karakteristik apa
yang harus dimiliki :
1. Didalam tahapan analisis requirement ditulis dari sudut pandang business, atau apa
yang dilakukan oleh sistem. Fokusnya ada pada "WHAT". Fokusnya ada pada user
needs, sehingga biasanya disebut business requirements.
2. Selanjutnya didalam tahapan design, business requirement bergerak menjadi lebih
teknis, dan akan menjelaskan bagaimana (HOW) sistem akan diimplementasikan.
Requirement pada saat design dilihat dari sudut pandang pembuat sistem (developer).
Yang harus diperhatikan bahwa pembatas antara analisis dan perancangan remang-remang.
Beberapa pihak menggunakan istilah tersebut secara bolak-balik. Yang harus diperhatikan
adalah requirement adalah pernyataan apa yang harus dilakukan oleh sistem dan selalu da
kemungkinan untuk berubah. Secara umum requirement terbagi dua yaitu :
1. Functional requirement. Requirement ini berelasi langsung dengan dengan proses
yang harus dilakukan oleh sistem yang akan dibuat sehingga dapat menyediakan
informasi yang diperlukan. Functional requirement mengalir langsung kedalam
tahapan analisis selanjutnya, karena mendefinisikan fungsi-fungsi yang harus dimiliki
oleh sistem. Perhatikanlah Gambar 1 mengenai Functional Requirements
2. Nonfunctional requirement. Requirement ini berhubungan dengan behavioral
properties yang harus dimiliki oleh sistem, seperti performance and usability.
menjelaskan bermacam-macam karakteristik sistem : operational, performance,
secutiry, cultural and political. Karakteristik tersebut tidak menjelaskan business
process ataupun informasi yang diperlukannya, tetapi sangat penting untuk dpat
memahami apa yang harus dimiliki oleh sistem final. Perhatikanlah Gambar 2
mengenai Nonfunctinal Requirements
2013 4 Analisa Perancangan Berorientasi Objek Modul 04 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Gambar 1. Contoh Functional Requirement
Gambar 2 Contoh Non Functional Requirement
2013 5 Analisa Perancangan Berorientasi Objek Modul 04 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
RequirementDefinition
Requirement definition report biasanya hanya disebut requirement definition adalah text
report yang berisi daftar functional dan nonfunctinal requirement. dalam bentuk outline.
Daftarnya dibuat secara berurut dan diberi nomer supaya jelas, Sebagaimana digambarkan
pada gambar 1 dan gambar 2 requirement dibuat daftarnya. Selanjutnya dibuatkan
prioritasnya. Tujuan terpenting dari requirement determination adalah menentukan tahapan
dari sistem. Kalau ada kebingunan dokumen bertindak sebagai alat klarifikasi.
DeterminingRequirements
Didalam menentukanUntuk menentukan requirement diperlukan pemahaman business dan IT.
Hal ini bisa dianalogikan seperti membuat bangunan. Jika kita pemilik tumah, maka kita tahu
apa yang kita inginkan dari rumah kita, tetapi kita tidak akan dapat membuatrancangan
rumah. Demikan juga dengan seorang ahli bangunan sipil atau arsitek tidak akan dapat
menentukan bentuk bangunan dengan baik meskipun memiliki kemampuan teknis untuk
dapat menggambarkannya jika tidak berkomunikasi dengan orang yang akan menggunakan
bangunan tersebut. Karena pendekatan terbaik adalah mempekerjakan ahli business dan IT
bersama-sama untuk membuat analisa sistem. Kadang kala pengguna tidak tahu secara tepat
apa yang diinginkannya maka analis akan membantunya dengan teknik/perangkat/notasi dan
pemahaman yang dimilikinya. Teknik yang populer untuk melakukan analisis adalah :
Business process Automation.
Business Process Improvement.
Business Process Reengineering.
Ketiga teknik yang disebutkan di atas memiliki cara kerja yang sama yaitu :
Membantu user untuk menjelaskan sistem dan proses yang sekarang (as‐is).
Identifikasi apa yang akan dirubah.
Membuat konsep untuk sistem yang baru.
MembuatReqirementDefinition
Requirement definition haruslah dibuat mutakhir karena akan digunakan untuk referensi dan
pemahaman sistem yang akan dibuat. Membuat Requirement Definition sifatnya itterative
dan berkesinambungan yang meliputi :
2013 6 Analisa Perancangan Berorientasi Objek Modul 04 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
1. Mengumpulkan informasi dengan teknik yang diperlukan (interviews, document
analysis, dan lain-lain
2. Melakukan informasi untuk mengidentifikasi business requirement untuk sistem yang
akan dibuat.
3. Menambahakan requirements kedalam requirement definition reportyang akan
digunakan untuk menentukan pekerjaan.
Untuk membuat requirement definition, project team harus menentukan jenis -jenis dari
functional dan nonfunctional requirement dari sistem yang akan dibuat. Penentuan
requirements tersebut menjadi bagian utama dari dokumen yang akan dibuat. Selanjutnya
analis akan menggunakan bermacam-macam teknik untuk menentukan requirement seperti
interview dan observation untuk untuk mengumpulkan informasi, dan membuat daftar
business requirement yang teridentifikasi dari informasi diatas. Dan akhirnya bersama-sama
dengan dengan seluruh tim dan user akan melakukan :
1. Verifikasi
2. Perubahan
3. Melengkapi
4. Menentukan prioritas dari requirement.
Process akan berkesinambungan , dan requirement akan berevolusi jika requirement sudah
teridentifikasi dengan baik maka pekerjaan akan bergerak ke tahapan selanjutnya dari SDLC.
EVOLUTION OF REQUIREMENT harus secara hati-hati dikelola karena jika tidak akan ada
proliferasi requirment yang tak terkendali. Sehingga akan menyebabkan sistem tidak pernah
selesai dan selalu tumbuh diluar cakupan sistem. Ketika requirement mencerminkan
kebuatuhan business di dunia nyata dan bukan didalam sistem yang sekarang dibuat maka
dimasukkan kedalam requirement dimasa yang akan datang dan diberi nomor prioritas yang
lebih rendem. Pengelolaan requirement (dan cakupan dari sistem yang akan dibuat)
merupakan bagian yang paling berat dari pembuatan sistem.
RequirementsAnalysisTechniques.
Sebelum project team dapat menentukan requirement apa yang tepat untuk sistem yang akan
dibuat, mereka harus memiliki visi yang jelas sistem apa yang akan dibuat, dan tingkat
perubahan apa yang akan terjadi pada organisasi. Proses dasar analisis terbagi menjadi tiga
tahapan :
2013 7 Analisa Perancangan Berorientasi Objek Modul 04 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
1. Mamahami sistem yang sekarang
2. Mengidentifikasi peningkatan
3. Membuat/mengumpulkan requirement untuk sistem yang akan dibuat.
Kadang-kadang langkah yang pertama dilewati jika tidak ada sistem yang ada atau hanya
dilakukan sepintas pada methodology seperti RAD dan Agile. Sedangkan pada metodologi
seperti waterfamm dan pararel development menggunakan waktu yang cukup panjang untuk
menganalisa sistem yang sudah ada dan mengidentifikasi perbaikan yang mungkin dilakukan
sebelum mealukan requirement gathering. Sementara itu metodologi yang berfokus pada
peningkatan dan requirement system yang akan dibuat akan melakukan investigasi terhadap
sistem yang sekarang berjalan secara sepintas saja. Metodologi tersebut adalah :
1. Generasi baru RAD
2. Agile
3. OO methodologies
4. phased development
5. prototyping
6. throwaway prototyping
7. XP
Ada tiga tehnik yang digunakan sebagaimana disebutkan diatas yaitu Business process
Automation, Business Process Improvement, dan Business Process Reengineering. Ketiga
tehnik tersebut membantu analis melakukan analisa sehingga visi dari sistem dapat
dikembangkan dengan baik. Tehnik Requirement analysis yang disebutkan diatas akan
digunakan bersama-sama dengan requirement-gathering techniques yang meliputi :
1. Interviews
2. JAD Session
3. questionaires
4. document analysis
5. observation.
Requirement analysis techniques akan menentukan jenis informasi apa yang akan
dikumpulkan dan bagaimana analisanya. Kedua jenis tehnik tersebut bersifat komplementer.
2013 8 Analisa Perancangan Berorientasi Objek Modul 04 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Pilihan tehniknya akan menentukan bentuk perubahan yang akan terjadi di dalam organisasi :
1. BPA digunakan untuk menangani perubahan kecil yang berhubungan dengan otomasi
proses.
2. BPI digunakan untuk melakukan perbaikan proses untuk memperbaiki efektifitas dan
efisiensi kerja
3. BPR merubah bagaimana cara organisasi bekerja sehingga yang terjadi adalah
transformasi organisasi ke bentuk yang lebih baik.
Untuk menggerakkan pengguna menggunakan sistem yang baru analis harus memiliki
kemampuan berpikir kritis yang tingi. Kemampuan berpikir kritis adalah kemampuan untuk
memahami strengths dan weaknesses dan membentuk kembali idea yang sudah ada menjadi
bentuk yang lebih baik sehingga. Idea tersebut digunakan untuk memahami issues dan
mengembangkan business process yang baru. Kemampuan ini diperlukan untuk mempelajari
:
1. Hasil dari requirements gathering
2. Identifikasi business requirement
3. menterjemahkan requirements menjadi sistem yang baru.
BusinessProcessAutomation
BPA artinya tetap menggunakan cara bagaimana organisasi bekerja, tetapi menggunakan
teknologi komputasi untuk mengerjakan beberapa pekerjaan yang harus dilakukan. BPA
dapat membuat organisasi bekerja lebih effisien tetapi mempunya pengaruh yang lebih kecil
dibandingkan dengan ketiga tehnik tersebut diatas. BPA akan mempelajari sistem yang
sedang berjalan dengan seksama dan pada akhirnya akan memperbaiki system requirements
yang dibuat. Problem analysis dan Root Cause Analysis adalah 2 cara BPA yang cukup
ngetop :
1. Problem Analysis. Adalah cara langsung requirment analysis. Problem analysis
artinya bertanya kepada user dan managers untuk melakukan identifikasi problem
dengan sistem yang sekarang sudah ada dan menjelaskan penyelesaian permasalahan
yang terjadi didalam sistem. Hampir semua pengguna sistem memiliki ide bagaimana
perbaikan dilakukan. Perbaikan proses dari problem analysis biasanya sedikit dan
bersifat incremental. Jenis pebaikan ini biasanya efektif untuk memperbaiki efisiensi
2013 9 Analisa Perancangan Berorientasi Objek Modul 04 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
sistem. Tetapi basanya monetary benefits yang diperoleh tidak besar. Yang jelas
adalah perbaikan dari sistem yang sudah ada.
2. Root Cause Analys. Problem analysis bekerja berdasarkan asumsi yang bisa saja valid
3. atau tidak valid. Umumnya orang selalu membuat kesimpulan sebelum melakukan
pemikiran mengenai sebab dan akibat . Biasanya kesimpulan atau tindakan yang akan
dilakukan adalah mengobati gejala bukan akar permasalahannya. Didalam dunia nyata
permasalahn untuk perbaikan proses adalah dengan menggunakan root cause.
Pemecahan bisa jadi mengobati gejala, bisa juga akar permasalahan. , tetapi yang jelas
tanpa analisa yang mendalam akan sulit untuk memecahkan permasalahan dan
menentukan mana yang gejala dan mana yang akar permasalahan. Root cause analysis
berfokus pada masalah bukan pada pemecahan masalah.
BusinessProcessImprovement
BPI artinya membuat perubahan moderat dari cara bagaimana organisasi beroperasi, dengan
melihat bagaimana organisasi beroperasi untuk memanfaatkan teknologi yang baru atau apa yang
dilakukan oleh kompetitor. Tujuan dati BPI adalah meningkatkan efisiensi (doing thighs right) dan
meningkatkan efektifitas (doing the right things). Focus BPI adalah meningkatkan business process,
sehingga mempelajari business process yang ada sangat diperlukan untuk perbaikan proses dan
membuat sistem requirement yang baru. BPI menggunakan Duration analysis, activity based‐costing,
dan information benchmarking.
1. Duration Analysis memerlukan pembelajaran secara detail proses yang dilakukan didalam
sistem yang sekarang berjalan. Analisis dimulai dengan melihat waktu yang diperlukan
secara rata‐rata untuk melakukan business process guna menghasilkan output tertentu. Lalu
menghitung waktu yang diperlukan untuk menyelesaikan setiap pekerjaan/bagian proses
didalam business sehari‐hari. Waktu yang diperlukan untuk mengerjakan suatu bagian
pekerjaan kemudian ditotal. Selanjutnya akan diketahui persentase dari pekerjaan tersebut
secara keseluruhan. Dari perbandingan akan dapat dicari permasalahannya dimana. Karena
total dari masing‐masing subproses bisa jadi lebih kecil dari waktu yang diperlukan untuk
menyelesaikan pekerjaan. Permasalahan ini terjadi karena :
1. Fragmentasi sub‐process tidak baik.
2. Process integration/parrarelization.
2. Activity‐Based Costing sama dengan analisa biaya dari setiap sub aktifitas. Jika ternyata biaya
untuk menyelesaikan pekerjaan lebih besar dari biaya untuk melaksanakan seluruh sub
proses maka proses tidak dikelola dengan baik.
2013 10 Analisa Perancangan Berorientasi Objek Modul 04 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
3. Informal Benchmarking. Benchmarking artinya membandingkan bagaimana organisasi lain
melakukan business process agar organisasi dapat bekerja dengan lebih baik. Benchmarking
tujuannya adalah agar dapat memperkenalkan idea bahwa karyawan dapat bekerja dengan
lebih baik dengan cara yang baru yang sebelumnya tidak pernah terbayangkan. Informal
Benchmarking adalah istilah dimana karyawan perusahaan berkunjung sebagai customer
untuk perusahaan lain. Misalkan membuat web site untuk universitas, maka team akan
melihat web site bermacam‐macam universitas untuk membandingkan apa yang dilakukan.
BusinessProcessReengineering
Business Process Reenginering (BPR) artinya merubah cara bagaimana organisasi beroperasi,
yaitu merubah cara bagaimana menjalankan business dan membuat perubahan besar karena
danya ide dan teknologi yang baru. Adapun tehnik yang digunakan didalam BPR adalah :
1. Outcome Analysis yang berfocus pada pemahaman dari produk yang memberikan
nilai yang lebih baik kepada customer.
2. Technology Analysis yang tujuannya adalah untuk menerapkan bagaimana analis dan
manager untuk membuat list/daftar teknologi apa saja yang akan dibuat atau
dimanfaatkan, untuk selanjutnya menentukan apa yang akan diterapkan didalam
business process.
3. Activity Elimination. Activity elimination adalah menghilangkan aktifitas yang
kurang produktif dan menggantikannya dengan aktifitas yang produktif.
Pemilihan Teknik yang Tepat
Untuk dapat melakukan pemilihan teknik atau mencampur teknik yang tepat perlu
diperhatikan strength dan weakness dari :
1. Potential Business Value. Nilai tambah yang dihasilkan oleh tehnik yang dipilih.
2. Project Cost. Biaya yang ditimbulkan dari tehnik yang dipilih.
3. Breadth of Analysis. Cakupan analisis yang apakah analisis meliputi :
1. business process dalam satu fungsi business
2. process yang menjangkau seluruh organisasi
3. process yang berinteraksi dengan seluruh customer dan organisasi.
4. RiskResiko kegagalan, yang diakibatkan oleh rancangan yang tidak baik, kebutuhan
2013 11 Analisa Perancangan Berorientasi Objek Modul 04 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
yang tidak terpenuhi atau perubahan radikal yang tidak dapat ditangani oleh
organisasi, sehinga resikonya menjadi semakin besar.
Selanjutnya perhatikanlah matriks pemilihan tehnik pada gambar 3 mengenai Strategi dari
analisa proses bisnis.
Gambar 3 Karakteristik dari Stategi Analisa Proses.
2013 12 Analisa Perancangan Berorientasi Objek Modul 04 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Daftar Pustaka
Alan Denis, Barbara Haley Wixon, David Tagerden, System Analys and Design : an Object –
Oriented Approach with UML 2.0, John Willey and Sons, 2005
Henry C. Lucas Jr., The Analysis, Design and Implementation of Information Systems 4th,
McGraw Hill, 1992
Satzinger, Jackson, Burd, Object-Oriented Analysis and Design with the Unified Process,
Course Technology, 2005
Simon Bennet, Steve McRobb and Ray Farmer, Object-Oriented System Analysis and
Design Using UML, McGraw Hill, 2006
Wendy and Michael Boggs, UML with Rational Rose 2002, Sibex Inc., 2002
MODUL PERKULIAHAN
ANALISA
PERANCANGAN BERORIENTASI OBJEK
Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana
Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh
Ilmu Komputer Teknik Informatika
05 87016 Tim Dosen
Abstract Kompetensi
Memahami kebutuhan sistem Menentukan kebutuhan teknik dan menganalisa kebutuhan
2013 2 Analisa Perancangan Berorientasi Objek Modul 05 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Requierment Gathering Technique
Analis pekerjaannya adalah seperti detektip. Ia tahu ada permasalahan dengan sesuatu dan
mencari solusi pemecahan. Berarti harus dapat mencari permasalahan yang melingkupi
suatu aktifitas business. Sayangnya pemecahan permasalahan tidk selalu langsung terlihat
dengan jelas. Seorang system analyst akan mencari pemecahan dengan bermacam-macam
technique, dan memastikan bahwa business process yang berjalan saat ini dan kebutuhan
akan sistem yang baru dipahami dengan baik sebelum dilakukan perancangan/design yang
baru. Yang tidak diinginkan adalah requirement yang salah yang menyebabkan pekerjaan
pengembangan sistem menjadi gagal.
Requirement gathering akan memberikan dukungan politis dan membuka komunikasi serta
membangun kepercayaan dan pelaporan antara project dan pengguna yang pada akhirnya
akan menggunakan atau tidak menggunakan hasil dari project tersebut. Seluruh
stakeholders (orang yang berkepentingan) yang penting harus dilibatkan sehingga akan
menyebabkan requirement dapat dikumpulkan dengan lebih seksama. Stakeholder yang
dilibatkan didalam requirement gathering meliputi :
1. Managers
2. Karyawan-karyawan
3. Staff,
4. Customer,
5. Supplier
Selanjutnya adalah mencari cara bagaimana informasi dikumpulkan secara efektif. Adapun
cara-cara yang digunakan meliputi :
Interview
JAD (Joint application development) session
Document Analysis.
Interviews
Interview merupakan cara yang paling umum digunakan. Secara umum interview dapat
dilakukan dengan cara :
one on one interview.
one on many interview.
2013 3 Analisa Perancangan Berorientasi Objek Modul 05 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Ada lima tahapan dalam melakukan interview :
1. Memilih object interview. Memilih orang yang ditanya dengan membuat jadwal yang
berisi nama dan jadwal interview. Jadwal dapat saja informal, tetapi harus
merupakan bagian dari rencana kerja.
2. Merancang pertanyaan yang digunakan untuk interview, dapat saja meliputi :
1. Open ended question. Jenis pertanyaan yang bersifat terbuka untuk dapat
mengumpulkan informasi yang lebih kaya.
2. Closed Ended Question. Jenis pertanyaan tertutup yang berada dibawah kendali
penanya. Pertanyaan ini lebih ditujukan untuk apa.
3. Probing Question. Jenis pertnyaan ini sangat terbuka dan memungkinkan
penanya untuk mengungkapkan yang lebih lanjut lagi dari subject yang
ditanyakan. Jenis pertanyaan ini menyebabkan yang ditanya akan bebicara lebih
luas untuk lebih menjelaskan lagi persepsinya.
4. Yang terpenting jangan menanyakan pertanyaan yang sudah ada jawabannya.
5. Kombinasi dari ketiga jenis pertanyaan digunakan karena tidak ada yang lebih
baik atau lebih buruk
6. Pada saat project berjalan. Semakin lama analis akan memahami business
proses yang dilakukan. Sehingga ia akan memerlukan informasi yang lebih terinci
dan spesifik. Pada tahapan ini analis akan melakukan structured interview, disini
akan lebih banyak pertanyaan yang tertutup.
7. Selanjutnya harus diperhatikan strategi penentuan pertanyaan apakah Top-Down
atau Bottom-Up.
8. Top-down merupakan pendekatan yang paling umum dilakukan. Top down
memungkinkan penanya memahami terlebih dahulu topic yang ditanyakannya.
9. Jika analis sudah memiliki pemahaman yang lebih ia mungkin akan melakkukan
apa yang disebut dengan Bottom-up approach.
3. Mempersiapkan interview. Persiapan interview sangat penting. Sama pentingnya
dengan mengadakan presentasi. Harus ada rencana apa yang akan ditanyakan.
Harus diperhatikan bahwa pertanyaan yang akan diajukan haruslah dapat dijawab..
1. Closed ended question lebih memerlukan waktu untuk persiapannya
2. Yang paling berbahaya adalah unstructured interview karena hasil yang diperoleh
memerlukan follow up effort.
2013 4 Analisa Perancangan Berorientasi Objek Modul 05 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
4. Melakukan interview. Pastikanlah bahwa interview berjalan dengan baik dimana yang
diwawancarai akan secara terbuka mau menjawab pertanyaan dengan baik dan
benar. percaya kepada interviewr. Adapun aturannya adalah :
1. Tulis semua yang dijawab dan dikatakan.
2. Pahami apa yang didiskusikan.
3. Pisahkan fata dengan opini.
4. Pastikanlah bahwa orang yang ditanya juga punya kesempatan untuk bertanya
5. Pada akhir interview beritahukanlah dengan ringkas apa yang akan dilakukan
selanjutnya.
5. Post-Interview Follow-up. Setelah interview selesai siapkan interview report yang
menjelaskan informasi yang telah diperoleh dari orang yang ditanya. Mintalah orang
ditanya untuk membaca dengan seksama dan mungkin perlu ada koreksi jika
diperlukan.
Gambar 1 Top-Down & Bottom Questioning Strategies.
Joint Application Development (JAD) JAD adalah information gathering technique yang memungkinkan project team, user, dan
management bekerja sama untuk dapat memperoleh requirement dari system. JAD
dikembangkan oleh IBM pada akhir 1970an. Dianggap sebagai metode yang cukup baik
sehingga dapat :
1. Mengurangi scoop creep sampai 50 %.
2. Menghindarkan requirement yang terlalu spesific atau kurang jelas.
3. JAD merupakan proses yang terstruktur dimana 10 sampai 20 user bertemu dibawah
2013 5 Analisa Perancangan Berorientasi Objek Modul 05 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
pimpinan fasilitator yang memahami teknik JAD dan permasalahan yang dibahas
tetapi tidak ikut sebagai partisipan.
4. JAD akan bertemu sesuai dengan batas waktu yang ditentukan sampai menemukan
requirement yang dianggap perlu.
5. Menggunakan bermacam-macam perangkat diantaranya adalah CASE-tools.
6. Tempat dilaksanakannya JAD ditempat yang jauh dari tempat kerja partisipan.
7. Perhatikanlah agar komunikasi dapat berjalan dengan effetive.
Urut-urutan pelaksanaan JAD adalah :
1. Memilih partisipan. Partisipan dipilih berdasarkan informasi yang dapat diberikan,
yang terdiri-dari bermacam-macam tingkatan organisational, tujuannya untuk
membangun political support untuk system yang akan dibuat.
2. Merancang Sesi. Biasanya sesi JAD akan berlangsung selam 4 hari dalam satu
minggu atau 8 hari dalam 2 minggu, dan seterusnya. Karena peserta biasanya pada
akhir sesi harus melakukan analisis dan koleksi data.
3. Menyiapkan Sesi. Memastikan bahwa partisipan memahami apa yang diharapkan
dari mereka.
4. Melaksanakan JAD. Fasilitator harus memegang peranan utamanya dalam
mengarahkan diskusi peserta JAD :
5. Memastikan agenda dipenuhi
5. Membantu memahami istilah teknis dan methodologi.
5. Merekam apa yang menjadi hasil JAD dan mendistribusikannya.
5. Post JAD Follow-up. Setelah JAD selesai dilaksanakan haruslah ada dokumentasi
yang diterbitkan dan ditindaklanjuti.
2013 6 Analisa Perancangan Berorientasi Objek Modul 05 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Gambar 2 Ruang Pelaksanaan JAD.
Questionnaires Questionaire adalah sehimpunan pertanyaan tertulis untuk memperoleh informasi dari
individuals. Questionarire digunakan untuk mengumpulkan opini dari banyak orang. Urut-
urutan pelaksanaannya adalah sebagai berikut :
1. Memilih Participants
2. Merancang Questionaire
3. Administrasi questionaire
4. Questionaire Follow Up.
Document Analysis
Dokumen dianalisa untuk memahami sistem berjalan maupun project yang sedang berjalan.
Dokumen dapat saja terdiri dari :
1. Laporan
2. Memorandums
3. Policy Manuals
4. User Training Manuals
5. Organization charts
6. Forms.
2013 7 Analisa Perancangan Berorientasi Objek Modul 05 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Indikasi bahwa sistem harus diperbaiki adalah jika banyak tambahan informasi yang
diletakkan pada dokumen.
Observation Observasi atau melihat adalah adalah alat yang powerful untuk memperoleh informasi
mengenai sistem yang berjalan secara nyata bukan secara terdokumentasi. Observasi
adalah cara yang baik untuk memeriksa kebenaran informasi dari sumber yang tidak
langsung.
Observasi menjadi supplemen/pelengkep dari informasi yang diperoleh dari interview
dengan responden
Pemilihan tehnik Setiap teknik untuk requirement gathering ditentukan mana yang akan dipilih, atau digunakan bersama-sama dengan yang lain. Kriteria penilaiannya adalah :
1. Type of Information. Jenis informasi yang diperlukan
2. Depth of Information. Kedalaman Informasi yang diberikan
3. Breadth of Information. Range/sebaran informasi yang dapat dikumpulkan
4. Integration of Information. Bagaimana mengabungkan Informasi yang diperlukan.
5. User Involvement. Keterlibatan User
6. Biaya yang diperlukan.
Berikut ini adalah ringkasan dari pemilihan tehnik pengumpulan requirement.
Gambar 3. Requirements-Gathering Technique
Selanjutnya akan dibahas bagaimana menggunakan bermacam-macam notasi yang
berhubungan dengan Analisa dan Perancangan Sistem dengan menggunakan methodologi
yang menggunakan UML oleh karena itu untuk memaksa memahami data berikutnya akan
2013 8 Analisa Perancangan Berorientasi Objek Modul 05 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
dibahas ER dengan notasi UML sehingga kita akan tahu kegunaan melakukan analisa
dengan menggunakan class-diagram UML.
Entity Relationship Modeling
Permasalahan dengan pemodelan data adalah, perbedaan pandangan dari
pengguna akhir, perancang, programmer, dan administrator mengenai apa yang
seharusnya direpresentasikan didalam database. Karena itu diperlukan cara yang
tidak ambigous untuk menampilkan model yang dimiliki. Pendekatan ini adalah
pendekatan semantik terhadap data. ER-modeling adalah pendekatan yang akan
kita gunakan. Didalam ER-modeling kita akan menggunakan pendekatan yang
mewakili pandangan para pengguna tersebut. ER-modeling adalah pendekatan yang
bersifat top-down dimana perancangan dimulai dengan melakukan identifikasi data
penting yang disebut entity dan hubungan antar entity yang bisa teridentifikasi, untuk
selanjutnya kita akan menambahkan rincian yang nantinya akan menyimpan
informasi mengenai entity yang disebut attribute dan constraint (batasan) pada
entity-entity, relationship-relationhip, dan attribute-attribute.
Didalam pembahasan ini kita juga akan menggunakan notasi UML (Unified
Modelling Language) yang saat ini banyak digunakan untuk aplikasi-aplikasi
perancangan sistem berbasis obyek (Object Oriented Analysis and Design).
Meskipun kita menggunakan notasi UML kita tetap akan menggunakan istialah
database yang sudah kita kenal. Adapun tujuan penggunaan notasi ini adalah untuk
menggunakan notasi yang memiliki sitaksis dan semantik yang lebih kaya
dibandingkan dengan notasi crow (ceker ayam) dan Chen serta telah didukung oleh
perangkat gambar open source seperti Dia.
2013 9 Analisa Perancangan Berorientasi Objek Modul 05 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Gambar 4. Entity Types.
Entity Types Entity Type adalah sehimpunan obyek sama memiliki properties (ciri-ciri) yang dapat
diidentifikasikan dan terdapat contoh kejadiannya Obyek-obyek tersebut tentunya harus
memiliki kepentingan bagi pengolahan data sehingga perlu diidentifikasikan dengan jelas.
Contoh kejadian atau benda adalah Mahasiswa (nyata) ataupun jadwal kuliah (abstract).
Perhatikanlah gambar dibawah ini yang merupakan contoh Diagram ER.
2013 10 Analisa Perancangan Berorientasi Objek Modul 05 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Notasi Setiap entity dialam ER diagram dinotasikan dengan sebuah kotak dengan nama entity.
Nama entity adalah kata benda tunggal, Selanjutnya huruf pertama adalah huruf besar.
Gambar dibawah ini menunjukkan contoh dari penggambaran entity
Relatioship Types
Relationship adalah sehimpunan asosiasi yang bermakna. Yang dimaknud
bermakna adalah asosiasi yang memiliki kepentingan didalam konteks pengolahan
data. Selanjutnya setiap relationship diberi nama yang harus dapat menunjukkan
hubungan antar entity. Relationship dapat memiliki derajat hubungan satu (unary),
dua (binary), tiga (ternary), empat (quartenary), ataupun lebih.
Notasi Setiap relationship ditunjukkan dengan garis yang menghubungkan entity type, dan diberi
nama. Sedangkan untuk menunjukkan hubungan tiga atau lebih menggunakan berlian
(diamond) perhatikanlah contoh gambar hubungan quartenary dibawah ini.
Recursive Relationship Recursive relationship adalah relationship type dimana beberapa obyek dari entity yang
berjenis sama berpartisipasi dalam satu relatioship tapi dalam kepasitasnya yang berbeda
contohnya adalah hubungan antara dosen biasa dan dosen supervisor.
Attributes
Attribute merupakan properties (ciri-ciri) dari sebuah entity atau relationship type.
Sebagai contoh adalah NIM, NamaMahasiswa, dan lain sebagainya. Attribute
tersebut menyimpan nilai yang menjelaskan contoh kejadian dari entity dan disimpan
sebagai data didalam database. Adapun nilai yang disimpan haruslah nilai yang sah.
Contoh nilai yang sah adalah jenis kelamin hanya terdiri dari 2 nilai saja yaitu laki-
laki dan peyempuan. Himpunan nilai yang sah dari suatu attribute disubut sebagai
attribute domain.
2013 11 Analisa Perancangan Berorientasi Objek Modul 05 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Simple & Composite
Simple attribute merupakan attribute yang memiliki nilai tunggal yang berdiri sendiri.
Contoh dari jenis attribute ini adalah NIM yang hanya memiliki nilai tunggal untuk
seorang mahasiswa. Attribute ini juga disebut attribute yang bersifat atomic yang
artinya tidak bisa dipecah menjadi bagian-bagian yang lebih kecil.
Sedangkan Composite attribute merupakan attribute yang terdiri dari banyak komponen.
Dimana setiap komponennya merupakan nilain tunggal yang beridi sendiri, sebagai contoh
adalah alamat yang terdiri dari jalan, kelurahan, kecamatan, dati2, dan propinsi.
Single-Valued & Multi-Valued Attribute Single-Valued attribute merupakan attribute yang hanya berisi satu nilai saja untuk setiap
contoh kejadian dari entity, sebagai contoh adalah NIM hanya berisi satu nilai saja untuk
seorang mahasiswa.
Sedangkan multi-valued attribute merupakan attribute yang terdiri dari beberapa nilai.
NomorTelepon dapat saja maksimum diisi sebanyak 3 nomor.
Derived Attributes
Derived attribute merupakan attribute yang merepresentasikan nilai yang dapat diturunkan
dari nilai attribute yang lain, yang boleh jadi berasal dari entity yang berbeda. Contoh dari
hal ini adalah jumlahdosen yang merupakan hasil pencacahan dari dosen yang ada.
Keys Candidate keys adalah himpunan attribute yang jumlahnya aharus minimal yang dapat
mengidentifikasi baris secara unik didalam suatu tabel
Primary Key adalah candidate key yang terpilih untuk mengidentifikasi sebauah baris secara
unik
Notasi Attributes Attribute diletakkan pada kotak dibawah nama entity. Primary key diberi label {PK}.
Strong and Weak Entity
1. Strong Entity adalah entity yang keberadaan contoh kejadiannya tidak tergantung
kepada contoh kejadian dari entity type yang lain.
2. Weak Entity type adalah etntiy yang contoh kejadiannya tergantung kepada contoh
kejadian dari entity type yang lain contohnya adalah Karyawan dan
TanggunganKaryawan.
2013 12 Analisa Perancangan Berorientasi Objek Modul 05 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
3. Attributes on Relationships. Kita bisa menambahakan attributes pada relationships.
Adanya attribute pada relationship menunjukkan adanya entity yang belum
teridentifikasi. Notasi yang digunakan sama dengan yang digunakan oleh entity,
tetapi sesuai dengan semantik yang disampaikan notasi tersebut tanpa menunjukkan
adanya class.
Structural Constraint
Ada 3 jenis structural constraint yang harus diperhatikan yaitu :
1. One to One -> Satu ke Satu
2. One to Many -> Satu ke Banyak
3. Many to Many -> Banyak ke banyak
Notasi
Untuk menggambarkan constraint tersebut digunakan notasi :
Harus :
1. One to One -> 1..1
2. One to Many -> 1..*
3. Many to Many -> *..*
Optional :
1. Nol sampai satu 0..1
1. Nol sampai banyak 0..*
2. Nol sampai tiga misalnya 0..3
&&&&
2013 13 Analisa Perancangan Berorientasi Objek Modul 05 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Daftar Pustaka
Alan Denis, Barbara Haley Wixon, David Tagerden, System Analys and Design : an Object –
Oriented Approach with UML 2.0, John Willey and Sons, 2005
Henry C. Lucas Jr., The Analysis, Design and Implementation of Information Systems 4th,
McGraw Hill, 1992
Satzinger, Jackson, Burd, Object-Oriented Analysis and Design with the Unified Process,
Course Technology, 2005
Simon Bennet, Steve McRobb and Ray Farmer, Object-Oriented System Analysis and
Design Using UML, McGraw Hill, 2006
Wendy and Michael Boggs, UML with Rational Rose 2002, Sibex Inc., 2002
MODUL PERKULIAHAN
ANALISA
PERANCANGAN BERORIENTASI OBJEK
Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana
Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh
Ilmu Komputer Teknik Informatika
06 87016 Tim Dosen
Abstract Kompetensi
Memahami kebutuhan sistem Menentukan kebutuhan teknik dan menganalisa kebutuhan
2013 2 Analisa Perancangan Berorientasi Objek Modul 06 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Functional Modelling Functional model menjelaskan business process dan interaksi dari Teknik Informatika
dengan lingkungannya. Didalam OOAD ada dua buah model yang digunakan didalam
analisis dan disain :
1. Activity diagram. Menjelaskan pemodelan logical dari proses bisnis dan workflow
pekerjaan didalam bisnis. Notasi ini digunakan untuk menjelaskan apa yang telah
berlaku sekarang dan yang akan berlangsung pada sistem yang baru. Sebuah
activity diagram dapat digunakan untuk menjelaskan bermacam pemodelan aktifitas
yang berlangsung didalam sebuah Teknik Informatika yang berjalan pada sebuah
business sistem.
2. Use Case. Use case digunakan untuk menjelaskan fungsi dasar Teknik Informatika.
Notasi ini digunakan untuk menjelaskan apa yang telah berlaku sekarang dan yang
akan berlangsung pada sistem yang baru. Sebuah use case adalah cara formal
untuk menjelaskan bagaimana sebuah business system berinteraksi dengan
lingkungannya. Sebuah use case menjelaskan aktifitas yang dilakukan oleh
pengguna didalam sebuah Teknik Informatika. Use case dapat dilihat sebagai
gambaran eksternal atau gambaran functional sebuah proses business dimana
didalamnya diperlihatakan bagaimana pandangan pengguna terhadap sistem
3. Activity diagram dan use case merupakan logical models yaitu model yang
menjelaskan aktifitas-aktifitas yang terjadi didalam sebuah business domain tanpa
menjelaskan secara terinci bagaimana mereka harus dilakukan. Logical models
disebut juga sebagai problem domains models.
4. Disamping itu Activity diagram dan use case juga merupakan physical model yang
menggambarkan aktifitas fisik terinci yang memungkinkan sistem berjalan dengan
baik.
5. Dengan memfokuskan diri pada logical modelling analyst dapat melihat business
process tanpa harus memperhatikan implementation details terlebih dahulu.
Tujuan dari requirement determination adalah untuk merubah very high level explanation of
the business requirement menjadi daftar yang lebih jelas dari requirement yang dapat
digunakan sebagai input untuk analysis (membuat , functional models, structural models,
and behavioral models)
2013 3 Analisa Perancangan Berorientasi Objek Modul 06 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Pengertian Requirement Requirement adalah pernyataan apa yang harus dilakukan oleh sistem atau karakteristik apa
yang harus dimiliki :
6. Didalam tahapan analisis requirement ditulis dari sudut pandang business, atau apa
yang dilakukan oleh sistem. Fokusnya ada pada "WHAT". Fokusnya ada pada user
needs, sehingga biasanya disebut business requirements.
7. Selanjutnya didalam tahapan design, business requirement bergerak menjadi lebih
teknis, dan akan menjelaskan bagaimana (HOW) sistem akan diimplementasikan.
Requirement pada saat design dilihat dari sudut pandang pembuat sistem
(developer).
Use haruslah dapat menggambarkan user requirement. Yang harus diperhatikan bahwa
pembatas antara analisis dan perancangan remang-remang. Beberapa pihak menggunakan
istilah tersebut secara bolak-balik. Yang harus diperhatikan adalah requirement adalah
pernyataan apa yang harus dilakukan oleh sistem dan selalu da kemungkinan untuk
berubah. Secara umum requirement terbagi dua yaitu :
1. Functional requirement. Requirement ini berelasi langsung dengan dengan proses
yang harus dilakukan oleh sistem yang akan dibuat sehingga dapat menyediakan
informasi yang diperlukan. Functional requirement mengalir langsung kedalam
tahapan analisis selanjutnya, karena mendefinisikan fungsi-fungsi yang harus dimiliki
oleh sistem. Perhatikanlah Gambar 1 mengenai Functional Requirements
2. Nonfunctional requirement. Requirement ini berhubungan dengan behavioral
properties yang harus dimiliki oleh sistem, seperti performance and usability.
menjelaskan bermacam-macam karakteristik sistem : operational, performance,
secutiry, cultural and political. Karakteristik tersebut tidak menjelaskan business
process ataupun informasi yang diperlukannya, tetapi sangat penting untuk dpat
memahami apa yang harus dimiliki oleh sistem final.
Didalam menentukanUntuk menentukan requirement diperlukan pemahaman business dan
IT. Hal ini bisa dianalogikan seperti membuat bangunan. Jika kita pemilik tumah, maka kita
tahu apa yang kita inginkan dari rumah kita, tetapi kita tidak akan dapat membuatrancangan
rumah. Demikan juga dengan seorang ahli bangunan sipil atau arsitek tidak akan dapat
menentukan bentuk bangunan dengan baik meskipun memiliki kemampuan teknis untuk
dapat menggambarkannya jika tidak berkomunikasi dengan orang yang akan menggunakan
bangunan tersebut. Karena pendekatan terbaik adalah mempekerjakan ahli business dan IT
2013 4 Analisa Perancangan Berorientasi Objek Modul 06 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
bersama-sama untuk membuat analisa sistem. Kadang kala pengguna tidak tahu secara
tepat apa yang diinginkannya maka analis akan membantunya dengan
teknik/perangkat/notasi dan pemahaman yang dimilikinya. Teknik yang populer untuk
melakukan analisis adalah :
Business process Automation.
Business Process Improvement.
Business Process Reengineering.
1. Business Process Modelling dengan Activity Diagrams Business process model menjelaskan bermacam-macam aktifitas yang menjadi pendukung
dari proses buiness yang dilakukan sehari-hari. Business process biasanya memotong
beberapa departemen fungsional sehingga melibatkan fungsionalitas beberapa department.
1.1 Elemen dari activity diagram Activity diagram merupakan gambaran sebuah data flow yang lebih mutakhir dibandingkan
dengan flow chart maupun DFD didalamnya dapat menggambarkan pararel process dan
aktifitas yang lebih rumit. Berikut ini adalah contoh dari Activity diagram.
Gambar 1 Contoh Activity Diagram untuk Pendaftaran Pasien
2013 5 Analisa Perancangan Berorientasi Objek Modul 06 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Elemen-elemen dari activy diagram adalah :
1. Action :
a. Behaviour sederhana yang tidak bisa dipecah lagi (secara conceptual).
b. Diberi label dengan nama
2. Activity :
a. Digunakan untuk menggambarkan sehimpunan Action
b. Diberi label dengan nama
3. Control flow : Memperlihatkan urut-urutan eksekusi.
4. Object flow :Memperlihatkan aliran object adi sebuah action atau activity ke action
atau activity lain.
5. Initial node : Memperlihatkan titik awal.
6. Final Activity node : Akhir dari sebuah activity diagram
7. Final flow node : Digunakan untuk menghentikan sebuah control flow atau object flow
yang spesific.
8. Decision node :
a. Digunakan untuk menggambarkan test condition untuk memastikan bahwa
control flow atau object flow mengalir ke lebih dari satu jalur.
9. Merge node : digunakan untuk menggabungkan kembali decision path.
10. Fork Node : Digunakan untuk memecah sebuah behaviour menjadi activity atau
action pararel yang pararel.
11. Join node : digunakan untuk menggabungkan kembali activity atau action yang
pararel.
12. Swimlane :
a. digunakan untuk memecah activity diagram kedalam baris dan kolom untuk
membagi tanggung jawab kepada object-object yang melakukan aktifitas
tersebut.
b. Diberi label dengan nama object yang bertanggung jawab untuk menjalankan
activity atau action.
Adapun garis besar yang harus diikuti untuk membuat activity diagram, adalah :
Since an activity diagram can be used to model any kind of process, you should set
the context or scope of the activity being modeled. Once you have
determined the scope, you should give the diagram an appropriate title.
You must identify the activities, control flows, and object flows that occur between the
activities.
2013 6 Analisa Perancangan Berorientasi Objek Modul 06 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
You should identify any decisions that are part of the process being modeled.
You should attempt to identify any prospects for parallelism in the process.
You should draw the activity diagram.
2. Use Case Use case adalah penjelasan dari fungsi sistem dilihat dari kaca mata penggunanya. Use
case diagram merupakan sebuah functional diagram yang menggambarkan fungsi dasar
dari sistem. Yaitu apa yang dapat digunakan oleh user dan bagaimana sistem harus
merespon terhadap user action. Tahapan yang harus dialui adalah :
Membuat text base description.
Menterjemahkan use case menjadi use case diagram.
Use case menjelaskan sebuah fungsi didalam organisasi tetatpi terdiri dari bermacam-
macam action dan aktifitas.
Use case dikembangkan dengan cara bersama-sama dengan user. Use case diagram
menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang
ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case
merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan
sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja,
dan sebagainya.
Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan
sistem untuk melakukan pekerjaan-pekerjaan tertentu.
Use case diagram dapat sangat membantu bila kita sedang menyusun requirement sebuah
sistem, mengkomunikasikan rancangan dengan klien, dan merancang test case untuk
semua feature yang ada pada sistem.
Sebuah use case dapat meng-include fungsionalitas use case lain sebagai bagian dari
proses dalam dirinya. Secara umum diasumsikan bahwa use case yang di-include akan
dipanggil setiap kali use case yang meng-include dieksekusi secara normal.
Sebuah use case dapat di-include oleh lebih dari satu use case lain, sehingga duplikasi
fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas yang common.
Sebuah use case juga dapat meng-extend use case lain dengan behaviour-nya sendiri.
2013 7 Analisa Perancangan Berorientasi Objek Modul 06 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Sementara hubungan generalisasi antar use case menunjukkan bahwa use case yang satu
merupakan spesialisasi dari yang lain.
2.1. Jenis jenis use case Use case merupakan :
use case capture a contract ….[that] describes the system’s behaviour under various
conditions as the system respons to request from one of its stakeholders
Pada dasarnya use case adalah ceritera lengkap dengan sebuah form tertentu tentang
bagaimana pengguna system berinteraksi dengan system didalam suatu keadaan tertentu.
Tahapan pertama dalam menulis use case adalah menentukan actor yang diikutkan didalam
ceritera. Actor adalah orang atau perangkat yang menggunakan system atau product
didalam context system atau behaviour yang dilakukan.
Actor dan end-user belum tentu orang yang sama . User boleh jadi melakukan peran yang
berbeda sehingga user dan actor belum tentu sama. Yang harus diperhatikan adalah
pembuatan use case merupakan aktifitas yang berulang dimana tidak seluruh actor dapat
ditemukan pada iterasi yang pertama. Sesudah actor dapat diidentifikasi use case dapat
dikembangkan. Ivar Jacobson menyarankan beberapa pertanyaan untuk dapat memahami
use case apa yang ada didalam sebuah object analisis dan disain :
Ada dua jenis use case yaitu :
1. Overview vs detail. Overview use case digunakan untuk memungkinkan analis dan
user setuju atas requirement secara umum. Jika sudah dipahami bersama-sama
maka requirement tadi akan dikonversi menjadi detail use case :
a. Presents an important business process.
b. The use case supports revenue generation or cost reduction.
c. Technology needed to support the use case is new or risky and therefore will
require considerable research.
2. Essential versus real. Pada essential use case yang dijelaskan adalah minimal
essential issues untuk memahami required functinality, sedangkan pada real use
case yang harus dijelaskan adalah lengkah-langkah terinci dari Teknik Informatika.
Untuk membuat use case petunjuk yang diberikan adalah :
1. Write each step in “SVDPI (Subject – Verb – Direct Object or Preposition – Indirect
Object)" form. Setiap langkah didalam Use case dituliskan secara lengkap dengan
aturan tata bahasa yang baik
2013 8 Analisa Perancangan Berorientasi Objek Modul 06 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
2. Clarify initiator and receivers of action. Siapa yang memulai action harus jelas, dan
siapa yang menjawab tindakan tersebut juga harus dijelaskan dengan terinci.
(System Response harus jelas)r
3. Write from independent observer perspective. Ditulis secara independent tidak
secara judgemental.
4. Write at same level of abstraction. Tingkat abstraksi harus sama dengan responden
yang ditanya.
5. Ensure a sensible set of steps. Urut-urutan langkah harus masuk akal. Secara logis
urut-urutan harus benar berurut
6. Apply KISS principle liberally. Use case harus dibuat sederhana, dan mudah
dipahami (Keep it simple stupid).
7. Write repeating instructions after the set of steps to be repeated. Tulislah
instruksi untuk mengulang sesudah langkah penjelasan langkah yang harus
dilakukan.
Adapun notasi notasi yang digunakan adalah sebagaimana diperlihatkan pada Gambar 3
yang meliputi :
1. Actor/Role.
2. Use Case.
3. System
4. Association yang dapat berjenis :
5. Association Relationship
6. Include Relationship
7. Extend Relationship
2013 9 Analisa Perancangan Berorientasi Objek Modul 06 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Gambar 3. Notasi Use Case
Gambar 4. Use Case Diagram
2013 10 Analisa Perancangan Berorientasi Objek Modul 06 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Gambar 5. Extend dan Include Relationship.
Gambar 6. Cara Identifikasi Use Case
2013 11 Analisa Perancangan Berorientasi Objek Modul 06 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Daftar Pustaka
Alan Denis, Barbara Haley Wixon, David Tagerden, System Analys and Design : an Object –
Oriented Approach with UML 2.0, John Willey and Sons, 2005
Henry C. Lucas Jr., The Analysis, Design and Implementation of Information Systems 4th,
McGraw Hill, 1992
Satzinger, Jackson, Burd, Object-Oriented Analysis and Design with the Unified Process,
Course Technology, 2005
Simon Bennet, Steve McRobb and Ray Farmer, Object-Oriented System Analysis and
Design Using UML, McGraw Hill, 2006
Wendy and Michael Boggs, UML with Rational Rose 2002, Sibex Inc., 2002
MODUL PERKULIAHAN
ANALISA
PERANCANGAN BERORIENTASI OBJEK
Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana
Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh
Ilmu Komputer Teknik Informatika
07 87016 Tim Dosen
Abstract Kompetensi
Memahami kebutuhan sistem Menentukan kebutuhan teknik dan menganalisa kebutuhan
2013 2 Analisa Perancangan Berorientasi Objek Modul 07 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Structural Modelling 7.1 Pendahuluan
Structural modelling adalah:
1. A structural or conceptual model describes the structure of the data that supports the
business processes in an organization. Model terstruktur atau konseptual yang
menjelaskan struktur data yang digunakan didalam business proses didalam
organisasi.
2. The structure of data used in the system is represented through CRC cards, class
diagrams, and object diagrams.
Tujuan dari pemodelan tersebut adalah :
1. Reduce the “semantic gap” between the real world and the world of software.
2. Create a vocabulary for analysts and users
3. Represent things, ideas, and concepts of importance in the application domain
7.1.1 CLASS dan OBJECT
CLASS adalah template/cetakan yang digunakan untuk mendefinisikan suatu
instance/contoh kejadian yang disebut object. Object adalah contoh kejadian dari class.
setiap object pasti akan berasosiasi tepat dengan satu class.
Setiap object memiliki attributes yang berisikan informasi mengenai object tersebut. State
dari sebuah object ditentukan oleh nilai dari attributes dan relationshipnya pada suatu waktu
tertentu.
Setiap object juga memiliki behaviour yang menspesifikasikan apa yang bisan dilakukan
sebuah object.
2013 3 Analisa Perancangan Berorientasi Objek Modul 07 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
7.1.2 Methods dan Messages
Method merupakan implementasi dari behaviour(kelakukan) sebuah object. Method adalan
sebuah action(tindakan) yang dapat dilakukan oleh object. Method dapat dianalogikan
dengan fungsi sebagaimana terdapat didalam bahasa C. Message merupakan informasi
yang dikirimkan ke Object yang akan menjadi pemicu dari dilakukannya sebuah tindakan.
7.1.3 Encapsulation dan Information Hiding
Pemikiran mengenai encapsulation dan Information hiding sudah ada sejak jaman dahulu
kala. Encapsulation adalah kombinasi dari proses dan data yang diletakkan didalam sebuah
class. Didalam OOSAD yang dimaksudkan dengan
Encapsulation adalah meletakkan attribute dan behaviour kedalam sebuah object yang
dispesifikasikan didalam class. didalam notasi yang digunakan UML 2.0 attribute diletakkan
pada bagian atas sedangkan behaviour diletakkan pada bagian bawah dari kotak.
Information hiding adalah sebuah cara berpikir dimana informasi yang diperlukan oleh
penggunalah yang akan ditampilkan sedangkan yang tidak diperlukan tidak usah
ditampilkan/diberikan. Konsekuensinya yang dapat diakses adalah bagian dari object yang
digunakan untuk menerima perintah dan memberikan informasi kepada pengguna object
tersebut. Sehingga object diperlakukan seperti sebuah kotak hitam.
The only information that an object needs to know is the set of operations, or
methods, that other objects can perform and what messages need to be sent to
trigger them.
7.1.4 Inheritance
Inheritance atau pewarisan digunakan untuk mengidentifikasi object/class yang memiliki
tingkat yang lebih tinggi dan lebih general. Atributes dan methods yang sama dikelompokkan
menjadi sebuah superclass. Biasanya superclass diletakkan diatas dan turunannya
diletakkan dibawah. Hubungan inheritance yang terjadi adalah A KIND OF.
2013 4 Analisa Perancangan Berorientasi Objek Modul 07 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Subclass akan mewarisi attributes dan methods dari class yang berada diatasnya. Artinya
subclass berisi attributes dan methods dari superclass yang berada diatasnya.
Class yang berada didalam rantai hierarchy pasti akan ada yang memiliki instance/contoh
kejadian. Class yang memiliki contoh kejadian disebut concrete class. Ada juga class yang
menjadi superclass yang menjadi template bagi sebagian dari class yang berada
dibawahnya. Class tersebut merupakan abstract class.
Pada contoh Person adalah abstract class sedangkan Doctor dan Patient merupakan
concrete class
2013 5 Analisa Perancangan Berorientasi Objek Modul 07 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
7.1.5 Polymorphism dan Dynamic Binding
Polymorphism artinya message yang sama diinterpretasikan/memiliki arti/bentuk yang
berbeda. Sebagai contoh jika kita beri perintah draw kepada object segi empat, segi tiga,
dan lingkaran akan menjalankan perintah yang berbeda. Dibawah ini adalah contoh
polymorphism :
int kali(int a, int b);
int kali(int a, int b, int c);
maka fungsi mana yang akan dijalankan tergantung kepada argumen yang disertakan.
Polymorphism dapat terlaksanya karena adanya dynamic binding. Dynamic, atau, late
binding adalah teknik/cara penundaan penentuan jenis object sampai pada saat run-time.
Artinya method mana yang akan dijalankan ditunda sampai system/program berjalan.
Kontrasnya adalah static binding dimana setiap methods sudah ditentukan pada saat
kompilasi.
Attributes :
Units of Information relevant to the description of class (attribute berisi informasi yang
menjelaskan class
2013 6 Analisa Perancangan Berorientasi Objek Modul 07 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Hanya attribute yang relevan yang disertakan dalam class diagram
Operations/Methods :
Aksi yang dilakukan oleh objects.
Berfokus pada operasi yang spesific untu sbh problem domain
Relationship :
1. Generalization Enables inheritance of attributes and operations
2. Aggregation Relates parts to wholes
3. Association Miscellaneous relationships between classes
7.2 Class Responsibilities and Collaboration Menunjukkan kerjasama dari classes untuk melakukan pemenuhan kebutuhan dari client :
1. Responsibilites adalah :
a. Knowing. Mengetahui apa yang harus dikerjakan untuk melayani permintaan
client
b. Doing. Melakukan apa yang diminta client
2. Collaboration Objects working together to service a request
2013 7 Analisa Perancangan Berorientasi Objek Modul 07 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Gambar 7-1 CRC Jenis-jenis attribute :
1. Derived atau attribute turunan yang diturunkan dari attribute primitive. Contoh
tanggal lahir adalah primitive. Umur adalah derived attributes
2. Visibility
3. Public bisa dilihat siapa saja
4. Protected hanya bisa dihubungi oleh class yang menjadi friend/teman
5. Private hanya bisa dilihat oleh class itu sendiri
Jenis-jenis operasi selain fungsi methods yang biasa :
1. Constructor. :
2. Secara otomatis akan dijalankan pada saat oject dibuat
3. Biasanya juga membuat object yang lain
4. Query : Menanyakan state dari object
5. Update : Merubah nilai dari beberapa atau seluruh attribute.
Relationship adalah hubungan antar object/class. Jenis hubungannya bermacam-macam :
1. Sebuah class dapat berhubungan denga dirinya sendiri atau disebut recursive
2. Multiplicity :
3. One to one
2013 8 Analisa Perancangan Berorientasi Objek Modul 07 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
4. Zero to many
5. One to many
6. Zero to one
7. Specified Range
8. Multiple disjoint range
Association
Gambar 7-2 Class Diagram
Class diagram dapat disederhanakan dengan hanya memperlihatkan bagian yang ingin
dilihat saja, tetapi paling tidak harus memiliki nama class. Disamping class digram terdapat
object diagram yang membantu memperlihatkan hubungan antar object atau contoh
kejadian dari sebuah class. Object diagram menggambarkan hubungan structural pada saat
run time. Contoh object diagram dapat dilihat pada gambar berikut
2013 9 Analisa Perancangan Berorientasi Objek Modul 07 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
7.3 Membuat CRC dan Class Diagram Yang pertama tama harus dilakukan adalah melakukan identifikasi object. Identifikasi object
dilakukan dengan cara membaca use case untuk kemudian dilakukan parsing dari setiap
kalimat yang terdapat didalam Use case scenario. Aktivitasnya meliputi :
1. Analisis tekstual dari use case (Textual analysis of use-case information)
:
1. Nouns suggest classes
2. Verbs suggest operations
2. Membuat gambaran secara kasar (Creates a rough first cut)
3. Membuat daftar object (Common object list)
4. Membuat daftar contoh kejadian
5. Membuat daftar peranan (Roles)
Setelah melakukan identifikasi class lalu membuat identifikasi pola :
1. hubungan antar class yang dapat dikelompokkan berdasarkan :
2. Transactions
2013 10 Analisa Perancangan Berorientasi Objek Modul 07 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
1. Transaction class
2. Transaction line item class
3. Item class
4. Location class
5. Participant class
Adapun tahapan tahapan pembuatan model struktural adalah :
1. Create CRC cards.
2. Examine common object lists.
3. Role-play the CRC cards.
4. Create the class diagram.
5. Review the class diagram.
6. Incorporate patterns.
7. Review the model.
&&&&&&&
2013 11 Analisa Perancangan Berorientasi Objek Modul 07 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Daftar Pustaka
Alan Denis, Barbara Haley Wixon, David Tagerden, System Analys and Design : an Object –
Oriented Approach with UML 2.0, John Willey and Sons, 2005
Henry C. Lucas Jr., The Analysis, Design and Implementation of Information Systems 4th,
McGraw Hill, 1992
Satzinger, Jackson, Burd, Object-Oriented Analysis and Design with the Unified Process,
Course Technology, 2005
Simon Bennet, Steve McRobb and Ray Farmer, Object-Oriented System Analysis and
Design Using UML, McGraw Hill, 2006
Wendy and Michael Boggs, UML with Rational Rose 2002, Sibex Inc., 2002
MODUL PERKULIAHAN
ANALISA
PERANCANGAN BERORIENTASI OBJEK
Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana
Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh
Ilmu Komputer Teknik Informatika
08 87016 Tim Dosen
Abstract Kompetensi
Memahami kebutuhan sistem Menentukan kebutuhan teknik dan menganalisa kebutuhan
2013 2 Analisa Perancangan Berorientasi Objek Modul 08 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Unified Modeling Language Unified Modeling Language (UML) adalah notasi yang lengkap untuk membuat visualisasi
model suatu sistem. Sistem berisi informasi dan fungsi, tetapi secara normal digunakan untuk
memodelkan sistem komputer. Di dalam pemodelan obyek guna menyajikan sistem yang
berorientasi pada objek pada orang lain, akan sangat sulit dilakukan jika pemodelan tersebut
dilakukan dalam bentuk kode bahasa pemrograman. Kesulitan yang muncul adalah timbulnya
ketidak jelasan dan salah interpretasi di dalam pembacaan kode pemrograman untuk
pemodelan objek tersebut.
Dimulai tahun 1994, Booch, Runbaugh dan Jacobson merupakan tiga tokoh yang metodelogi-
nya paling banyak dipakai mempelopori organisasi yang bertujuan menyatukan metodelogi-
metodelogi berorientasi objek, organisasi tersebut dinamakan OMG (Object Modelling
Group). Pada tahun 1995 OMG merealisasi draf pertama dari UML (versi 0.8) dan pada
tahun 1997 UML versi 1.1 muncul dan sekarang versi terbaru dari UML adalah versi 2.0.
Pada tahun 1997 Booch, Runbaugh dan Jacobson menyusun tiga buku tentang UML. Sejak
saat itulah UML telah menjelma menjadi standar bahasa pemodelan untuk aplikasi
berorientasi objek.
Notasi Dasar UML
Actor
Actor adalah segala sesuatu yang berinteraksi langsung dengan sistem aplikasi komputer,
seperti orang, benda atau lainnya. Tugas actor adalah memberikan informasi kepada sistem
dan dapat memerintahkan sistem agar melakukan sesuatu tugas. Lihat Gambar 1 di bawah.
Gambar 1 Notasi actor pada UML
Class
Notasi utama dan yang paling mendasar pada diagram UML adalah notasi untuk
mempresentasikan suatu class beserta dengan atribut dan operasinya. Class adalah pembentuk
2013 3 Analisa Perancangan Berorientasi Objek Modul 08 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
utama dari sistem berorientasi objek. Gambar 2 menunjukkan notasi dari class UML.
Gambar 2 Notasi class pada UML
Use Case
Use case adalah deskripsi fungsi dari sebuah sistem dari perspektif pengguna. Use case
bekerja dengan cara mendeskripsikan tipikal interaksi antara user (pengguna) sebuah sistem
dengan sistemnya sendiri melalui sebuah cerita bagaimana sebuah sistem dipakai. Urutan
langkah-langkah yang menerangkan antara pengguna dan sistem disebut scenario. Notasi use
case dapat di perlihatkan pada gambar dibawah berikut ini.
Gambar 3 Notasi use case pada UML
Diagram UML
UML merupakan sintak umum untuk membuat model logika dari suatu sistem dan digunakan
untuk menggambarkan sistem agar dapat dipahami selama fase analisis dan desain. UML
biasanya disajikan dalam bentuk diagram/gambar yang meliputi class beserta atribut dan
operasinya, serta hubungan antar class yang meliputi inheritance, association dan komposisi.
UML tediri dari banyak diagram, secara garis besar diagram yang terdapat pada UML dapat
diperlihatkan pada gambar dibawah ini :
2013 4 Analisa Perancangan Berorientasi Objek Modul 08 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Gambar 4 Diagram-diagram pada UML versi 2.0 (www.uml.org)
Use Case Diagram
Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem, yang
ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case
mempresentasikan sebuah interaksi antara actor dengan sistem. Use case menggambarkan
kata kerja seperti Login ke sistem, maintenance user dan sebagainya. Model use case seperti
pada Gambar 5 dan contoh use case diagram ditunjukkan pada Gambar 6 di bawah.
Actor Actor
Gambar 5 Use case model
Sistem
2013 5 Analisa Perancangan Berorientasi Objek Modul 08 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Penjaga Toko
Buat Laporan
Petugas Stok
Hitung Stok Barang
Petugas Keuangan
Hitung Penjualan
EntrY Permintaan
View Permintaan
<<extend>>
<<include>>
<<include>>
Gambar 6 Use case diagram pada penjualan VCD
Actor : penjaga toko dan petugas keuangan
Use case : entry permintaan, view permintaan, hitung penjualan dan buat
laporan.
Class Diagram
Class adalah sebuah spesifikasi yang jika di-instansiasi akan menghasilkan sebuah objek dan
merupakan inti dari pengembangan berorientasi objek. Class menggambarkan keadaan
(attribute/property) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi
keadaan tersebut (metode/fungsi). Class diagram menggambarkan struktur dan deskripsi
class, packed dan objek beserta hubungan satu sama lain seperti containment, pewarisan,
asosiasi dan lainnya. Lihat Gambar 7 dan Gambar 8 contoh class diagram di bawah.
2013 6 Analisa Perancangan Berorientasi Objek Modul 08 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Nama Class
Attibute
Operasi
Gambar 7 Sebuah class dalam UML
Gambar 8 Contoh class diagram penjualan VCD
Activity Diagram
Activity diagram menggambarkan berbagai alir aktifitas dalam sebuah sistem yang sedang
dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi dan
bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang
mungkin terjadi pada beberapa eksekusi. Activity diagram tidak menggambarkan sifat internal
dari sebuah sistem dan interaksi antara beberapa sub sistem secara eksak, tetapi lebih
Class
1. Attribut : tipe
2. Operasi : tipe
Cabang
Nama Cabang
Pelanggan
Nama Pelanggan
Pembayaran
Jumlah
Tunai
JmlKembalian
Order
No
Tgl
Order Detail
Jumlah
Kartu Kredit
No
Item Barang
Nama Barang
2013 7 Analisa Perancangan Berorientasi Objek Modul 08 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum. Pada
UML 2.X aktivitas tidak lagi disebut sebagai activity, akan tetapi cukup disebut dengan
action saja. Activity adalah struktur yang lebih tinggi yang terdiri atas action-action yang
berurutan. Oleh karenanya activity diagram menunjukkan action-action yang membangun
sebuah aktivitas. Berikut adalah simbol-simbol yang digunakan pada activity diagram.
Tabel 1 Tabel Simbol Activity Diagram
Simbol Keterangan
Titik Awal
Titik Akhir
Activity
Pilihan untuk pengambilan keputusan
Fork; Untuk menunjukkan kegiatan yang dilakukan secara paralel
Rake; menunjukkan adanya dekomposisi
Tanda Waktu
Tanda Penerimaan
Aliran Akhir (Flow Final)
Start
Tidak membeli VCD
End
Gambar 9 Contoh activity diagram penjualan VCD
Sequence Diagram
Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem
(termasuk pengguna, display dan sebagainya) berupa message yang digambarkan terhadap
Datang ke gallery VCD
Memilih VCD yang dibeli
Petugas Keuangan
Bayar VCD yang dibeli
2013 8 Analisa Perancangan Berorientasi Objek Modul 08 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
waktu. Sequence diagram terdiri atas waktu dan obyek-obyek yang terkait. Sequence diagram
biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang
dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu, proses dan
perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan.Gambar 10
menunjukkan esensi simbol dari sequence diagram dan simbol kerjanya secara bersama-
sama.
Actor
Objek
Message Lifeline
Gambar 10 Simbol-simbol yang ada pada sequence diagram
State Machine Diagram
Interaction diagram dan state chart menampilkan dua pandangan yang saling melengkapi
tentang perilaku dinamis sebuah sistem. Interaction diagram menunjukan pesan-pesan yang
dilewatkan diantara obyek-obyek didalam sistem selama periode waktu yang pendek.
Sedangkan state chart diagram menelusuri individu-individu obyek melalui keseluruhan daur
hidupnya, menspesifikasikan semua urutan yang mungki dari pesan-pesan yang akan di
terima objek tersebut bersama-sama dengan tanggapan atas pesan-pesan tersebut.
Simbol UML untuk state transition diagram adalah segiempat yang setiap pojoknya dibuat
rounded. Titik awalnya menggunakan lingkaran solid yang diasir dn diakhiri dangan mata.
Berikut adlah symbol UML untuk statechart.
Gambar 11 Simbol Statechart Diagram
Name 1 Name 2
2013 9 Analisa Perancangan Berorientasi Objek Modul 08 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
UML juga memberi pilihan untuk menambahkan detail ke dalam simbol tersebut dengan
membagi menjadi 3 area yaitu nama state, state variable dan activity.
Gambar 12 Penambahan detail ke state
State variable seperti timer dan counter kadangkala sangat membantu. Activity terdiri atas
events dan action. Tiga hal yang sering dipakai disini adalah entry ( apa yang terjadi ketika
sistem masuk ke state), exit ( apa yang terjadi ketika sistem meninggalkan state) dan do ( apa
yang terjadi ketika sistem ada di state). Hal-hal lain bisa ditambahkan jika perlu.
Collaboration Diagram
Informasi yang disampaikan sama dengan sequencial diagram namun beda dalam
pengambaran dan kegunaan saja. Dalam diagram ini digambarkan hubungan antar objek dan
actor dengan tidak memperhatikan waktu/urutan.
Gambar 13 Colaboration diagram
Component Diagram
Component diagram mengandung componet, interface dan relationship. Notasi component
bisa dilihat pada gambar dibawah ini.
Nama
State Variable
Activities
2013 10 Analisa Perancangan Berorientasi Objek Modul 08 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Gambar 14 Contoh notasi component
Hal penting pada component adalah component mewakili potongan-potongan yang
independent yang bisa dipesan dan diperbaharui sewaktu-waktu. Dengan demikian,
pembagian sistem kedalam component-component lebih banyak didorong oleh kepentingan
marketing dari pada kepentingan teknis. Meskipun demikian harus juga diingat bahwa terlalu
banyak component juga kurang bagus, karena susah mengatur dan memeliharanya khususnya
menyangkut masalah versioning.
Component digunakan untuk menunujukan struktur fisik seperti DAN LAIN-LAIN. Hal
tersebut tidak terlalu benar sekarang, karena struktur fisik ditunjukan dengan artifact. Artifact
adalah manifestasi fisik dari software, biasanya file. File-file ini biasanya bisa
dieksekusi/executable (seperti: . EXE file, biner, DAN LAIN-LAIN, file JAR, Assembly atau
Script), atau file-file data, file-file konfigurasi, dokumen HTML dan lain-lain.
Component dihubungkan melalui interface yang diimplementasikan. Biasanya menggunakan
notasi ball-and-socket seperti class diagram. Component juga bisa dikompose dengan
menggunakan composite struktur diagram.
Gambar 16 menunjukan contoh component diagram. Pada contoh ini, seorang sales mesin
dapat berhubungan dengan component server sales, dengan menggunakan interface sales
message. Karena networknya tidak dapat dipercaya, component antrian pesan (queue)
dipasang sehingga masih tetap dapat berhubungan dengan server ketika server sedang hidup
dan berhubungan dengan queue ketika network mati. Selanjutnya queue berhubungan dengan
server ketika network sudah berfungsi kembali. Hasilnya queue message hasus bisa
mendukung interface sales message untuk berhubungan dengan component mesin dan
membutuhkan interface tersebut untuk berhubungan dengan server. Server dibagi menjadi 2
component utama. Prosesor transaksi untuk merealisasikan interface sales message dan
accounting driver untuk berhubungan dengan system akutansi.
2013 11 Analisa Perancangan Berorientasi Objek Modul 08 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Gambar 17 Contoh component diagram
Deployment Diagram
Deployment diagram menunjukan tata letak sebuah system secara fisik, menampakkan
bagian-bagian software yang berjalan pada bagian-bagian hardware. Bagian utama
hardware/perangkat keras adalah node; yaitu nama umum untuk semuah jenis sumber
komputasi. Ada 2 tipe node yang mungkin. Processor adalah node yang bisa mengeksekusi
sebuah component, sedangakan device tidak. Device adalah perangkat keras (seperti printer
atau monitor) tipikalnya menjadi interface dengan dunia luar.
Node mengandung artifact, dimana artifact adalah manifestasi fisik dari software; biasanya
file. File-file ini biasanya bisa dieksekusi/executable (seperti: .EXE file, biner, DAN LAIN-
LAIN, file JAR, Assembly atau script), atau file-file data, file-file konfigurasi, dokumen
HTML dan lain-lain. Daftar artifact di dalam sebuah node menunjukan bahwa artifact
tersebut di deploy ke node tersebut pada saat system sedang dijalankan. Di UML, kubus
menunjukan node. Node bisa diberi nama & ditambahkan stereotype untuk
mengidentifikasikan tipe resource yang ada sebelumnya. Jika node adalah bagian dari
package, namanya bisa mengandung nama package tersebut. Kubus bisa juga ditambahkan
kompartemen yang berisi informasi seperti component yang dideploy di node tersebut.
Jalur komunikasi diantara node menunjukan bagaimana mereka berkomunikasi. Jalur
tersebut bisa ditambahkan label yang menginformasikan protocol komunikasi apa yang
dipakai
2013 12 Analisa Perancangan Berorientasi Objek Modul 08 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Daftar Pustaka
Alan Denis, Barbara Haley Wixon, David Tagerden, System Analys and Design : an Object –
Oriented Approach with UML 2.0, John Willey and Sons, 2005
Henry C. Lucas Jr., The Analysis, Design and Implementation of Information Systems 4th,
McGraw Hill, 1992
Satzinger, Jackson, Burd, Object-Oriented Analysis and Design with the Unified Process,
Course Technology, 2005
Simon Bennet, Steve McRobb and Ray Farmer, Object-Oriented System Analysis and
Design Using UML, McGraw Hill, 2006
Wendy and Michael Boggs, UML with Rational Rose 2002, Sibex Inc., 2002
MODUL PERKULIAHAN
ANALISA
PERANCANGAN BERORIENTASI OBJEK
Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana
Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh
Ilmu Komputer Teknik Informatika
09 87016 Tim Dosen
Abstract Kompetensi
Memahami kebutuhan sistem Menentukan kebutuhan teknik dan menganalisa kebutuhan
2013 2 Analisa Perancangan Berorientasi Objek Modul 09 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Penggunaan Notasi UML
Modul ini akan membahas contoh penggunaan notasi-notasi UML didalam kasus
operasional perusahaan yang memerlukan data dan informasi yang cukup bagi pihak
perusahaan sebagai dasar pengambilan keputusan strategis dan operasional dalam
rangka memenangkan persaingan dan untuk meningkatkan omzet pendapatan perusahaan
tersebut.
Pada bab tiga ini diuraikan tentang tahap pengembangan sistem diantaranya adalah
pemodelan bisnis, analisis, perancangan, pengujian dan implementasi sistem, sistem
pengiriman (delivery) pada PT X
Bahan dan Alat
Bahan penelitian yang digunakan adalah data paket atau dokumen yang akan dikirim, data
pengirim dan alamat tujuan barang akan dikirim serta bukti atau nota pengiriman. Peralatan
diperlukan untuk mendukung penelitian dan mengoperasikan aplikasi antaralain digolongkan
menjadi :
Perangkat Keras.
Perangkat keras adalah seperangkat alat atau komponen yang akan digunakan untuk
membentuk suatu sistem komputer :
1. CPU (Central Processing Unit).
CPU merupakan pusat pengolahan dan juga pusat pengontrolan dari
sebuah sistem komputer yang saling melaksanakan kegiatan.
2. Floppy Disk.
Floppy Disk adalah alat penggerak untuk membaca atau untuk merekam
data dari atau ke media penyimpanan disket.
3. Harddisk.
Hard Disk adalah media penyimpanan data yang terbuat dari piringan
keras yang dilapisi dengan zat magnetik. Harddisk dapat menyimpan
data lebih banyak dan mempunyai kecepatan yang tinggi dalam
pengambilan dan penyimpanan data.
4. Keyboard.
Keyboard adalah alat input yang biasanya didampingi dengan alat
tampilan (display) di layar yang menampilkan apa yang ditekan di
keyboard.
2013 3 Analisa Perancangan Berorientasi Objek Modul 09 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
5. Video Display Unit (VDU)
VDU adalah alat yang digunakan untuk komunikasi interaktif antara
manusia dengan komputer yang berupa tampilan visual.
6. Mouse
Mouse adalah alat input komputer yang digunakan oleh berbagai
program aplikasi GUI ( Graphcal User Interface ) dengan petunjuk posisi
yang ditampilkan melalui monitor.
7. Printer
Printer adalah alat yang digunakan untuk mencetak keluaran baik berupa
tulisan, grafik atau gambar pada media kertas.
Perangkat Lunak
Perangkat lunak merupakan bagian dari suatu sistem pengolahan data yang digunakan
untuk mengaktifkan fungsi dari perangkat keras komputer. Perangkat lunak yang dibutuhkan
pada sistem usulan adalah sebagai berikut :
1. Sistem Operasi
Sistem operasi yang disarankan minimal Windows 98.
2. Program Aplikasi.
Merupakan perangkat lunak yang akan digunakan dalam pembuatan
program sistem usulan diantaranya adalah aplikasi databases MySQL,
aplikasi Java jdk-1_5_0_02-windows-i586-p.exe dan aplikasi
penghubung (connection) antara aplikasi database dan aplikasi compiler
java yaitu mysql-connector-java-5.0.3-bin.jar.
Kasus menggunakan pendekatan pemodelan bisnis dan objek, model ini berkosentrasi pada
lingkup bisnis di perusahaan yang akan kita rancang sistemnya. Terlebih dahulu kita harus
melakukan pemeriksaan-pemeriksaan pada bisnis itu sendiri: entitas-entitas yang
berinteraksi dengan bisnis serta aliran-aliran kerja dalamnya. Metode pengembangan sistem
penulis menggunakan metodologi Berorientasi Objek dan menggunakan perkakas utama
dalam analisis dan perancangannya menggunakan notasi Unified Modeling Language
(UML).
Pemodelan Bisnis
Pengembangan sistem/perangkat lunak bisnis menuntut kita melakukan pemodelan bisnis
yang berkosentrasi pada lingkup bisnis diperusahaan yang akan kita rancang sistemnya.
Terlebih dahulu kita harus melakukan pemeriksaan-pemeriksaan pada bisnis itu sendiri:
2013 4 Analisa Perancangan Berorientasi Objek Modul 09 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
entits-entitas yang berinteraksi dengan bisnis serta aliran-aliran kerja di dalamnya. Sangat
penting untuk memahami bisnis itu sendiri. Kita seharusnya melakukan penelahan sistem
secara seksama dengan cara melakukan pencarian data dengan pihak yang terlibat serta
ditambah dengan melakukan studi-studi literature.
Fungsi Pemodelan Bisnis
Pemodelan bisnis adalah studi tentang organisasi/perusahaan. Selama proses pemodelan
bisnis, kita melakukan pemeriksaan struktur organisasi/perusahaan dan mencari peran-
peran penting dalam organisasi/perusahaan dan bagaimana mereka saling berhubungan.
Ada beberapa alasan untuk melakukan pemodelan bisnis. Alasan utama adalah untuk
memahami organisasi, sistem yang saat ini bekerja di organisasi yang bersangkutan, serta
perangakat lunak yang saat ini dimilikinya. Tahapan yang terdapat pada tahap ini antara lain
terdiri dari beberapa penentuaan kosep-konsep dasar pemodelan bisnis.
Identifikasi Aktor Bisnis
Sesungguhnya, sebelum kita memulai segala sesuatunya menyangkut pengembangan
sistem/perangkat lunak, pertama kali kita harus menentukan aktor-aktor bisnis, kita
seharusnya melihat pada lingkup proyek dimana sistem kita akan dikembangkan serta
berusaha menentukan apa yang ada diluar linkup-lingkup proyek kita. Dalam hal ini penulis
mendefiniskan bahwa yang dapat menjadi sebagai aktor bisnis adalah pelanggan (pengirim)
yang menggunakan jasa pengiriman tersebut. Dalam UML, aktor bisnis digambarkan
sebagai berikut :
Gambar 1 Pelanggan (Pengirim)
Identifikasi Pekerja Bisnis
Untuk mengidentifikasi pekerja-pekerja Bisnis, sekali lagi kita harus melihat pada lingkup
proyek kita. Jika kita berusaha memodelkan bisnis secara terbatas, suatu diagram struktur
organisasi mungkin merupakan suatu awal untuk memulai. Pertimbangan setiap peran
dalam struktur organisasi itu alih-alih posisinya. Pertimbangkan bahwa seseorang mungkin
memiliki peran-peran yang berbeda dalam bisnis tersebut. Dalam hal ini penulis
mendefiniskan bahwa yang dapat menjadi model pekerja bisnis antara lain : petugas entri,
dan kurir (pengantar barang). Dalam UML, pekerja bisnis digambarkan sebagai berikut :
2013 5 Analisa Perancangan Berorientasi Objek Modul 09 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Gambar 2. Petugas entry Gambar 3. Kurir (pengantar
barang)
Identifikasi Use Case Bisnis
Untuk mengidentifikasi use case bisnis, kita bias memulainya dari pernyataan visi dan misi
organisasi, yang merupakan peringkat tertinggi dari sasaran bisnis dalam menciptakan nilai-
nilai tertentu bagi lingkungannya. Misalnya dalam perusahan yang menjadi tempat riset bagi
penulis, perusahaan tersebut bergerak dibidang pengiriman barang. kita kemudian berusaha
memikirkan apa yang dibutuhkan dalam upaya perusahaan itu mengantarkan barang
ketujuan. Pertama kali, perusahaan tersebut harus memiliki mekanisme yang
memungkinkan pengirim untuk melakukan transaksi, mekanisme selanjutnya adalah
pembuatan nota pembayaran. Kemudian mekanisme selanjutnya adalah pengiriman
panagantaran barang yang akan dikirim, setelah itu barang yang telah di kirim dilakukan
verifikasi lebih lanjut. Dari apa yang kita definsikan dari problem yang terdapat pada
perusahaan, kita mungkin dapat menemukan beberapa use case bisnis, yaitu : transasksi,
pembayaran, pengiriman dan verifikasi.
Diagram Use Case Bisnis
Setelah kita dapat menentukan aktor-aktor bisnis, pekerja-pekerja bisnis, serta use case
bisnis, maka langkah selanjutnya adalah menggambarkan diagram use case bisnis yang
memperlihatkan interaksi-interaksi yang terjadi di antara mereka. Suatu tanda panah yang
berarah dari pekerja bisnis ke use case bisnis mengambarkan bahwa pekerja bisnis
memulai proses tertentu yang dilakukan dengan use case. UML, pekerja bisnis digambarkan
sebagai berikut :
2013 6 Analisa Perancangan Berorientasi Objek Modul 09 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Gambar 3.4. Diagram use case bisnis
Analisis
Definisi analisis sistem menurut DeMarco [De Marco, 1978], “ The study of a problem, prior
to taking some action”. Analisis sistem adalah mempelajari suatu masalah dan mempunyai
tujuan utama untuk melakukan tindakan. Analisis sistem merupakan proses menentukan
kebutuhan sistem – apa yang harus silakukan sistem untuk memenuhi kebutuhan klien,
bukanlah bagaimana sistem tersebut diimplementasikan.
Identifikasi Masalah
Sebuah perusahaan yang bergerak dibidang pengiriman barang, memberikan sebuah
pelayanan jasa berupa jasa pengiriman barang berupa dokumen dan paket. Didalam
proses bisnisnya, dimulai saat seorang pelanggan (pengirim) melakukan pengiriman sebuah
dokumen atau paket keperusahaan tersebut. Oleh petugas yang bertugas memasukan
(entry) data, transaksi itu dicatatat. Dengan ketentuaan yang telah ditetapkan sebelumnya
data-data dicatat dan disimpan sesuai keterangan dan informasi yang didapat.
Kemudian petugas melakukan perhitungan pembayaran, saat pembayaran dilakukan
petugas akan memproses apakah tagihan langsung dibuat atau akan ditagihkan pada suatu
periode tertentu. Dengan ketentuan sebelumnya bahwa pelanggan yang sudah menjadi
member, proses pembayarannya dapat dilakukan dengan membuat nota tagihan untuk
pembayaran suatu periode tertentu, data yang terdapat pada tagihan tersebut merupakan
kumpulan dari beberapa transaksi yang dilakukan dalam satu periode.
2013 7 Analisa Perancangan Berorientasi Objek Modul 09 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Setelah selesai melakukan proses transaksi tersebut, document atau paket tersebut mulai
dilakukan proses pengiriman ketujuan. Dokumen atau paket tersebut akan dikirim ketujuan
sesuai dengan keterangan informasi yang terdapat pada nota transaksi.
Untuk memberikan pelayanan lebih kepada pelanggan, pelanggan diperbolehkan
melakukan klaim bila didapatkan suatu problem yang menyangkut tentang proses
pengiriman dokumen atau paket yang dikirimkan. Proses klaim dapat dilakukan dan dapat
dikatakan sah apabila transaksi tersebut belum dibuat tagihan dan memenuhi beberapa
kententuan atau perjanjian yang telah disepakati sebelumnya.
Diagram Konteks
Gambar 3.5. Diagram konteks
Identifikasi Use Case dan Aktor
Pada bagian ini kita mulai melakukan proses pencarian atau penentuan beberapa
kebutuhan dasar didalam membentuk use case. Aktor dan use case ditentukan atas dasar
kenutuhan fungsi-fungsi. Kebutuhan fungsi ini diakomodir di use case. Selanjutnya use case
menyediakan nilai hasil kepada aktor. Atas dasar spesifikasi diatas paling tidak kita dapat
menemukan aktor.
Use case, seperti kita ketahui sebelumnya, mencakup aliran-aliran kerja (workflow) dalam
sistem (bersifat internal) sedangkan aktor-aktor mencakup segala sesuatu yang ada diluar
sistem (bersifat eksternal). Tentu saja ada perbedaan antara use case dan aktor yang
sedang kita bahas saat ini dengan use case bisnis dan aktor bisnis (juga pekerja bisnis)
yang telah kita bahas sebelumnya. Perbedaan-perbedaan itu akan kita bahas sekilas pada
tabel di bawah ini (Tabel 3.1).
2013 8 Analisa Perancangan Berorientasi Objek Modul 09 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Table 1 Perbedaan objek-objek dalam model bisnis dan model sistem.
Nama Objek Model Bisnis Model Sistem
Use Case Mendeskripsikan apa
yang dikerjakan
perusahaan.
Mendeskripsikan sistem
yang akan/sedang
dikembangkan dalam
perusahaan.
Aktor Bersifat eksternal
terhadap perusaan
Bersifat eksternal terhadap
sistem yang akan/sedang
dikembangkan
Pekerja Bisnis Bersifat internal dalam
perusahaan
Tidak digunakan
Untuk mendeskripsikan use case apa saja dan aktor yang akan terlibat dalam use case
tersebut, biasanya digunakan tabel seperti tabel 3.1 Untuk itu bisa dilihat kembali spesifikasi
sistem diatas.
Tabel 2 Requirement aktor dan use case
No Requirement Aktor Use Case
1 Operator Data Entry melakukan
verifikasi user untuk menggunakan
sistem
Operator Data
Entry
Proses Login
(verifikasi user)
2 Operator Data Entry melakukan input
proses transaksi pengiriman yang
berisi data pengirim dan tujuan
penerima
Operator Data
Entry
Transaksi
pengiriman,
Input Data
Pengirim, Input
Data Penerima
3. Sesudah data dan informasi dengan
benar maka operator data entry
membuat nota pembayaran dari suatu
transaksi terebut
Operator Data
Entry
Pembayaran,
Tagihan
4 Dengan sudah masuknya semua data
ke database computer, proses
selanjutnya adalah membuat laporan
berkala yang diperlukan untuk
keperluan-keperluan lain yang
berhubungan dengan proses yang
Operator Data
Entry
Buat Laporan,
Laporan Data
Pengirim ,
Laporan Data
Penerima,
Laporan Data
2013 9 Analisa Perancangan Berorientasi Objek Modul 09 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
berlangsung di perusahaan tersebut. Transaksi,
Laporan Data
Tagihan
5. Untuk melakukan tugas lainnya maka
diperlukan pegawai lainnnya, oleh
karena itu diperluka pendataan
pegawai dengan benar.
Data Pegawai
Selanjutnya atas dasar tabel diatas dibuat use case diagram. Sebagai catatan
bahwa suatu proses penambahan data pengirim dan peneriman dapat dilakukan
secara langsung pada form data pengirim atau form data penerima, selain itu dapat
dilakukan pada saat proses transaksi terjadi. Untuk keterangan dan penjelasan lebih
lengkap dapat dilihat pada gambar diagram use case berikut ini :
Gambar 6 Diagram use case diagram
&&&&&&&&&
2013 10 Analisa Perancangan Berorientasi Objek Modul 09 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Daftar Pustaka
Alan Denis, Barbara Haley Wixon, David Tagerden, System Analys and Design : an Object –
Oriented Approach with UML 2.0, John Willey and Sons, 2005
Henry C. Lucas Jr., The Analysis, Design and Implementation of Information Systems 4th,
McGraw Hill, 1992
Satzinger, Jackson, Burd, Object-Oriented Analysis and Design with the Unified Process,
Course Technology, 2005
Simon Bennet, Steve McRobb and Ray Farmer, Object-Oriented System Analysis and
Design Using UML, McGraw Hill, 2006
Wendy and Michael Boggs, UML with Rational Rose 2002, Sibex Inc., 2002
MODUL PERKULIAHAN
ANALISA
PERANCANGAN BERORIENTASI OBJEK
Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana
Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh
Ilmu Komputer Teknik Informatika
10 87016 Tim Dosen
Abstract Kompetensi
Memahami kebutuhan sistem Menentukan kebutuhan teknik dan menganalisa kebutuhan
2013 2 Analisa Perancangan Berorientasi Objek Modul 10 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Diskripsi Use Case Setiap use case di atas harus dideskripsikan dalam dokumen yang disebut dengan dokumen
flow of event. Dokumentasi ini mendefisikan apa yang harus dilakukan oleh sistem ketika
aktor mengaktipkan use case. Struktur dari dokumen use case ini bisa bermacam-macam,
tetapi umumnya deskripsi ini paling tidak harus mengandung : (sumber Quantrani, 2000).
Brief Description (deskripsi singkat).
Aktor yang terlibat.
Precondition yang penting bagi use case untuk memulai.
Deskripsi rinci dari aliran kejadian yang mencakup :
Main Flow dari kejadian yang bisa dirinci lagi menjadi
SubFlow dari kejadian (Sub flow bisa di bagi lagi lebih jauh menjadi
sub flow yang lebih kecil agar dokumen lebih mudah dibaca dan
dimengerti).
Alternative Flow untuk mendefinisikan situasi perkecualian
Postcondition yang menjelaskan state dari sistem setelah use case
berakhir.
Selain hal diatas kita juga boleh memakai beberapa deskripsi tambahan untuk
melengkapi pendeskripsian use case yang kita buat. Setelah pembuatan use case pada
sub bab sebelumnya kini kita akan menjelaskan spesifikasi use case yang telah kita
tentukan.
Tabel 3 Spesifikasi naratif untuk use case login tingkat analisis
Use case name Login
Aktor Operator Data Entry
Brief
Description
Use case ini merupakan awal dari semua kegiatan
yang terjadi. Operator Data Entry ingin Login
terhadap sistem dengan menginputkan data user
name dan password, maka sistem akan memvalidasi
user name dan password tersebut.
Exception Jika dalam verifikasi user tidak ditemukan berati
tidak berhak untuk menggunakan sistem.
2013 3 Analisa Perancangan Berorientasi Objek Modul 10 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Basic Flow Operator Data Entry meninputkan User
name.
Operator Data Entry menginputkan
Password
Sistem memvalidasi User name dan
Password tersebut.
Sistem akan merespon dari proses tersebut
untuk memberikan keterangan
Alternatif flow Jika dalam menginputkan User name dan Password
tidak sesuai maka user harus mengisi kembali
Pre condition Operator Data Entry harus mengetahui User name
dan Password
Post condition Akan masuk ke dalam sistem
Tabel 4 Spesifikasi naratif untuk use case transaksi pengiriman tingkat analisis
Use case name Transaksi Pengiriman
Aktor Operator Data Entry
Brief
Description
Use case ini merupakan tempat untuk melakukan
transaksi. Transaksi terjadi saat pelanggan ingin
melakukan pengiriman dokumen atau paket
menggunakan jasa perusahaan tersebut.
Exception Data pengiriman yang akan dimasukan sudah
tersedia dan sudah sesuai dengan ketentuan.
Basic Flow 1. Pengirim ingin melakukan pengiriman
dokumen atau paket.
2. Operator Data Entry mulai melakukan input
data yang dibutuhkan sebagai bahan
informasi berikutnya.
3. Sistem akan memproses data yang telah
diinputkan sesuai dengan ketentuan yang
berlaku.
4. Setelah itu data yang telah di inputkan akan
disimpan untuk menjadi sumber informasi
2013 4 Analisa Perancangan Berorientasi Objek Modul 10 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
yang dibutuhkan untuk proses nantinya.
Alternatif flow Jika data yang dibutuhkan tidak sesuai atau kurang
lengkap maka perlu dilakukan verifikasi lebih lanjut
kepada pengirim.
Pre condition 1. Operator data entry harus login terlebih
dahulu.
2. Data yang diperlukan sudah tersedia dan
sesuai.
Post condition Data transaksi telah tersimpan
Tabel 5 Spesifikasi naratif untuk use case input data pengirim tingkat analisis
Use case name Input Data Pengirim
Aktor Operator Data Entry
Brief
Description
Walaupun sebenarnya data pengirim secara tidak
langsung telah diimputkan dan disimpan saat
melakukan transaksi. Tetapi untuk mendapatkan
keterangan yang lebih terperinci data pengirim
maka diperlukan use case ini. Use case ini
merupakan tempat untuk melakukan penambahan
atau mengedit data pengirim.
Exception Data pengirim yang akan dimasukan sudah tersedia
dan sudah sesuai dengan ketentuan.
Basic Flow 1. Operator data entry dapat menambahkan
atau mengedit data yang telah tersimpan
untuk menambahkan rincian informasi .
2. Operator data entry mulai melakukan input
data yang dibutuhkan sebagai bahan
informasi berikutnya.
3. Sistem akan memproses data yang telah
diinputkan sesuai dengan ketentuan yang
berlaku.
4. Setelah itu data yang telah di inputkan akan
disimpan untuk menjadi sumber informasi
2013 5 Analisa Perancangan Berorientasi Objek Modul 10 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
yang dibutuhkan untuk proses nantinya.
Alternatif flow Jika data pengirim sebelumnya sudah ada maka
sistem akan otomastis akan menampilkan data
tersebut, akan tetapi bila tidak maka operator data
entry harus mengimputkan data baru tersebut.
Pre condition 3. Operator data entry harus login terlebih
dahulu.
4. Data yang diperlukan sudah tersedia dan
sesuai.
Post condition Data Pengirim telah tersimpan
Tabel 6 Spesifikasi naratif untuk use case input data penerima tingkat analisis
Use case name Input Data Penerima
Aktor Operator Data Entry
Brief
Description
Walaupun sebenarnya data penerima secara tidak
langsung telah diimputkan dan disimpan saat
melakukan transaksi. Tetapi untuk mendapatkan
keterangan yang lebih terperinci data penerima
maka diperlukan use case ini. Use case ini
merupakan tempat untuk melakukan penambahan
atau mengedit data penerima.
Exception Data karyawan yang akan dimasukan berisi biodata
para pegawai yang bekerja di perusahaan tersebut.
Basic Flow 1. Operator data entry dapat menambahkan
atau mengedit biodata karyawan yang
bekerja di peerusahaan .
2. Operator data entry mulai melakukan input
data yang dibutuhkan sebagai bahan
informasi berikutnya.
3. Sistem akan memproses data yang telah
diinputkan sesuai dengan ketentuan yang
berlaku.
4. Setelah itu data yang telah di inputkan akan
2013 6 Analisa Perancangan Berorientasi Objek Modul 10 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
disimpan untuk menjadi sumber informasi
yang dibutuhkan untuk proses nantinya.
Alternatif flow Jika data penerima sebelumnya sudah ada maka
sistem akan otomastis akan menampilkan data
tersebut, akan tetapi bila tidak maka operator data
entry harus mengimputkan data baru tersebut.
Pre condition 5. Operator data entry harus login terlebih
dahulu.
6. Data yang diperlukan sudah tersedia dan
sesuai.
Post condition Data Penerima telah tersimpan
Tabel 7 Spesifikasi naratif untuk use case input data karyawan tingkat analisis
Use case name Input Data Karyawan
Aktor Operator Data Entry
Brief
Description
Use case ini memungkin operator data entri untuk
melakukan entry data karyawan yang bekerja di
perusahaan tersebut
Exception Data karyawan yang akan dimasukan sudah tersedia
dan sudah sesuai dengan ketentuan.
Basic Flow 1. Operator data entry dapat menambahkan
atau mengedit data yang telah tersimpan
untuk menambahkan rincian informasi .
2. Operator data entry mulai melakukan input
data yang dibutuhkan sebagai bahan
informasi berikutnya.
3. Sistem akan memproses data yang telah
diinputkan sesuai dengan ketentuan yang
berlaku.
4. Setelah itu data yang telah di inputkan akan
disimpan untuk menjadi sumber informasi
yang dibutuhkan untuk proses nantinya.
Alternatif flow Jika data pegawai sebelumnya sudah ada maka
2013 7 Analisa Perancangan Berorientasi Objek Modul 10 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
sistem akan otomastis akan menampilkan data
tersebut, akan tetapi bila tidak maka operator data
entry harus mengimputkan data baru tersebut.
Pre condition 7. Operator data entry harus login terlebih
dahulu.
8. Data yang diperlukan sudah tersedia dan
sesuai.
Post condition Data karyawan telah tersimpan
Tabel 8 Spesifikasi naratif untuk use case proses tagihan tingkat analisis
Use case name Proses Tagihan
Aktor Operator Data Entry
Brief
Description
Use case ini memungkin operator data entri untuk
melakukan proses pembayaran dari suatu transaksi
yang berlangsung atau dibuatkan tagihan untuk
beberapa transaksi dalam satu periode.
Exception Data transaksi yang dilakukan sudah terjadi.
Basic Flow 1. Proses pembayaran atas transaksi yang
dilakukan diproses secara berkala (per
periode) atau secara langsung .
2. Operator data entry mulai melakukan input
data yang dibutuhkan sebagai bahan
pemrosesan tagihan.
3. Sistem akan meminta kepada operator data
entry untuk memasukan ketentuan atau
parameter yang akan menjadi batasan untuk
memproses data.
4. Sistem akan memproses data yang telah
diinputkan sesuai dengan ketentuan yang
berlaku.
5. Setelah itu data yang telah di inputkan akan
disimpan untuk menjadi sumber informasi
yang dibutuhkan untuk proses nantinya.
2013 8 Analisa Perancangan Berorientasi Objek Modul 10 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Alternatif flow Jika penerima tersebut merupakan member maka
proses pembayaran akan dibuat tagihan untuk satu
periode, dan bila bukan maka pembayaran dapat
langsung dilakukan.
Pre condition 9. Operator data entry harus login terlebih
dahulu.
10. Data yang diperlukan sudah tersedia dan
sesuai.
Post condition Data Tagihan telah tersimpan
Tabel 9 Spesifikasi naratif untuk use case laporan data transaksi tingkat analisis
Use case name Laporan Data Transaksi
Aktor Operator Data Entry
Brief
Description
Use case ini memungkin operator data entri untuk
melakukan pembuatan laporan, data yang didapat
dari proses transaksi yang terjadi.
Exception Data transaksi yang akan dimasukan sudah tersedia
dan sudah sesuai dengan ketentuan.
Basic Flow 1. Proses pembuatan laporan dilakukan
bertujuan untuk mengetahui seberapa
banyak proses terjadinya transaksi dan
pendapatan yang di hasilkan
2. Operator data entry mulai melakukan input
data yang dibutuhkan sebagai bahan
pemrosesan pembuatan laporan
3. Sistem akan meminta kepada operator data
entry untuk memasukan ketentuan atau
parameter yang akan menjadi batasan untuk
memproses data.
4. Sistem akan memproses data yang telah
diinputkan sesuai dengan ketentuan yang
berlaku.
5. Setelah itu data yang telah di inputkan akan
2013 9 Analisa Perancangan Berorientasi Objek Modul 10 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
disimpan untuk menjadi sumber informasi
yang dibutuhkan untuk proses nantinya.
Alternatif flow Jika data pada saat memasukan data parameter tak
sesuai, maka proses harus diulang .
Pre condition 11. Operator data entry harus login terlebih
dahulu.
12. Data yang diperlukan sudah tersedia dan
sesuai.
Post condition Data Laporan telah tersimpan
Tabel 10 Spesifikasi naratif untuk use case laporan data tagihan tingkat analisis
Use case name Laporan Data Tagihan
Aktor Operator Data Entry
Brief
Description
Use case ini memungkin operator data entri untuk
melakukan pembuatan laporan, data yang didapat
dari proses transaksi yang telah terjadi. Kemudian
data tersebut akan dibuat sebuah tagihan secara
berkala
Exception Data tagihan didapat dari data transaksi yang akan
dimasukan sudah tersedia dan sudah sesuai dengan
ketentuan.
Basic Flow 1. Proses pembuatan laporan tagihan
dilakukan bertujuan untuk mengetahui
seberapa banyak tagihan yang didapat dari
beberapa transaksi dalam satu periode
tertentu.
2. Operator data entry mulai melakukan input
data yang dibutuhkan sebagai bahan
pemrosesan pembuatan laporan
3. Sistem akan meminta kepada operator data
entry untuk memasukan ketentuan atau
parameter yang akan menjadi batasan untuk
memproses data.
2013 10 Analisa Perancangan Berorientasi Objek Modul 10 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
4. Sistem akan memproses data yang telah
diinputkan sesuai dengan ketentuan yang
berlaku.
5. Setelah itu data yang telah di inputkan akan
disimpan untuk menjadi sumber informasi
yang dibutuhkan untuk proses nantinya.
Alternatif flow Jika data pada saat memasukan data parameter tak
sesuai, maka proses harus diulang .
Pre condition 13. Operator data entry harus login terlebih
dahulu.
14. Data yang diperlukan sudah tersedia dan
sesuai.
Post condition Data Laporan Tagihan telah siap cetak
Tabel 11 Spesifikasi naratif untuk use case laporan data pengirim tingkat analisis
Use case name Laporan Data Pengirim
Aktor Operator Data Entry
Brief
Description
Use case ini memungkin operator data entri untuk
melakukan pembuatan laporan data pengirim, data
yang didapat dari proses transaksi yang telah terjadi
atau secara langsung hasil inputan. Kemudian data
dapat dibuat laporannya untuk mengetahui data
yang telah diimputkan dan tersimpan di dalam
database.
Exception Data laporan didapat dari data transaksi yang akan
dimasukan sudah tersedia dan sudah sesuai dengan
ketentuan atau dimputkan secara langsung pada
sistem.
Basic Flow 1. Proses pembuatan laporan pengirim
dilakukan bertujuan untuk mengetahui
seberapa banyak data pengirim yang telah
tesimpan didalam sistem tersebut
2. Operator data entry mulai melakukan input
2013 11 Analisa Perancangan Berorientasi Objek Modul 10 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
data yang dibutuhkan sebagai bahan
pemrosesan pembuatan laporan
3. Sistem akan meminta kepada operator data
entry untuk memasukan ketentuan atau
parameter yang akan menjadi batasan untuk
memproses data.
4. Sistem akan memproses data yang telah
diinputkan sesuai dengan ketentuan yang
berlaku.
5. Setelah itu data yang telah di inputkan akan
disimpan untuk menjadi sumber informasi
yang dibutuhkan untuk proses nantinya.
Alternatif flow Jika data pada saat memasukan data parameter tak
sesuai, maka proses harus diulang .
Pre condition 15. Operator data entry harus login terlebih
dahulu.
16. Data yang diperlukan sudah tersedia dan
sesuai.
Post condition Data Laporan pengirim siap cetak
Tabel 12 Spesifikasi naratif untuk use case laporan data penerima tingkat analisis
Use case name Laporan Data Penerima
Aktor Operator Data Entry
Brief
Description
Use case ini memungkin operator data entri untuk
melakukan pembuatan laporan data penerima, data
yang didapat dari proses transaksi yang telah terjadi
atau secara langsung hasil inputan. Kemudian data
dapat dibuat laporannya untuk mengetahui data
yang telah diimputkan dan tersimpan di dalam
database.
Exception Data laporan didapat dari data transaksi yang akan
dimasukan sudah tersedia dan sudah sesuai dengan
ketentuan atau dimputkan secara langsung pada
2013 12 Analisa Perancangan Berorientasi Objek Modul 10 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
sistem.
Basic Flow Proses pembuatan laporan penerima dilakukan
bertujuan untuk mengetahui seberapa banyak data
pengirim yang telah tesimpan didalam sistem
tersebut
Operator data entry mulai melakukan input data
yang dibutuhkan sebagai bahan pemrosesan
pembuatan laporan
Sistem akan meminta kepada operator data entry
untuk memasukan ketentuan atau parameter yang
akan menjadi batasan untuk memproses data.
Sistem akan memproses data yang telah diinputkan
sesuai dengan ketentuan yang berlaku.
Setelah itu data yang telah di inputkan akan
disimpan untuk menjadi sumber informasi yang
dibutuhkan untuk proses nantinya.
Alternatif flow Jika data pada saat memasukan data parameter tak
sesuai, maka proses harus diulang .
Pre condition 17. Operator data entry harus login terlebih
dahulu.
18. Data yang diperlukan sudah tersedia dan
sesuai.
Post condition Data laporan penerima siap cetak
Identifikasi Kelas pada Use Case
Meskipun dalam pembahasan ini pemodelan class dilakukan setelah pemodelan use case,
sebenarnya pada faktanya kedua aktivitas tersebut dilakukan secara parale. Kedua model
tersebut sebenarnya saling mendukung dalam pemberian informasi. Use case memfasilitasi
dalam hal penggalian class dan sebaliknya pemodelan class dapat membantu menemukan use
case yang terlupakan.
Class biasanya digunakan untuk mendefinisikan objek-objek bisnis. Class-class seperti ini
biasanya mendefinisikan model database dari suatu aplikasi. Atas dasar itulah class seperti ini
2013 13 Analisa Perancangan Berorientasi Objek Modul 10 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
sering disebut dengan class entity karena mewakili objek database.
Class entity ini menjelaskan esensi Teknik Informatika apapun. Biasanya analisis kebutuhan
digunakan untuk menemukan class entity ini. Akan tetapi, untuk bisa menjalankan sistem
secara benar, sistem membutuhkan class-class yang mendefinisikan objek-objek GUI (seperti
form layer) yang disebut dengan class boundary. Sistem juga membutuhkan class-class yang
mengontrol logika program yang disebut dengan class control. Namun biasanya pemodelan
kedua class yang terakhir ini dilakukan saat memasuki fase perancangan, bukan fase analisis.
Tabel berikut menjelaskan cara pencarian kandidat class entity pada Aplikasi Pengiriman
Barang pada PT. X
Tabel 13 Kandidat class entity pada aplikasi pengiriman barang pada PT. X
No Requirement Class Entity
1. Operator Data Entry ingin Login terhadap sistem
dengan menginputkan data user name dan
password, maka sistem akan memvalidasi user
name dan password tersebut
Operator Data Entry
(Data User).
2. Transaksi terjadi saat pelanggan ingin melakukan
pengiriman dokumen atau paket menggunakan jasa
perusahaan tersebut kebeberapa kota tujuan dengan
berbagai bentuk pilihan jenis dan sifat pengiriman.
Transaksi, Jenis
Pengiriman dan Sifat
Pengiriman
3. Saat melakukan transaksi tentu saja dibutuhan
beberapa data, untuk itu diperlukan data pengirim
dan data penerima. Sehingga barang yang dikirim
terdapat keterangan siapa pengirimnya dan
keterangan penerimanya
Data Pengirim, Data
Penerima
4. Setelah proses memasukan data yang dibutuhkan
saat transaksi tersebut, maka akan diproses
pembayaran yang berlangsung saat itu apakah
secara tunai atau dibuat tagihan.
Pembayaran
5. Pada saat proses pembayaran yang dilakukan tidak
secara langsung (dibuatkan tagihan) bila pelanggan
tersebut sudah menjadi member dari perusahaan
tersebut. Tagihan akan ditagihkan menurut
periodenya dan berisi data trasaksi selama periode
Tagihan
2013 14 Analisa Perancangan Berorientasi Objek Modul 10 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
tersebut
Langkah selanjutnya adalah membuat class diagram. Dengan mengacu pada ilustrasi tabel
diatas maka kita bisa melakukan pemodelan diagram class tersebut.
Gambar 7 Class Diagram
2013 15 Analisa Perancangan Berorientasi Objek Modul 10 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Daftar Pustaka
Alan Denis, Barbara Haley Wixon, David Tagerden, System Analys and Design : an Object –
Oriented Approach with UML 2.0, John Willey and Sons, 2005
Henry C. Lucas Jr., The Analysis, Design and Implementation of Information Systems 4th,
McGraw Hill, 1992
Satzinger, Jackson, Burd, Object-Oriented Analysis and Design with the Unified Process,
Course Technology, 2005
Simon Bennet, Steve McRobb and Ray Farmer, Object-Oriented System Analysis and
Design Using UML, McGraw Hill, 2006
Wendy and Michael Boggs, UML with Rational Rose 2002, Sibex Inc., 2002
MODUL PERKULIAHAN
ANALISA
PERANCANGAN BERORIENTASI OBJEK
Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana
Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh
Ilmu Komputer Teknik Informatika
11 87016 Tim Dosen
Abstract Kompetensi
Memahami kebutuhan sistem Menentukan kebutuhan teknik dan menganalisa kebutuhan
2013 2 Analisa Perancangan Berorientasi Objek Modul 11 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Perancangan Sistem Setelah membahas analisis sistem, maka tiba saatnya untuk membahas desain (perancangan)
sistem. Pada perancangan aplikasi penulis akan menggunakan tool UML dengan membangun
diagram-diagram yang akan digunakan pada sistem. Pada perancangan ini penulis hanya
membangun beberapa diagram saja. Proses perancangan bertujuan untuk :
Menggambarkan secara detail komunikasi antar objek
Menentukan objek-objek pendukung lain selain objek-objek domain persoalan.
Menentukan pemilahan sistem.
Menentukan ciri objek secara detail.
Menetapkan penggunaan objek-objek pustaka yang telah tersedia.
Selain itu untuk mengembangkan model perancangan, kita harus mengidentifikasi dan
menyelidiki konsekuensi pada lingkungan implementasi akibat langkah-langkah
perancangan. Semua keputusan-keputusan strategis perancangan, misalnya bagaimana
DBMS akan digunakan, bagaimana komunikasi proses dan penaganan kesalahan (error
handler) akan dicapai, pustaka komponen apa yang akan digunakan ulang (reusable
component) harus dibuat. Kemudian, kita menggunakan keputusan-keputusan itu untuk
beradaptasi dengan lingkungan implementasi. Shlaer dan Mellor membuat pendefinisan yang
membedakan antara problem dan solusi, apa dan bagaimana atau analisa dan desain [Coad,
1991]. Desain berorientasi objek mempunyai tiga dasar ,yaitu :
1. Notasi. Notasi digunakan untuk memberikan gambaran tentang gagasan sistem
kepada anggota team yang lain dan pihak lain yagn memerlukan.
2. Strategi. Setiap proyek tidak harus dimulai dari awal seperti pada saat memikirkan
untuk memecahkan persoalan. Desain untuk problem domain yang biasa ditemui
dapat digunakan untuk pemecahan masala.
3. Kriteria yang baik. Evaluasi suatu desain dapat dilakukan secra obyektif dengan
melihat apakah diterima, ditolak atau direvisi.
Pada tahap perancangan objek, kita mendefinisikan bagaimana analisis berorientasi
aplikasi akan direalisasikan pada lingkungan implementasi. Jacobson(1992) (dikutip dari
buku Modern Database Management, tulisan Fred McFadden, dkk) menyebutkan 3 alasan
utama mengapa kita menggunakan pendekatan perancangan berorientasi objek. Alasan-alasan
itu adalah :
2013 3 Analisa Perancangan Berorientasi Objek Modul 11 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
1. Model analisis pada analisis dengan metoda terstruktur tidak cukup formal untuk
diimplementsikan secara langsung ke bahasa pemrogrman. Untuk
menterjemahkan ke kode computer, kita perlu melakukan langkah-langkah
penghalusan (refinement) dengan membuat keputusan-keputusan pada operasi
apa yang objek akan lakukan, bagaimana seharusnya komunikasi antara objek-
objek dalam suatu sistem dilakukan, pesan apa yang harus dilewatkan, dan apa
sebagainya.
2. Sistem nyata harus diadaptasi ke lingkungan dimana sistem kelak akan
diimplementasi. Dalam hal ini, perlu dilakukan modifikasi-modifikasi model
analisis ke beberapa faktor yang berbeda seperti kebutuhan kinerja, perangkat
keras target dan perangkat lunak sistem, DBMS (Database Management Sistem),
bahasa pemrograman yang akan digunakan, dan sebagainya.
3. Hasil analisis dapat divalidasi menggunakan perancangan berorientasi objek pada
tahap ini, kita daapat memverifikasi apakah hasil dari analisis sesuai untuk
membangun sistem dan kemudian, jika tidak sesuai, kita kembali secara iterative
ke tahap analisis, serta membuat perubahan yang perlu pada model analisis.
Untuk mengembangkan model perancangan, kita harus mengidentifikasi dan menyelidiki
konsekuensi pada lingkungan implementasi akibat langka-langkah perancangan. Semua
keputusan strategis perancangan, misalnya bagaimana DBMS akan digunakan, bagaiman
komunikasi proses dan penanganan kesalahan (error handler) akan dicapai, pustaka
komponen apa yang harus dibuat. Kemudian. Kita menggunakan keputusan-keputusan itu
untuk mendeskripsikan bagaimana objek-objek berinteraksi satu sama lain lewat suatu
sknario (use case) yang telah kita kembangkan sebelumnya.
Deskripsi Use Case Tingkat Perancangan
Tabel 1 Spesifikasi naratif untuk use case login tingkat perancangan
Use case name Login
Aktor Operator Data Entry
Brief
Description
Operator Data Entry ingin Login terhadap sistem
dengan menginputkan data user name dan
password, maka sistem akan memvalidasi user
name dan password tersebut.
2013 4 Analisa Perancangan Berorientasi Objek Modul 11 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Exception Jika salah dalam mengimputkan user dan password
maka sistem tidak akan menampilkan menu utama
(main form).
Basic Flow 1. Tampilkan Form Login
2. Operator Data Entry meninputkan User
name.
3. Operator Data Entry menginputkan
Password
4. Operator Data Entry mengirimkan User
name dan Password dengan memilih tombol
Login agar sistem memvalidasi User name
dan Password tersebut.
5. Sistem memvalidasi User name dan
Password tersebut.
6. Sistem menampilkan informasi, jika User
name dan Password yang diinputkan benar
maka sistem akan menampilkan Form menu
utama, tetapi jika salah maka sistem akan
menampilkan pesan error.
Alternatif flow Jika dalam menginputkan User name dan Password
salah maka sistem akan menampilkan pesan error
dan memintanya untuk mengisi kembali
Pre condition Operator Data Entry harus mengetahui User name
dan Password
Post condition Tampil form Menu Utama
Tabel 2 Spesifikasi naratif untuk use case transaksi pengiriman tingkat perancangan
Use case name Transaksi Pengiriman
Aktor Operator Data Entry
Brief
Description
Use case ini memungkinkan seseorang operator data
entry untuk melakukan transaksi pengiriman
dokument atau paket.
Exception Data untuk keterangan yang dibutuhkan untuk
2013 5 Analisa Perancangan Berorientasi Objek Modul 11 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
transaksi telah ditentukan.
Basic Flow 1. Operator Data Entry menampilkan data
transaksi dengan memilih menu proses
Transaksi
2. Sistem secara otomatis akan menampilkan
form tesebut yang berisi data nomor
transaksi .
3. Operator Data Entry menginputkan data-data
pada space yang telah ditentukan dengan
benar.
4. Sistem akan mengontrol setiap entri yang
masuk apakah sesuai dengan ketentuan.
5. Bila semua data yang dimasukan telah benar
maka Operator Data Entry dapat menyimpan
data tersebut dengan menekan tombol save.
6. Sistem akan menyimpan data transaksi
tersebut.
Alternatif flow Jika dalam pengisian data transaksi tidak lengkap
maka sistem akan menampilkan pesan kesalahan
dan meminta kepada Operator Data Entri untuk
mengisi informasi yang dibuthkan terlebih dahulu.
Operator Data Entry bisa memilih Reset(atau nama
lain yang sejenis) untuk mengosongkan form
transaksi.
Pre condition Operator Data Entry harus login terlebih dahulu.
Data transaksi yang akan dimasukan sudah tersedia
dan sesuai.
Post condition Jika use case sukses dijalankan, maka data akan
dicatat di database sistem. Jika tidak status tidak
berubah.
2013 6 Analisa Perancangan Berorientasi Objek Modul 11 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Tabel 3 Spesifikasi naratif untuk use case input data pengirim tingkat perancangan
Use case name Input Data Pengirim
Aktor Operator Data Entry
Brief
Description
Walaupun sebenarnya data pengirim secara tidak
langsung telah diimputkan dan disimpan saat
melakukan transaksi. Tetapi untuk mendapatkan
keterangan yang lebih terperinci data pengirim
maka diperlukan use case ini. Use case ini
merupakan tempat untuk melakukan penambahan
atau mengedit data pengirim.
Exception Data untuk keterangan yang dibutuhkan untuk data
pengirim telah ditentukan.
Basic Flow 1. Untuk menambahakan, menghapus dan
mengedit data pengirim maka dapat
dilakukan pada form ini dengan memilih
menu Record Data Pengirim.
2. Sistem secara otomatis akan menampilkan
form tesebut yang berisi data pengirim yang
sebelumnya telah tersimpan.
3. Operator Data Entry menginputkan data-data
pada space yang telah ditentukan dengan
benar.
4. Sistem akan mengontrol setiap entri yang
masuk apakah sesuai dengan ketentuan.
5. Bila semua data yang dimasukan telah benar
maka Operator Data Entry dapat menyimpan
data tersebut dengan menekan tombol save.
6. Sistem akan menyimpan data pengirim
tersebut.
Alternatif flow Jika dalam pengisian data transaksi tidak lengkap
maka sistem akan menampilkan pesan kesalahan
dan meminta kepada Operator Data Entri untuk
2013 7 Analisa Perancangan Berorientasi Objek Modul 11 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
mengisi informasi yang dibuthkan terlebih dahulu.
Operator Data Entry bisa memilih Reset(atau nama
lain yang sejenis) untuk mengosongkan form data
penerima.
Pre condition Operator Data Entry harus login terlebih dahulu.
Data pengirim yang akan dimasukan sudah tersedia
dan sesuai.
Post condition Jika use case sukses dijalankan, maka data akan
dicatat di database sistem. Jika tidak status tidak
berubah.
Tabel 4 Spesifikasi naratif untuk use case input data penerima tingkat perancangan
Use case name Input Data Penerima
Aktor Operator Data Entry
Brief
Description
Walaupun sebenarnya data penerima secara tidak
langsung telah diimputkan dan disimpan saat
melakukan transaksi. Tetapi untuk mendapatkan
keterangan yang lebih terperinci data penerima
maka diperlukan use case ini. Use case ini
merupakan tempat untuk melakukan penambahan
atau mengedit data penerima.
Exception Data untuk keterangan yang dibutuhkan untuk data
penerima telah ditentukan.
Basic Flow 1. Untuk menambahkan, menghapus dan
mengedit data penerima maka dapat
dilakukan pada form ini dengan memilih
menu Record Data Penerima.
2. Sistem secara otomatis akan menampilkan
form tesebut yang berisi data penerima yang
sebelumnya telah tersimpan.
3. Operator Data Entry menginputkan data-data
pada space yang telah ditentukan dengan
benar.
2013 8 Analisa Perancangan Berorientasi Objek Modul 11 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
4. Sistem akan mengontrol setiap entri yang
masuk apakah sesuai dengan ketentuan.
5. Bila semua data yang dimasukan telah benar
maka Operator Data Entry dapat menyimpan
data tersebut dengan menekan tombol save.
6. Sistem akan menyimpan data penerima
tersebut.
Alternatif flow Jika dalam pengisian data penerima tidak lengkap
maka sistem akan menampilkan pesan kesalahan
dan meminta kepada Operator Data Entri untuk
mengisi informasi yang dibuthkan terlebih dahulu.
Operator Data Entry bisa memilih Reset(atau nama
lain yang sejenis) untuk mengosongkan form data
penerima.
Pre condition Operator Data Entry harus login terlebih dahulu.
Data penerima yang akan dimasukan sudah tersedia
dan sesuai.
Post condition Jika use case sukses dijalankan, maka data akan
dicatat di database sistem. Jika tidak status tidak
berubah.
Tabel 5 Spesifikasi naratif untuk use case input data karyawan tingkat perancangan
Use case name Input Data Karyawan
Aktor Operator Data Entry
Brief
Description
Use case ini memungkin operator data entri untuk
melakukan entry data karyawan yang bekerja di
perusahaan tersebut
Exception Data karyawan yang akan dimasukan sudah tersedia
dan sudah sesuai dengan ketentuan dan karyawan
tersebut merupakan pekerja di perusahan tersebut.
Basic Flow 1. Untuk menambahkan, menghapus dan
mengedit data Karyawan maka dapat
dilakukan pada form ini dengan memilih
2013 9 Analisa Perancangan Berorientasi Objek Modul 11 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
menu Record Data Karyawan.
2. Sistem secara otomatis akan menampilkan
form tesebut.
3. Operator Data Entry menginputkan data-data
pada space yang telah ditentukan dengan
benar.
4. Sistem akan mengontrol setiap entri yang
masuk apakah sesuai dengan ketentuan.
5. Bila semua data yang dimasukan telah benar
maka Operator Data Entry dapat menyimpan
data tersebut dengan menekan tombol save
(atau nama lain yang sejenis) .
Sistem akan menyimpan data Karyawan
tersebut.
Alternatif flow Jika dalam pengisian data karyawan tidak lengkap
maka sistem akan menampilkan pesan kesalahan
dan meminta kepada Operator Data Entri untuk
mengisi informasi yang dibuthkan terlebih dahulu.
Operator Data Entry bisa memilih Reset(atau nama
lain yang sejenis) untuk mengosongkan form data
penerima.
Pre condition Operator data entry harus login terlebih
dahulu.
Data yang diperlukan sudah tersedia dan
sesuai.
Post condition Data karyawan telah tersimpan
Tabel 6 Spesifikasi Naratif untuk Use Case Proses Tagihan (Pembayaran) Tingkat
Perancangan
2013 10 Analisa Perancangan Berorientasi Objek Modul 11 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Use case name Proses Tagihan
Aktor Operator Data Entry
Brief
Description
Use case ini memungkin operator data entri untuk
melakukan pembayaran dari sebuah transaksi.
Proses pembayaran diproses secara langsung atau
dibuat tagihannya untuk beberapa transaksi dalam
satu periode tertentu bagi pengirim yang sudah
menjadi member.
Exception Proses transaksi telah berlangsung sudah sesuai
dengan ketentuan.
Basic Flow 1. Untuk menambahkan, menghapus dan
mengedit data pembayaran (tagihan) maka
dapat dilakukan pada form ini dengan
memilih menu proses Tagihan.
2. Sistem secara otomatis akan menampilkan
form tesebut.
3. Operator Data Entry menginputkan data-data
pada space yang telah ditentukan dengan
benar.
4. Sistem akan mengontrol setiap entri yang
masuk apakah sesuai dengan ketentuan.
5. Bila semua data yang dimasukan telah benar
maka Operator Data Entry dapat memproses
data tersebut dengan menekan tombol Ok
(atau nama lain yang sejenis) .
Sistem akan menyimpan data tagihan
tersebut.
Alternatif flow Jika dalam pengisian data tagihan tidak lengkap
maka sistem akan menampilkan pesan kesalahan
dan meminta kepada Operator Data Entri untuk
mengisi informasi yang dibutuhkan terlebih dahulu.
Operator Data Entry bisa memilih Reset(atau nama
2013 11 Analisa Perancangan Berorientasi Objek Modul 11 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
lain yang sejenis) untuk mengosongkan form data
penerima.
Pre condition Operator data entry harus login terlebih
dahulu.
Data yang diperlukan sudah tersedia dan
sesuai.
Post condition Data tagihan telah tersimpan
Tabel 7 Spesifikasi naratif untuk use case laporan data transaksi tingkat perancangan
Use case name Laporan Data Transaksi
Aktor Operator Data Entry
Brief
Description
Use case ini memungkin operator data entri untuk
melakukan pembuatan laporan, data yang didapat
dari proses transaksi yang terjadi.
Exception Data transaksi yang akan dimasukan sudah tersedia
dan sudah sesuai dengan ketentuan.
Basic Flow Proses pembuatan laporan dilakukan
bertujuan untuk mengetahui seberapa
banyak proses terjadinya transaksi dan
pendapatan yang di hasilkan
Operator data entry mulai memproses
pembuatan laporan maka dapat dilakukan
pada form ini dengan memilih menu proses
Laporan.
Sistem akan meminta kepada operator data
entry untuk memasukan ketentuan atau
parameter yang akan menjadi batasan untuk
memproses data.
Sistem akan memproses data yang telah
diinputkan sesuai dengan ketentuan yang
berlaku.
2013 12 Analisa Perancangan Berorientasi Objek Modul 11 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Setelah itu data yang telah di inputkan akan
disimpan untuk menjadi sumber informasi
yang dibutuhkan untuk proses nantinya.
Alternatif flow Jika data pada saat memasukan data parameter tak
sesuai, maka proses harus diulang .
Pre condition Operator data entry harus login terlebih
dahulu.
Data yang diperlukan sudah tersedia dan
sesuai.
Post condition Data laporan siap cetak
Tabel 8 Spesifikasi naratif untuk use case laporan data tagihan tingkat perancangan
Use case name Laporan Data Tagihan
Aktor Operator Data Entry
Brief
Description
Use case ini memungkin operator data entri untuk
melakukan pembuatan laporan, data yang didapat
dari proses transaksi yang terjadi yang kemudian
akan dibuat tagihan berdasarkan kode pengirim .
Exception Data transaksi yang akan dimasukan sudah tersedia
dan sudah sesuai dengan ketentuan.
Basic Flow 1. Proses pembuatan laporan dilakukan
bertujuan untuk mengetahui jumlah tagihan
yang dapat dibuat dari beberapa transaksi,
dan sebagai bukti kepada pengirim.
2. Operator data entry mulai memproses
pembuatan laporan maka dapat dilakukan
pada form ini dengan memilih menu proses
Laporan.
3. Sistem akan meminta kepada operator data
entry untuk memasukan ketentuan atau
parameter yang akan menjadi batasan untuk
memproses data.
4. Sistem akan memproses data yang telah
2013 13 Analisa Perancangan Berorientasi Objek Modul 11 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
diinputkan sesuai dengan ketentuan yang
berlaku.
5. Setelah itu data yang telah di inputkan akan
disimpan untuk menjadi sumber informasi
yang dibutuhkan untuk proses nantinya.
Alternatif flow Jika data pada saat memasukan data parameter tak
sesuai, maka proses harus diulang .
Pre condition Operator data entry harus login terlebih
dahulu.
Data yang diperlukan sudah tersedia dan
sesuai.
Post condition Data laporan tagihan siap cetak
Tabel 9 Spesifikasi naratif untuk use case laporan data pengirim tingkat perancangan
Use case name Laporan Data Pengirim
Aktor Operator Data Entry
Brief
Description
Use case ini memungkin operator data entri untuk
melakukan pembuatan laporan, data yang didapat
dari proses transaksi yang terjadi yang kemudian
akan dibuat laporan berdasarkan kode pengirim .
Exception Data transaksi yang akan dimasukan sudah tersedia
dan sudah sesuai dengan ketentuan.
Basic Flow 1. Proses pembuatan laporan dilakukan
bertujuan untuk mengetahui data-data
pengirim yang menggunkan jasa perusahaan
tersebut.
2. Operator data entry mulai memproses
pembuatan laporan maka dapat dilakukan
pada form ini dengan memilih menu proses
Laporan.
3. Sistem akan meminta kepada operator data
entry untuk memasukan ketentuan atau
parameter yang akan menjadi batasan untuk
2013 14 Analisa Perancangan Berorientasi Objek Modul 11 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
memproses data.
4. Sistem akan memproses data yang telah
diinputkan sesuai dengan ketentuan yang
berlaku.
5. Setelah itu data yang telah di inputkan akan
disimpan untuk menjadi sumber informasi
yang dibutuhkan untuk proses nantinya.
Alternatif flow Jika data pada saat memasukan data parameter tak
sesuai, maka proses harus diulang .
Pre condition Operator data entry harus login terlebih
dahulu.
Data yang diperlukan sudah tersedia dan
sesuai.
Post condition Data laporan Pengirim siap cetak
Tabel 10 Spesifikasi naratif untuk use case laporan data penerima tingkat perancangan
Use case name Laporan Data Penerima
Aktor Operator Data Entry
Brief
Description
Use case ini memungkin operator data entri untuk
melakukan pembuatan laporan, data yang didapat
dari proses transaksi yang terjadi yang kemudian
akan dibuat laporan berdasarkan kode penerima.
Exception Data transaksi yang akan dimasukan sudah tersedia
dan sudah sesuai dengan ketentuan.
Basic Flow 1. Proses pembuatan laporan dilakukan
bertujuan untuk mengetahui data-data
pengirim yang menggunkan jasa perusahaan
tersebut.
2. Operator data entry mulai memproses
pembuatan laporan maka dapat dilakukan
pada form ini dengan memilih menu proses
Laporan.
2013 15 Analisa Perancangan Berorientasi Objek Modul 11 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
3. Sistem akan meminta kepada operator data
entry untuk memasukan ketentuan atau
parameter yang akan menjadi batasan untuk
memproses data.
4. Sistem akan memproses data yang telah
diinputkan sesuai dengan ketentuan yang
berlaku.
5. Setelah itu data yang telah di inputkan akan
disimpan untuk menjadi sumber informasi
yang dibutuhkan untuk proses nantinya.
Alternatif flow Jika data pada saat memasukan data parameter tak
sesuai, maka proses harus diulang .
Pre condition Operator data entry harus login terlebih
dahulu.
Data yang diperlukan sudah tersedia dan
sesuai.
Post condition Data laporan Pengirim siap cetak
Identifikasi Kelas pada Use Case
Dalam hal ini, kita memilki 3 jenis kelas dalam UML yang di gunakan yaitu : Boundary,
Entity dan Control. Kita akan membahas masing-masing stereotype di bawah ini :
a. Boundary Class
Boundary class adalah kelas-kelas yang berada pada batasan antara sistem
kita dengan lingkungan. Kelas.kelas ini mencakup form-form, laporan-
laporan, antarmuka-antarmuka (interface) ke perangkat-perangkat keras
seperti printer-perinter serta antarmuka ke sistem yang lain. Representasi
UML untuk boundary terlihat pada Gambar di bawah ini.
Gambar 1 Boundary class
2013 16 Analisa Perancangan Berorientasi Objek Modul 11 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
b. Entity Class
Entity class memelihara informasi-informasi yang mungkin akan kita
simpan di tempat penyimpanan yang persisten (Objek persisten adalah objek
yang tetap hadir saat perangkat lunak berakhir). Representasi UML untuk
entity terlihat pada Gambar di bawah ini.
Gambar 2. Entity class
c. Control Class
Control class bertanggung jawab untuk mengkoordinasi upaya-upaya
yang dilakukan kelas-kelas lainnya. Mereka bersifat optional, tetapi jika
control class digunakan, mereka biasanya digunakan satu untuk setiap use
case, yang fungsinya adalah mengendalikan urutan-urutan event yang menglir
pada use case. Representasi UML untuk control terlihat pada gambar di
bawah ini.
Gambar 3. Control class
Tabel 11 Spesifikasi strereotype class tingkat perancangan
Class Boundary Class Control Class Entity
MainForm
FormLogin ProsesLogin (verifikasi user,
password).
Data_User
FormTransaksiPengiriman AddTransaksiPengiriman Transaksi
2013 17 Analisa Perancangan Berorientasi Objek Modul 11 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
FormDataPengirim AddEditDataPengirim Pengirim
FormDataPenerima AddEdit Data Penerima Penerima
FormDataKaryawan AddEditDataKaryawan Karyawan
FormProsesTagihan ProsesTagihan Tagihan
FormLaporanPenerima ProsesLaporanPenerima Penerima
FormLaporanPengirim ProsesLaporanPengirim Pengirim
FormLaporanTransaksi ProsesLaporanTransaksi Transaksi
FormLaporanTagihan ProsesLaporanTagihan Tagihan
Langkah selanjutnya adalah membuat class diagram. Dengan mengacu pada ilustrasi tabel
diatas maka kita bisa melakukan pemodelan diagram class tersebut.
2013 18 Analisa Perancangan Berorientasi Objek Modul 11 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Data_UserProsesLogin
KoneksiDatabase
FormLogin
MainForm
FormDataPenerima
FormLaporanPenerima
FormDataPengirim
FormLaporanPengirim
FormProsesTagihan
FormLaporanTagihan
FormDataKaryawan
FormTransaksiPengiriman
FormLaporanTransaksi
AddEditDataPenerima
ProsesLaporanPenerima
AddEditDataPengirim
ProsesLaporanPengirim
ProsesTagihan
ProsesLaporanTagihan
AddEditDataKaryawan
AddTransaksiPengiriman
ProsesLaporanTransaksi
Penerima
Pengirim
Tagihan
Karyawan
Sifat
Transaksi
Jenis
Gambar 4 Class diagram tingkat desain
Tabel 12 Daftar attribut dan operasi pada class tingkat perancangan
Class Attribut Operasi
MainForm <<Komponen
Tampilan Form>>
Tampilkan Form(frame :
JFrame)
KoneksiDatabase()
BelumLogin()
LoginSukses()
UnLoadWindow()
KonneksiDatabase koneksi_database()
load_DriverJDBC()
Connection koneksiDatabase()
getData()
getResourceBundle()
FormLogin <<Komponen FormLogin()
2013 19 Analisa Perancangan Berorientasi Objek Modul 11 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Tampilan Form>> Close Form()
ProsesLogin dataUser
dataPassword
Status
CheckUserPassword()
Check Status()
KoneksiDatabase()
ValidasiUserdanPassword()
Data_User NamaUser
Password
Status
ValidasiUserPassword()
FormDataPengirim <<Komponen
Tampilan Form>>
FormDataPengirim(frame :
JFrame)
CreateTable()
reloadRecord(scrSQL : string)
reloadRecord()
KoneksiDatabase()
Close()
AddEditDataPengirim <<Komponen
Tampilan Form>>
Add_Edit_Data_Pengirim(fra
me : JFrame)
listener_tombol()
tampilKode()
clearFields()
KoneksiDatabase()
dispose()
Pengirim KodePengirim
NamaPengirim
Alamat
Kota
NoTelpon
KodePos
Simpan()
Update()
SelectData()
Cetak()
FormDataPenerima <<Komponen
Tampilan Form>>
FormDataPenerima(frame :
JFrame)
CreateTable()
reloadRecord(scrSQL : string)
reloadRecord()
2013 20 Analisa Perancangan Berorientasi Objek Modul 11 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
KoneksiDatabase()
Close()
AddEditDataPenerima <<Komponen
Tampilan Form>>
Add_Edit_Data_Penerima(fra
me : JFrame)
listener_tombol()
tampilKode()
clearFields()
KoneksiDatabase()
Dispose()
Penerima Kode Penerima
Nama Penerima
Alamat
Kota
NoTelpon
KodePos
Simpan()
Update()
SelectData()
Cetak()
FormDataKaryawan <<Komponen
Tampilan Form>>
FormDataKaryawan(frame :
JFrame)
CreateTable()
reloadRecord(scrSQL : string)
reloadRecord()
KoneksiDatabase()
Close()
AddEditDataKaryawan <<Komponen
Tampilan Form>>
Add_Edit_Data_Karyawan(fra
me : JFrame)
listener_tombol()
tampilKode()
clearFields()
KoneksiDatabase()
Dispose()
Karyawan KodeKaryawan
NamaKaryawan
TglLahir
Alamat
Simpan()
Update()
SelectData()
Cetak()
2013 21 Analisa Perancangan Berorientasi Objek Modul 11 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Kota
NoTelpon
KontakPerson
FormTransaksiPengiriman <<Komponen
Tampilan Form>>
FormTransaksiPengiriman(fra
me : JFrame)
CreateTable()
reloadRecord(scrSQL : string)
reloadRecord()
KoneksiDatabase()
Close()
AddTransaksiPengiriman <<Komponen
Tampilan Form>>
AddTransaksiPengiriman(fram
e : JFrame)
listener_tombol()
ambilNoTran()
inputdataPenerima()
inputDataPengirim()
biaya()
KoneksiDatabase()
Dispose()
Transaksi TglTransaksi
NoTransaksi
KodePengirim
KodePenerima
JenisPengiriman
SifatPengiriman
Biaya
NamaKurir
SelectData()
Cetak()
FormProsesTagihan <<Komponen
Tampilan Form>>
FormProsesPenagihan(frame :
JFrame)
tambahListener()
tampilNoTagihan()
tampilDataKeTabel()
Close()
2013 22 Analisa Perancangan Berorientasi Objek Modul 11 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
KoneksiDatabase()
ProsesTagihan Update Data()
Proses()
Input Kriteria()
ProsesInputan()
Dispose()
KoneksiDatabase()
getData()
Cetak()
Tagihan NoTagihan
TglTagihan
Jumlah
SelectData
FormLaporanPenerima <<Komponen
Tampilan Form>>
FormLapPenerima()
KoneksiDatabase()
TampilkankeTabel()
Close()
ProsesLaporanPenerima InputKriteria()
KoneksiDatabase()
TambahListerner()
ProsesSelect()
Cetak()
getData()
FormLaporanPengirim <<Komponen
Tampilan Form>>
FormLapPengirim()
KoneksiDatabase()
TampilkankeTabel()
Close()
ProsesLaporanPengirim InputKriteria()
KoneksiDatabase()
TambahListerner()
ProsesSelect()
Cetak()
getData()
FormLaporanTransaksi <<Komponen FormLapTransaksi()
2013 23 Analisa Perancangan Berorientasi Objek Modul 11 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Tampilan Form>> KoneksiDatabase()
TampilkankeTabel()
Close()
ProsesLaporanTransaksi InputKriteria()
KoneksiDatabasev
TambahListerner()
ProsesSelect()
Cetak()
getData()
FormLaporanTagihan <<Komponen
Tampilan Form>>
FormLapTagihan()
KoneksiDatabase()
TampilkankeTabel
Close()
ProsesLaporanTagihan InputKriteria()
KoneksiDatabase()
TambahListerner()
ProsesSelect()
Cetak()
getData()
2013 24 Analisa Perancangan Berorientasi Objek Modul 11 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Daftar Pustaka
Alan Denis, Barbara Haley Wixon, David Tagerden, System Analys and Design : an Object –
Oriented Approach with UML 2.0, John Willey and Sons, 2005
Henry C. Lucas Jr., The Analysis, Design and Implementation of Information Systems 4th,
McGraw Hill, 1992
Satzinger, Jackson, Burd, Object-Oriented Analysis and Design with the Unified Process,
Course Technology, 2005
Simon Bennet, Steve McRobb and Ray Farmer, Object-Oriented System Analysis and
Design Using UML, McGraw Hill, 2006
Wendy and Michael Boggs, UML with Rational Rose 2002, Sibex Inc., 2002
MODUL PERKULIAHAN
ANALISA
PERANCANGAN BERORIENTASI OBJEK
Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana
Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh
Ilmu Komputer Teknik Informatika
12 87016 Tim Dosen
Abstract Kompetensi
Memahami kebutuhan sistem Menentukan kebutuhan teknik dan menganalisa kebutuhan
2013 2 Analisa Perancangan Berorientasi Objek Modul 12 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Sequence Diagram Sequence diagram digunakan untuk menggambarkan perilaku pada sebuah scenario. Diagram
ini menunjukan sejumlah contoh obyek dan message (pesan) yang diletakkan diantara obyek-
obyek ini di dalam use case.
Komponen utama sequence diagram terdiri dari atas obyek yang ditulisakan dengan kotak
segiempatbernama. Message diwakili oleh garis dengan tanda panah dan waktu yang
ditunjukan dengan progress vertikal dan penjelasan lebih lengkap telah dijelaskan pada bab
sebelumnya.
Sequence Diagram Untuk Use Case Login
Gambar 1. Sequence diagram use case login
2013 3 Analisa Perancangan Berorientasi Objek Modul 12 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Sequence Diagram untuk Use Case Transaksi Pengiriman
Gambar 3. Sequence diagram use case transaksi pengiriman
2013 4 Analisa Perancangan Berorientasi Objek Modul 12 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Sequence Diagram untuk Use Case Input Data Pengirim
Gambar 4. Sequence diagram use case input data pengirim
2013 5 Analisa Perancangan Berorientasi Objek Modul 12 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Sequence Diagram untuk Use Case Input Data Penerima
Gambar 5. Sequence diagram use case input data penerima
2013 6 Analisa Perancangan Berorientasi Objek Modul 12 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Sequence Diagram untuk Use Case Input Data Karyawan
Gambar 6. Sequence diagram use case input data karyawan
2013 7 Analisa Perancangan Berorientasi Objek Modul 12 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Sequence Diagram untuk Use Case Proses Tagihan
Gambar 7. Sequence diagram use case proses tagihan
2013 8 Analisa Perancangan Berorientasi Objek Modul 12 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Sequence Diagram untuk Use Case Laporan Transaksi
Gambar 8. Sequence diagram use case laporan transaksi
2013 9 Analisa Perancangan Berorientasi Objek Modul 12 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Sequence Diagram untuk Use Case Laporan Pengirim
Gambar 9. Sequence diagram use case laporan pengirim
2013 10 Analisa Perancangan Berorientasi Objek Modul 12 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Sequence Diagram untuk Use Case Laporan Penerima
Gambar 9. Sequence diagram use case laporan penerima
2013 11 Analisa Perancangan Berorientasi Objek Modul 12 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Sequence Diagram untuk Use Case Laporan Tagihan
Gambar 10. Sequence diagram use case laporan tagihan
State Machine Diagram
State Machine diagram biasanya digunakan untuk memodelkan perilaku dinamis suatu class
atau obyek. State machine diagram memperlihatkan urutan state yang dilalui sebuah obyek,
kejadian yang menyebabkan sebuah transisi dari suatu state atau aktivitas ke state atau
aktivitas yang lain, dan aksi yang menyebabkan perubahan state atau aktivitas.
State machine diagram khususnya digunakan untuk memodelkan taraf-taraf diskrit suatu
siklus hidup obyek, sedangkan activity diagram paling cocok digunakan memodelkan urutan
activitas duatu proses. State machine diagram digunakan untuk memodelkan obyek dari
semenjak dibuat sampai selesai. Pada kondisi ini tidak semua class akan mempunyai state
yang menarik untuk dibahas.
2013 12 Analisa Perancangan Berorientasi Objek Modul 12 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
State Machine Diagram Pengirim
Gambar 11 State machine diagram pengirim
2013 13 Analisa Perancangan Berorientasi Objek Modul 12 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
State Machine Diagram Tagihan
Gambar 12. State machine diagram tagihan
2013 14 Analisa Perancangan Berorientasi Objek Modul 12 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
State Machine Diagram Transaksi
Gambar 13. State machine diagram transaksi
Diagram Activity
Activity diagram memodelkan alur kerja (work flow) sebuah urutan aktivitas pada suatu
proses. Diagram ini sangat mirip dengan flow chart karena kita dapat memodelkan prosedur
logika, proses bisnis dan alur kerja. Perbedaan utamanya adalah flow chart dibuat untuk
menggambarkan alur kerja dari sebuah sistem, sedangkan activity diagram dibuat untuk
menggambarkan aktivitas aktor.
2013 15 Analisa Perancangan Berorientasi Objek Modul 12 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Diagram Activity untuk Aplikasi Pengiriman Barang
Gambar 13. Diagram Activity untuk Aplikasi Pengiriman Barang
Component Diagram
Component diagram menggambarkan alokasi semua class dan objek ke dalam komponen-
komponen fisik di sebuah sistem software. Diagram ini memperlihatkan pengaturan dan
kebergantungan diantara komponen-komponen software seperti dinamik library link (DLL),
executable component dan lain-lain. Manfaat dari penggunaan component in adalah
penggunaan kembali (reusable) suatu component pada proyek lain tanpa harus melakukan
usaha yang berarti. Dengan demikian akan bisa menghemat waktu dan biaya dalam
pengembangannya. Pada permasalahan ini, diasumsikan akan memanfaatkan teknologi COM
(Component Objek Modeling) atau DCOM melalui DTS (Data Translation Service). Berikut
ini adalah gambaran layer untuk DTS tersebut.
2013 16 Analisa Perancangan Berorientasi Objek Modul 12 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Secara umum, business rule services mengandung class-class bisnis dari interface-
interface yang dipakai diaplikasi. Sedangkan class data translation akan menjdi
interface CRUD(Create, Read, Update, Delete). Adapun DASVC.DLL akan
menjalankan beberapa operation yaitu :
DARetrieve akan membuat connection string dan menjalankan sebuah query
Select.
DAQuery akan menjalanakan semua tipe query yang lain (Delete, Update dn
Insert).
Mengandung class-class bisnis seperti
pelangga, pengirim, penerima, transaksi dll.
Menangani aliran kerja dan
menyiapkan user interface yang gampang
dioperasikan.
Mengkomunikasikan class di layer in
i dengan layer DTS.
Business Rul
Data Translati
Data Acce
ss
2013 17 Analisa Perancangan Berorientasi Objek Modul 12 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Diagram Component Sebuah Sistem
Gambar 14. Diagram component sebuah system
Deployment Diagram
Deployment diagram menyediakan gambaran bagaimana sistem secara fisik akan terlihat.
Sistem terdiri dari node-node dimana setiap node diwakili untuk sebuah kubus. Garis yang
menghubungkan antara 2 kubus menunjukan hubungan diantara hardware dan bisa juga
processor (yang mengeksekusi component) atau execution environment (software yang
menjadi hsost atau mengandung software lain.
2013 18 Analisa Perancangan Berorientasi Objek Modul 12 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Penerapan Diagram Deployment
Gambar 3.27. Penerapan Deployment Diagram pada Sistem
&&&&&&
2013 19 Analisa Perancangan Berorientasi Objek Modul 12 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Daftar Pustaka
Alan Denis, Barbara Haley Wixon, David Tagerden, System Analys and Design : an Object –
Oriented Approach with UML 2.0, John Willey and Sons, 2005
Henry C. Lucas Jr., The Analysis, Design and Implementation of Information Systems 4th,
McGraw Hill, 1992
Satzinger, Jackson, Burd, Object-Oriented Analysis and Design with the Unified Process,
Course Technology, 2005
Simon Bennet, Steve McRobb and Ray Farmer, Object-Oriented System Analysis and
Design Using UML, McGraw Hill, 2006
Wendy and Michael Boggs, UML with Rational Rose 2002, Sibex Inc., 2002
MODUL PERKULIAHAN
ANALISA
PERANCANGAN BERORIENTASI OBJEK
Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana
Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh
Ilmu Komputer Teknik Informatika
13 87016 Tim Dosen
Abstract Kompetensi
Memahami kebutuhan sistem Menentukan kebutuhan teknik dan menganalisa kebutuhan
2013 2 Analisa Perancangan Berorientasi Objek Modul 13 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Menggunakan Rekayasa Web
Atribut pada Aplikasi dan Sistem Berbasis Web
Menurut Pressman (2005: 502) Web application berbeda dari kategori lainnya dalam
perangkat lunak komputer. Atribut yang mengikuti sangat banyak ditemui di dalam web
application adalah:
Network intensiveness,
Concurrency,
Unpredicable load,
Performance,
Availability,
Data driven,
Content sensitive,
Continuous evolution,
Immediacy,
Security,
Aesthetics,
Sedangkan yang termasuk ke dalam kategori aplikasi yang sering ditemui di dalam kerja
rekayasa web adalah:
Informational,
Download,
Customizeable,
Interaction,
User input,
Transaction-oriented,
Service-oriented,
Portal,
Database access,
Data warehouse.
2013 3 Analisa Perancangan Berorientasi Objek Modul 13 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Layer-layer WebApp Engineering
Rekayasa web dapat digambarkan ke dalam tiga layer yaitu:
process,
methods, dan
tools/technology.
Web Engineering Process
Proses rekayasa web mengambil filosofi pengembangan cerdas yang menekankan pada
pendekatan teknik kecenderungan yang mudah untuk menaikan pengiriman data dari sistem
yang berkembang. Proses umum dari framework yang dapat diaplikasikan untuk rekayasa
web adalah:
Customer communication,
web customer communication
Dalam proses rekayasa digolongkan ke dalam dua tugas besar, yaitu:
1. Business Analysis menetapkan konteks bisnis / organisasi untuk web application.
Dengan tambahan, :
a. stakeholder telah dikenali,
b. perubahan yang mungkin dalam lingkungan bisnis atau syarat yang harus dipenuhi
telah diprediksi, dan
c. integrasi antara web application dan aplikasi bisnis lainnya, database, dan fungsi
telah dikenali.
d. Formulation syarat-syarat aktivitas yang harus dipenuhi untuk semua stakeholder.
2. Planning, Rencana proyek untuk pengembangan applikasi web yang telah dibuat/telah
ada . Rencana tersebut terdiri dari :
a. task definition dan
b. jadwal kerja untuk jangka waktu relative pendek.
3. Modeling, Analisis rekayasa perangkat lunak konvensional dan tugas mendisain
yang disesuaikan untuk perkembangan web application, digabungkan, dan
kemudian dimasukkan ke dalam aktivitas modeling rekayasa web.
2013 4 Analisa Perancangan Berorientasi Objek Modul 13 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
4. Construction, Menggunakan alat dan teknologi rekayasa web untuk membangun
aplikasi web yang telah dirancang.
5. Deployment, Pemasangan dan konfigurasi aplikasi disesuaikan dengan lingkungan
tempat dimana aplikasi akan dipasang dikirimkan kepada end-user, dan kemudian
memulai masa evaluasi.
Aktivitas dari framework ini dipilah kedalam sepasang tugas-tugas rekayasa web yang
disesuaikan menurut kebutuhan dari setiap framework rekayasa Web yang diterapkan
didalam proyek. Aktivitas dari lima akrifitas process yang meliputi :
Gambar 1 Web Engineering Process (Dari Pressman: 508)
Formulating Sistem Berbasis Web
Formulation adalah aktivitas komunikasi konsumen yang menemukan masalah yang akan
dipecahkan oleh web application :
1. Kebutuhan bisnis,
2. Tujuan dan kriteria keberhasilan proyek,
3. Kategorisasi end-user,
4. fitur dan fungsi utama, dan
5. tingkat interoperabilitas dengan aplikasi lainnya
Kelompok Web Engineering (Web Engineering Group)
1. Kelompok web engineering terdiri dari anggota kelompok yang punya spesialisasi
2013 5 Analisa Perancangan Berorientasi Objek Modul 13 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
teknis dan non-teknis yang memungkinkan kelompok ini memiliki otoritas untuk
melakukan pengambilan keputusan.
2. Manajemen proyek dibutuhkan selama web engineering, perbedaannya adalah masa
tugas yang lebih singkat, dan boleh jadi otoritasnya tidak meliputi keseluruhan Teknik
Informatika organisasi.
Requirements analysis untuk WebApps
Requirements analysis untuk WebApps mencakup tiga tugas utama:
1. formulation,
2. requirements gathering, dan
3. analysis modeling.
Selama formulation, tujuan utama dan obyek untuk WebApp telah diidentifikasi, dan kategori
dari user ditemukan. Sejak requirements gathering dimulai, komunikasi diantara tim Web
ngineering dan WebApp stakeholder semakin erat. Formulation, requirement gathering, dan
analysis modeling dilakukan untuk dapat melakukan identifikasi kebutuhan user yang akan
diterapkan/dipenuhi oleh web application :
1. Hirarki User. Kategori dari end-users yang berinteraksi dengan WebApp diidentifikasi
sebagai bagian dari tugas-tugas formulation dan equirements gathering.
2. Kategorisasi user (sering disebut actors) memberikan petunjuk pada fungsionalitas
untuk diberikan oleh WebApp dan menunjukan kebutuhan user yang digambarkan
dengan use-case yang dibangun untuk setiap end-user (actor) yang ditulis secara
hirarki.
3. Membangun Use-Cases. Menurut Franklin [FRA01] dalam pressman: 542,
menyatakan bahwa use-cases sebagai “bundles of functionality”. Deskripsi ini
memperlihatkan esensi dari pentingnya teknik analysis modeling. Use-case dibangun
untuk setiap kategori user yang digambarkan di dalam hirarki user. Di dalam konteks
Web engineering, use-case itu sendiri cenderung informal – paragraf narasi yang
menggambarkan interaksi spesifik diantara user dan WebApp.
4. Menemukan kembali Use-Case Model. Sebagaimana use-case Diagram dibuat untuk
setiap kategori user, use-case adalah katalisator untuk semua syarat aktivitas analisis
dan pemodelan. Use-cases diatur ke dalam package-package dan setiap package
dinilai untuk memastikan bahwa use-case:
2013 6 Analisa Perancangan Berorientasi Objek Modul 13 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
5. Comprehensible (Lengkap), Semua stakeholder mengerti tujuan dari package.
5. Cohesive, fungsi alamat package yang berhubungan dekat satu dengan lainnya.
5. Loosely coupled, fungsi atau kelas dalam package bekerjasama satu
dengan lainnya, tetapi kerjasama ketergantungan antar package dijaga tetap
minimum.
5. Hierarchically shallow, fungsional hierarki yang terdalam sulit untuk mengontrol
dan susah bagi end-user untuk mengerti; oleh karena itu, jumlah dari tingkatan
dalam hirarki use-case seharusnya diminimalkan jika dimungkinkan.
Content Model
Content model menggambarkan spectrum dari content obyek yang dimasukkan kedalam web
application. Content obyek ini harus dibangun atau diperoleh untuk penggabungan ke dalam
arsitektur web application. Pohon data dapat digunakan untuk mewakili content hirarki
obyek. Kelas analisis (berasal dari use-case) memberikan arti lain untuk mewakili kunci
obyek bahwa web application akan dimanipulasi.
Interaction Model
Interaction model disusun dengan use-cases, UML sequence diagrams, dan UML state
diagrams untuk menggambarkan percakapan diantara user dan web application. Sebagai
tambahan, bentuk dasar antar muka mungkin dibangun untuk membantu dalam
pengembangan layout dan keperluan navigasi. Sebagian besar dari web application
membolehkan percakapan antara end-user dan fungsionalitas aplikasi, isi, dan perilaku.
Interaction model terdiri dari empat elemen yaitu:
1. Use-cases, Adalah elemen yang dominan dari interaction model untuk web
application. Sudah umum menggambarkan 100 atau lebih use-cases ketika sangat
besar, web application yang kompleks yang dianalisis, didisain, dan dibangun.
Bagaimanapun, persentase yang kecil secara relative use-cases ini menggambarkan
sebagian besar interaksi antara end-user categories (aktor) dan sistem. Use-cases
lainnya memperbaiki interaksi, memperbaiki secara rinci analisis yang diperlukan
untuk panduan pada disain dan pembangunan.
2013 7 Analisa Perancangan Berorientasi Objek Modul 13 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
2. Sequence diagrams, UML sequence diagrams memberikan gambaran singkat dari cara
yang mana aksi user (elemen dinamis dari sistem yang didefinisikan oleh use-cases)
bekerjasama dengan kelas analisis (elemen structural dari sistem yang didefinisikan
oleh kelas diagram). Kelas harus dapat dijejaki ke use case.
3. State diagrams, UML state diagrams memberikan gambaran lain dari perilaku dinamis
web application sebagai interaksi yang terjadi. Seperti kebanyakan gambaran
modeling digunakan di dalam rekayasa web (atau rekayasa perangkat lunak), state
diagram dapat digambarkan dengan perbedaan tingkatan dari abstraksi.
4. User interface prototype, Tata ruang dari user interface, isinya ditampilkan, ekanisme
interaksinya dilaksanakan, dan estetika secara keseluruhan dari hubungan user dengan
web application telah banyak dilakukan dengan kenyamanan user dan dukungan
secara keseluruhan dari web application.
Functional Model
Functional model menggambarkan user dapat mengamati fungsi dan kelas operasi
menggunakan UML activity diagram. Functional model memanggil dua proses elemen dari
web application, setiap penggambaran berbeda tingkatan dari prosedure abstraksi:
1. User dapat mengamati fungsionalitas yang dikirimkan web application kepada end-
user,
2. Operation diisi dalam kelas analisis yang melaksanakan perilaku bersahabat dengan
kelas.
Configuration Model
Configuration model menggambarkan lingkungan yang web application akan digunakan
pada sistem berbasis server dan berbasis klien :
1. Relationship-Navigation Analysis Relationship–navigation analysis (RNA)
memperkenalkan hampir semua hubungan elemen isi dan fungsional ditemukan pada
analysis model dan menentukan syarat–syarat untuk menemukan link navigasi yang tepat
dari keseluruhan sistem. Rangkaian dari jawaban pertolongan untuk menentukan
hubungan dan memperkenalkan karakteristik yang akan mempengaruhi pada desain
navigasi. Pendekatan RNA diorganisir ke dalam lima tahap :
1. Stakeholder analysis = mengenali berbagai kategori user dan membuat hierarki
stakeholder yang tepat.
2013 8 Analisa Perancangan Berorientasi Objek Modul 13 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
2. Element analysis = mengenali isi obyek dan elemen fungsional yang menarik
perhatian end-user.
3. Relationship analysis = menggambarkan hubungan kerjasama yang ada diantara
elemen web application.
4. Navigation analaysis = memeriksa bagaimana user boleh mengakses elemen
perorangan atau elemen kelompok.
5. Evaluation analysis = memutuskan pokok permasalahan secara pragmatis
dihubungkan dengan pelaksanaan hubungan kerjasama yang didefinisikan segera.
2. Desain dan Kualitas WebApp Olsina et.al [OLS99] dalam pressman: 561, telah
menyiapkan “quality requirement tree” yang mengidentifikasikan satu set atribut
untuk menilai kualitas WebApp.Kriteria yang ada pada gambar di bawah ini menjadi
bagian menarik untuk Web engineers siapa yang harus mendesain, membangun, dan
merawat WebApps melewati jangka waktu yang lama :
Gambar 2 Quality Requirement Tree (Pressman: 561)
2013 9 Analisa Perancangan Berorientasi Objek Modul 13 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Offut [OFF02] dalam pressman: 561, memperluas lima kualitas utama atribut yang dicatat
pada gambar di atas dengan menambah atribut yang mengikutinya, yaitu:
1. Security,
2. Availability,
3. Scalability,
4. Time-to-market.
Design Goals
Menurut Jean Kaiser [KAI02] dalam pressman: 563, untuk mencapai kualitas atribut web
application, desain web application yang baik harus menampilkan:
1. Simplicity,
2. Consistency,
3. Identity,
4. Robustness,
5. Navigability,
6. Visual Appeal,
7. Compatibility.
&&&&&&&&
2013 10 Analisa Perancangan Berorientasi Objek Modul 13 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Daftar Pustaka
Alan Denis, Barbara Haley Wixon, David Tagerden, System Analys and Design : an Object –
Oriented Approach with UML 2.0, John Willey and Sons, 2005
Henry C. Lucas Jr., The Analysis, Design and Implementation of Information Systems 4th,
McGraw Hill, 1992
Satzinger, Jackson, Burd, Object-Oriented Analysis and Design with the Unified Process,
Course Technology, 2005
Simon Bennet, Steve McRobb and Ray Farmer, Object-Oriented System Analysis and
Design Using UML, McGraw Hill, 2006
Wendy and Michael Boggs, UML with Rational Rose 2002, Sibex Inc., 2002
MODUL PERKULIAHAN
ANALISA
PERANCANGAN BERORIENTASI OBJEK
Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana
Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh
Ilmu Komputer Teknik Informatika
14 87016 Tim Dosen
Abstract Kompetensi
Memahami kebutuhan sistem Menentukan kebutuhan teknik dan menganalisa kebutuhan
2013 2 Analisa Perancangan Berorientasi Objek Modul 14 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Perancangan Database
Di UML, class diagram mendefinisikan struktur data yang dibutuhkan oleh
sebuah aplikasi. Struktur data yang tetap di database dimodelkan sebagai class entity
dan sebagai relasi diantara class entity. Class entity ini perlu dimappingkan ke
struktur data yang dikenal oleh database. Struktur data ini dangat tergantung pada
model database dimana bisa objek oriented, objek relational maupun relational.
Pemodelan class dan package class BCED (Boundary Control Entity Databases)
merefleksikan class-class aplikasi bukan struktur penyimpanan database.
Class-class entity mewakili databases objek di aplikasi, tetapi bukan class
yang menetap di database. Class-class database menyembunyikan komunikasi
diantara aplikasi dan database, akan tetapi mereka bukan persistent class. Oleh
karenanya kita masih perlu merancang layer persistent database. Layer persistent
database bisa jadi adalah relasional
2013 3 Analisa Perancangan Berorientasi Objek Modul 14 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
ER Conceptual Data Model (CDM)
Pengirim Transaksi1,1
1,n
KaryawanCatatTransaksi1,1
0,n
TagihanTransaksi
1,1
1,n
PenerimaTransaksi
0,1
0,n
JenisTransaksi
1,11,n
SifatTransaksi1,1
1,n
KotaTransaksi
1,1
0,n
KotaPenerima
0,n
1,1
KotaKaryawan
0,n
1,1
KotaPengirim
0,n
1,1
TagihanPengirim
1,1
1,n
Transaksi
NoTransaksiTglTransaksiBeratTransaksi
<pi> A9DVA20
<M>
Pengirim
KdPengirimNamaPengirimAlamatPengirimKdPosPengirimTlpPengirimFaksPengirimKPPengirim
<pi> VA20VA50VA100VA10VA20VA20VA20
<M>
Karyawan
KdkaryawanNamaKaryawanTglLahirKaryawanSexStatusAlamatKPKaryawan
<pi> A9VA20DVA9VA20VA50VA20
<M>
Tagihan
NoTagihanTglTagihan
<pi> A9D
<M>
Kota
KdKotaNamaKota
<pi> A9VA20
<M>
Jenis
KdJenisNamaJenis
<pi> A9VA20
<M>
Sifat
KdSifatNamaSifatBiayaSifat
<pi> A9VA20DC12,2
<M>
Penerima
KdPenerimaNamaPenerimaAlamatPenerimaKdPosPenerimaTlpPenerimaFaksPenerimaKPPenerima
<pi> A9VA30VA100VA9VA9VA9VA20
<M>
Gambar 1. Conceptual data model (cdm)
2013 4 Analisa Perancangan Berorientasi Objek Modul 14 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Normalisasi
1NF
Keterangan :
NoTrans = NoTransaksi Nm = Nama Brt
= Berat
NoTag = No Tagihan Alm = Alamat Biy
= Biaya
TglTrans = TglTransaksi Kta = Kota Ktr
= Keterangan
K_Pgr = KodePengirim K_Pos = Kode_Pos
K_Pnr = KodePenerima Tlp = Telepon
K_Jns = KodeJenis Faks = Faksimile
K_Sft = KodeSifat K_Prs = KontakPerson
K_Kry = Kode_Karyawan Sts = Status
Jml = Jumlah TglTrm = TglTerima
2NF
Transaksi
Penerima
Pengirim
2013 5 Analisa Perancangan Berorientasi Objek Modul 14 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Karyawan
Tagihan
Sifat
Jenis
Kota
3NF
Transaksi
Tagihan
2013 6 Analisa Perancangan Berorientasi Objek Modul 14 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Diagram ER Physical Data Model (PDM)
FK_TRANSAKS_PENGIRIM__PENGIRIM
FK_TRANSAKS_KARYAWANC_KARYAWAN
FK_TRANSAKS_TAGIHANTR_TAGIHAN
FK_TRANSAKS_PENERIMAT_PENERIMA
FK_TRANSAKS_JENISTRAN_JENIS
FK_TRANSAKS_SIFATTRAN_SIFAT
FK_TRANSAKS_KOTATRANS_KOTA
FK_PENERIMA_KOTAPENER_KOTA
FK_KARYAWAN_KOTAKARYA_KOTA
FK_PENGIRIM_KOTAPENGI_KOTA
FK_TAGIHAN_TAGIHANPE_PENGIRIM
Transaksi
NoTransaksiKdJenisKdPenerimaKdkaryawanKdSifatKdKotaNoTagihanKdPengirimTglTransaksiBeratTransaksi
CHAR(9)CHAR(9)CHAR(9)CHAR(9)CHAR(9)CHAR(9)CHAR(9)CHAR(9)DATEVARCHAR(20)
<pk><fk5><fk4><fk2><fk6><fk7><fk3><fk1>
Pengirim
KdPengirimKdKotaNamaPengirimAlamatPengirimKdPosPengirimTlpPengirimFaksPengirimKPPengirim
CHAR(9)CHAR(9)VARCHAR(30)VARCHAR(100)VARCHAR(9)VARCHAR(20)VARCHAR(20)VARCHAR(20)
<pk><fk>
Karyawan
KdkaryawanKdKotaNamaKaryawanTglLahirKaryawanSexStatusAlamatKPKaryawan
CHAR(9)CHAR(9)VARCHAR(20)DATEVARCHAR(9)VARCHAR(20)VARCHAR(50)VARCHAR(20)
<pk><fk>
Tagihan
NoTagihanKdPengirimTglTagihan
CHAR(9)CHAR(9)DATE
<pk><fk>
Kota
KdKotaNamaKota
CHAR(9)VARCHAR(20)
<pk>
Jenis
KdJenisNamaJenis
CHAR(9)VARCHAR(20)
<pk>
Sifat
KdSifatNamaSifatBiayaSifat
CHAR(9)VARCHAR(20)NUMBER(12,2)
<pk>
Penerima
KdPenerimaKdKotaNamaPenerimaAlamatPenerimaKdPosPenerimaTlpPenerimaFaksPenerimaKPPenerima
CHAR(9)CHAR(9)VARCHAR(30)VARCHAR(100)VARCHAR(9)VARCHAR(9)VARCHAR(9)VARCHAR(20)
<pk><fk>
Gambar 2. Model er physical data model (pdm)
Perancangan Struktur Menu Tampilan
Struktur Menu Program Keseluruhan
Gambar 3. Perancangan struktur menu program keseluruhan
2013 7 Analisa Perancangan Berorientasi Objek Modul 14 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Struktur Menu Utama
Gambar 4. Perancangan struktur menu utama
Struktur Menu File
Gambar 5. Perancangan struktur menu file
Struktur Menu Record
Gambar 6. Perancangan struktur menu record
Struktur Menu Proccess
Gambar 7. Perancangan struktur menu proccess
Struktur Menu Report
Gambar 8. Perancangan struktur menu report
2013 8 Analisa Perancangan Berorientasi Objek Modul 14 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Struktur Menu Help
Gambar 9. Perancangan struktur menu help
Struktur Menu Utility
Gambar 10. Perancangan struktur menu utility
Perancangan Input Output
Form Login
Pada rancangan layar Login, User harus measukkan Username dan
Password untuk dapat memasuki layar menu utama. Apabila user salah
measukkan password, maka akan muncul pesan “invalid user ID or
password”. Berikut rancangan layar login pada Gambar 11
Gambar 11. Tampilan form login
Keterangan gambar :
Username
Admin harus memasukkan usernamenya dengan benar
Password
Admin harus memasukkan password dengan benar.
Login
2013 9 Analisa Perancangan Berorientasi Objek Modul 14 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Untuk memasuki layar menu admin apabila username dan password
sesuai.
Layar Menu Utama
Setelah login berhasil operator dapat melakukan transaksi pembayaran
atau input data baru dengan menggunakan fasilitas yang tersedia pada form
menu, dalam bentuk menubar yang ter diri atas;
File
Pada menubar File berisi menu item Loogoff dan Exit. Data Operator
digunakan untuk melakukan login untuk operator baru, dan untuk
mengakhiri program dari menu file.
Record
Pada menubar Record menyediakan fasilitas bagi operator data entry
untuk melakukan penambahan dan pengeditan beberapa data antra lai :
data pengirim, data penerima, data karyawan dan data parameter.
Proceess
Pada menubar process ini digunakan untuk memproses suatu transaksi
yang berlangsung, proses konfirmasi penerimaan dan proses penagihan
atas beberapa transaksi.
Report
Pada menubar report ini operator data entry dapat melihat bebrapa data
diantranya adalah data pengirim, data penerima, data tagihan dan data
tagihan yang kemudian dapat dicetak sebagai dibuat laporan.
Help
Apabila didalam pengoperasian aplikasi ini menemui sebuah masalah
maka menu ini mungkin bisa membantu para pengguna untuk
menyelesaikan masalah yang didapatkan dalam aplikasi ini.
BussinessSetup
Pada menubar ini bila seorang user berstatus admin maka ia dapat
menggunakan menubar ini untuk menambah user, dan mengedit data
rekening perusahaan tersebut.
2013 10 Analisa Perancangan Berorientasi Objek Modul 14 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Gambar 12. Tampilan Form Utama (mainform).
Tampilan Form Data Pengirim
Form ini digunakan untuk melihat data dan menginput data pengirim serta
untuk menanipulasi dan menghapus data pengirim, pada form ini berisi beberapa
data sebagai berikut :
1. Kode Pengirim, berisi kode dari pengirim.
2. Nama Pengirim, menjelaskan nama pengirim dengan
jelas.
3. Alamat, untuk mengetahui data alamat pengirim
dengan benar.
4. Telpon, untuk alat komunikasi dengan pengirim.
Form ini juga menyediakan tabel untuk kita dapat melihat dan merubah
input data juga hasil data yang sudah masuk. Form ini juga menyediakan tombol
simpan, buat baru dan hapus untuk mengkoreksi atau menghilangkan data yang
sudah ada.
Gambar 13. Tampilan form data pengirim
2013 11 Analisa Perancangan Berorientasi Objek Modul 14 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Tampilan Form Tambah Data Pengirim
Selain dengan menggunakan form transaksi untuk menambah data
pengirim form ini juga dapat digunakan untuk menambahkan data pengirim
diantaranya :
Gambar 14. Tampilan form tambah data pengirim
Tampilan Form Data Penerima
Form ini digunakan untuk melihat data dan menginput data penerima serta
untuk menanipulasi dan menghapus data penerima, pada form ini berisi beberapa
data sebagai berikut :
1. Kode Penerima, berisi kode dari penerima.
2. Nama Penerima, menjelaskan nama penerima dengan jelas.
3. Alamat, untuk mengetahui data alamat penerima dengan benar.
4. Telpon, untuk alat komunikasi dengan penerima.
Form ini juga menyediakan tabel untuk kita dapat melihat dan merubah
input data juga hasil data yang sudah masuk. Form ini juga menyediakan tombol
simpan, buat baru dan hapus untuk mengkoreksi atau menghilangkan data yang
sudah ada.
2013 12 Analisa Perancangan Berorientasi Objek Modul 14 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Gambar 15. Tampilan form data penerima
Tampilan Form Tambah Data Penerima
Selain dengan menggunakan form transaksi untuk menambah data
pengirim form ini juga dapat digunakan untuk menambahkan data penerima
diantaranya :
Gambar 16. Tampilan form tambah data penerima
Tampilan Form Data Karyawan
Form ini digunakan untuk melihat data dan menginput data karyawan
serta untuk menanipulasi dan menghapus data karyawan, pada form ini berisi
beberapa data sebagai berikut :
1. Kode Karyawan, berisi kode dari karyawan.
2. Nama Karyawan, menjelaskan nama karyawan dengan jelas.
3. Alamat, untuk mengetahui data alamat karyawan dengan benar.
4. Telpon, untuk alat komunikasi dengan karyawan.
Form ini juga menyediakan tabel untuk kita dapat melihat dan merubah
2013 13 Analisa Perancangan Berorientasi Objek Modul 14 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
input data juga hasil data yang sudah masuk. Form ini juga menyediakan tombol
simpan, buat baru dan hapus untuk mengkoreksi atau menghilangkan data yang
sudah ada.
Gambar 17. Tampilan form data karyawan
Tampilan Form Tambah Data Karyawan
Selain dengan menggunakan form transaksi untuk menambah data
pengirim form ini juga dapat digunakan untuk menambahkan data karyawan
diantaranya :
Gambar 18. Tampilan form tambah data karyawan
Tampilan Form Data Transaksi Pengiriman
Form ini juga menyediakan tabel untuk kita dapat melihat dan merubah
input data juga hasil data yang sudah masuk dari sebuah proses transaksi
pengiriman. Form ini juga menyediakan tombol simpan, buat baru dan hapus
2013 14 Analisa Perancangan Berorientasi Objek Modul 14 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
untuk mengkoreksi atau menghilangkan data yang sudah ada
Gambar 19. Tampilan form data transaksi
Tampilan Form Tambah Transaksi
Pengiriman
Setelah kita menampilkan form utama proses transaksi pengiriman dan
untuk menambahkan data transaksi yang baru dengan mengklik tombol tambah
(add), maka form yang selanjutnya ditampilkan adalah form berikut ini :
Gambar 20. Tampilan form tambah transaksi
Tampilan Form Konfirmasi Transksi Pengiriman
Form ini adalah digunakan untuk memproses konfirmasi atas transaksi-
trasaksi yang dikirim
2013 15 Analisa Perancangan Berorientasi Objek Modul 14 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Gambar 21. Tampilan form konfirmasi pengiriman
Tampilan Form Proses Penagihan
Pada form poses penagihan ini digunakan oleh operator untuk membuat
atau memproses tagihan kepengirim atas transaksi-transaksi yang telah dilakukan
dan dianggap benar, operator dapat melakukan proses penagihan berdasarkan
tanggal dan kode pengirim :
Gambar 22. Tampilan form proses penagihan
Tampilan Form Proses Penagihan untuk Melihat Detail Tagihan
Setelah melakukan proses penagihan dan kita ingin melihat detail dari
nomor tagihan tersebut, maka kita dapat mengklik tabpane yang berada disebelah
kanannya. Form ini berisi data-data tagihan.
2013 16 Analisa Perancangan Berorientasi Objek Modul 14 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Gambar 23. Tampilan form detail tagihan
Pada form proses penagihan
Tampilan Form Parameter untuk Kota Pengiriman
Karena pada pada proses pengiriman barang atau paket itu oleh beberapa
kriteria, akan tetapi hal yang paling menentukan banyak atau sedikitnya biaya
yang dibutuhkan yaitu kota tujuan atau jarak jauh dekatnya tujuan dari penerima
barang tersebut. Oleh karena itu dibutuhkan sebuah ukuran untuk menentukan
biaya yang dibuhkan, dan untuk keperluan tersebut maka dapat di lakukan pada
form berikut ini :
Gambar 24. Tampilan form parameter kota
Tampilan Form Parameter untuk Sifat Pengiriman
Pada form ini berguna untuk memberikan informasi sifat dari pengiriman
dan dapat dijadikan acuan untuk menghitung biaya yang dibutuhkan, sehingga
kita dapat membrikan pilhan kepada pelanggan (pengirim) untuk apat memilih
sifat pengiriman yang dipilih sesuai dengan kebutuhan.
2013 17 Analisa Perancangan Berorientasi Objek Modul 14 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Gambar 25. Tampilan form parameter sifat
Tampilan Form Parameter untuk Jenis Pengiriman
Pada form ini berguna untuk memberikan informasi jenis dari pengiriman
dan dapat dijadikan sebagai sebuah data tambahan didalam proses transaksi
pengiriman.
Gambar 26. Tampilan form parameter jenis
Tampilan Form Laporan Data Penerima
Form laporan data penerima ini untuk mncetak data yang berfungsi untuk
laporan dari operator ke manager. Operator hanya mengimput kode penerima
lewat menu drop down yang telah disediakan. Dan bila data yang dipilih telah
sesuai maka data tersebut akan ditampilkan di tabel tersebut.
2013 18 Analisa Perancangan Berorientasi Objek Modul 14 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Gambar 27. Tampilan form laporan data penerima
Tampilan Form Laporan Data Pengirim
Form laporan data pengirim ini untuk mncetak data yang berfungsi untuk
laporan dari operator ke manager. Operator hanya mengimput kode pengirim
lewat menu drop down yang telah disediakan. Dan bila data yang dipilih telah
sesuai maka data tersebut akan ditampilkan di tabel tersebut.
Gambar 28. Tampilan form laporan data pengirim
Tampilan Form Laporan Data Transaksi
Form laporan data transaksi ini untuk mncetak data yang berfungsi untuk
laporan dari operator ke manager. Operator hanya mengimput kode pengirim dan
tanggal pengiriman lewat menu drop down yang telah disediakan. Dan bila data
yang dipilih telah sesuai maka data tersebut akan ditampilkan di tabel tersebut.
2013 19 Analisa Perancangan Berorientasi Objek Modul 14 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Gambar 29. Tampilan form laporan data transaksi
Tampilan Form Laporan Data Tagihan
Form laporan data tagihan ini untuk mncetak data yang berfungsi untuk
laporan dari operator ke manager. Operator hanya mengimput nomor tagihan
lewat menu drop down yang telah disediakan. Dan bila data yang dipilih telah
sesuai maka data-data transaksi yang telah berlangsung selama satu periode
tersebut akan ditampilkan di tabel tersebut.
Gambar 30. Tampilan form laporan data tagihan
Tampilan Form Data Rekening
Apabila yang login adalah seorang admin maka ia dapat membuka form
ini. Form ini digunakan untuk mengisi data rekening dari perusahaan yang
bersangkutan.
2013 20 Analisa Perancangan Berorientasi Objek Modul 14 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Gambar 31. Tampilan form laporan data rekening
Tampilan Form Tambah Data User
Apabila yang login adalah seorang admin maka ia dapat membuka form
ini. Form ini digunakan untuk menambah, menghapus serta mengedit data user
yang berhak untuk mngoperasikan aplikasi tersebut.
Gambar 32. Tampilan form tambah user
Tampilan Form Bantuan (Help)
Pada form bantuan ini, untuk dapat mejadi fasilitas tambahan bagi seorang
operator baru yang ingin mengetahui cara penggunaan aplikasi yang dibuat.
1. About
Merupakan menu bantuan yang memberikan informasi tentang penjelasan
pemanfaatan aplikasi tersebut.
2013 21 Analisa Perancangan Berorientasi Objek Modul 14 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Gambar 33. Tampilan Form Bantuan (Help) untuk About
2. Content
Merupakan menu bantuan yang memberikan informasi tentang penjelasan
beberapa hal.
1. Tata cara konfigurasi dan install
2. Tentang Aplikasi Delivery Sistem version 1.1
3. Tentang pembuat aplikasi (Programer).
4. Sedikit penjelasan tentang bahasa pemrograman Java
Gambar 34. Tampilan form bantuan (help) untuk content
Perancangan layar Output
Laporan Data Transaksi
Gambar 3.62. Rancangan output data transaksi
2013 22 Analisa Perancangan Berorientasi Objek Modul 14 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Hasil Cetak Data Pengirim Per Kode
Pengirim
Gambar 35. Rancangan output data pengirim
Per kode pengirim
Hasil Cetak Data Pengirim Per Kode Penerima
Gambar 36. Rancangan output data penerima
Per kode penerima
Hasil Cetak Data Karyawan
2013 23 Analisa Perancangan Berorientasi Objek Modul 14 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Gambar 37. Rancangan output data karyawan
Per kode karyawan
Laporan Data Penerima
Gambar 38. Rancangan output data penerima
Laporan Data Pengirim
Gambar 39. Rancangan output data pengirim
2013 24 Analisa Perancangan Berorientasi Objek Modul 14 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Laporan Data Tagihan
Gambar 40. Rancangan output data tagihan
Implementasi Sistem
Tahap perancangan diikuti oleh tahap implementasi. Menterjemahkan perancangan ke
kode program adalah proses yang relative sederhana dan bersifat mekanis sebab
perancangan yang baik sudah mengambarkan dengan baik apa yang harus dilakukan
dengan bahasa-bahasa pemrograman. Asalkan kita telah melakukan pemodelan
dengan baik (misalnya dengan menggunakan UML yang penulis telah gunakan ) dan
mempergunakan banyak perangakat-perangkat lunak berjenis CASE (Computer Aided
Software Engineering) yang baik, misalnya Rational Rose dan Visual Paradigm yang
penulis gunakan yang akan dengan mudah menterjemahkan model-model kita tadi
kedalam sintak beberapa bahasa pemrograman.
2013 25 Analisa Perancangan Berorientasi Objek Modul 14 Pusat Bahan Ajar dan eLearning
Tim Dosen http://www.mercubuana.ac.id
Daftar Pustaka
Alan Denis, Barbara Haley Wixon, David Tagerden, System Analys and Design : an Object –
Oriented Approach with UML 2.0, John Willey and Sons, 2005
Henry C. Lucas Jr., The Analysis, Design and Implementation of Information Systems 4th,
McGraw Hill, 1992
Satzinger, Jackson, Burd, Object-Oriented Analysis and Design with the Unified Process,
Course Technology, 2005
Simon Bennet, Steve McRobb and Ray Farmer, Object-Oriented System Analysis and
Design Using UML, McGraw Hill, 2006
Wendy and Michael Boggs, UML with Rational Rose 2002, Sibex Inc., 2002