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



dan Object sistem, memahami metodhologi pengembangan sistem, mengenal UML

2013 3



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



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



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



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



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



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



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



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



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



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



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



MODUL PERKULIAHAN





02 87007 Team Dosen

Abstract Kompetensi

Memahami awal dari project dan Memahami hubungan sistem informasi

2013 2



memahami data dan kebutuhan bisnis dan pengelolaan data

2013 3



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



(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



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



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



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



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




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



2013 10



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



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




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



3. Menghapus Customer

4. Delete from Customer where CustomerNo = ‘007’

Daftar Pustaka




McGraw Hill, 1992






2013 1



MODUL PERKULIAHAN





03 87007 Team Dosen

Abstract Kompetensi

Mengidentifikasi ukuran project, Memahami Managemen Project

2013 2



membuat dan mengelola rencana kerja pelaksanaan project

2013 3



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



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



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



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



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



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



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



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



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



Daftar Pustaka




McGraw Hill, 1992






2013 1



MODUL PERKULIAHAN





04 87007 Team Dosen

Abstract Kompetensi

Memahami kebutuhan sistem Menentukan kebutuhan teknik dan

2013 2



menganalisa kebutuhan

2013 3



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



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



Gambar 1. Contoh Functional Requirement

2013 6



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



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



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



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



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



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



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



Daftar Pustaka




McGraw Hill, 1992






2013 1



MODUL PERKULIAHAN





05 87007 Team Dosen

Abstract Kompetensi


2013 2




2013 3



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



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



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



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



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



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



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



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



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



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



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



Daftar Pustaka



Henry C. Lucas Jr., The Analysis, Design and Implementation of Information Systems 4th,

McGraw Hill, 1992






2013 1



MODUL PERKULIAHAN





06 87007 Team Dosen

Abstract Kompetensi


2013 2




2013 3



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



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



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



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



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



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



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



Gambar 3. Notasi Use Case

2013 11



Gambar 4. Use Case Diagram

Gambar 5. Extend dan Include Relationship.

2013 12



Gambar 6. Cara Identifikasi Use Case

Daftar Pustaka




McGraw Hill, 1992






2013 1



MODUL PERKULIAHAN





07 87007 Team Dosen

Abstract Kompetensi


2013 2




2013 3



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



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



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



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



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



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



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



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



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



&&&&&&&

Daftar Pustaka




McGraw Hill, 1992






2013 1



MODUL PERKULIAHAN





08 87007 Team Dosen

Abstract Kompetensi


2013 2




2013 3



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



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



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



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



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



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



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



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



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



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



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




McGraw Hill, 1992






2013 1



MODUL PERKULIAHAN





09 87007 Team Dosen

Abstract Kompetensi


2013 2




2013 3



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



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



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



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



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



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



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



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



Gambar 6 Diagram use case diagram

&&&&&&&&&

2013 12



Daftar Pustaka




McGraw Hill, 1992






2013 1



MODUL PERKULIAHAN





10 87007 Team Dosen

Abstract Kompetensi


2013 2




2013 3



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



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


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



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


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



2013 6





berlaku.




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.


dahulu.


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


Brief

Description

Walaupun sebenarnya data penerima secara tidak



keterangan yang lebih terperinci data penerima



atau mengedit data penerima.

Exception Data karyawan yang akan dimasukan berisi biodata

para pegawai yang bekerja di perusahaan tersebut.


atau mengedit biodata karyawan yang

bekerja di peerusahaan .

2013 7








berlaku.




Alternatif flow Jika data penerima sebelumnya sudah ada maka





dahulu.


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


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



atau mengedit data yang telah tersimpan

untuk menambahkan rincian informasi .


2013 8







berlaku.




Alternatif flow Jika data pegawai sebelumnya sudah ada maka





dahulu.


sesuai.

Post condition Data karyawan telah tersimpan

Tabel 8 Spesifikasi naratif untuk use case proses tagihan tingkat analisis

Use case name Proses Tagihan


Brief

Description


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 .



2013 9



pemrosesan tagihan.

17. Sistem akan meminta kepada operator data

entry untuk memasukan ketentuan atau

parameter yang akan menjadi batasan untuk

memproses data.



berlaku.




Alternatif flow Jika penerima tersebut merupakan member maka

proses pembayaran akan dibuat tagihan untuk satu

periode, dan bila bukan maka pembayaran dapat

langsung dilakukan.


dahulu.


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


Brief

Description


melakukan pembuatan laporan, data yang didapat

dari proses transaksi yang terjadi.

Exception Data transaksi yang akan dimasukan sudah tersedia


Basic Flow 7. Proses pembuatan laporan dilakukan

bertujuan untuk mengetahui seberapa

2013 10



banyak proses terjadinya transaksi dan

pendapatan yang di hasilkan



pemrosesan pembuatan laporan




memproses data.



berlaku.




Alternatif flow Jika data pada saat memasukan data parameter tak

sesuai, maka proses harus diulang .


dahulu.


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


Brief

Description



dari proses transaksi yang telah terjadi. Kemudian

data tersebut akan dibuat sebuah tagihan secara

berkala

2013 11



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.







memproses data.



berlaku.







dahulu.


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




Brief

Description


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


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







memproses data.



berlaku.






2013 13




dahulu.


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


Brief

Description


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


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



sesuai dengan ketentuan yang berlaku.

Setelah itu data yang telah di inputkan akan

disimpan untuk menjadi sumber informasi yang

dibutuhkan untuk proses nantinya.




dahulu.


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



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



Gambar 7 Class Diagram

2013 17



Daftar Pustaka




McGraw Hill, 1992






2013 1



MODUL PERKULIAHAN





11 87007 Team Dosen

Abstract Kompetensi


2013 2




2013 3



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



:

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


Brief

Description

Operator Data Entry ingin Login terhadap sistem

dengan menginputkan data user name dan

2013 5



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


2013 6



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



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


Brief

Description

Walaupun sebenarnya data pengirim secara tidak



keterangan yang lebih terperinci data pengirim



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.


form tesebut yang berisi data pengirim yang

sebelumnya telah tersimpan.



benar.


2013 8







29. Sistem akan menyimpan data pengirim

tersebut.

Alternatif flow Jika dalam pengisian data transaksi tidak lengkap





lain yang sejenis) untuk mengosongkan form data

