MODUL PERKULIAHAN ANALISA PERANCANGAN...
Transcript of MODUL PERKULIAHAN ANALISA PERANCANGAN...
2013 1
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 Sistem Informasi
01 87007 Team Dosen
Abstract Kompetensi
SDLC, RAD, Design Tersturktur, Class Memahami siklus pengembangan
2013 2
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
dan Object sistem, memahami metodhologi pengembangan sistem, mengenal UML
2013 3
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 sistem informasi 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 4
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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
2013 5
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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.
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 6
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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);
2013 7
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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.
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 sistem informasi. 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 8
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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
2013 9
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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
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
2013 10
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
menjelaskan hubungan struktural dan behaviour dari sebuah sistem informasi. 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. 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.
2013 11
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Figure 2-7 The Unified Process
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
2013 12
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 sistem
informasi secara itterative dan incremental. Tahapan-tahapan tersebut menjelaskan
bagaimana sistem informasi berevolosi. Tergantung kepada tahapan yang mana,
tingkat aktivitas dalam setiap workflows akan bervariasi.
2013 13
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 4 th,
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
2013 1
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 Sistem Informasi
02 87007 Team Dosen
Abstract Kompetensi
Memahami awal dari project dan Memahami hubungan sistem informasi
2013 2
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
memahami data dan kebutuhan bisnis dan pengelolaan data
2013 3
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 :
4. 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.
5. 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.
6. Perhatikan latihan normalisasi yang diberikan pada contoh Invoice :
UoD : R
Y1
Y2
Y3
X1
X2
X3
X4
X5
2013 4
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
(Invoice.InvoiceNo + Invoice.ItemNo) Invoice.Qty. Pasangan Nilai InvoiceNo dan ItemNo menjadi determinan bagi Qty (Jumlah barang yang dibeli yang dicatat didalam tabel invoice). Qty menjadi berarti jika dipasangkan dengan InvoiceNo dan ItemNo sekaligus.
7. 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.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
Dari contoh invoice diatas kita dapat mulai melakukan proses normalisasi dan membuat tabel didalam Database. II. URUT-URUTAN PEKERJAAN
7. Transformasi fakta menjadi Tabel 1 NF 8. Tentukan Functional Dependencynya 9. Normalisasikan sampai bentuk normal ke 3 10. Buat SQL Script untuk medefinisikan tabel 11. Definisikan tabel didalam database
2013 5
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 :
InvoiceNo
ItemNo
CustomerNo CustomerName
Address
City
InvoiceDate
ItemDescriptio
n
Qty
Unit UnitPric
e
SubTotal
PPN
Total
Cost
2013 6
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 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,
Customer Item
Invoice InvoiceItem
2013 7
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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)); 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
2013 8
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 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.00 1002 Kembang Api 10 Dozen 1,000,000 10,000,000.00 1003 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 9
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
2013 10
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 :
5. Data yang berada pada sisi one/sisi primary key harus diisi terlebih dahulu. 6. Data yang berada pada sisi many/foreign key diisi setelah sisi primary key. 7. 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 :
11. Customer dan Item harus diisi terlebih dahulu 12. Invoice 13. 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’)
Customer Item
Invoice InvoiceItem
2013 11
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
4. Mengisi Invoice Item
Insert into InvoiceItem(InvoiceNo, ItemNo, Qty) values(‘1001’, ‘X01’, 20) Insert into InvoiceItem(InvoiceNo, ItemNo, Qty) values(‘1001’, ‘X02’, 10) 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’
2013 12
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
3. Menghapus Customer
4. Delete from Customer where CustomerNo = ‘007’
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 4 th,
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
2013 1
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 Sistem Informasi
03 87007 Team Dosen
Abstract Kompetensi
Mengidentifikasi ukuran project, Memahami Managemen Project
2013 2
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
membuat dan mengelola rencana kerja pelaksanaan project
2013 3
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 :
8. Studi kelayakan digunakan untuk membantu dalam menentukan untuk meneruskan
sistem informasi atau tidak.
9. 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.
10. 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 :
12. Tangible value merupakan nilai yang bisa dikuantifikasidan diukur dengan alat ukur
2013 4
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
numerik. Misalkan penurunan penggunaan kertas sebesar 2 persen karena tidak perlu
mencetak memo.
13. 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 5
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Feasibily analysis secara umum terdiri dari 3 teknik :
8. 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.
9. 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.
10. 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 :
14. Identifikasi Biaya dan Manfaat : Membuat bdaftar seluruh tangible cost dan manfaat dari
project.
15. 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.
16. Menentukan cash flow : Memproyeksikan apakah manfaat dan biaya yang akan terjadi
2013 6
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
dalam suatu periode tertentu baik jangka menengah maupun panjang. Termasuk juga
memperhitungkan faktor pertumbuhan.
17. Menentukan NPV (Net Present Value) : Menghitung nilai sekarang dari biaya yang
timbul dimasa yang akan datang dihitung dengan standard hari ini. Rate of growth harus
ditentukan untuk menghitung NPV
18. Tentukan ROI (Return On Investment) : Menghitung seberapa banyak organisasi akan
menerima manfaat investasi.
19. 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.
20. Menggambarkan BEP : Gambarlah BEP dengan menggunakan time-graph.
Adapun biaya-biaya yang harus diperhitungkan dalam melakukanCost and Benefit Analysis
meliputi/diantaranya adalah :
5. Development Cost :
6. Development Team Salaries
7. Consultant Fees
8. Development Training
9. Hardware and Software
10. Vendor Installation
11. Office Space and Equipment
12. Data Conversion Costs
13. Operational Costs
14. Software Upgrades
15. Software Licensing Fees
16. Hardware Repairs
17. Hardware Upgrades
2013 7
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
18. Operational Team Salaries
19. Communication Charges
20. User Training
21. Tangible Benefits
22. Increased Sales
23. Reduction in Staff
24. Reduction in Inventory
25. Better Supplier Prices
26. Intangible Benefits
27. Increased Market Share
28. Increased Brand Recognition
29. Higher Quality Products
30. Improves Customer Service
31. Better Supplier Relations
Kelayakan organizational adalah penting yaitu untuk memenuhi kepentingan Stakeholders yaitu
:
4. Champion : Adalah orang yang :
5. Menginisiasi project.
6. Mempromosikan project.
7. Mengalokasikan waktunya untuk project.
8. Menyediakan resources.
9. Organizational Management : Adalah pengelolaan organisasi yang :
10. Memahami project.
11. Memberikan anggaran yang cukup bagi terlasananya pekerjaan.
12. Mendorong/memaksa pengguna untuk menerima dan menggunakan sistem.
13. System Users adalah pengguna sistem :
2013 8
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
14. Membuat keputusan yang mempengaruhi project
15. Melakukan aktifitas( atas produk yang dihasilkan) project
16. Menentukan apakah project sukses dengan menggunakan atau tidak menggunakan
sistem.
Project dapat diklasifikasikan Penentuan klasifikasi project ditentukan dengan melihat :
5. Size. Ukuran project dapat dilihat dari seberapa banyak orang yang terlibat dalam
pengerjaannya.
6. Cost. Seberapa banyak biaya yang harus dikeluarkan organisasi untuk mengerjakan
project tersebut.
7. Purpose. Apakah tujuan project. Apakah untuk meningkatkan infrastruktur teknik, untuk
mendukung strategi bisnis, ataukah untuk peningkatan inovasi baru.
8. Length. Seberapa lama project akan selesai sebelum dapat digunakan untuk melakukan
business.
9. Risk. Berapakah kemungkinan project untuk berhasil dan sukses.
10. Scope. Seberapa banyak organisasi dipengaruhi oleh sistem yang dibuat, Apakah satu
departemen, satu divisi, atau seluruh korporasi.
11. 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
2013 9
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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.
Gambar 1 Total Unadjusted Function Points
2013 10
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Gambar 2. Total Processing Complexity
Adjusted Project Complexity = .065 + (0.01 * Project Complexity) Total Adjusted Function Points = Adjusted Project Complexity * TUFP 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
2013 11
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 12
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 4 th,
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
2013 1
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 Sistem Informasi
04 87007 Team Dosen
Abstract Kompetensi
Memahami kebutuhan sistem Menentukan kebutuhan teknik dan
2013 2
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
menganalisa kebutuhan
2013 3
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 4
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Pengertian Requirement
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 5
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Gambar 1. Contoh Functional Requirement
2013 6
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Gambar 2 Contoh Non Functional Requirement
Requirement Definition
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.
Determining Requirements
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.
2013 7
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Membuat Reqirement Definition
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 :
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
2013 8
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
paling berat dari pembuatan sistem.
Requirements Analysis Techniques.
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 :
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
2013 9
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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. 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.
Business Process Automation
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
2013 10
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 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.
Business Process Improvement
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
2013 11
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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.
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.
Business Process Reengineering
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
2013 12
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 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 13
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 4 th,
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
2013 1
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 Sistem Informasi
05 87007 Team Dosen
Abstract Kompetensi
Memahami kebutuhan sistem Menentukan kebutuhan teknik dan
2013 2
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
menganalisa kebutuhan
2013 3
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 :
3. Managers
4. Karyawan-karyawan
5. Staff,
6. Customer,
7. 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 :
2013 4
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
one on one interview.
one on many interview.
Ada lima tahapan dalam melakukan interview :
4. 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.
5. 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.
6. Mempersiapkan interview. Persiapan interview sangat penting. Sama pentingnya
2013 5
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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.
7. 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.
8. 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.
2013 6
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 :
5. Mengurangi scoop creep sampai 50 %.
6. Menghindarkan requirement yang terlalu spesific atau kurang jelas.
7. JAD merupakan proses yang terstruktur dimana 10 sampai 20 user bertemu dibawah
pimpinan fasilitator yang memahami teknik JAD dan permasalahan yang dibahas tetapi
tidak ikut sebagai partisipan.
8. JAD akan bertemu sesuai dengan batas waktu yang ditentukan sampai menemukan
requirement yang dianggap perlu.
9. Menggunakan bermacam-macam perangkat diantaranya adalah CASE-tools.
10. Tempat dilaksanakannya JAD ditempat yang jauh dari tempat kerja partisipan.
11. Perhatikanlah agar komunikasi dapat berjalan dengan effetive.
Urut-urutan pelaksanaan JAD adalah :
4. 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.
5. 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.
6. Menyiapkan Sesi. Memastikan bahwa partisipan memahami apa yang diharapkan dari
mereka.
7. Melaksanakan JAD. Fasilitator harus memegang peranan utamanya dalam
mengarahkan diskusi peserta JAD :
8. Memastikan agenda dipenuhi
9. Membantu memahami istilah teknis dan methodologi.
10. Merekam apa yang menjadi hasil JAD dan mendistribusikannya.
2013 7
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
11. Post JAD Follow-up. Setelah JAD selesai dilaksanakan haruslah ada dokumentasi yang
diterbitkan dan ditindaklanjuti.
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 :
8. Memilih Participants
9. Merancang Questionaire
10. Administrasi questionaire
11. Questionaire Follow Up.
Document Analysis
Dokumen dianalisa untuk memahami sistem berjalan maupun project yang sedang berjalan.
Dokumen dapat saja terdiri dari :
6. Laporan
7. Memorandums
2013 8
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
8. Policy Manuals
9. User Training Manuals
10. Organization charts
11. Forms.
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 :
4. Type of Information. Jenis informasi yang diperlukan
5. Depth of Information. Kedalaman Informasi yang diberikan
6. Breadth of Information. Range/sebaran informasi yang dapat dikumpulkan
7. Integration of Information. Bagaimana mengabungkan Informasi yang diperlukan.
8. User Involvement. Keterlibatan User
9. Biaya yang diperlukan.
Berikut ini adalah ringkasan dari pemilihan tehnik pengumpulan requirement.
2013 9
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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
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 10
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
G
amb
ar 4.
Entit
y
Type
s.
Entity Types
Entit
y
Type
adala
h
sehi
mpu
nan
obye
k
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.
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
2013 11
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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.
Simple & Composite
Simple attribute merupakan attribute yang memiliki nilai tunggal yang berdiri sendiri.
2013 12
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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
4. Strong Entity adalah entity yang keberadaan contoh kejadiannya tidak tergantung
kepada contoh kejadian dari entity type yang lain.
5. Weak Entity type adalah etntiy yang contoh kejadiannya tergantung kepada contoh
kejadian dari entity type yang lain contohnya adalah Karyawan dan
2013 13
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
TanggunganKaryawan.
6. 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 :
3. One to One -> Satu ke Satu
4. One to Many -> Satu ke Banyak
5. Many to Many -> Banyak ke banyak
Notasi
Untuk menggambarkan constraint tersebut digunakan notasi :
Harus :
4. One to One -> 1..1
5. One to Many -> 1..*
6. Many to Many -> *..*
Optional :
1. Nol sampai satu 0..1
4. Nol sampai banyak 0..*
5. Nol sampai tiga misalnya 0..3
&&&&
2013 14
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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
2013 1
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 Sistem Informasi
06 87007 Team Dosen
Abstract Kompetensi
Memahami kebutuhan sistem Menentukan kebutuhan teknik dan
2013 2
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
menganalisa kebutuhan
2013 3
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Functional Modelling
Functional model menjelaskan business process dan interaksi dari sistem informasi dengan
lingkungannya. Didalam OOAD ada dua buah model yang digunakan didalam analisis dan
disain :
6. 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 sistem informasi yang berjalan pada sebuah business
sistem.
7. Use Case. Use case digunakan untuk menjelaskan fungsi dasar sistem informasi. 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
sistem informasi. Use case dapat dilihat sebagai gambaran eksternal atau gambaran
functional sebuah proses business dimana didalamnya diperlihatakan bagaimana
pandangan pengguna terhadap sistem
8. 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.
9. Disamping itu Activity diagram dan use case juga merupakan physical model yang
menggambarkan aktifitas fisik terinci yang memungkinkan sistem berjalan dengan baik.
10. 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 4
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Pengertian Requirement
Requirement adalah pernyataan apa yang harus dilakukan oleh sistem atau karakteristik apa
yang harus dimiliki :
11. 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.
12. 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 :
8. 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
9. 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
2013 5
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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.
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.
2013 6
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Gambar 1 Contoh Activity Diagram untuk Pendaftaran Pasien
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.
2013 7
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
You must identify the activities, control flows, and object flows that occur between the
activities.
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.
2013 8
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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.
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 :
9. 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 :
1. Presents an important business process.
2. The use case supports revenue generation or cost reduction.
3. Technology needed to support the use case is new or risky and therefore will require
considerable research.
2013 9
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
10. 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 sistem informasi.
Untuk membuat use case petunjuk yang diberikan adalah :
12. 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
13. 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
14. Write from independent observer perspective. Ditulis secara independent tidak secara
judgemental.
15. Write at same level of abstraction. Tingkat abstraksi harus sama dengan responden
yang ditanya.
16. Ensure a sensible set of steps. Urut-urutan langkah harus masuk akal. Secara logis urut-
urutan harus benar berurut
17. Apply KISS principle liberally. Use case harus dibuat sederhana, dan mudah dipahami
(Keep it simple stupid).
18. 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 :
12. Actor/Role.
13. Use Case.
14. System
15. Association yang dapat berjenis :
16. Association Relationship
17. Include Relationship
18. Extend Relationship
2013 10
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Gambar 3. Notasi Use Case
2013 11
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Gambar 4. Use Case Diagram
Gambar 5. Extend dan Include Relationship.
2013 12
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Gambar 6. Cara Identifikasi Use Case
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 4 th,
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
2013 1
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 Sistem Informasi
07 87007 Team Dosen
Abstract Kompetensi
Memahami kebutuhan sistem Menentukan kebutuhan teknik dan
2013 2
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
menganalisa kebutuhan
2013 3
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Structural Modelling
7.1 Pendahuluan
Structural modelling adalah:
13. 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.
14. The structure of data used in the system is represented through CRC cards, class
diagrams, and object diagrams.
Tujuan dari pemodelan tersebut adalah :
10. Reduce the “semantic gap” between the real world and the world of software.
11. Create a vocabulary for analysts and users
12. 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 4
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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
2013 5
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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.
Pada contoh Person adalah abstract class sedangkan Doctor dan Patient merupakan concrete
class
2013 6
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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
2013 7
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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
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 :
11. Generalization Enables inheritance of attributes and operations
12. Aggregation Relates parts to wholes
13. Association Miscellaneous relationships between classes
7.2 Class Responsibilities and Collaboration
Menunjukkan kerjasama dari classes untuk melakukan pemenuhan kebutuhan dari client :
19. Responsibilites adalah :
1. Knowing. Mengetahui apa yang harus dikerjakan untuk melayani permintaan client
2. Doing. Melakukan apa yang diminta client
20. Collaboration Objects working together to service a request
2013 8
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Gambar 7-1 CRC Jenis-jenis attribute :
19. Derived atau attribute turunan yang diturunkan dari attribute primitive. Contoh tanggal
lahir adalah primitive. Umur adalah derived attributes
20. Visibility
21. Public bisa dilihat siapa saja
22. Protected hanya bisa dihubungi oleh class yang menjadi friend/teman
23. Private hanya bisa dilihat oleh class itu sendiri
Jenis-jenis operasi selain fungsi methods yang biasa :
2013 9
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
12. Constructor. :
13. Secara otomatis akan dijalankan pada saat oject dibuat
14. Biasanya juga membuat object yang lain
15. Query : Menanyakan state dari object
16. Update : Merubah nilai dari beberapa atau seluruh attribute.
Relationship adalah hubungan antar object/class. Jenis hubungannya bermacam-macam :
12. Sebuah class dapat berhubungan denga dirinya sendiri atau disebut recursive
13. Multiplicity :
14. One to one
15. Zero to many
16. One to many
17. Zero to one
18. Specified Range
19. Multiple disjoint range
Association
Gambar 7-2 Class Diagram
2013 10
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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
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 :
2013 11
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
10. Analisis tekstual dari use case (Textual analysis of use-case information) :
1. Nouns suggest classes
2. Verbs suggest operations
11. Membuat gambaran secara kasar (Creates a rough first cut)
12. Membuat daftar object (Common object list)
13. Membuat daftar contoh kejadian
14. Membuat daftar peranan (Roles)
Setelah melakukan identifikasi class lalu membuat identifikasi pola :
6. hubungan antar class yang dapat dikelompokkan berdasarkan :
7. Transactions
1. Transaction class
2. Transaction line item class
3. Item class
4. Location class
5. Participant class
Adapun tahapan tahapan pembuatan model struktural adalah :
7. Create CRC cards.
8. Examine common object lists.
9. Role-play the CRC cards.
10.Create the class diagram.
11.Review the class diagram.
12.Incorporate patterns.
13.Review the model.
2013 12
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 4 th,
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
2013 1
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 Sistem Informasi
08 87007 Team Dosen
Abstract Kompetensi
Memahami kebutuhan sistem Menentukan kebutuhan teknik dan
2013 2
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
menganalisa kebutuhan
2013 3
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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
2013 4
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
mempresentasikan suatu class beserta dengan atribut dan operasinya. Class adalah pembentuk
utama dari sistem berorientasi objek. Gambar 2 menunjukkan notasi dari class UML.
Nama Class
Atribut
Operasi
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 5
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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
Use Case
2013 6
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 7
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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
Class
1. Attribut : tipe
2. Operasi : tipe
Cabang
Nama Cabang
Pelanggan
Nama Pelanggan
Pembayaran
Jumlah
Tunai
JmlKembalian
Order
No
Tgl
status
Order Detail
Jumlah
Kartu Kredit
No
expDate
Item Barang
Nama Barang
Harga
2013 8
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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
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
Datang ke
gallery
VCD
Memilih
VCD yang
dibeli
Petugas
Keuangan
Bayar VCD
yang dibeli
2013 9
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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
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
Name 1 Name 2
2013 10
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
rounded. Titik awalnya menggunakan lingkaran solid yang diasir dn diakhiri dangan mata.
Berikut adlah symbol UML untuk statechart.
Gambar 11 Simbol Statechart Diagram
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.
Nama
State Variable
Activities
2013 11
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Gambar 13 Colaboration diagram
Component Diagram
Component diagram mengandung componet, interface dan relationship. Notasi component bisa
dilihat pada gambar dibawah ini.
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.
2013 12
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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.
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
2013 13
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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
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 4 th,
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
2013 1
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 Sistem Informasi
09 87007 Team Dosen
Abstract Kompetensi
Memahami kebutuhan sistem Menentukan kebutuhan teknik dan
2013 2
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
menganalisa kebutuhan
2013 3
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 :
15. CPU (Central Processing Unit).
CPU merupakan pusat pengolahan dan juga pusat pengontrolan dari
sebuah sistem komputer yang saling melaksanakan kegiatan.
16. Floppy Disk.
Floppy Disk adalah alat penggerak untuk membaca atau untuk merekam
data dari atau ke media penyimpanan disket.
17. 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.
18. Keyboard.
Keyboard adalah alat input yang biasanya didampingi dengan alat tampilan
(display) di layar yang menampilkan apa yang ditekan di keyboard.
2013 4
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
19. Video Display Unit (VDU)
VDU adalah alat yang digunakan untuk komunikasi interaktif antara manusia
dengan komputer yang berupa tampilan visual.
20. Mouse
Mouse adalah alat input komputer yang digunakan oleh berbagai program
aplikasi GUI ( Graphcal User Interface ) dengan petunjuk posisi yang
ditampilkan melalui monitor.
21. 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 :
13. Sistem Operasi
Sistem operasi yang disarankan minimal Windows 98.
14. 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
2013 5
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
berkosentrasi pada lingkup bisnis diperusahaan yang akan kita rancang sistemnya. Terlebih
dahulu kita harus melakukan pemeriksaan-pemeriksaan pada bisnis itu sendiri: 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
2013 6
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 :
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
2013 7
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
proses tertentu yang dilakukan dengan use case. UML, pekerja bisnis digambarkan sebagai
berikut :
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
2013 8
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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.
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
2013 9
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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).
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
2013 10
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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
berlangsung di perusahaan tersebut.
Operator Data
Entry
Buat Laporan,
Laporan Data
Pengirim ,
Laporan Data
Penerima,
Laporan Data
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 :
2013 11
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Gambar 6 Diagram use case diagram
&&&&&&&&&
2013 12
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 4 th,
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
2013 1
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 Sistem Informasi
10 87007 Team Dosen
Abstract Kompetensi
Memahami kebutuhan sistem Menentukan kebutuhan teknik dan
2013 2
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
menganalisa kebutuhan
2013 3
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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).
22. Brief Description (deskripsi singkat).
23. Aktor yang terlibat.
24. Precondition yang penting bagi use case untuk memulai.
25. Deskripsi rinci dari aliran kejadian yang mencakup :
15. Main Flow dari kejadian yang bisa dirinci lagi menjadi
26. 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
27. 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 4
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 14. Pengirim ingin melakukan pengiriman
dokumen atau paket.
15. Operator Data Entry mulai melakukan input
data yang dibutuhkan sebagai bahan
informasi berikutnya.
16. Sistem akan memproses data yang telah
diinputkan sesuai dengan ketentuan yang
2013 5
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
berlaku.
17. Setelah itu data yang telah di inputkan akan
disimpan untuk menjadi sumber informasi
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 21. Operator data entry harus login terlebih
dahulu.
22. 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 24. Operator data entry dapat menambahkan
atau mengedit data yang telah tersimpan
untuk menambahkan rincian informasi .
25. Operator data entry mulai melakukan input
data yang dibutuhkan sebagai bahan
informasi berikutnya.
2013 6
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
26. Sistem akan memproses data yang telah
diinputkan sesuai dengan ketentuan yang
berlaku.
27. Setelah itu data yang telah di inputkan akan
disimpan untuk menjadi sumber informasi
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 23. Operator data entry harus login terlebih
dahulu.
24. 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 17. Operator data entry dapat menambahkan
atau mengedit biodata karyawan yang
bekerja di peerusahaan .
2013 7
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
18. Operator data entry mulai melakukan input
data yang dibutuhkan sebagai bahan
informasi berikutnya.
19. Sistem akan memproses data yang telah
diinputkan sesuai dengan ketentuan yang
berlaku.
20. Setelah itu data yang telah di inputkan akan
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 25. Operator data entry harus login terlebih
dahulu.
26. 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 20. Operator data entry dapat menambahkan
atau mengedit data yang telah tersimpan
untuk menambahkan rincian informasi .
21. Operator data entry mulai melakukan input
2013 8
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
data yang dibutuhkan sebagai bahan
informasi berikutnya.
22. Sistem akan memproses data yang telah
diinputkan sesuai dengan ketentuan yang
berlaku.
23. 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
sistem akan otomastis akan menampilkan data
tersebut, akan tetapi bila tidak maka operator data
entry harus mengimputkan data baru tersebut.
Pre condition 27. Operator data entry harus login terlebih
dahulu.
28. 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 15. Proses pembayaran atas transaksi yang
dilakukan diproses secara berkala (per
periode) atau secara langsung .
16. Operator data entry mulai melakukan input
data yang dibutuhkan sebagai bahan
2013 9
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
pemrosesan tagihan.
17. Sistem akan meminta kepada operator data
entry untuk memasukan ketentuan atau
parameter yang akan menjadi batasan untuk
memproses data.
18. Sistem akan memproses data yang telah
diinputkan sesuai dengan ketentuan yang
berlaku.
19. Setelah itu data yang telah di inputkan akan
disimpan untuk menjadi sumber informasi
yang dibutuhkan untuk proses nantinya.
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 29. Operator data entry harus login terlebih
dahulu.
30. 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 7. Proses pembuatan laporan dilakukan
bertujuan untuk mengetahui seberapa
2013 10
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
banyak proses terjadinya transaksi dan
pendapatan yang di hasilkan
8. Operator data entry mulai melakukan input
data yang dibutuhkan sebagai bahan
pemrosesan pembuatan laporan
9. Sistem akan meminta kepada operator data
entry untuk memasukan ketentuan atau
parameter yang akan menjadi batasan untuk
memproses data.
10. Sistem akan memproses data yang telah
diinputkan sesuai dengan ketentuan yang
berlaku.
11. 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 31. Operator data entry harus login terlebih
dahulu.
32. 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
2013 11
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Exception Data tagihan didapat dari data transaksi yang akan
dimasukan sudah tersedia dan sudah sesuai dengan
ketentuan.
Basic Flow 8. Proses pembuatan laporan tagihan
dilakukan bertujuan untuk mengetahui
seberapa banyak tagihan yang didapat dari
beberapa transaksi dalam satu periode
tertentu.
9. Operator data entry mulai melakukan input
data yang dibutuhkan sebagai bahan
pemrosesan pembuatan laporan
10. Sistem akan meminta kepada operator data
entry untuk memasukan ketentuan atau
parameter yang akan menjadi batasan untuk
memproses data.
11. Sistem akan memproses data yang telah
diinputkan sesuai dengan ketentuan yang
berlaku.
12. 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 33. Operator data entry harus login terlebih
dahulu.
34. 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
2013 12
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 14. Proses pembuatan laporan pengirim
dilakukan bertujuan untuk mengetahui
seberapa banyak data pengirim yang telah
tesimpan didalam sistem tersebut
15. Operator data entry mulai melakukan input
data yang dibutuhkan sebagai bahan
pemrosesan pembuatan laporan
16. Sistem akan meminta kepada operator data
entry untuk memasukan ketentuan atau
parameter yang akan menjadi batasan untuk
memproses data.
17. Sistem akan memproses data yang telah
diinputkan sesuai dengan ketentuan yang
berlaku.
18. 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 .
2013 13
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Pre condition 35. Operator data entry harus login terlebih
dahulu.
36. 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
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
2013 14
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 37. Operator data entry harus login terlebih
dahulu.
38. 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
sering disebut dengan class entity karena mewakili objek database.
Class entity ini menjelaskan esensi sistem informasi 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
2013 15
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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
tersebut
Tagihan
Langkah selanjutnya adalah membuat class diagram. Dengan mengacu pada ilustrasi tabel diatas
maka kita bisa melakukan pemodelan diagram class tersebut.
2013 16
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Gambar 7 Class Diagram
2013 17
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 4 th,
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
2013 1
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 Sistem Informasi
11 87007 Team Dosen
Abstract Kompetensi
Memahami kebutuhan sistem Menentukan kebutuhan teknik dan
2013 2
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
menganalisa kebutuhan
2013 3
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 :
18. Notasi. Notasi digunakan untuk memberikan gambaran tentang gagasan sistem
kepada anggota team yang lain dan pihak lain yagn memerlukan.
19. 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.
20. 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 4
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
:
39. 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.
40. 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.
41. 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
2013 5
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
password, maka sistem akan memvalidasi user
name dan password tersebut.
Exception Jika salah dalam mengimputkan user dan password
maka sistem tidak akan menampilkan menu utama
(main form).
Basic Flow 28. Tampilkan Form Login
29. Operator Data Entry meninputkan User
name.
30. Operator Data Entry menginputkan
Password
31. Operator Data Entry mengirimkan User
name dan Password dengan memilih tombol
Login agar sistem memvalidasi User name
dan Password tersebut.
32. Sistem memvalidasi User name dan
Password tersebut.
33. 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
2013 6
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Brief
Description
Use case ini memungkinkan seseorang operator data
entry untuk melakukan transaksi pengiriman
dokument atau paket.
Exception Data untuk keterangan yang dibutuhkan untuk
transaksi telah ditentukan.
Basic Flow 21. Operator Data Entry menampilkan data
transaksi dengan memilih menu proses
Transaksi
22. Sistem secara otomatis akan menampilkan
form tesebut yang berisi data nomor
transaksi .
23. Operator Data Entry menginputkan data-data
pada space yang telah ditentukan dengan
benar.
24. Sistem akan mengontrol setiap entri yang
masuk apakah sesuai dengan ketentuan.
25. Bila semua data yang dimasukan telah benar
maka Operator Data Entry dapat menyimpan
data tersebut dengan menekan tombol save.
26. 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
2013 7
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
dan sesuai.
Post condition Jika use case sukses dijalankan, maka data akan
dicatat di database sistem. Jika tidak status tidak
berubah.
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 24. Untuk menambahakan, menghapus dan
mengedit data pengirim maka dapat
dilakukan pada form ini dengan memilih
menu Record Data Pengirim.
25. Sistem secara otomatis akan menampilkan
form tesebut yang berisi data pengirim yang
sebelumnya telah tersimpan.
26. Operator Data Entry menginputkan data-data
pada space yang telah ditentukan dengan
benar.
27. Sistem akan mengontrol setiap entri yang
2013 8
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
masuk apakah sesuai dengan ketentuan.
28. Bila semua data yang dimasukan telah benar
maka Operator Data Entry dapat menyimpan
data tersebut dengan menekan tombol save.
29. 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
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
2013 9
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
penerima telah ditentukan.
Basic Flow 20. Untuk menambahkan, menghapus dan
mengedit data penerima maka dapat
dilakukan pada form ini dengan memilih
menu Record Data Penerima.
21. Sistem secara otomatis akan menampilkan
form tesebut yang berisi data penerima yang
sebelumnya telah tersimpan.
22. Operator Data Entry menginputkan data-data
pada space yang telah ditentukan dengan
benar.
23. Sistem akan mengontrol setiap entri yang
masuk apakah sesuai dengan ketentuan.
24. Bila semua data yang dimasukan telah benar
maka Operator Data Entry dapat menyimpan
data tersebut dengan menekan tombol save.
25. 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
2013 10
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 12. Untuk menambahkan, menghapus dan
mengedit data Karyawan maka dapat
dilakukan pada form ini dengan memilih
menu Record Data Karyawan.
13. Sistem secara otomatis akan menampilkan
form tesebut.
14. Operator Data Entry menginputkan data-data
pada space yang telah ditentukan dengan
benar.
15. Sistem akan mengontrol setiap entri yang
masuk apakah sesuai dengan ketentuan.
16. Bila semua data yang dimasukan telah benar
maka Operator Data Entry dapat menyimpan
data tersebut dengan menekan tombol save
(atau nama lain yang sejenis) .
16. Sistem akan menyimpan data Karyawan
tersebut.
Alternatif flow Jika dalam pengisian data karyawan tidak lengkap
maka sistem akan menampilkan pesan kesalahan
2013 11
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 28. Operator data entry harus login terlebih
dahulu.
29. 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
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 13. Untuk menambahkan, menghapus dan
mengedit data pembayaran (tagihan) maka
dapat dilakukan pada form ini dengan
memilih menu proses Tagihan.
14. Sistem secara otomatis akan menampilkan
2013 12
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
form tesebut.
15. Operator Data Entry menginputkan data-data
pada space yang telah ditentukan dengan
benar.
16. Sistem akan mengontrol setiap entri yang
masuk apakah sesuai dengan ketentuan.
17. Bila semua data yang dimasukan telah benar
maka Operator Data Entry dapat memproses
data tersebut dengan menekan tombol Ok
(atau nama lain yang sejenis) .
17. 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
lain yang sejenis) untuk mengosongkan form data
penerima.
Pre condition 30. Operator data entry harus login terlebih
dahulu.
31. 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
2013 13
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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.
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 32. Operator data entry harus login terlebih
dahulu.
33. 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
2013 14
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 19. Proses pembuatan laporan dilakukan
bertujuan untuk mengetahui jumlah tagihan
yang dapat dibuat dari beberapa transaksi,
dan sebagai bukti kepada pengirim.
20. Operator data entry mulai memproses
pembuatan laporan maka dapat dilakukan
pada form ini dengan memilih menu proses
Laporan.
21. Sistem akan meminta kepada operator data
entry untuk memasukan ketentuan atau
parameter yang akan menjadi batasan untuk
memproses data.
22. Sistem akan memproses data yang telah
diinputkan sesuai dengan ketentuan yang
berlaku.
23. 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 34. Operator data entry harus login terlebih
dahulu.
2013 15
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
35. 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 4. Proses pembuatan laporan dilakukan
bertujuan untuk mengetahui data-data
pengirim yang menggunkan jasa perusahaan
tersebut.
5. Operator data entry mulai memproses
pembuatan laporan maka dapat dilakukan
pada form ini dengan memilih menu proses
Laporan.
6. Sistem akan meminta kepada operator data
entry untuk memasukan ketentuan atau
parameter yang akan menjadi batasan untuk
memproses data.
7. Sistem akan memproses data yang telah
diinputkan sesuai dengan ketentuan yang
berlaku.
8. Setelah itu data yang telah di inputkan akan
disimpan untuk menjadi sumber informasi
2013 16
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
yang dibutuhkan untuk proses nantinya.
Alternatif flow Jika data pada saat memasukan data parameter tak
sesuai, maka proses harus diulang .
Pre condition 36. Operator data entry harus login terlebih
dahulu.
37. 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 5. Proses pembuatan laporan dilakukan
bertujuan untuk mengetahui data-data
pengirim yang menggunkan jasa perusahaan
tersebut.
6. Operator data entry mulai memproses
pembuatan laporan maka dapat dilakukan
pada form ini dengan memilih menu proses
Laporan.
7. Sistem akan meminta kepada operator data
entry untuk memasukan ketentuan atau
parameter yang akan menjadi batasan untuk
2013 17
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
memproses data.
8. Sistem akan memproses data yang telah
diinputkan sesuai dengan ketentuan yang
berlaku.
9. 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 38. Operator data entry harus login terlebih
dahulu.
39. 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 18
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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
2013 19
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
FormTransaksiPengiriman AddTransaksiPengiriman Transaksi
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 20
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Data_UserProsesLogin
KoneksiDatabase
FormLogin
MainForm
FormDataPenerima
FormLaporanPenerima
FormDataPengirim
FormLaporanPengirim
FormProsesTagihan
FormLaporanTagihan
FormDataKaryawan
FormTransaksiPengiriman
FormLaporanTransaksi
AddEditDataPenerima
ProsesLaporanPeneri
ma
AddEditDataPengirim
ProsesLaporanPengiri
m
ProsesTagihan
ProsesLaporanTagihan
AddEditDataKaryawan
AddTransaksiPengirim
an
ProsesLaporanTransak
si
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()
2013 21
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
getResourceBundle()
FormLogin <<Komponen
Tampilan Form>>
FormLogin()
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 FormDataPenerima(frame :
2013 22
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Tampilan Form>> JFrame)
CreateTable()
reloadRecord(scrSQL : string)
reloadRecord()
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()
2013 23
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
KoneksiDatabase()
Dispose()
Karyawan KodeKaryawan
NamaKaryawan
TglLahir
Alamat
Kota
NoTelpon
KontakPerson
Simpan()
Update()
SelectData()
Cetak()
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
SelectData()
Cetak()
2013 24
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Biaya
NamaKurir
FormProsesTagihan <<Komponen
Tampilan Form>>
FormProsesPenagihan(frame :
JFrame)
tambahListener()
tampilNoTagihan()
tampilDataKeTabel()
Close()
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 FormLapPengirim()
2013 25
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Tampilan Form>> KoneksiDatabase()
TampilkankeTabel()
Close()
ProsesLaporanPengirim InputKriteria()
KoneksiDatabase()
TambahListerner()
ProsesSelect()
Cetak()
getData()
FormLaporanTransaksi <<Komponen
Tampilan Form>>
FormLapTransaksi()
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 26
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 4 th,
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
2013 1
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 Sistem Informasi
12 87007 Team Dosen
Abstract Kompetensi
Memahami kebutuhan sistem Menentukan kebutuhan teknik dan
2013 2
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
menganalisa kebutuhan
2013 3
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 4
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Sequence Diagram untuk Use Case Transaksi Pengiriman
Gambar 3. Sequence diagram use case transaksi pengiriman
2013 5
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Sequence Diagram untuk Use Case Input Data Pengirim
Gambar 4. Sequence diagram use case input data pengirim
2013 6
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Sequence Diagram untuk Use Case Input Data Penerima
Gambar 5. Sequence diagram use case input data penerima
2013 7
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Sequence Diagram untuk Use Case Input Data Karyawan
Gambar 6. Sequence diagram use case input data karyawan
2013 8
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Sequence Diagram untuk Use Case Proses Tagihan
Gambar 7. Sequence diagram use case proses tagihan
2013 9
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Sequence Diagram untuk Use Case Laporan Transaksi
Gambar 8. Sequence diagram use case laporan transaksi
2013 10
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Sequence Diagram untuk Use Case Laporan Pengirim
2013 11
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Gambar 9. Sequence diagram use case laporan pengirim
Sequence Diagram untuk Use Case Laporan Penerima
2013 12
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Gambar 9. Sequence diagram use case laporan penerima
2013 13
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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
2013 14
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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.
State Machine Diagram Pengirim
Gambar 11 State machine diagram pengirim
2013 15
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
State Machine Diagram Tagihan
Gambar 12. State machine diagram tagihan
2013 16
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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,
2013 17
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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.
Diagram Activity untuk Aplikasi Pengiriman Barang
Gambar 13. Diagram Activity untuk Aplikasi Pengiriman Barang
2013 18
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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.
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
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.
Mengandung class-class translasi
Membuat statement sql untuk mengakses layer
Data Access
Mengandung SQL umum untuk akses data
seperti DARetrieve (Select) dan DAQuery
Busi
ness
Rul
e
Sevi
ce
BRS
VC.
DL
L
Data
Tran
slati
on
Serv
ice
DTS
VC.
DLL
Data
Acce
ss
Serv
ice
DAS
VC.
DLL
2013 19
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
operation yaitu :
40. DARetrieve akan membuat connection string dan menjalankan sebuah query Select.
41. DAQuery akan menjalanakan semua tipe query yang lain (Delete, Update dn Insert).
Diagram Component Sebuah Sistem
Gambar 14. Diagram component sebuah system
Deployment Diagram
Deployment diagram menyediakan gambaran bagaimana sistem secara fisik akan terlihat. Sistem
2013 20
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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.
Penerapan Diagram Deployment
Gambar 3.27. Penerapan Deployment Diagram pada Sistem
&&&&&&
2013 21
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 4 th,
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
2013 22
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
2013 1
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 Sistem Informasi
13 87007 Team Dosen
Abstract Kompetensi
Memahami kebutuhan sistem Menentukan kebutuhan teknik dan
2013 2
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
menganalisa kebutuhan
2013 3
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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:
42. Network intensiveness,
43. Concurrency,
44. Unpredicable load,
45. Performance,
46. Availability,
47. Data driven,
48. Content sensitive,
49. Continuous evolution,
50. Immediacy,
51. Security,
52. Aesthetics,
Sedangkan yang termasuk ke dalam kategori aplikasi yang sering ditemui di dalam kerja
rekayasa web adalah:
18. Informational,
19. Download,
20. Customizeable,
21. Interaction,
22. User input,
23. Transaction-oriented,
24. Service-oriented,
25. Portal,
26. Database access,
27. Data warehouse.
2013 4
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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:
21. Business Analysis menetapkan konteks bisnis / organisasi untuk web application. Dengan
tambahan, :
1. stakeholder telah dikenali,
2. perubahan yang mungkin dalam lingkungan bisnis atau syarat yang harus dipenuhi
telah diprediksi, dan
3. integrasi antara web application dan aplikasi bisnis lainnya, database, dan fungsi telah
dikenali.
4. Formulation syarat-syarat aktivitas yang harus dipenuhi untuk semua stakeholder.
22. Planning, Rencana proyek untuk pengembangan applikasi web yang telah dibuat/telah
ada . Rencana tersebut terdiri dari :
1. task definition dan
2. jadwal kerja untuk jangka waktu relative pendek.
23. Modeling, Analisis rekayasa perangkat lunak konvensional dan tugas mendisain yang
2013 5
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
disesuaikan untuk perkembangan web application, digabungkan, dan kemudian
dimasukkan ke dalam aktivitas modeling rekayasa web.
24. Construction, Menggunakan alat dan teknologi rekayasa web untuk membangun aplikasi
web yang telah dirancang.
25. 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 :
42. Kebutuhan bisnis,
43. Tujuan dan kriteria keberhasilan proyek,
44. Kategorisasi end-user,
45. fitur dan fungsi utama, dan
2013 6
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
46. tingkat interoperabilitas dengan aplikasi lainnya
Kelompok Web Engineering (Web Engineering Group)
34. Kelompok web engineering terdiri dari anggota kelompok yang punya spesialisasi teknis
dan non-teknis yang memungkinkan kelompok ini memiliki otoritas untuk melakukan
pengambilan keputusan.
35. Manajemen proyek dibutuhkan selama web engineering, perbedaannya adalah masa
tugas yang lebih singkat, dan boleh jadi otoritasnya tidak meliputi keseluruhan sistem
informasi organisasi.
Requirements analysis untuk WebApps
Requirements analysis untuk WebApps mencakup tiga tugas utama:
27. formulation,
28. requirements gathering, dan
29. 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 :
30. Hirarki User. Kategori dari end-users yang berinteraksi dengan WebApp diidentifikasi
sebagai bagian dari tugas-tugas formulation dan equirements gathering.
31. 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.
32. 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
2013 7
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
diantara user dan WebApp.
33. 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:
34. Comprehensible (Lengkap), Semua stakeholder mengerti tujuan dari package.
35. Cohesive, fungsi alamat package yang berhubungan dekat satu dengan lainnya.
36. Loosely coupled, fungsi atau kelas dalam package bekerjasama satu dengan
lainnya, tetapi kerjasama ketergantungan antar package dijaga tetap minimum.
37. 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:
26. Use-cases, Adalah elemen yang dominan dari interaction model untuk web application.
2013 8
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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.
27. 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.
28. 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.
29. 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:
17. User dapat mengamati fungsionalitas yang dikirimkan web application kepada end-user,
18. 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 :
2013 9
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
18. 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.
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.
19. 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 :
2013 10
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Gambar 2 Quality Requirement Tree (Pressman: 561)
Offut [OFF02] dalam pressman: 561, memperluas lima kualitas utama atribut yang dicatat pada
gambar di atas dengan menambah atribut yang mengikutinya, yaitu:
24. Security,
25. Availability,
26. Scalability,
27. 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:
9. Simplicity,
10. Consistency,
2013 11
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
11. Identity,
12. Robustness,
13. Navigability,
14. Visual Appeal,
15. Compatibility.
&&&&&&&&
2013 12
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 4 th,
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
2013 1
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 Sistem Informasi
12 87007 Team Dosen
Abstract Kompetensi
Memahami kebutuhan sistem Menentukan kebutuhan teknik dan
2013 2
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
menganalisa kebutuhan
2013 3
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 4
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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,1
1,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
NoTransaksi
TglTransaksi
BeratTransaksi
<pi> A9
D
VA20
<M>
Pengirim
KdPengirim
NamaPengirim
AlamatPengirim
KdPosPengirim
TlpPengirim
FaksPengirim
KPPengirim
<pi> VA20
VA50
VA100
VA10
VA20
VA20
VA20
<M>
Karyawan
Kdkaryawan
NamaKaryawan
TglLahirKaryawan
Sex
Status
Alamat
KPKaryawan
<pi> A9
VA20
D
VA9
VA20
VA50
VA20
<M>
Tagihan
NoTagihan
TglTagihan
<pi> A9
D
<M>
Kota
KdKota
NamaKota
<pi> A9
VA20
<M>
Jenis
KdJenis
NamaJenis
<pi> A9
VA20
<M>
Sifat
KdSifat
NamaSifat
BiayaSifat
<pi> A9
VA20
DC12,2
<M>
Penerima
KdPenerima
NamaPenerima
AlamatPenerima
KdPosPenerima
TlpPenerima
FaksPenerima
KPPenerima
<pi> A9
VA30
VA100
VA9
VA9
VA9
VA20
<M>
Gambar 1. Conceptual data model (cdm)
2013 5
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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
28. Transaksi
29. Penerima
2013 6
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
30. Pengirim
31. Karyawan
32. Tagihan
33. Sifat
34. Jenis
35. Kota
3NF
Transaksi
2013 7
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Tagihan
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
NoTransaksi
KdJenis
KdPenerima
Kdkaryawan
KdSifat
KdKota
NoTagihan
KdPengirim
TglTransaksi
BeratTransaksi
CHAR(9)
CHAR(9)
CHAR(9)
CHAR(9)
CHAR(9)
CHAR(9)
CHAR(9)
CHAR(9)
DATE
VARCHAR(20)
<pk>
<fk5>
<fk4>
<fk2>
<fk6>
<fk7>
<fk3>
<fk1>
Pengirim
KdPengirim
KdKota
NamaPengirim
AlamatPengirim
KdPosPengirim
TlpPengirim
FaksPengirim
KPPengirim
CHAR(9)
CHAR(9)
VARCHAR(30)
VARCHAR(100)
VARCHAR(9)
VARCHAR(20)
VARCHAR(20)
VARCHAR(20)
<pk>
<fk>
Karyawan
Kdkaryawan
KdKota
NamaKaryawan
TglLahirKaryawan
Sex
Status
Alamat
KPKaryawan
CHAR(9)
CHAR(9)
VARCHAR(20)
DATE
VARCHAR(9)
VARCHAR(20)
VARCHAR(50)
VARCHAR(20)
<pk>
<fk>
Tagihan
NoTagihan
KdPengirim
TglTagihan
CHAR(9)
CHAR(9)
DATE
<pk>
<fk>
Kota
KdKota
NamaKota
CHAR(9)
VARCHAR(20)
<pk>
Jenis
KdJenis
NamaJenis
CHAR(9)
VARCHAR(20)
<pk>
Sifat
KdSifat
NamaSifat
BiayaSifat
CHAR(9)
VARCHAR(20)
NUMBER(12,2)
<pk>
Penerima
KdPenerima
KdKota
NamaPenerima
AlamatPenerima
KdPosPenerima
TlpPenerima
FaksPenerima
KPPenerima
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
2013 8
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Gambar 3. Perancangan struktur menu program keseluruhan
Struktur Menu Utama
Gambar 4. Perancangan struktur menu utama
Struktur Menu File
Gambar 5. Perancangan struktur menu file
Struktur Menu Record
2013 9
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Gambar 6. Perancangan struktur menu record
Struktur Menu Proccess
Gambar 7. Perancangan struktur menu proccess
Struktur Menu Report
Gambar 8. Perancangan struktur menu report
Struktur Menu Help
Gambar 9. Perancangan struktur menu help
Struktur Menu Utility
2013 10
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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
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,
2013 11
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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 12
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 :
26. Kode Pengirim, berisi kode dari pengirim.
27. Nama Pengirim, menjelaskan nama pengirim dengan jelas.
28. Alamat, untuk mengetahui data alamat pengirim dengan benar.
29. 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 13
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
53. 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 :
47. Kode Penerima, berisi kode dari penerima.
48. Nama Penerima, menjelaskan nama penerima dengan jelas.
49. Alamat, untuk mengetahui data alamat penerima dengan benar.
50. 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 14
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 :
36.Kode Karyawan, berisi kode dari karyawan.
37.Nama Karyawan, menjelaskan nama karyawan dengan jelas.
38.Alamat, untuk mengetahui data alamat karyawan dengan benar.
2013 15
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
39.Telpon, untuk alat komunikasi dengan karyawan.
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 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
2013 16
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
data juga hasil data yang sudah masuk dari sebuah proses transaksi pengiriman.
Form ini juga menyediakan tombol simpan, buat baru dan hapus untuk mengkoreksi
atau menghilangkan data yang sudah ada
Gambar 19. Tampilan form data transaksi
54. 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 17
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 18
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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
2013 19
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
membrikan pilhan kepada pelanggan (pengirim) untuk apat memilih sifat pengiriman
yang dipilih sesuai dengan kebutuhan.
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 20
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 21
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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 22
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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.
30. About
Merupakan menu bantuan yang memberikan informasi tentang penjelasan
pemanfaatan aplikasi tersebut.
2013 23
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Gambar 33. Tampilan Form Bantuan (Help) untuk About
31. Content
Merupakan menu bantuan yang memberikan informasi tentang penjelasan
beberapa hal.
38. Tata cara konfigurasi dan install
39. Tentang Aplikasi Delivery Sistem version 1.1
40. Tentang pembuat aplikasi (Programer).
41. Sedikit penjelasan tentang bahasa pemrograman Java
Gambar 34. Tampilan form bantuan (help) untuk content
55. Perancangan layar Output
56. Laporan Data Transaksi
2013 24
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Gambar 3.62. Rancangan output data transaksi
57. 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 25
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team 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
2013 26
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
Gambar 39. Rancangan output data pengirim
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
2013 27
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
kedalam sintak beberapa bahasa pemrograman.
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
2013 28
Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning
Team Dosen http://www.mercubuana.ac.id
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