penerima.


Data pengirim yang akan dimasukan sudah tersedia

dan sesuai.



berubah.

Tabel 4 Spesifikasi naratif untuk use case input data penerima tingkat perancangan

Use case name Input Data Penerima


Brief

Description

Walaupun sebenarnya data penerima secara tidak



keterangan yang lebih terperinci data penerima



atau mengedit data penerima.

Exception Data untuk keterangan yang dibutuhkan untuk data

2013 9



penerima telah ditentukan.

Basic Flow 20. Untuk menambahkan, menghapus dan

mengedit data penerima maka dapat


menu Record Data Penerima.


form tesebut yang berisi data penerima yang

sebelumnya telah tersimpan.



benar.






25. Sistem akan menyimpan data penerima

tersebut.

Alternatif flow Jika dalam pengisian data penerima tidak lengkap






penerima.


Data penerima yang akan dimasukan sudah tersedia

dan sesuai.



2013 10



berubah.

Tabel 5 Spesifikasi naratif untuk use case input data karyawan tingkat perancangan

Use case name Input Data Karyawan


Brief

Description


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.


mengedit data Karyawan maka dapat


menu Record Data Karyawan.


form tesebut.



benar.





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


2013 11







penerima.


dahulu.


sesuai.

Post condition Data karyawan telah tersimpan

Tabel 6 Spesifikasi Naratif untuk Use Case Proses Tagihan (Pembayaran) Tingkat Perancangan

Use case name Proses Tagihan


Brief

Description


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.


mengedit data pembayaran (tagihan) maka

dapat dilakukan pada form ini dengan

memilih menu proses Tagihan.


2013 12



form tesebut.



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



mengisi informasi yang dibutuhkan terlebih dahulu.



penerima.


dahulu.


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


Brief

Description



2013 13



dari proses transaksi yang terjadi.



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



memproses data.

Sistem akan memproses data yang telah


berlaku.

Setelah itu data yang telah di inputkan akan






dahulu.


sesuai.

Post condition Data laporan siap cetak

Tabel 8 Spesifikasi naratif untuk use case laporan data tagihan tingkat perancangan

2013 14



Use case name Laporan Data Tagihan


Brief

Description



dari proses transaksi yang terjadi yang kemudian

akan dibuat tagihan berdasarkan kode pengirim .




bertujuan untuk mengetahui jumlah tagihan

yang dapat dibuat dari beberapa transaksi,

dan sebagai bukti kepada pengirim.

20. Operator data entry mulai memproses



Laporan.




memproses data.



berlaku.







dahulu.

2013 15




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


Brief

Description




akan dibuat laporan berdasarkan kode pengirim .




bertujuan untuk mengetahui data-data

pengirim yang menggunkan jasa perusahaan

tersebut.




Laporan.




memproses data.



berlaku.



2013 16







dahulu.


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


Brief

Description




akan dibuat laporan berdasarkan kode penerima.




bertujuan untuk mengetahui data-data

pengirim yang menggunkan jasa perusahaan

tersebut.




Laporan.




2013 17



memproses data.



berlaku.







dahulu.


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



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



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



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



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



Tampilan Form>> JFrame)

CreateTable()


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()

KoneksiDatabase()

Close()

AddEditDataKaryawan <<Komponen

Tampilan Form>>

Add_Edit_Data_Karyawan(fra

me : JFrame)

listener_tombol()

tampilKode()

clearFields()

2013 23



KoneksiDatabase()

Dispose()

Karyawan KodeKaryawan

NamaKaryawan

TglLahir

Alamat

Kota

NoTelpon

KontakPerson

Simpan()

Update()

SelectData()

Cetak()

FormTransaksiPengiriman <<Komponen

Tampilan Form>>

FormTransaksiPengiriman(fra

me : JFrame)

CreateTable()


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



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



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



Daftar Pustaka




McGraw Hill, 1992






2013 1



MODUL PERKULIAHAN





12 87007 Team Dosen

Abstract Kompetensi


2013 2




2013 3



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



Sequence Diagram untuk Use Case Transaksi Pengiriman

Gambar 3. Sequence diagram use case transaksi pengiriman

2013 5



Sequence Diagram untuk Use Case Input Data Pengirim

Gambar 4. Sequence diagram use case input data pengirim

2013 6



Sequence Diagram untuk Use Case Input Data Penerima

Gambar 5. Sequence diagram use case input data penerima

2013 7



Sequence Diagram untuk Use Case Input Data Karyawan

Gambar 6. Sequence diagram use case input data karyawan

2013 8



Sequence Diagram untuk Use Case Proses Tagihan

Gambar 7. Sequence diagram use case proses tagihan

2013 9



Sequence Diagram untuk Use Case Laporan Transaksi

Gambar 8. Sequence diagram use case laporan transaksi

2013 10



Sequence Diagram untuk Use Case Laporan Pengirim

2013 11



Gambar 9. Sequence diagram use case laporan pengirim

Sequence Diagram untuk Use Case Laporan Penerima

2013 12



Gambar 9. Sequence diagram use case laporan penerima

2013 13



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



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



State Machine Diagram Tagihan

Gambar 12. State machine diagram tagihan

2013 16



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



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



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



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



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



Daftar Pustaka




McGraw Hill, 1992






2013 22



2013 1



MODUL PERKULIAHAN





13 87007 Team Dosen

Abstract Kompetensi


2013 2




2013 3



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



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



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



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



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



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



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



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



11. Identity,

12. Robustness,

13. Navigability,

14. Visual Appeal,

15. Compatibility.

&&&&&&&&

2013 12



Daftar Pustaka




McGraw Hill, 1992






2013 1



MODUL PERKULIAHAN





12 87007 Team Dosen

Abstract Kompetensi


2013 2




2013 3



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



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



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



30. Pengirim

31. Karyawan

32. Tagihan

33. Sifat

34. Jenis

35. Kota

3NF

Transaksi

2013 7



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



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



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



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



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



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



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.




2013 14



Gambar 15. Tampilan form data penerima

Tampilan Form Tambah Data Penerima


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



39.Telpon, untuk alat komunikasi dengan karyawan.




Gambar 17. Tampilan form data karyawan

Tampilan Form Tambah Data Karyawan


form ini juga dapat digunakan untuk menambahkan data karyawan diantaranya :

Gambar 18. Tampilan form tambah data karyawan

Tampilan Form Data Transaksi Pengiriman


2013 16



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



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



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



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



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


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



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


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



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



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



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



Gambar 37. Rancangan output data karyawan

Per kode karyawan

Laporan Data Penerima

Gambar 38. Rancangan output data penerima

Laporan Data Pengirim

2013 26



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



kedalam sintak beberapa bahasa pemrograman.

Daftar Pustaka



Henry C. Lucas Jr., The Analysis, Design and Implementation of Information Systems 4th,

McGraw Hill, 1992

2013 28








modul perkuliahan analisa perancangan...

Documents