modul perkuliahan analisa perancangan...

MODUL PERKULIAHAN

ANALISA

PERANCANGAN BERORIENTASI OBJEK

Modul Standar untuk digunakan dalam Perkuliahan di Universitas Mercu Buana

Fakultas Program Studi Tatap Muka Kode MK Disusun Oleh

Ilmu Komputer Teknik Informatika

01 87016 Tim Dosen

Abstract Kompetensi

SDLC, RAD, Design Tersturktur, Class dan Object

Memahami siklus pengembangan sistem, memahami metodhologi pengembangan sistem, mengenal UML

2013 2 Analisa Perancangan Berorientasi Objek Modul 01 Pusat Bahan Ajar dan eLearning

Tim Dosen http://www.mercubuana.ac.id

Karakteristik Dasar Sistem Object Oriented

1. Pendahuluan

OOSAD (Object Oriented System Analysis and Design) merupakan paradigma

analisa dan perancangan sistem yang titik perhatiannya adalah penggambaran struktur dan

tingkah laku Teknik Informatika yang meliputi data dan process. Secara statis struktur data

dan process akan menunjukkan hubungan antar bagian dari sistem, sedangkan secara

dinamis menunjukkan bagaimana bagian-bagian sistem tersebut akan berinteraksi antara

satu dengan lainnya. Untuk penggambaran tersebut diperlukan pemahaman dasar dari

class, object, method, message, encapsulation, information hiding, inheritance,

polymorphism, dan dynamic binding.

1.1. Class dan Object

CLASS adalah template/cetakan yang digunakan untuk mendefinisikan suatu

instance/contoh kejadian yang disebut object. Object adalah contoh kejadian dari class.

setiap object pasti akan berasosiasi tepat dengan satu class.

Setiap object memiliki attributes yang berisikan informasi mengenai object tersebut. State

dari sebuah object ditentukan oleh nilai dari attributes dan relationshipnya pada suatu waktu

tertentu.

Setiap object juga memiliki behaviour yang menspesifikasikan apa yang bisan dilakukan

sebuah object.



1.2. Methods dan Messages

Method merupakan implementasi dari behaviour(kelakukan) sebuah object. Method adalan sebuah

action(tindakan) yang dapat dilakukan oleh object. Method dapat dianalogikan dengan fungsi

sebagaimana terdapat didalam bahasa C. Message merupakan informasi yang dikirimkan ke Object

yang akan menjadi pemicu dari dilakukannya sebuah tindakan.

1.3. Encapsulation dan Information Hiding

Pemikiran mengenai encapsulation dan Information hiding sudah ada sejak jaman

dahulu kala. Encapsulation adalah kombinasi dari proses dan data yang diletakkan didalam

sebuah class. Didalam OOSAD yang dimaksudkan dengan

Encapsulation adalah meletakkan attribute dan behaviour kedalam sebuah object yang

dispesifikasikan didalam class. didalam notasi yang digunakan UML 2.0 attribute diletakkan

pada bagian atas sedangkan behaviour diletakkan pada bagian bawah dari kotak.

Information hiding adalah sebuah cara berpikir dimana informasi yang diperlukan oleh

penggunalah yang akan ditampilkan sedangkan yang tidak diperlukan tidak usah

ditampilkan/diberikan. Konsekuensinya yang dapat diakses adalah bagian dari object yang

digunakan untuk menerima perintah dan memberikan informasi kepada pengguna object

tersebut. Sehingga object diperlakukan seperti sebuah kotak hitam.

The only information that an object needs to know is the set of operations, or methods, that

other objects can perform and what messages need to be sent to trigger them.



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.



Pada contoh dibawah ini Person adalah abstract class sedangkan Doctor dan Patient

merupakan concrete class

1.5. Polymorphism dan Dynamic Binding

Polymorphism artinya message yang sama diinterpretasikan/memiliki arti/bentuk yang

berbeda. Sebagai contoh jika kita beri perintah draw kepada object segi empat, segi tiga,

dan lingkaran akan menjalankan perintah yang berbeda. Dibawah ini adalah contoh

polymorphism :

int kali(int a, int b);

int kali(int a, int b, int c);

maka fungsi mana yang akan dijalankan tergantung kepada argumen yang disertakan.

Polymorphism dapat terlaksanya karena adanya dynamic binding. Dynamic, atau, late

binding adalah teknik/cara penundaan penentuan jenis object sampai pada saat run-time.

Artinya method mana yang akan dijalankan ditunda sampai system/program berjalan.

Kontrasnya adalah static binding dimana setiap methods sudah ditentukan pada saat

kompilasi.



2. UML Versi 2.0

UML (Unified Modeling Language) versi 2 mendefinisikan sehimpunan notasi yang terdiri

dari 14 technique pembuatan diagram yang digunakan untuk memodelkan sistem. Diagram

dikelompokkan menjadi 2 yaitu :

1. Structure Modelling Diagram yang digunakan untuk memodelkan struktur sistem.

2. Behaviour Modelling Diagram yang digunakan memodelkan tingkah laku sistem.

2.1. Structure Diagram

Structure diagram menggambarkan cara untuk merepresentasikan hubungan static dan data

yang terdapat didalam Teknik Informatika. Adapun diagram yang digunakan adalah :

1. Class : relationship between classes

2. Object : Relationships between objects

3. Package : Group UML elements together to form higher level constructs

4. Deployment : Shows the physical architecture and software components of system

5. Component : Physical relationships among software components

6. Composite Structure : Illustrates internal structure of a class



2.2. Behaviour Diagram

Behaviour diagram menggambarkan aspek dinamis dari sistem, yaitu bagaimana bekerjanya

sistem. Adapun diagram yang digunakan adalah :

a. Activity : Illustrates business workflows.

b. Sequence : Time-based ordering Behavior of objects activities in a use case.

c. Communication : Communication among a set of collaborating objects of an activity.

d. Interaction Overview : Overview of flow of control of a process

e. Timing Diagram : Portray the interaction between objects along a time axis.

f. Behavioral State Machine : Examines behavior of one class.

g. Protocol State Machine : Shows dependencies of different interfaces of a class

h. Use-Case : Captures business requirements and Illustrates interaction between

system and environment

2.3. Extension Mechanism

Extension Mechanism memungkinkan perluasan model yang digunakan, karena boleh jadi

model didalam suatu aktifitas OOSAD ada notasi lain yang diperlukan. Penambahan notasi

disebut extension mechanism :

a. Stereotypes : Gives ability to incrementally extend UML

b. Tagged Values : Add new properties to base elements

c. Constraints : Place restrictions on use of model elements

d. Profiles : Group model elements into a package

3. Object Oriented Systems Analysis and Design

Pendekatan OO dapat menggunakan methodology apapun, termasuk yang terstruktur,

tetapi umumnya lebih berhubungan dengan methodology yang bersifat RAD. Yang harus

diperhatikan didalam OOSAD adalah pemodelan dunia nyata berarti memodelkan : DATA

DAN PROSES yang susah dipisahkan. UML bersifat use-case drive, architecture-centric,

iterative dan incremental.

3.1. Use-Case Drive



Perangkat pemodelan utamanya adalah Use Case yang digunakan untuk menjelaskan

tingkah laku dari sistem

3.2. Architecture Centric

Architecture software yang akan dibuat haruslah mengikuti dan menghasilkan standard yang

meliputi spesifikasi, construction, dan documentation.

3.3. Itterative dan Incremental

Pengembangan dilakukan secara itterative dan incremental. Dimana setiap pengulangan

akan mendekatkan produk ke spesifikasi dari pengguna akhir.

3.4. Unified Process

Unified process mengunakan methodolgy yang secara khusus memetakan bagaimana

menggunakan perangkat methodoly yang dimiliki oleh UML. Jika UML memiliki struktur

untuk menjelaskan hubungan struktural dan behaviour dari sebuah Teknik Informatika.

RUPS menyediakan dukungan methodology penggunaan notasi UML.

Unified processadalah proses pengembangan sistem yang dijelaskan melalui tahapan-

tahapan dan workflows. Tahapannya (Phases) adalah :

1. Inception. Merupakan tahapan perencanaan. Business Case dibuat dalam tahapan

ini.

2. Elaboration. Mrupakan tahapan dimana dilakukan analisa dan perancangan sistem

secara mendalam. Pada tahapan ini dilakukan pembelajaran mengenai bagaimana

sistem yang akan dibuat. vision document, penyelesaian business case, revisi

penilaian resiko, dan menyelesaikan project plan secara terinci agar pihak-pihak

yang berkepentingan dapat setuju dengan pembuatan sistem yang final.

Deliverablesnya meliputi notasi-notasi struktur dan behaviour, executable of baseline

version. Baseline harus ditetapkan dengan baik pada tahapn ini karena merupakan

dasar bagi pekerjaan lanjutan untuk membuat sistem yang jadi.

3. Construction. Tahapan ini terfokus pada pemrogram dan pekerjaan teknis untuk

membuat sistem. Berarti merupakan implemention workflows. Disamping itu

requirement, analysis, dan design workflows juga dilibatkan dalam tahapan ini.



Version control dari configuration and change management, menjadi sangat penting

dalam tahapan ini. Deliverables yang utama adalah versi alpha maupun beta dari

sistem yang dibuat.

4. Transition. Tahapan ini merupakan pemasangan dari sistem yang sudah jadi berarti

deliverablesnya adalah sistem yang sudah jadi, berikut dokumentasi-dokumentasi

pendukungtermasuk didalamnya manuals, support plan, dan upgrading plan.

Figure 2-7 The Unified Process



Sedangkan workflowsnya meliputi :

1. Business modelling digunakan untuk menemukan permasalahan dan dapat

mengidentifikasi projects yang mungkin dikerjakan dalam organisasi.

2. Requirements digunakan untuk melakukan elisitasi kebutuhab baik secara fungsional

dan nonfungsional.

3. Analysis merupakan pekerjaan yang meliputi analisis dari problem/business domain.

4. Design meupakan pekerjaan yang mentransformasikan analysis model kedalam

bentuk yang daat digunakan untuk implementasi sistem yaitu : design model. Design

model merupakan peningkatan yang lebih terinci dari analysis model dengan

penambahan classes/object dan model-model lain yang akan digunakan untuk

pembuatan sistem yang nantinya akan dibangun.

5. Implementation merupakan pekerjaan pembangunan sistem. Aktifitas yang

dilakukan, sebagai contoh, adalah pemrograman.

6. Test atau pengujian bertujuan agar produk yang dibuat memenuhi kriteria kualitas

yang telah ditentukan untuk sistem yang dibuat.

7. Deployment. Bagian ini berhubungan dengan tahapan transisi pada RUP.

Aktifitasnya meliputi packaging, distribution , beta testing, dan pada akhirnya adalah

sistem yang telah jadi.

8. Project management. Merupakan cross-phase flow. Contoh dari aktifitas yang

dilakukan dalam tahap ini adalah : risk identification & management, scope

management, time estimation, cost estimation, dan tracking progress.

9. Configuration and change management bertujuan untuk menjejaki sampai sejauh

mana sistem yang sekarang sedang dibuat.

10. Environment. Dalam pengembangan sistem sudah tentu bermacam-macam

perangkat digunakan. Environmental workflows adalah kelompok perkerjaan yang

berhubungan dengan penyediaan perangkat untuk pembuatan sistem.

Tahapan-tahapan dialam RUP membantu analis dalam mengembangkan Teknik

Informatika secara itterative dan incremental. Tahapan-tahapan tersebut

menjelaskan bagaimana Teknik Informatika berevolosi. Tergantung kepada tahapan

yang mana, tingkat aktivitas dalam setiap workflows akan bervariasi.



Daftar Pustaka

Alan Denis, Barbara Haley Wixon, David Tagerden, System Analys and Design : an Object –

Oriented Approach with UML 2.0, John Willey and Sons, 2005

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

McGraw Hill, 1992

Satzinger, Jackson, Burd, Object-Oriented Analysis and Design with the Unified Process,

Course Technology, 2005

Simon Bennet, Steve McRobb and Ray Farmer, Object-Oriented System Analysis and

Design Using UML, McGraw Hill, 2006

Wendy and Michael Boggs, UML with Rational Rose 2002, Sibex Inc., 2002

MODUL PERKULIAHAN

ANALISA





02 87016 Tim Dosen

Abstract Kompetensi

Memahami awal dari project dan memahami data

Memahami hubungan Teknik Informatika dan kebutuhan bisnis dan pengelolaan data



Determinancy dan Functional Dependency Determinancy digunakan untuk menentukan “ketergantungan” sebuah attribute didalam tabel. Sebuah attribute dinyatakan sebagai determinant (penentu) attribute yang lain jika satu nilai attribute tersebut berpasangan tepat dengan attribute yang lain Definisi : Dalam Satu relation R, attribute Y dikatakan tergantung fungsional kepada attribute X jika setiap nilai X didalam R tepat berasosiasi dengan satu nilai Y, dimana X dan Y mungkin composite

Perhatikan himpunan dibawah ini :

Notasi : R.X R.Y Contoh :

1. Pada Tabel Penduduk(NoKTP, Nama, …) : Penduduk.NoKTP Penduduk.Nama Satu Nama berpasangan dengan banyak NoKTP, tetapi satu NoKTP tepat berpasangan dengan satu nama. NoKTP dinyatakan sebagai determinan dari Nama, dan Nama dinyatakan tergantung fungsional kepada NoKTP.

2. Pada Tabel Matakuliah(KodeMK, NamaMK, SKS) :

Matakuliah.KodeMKMatakuliah.SKS Satu nilai SKS berpasangan dengan banyak KodeMK, tetapi satu KodeMK tepat berpasangan dengan satu nilai SKS. KodeMK dinyatakan sebagai determinan dari SKS, dan SKS dinyatakan tergantung fungsional kepada KodeMK.

3. Perhatikan latihan normalisasi yang diberikan pada contoh Invoice : (Invoice.InvoiceNo + Invoice.ItemNo) Invoice.Qty. Pasangan Nilai InvoiceNo dan

UoD : R

Y1

Y2

X1

X2

X3



ItemNo menjadi determinan bagi Qty (Jumlah barang yang dibeli yang dicatat didalam tabel invoice). Qty menjadi berarti jika dipasangkan dengan InvoiceNo dan ItemNo sekaligus.

4. Perhatikan latihan normalisasi yang diberikan pada contoh invoice : Invoice.InvoiceNoInvoice.CustomerNo. Satu InvoiceNo akan berhubungan dengan satu CustomerNo, berarti pengertian sederhananya adalah : Sebuah invoice hanya dapat diterbitkan untuk seorang customer, sedangkan seorang customer bisa diberi banyak invoice.

Penentuan ketergantungan fungsional akan mementukan tabel-tabel yang akan dibuat. Perhatikan latihan normalisasi dibawah ini : PT. Mercon Trading Indonesia Jl. Meruya Selatan No. 9000 Jakarta Barat Invoice No : 1001 Invoice Date : 29 – February – 2000 To

Customer No : 007 PT. XYZ Kaaboom Jl. Kebon Jeruk Raya No 1000 Jakarta Barat

Item No Item Description

Qty Unit Unit Price Cost

X001 Teko 20 Dozen 1,000,000 20,000,000.00X002 Kembang Api 10 Dozen 1,000,000 10,000,000.00X003 Mercon Banting 20 Kg 1,000,000 20,000,000.00 Sub Total 50,000,000.00 PPN 5,000,000.00 Total 55,000,000.00

Dari contoh invoice diatas kita dapat mulai melakukan proses normalisasi dan membuat tabel didalam Database. II. URUT-URUTAN PEKERJAAN

1. Transformasi fakta menjadi Tabel 1 NF 2. Tentukan Functional Dependencynya 3. Normalisasikan sampai bentuk normal ke 3 4. Buat SQL Script untuk medefinisikan tabel 5. Definisikan tabel didalam database



III. Mentransformasi Fakta Menjadi Tabel 1 NF Fakta Invoice diatas ditransformasikan menjadi tabel 1 NF :

RUBAH ITEMS DATA YANG HARUS DIISI/DITAMPILKAN MENJADI ATTRIBUTES

Invoice akan menjadi sebuah tabel dengan attributes :

Invoice(InvoiceNo, InvoiceDate, CustomerNo, CustomerName, Address, City, ItemNo, ItemDescription, Qty, Unit, UnitPrice, Cost, SubTotal, PPN, Total)

Menentukan Functional Dependency Berdasarkan tabel tersebut, dapat dibuat functional dependency diagram sbb : Definisi : Bentuk Normal Pertama adalah bentuk tabel dimana setiap nilai-nilai setiap attribute adalah atomik, tidak terdapat pengulangan nilai. Berarti pada setiap perpotongan baris dan kolom hanya terdapat 1 nilai saja, tidak lebih tidak kurang.

Garis functional dependency dibuat dengan memperhatikan bentuk hubungan himpunan nilai antar attribute. Berdasarkan functional dependency diagram ditentukan bentuk normalisasinya IV. Mentransformasikan Sampai Ke Bentuk 3 NF Definisi : Candidate Key adalah himpunan attribute yang dapat memenuhi syarat :

Uniqueness – Tidak ada himpunan nilai attribute yang sama didalam satu tabel Minimality – Tidak ada bagian dari himpunan attribute yang dapat dihilangkan tanpa menghilangkan sifat uniqueness. Definisi : Bentuk Normal Kedua adalah bentuk dimana seluruh attribute bukan key tergantung

InvoiceNo

ItemNo

CustomerNo CustomerName

Address

City

InvoiceDate

ItemDescriptio

Qty

Unit UnitPric

SubTotal

PPN

Total

Cost



fungsional kepada key

Berdasarkan definisi diatas bentuk tabel berubah menjadi :

Invoice(InvoiceNo, InvoiceDate, CustomerNo, CustomerName, Address, City) Item(ItemNo, ItemDescription, Unit, UnitPrice) InvoiceItem(InvoiceNo*, ItemNo*, Qty)

Definisi:

TransitiveDependcy adalah ketergantungan himpunan attribute non-key terhadap himpunan attribute non-key lainnya.

Definisi :

Bentuknormal ketiga adalah tabel dimanatabel sudah berada dalam bentuk normal kedua dan tidak ada transitive dependency

Transitive depedency ditemui pada attribute CustomerNo, CustomerName, Address, dan City.

Berdasarkan definisi diatas maka bentuk tabel berubah menjadi :

Customer(CustomerNo, CustomerName, Address, City) Item(ItemNo, ItemDescription, Unit, UnitPrice) Invoice(InvoiceNo, InvoiceDate, CustomerNo*) InvoiceItem(InvoiceNo*, ItemNo*, Qty)

Bentuk Entity Relationship Diagram untuk tabel tersebut adalah : V. Membuat SQL Script untuk mendefinisikan tabel create table Customer (CustomerNo char(3), CustomerName char(30) not null, Address char(30) not null, City char(30) not null, Primary Key(CustomerNo)); create table Item (ItemNo char(4), ItemDescription char(40) not null, Unit char(5) not null, UnitPrice float not null, Primary Key (ItemNo));

Customer Item

Invoice InvoiceItem



create table Invoice (InvoiceNo char(4), InvoiceDate DateTime not null, CustomerNo char(3) not null, Primary Key (InvoiceNo), Foreign Key(CUstomerNo) references Customer); create table InvoiceItem (InvoiceNo char(4), ItemNo char(4), Qty float not null, Primary Key (InvoiceNo, ItemNo), Foreign Key (InvoiceNo) references Invoice, Foreign Key (ItemNo) references Item); VI. Definisikan Tabel Didalam Database SQL Script tersebut dijalankan didalam DBMS untuk dapat membuat tabel. VII. Latihan Dalam waktu 1 Minggu Anda diminta untuk membangun basis data oleh MIS manager PT. Mercon Trading Indonesia. Karena mereka ingin anda membuat database untuk keperluan bisnis mereka. Seluruh Item barang dagangan dibeli dari Supplier (diidentifikasikan dengan Supplier_No). Supplier disimpan profilnya. Informasi yang diperlukan adalah Nama Perusahaannya, Contact Person, Telpon dan Alamat lengkapnya. (Supplier adalah entity !!!) Setiap supplier dapat mengirimkan bermacam-macam Barang. Barang dagangan tersebut tidak menjadi monopoli dari setiap supplier. Sehingga setiap supplier dapat mensupply banyak barang, dan tiap – tiap barang dapat disupply oleh banyak supplier (Bentuk many to many yang harus dirubah menjadi sejumlah n one-to–many, dimana n harus anda tentukan sendiri). Informasi Barang (diidentifikasikan dengan Barang_No) yang ingin disimpan adalah keterangan mengenai barang tersebut (Item description), Unit, dan Unit Price. Setiap pengriman barang dari supplier dicatat didalam buku pembelian. Didalam buku pembelian tersebut dicatat Tanggal, Jumlah Pembelian, Supplier dan Barangnya. (Tentukan sendiri attribute yang relevan, dan keys nya ) Setiap Customer (Diidentifikasikan dengan Customer_No) dapat membeli bermacam-macam barang. Dalam Melakukan penjualan mereka mengirimkan invoice kepada pembeli. Contoh invoice diberikan dibawah ini. Sebagai seorang analis anda diminta untuk membuat tabel 3NF bagi data base tersebut. Untuk keperluan dokumentasi mereka meminta : Entity Relationship Diagram. Buatlah DDL Script untuk membuat table dengan SQL dari E/R diagram tersebut. PT. Mercon Trading Indonesia Jl. Meruya Selatan No. 9000 Jakarta Barat Invoice No : 1001 Invoice Date : 29 – February – 2000



To Customer No : 007 PT. XYZ Kaaboom Jl. Kebon Jeruk Raya No 1000 Jakarta Barat



1001 Teko 20 Dozen 1,000,000 20,000,000.001002 Kembang Api 10 Dozen 1,000,000 10,000,000.001003 Mercon Banting 20 Kg 1,000,000 20,000,000.00 Sub Total 50,000,000.00 PPN 5,000,000.00 Total 55,000,000.00 SYNTAX PEMBUATAN TABEL DIDALAM SQL CREATE TABLE NamaTable (

{NamaKolom TipeKolom [daftarconstraint …..] {KolomBerikut….} [Primary Key (DaftarKolom…..)] [Foreign Key (Daftar Kolom……) references TabelLain|TabelIni (DaftarKolom)

)

NamaKolom adalah nama kolom dari tabel yang dibuat TipeKolom : Data Type Kolom yang akan dibuat DaftarConstraint : Pembatasan yang akan dibuat misal Null, Not Null Primary Key : Primary Key dari tabel Foreign Key : Kolom(Kolom-kolom) yang menunjuk primary key pada tabel lain atau

tabel bersangkutan



OPERASI UPDATE TERHADAP TABEL

I. Menyisipkan/Memasukkan Data Setelah selesai membuat tabel-tabel didalam database maka data dapat mulai dimasukkan. Aturan memasukkan data adalah :

1. Data yang berada pada sisi one/sisi primary key harus diisi terlebih dahulu. 2. Data yang berada pada sisi many/foreign key diisi setelah sisi primary key. 3. Pengisian data harus memenuhi aturan-aturan database yang didefinisikan sebelumnya.

Baik data yang dimasukkan dengan perintah SQL maupun dengan interface DBMS haruslah memenuhi aturan-aturan tersebut : Perhatikan tabel-tabel dibawah ini :

Customer(CustomerNo, CustomerName, Address, City) Item(ItemNo, ItemDescription, Unit, UnitPrice) Invoice(InvoiceNo, InvoiceDate, CustomerNo*) InvoiceItem(InvoiceNo*, ItemNo*, Qty)

Pada tabel-tabel diatas, sebelum dapat melengkapi sebuah Faktur secara lengkap, Tabel harus diisi dengan urutan :

1. Customer dan Item harus diisi terlebih dahulu 2. Invoice 3. InvoiceItem

Perhatikanlah urut-urutan tersebut bersesuaian dengan aturan Entity Integrity dan Referential Integrity. Sehingga untuk mengisi tabel dijalankan perintah :

1. Mengisi Customer Insert Into Customer(CustomerNo, CustomerName, Address, City) values (‘007’, ‘PT XYZ Kaaboom’, ‘Jl. Kebon Jeruk Raya No 1000’, ‘Jakarta Barat’); Insert Into Customer(CustomerNo, CustomerName, Address, City) values (‘008’, ‘PT Dor’, ‘Jl. Meruya Selatan No 1000’, ‘Jakarta Barat’);

2. Mengisi Item Insert into Item(ItemNo, ItemDescription, Unit, UnitPrice) values (‘X001’, ‘Teko’, Dozen, 1000000) Insert into Item(ItemNo, ItemDescription, Unit, UnitPrice) values (‘X002’, ‘Mbang Api’, Dozen, 1000000) Insert into Item(ItemNo, ItemDescription, Unit, UnitPrice) values (‘X003’, ‘Mercon Banting’, Kg, 1000000)

3. Mengisi Invoice Insert into Invoice(InvoiceNo, InvoiceDate, CustomerNo) values(‘1001’, ‘02/29/2000’, ‘007’)

4. Mengisi Invoice Item Insert into InvoiceItem(InvoiceNo, ItemNo, Qty) values(‘1001’, ‘X01’, 20) Insert into InvoiceItem(InvoiceNo, ItemNo, Qty) values(‘1001’, ‘X02’, 10)

Customer Item

Invoice InvoiceItem



Insert into InvoiceItem(InvoiceNo, ItemNo, Qty) values(‘1001’, ‘X03’, 20) PT. Mercon Trading Indonesia Jl. Meruya Selatan No. 9000 Jakarta Barat Invoice No : 1001 Invoice Date : 29 – February – 2000 To

Customer No : 007 PT. XYZ Kaaboom Jl. Kebon Jeruk Raya No 1000 Jakarta Barat



X001 Teko 20 Dozen 1,000,000 20,000,000.00

X002 Kembang Api 10 Dozen 1,000,000 10,000,000.00

X003 Mercon Banting 20 Kg 1,000,000 20,000,000.00

Sub Total

50,000,000.00 PPN

5,000,000.00 Total

55,000,000.00 II. Menghapus Data Untuk menghapus data harus diperhatikan baik aturan referensial dan aturan integrity. Aturan yang harus dipenuhi untuk menghapus data didalam tabel adalah :

1. Data yang berada pada sisi many/sisi foreign key harus dihapus terlebih dahulu. 2. Data yang berada pada sisi one/primary key dihapus setelah sisi foreign key. 3. Pengisian data harus memenuhi aturan-aturan database yang didefinisikan sebelumnya.

Untuk menghapus seorang customer yang harus dilakukan adalah :

1. Menghapus InvoiceItem Delete from InvoiceItem where InvoiceNo = ‘1001’

2. Menghapus Invoice Delete from Invoice where InvoiceNo = ‘1001’

3. Menghapus Customer

4. Delete from Customer where CustomerNo = ‘007’



Daftar Pustaka




McGraw Hill, 1992






MODUL PERKULIAHAN

ANALISA





03 87016 Tim Dosen

Abstract Kompetensi

Mengidentifikasi ukuran project, membuat dan mengelola rencana kerja pelaksanaan project

Memahami Managemen Project



Project Initiation dan Project Management

2.1 Project Initiation

Project adalah sehimpunan aktifitas with titik mulai dan titik akhir yang digunakan untuk

membuat suatu sistem yang akan memberikan nilai tambah. Ide dasar dari pembuatan

sebuah project adalah jika seseorang dapat melihat/menemukan kesempatan untuk

membuat business value /niai tambah dengan penerapan paradigma teknologi informasi

yang baru :

1. Studi kelayakan digunakan untuk membantu dalam menentukan untuk meneruskan

Teknik Informatika atau tidak.

2. Project sponsor adalah orang yang mengajukan pengembangan atau penerapan paradigma baru dalam teknologi informasi. Cakupan project menentukan siapa yang pantas menjadi sponsor. Jika implementasinya meliputi seluruh organisasi boleh jadi yang menjadi sponsor adalah CEO. Jika projectnya sangat spesifik misalnya pengembangan jaringan maka sponsornya adalah departemen atau bagian yang berhubungan dengan teknologi informasi.

3. Approval committee akan melakukan penilaian proposal untuk menentukan mana

yang layak untuk dikembangkan didalam organisasi.

Secara umum project akan dapat diidentifikasi ketika seseorang melihat business need

untuk membangun sebuah sistem. Business need muncul ketika dapat diidentifikasi baik

secara eksternal maupun internal. Bisa juga terjadi ketika seseorang melihat cara

penggunaan teknologi informasi dengan cara yang unik, sebagai contoh penggunaan J2EE

untuk visualisasi data GIS bagi pengambaran instalasi media iklan.

2.1.1 Identifikasi Project

Kebutuhan business akan mendorong adanya permintaan penggunaaan cara maupun

teknologi yang baru atau business requirement. Requirement adalah apa yang akan

dilakukan oleh sistem, dan fungsi apa yang dialkukannya. Project sponsor harus memiliki

pemahaman apa yang akan dilakukan oleh sistem yang akan dibuat, business value yang

akan diberikan oleh sistem yang baru. Business value yang diberikan dapat saja bersifat :

1. Tangible value merupakan nilai yang bisa dikuantifikasidan diukur dengan alat ukur



numerik. Misalkan penurunan penggunaan kertas sebesar 2 persen karena tidak

perlu mencetak memo.

2. Intangible value merupakan nilai yang tidak bisa dikuantifikasi tetapi secara intuitif

bisa dirasakan manfaatnya.

Setelah project sponsor dapat mengidentifikasi project yang dapat memenuhi kebutuhan

akan business value tersebut maka dia akan dapat membuat identifikasi business

requirement dan value, maka secara formal sudah dapat melakukan inisiasi project. Project

initiation dapat dimulai dengan menggunakan System Request.

2.1.2 System Request

System request adalah dokumen yang menjelaskan alasan pembuatan system dan nilai

yang diharapkan dapat disediakan oleh system. System request paling tidak meliputi 5

elemen yaitu :

Project Sponsor : Orang yang menginiasi project dan bekerja sebagai promary point

of contact untuk project pada sisi business.

Business need : Business-related reason for initiating the need

Business requirement : Kemampuan business yang disediakan oleh sistem yang

akan dibuat

Business value : Manfaat yang akan dinikmati oleh organisasi pemilik sistem, jika

sistem dibuat.

Special Issues / constraint : Issues/batasan yang relevan untuk implementasi sistem

dan penagmbilan keputusan mengenai pelaksanaan project.

2.1.3 Feasibility Analysis

Jika kebutuhan akan sistem yang baru dan business requiremenya sudah didefinisikan,

maka studi yang lebih terinci harus dilaksanakan untuk lebih memahami kesempatan dan

batasan yang berhubungan dengan project yang akan dilaksanakan. Feasibility analysis

harus dilaksanakan, karena akan memberikan petunjuk :

Apakah harus diteruskan atau tidak.

Resiko yang harus dihadapi jika project disetujui.



Feasibily analysis secara umum terdiri dari 3 teknik :

1. Technical Feasibility : Dapat secara tehnik membuatnya, : faktor penilainya adalah

1. Familiar dengan aplikasinya

2. Familiar dengan tehnologinya

3. Ukuran project : Semakin besar semakin beresiko

4. Compatibility : Semakin sulit mengintegrasikan sistem dengan teknologi yang

sudah ada maka resiko akan lebih besar.

2. Economic Feasibility : Haruskah dibuat/apakah ekonomis, faktor penilainya adalah

1. Development Cost

2. Annual operating cost

3. Annual benefits (cost saving dan revenues)

4. Intangible costs and benefit.

3. Organizational Feasibility : Kelayakan organisasional, kalau sudah dibuat akankah

secara organisasional bisa dipakai :

1. Project Champion

2. Senior Management

3. Users

4. Other Stakeholders

5. Kecocokan project dengan business.

Adapun untuk urut-urutan Economic Feasibility adalah :

1. Identifikasi Biaya dan Manfaat : Membuat bdaftar seluruh tangible cost dan manfaat

dari project.

2. Memasukkan nilai kedalam biaya dan manfaat : Bekerja dengan business user dan

IT professional untuk menghiting angka bagi biaya dan manfaat. Yang intangibles

juga harus dikuantifikasikan.

3. Menentukan cash flow : Memproyeksikan apakah manfaat dan biaya yang akan

terjadi dalam suatu periode tertentu baik jangka menengah maupun panjang.

Termasuk juga memperhitungkan faktor pertumbuhan.

4. Menentukan NPV (Net Present Value) : Menghitung nilai sekarang dari biaya yang

timbul dimasa yang akan datang dihitung dengan standard hari ini. Rate of growth



harus ditentukan untuk menghitung NPV

5. Tentukan ROI (Return On Investment) : Menghitung seberapa banyak organisasi

akan menerima manfaat investasi.

6. Menghitung BEP (Break-Even Point) : Digunakan untuk menentukan kapankah

sistem yang dibuat memberikan hasil yang lebih tinggi dibandingkan dengan

biayanya. Formula Break Even digunakan untuk menghitung BEP. Hal ini akan

membantu kapan organisasi akan memperoleh manfaat dari perhitungan yang

dilakukan.

7. Menggambarkan BEP : Gambarlah BEP dengan menggunakan time-graph.

Adapun biaya-biaya yang harus diperhitungkan dalam melakukanCost and Benefit Analysis

meliputi/diantaranya adalah :

1. Development Cost :

2. Development Team Salaries

2. Consultant Fees

2. Development Training

2. Hardware and Software

2. Vendor Installation

2. Office Space and Equipment

2. Data Conversion Costs

2. Operational Costs

3. Software Upgrades

3. Software Licensing Fees

3. Hardware Repairs

3. Hardware Upgrades

3. Operational Team Salaries

3. Communication Charges

3. User Training

3. Tangible Benefits



4. Increased Sales

4. Reduction in Staff

4. Reduction in Inventory

4. Better Supplier Prices

4. Intangible Benefits

5. Increased Market Share

5. Increased Brand Recognition

5. Higher Quality Products

5. Improves Customer Service

5. Better Supplier Relations

Kelayakan organizational adalah penting yaitu untuk memenuhi kepentingan Stakeholders

yaitu :

1. Champion : Adalah orang yang :

2. Menginisiasi project.

2. Mempromosikan project.

2. Mengalokasikan waktunya untuk project.

2. Menyediakan resources.

2. Organizational Management : Adalah pengelolaan organisasi yang :

3. Memahami project.

3. Memberikan anggaran yang cukup bagi terlasananya pekerjaan.

3. Mendorong/memaksa pengguna untuk menerima dan menggunakan sistem.

3. System Users adalah pengguna sistem :

4. Membuat keputusan yang mempengaruhi project

4. Melakukan aktifitas( atas produk yang dihasilkan) project

4. Menentukan apakah project sukses dengan menggunakan atau tidak

menggunakan sistem.

Project dapat diklasifikasikan Penentuan klasifikasi project ditentukan dengan melihat :

1. Size. Ukuran project dapat dilihat dari seberapa banyak orang yang terlibat dalam

pengerjaannya.



2. Cost. Seberapa banyak biaya yang harus dikeluarkan organisasi untuk mengerjakan

project tersebut.

3. Purpose. Apakah tujuan project. Apakah untuk meningkatkan infrastruktur teknik,

untuk mendukung strategi bisnis, ataukah untuk peningkatan inovasi baru.

4. Length. Seberapa lama project akan selesai sebelum dapat digunakan untuk

melakukan business.

5. Risk. Berapakah kemungkinan project untuk berhasil dan sukses.

6. Scope. Seberapa banyak organisasi dipengaruhi oleh sistem yang dibuat, Apakah

satu departemen, satu divisi, atau seluruh korporasi.

7. Return on Investment. Seberapa banyak organisasi mengharapkan ROI dari biaya

yang dikeluarkan.

2.2 Project Management

Perhatikanlah dua definisi dibawah ini sebelum meneruskan pembahasan selanjutnya :

1. Project Manager : A project manager has the primary responsibility for managing the

hundreds of tasks and roles that need to be carefully coordinated.

2. Project Management : Project management is the process of planning and controlling the development of a system within a specified timeframe at a minimum cost with the right functionality.

Pada tahun 1999 dari survey yang dilakukan oleh computer world separo dari 103 perusahaan yang di survey menyatakan bahwamereka menyadiakan pelatihan formal untuk project management untuk IT projects teams. Disamping itu juga disediakan perangkat untuk manajemen project seperti : Microsoft Project, Plan View, dan PMOffice yang mendukung project management. Tetapi banyak project yang tidak jadi karena tuntutan yang tidak masuk akal dan kurangnya dukungan dari management yang lebih tinggi.

Selanjutnya akan dibahas bagaimana mengidentifikasikan Ukuran project dengan Pendekatan Function Point. Adapun Pendekatan yang dilakukan adalah dengan :

1. Melakukan Estimasi Ukuran System.

2. Estimasi Effort yang diperlukan.

3. Estimasi Waktu yang diperlukan.



Gambar 1 Total Unadjusted Function Points

Gambar 2. Total Processing Complexity

Adjusted Project Complexity = .065 + (0.01 * Project Complexity) Total Adjusted Function Points = Adjusted Project Complexity * TUFP



Adapun perkiraan jumlah LOC per function points adalah : 1. C >> 130 2. COBOL >> 110 3. Java >> 55 4. C++ >> 50 5. Turbo Pascal >> 50 6. VB >> 30 7. Power Builder >> 15 8. HTML >> 15 9. Packages : Access, Excel, dll >> 10 - 40

Pengelolaan Rencana Kerja

Adapun perangkat yang digunakan didalam mengelola pekerjaan adalah :

1. Identifying Task

2. Project Workplan

3. Gantt Chart

4. PERT Chart

5. Refining Estimates

6. Scope Management

7. Time Boxing

8. Evolutionary Work Breakdown Structure and Itterative Work Plans

Perangkat/tools tidaklah cukup sehingga perlu ada :

1. Staffing Plan

2. Motivation

3. Handling Conflict

Coordinating Project Activities

1. CASE Tools

2. Standards

3. Documentation

4. Managing Risks



Daftar Pustaka




McGraw Hill, 1992






MODUL PERKULIAHAN

ANALISA





04 87016 Tim Dosen

Abstract Kompetensi

Memahami kebutuhan sistem Menentukan kebutuhan teknik dan menganalisa kebutuhan



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)



PengertianRequirement

Requirement adalah pernyataan apa yang harus dilakukan oleh sistem atau karakteristik apa

yang harus dimiliki :

1. Didalam tahapan analisis requirement ditulis dari sudut pandang business, atau apa

yang dilakukan oleh sistem. Fokusnya ada pada "WHAT". Fokusnya ada pada user

needs, sehingga biasanya disebut business requirements.

2. Selanjutnya didalam tahapan design, business requirement bergerak menjadi lebih

teknis, dan akan menjelaskan bagaimana (HOW) sistem akan diimplementasikan.

Requirement pada saat design dilihat dari sudut pandang pembuat sistem (developer).

Yang harus diperhatikan bahwa pembatas antara analisis dan perancangan remang-remang.

Beberapa pihak menggunakan istilah tersebut secara bolak-balik. Yang harus diperhatikan

adalah requirement adalah pernyataan apa yang harus dilakukan oleh sistem dan selalu da

kemungkinan untuk berubah. Secara umum requirement terbagi dua yaitu :

1. Functional requirement. Requirement ini berelasi langsung dengan dengan proses

yang harus dilakukan oleh sistem yang akan dibuat sehingga dapat menyediakan

informasi yang diperlukan. Functional requirement mengalir langsung kedalam

tahapan analisis selanjutnya, karena mendefinisikan fungsi-fungsi yang harus dimiliki

oleh sistem. Perhatikanlah Gambar 1 mengenai Functional Requirements

2. Nonfunctional requirement. Requirement ini berhubungan dengan behavioral

properties yang harus dimiliki oleh sistem, seperti performance and usability.

menjelaskan bermacam-macam karakteristik sistem : operational, performance,

secutiry, cultural and political. Karakteristik tersebut tidak menjelaskan business

process ataupun informasi yang diperlukannya, tetapi sangat penting untuk dpat

memahami apa yang harus dimiliki oleh sistem final. Perhatikanlah Gambar 2

mengenai Nonfunctinal Requirements



Gambar 1. Contoh Functional Requirement

Gambar 2 Contoh Non Functional Requirement



RequirementDefinition

Requirement definition report biasanya hanya disebut requirement definition adalah text

report yang berisi daftar functional dan nonfunctinal requirement. dalam bentuk outline.

Daftarnya dibuat secara berurut dan diberi nomer supaya jelas, Sebagaimana digambarkan

pada gambar 1 dan gambar 2 requirement dibuat daftarnya. Selanjutnya dibuatkan

prioritasnya. Tujuan terpenting dari requirement determination adalah menentukan tahapan

dari sistem. Kalau ada kebingunan dokumen bertindak sebagai alat klarifikasi.

DeterminingRequirements

Didalam menentukanUntuk menentukan requirement diperlukan pemahaman business dan IT.

Hal ini bisa dianalogikan seperti membuat bangunan. Jika kita pemilik tumah, maka kita tahu

apa yang kita inginkan dari rumah kita, tetapi kita tidak akan dapat membuatrancangan

rumah. Demikan juga dengan seorang ahli bangunan sipil atau arsitek tidak akan dapat

menentukan bentuk bangunan dengan baik meskipun memiliki kemampuan teknis untuk

dapat menggambarkannya jika tidak berkomunikasi dengan orang yang akan menggunakan

bangunan tersebut. Karena pendekatan terbaik adalah mempekerjakan ahli business dan IT

bersama-sama untuk membuat analisa sistem. Kadang kala pengguna tidak tahu secara tepat

apa yang diinginkannya maka analis akan membantunya dengan teknik/perangkat/notasi dan

pemahaman yang dimilikinya. Teknik yang populer untuk melakukan analisis adalah :

Business process Automation.

Business Process Improvement.

Business Process Reengineering.

Ketiga teknik yang disebutkan di atas memiliki cara kerja yang sama yaitu :

Membantu user untuk menjelaskan sistem dan proses yang sekarang (as‐is).

Identifikasi apa yang akan dirubah.

Membuat konsep untuk sistem yang baru.

MembuatReqirementDefinition

Requirement definition haruslah dibuat mutakhir karena akan digunakan untuk referensi dan

pemahaman sistem yang akan dibuat. Membuat Requirement Definition sifatnya itterative

dan berkesinambungan yang meliputi :



1. Mengumpulkan informasi dengan teknik yang diperlukan (interviews, document

analysis, dan lain-lain

2. Melakukan informasi untuk mengidentifikasi business requirement untuk sistem yang

akan dibuat.

3. Menambahakan requirements kedalam requirement definition reportyang akan

digunakan untuk menentukan pekerjaan.

Untuk membuat requirement definition, project team harus menentukan jenis -jenis dari

functional dan nonfunctional requirement dari sistem yang akan dibuat. Penentuan

requirements tersebut menjadi bagian utama dari dokumen yang akan dibuat. Selanjutnya

analis akan menggunakan bermacam-macam teknik untuk menentukan requirement seperti

interview dan observation untuk untuk mengumpulkan informasi, dan membuat daftar

business requirement yang teridentifikasi dari informasi diatas. Dan akhirnya bersama-sama

dengan dengan seluruh tim dan user akan melakukan :

1. Verifikasi

2. Perubahan

3. Melengkapi

4. Menentukan prioritas dari requirement.

Process akan berkesinambungan , dan requirement akan berevolusi jika requirement sudah

teridentifikasi dengan baik maka pekerjaan akan bergerak ke tahapan selanjutnya dari SDLC.

EVOLUTION OF REQUIREMENT harus secara hati-hati dikelola karena jika tidak akan ada

proliferasi requirment yang tak terkendali. Sehingga akan menyebabkan sistem tidak pernah

selesai dan selalu tumbuh diluar cakupan sistem. Ketika requirement mencerminkan

kebuatuhan business di dunia nyata dan bukan didalam sistem yang sekarang dibuat maka

dimasukkan kedalam requirement dimasa yang akan datang dan diberi nomor prioritas yang

lebih rendem. Pengelolaan requirement (dan cakupan dari sistem yang akan dibuat)

merupakan bagian yang paling berat dari pembuatan sistem.

RequirementsAnalysisTechniques.

Sebelum project team dapat menentukan requirement apa yang tepat untuk sistem yang akan

dibuat, mereka harus memiliki visi yang jelas sistem apa yang akan dibuat, dan tingkat

perubahan apa yang akan terjadi pada organisasi. Proses dasar analisis terbagi menjadi tiga

tahapan :



1. Mamahami sistem yang sekarang

2. Mengidentifikasi peningkatan

3. Membuat/mengumpulkan requirement untuk sistem yang akan dibuat.

Kadang-kadang langkah yang pertama dilewati jika tidak ada sistem yang ada atau hanya

dilakukan sepintas pada methodology seperti RAD dan Agile. Sedangkan pada metodologi

seperti waterfamm dan pararel development menggunakan waktu yang cukup panjang untuk

menganalisa sistem yang sudah ada dan mengidentifikasi perbaikan yang mungkin dilakukan

sebelum mealukan requirement gathering. Sementara itu metodologi yang berfokus pada

peningkatan dan requirement system yang akan dibuat akan melakukan investigasi terhadap

sistem yang sekarang berjalan secara sepintas saja. Metodologi tersebut adalah :

1. Generasi baru RAD

2. Agile

3. OO methodologies

4. phased development

5. prototyping

6. throwaway prototyping

7. XP

Ada tiga tehnik yang digunakan sebagaimana disebutkan diatas yaitu Business process

Automation, Business Process Improvement, dan Business Process Reengineering. Ketiga

tehnik tersebut membantu analis melakukan analisa sehingga visi dari sistem dapat

dikembangkan dengan baik. Tehnik Requirement analysis yang disebutkan diatas akan

digunakan bersama-sama dengan requirement-gathering techniques yang meliputi :

1. Interviews

2. JAD Session

3. questionaires

4. document analysis

5. observation.

Requirement analysis techniques akan menentukan jenis informasi apa yang akan

dikumpulkan dan bagaimana analisanya. Kedua jenis tehnik tersebut bersifat komplementer.



Pilihan tehniknya akan menentukan bentuk perubahan yang akan terjadi di dalam organisasi :

1. BPA digunakan untuk menangani perubahan kecil yang berhubungan dengan otomasi

proses.

2. BPI digunakan untuk melakukan perbaikan proses untuk memperbaiki efektifitas dan

efisiensi kerja

3. BPR merubah bagaimana cara organisasi bekerja sehingga yang terjadi adalah

transformasi organisasi ke bentuk yang lebih baik.

Untuk menggerakkan pengguna menggunakan sistem yang baru analis harus memiliki

kemampuan berpikir kritis yang tingi. Kemampuan berpikir kritis adalah kemampuan untuk

memahami strengths dan weaknesses dan membentuk kembali idea yang sudah ada menjadi

bentuk yang lebih baik sehingga. Idea tersebut digunakan untuk memahami issues dan

mengembangkan business process yang baru. Kemampuan ini diperlukan untuk mempelajari

:

1. Hasil dari requirements gathering

2. Identifikasi business requirement

3. menterjemahkan requirements menjadi sistem yang baru.

BusinessProcessAutomation

BPA artinya tetap menggunakan cara bagaimana organisasi bekerja, tetapi menggunakan

teknologi komputasi untuk mengerjakan beberapa pekerjaan yang harus dilakukan. BPA

dapat membuat organisasi bekerja lebih effisien tetapi mempunya pengaruh yang lebih kecil

dibandingkan dengan ketiga tehnik tersebut diatas. BPA akan mempelajari sistem yang

sedang berjalan dengan seksama dan pada akhirnya akan memperbaiki system requirements

yang dibuat. Problem analysis dan Root Cause Analysis adalah 2 cara BPA yang cukup

ngetop :

1. Problem Analysis. Adalah cara langsung requirment analysis. Problem analysis

artinya bertanya kepada user dan managers untuk melakukan identifikasi problem

dengan sistem yang sekarang sudah ada dan menjelaskan penyelesaian permasalahan

yang terjadi didalam sistem. Hampir semua pengguna sistem memiliki ide bagaimana

perbaikan dilakukan. Perbaikan proses dari problem analysis biasanya sedikit dan

bersifat incremental. Jenis pebaikan ini biasanya efektif untuk memperbaiki efisiensi



sistem. Tetapi basanya monetary benefits yang diperoleh tidak besar. Yang jelas

adalah perbaikan dari sistem yang sudah ada.

2. Root Cause Analys. Problem analysis bekerja berdasarkan asumsi yang bisa saja valid

3. atau tidak valid. Umumnya orang selalu membuat kesimpulan sebelum melakukan

pemikiran mengenai sebab dan akibat . Biasanya kesimpulan atau tindakan yang akan

dilakukan adalah mengobati gejala bukan akar permasalahannya. Didalam dunia nyata

permasalahn untuk perbaikan proses adalah dengan menggunakan root cause.

Pemecahan bisa jadi mengobati gejala, bisa juga akar permasalahan. , tetapi yang jelas

tanpa analisa yang mendalam akan sulit untuk memecahkan permasalahan dan

menentukan mana yang gejala dan mana yang akar permasalahan. Root cause analysis

berfokus pada masalah bukan pada pemecahan masalah.

BusinessProcessImprovement

BPI artinya membuat perubahan moderat dari cara bagaimana organisasi beroperasi, dengan

melihat bagaimana organisasi beroperasi untuk memanfaatkan teknologi yang baru atau apa yang

dilakukan oleh kompetitor. Tujuan dati BPI adalah meningkatkan efisiensi (doing thighs right) dan

meningkatkan efektifitas (doing the right things). Focus BPI adalah meningkatkan business process,

sehingga mempelajari business process yang ada sangat diperlukan untuk perbaikan proses dan

membuat sistem requirement yang baru. BPI menggunakan Duration analysis, activity based‐costing,

dan information benchmarking.

1. Duration Analysis memerlukan pembelajaran secara detail proses yang dilakukan didalam

sistem yang sekarang berjalan. Analisis dimulai dengan melihat waktu yang diperlukan

secara rata‐rata untuk melakukan business process guna menghasilkan output tertentu. Lalu

menghitung waktu yang diperlukan untuk menyelesaikan setiap pekerjaan/bagian proses

didalam business sehari‐hari. Waktu yang diperlukan untuk mengerjakan suatu bagian

pekerjaan kemudian ditotal. Selanjutnya akan diketahui persentase dari pekerjaan tersebut

secara keseluruhan. Dari perbandingan akan dapat dicari permasalahannya dimana. Karena

total dari masing‐masing subproses bisa jadi lebih kecil dari waktu yang diperlukan untuk

menyelesaikan pekerjaan. Permasalahan ini terjadi karena :

1. Fragmentasi sub‐process tidak baik.

2. Process integration/parrarelization.

2. Activity‐Based Costing sama dengan analisa biaya dari setiap sub aktifitas. Jika ternyata biaya

untuk menyelesaikan pekerjaan lebih besar dari biaya untuk melaksanakan seluruh sub

proses maka proses tidak dikelola dengan baik.



3. Informal Benchmarking. Benchmarking artinya membandingkan bagaimana organisasi lain

melakukan business process agar organisasi dapat bekerja dengan lebih baik. Benchmarking

tujuannya adalah agar dapat memperkenalkan idea bahwa karyawan dapat bekerja dengan

lebih baik dengan cara yang baru yang sebelumnya tidak pernah terbayangkan. Informal

Benchmarking adalah istilah dimana karyawan perusahaan berkunjung sebagai customer

untuk perusahaan lain. Misalkan membuat web site untuk universitas, maka team akan

melihat web site bermacam‐macam universitas untuk membandingkan apa yang dilakukan.

BusinessProcessReengineering

Business Process Reenginering (BPR) artinya merubah cara bagaimana organisasi beroperasi,

yaitu merubah cara bagaimana menjalankan business dan membuat perubahan besar karena

danya ide dan teknologi yang baru. Adapun tehnik yang digunakan didalam BPR adalah :

1. Outcome Analysis yang berfocus pada pemahaman dari produk yang memberikan

nilai yang lebih baik kepada customer.

2. Technology Analysis yang tujuannya adalah untuk menerapkan bagaimana analis dan

manager untuk membuat list/daftar teknologi apa saja yang akan dibuat atau

dimanfaatkan, untuk selanjutnya menentukan apa yang akan diterapkan didalam

business process.

3. Activity Elimination. Activity elimination adalah menghilangkan aktifitas yang

kurang produktif dan menggantikannya dengan aktifitas yang produktif.

Pemilihan Teknik yang Tepat

Untuk dapat melakukan pemilihan teknik atau mencampur teknik yang tepat perlu

diperhatikan strength dan weakness dari :

1. Potential Business Value. Nilai tambah yang dihasilkan oleh tehnik yang dipilih.

2. Project Cost. Biaya yang ditimbulkan dari tehnik yang dipilih.

3. Breadth of Analysis. Cakupan analisis yang apakah analisis meliputi :

1. business process dalam satu fungsi business

2. process yang menjangkau seluruh organisasi

3. process yang berinteraksi dengan seluruh customer dan organisasi.

4. RiskResiko kegagalan, yang diakibatkan oleh rancangan yang tidak baik, kebutuhan



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.



Daftar Pustaka




McGraw Hill, 1992






MODUL PERKULIAHAN

ANALISA





05 87016 Tim Dosen

Abstract Kompetensi




Requierment Gathering Technique

Analis pekerjaannya adalah seperti detektip. Ia tahu ada permasalahan dengan sesuatu dan

mencari solusi pemecahan. Berarti harus dapat mencari permasalahan yang melingkupi

suatu aktifitas business. Sayangnya pemecahan permasalahan tidk selalu langsung terlihat

dengan jelas. Seorang system analyst akan mencari pemecahan dengan bermacam-macam

technique, dan memastikan bahwa business process yang berjalan saat ini dan kebutuhan

akan sistem yang baru dipahami dengan baik sebelum dilakukan perancangan/design yang

baru. Yang tidak diinginkan adalah requirement yang salah yang menyebabkan pekerjaan

pengembangan sistem menjadi gagal.

Requirement gathering akan memberikan dukungan politis dan membuka komunikasi serta

membangun kepercayaan dan pelaporan antara project dan pengguna yang pada akhirnya

akan menggunakan atau tidak menggunakan hasil dari project tersebut. Seluruh

stakeholders (orang yang berkepentingan) yang penting harus dilibatkan sehingga akan

menyebabkan requirement dapat dikumpulkan dengan lebih seksama. Stakeholder yang

dilibatkan didalam requirement gathering meliputi :

1. Managers

2. Karyawan-karyawan

3. Staff,

4. Customer,

5. Supplier

Selanjutnya adalah mencari cara bagaimana informasi dikumpulkan secara efektif. Adapun

cara-cara yang digunakan meliputi :

Interview

JAD (Joint application development) session

Document Analysis.

Interviews

Interview merupakan cara yang paling umum digunakan. Secara umum interview dapat

dilakukan dengan cara :

one on one interview.

one on many interview.



Ada lima tahapan dalam melakukan interview :

1. Memilih object interview. Memilih orang yang ditanya dengan membuat jadwal yang

berisi nama dan jadwal interview. Jadwal dapat saja informal, tetapi harus

merupakan bagian dari rencana kerja.

2. Merancang pertanyaan yang digunakan untuk interview, dapat saja meliputi :

1. Open ended question. Jenis pertanyaan yang bersifat terbuka untuk dapat

mengumpulkan informasi yang lebih kaya.

2. Closed Ended Question. Jenis pertanyaan tertutup yang berada dibawah kendali

penanya. Pertanyaan ini lebih ditujukan untuk apa.

3. Probing Question. Jenis pertnyaan ini sangat terbuka dan memungkinkan

penanya untuk mengungkapkan yang lebih lanjut lagi dari subject yang

ditanyakan. Jenis pertanyaan ini menyebabkan yang ditanya akan bebicara lebih

luas untuk lebih menjelaskan lagi persepsinya.

4. Yang terpenting jangan menanyakan pertanyaan yang sudah ada jawabannya.

5. Kombinasi dari ketiga jenis pertanyaan digunakan karena tidak ada yang lebih

baik atau lebih buruk

6. Pada saat project berjalan. Semakin lama analis akan memahami business

proses yang dilakukan. Sehingga ia akan memerlukan informasi yang lebih terinci

dan spesifik. Pada tahapan ini analis akan melakukan structured interview, disini

akan lebih banyak pertanyaan yang tertutup.

7. Selanjutnya harus diperhatikan strategi penentuan pertanyaan apakah Top-Down

atau Bottom-Up.

8. Top-down merupakan pendekatan yang paling umum dilakukan. Top down

memungkinkan penanya memahami terlebih dahulu topic yang ditanyakannya.

9. Jika analis sudah memiliki pemahaman yang lebih ia mungkin akan melakkukan

apa yang disebut dengan Bottom-up approach.

3. Mempersiapkan interview. Persiapan interview sangat penting. Sama pentingnya

dengan mengadakan presentasi. Harus ada rencana apa yang akan ditanyakan.

Harus diperhatikan bahwa pertanyaan yang akan diajukan haruslah dapat dijawab..

1. Closed ended question lebih memerlukan waktu untuk persiapannya

2. Yang paling berbahaya adalah unstructured interview karena hasil yang diperoleh

memerlukan follow up effort.



4. Melakukan interview. Pastikanlah bahwa interview berjalan dengan baik dimana yang

diwawancarai akan secara terbuka mau menjawab pertanyaan dengan baik dan

benar. percaya kepada interviewr. Adapun aturannya adalah :

1. Tulis semua yang dijawab dan dikatakan.

2. Pahami apa yang didiskusikan.

3. Pisahkan fata dengan opini.

4. Pastikanlah bahwa orang yang ditanya juga punya kesempatan untuk bertanya

5. Pada akhir interview beritahukanlah dengan ringkas apa yang akan dilakukan

selanjutnya.

5. Post-Interview Follow-up. Setelah interview selesai siapkan interview report yang

menjelaskan informasi yang telah diperoleh dari orang yang ditanya. Mintalah orang

ditanya untuk membaca dengan seksama dan mungkin perlu ada koreksi jika

diperlukan.

Gambar 1 Top-Down & Bottom Questioning Strategies.

Joint Application Development (JAD) JAD adalah information gathering technique yang memungkinkan project team, user, dan

management bekerja sama untuk dapat memperoleh requirement dari system. JAD

dikembangkan oleh IBM pada akhir 1970an. Dianggap sebagai metode yang cukup baik

sehingga dapat :

1. Mengurangi scoop creep sampai 50 %.

2. Menghindarkan requirement yang terlalu spesific atau kurang jelas.

3. JAD merupakan proses yang terstruktur dimana 10 sampai 20 user bertemu dibawah



pimpinan fasilitator yang memahami teknik JAD dan permasalahan yang dibahas

tetapi tidak ikut sebagai partisipan.

4. JAD akan bertemu sesuai dengan batas waktu yang ditentukan sampai menemukan

requirement yang dianggap perlu.

5. Menggunakan bermacam-macam perangkat diantaranya adalah CASE-tools.

6. Tempat dilaksanakannya JAD ditempat yang jauh dari tempat kerja partisipan.

7. Perhatikanlah agar komunikasi dapat berjalan dengan effetive.

Urut-urutan pelaksanaan JAD adalah :

1. Memilih partisipan. Partisipan dipilih berdasarkan informasi yang dapat diberikan,

yang terdiri-dari bermacam-macam tingkatan organisational, tujuannya untuk

membangun political support untuk system yang akan dibuat.

2. Merancang Sesi. Biasanya sesi JAD akan berlangsung selam 4 hari dalam satu

minggu atau 8 hari dalam 2 minggu, dan seterusnya. Karena peserta biasanya pada

akhir sesi harus melakukan analisis dan koleksi data.

3. Menyiapkan Sesi. Memastikan bahwa partisipan memahami apa yang diharapkan

dari mereka.

4. Melaksanakan JAD. Fasilitator harus memegang peranan utamanya dalam

mengarahkan diskusi peserta JAD :

5. Memastikan agenda dipenuhi

5. Membantu memahami istilah teknis dan methodologi.

5. Merekam apa yang menjadi hasil JAD dan mendistribusikannya.

5. Post JAD Follow-up. Setelah JAD selesai dilaksanakan haruslah ada dokumentasi

yang diterbitkan dan ditindaklanjuti.



Gambar 2 Ruang Pelaksanaan JAD.

Questionnaires Questionaire adalah sehimpunan pertanyaan tertulis untuk memperoleh informasi dari

individuals. Questionarire digunakan untuk mengumpulkan opini dari banyak orang. Urut-

urutan pelaksanaannya adalah sebagai berikut :

1. Memilih Participants

2. Merancang Questionaire

3. Administrasi questionaire

4. Questionaire Follow Up.

Document Analysis

Dokumen dianalisa untuk memahami sistem berjalan maupun project yang sedang berjalan.

Dokumen dapat saja terdiri dari :

1. Laporan

2. Memorandums

3. Policy Manuals

4. User Training Manuals

5. Organization charts

6. Forms.



Indikasi bahwa sistem harus diperbaiki adalah jika banyak tambahan informasi yang

diletakkan pada dokumen.

Observation Observasi atau melihat adalah adalah alat yang powerful untuk memperoleh informasi

mengenai sistem yang berjalan secara nyata bukan secara terdokumentasi. Observasi

adalah cara yang baik untuk memeriksa kebenaran informasi dari sumber yang tidak

langsung.

Observasi menjadi supplemen/pelengkep dari informasi yang diperoleh dari interview

dengan responden

Pemilihan tehnik Setiap teknik untuk requirement gathering ditentukan mana yang akan dipilih, atau digunakan bersama-sama dengan yang lain. Kriteria penilaiannya adalah :

1. Type of Information. Jenis informasi yang diperlukan

2. Depth of Information. Kedalaman Informasi yang diberikan

3. Breadth of Information. Range/sebaran informasi yang dapat dikumpulkan

4. Integration of Information. Bagaimana mengabungkan Informasi yang diperlukan.

5. User Involvement. Keterlibatan User

6. Biaya yang diperlukan.

Berikut ini adalah ringkasan dari pemilihan tehnik pengumpulan requirement.

Gambar 3. Requirements-Gathering Technique

Selanjutnya akan dibahas bagaimana menggunakan bermacam-macam notasi yang

berhubungan dengan Analisa dan Perancangan Sistem dengan menggunakan methodologi

yang menggunakan UML oleh karena itu untuk memaksa memahami data berikutnya akan



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.



Gambar 4. Entity Types.

Entity Types Entity Type adalah sehimpunan obyek sama memiliki properties (ciri-ciri) yang dapat

diidentifikasikan dan terdapat contoh kejadiannya Obyek-obyek tersebut tentunya harus

memiliki kepentingan bagi pengolahan data sehingga perlu diidentifikasikan dengan jelas.

Contoh kejadian atau benda adalah Mahasiswa (nyata) ataupun jadwal kuliah (abstract).

Perhatikanlah gambar dibawah ini yang merupakan contoh Diagram ER.



Notasi Setiap entity dialam ER diagram dinotasikan dengan sebuah kotak dengan nama entity.

Nama entity adalah kata benda tunggal, Selanjutnya huruf pertama adalah huruf besar.

Gambar dibawah ini menunjukkan contoh dari penggambaran entity

Relatioship Types

Relationship adalah sehimpunan asosiasi yang bermakna. Yang dimaknud

bermakna adalah asosiasi yang memiliki kepentingan didalam konteks pengolahan

data. Selanjutnya setiap relationship diberi nama yang harus dapat menunjukkan

hubungan antar entity. Relationship dapat memiliki derajat hubungan satu (unary),

dua (binary), tiga (ternary), empat (quartenary), ataupun lebih.

Notasi Setiap relationship ditunjukkan dengan garis yang menghubungkan entity type, dan diberi

nama. Sedangkan untuk menunjukkan hubungan tiga atau lebih menggunakan berlian

(diamond) perhatikanlah contoh gambar hubungan quartenary dibawah ini.

Recursive Relationship Recursive relationship adalah relationship type dimana beberapa obyek dari entity yang

berjenis sama berpartisipasi dalam satu relatioship tapi dalam kepasitasnya yang berbeda

contohnya adalah hubungan antara dosen biasa dan dosen supervisor.

Attributes

Attribute merupakan properties (ciri-ciri) dari sebuah entity atau relationship type.

Sebagai contoh adalah NIM, NamaMahasiswa, dan lain sebagainya. Attribute

tersebut menyimpan nilai yang menjelaskan contoh kejadian dari entity dan disimpan

sebagai data didalam database. Adapun nilai yang disimpan haruslah nilai yang sah.

Contoh nilai yang sah adalah jenis kelamin hanya terdiri dari 2 nilai saja yaitu laki-

laki dan peyempuan. Himpunan nilai yang sah dari suatu attribute disubut sebagai

attribute domain.



Simple & Composite

Simple attribute merupakan attribute yang memiliki nilai tunggal yang berdiri sendiri.

Contoh dari jenis attribute ini adalah NIM yang hanya memiliki nilai tunggal untuk

seorang mahasiswa. Attribute ini juga disebut attribute yang bersifat atomic yang

artinya tidak bisa dipecah menjadi bagian-bagian yang lebih kecil.

Sedangkan Composite attribute merupakan attribute yang terdiri dari banyak komponen.

Dimana setiap komponennya merupakan nilain tunggal yang beridi sendiri, sebagai contoh

adalah alamat yang terdiri dari jalan, kelurahan, kecamatan, dati2, dan propinsi.

Single-Valued & Multi-Valued Attribute Single-Valued attribute merupakan attribute yang hanya berisi satu nilai saja untuk setiap

contoh kejadian dari entity, sebagai contoh adalah NIM hanya berisi satu nilai saja untuk

seorang mahasiswa.

Sedangkan multi-valued attribute merupakan attribute yang terdiri dari beberapa nilai.

NomorTelepon dapat saja maksimum diisi sebanyak 3 nomor.

Derived Attributes

Derived attribute merupakan attribute yang merepresentasikan nilai yang dapat diturunkan

dari nilai attribute yang lain, yang boleh jadi berasal dari entity yang berbeda. Contoh dari

hal ini adalah jumlahdosen yang merupakan hasil pencacahan dari dosen yang ada.

Keys Candidate keys adalah himpunan attribute yang jumlahnya aharus minimal yang dapat

mengidentifikasi baris secara unik didalam suatu tabel

Primary Key adalah candidate key yang terpilih untuk mengidentifikasi sebauah baris secara

unik

Notasi Attributes Attribute diletakkan pada kotak dibawah nama entity. Primary key diberi label {PK}.

Strong and Weak Entity

1. Strong Entity adalah entity yang keberadaan contoh kejadiannya tidak tergantung

kepada contoh kejadian dari entity type yang lain.

2. Weak Entity type adalah etntiy yang contoh kejadiannya tergantung kepada contoh

kejadian dari entity type yang lain contohnya adalah Karyawan dan

TanggunganKaryawan.



3. Attributes on Relationships. Kita bisa menambahakan attributes pada relationships.

Adanya attribute pada relationship menunjukkan adanya entity yang belum

teridentifikasi. Notasi yang digunakan sama dengan yang digunakan oleh entity,

tetapi sesuai dengan semantik yang disampaikan notasi tersebut tanpa menunjukkan

adanya class.

Structural Constraint

Ada 3 jenis structural constraint yang harus diperhatikan yaitu :

1. One to One -> Satu ke Satu

2. One to Many -> Satu ke Banyak

3. Many to Many -> Banyak ke banyak

Notasi

Untuk menggambarkan constraint tersebut digunakan notasi :

Harus :

1. One to One -> 1..1

2. One to Many -> 1..*

3. Many to Many -> *..*

Optional :

1. Nol sampai satu 0..1

1. Nol sampai banyak 0..*

2. Nol sampai tiga misalnya 0..3

&&&&



Daftar Pustaka




McGraw Hill, 1992






MODUL PERKULIAHAN

ANALISA





06 87016 Tim Dosen

Abstract Kompetensi




Functional Modelling Functional model menjelaskan business process dan interaksi dari Teknik Informatika

dengan lingkungannya. Didalam OOAD ada dua buah model yang digunakan didalam

analisis dan disain :

1. Activity diagram. Menjelaskan pemodelan logical dari proses bisnis dan workflow

pekerjaan didalam bisnis. Notasi ini digunakan untuk menjelaskan apa yang telah

berlaku sekarang dan yang akan berlangsung pada sistem yang baru. Sebuah

activity diagram dapat digunakan untuk menjelaskan bermacam pemodelan aktifitas

yang berlangsung didalam sebuah Teknik Informatika yang berjalan pada sebuah

business sistem.

2. Use Case. Use case digunakan untuk menjelaskan fungsi dasar Teknik Informatika.

Notasi ini digunakan untuk menjelaskan apa yang telah berlaku sekarang dan yang

akan berlangsung pada sistem yang baru. Sebuah use case adalah cara formal

untuk menjelaskan bagaimana sebuah business system berinteraksi dengan

lingkungannya. Sebuah use case menjelaskan aktifitas yang dilakukan oleh

pengguna didalam sebuah Teknik Informatika. Use case dapat dilihat sebagai

gambaran eksternal atau gambaran functional sebuah proses business dimana

didalamnya diperlihatakan bagaimana pandangan pengguna terhadap sistem

3. Activity diagram dan use case merupakan logical models yaitu model yang

menjelaskan aktifitas-aktifitas yang terjadi didalam sebuah business domain tanpa

menjelaskan secara terinci bagaimana mereka harus dilakukan. Logical models

disebut juga sebagai problem domains models.

4. Disamping itu Activity diagram dan use case juga merupakan physical model yang

menggambarkan aktifitas fisik terinci yang memungkinkan sistem berjalan dengan

baik.

5. Dengan memfokuskan diri pada logical modelling analyst dapat melihat business

process tanpa harus memperhatikan implementation details terlebih dahulu.

Tujuan dari requirement determination adalah untuk merubah very high level explanation of

the business requirement menjadi daftar yang lebih jelas dari requirement yang dapat

digunakan sebagai input untuk analysis (membuat , functional models, structural models,

and behavioral models)



Pengertian Requirement Requirement adalah pernyataan apa yang harus dilakukan oleh sistem atau karakteristik apa

yang harus dimiliki :

6. Didalam tahapan analisis requirement ditulis dari sudut pandang business, atau apa

yang dilakukan oleh sistem. Fokusnya ada pada "WHAT". Fokusnya ada pada user

needs, sehingga biasanya disebut business requirements.

7. Selanjutnya didalam tahapan design, business requirement bergerak menjadi lebih

teknis, dan akan menjelaskan bagaimana (HOW) sistem akan diimplementasikan.

Requirement pada saat design dilihat dari sudut pandang pembuat sistem

(developer).

Use haruslah dapat menggambarkan user requirement. Yang harus diperhatikan bahwa

pembatas antara analisis dan perancangan remang-remang. Beberapa pihak menggunakan

istilah tersebut secara bolak-balik. Yang harus diperhatikan adalah requirement adalah

pernyataan apa yang harus dilakukan oleh sistem dan selalu da kemungkinan untuk

berubah. Secara umum requirement terbagi dua yaitu :

1. Functional requirement. Requirement ini berelasi langsung dengan dengan proses

yang harus dilakukan oleh sistem yang akan dibuat sehingga dapat menyediakan

informasi yang diperlukan. Functional requirement mengalir langsung kedalam

tahapan analisis selanjutnya, karena mendefinisikan fungsi-fungsi yang harus dimiliki

oleh sistem. Perhatikanlah Gambar 1 mengenai Functional Requirements

2. Nonfunctional requirement. Requirement ini berhubungan dengan behavioral

properties yang harus dimiliki oleh sistem, seperti performance and usability.

menjelaskan bermacam-macam karakteristik sistem : operational, performance,

secutiry, cultural and political. Karakteristik tersebut tidak menjelaskan business

process ataupun informasi yang diperlukannya, tetapi sangat penting untuk dpat

memahami apa yang harus dimiliki oleh sistem final.

Didalam menentukanUntuk menentukan requirement diperlukan pemahaman business dan

IT. Hal ini bisa dianalogikan seperti membuat bangunan. Jika kita pemilik tumah, maka kita

tahu apa yang kita inginkan dari rumah kita, tetapi kita tidak akan dapat membuatrancangan

rumah. Demikan juga dengan seorang ahli bangunan sipil atau arsitek tidak akan dapat

menentukan bentuk bangunan dengan baik meskipun memiliki kemampuan teknis untuk

dapat menggambarkannya jika tidak berkomunikasi dengan orang yang akan menggunakan

bangunan tersebut. Karena pendekatan terbaik adalah mempekerjakan ahli business dan IT



bersama-sama untuk membuat analisa sistem. Kadang kala pengguna tidak tahu secara

tepat apa yang diinginkannya maka analis akan membantunya dengan

teknik/perangkat/notasi dan pemahaman yang dimilikinya. Teknik yang populer untuk

melakukan analisis adalah :

Business process Automation.

Business Process Improvement.

Business Process Reengineering.

1. Business Process Modelling dengan Activity Diagrams Business process model menjelaskan bermacam-macam aktifitas yang menjadi pendukung

dari proses buiness yang dilakukan sehari-hari. Business process biasanya memotong

beberapa departemen fungsional sehingga melibatkan fungsionalitas beberapa department.

1.1 Elemen dari activity diagram Activity diagram merupakan gambaran sebuah data flow yang lebih mutakhir dibandingkan

dengan flow chart maupun DFD didalamnya dapat menggambarkan pararel process dan

aktifitas yang lebih rumit. Berikut ini adalah contoh dari Activity diagram.

Gambar 1 Contoh Activity Diagram untuk Pendaftaran Pasien



Elemen-elemen dari activy diagram adalah :

1. Action :

a. Behaviour sederhana yang tidak bisa dipecah lagi (secara conceptual).

b. Diberi label dengan nama

2. Activity :

a. Digunakan untuk menggambarkan sehimpunan Action

b. Diberi label dengan nama

3. Control flow : Memperlihatkan urut-urutan eksekusi.

4. Object flow :Memperlihatkan aliran object adi sebuah action atau activity ke action

atau activity lain.

5. Initial node : Memperlihatkan titik awal.

6. Final Activity node : Akhir dari sebuah activity diagram

7. Final flow node : Digunakan untuk menghentikan sebuah control flow atau object flow

yang spesific.

8. Decision node :

a. Digunakan untuk menggambarkan test condition untuk memastikan bahwa

control flow atau object flow mengalir ke lebih dari satu jalur.

9. Merge node : digunakan untuk menggabungkan kembali decision path.

10. Fork Node : Digunakan untuk memecah sebuah behaviour menjadi activity atau

action pararel yang pararel.

11. Join node : digunakan untuk menggabungkan kembali activity atau action yang

pararel.

12. Swimlane :

a. digunakan untuk memecah activity diagram kedalam baris dan kolom untuk

membagi tanggung jawab kepada object-object yang melakukan aktifitas

tersebut.

b. Diberi label dengan nama object yang bertanggung jawab untuk menjalankan

activity atau action.

Adapun garis besar yang harus diikuti untuk membuat activity diagram, adalah :

Since an activity diagram can be used to model any kind of process, you should set

the context or scope of the activity being modeled. Once you have

determined the scope, you should give the diagram an appropriate title.

You must identify the activities, control flows, and object flows that occur between the

activities.



You should identify any decisions that are part of the process being modeled.

You should attempt to identify any prospects for parallelism in the process.

You should draw the activity diagram.

2. Use Case Use case adalah penjelasan dari fungsi sistem dilihat dari kaca mata penggunanya. Use

case diagram merupakan sebuah functional diagram yang menggambarkan fungsi dasar

dari sistem. Yaitu apa yang dapat digunakan oleh user dan bagaimana sistem harus

merespon terhadap user action. Tahapan yang harus dialui adalah :

Membuat text base description.

Menterjemahkan use case menjadi use case diagram.

Use case menjelaskan sebuah fungsi didalam organisasi tetatpi terdiri dari bermacam-

macam action dan aktifitas.

Use case dikembangkan dengan cara bersama-sama dengan user. Use case diagram

menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang

ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case

merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan

sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja,

dan sebagainya.

Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan

sistem untuk melakukan pekerjaan-pekerjaan tertentu.

Use case diagram dapat sangat membantu bila kita sedang menyusun requirement sebuah

sistem, mengkomunikasikan rancangan dengan klien, dan merancang test case untuk

semua feature yang ada pada sistem.

Sebuah use case dapat meng-include fungsionalitas use case lain sebagai bagian dari

proses dalam dirinya. Secara umum diasumsikan bahwa use case yang di-include akan

dipanggil setiap kali use case yang meng-include dieksekusi secara normal.

Sebuah use case dapat di-include oleh lebih dari satu use case lain, sehingga duplikasi

fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas yang common.

Sebuah use case juga dapat meng-extend use case lain dengan behaviour-nya sendiri.



Sementara hubungan generalisasi antar use case menunjukkan bahwa use case yang satu

merupakan spesialisasi dari yang lain.

2.1. Jenis jenis use case Use case merupakan :

use case capture a contract ….[that] describes the system’s behaviour under various

conditions as the system respons to request from one of its stakeholders

Pada dasarnya use case adalah ceritera lengkap dengan sebuah form tertentu tentang

bagaimana pengguna system berinteraksi dengan system didalam suatu keadaan tertentu.

Tahapan pertama dalam menulis use case adalah menentukan actor yang diikutkan didalam

ceritera. Actor adalah orang atau perangkat yang menggunakan system atau product

didalam context system atau behaviour yang dilakukan.

Actor dan end-user belum tentu orang yang sama . User boleh jadi melakukan peran yang

berbeda sehingga user dan actor belum tentu sama. Yang harus diperhatikan adalah

pembuatan use case merupakan aktifitas yang berulang dimana tidak seluruh actor dapat

ditemukan pada iterasi yang pertama. Sesudah actor dapat diidentifikasi use case dapat

dikembangkan. Ivar Jacobson menyarankan beberapa pertanyaan untuk dapat memahami

use case apa yang ada didalam sebuah object analisis dan disain :

Ada dua jenis use case yaitu :

1. Overview vs detail. Overview use case digunakan untuk memungkinkan analis dan

user setuju atas requirement secara umum. Jika sudah dipahami bersama-sama

maka requirement tadi akan dikonversi menjadi detail use case :

a. Presents an important business process.

b. The use case supports revenue generation or cost reduction.

c. Technology needed to support the use case is new or risky and therefore will

require considerable research.

2. Essential versus real. Pada essential use case yang dijelaskan adalah minimal

essential issues untuk memahami required functinality, sedangkan pada real use

case yang harus dijelaskan adalah lengkah-langkah terinci dari Teknik Informatika.

Untuk membuat use case petunjuk yang diberikan adalah :

1. Write each step in “SVDPI (Subject – Verb – Direct Object or Preposition – Indirect

Object)" form. Setiap langkah didalam Use case dituliskan secara lengkap dengan

aturan tata bahasa yang baik



2. Clarify initiator and receivers of action. Siapa yang memulai action harus jelas, dan

siapa yang menjawab tindakan tersebut juga harus dijelaskan dengan terinci.

(System Response harus jelas)r

3. Write from independent observer perspective. Ditulis secara independent tidak

secara judgemental.

4. Write at same level of abstraction. Tingkat abstraksi harus sama dengan responden

yang ditanya.

5. Ensure a sensible set of steps. Urut-urutan langkah harus masuk akal. Secara logis

urut-urutan harus benar berurut

6. Apply KISS principle liberally. Use case harus dibuat sederhana, dan mudah

dipahami (Keep it simple stupid).

7. Write repeating instructions after the set of steps to be repeated. Tulislah

instruksi untuk mengulang sesudah langkah penjelasan langkah yang harus

dilakukan.

Adapun notasi notasi yang digunakan adalah sebagaimana diperlihatkan pada Gambar 3

yang meliputi :

1. Actor/Role.

2. Use Case.

3. System

4. Association yang dapat berjenis :

5. Association Relationship

6. Include Relationship

7. Extend Relationship



Gambar 3. Notasi Use Case

Gambar 4. Use Case Diagram



Gambar 5. Extend dan Include Relationship.

Gambar 6. Cara Identifikasi Use Case



Daftar Pustaka




McGraw Hill, 1992






MODUL PERKULIAHAN

ANALISA





07 87016 Tim Dosen

Abstract Kompetensi




Structural Modelling 7.1 Pendahuluan

Structural modelling adalah:

1. A structural or conceptual model describes the structure of the data that supports the

business processes in an organization. Model terstruktur atau konseptual yang

menjelaskan struktur data yang digunakan didalam business proses didalam

organisasi.

2. The structure of data used in the system is represented through CRC cards, class

diagrams, and object diagrams.

Tujuan dari pemodelan tersebut adalah :

1. Reduce the “semantic gap” between the real world and the world of software.

2. Create a vocabulary for analysts and users

3. Represent things, ideas, and concepts of importance in the application domain

7.1.1 CLASS dan OBJECT

CLASS adalah template/cetakan yang digunakan untuk mendefinisikan suatu

instance/contoh kejadian yang disebut object. Object adalah contoh kejadian dari class.

setiap object pasti akan berasosiasi tepat dengan satu class.

Setiap object memiliki attributes yang berisikan informasi mengenai object tersebut. State

dari sebuah object ditentukan oleh nilai dari attributes dan relationshipnya pada suatu waktu

tertentu.

Setiap object juga memiliki behaviour yang menspesifikasikan apa yang bisan dilakukan

sebuah object.



7.1.2 Methods dan Messages

Method merupakan implementasi dari behaviour(kelakukan) sebuah object. Method adalan

sebuah action(tindakan) yang dapat dilakukan oleh object. Method dapat dianalogikan

dengan fungsi sebagaimana terdapat didalam bahasa C. Message merupakan informasi

yang dikirimkan ke Object yang akan menjadi pemicu dari dilakukannya sebuah tindakan.

7.1.3 Encapsulation dan Information Hiding

Pemikiran mengenai encapsulation dan Information hiding sudah ada sejak jaman dahulu

kala. Encapsulation adalah kombinasi dari proses dan data yang diletakkan didalam sebuah

class. Didalam OOSAD yang dimaksudkan dengan

Encapsulation adalah meletakkan attribute dan behaviour kedalam sebuah object yang

dispesifikasikan didalam class. didalam notasi yang digunakan UML 2.0 attribute diletakkan

pada bagian atas sedangkan behaviour diletakkan pada bagian bawah dari kotak.

Information hiding adalah sebuah cara berpikir dimana informasi yang diperlukan oleh

penggunalah yang akan ditampilkan sedangkan yang tidak diperlukan tidak usah

ditampilkan/diberikan. Konsekuensinya yang dapat diakses adalah bagian dari object yang

digunakan untuk menerima perintah dan memberikan informasi kepada pengguna object

tersebut. Sehingga object diperlakukan seperti sebuah kotak hitam.

The only information that an object needs to know is the set of operations, or

methods, that other objects can perform and what messages need to be sent to

trigger them.

7.1.4 Inheritance

Inheritance atau pewarisan digunakan untuk mengidentifikasi object/class yang memiliki

tingkat yang lebih tinggi dan lebih general. Atributes dan methods yang sama dikelompokkan

menjadi sebuah superclass. Biasanya superclass diletakkan diatas dan turunannya

diletakkan dibawah. Hubungan inheritance yang terjadi adalah A KIND OF.



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



7.1.5 Polymorphism dan Dynamic Binding

Polymorphism artinya message yang sama diinterpretasikan/memiliki arti/bentuk yang

berbeda. Sebagai contoh jika kita beri perintah draw kepada object segi empat, segi tiga,

dan lingkaran akan menjalankan perintah yang berbeda. Dibawah ini adalah contoh

polymorphism :

int kali(int a, int b);

int kali(int a, int b, int c);

maka fungsi mana yang akan dijalankan tergantung kepada argumen yang disertakan.

Polymorphism dapat terlaksanya karena adanya dynamic binding. Dynamic, atau, late

binding adalah teknik/cara penundaan penentuan jenis object sampai pada saat run-time.

Artinya method mana yang akan dijalankan ditunda sampai system/program berjalan.

Kontrasnya adalah static binding dimana setiap methods sudah ditentukan pada saat

kompilasi.

Attributes :

Units of Information relevant to the description of class (attribute berisi informasi yang

menjelaskan class



Hanya attribute yang relevan yang disertakan dalam class diagram

Operations/Methods :

Aksi yang dilakukan oleh objects.

Berfokus pada operasi yang spesific untu sbh problem domain

Relationship :

1. Generalization Enables inheritance of attributes and operations

2. Aggregation Relates parts to wholes

3. Association Miscellaneous relationships between classes

7.2 Class Responsibilities and Collaboration Menunjukkan kerjasama dari classes untuk melakukan pemenuhan kebutuhan dari client :

1. Responsibilites adalah :

a. Knowing. Mengetahui apa yang harus dikerjakan untuk melayani permintaan

client

b. Doing. Melakukan apa yang diminta client

2. Collaboration Objects working together to service a request



Gambar 7-1 CRC Jenis-jenis attribute :

1. Derived atau attribute turunan yang diturunkan dari attribute primitive. Contoh

tanggal lahir adalah primitive. Umur adalah derived attributes

2. Visibility

3. Public bisa dilihat siapa saja

4. Protected hanya bisa dihubungi oleh class yang menjadi friend/teman

5. Private hanya bisa dilihat oleh class itu sendiri

Jenis-jenis operasi selain fungsi methods yang biasa :

1. Constructor. :

2. Secara otomatis akan dijalankan pada saat oject dibuat

3. Biasanya juga membuat object yang lain

4. Query : Menanyakan state dari object

5. Update : Merubah nilai dari beberapa atau seluruh attribute.

Relationship adalah hubungan antar object/class. Jenis hubungannya bermacam-macam :

1. Sebuah class dapat berhubungan denga dirinya sendiri atau disebut recursive

2. Multiplicity :

3. One to one



4. Zero to many

5. One to many

6. Zero to one

7. Specified Range

8. Multiple disjoint range

Association

Gambar 7-2 Class Diagram

Class diagram dapat disederhanakan dengan hanya memperlihatkan bagian yang ingin

dilihat saja, tetapi paling tidak harus memiliki nama class. Disamping class digram terdapat

object diagram yang membantu memperlihatkan hubungan antar object atau contoh

kejadian dari sebuah class. Object diagram menggambarkan hubungan structural pada saat

run time. Contoh object diagram dapat dilihat pada gambar berikut



7.3 Membuat CRC dan Class Diagram Yang pertama tama harus dilakukan adalah melakukan identifikasi object. Identifikasi object

dilakukan dengan cara membaca use case untuk kemudian dilakukan parsing dari setiap

kalimat yang terdapat didalam Use case scenario. Aktivitasnya meliputi :

1. Analisis tekstual dari use case (Textual analysis of use-case information)

:

1. Nouns suggest classes

2. Verbs suggest operations

2. Membuat gambaran secara kasar (Creates a rough first cut)

3. Membuat daftar object (Common object list)

4. Membuat daftar contoh kejadian

5. Membuat daftar peranan (Roles)

Setelah melakukan identifikasi class lalu membuat identifikasi pola :

1. hubungan antar class yang dapat dikelompokkan berdasarkan :

2. Transactions



1. Transaction class

2. Transaction line item class

3. Item class

4. Location class

5. Participant class

Adapun tahapan tahapan pembuatan model struktural adalah :

1. Create CRC cards.

2. Examine common object lists.

3. Role-play the CRC cards.

4. Create the class diagram.

5. Review the class diagram.

6. Incorporate patterns.

7. Review the model.

&&&&&&&



Daftar Pustaka




McGraw Hill, 1992






MODUL PERKULIAHAN

ANALISA





08 87016 Tim Dosen

Abstract Kompetensi




Unified Modeling Language Unified Modeling Language (UML) adalah notasi yang lengkap untuk membuat visualisasi

model suatu sistem. Sistem berisi informasi dan fungsi, tetapi secara normal digunakan untuk

memodelkan sistem komputer. Di dalam pemodelan obyek guna menyajikan sistem yang

berorientasi pada objek pada orang lain, akan sangat sulit dilakukan jika pemodelan tersebut

dilakukan dalam bentuk kode bahasa pemrograman. Kesulitan yang muncul adalah timbulnya

ketidak jelasan dan salah interpretasi di dalam pembacaan kode pemrograman untuk

pemodelan objek tersebut.

Dimulai tahun 1994, Booch, Runbaugh dan Jacobson merupakan tiga tokoh yang metodelogi-

nya paling banyak dipakai mempelopori organisasi yang bertujuan menyatukan metodelogi-

metodelogi berorientasi objek, organisasi tersebut dinamakan OMG (Object Modelling

Group). Pada tahun 1995 OMG merealisasi draf pertama dari UML (versi 0.8) dan pada

tahun 1997 UML versi 1.1 muncul dan sekarang versi terbaru dari UML adalah versi 2.0.

Pada tahun 1997 Booch, Runbaugh dan Jacobson menyusun tiga buku tentang UML. Sejak

saat itulah UML telah menjelma menjadi standar bahasa pemodelan untuk aplikasi

berorientasi objek.

Notasi Dasar UML

Actor

Actor adalah segala sesuatu yang berinteraksi langsung dengan sistem aplikasi komputer,

seperti orang, benda atau lainnya. Tugas actor adalah memberikan informasi kepada sistem

dan dapat memerintahkan sistem agar melakukan sesuatu tugas. Lihat Gambar 1 di bawah.

Gambar 1 Notasi actor pada UML

Class

Notasi utama dan yang paling mendasar pada diagram UML adalah notasi untuk

mempresentasikan suatu class beserta dengan atribut dan operasinya. Class adalah pembentuk



utama dari sistem berorientasi objek. Gambar 2 menunjukkan notasi dari class UML.

Gambar 2 Notasi class pada UML

Use Case

Use case adalah deskripsi fungsi dari sebuah sistem dari perspektif pengguna. Use case

bekerja dengan cara mendeskripsikan tipikal interaksi antara user (pengguna) sebuah sistem

dengan sistemnya sendiri melalui sebuah cerita bagaimana sebuah sistem dipakai. Urutan

langkah-langkah yang menerangkan antara pengguna dan sistem disebut scenario. Notasi use

case dapat di perlihatkan pada gambar dibawah berikut ini.

Gambar 3 Notasi use case pada UML

Diagram UML

UML merupakan sintak umum untuk membuat model logika dari suatu sistem dan digunakan

untuk menggambarkan sistem agar dapat dipahami selama fase analisis dan desain. UML

biasanya disajikan dalam bentuk diagram/gambar yang meliputi class beserta atribut dan

operasinya, serta hubungan antar class yang meliputi inheritance, association dan komposisi.

UML tediri dari banyak diagram, secara garis besar diagram yang terdapat pada UML dapat

diperlihatkan pada gambar dibawah ini :



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



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.



Nama Class

Attibute

Operasi

Gambar 7 Sebuah class dalam UML

Gambar 8 Contoh class diagram penjualan VCD

Activity Diagram

Activity diagram menggambarkan berbagai alir aktifitas dalam sebuah sistem yang sedang

dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi dan

bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang

mungkin terjadi pada beberapa eksekusi. Activity diagram tidak menggambarkan sifat internal

dari sebuah sistem dan interaksi antara beberapa sub sistem secara eksak, tetapi lebih

Class

1. Attribut : tipe

2. Operasi : tipe

Cabang

Nama Cabang

Pelanggan

Nama Pelanggan

Pembayaran

Jumlah

Tunai

JmlKembalian

Order

No

Tgl

Order Detail

Jumlah

Kartu Kredit

No

Item Barang

Nama Barang



menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum. Pada

UML 2.X aktivitas tidak lagi disebut sebagai activity, akan tetapi cukup disebut dengan

action saja. Activity adalah struktur yang lebih tinggi yang terdiri atas action-action yang

berurutan. Oleh karenanya activity diagram menunjukkan action-action yang membangun

sebuah aktivitas. Berikut adalah simbol-simbol yang digunakan pada activity diagram.

Tabel 1 Tabel Simbol Activity Diagram

Simbol Keterangan

Titik Awal

Titik Akhir

Activity

Pilihan untuk pengambilan keputusan

Fork; Untuk menunjukkan kegiatan yang dilakukan secara paralel

Rake; menunjukkan adanya dekomposisi

Tanda Waktu

Tanda Penerimaan

Aliran Akhir (Flow Final)

Start

Tidak membeli VCD

End

Gambar 9 Contoh activity diagram penjualan VCD

Sequence Diagram

Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem

(termasuk pengguna, display dan sebagainya) berupa message yang digambarkan terhadap

Datang ke gallery VCD

Memilih VCD yang dibeli

Petugas Keuangan

Bayar VCD yang dibeli



waktu. Sequence diagram terdiri atas waktu dan obyek-obyek yang terkait. Sequence diagram

biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang

dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu, proses dan

perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan.Gambar 10

menunjukkan esensi simbol dari sequence diagram dan simbol kerjanya secara bersama-

sama.

Actor

Objek

Message Lifeline

Gambar 10 Simbol-simbol yang ada pada sequence diagram

State Machine Diagram

Interaction diagram dan state chart menampilkan dua pandangan yang saling melengkapi

tentang perilaku dinamis sebuah sistem. Interaction diagram menunjukan pesan-pesan yang

dilewatkan diantara obyek-obyek didalam sistem selama periode waktu yang pendek.

Sedangkan state chart diagram menelusuri individu-individu obyek melalui keseluruhan daur

hidupnya, menspesifikasikan semua urutan yang mungki dari pesan-pesan yang akan di

terima objek tersebut bersama-sama dengan tanggapan atas pesan-pesan tersebut.

Simbol UML untuk state transition diagram adalah segiempat yang setiap pojoknya dibuat

rounded. Titik awalnya menggunakan lingkaran solid yang diasir dn diakhiri dangan mata.

Berikut adlah symbol UML untuk statechart.

Gambar 11 Simbol Statechart Diagram

Name 1 Name 2



UML juga memberi pilihan untuk menambahkan detail ke dalam simbol tersebut dengan

membagi menjadi 3 area yaitu nama state, state variable dan activity.

Gambar 12 Penambahan detail ke state

State variable seperti timer dan counter kadangkala sangat membantu. Activity terdiri atas

events dan action. Tiga hal yang sering dipakai disini adalah entry ( apa yang terjadi ketika

sistem masuk ke state), exit ( apa yang terjadi ketika sistem meninggalkan state) dan do ( apa

yang terjadi ketika sistem ada di state). Hal-hal lain bisa ditambahkan jika perlu.

Collaboration Diagram

Informasi yang disampaikan sama dengan sequencial diagram namun beda dalam

pengambaran dan kegunaan saja. Dalam diagram ini digambarkan hubungan antar objek dan

actor dengan tidak memperhatikan waktu/urutan.

Gambar 13 Colaboration diagram

Component Diagram

Component diagram mengandung componet, interface dan relationship. Notasi component

bisa dilihat pada gambar dibawah ini.

Nama

State Variable

Activities



Gambar 14 Contoh notasi component

Hal penting pada component adalah component mewakili potongan-potongan yang

independent yang bisa dipesan dan diperbaharui sewaktu-waktu. Dengan demikian,

pembagian sistem kedalam component-component lebih banyak didorong oleh kepentingan

marketing dari pada kepentingan teknis. Meskipun demikian harus juga diingat bahwa terlalu

banyak component juga kurang bagus, karena susah mengatur dan memeliharanya khususnya

menyangkut masalah versioning.

Component digunakan untuk menunujukan struktur fisik seperti DAN LAIN-LAIN. Hal

tersebut tidak terlalu benar sekarang, karena struktur fisik ditunjukan dengan artifact. Artifact

adalah manifestasi fisik dari software, biasanya file. File-file ini biasanya bisa

dieksekusi/executable (seperti: . EXE file, biner, DAN LAIN-LAIN, file JAR, Assembly atau

Script), atau file-file data, file-file konfigurasi, dokumen HTML dan lain-lain.

Component dihubungkan melalui interface yang diimplementasikan. Biasanya menggunakan

notasi ball-and-socket seperti class diagram. Component juga bisa dikompose dengan

menggunakan composite struktur diagram.

Gambar 16 menunjukan contoh component diagram. Pada contoh ini, seorang sales mesin

dapat berhubungan dengan component server sales, dengan menggunakan interface sales

message. Karena networknya tidak dapat dipercaya, component antrian pesan (queue)

dipasang sehingga masih tetap dapat berhubungan dengan server ketika server sedang hidup

dan berhubungan dengan queue ketika network mati. Selanjutnya queue berhubungan dengan

server ketika network sudah berfungsi kembali. Hasilnya queue message hasus bisa

mendukung interface sales message untuk berhubungan dengan component mesin dan

membutuhkan interface tersebut untuk berhubungan dengan server. Server dibagi menjadi 2

component utama. Prosesor transaksi untuk merealisasikan interface sales message dan

accounting driver untuk berhubungan dengan system akutansi.



Gambar 17 Contoh component diagram

Deployment Diagram

Deployment diagram menunjukan tata letak sebuah system secara fisik, menampakkan

bagian-bagian software yang berjalan pada bagian-bagian hardware. Bagian utama

hardware/perangkat keras adalah node; yaitu nama umum untuk semuah jenis sumber

komputasi. Ada 2 tipe node yang mungkin. Processor adalah node yang bisa mengeksekusi

sebuah component, sedangakan device tidak. Device adalah perangkat keras (seperti printer

atau monitor) tipikalnya menjadi interface dengan dunia luar.

Node mengandung artifact, dimana artifact adalah manifestasi fisik dari software; biasanya

file. File-file ini biasanya bisa dieksekusi/executable (seperti: .EXE file, biner, DAN LAIN-

LAIN, file JAR, Assembly atau script), atau file-file data, file-file konfigurasi, dokumen

HTML dan lain-lain. Daftar artifact di dalam sebuah node menunjukan bahwa artifact

tersebut di deploy ke node tersebut pada saat system sedang dijalankan. Di UML, kubus

menunjukan node. Node bisa diberi nama & ditambahkan stereotype untuk

mengidentifikasikan tipe resource yang ada sebelumnya. Jika node adalah bagian dari

package, namanya bisa mengandung nama package tersebut. Kubus bisa juga ditambahkan

kompartemen yang berisi informasi seperti component yang dideploy di node tersebut.

Jalur komunikasi diantara node menunjukan bagaimana mereka berkomunikasi. Jalur

tersebut bisa ditambahkan label yang menginformasikan protocol komunikasi apa yang

dipakai



Daftar Pustaka




McGraw Hill, 1992






MODUL PERKULIAHAN

ANALISA





09 87016 Tim Dosen

Abstract Kompetensi




Penggunaan Notasi UML

Modul ini akan membahas contoh penggunaan notasi-notasi UML didalam kasus

operasional perusahaan yang memerlukan data dan informasi yang cukup bagi pihak

perusahaan sebagai dasar pengambilan keputusan strategis dan operasional dalam

rangka memenangkan persaingan dan untuk meningkatkan omzet pendapatan perusahaan

tersebut.

Pada bab tiga ini diuraikan tentang tahap pengembangan sistem diantaranya adalah

pemodelan bisnis, analisis, perancangan, pengujian dan implementasi sistem, sistem

pengiriman (delivery) pada PT X

Bahan dan Alat

Bahan penelitian yang digunakan adalah data paket atau dokumen yang akan dikirim, data

pengirim dan alamat tujuan barang akan dikirim serta bukti atau nota pengiriman. Peralatan

diperlukan untuk mendukung penelitian dan mengoperasikan aplikasi antaralain digolongkan

menjadi :

Perangkat Keras.

Perangkat keras adalah seperangkat alat atau komponen yang akan digunakan untuk

membentuk suatu sistem komputer :

1. CPU (Central Processing Unit).

CPU merupakan pusat pengolahan dan juga pusat pengontrolan dari

sebuah sistem komputer yang saling melaksanakan kegiatan.

2. Floppy Disk.

Floppy Disk adalah alat penggerak untuk membaca atau untuk merekam

data dari atau ke media penyimpanan disket.

3. Harddisk.

Hard Disk adalah media penyimpanan data yang terbuat dari piringan

keras yang dilapisi dengan zat magnetik. Harddisk dapat menyimpan

data lebih banyak dan mempunyai kecepatan yang tinggi dalam

pengambilan dan penyimpanan data.

4. Keyboard.

Keyboard adalah alat input yang biasanya didampingi dengan alat

tampilan (display) di layar yang menampilkan apa yang ditekan di

keyboard.



5. Video Display Unit (VDU)

VDU adalah alat yang digunakan untuk komunikasi interaktif antara

manusia dengan komputer yang berupa tampilan visual.

6. Mouse

Mouse adalah alat input komputer yang digunakan oleh berbagai

program aplikasi GUI ( Graphcal User Interface ) dengan petunjuk posisi

yang ditampilkan melalui monitor.

7. Printer

Printer adalah alat yang digunakan untuk mencetak keluaran baik berupa

tulisan, grafik atau gambar pada media kertas.

Perangkat Lunak

Perangkat lunak merupakan bagian dari suatu sistem pengolahan data yang digunakan

untuk mengaktifkan fungsi dari perangkat keras komputer. Perangkat lunak yang dibutuhkan

pada sistem usulan adalah sebagai berikut :

1. Sistem Operasi

Sistem operasi yang disarankan minimal Windows 98.

2. Program Aplikasi.

Merupakan perangkat lunak yang akan digunakan dalam pembuatan

program sistem usulan diantaranya adalah aplikasi databases MySQL,

aplikasi Java jdk-1_5_0_02-windows-i586-p.exe dan aplikasi

penghubung (connection) antara aplikasi database dan aplikasi compiler

java yaitu mysql-connector-java-5.0.3-bin.jar.

Kasus menggunakan pendekatan pemodelan bisnis dan objek, model ini berkosentrasi pada

lingkup bisnis di perusahaan yang akan kita rancang sistemnya. Terlebih dahulu kita harus

melakukan pemeriksaan-pemeriksaan pada bisnis itu sendiri: entitas-entitas yang

berinteraksi dengan bisnis serta aliran-aliran kerja dalamnya. Metode pengembangan sistem

penulis menggunakan metodologi Berorientasi Objek dan menggunakan perkakas utama

dalam analisis dan perancangannya menggunakan notasi Unified Modeling Language

(UML).

Pemodelan Bisnis

Pengembangan sistem/perangkat lunak bisnis menuntut kita melakukan pemodelan bisnis

yang berkosentrasi pada lingkup bisnis diperusahaan yang akan kita rancang sistemnya.

Terlebih dahulu kita harus melakukan pemeriksaan-pemeriksaan pada bisnis itu sendiri:



entits-entitas yang berinteraksi dengan bisnis serta aliran-aliran kerja di dalamnya. Sangat

penting untuk memahami bisnis itu sendiri. Kita seharusnya melakukan penelahan sistem

secara seksama dengan cara melakukan pencarian data dengan pihak yang terlibat serta

ditambah dengan melakukan studi-studi literature.

Fungsi Pemodelan Bisnis

Pemodelan bisnis adalah studi tentang organisasi/perusahaan. Selama proses pemodelan

bisnis, kita melakukan pemeriksaan struktur organisasi/perusahaan dan mencari peran-

peran penting dalam organisasi/perusahaan dan bagaimana mereka saling berhubungan.

Ada beberapa alasan untuk melakukan pemodelan bisnis. Alasan utama adalah untuk

memahami organisasi, sistem yang saat ini bekerja di organisasi yang bersangkutan, serta

perangakat lunak yang saat ini dimilikinya. Tahapan yang terdapat pada tahap ini antara lain

terdiri dari beberapa penentuaan kosep-konsep dasar pemodelan bisnis.

Identifikasi Aktor Bisnis

Sesungguhnya, sebelum kita memulai segala sesuatunya menyangkut pengembangan

sistem/perangkat lunak, pertama kali kita harus menentukan aktor-aktor bisnis, kita

seharusnya melihat pada lingkup proyek dimana sistem kita akan dikembangkan serta

berusaha menentukan apa yang ada diluar linkup-lingkup proyek kita. Dalam hal ini penulis

mendefiniskan bahwa yang dapat menjadi sebagai aktor bisnis adalah pelanggan (pengirim)

yang menggunakan jasa pengiriman tersebut. Dalam UML, aktor bisnis digambarkan

sebagai berikut :

Gambar 1 Pelanggan (Pengirim)

Identifikasi Pekerja Bisnis

Untuk mengidentifikasi pekerja-pekerja Bisnis, sekali lagi kita harus melihat pada lingkup

proyek kita. Jika kita berusaha memodelkan bisnis secara terbatas, suatu diagram struktur

organisasi mungkin merupakan suatu awal untuk memulai. Pertimbangan setiap peran

dalam struktur organisasi itu alih-alih posisinya. Pertimbangkan bahwa seseorang mungkin

memiliki peran-peran yang berbeda dalam bisnis tersebut. Dalam hal ini penulis

mendefiniskan bahwa yang dapat menjadi model pekerja bisnis antara lain : petugas entri,

dan kurir (pengantar barang). Dalam UML, pekerja bisnis digambarkan sebagai berikut :



Gambar 2. Petugas entry Gambar 3. Kurir (pengantar

barang)

Identifikasi Use Case Bisnis

Untuk mengidentifikasi use case bisnis, kita bias memulainya dari pernyataan visi dan misi

organisasi, yang merupakan peringkat tertinggi dari sasaran bisnis dalam menciptakan nilai-

nilai tertentu bagi lingkungannya. Misalnya dalam perusahan yang menjadi tempat riset bagi

penulis, perusahaan tersebut bergerak dibidang pengiriman barang. kita kemudian berusaha

memikirkan apa yang dibutuhkan dalam upaya perusahaan itu mengantarkan barang

ketujuan. Pertama kali, perusahaan tersebut harus memiliki mekanisme yang

memungkinkan pengirim untuk melakukan transaksi, mekanisme selanjutnya adalah

pembuatan nota pembayaran. Kemudian mekanisme selanjutnya adalah pengiriman

panagantaran barang yang akan dikirim, setelah itu barang yang telah di kirim dilakukan

verifikasi lebih lanjut. Dari apa yang kita definsikan dari problem yang terdapat pada

perusahaan, kita mungkin dapat menemukan beberapa use case bisnis, yaitu : transasksi,

pembayaran, pengiriman dan verifikasi.

Diagram Use Case Bisnis

Setelah kita dapat menentukan aktor-aktor bisnis, pekerja-pekerja bisnis, serta use case

bisnis, maka langkah selanjutnya adalah menggambarkan diagram use case bisnis yang

memperlihatkan interaksi-interaksi yang terjadi di antara mereka. Suatu tanda panah yang

berarah dari pekerja bisnis ke use case bisnis mengambarkan bahwa pekerja bisnis

memulai proses tertentu yang dilakukan dengan use case. UML, pekerja bisnis digambarkan

sebagai berikut :



Gambar 3.4. Diagram use case bisnis

Analisis

Definisi analisis sistem menurut DeMarco [De Marco, 1978], “ The study of a problem, prior

to taking some action”. Analisis sistem adalah mempelajari suatu masalah dan mempunyai

tujuan utama untuk melakukan tindakan. Analisis sistem merupakan proses menentukan

kebutuhan sistem – apa yang harus silakukan sistem untuk memenuhi kebutuhan klien,

bukanlah bagaimana sistem tersebut diimplementasikan.

Identifikasi Masalah

Sebuah perusahaan yang bergerak dibidang pengiriman barang, memberikan sebuah

pelayanan jasa berupa jasa pengiriman barang berupa dokumen dan paket. Didalam

proses bisnisnya, dimulai saat seorang pelanggan (pengirim) melakukan pengiriman sebuah

dokumen atau paket keperusahaan tersebut. Oleh petugas yang bertugas memasukan

(entry) data, transaksi itu dicatatat. Dengan ketentuaan yang telah ditetapkan sebelumnya

data-data dicatat dan disimpan sesuai keterangan dan informasi yang didapat.

Kemudian petugas melakukan perhitungan pembayaran, saat pembayaran dilakukan

petugas akan memproses apakah tagihan langsung dibuat atau akan ditagihkan pada suatu

periode tertentu. Dengan ketentuan sebelumnya bahwa pelanggan yang sudah menjadi

member, proses pembayarannya dapat dilakukan dengan membuat nota tagihan untuk

pembayaran suatu periode tertentu, data yang terdapat pada tagihan tersebut merupakan

kumpulan dari beberapa transaksi yang dilakukan dalam satu periode.



Setelah selesai melakukan proses transaksi tersebut, document atau paket tersebut mulai

dilakukan proses pengiriman ketujuan. Dokumen atau paket tersebut akan dikirim ketujuan

sesuai dengan keterangan informasi yang terdapat pada nota transaksi.

Untuk memberikan pelayanan lebih kepada pelanggan, pelanggan diperbolehkan

melakukan klaim bila didapatkan suatu problem yang menyangkut tentang proses

pengiriman dokumen atau paket yang dikirimkan. Proses klaim dapat dilakukan dan dapat

dikatakan sah apabila transaksi tersebut belum dibuat tagihan dan memenuhi beberapa

kententuan atau perjanjian yang telah disepakati sebelumnya.

Diagram Konteks

Gambar 3.5. Diagram konteks

Identifikasi Use Case dan Aktor

Pada bagian ini kita mulai melakukan proses pencarian atau penentuan beberapa

kebutuhan dasar didalam membentuk use case. Aktor dan use case ditentukan atas dasar

kenutuhan fungsi-fungsi. Kebutuhan fungsi ini diakomodir di use case. Selanjutnya use case

menyediakan nilai hasil kepada aktor. Atas dasar spesifikasi diatas paling tidak kita dapat

menemukan aktor.

Use case, seperti kita ketahui sebelumnya, mencakup aliran-aliran kerja (workflow) dalam

sistem (bersifat internal) sedangkan aktor-aktor mencakup segala sesuatu yang ada diluar

sistem (bersifat eksternal). Tentu saja ada perbedaan antara use case dan aktor yang

sedang kita bahas saat ini dengan use case bisnis dan aktor bisnis (juga pekerja bisnis)

yang telah kita bahas sebelumnya. Perbedaan-perbedaan itu akan kita bahas sekilas pada

tabel di bawah ini (Tabel 3.1).



Table 1 Perbedaan objek-objek dalam model bisnis dan model sistem.

Nama Objek Model Bisnis Model Sistem

Use Case Mendeskripsikan apa

yang dikerjakan

perusahaan.

Mendeskripsikan sistem

yang akan/sedang

dikembangkan dalam

perusahaan.

Aktor Bersifat eksternal

terhadap perusaan

Bersifat eksternal terhadap

sistem yang akan/sedang

dikembangkan

Pekerja Bisnis Bersifat internal dalam

perusahaan

Tidak digunakan

Untuk mendeskripsikan use case apa saja dan aktor yang akan terlibat dalam use case

tersebut, biasanya digunakan tabel seperti tabel 3.1 Untuk itu bisa dilihat kembali spesifikasi

sistem diatas.

Tabel 2 Requirement aktor dan use case

No Requirement Aktor Use Case

1 Operator Data Entry melakukan

verifikasi user untuk menggunakan

sistem

Operator Data

Entry

Proses Login

(verifikasi user)

2 Operator Data Entry melakukan input

proses transaksi pengiriman yang

berisi data pengirim dan tujuan

penerima

Operator Data

Entry

Transaksi

pengiriman,

Input Data

Pengirim, Input

Data Penerima

3. Sesudah data dan informasi dengan

benar maka operator data entry

membuat nota pembayaran dari suatu

transaksi terebut

Operator Data

Entry

Pembayaran,

Tagihan

4 Dengan sudah masuknya semua data

ke database computer, proses

selanjutnya adalah membuat laporan

berkala yang diperlukan untuk

keperluan-keperluan lain yang

berhubungan dengan proses yang

Operator Data

Entry

Buat Laporan,

Laporan Data

Pengirim ,

Laporan Data

Penerima,

Laporan Data



berlangsung di perusahaan tersebut. Transaksi,

Laporan Data

Tagihan

5. Untuk melakukan tugas lainnya maka

diperlukan pegawai lainnnya, oleh

karena itu diperluka pendataan

pegawai dengan benar.

Data Pegawai

Selanjutnya atas dasar tabel diatas dibuat use case diagram. Sebagai catatan

bahwa suatu proses penambahan data pengirim dan peneriman dapat dilakukan

secara langsung pada form data pengirim atau form data penerima, selain itu dapat

dilakukan pada saat proses transaksi terjadi. Untuk keterangan dan penjelasan lebih

lengkap dapat dilihat pada gambar diagram use case berikut ini :

Gambar 6 Diagram use case diagram

&&&&&&&&&



Daftar Pustaka




McGraw Hill, 1992






MODUL PERKULIAHAN

ANALISA





10 87016 Tim Dosen

Abstract Kompetensi




Diskripsi Use Case Setiap use case di atas harus dideskripsikan dalam dokumen yang disebut dengan dokumen

flow of event. Dokumentasi ini mendefisikan apa yang harus dilakukan oleh sistem ketika

aktor mengaktipkan use case. Struktur dari dokumen use case ini bisa bermacam-macam,

tetapi umumnya deskripsi ini paling tidak harus mengandung : (sumber Quantrani, 2000).

Brief Description (deskripsi singkat).

Aktor yang terlibat.

Precondition yang penting bagi use case untuk memulai.

Deskripsi rinci dari aliran kejadian yang mencakup :

Main Flow dari kejadian yang bisa dirinci lagi menjadi

SubFlow dari kejadian (Sub flow bisa di bagi lagi lebih jauh menjadi

sub flow yang lebih kecil agar dokumen lebih mudah dibaca dan

dimengerti).

Alternative Flow untuk mendefinisikan situasi perkecualian

Postcondition yang menjelaskan state dari sistem setelah use case

berakhir.

Selain hal diatas kita juga boleh memakai beberapa deskripsi tambahan untuk

melengkapi pendeskripsian use case yang kita buat. Setelah pembuatan use case pada

sub bab sebelumnya kini kita akan menjelaskan spesifikasi use case yang telah kita

tentukan.

Tabel 3 Spesifikasi naratif untuk use case login tingkat analisis

Use case name Login

Aktor Operator Data Entry

Brief

Description

Use case ini merupakan awal dari semua kegiatan

yang terjadi. Operator Data Entry ingin Login

terhadap sistem dengan menginputkan data user

name dan password, maka sistem akan memvalidasi

user name dan password tersebut.

Exception Jika dalam verifikasi user tidak ditemukan berati

tidak berhak untuk menggunakan sistem.



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 1. Pengirim ingin melakukan pengiriman

dokumen atau paket.

2. Operator Data Entry mulai melakukan input

data yang dibutuhkan sebagai bahan

informasi berikutnya.

3. Sistem akan memproses data yang telah

diinputkan sesuai dengan ketentuan yang

berlaku.

4. Setelah itu data yang telah di inputkan akan

disimpan untuk menjadi sumber informasi



yang dibutuhkan untuk proses nantinya.

Alternatif flow Jika data yang dibutuhkan tidak sesuai atau kurang

lengkap maka perlu dilakukan verifikasi lebih lanjut

kepada pengirim.

Pre condition 1. Operator data entry harus login terlebih

dahulu.

2. Data yang diperlukan sudah tersedia dan

sesuai.

Post condition Data transaksi telah tersimpan

Tabel 5 Spesifikasi naratif untuk use case input data pengirim tingkat analisis

Use case name Input Data Pengirim


Brief

Description

Walaupun sebenarnya data pengirim secara tidak

langsung telah diimputkan dan disimpan saat

melakukan transaksi. Tetapi untuk mendapatkan

keterangan yang lebih terperinci data pengirim

maka diperlukan use case ini. Use case ini

merupakan tempat untuk melakukan penambahan

atau mengedit data pengirim.

Exception Data pengirim yang akan dimasukan sudah tersedia

dan sudah sesuai dengan ketentuan.

Basic Flow 1. Operator data entry dapat menambahkan

atau mengedit data yang telah tersimpan

untuk menambahkan rincian informasi .

2. Operator data entry mulai melakukan input





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 .






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 .






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 1. Proses pembayaran atas transaksi yang

dilakukan diproses secara berkala (per

periode) atau secara langsung .



pemrosesan tagihan.

3. 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 1. Proses pembuatan laporan dilakukan

bertujuan untuk mengetahui seberapa

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

Exception Data tagihan didapat dari data transaksi yang akan

dimasukan sudah tersedia dan sudah sesuai dengan

ketentuan.

Basic Flow 1. Proses pembuatan laporan tagihan

dilakukan bertujuan untuk mengetahui

seberapa banyak tagihan yang didapat dari

beberapa transaksi dalam satu periode

tertentu.







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


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 1. Proses pembuatan laporan pengirim

dilakukan bertujuan untuk mengetahui

seberapa banyak data pengirim yang telah

tesimpan didalam sistem tersebut









memproses data.



berlaku.







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

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 Teknik Informatika apapun. Biasanya analisis kebutuhan

digunakan untuk menemukan class entity ini. Akan tetapi, untuk bisa menjalankan sistem

secara benar, sistem membutuhkan class-class yang mendefinisikan objek-objek GUI (seperti

form layer) yang disebut dengan class boundary. Sistem juga membutuhkan class-class yang

mengontrol logika program yang disebut dengan class control. Namun biasanya pemodelan

kedua class yang terakhir ini dilakukan saat memasuki fase perancangan, bukan fase analisis.

Tabel berikut menjelaskan cara pencarian kandidat class entity pada Aplikasi Pengiriman

Barang pada PT. X

Tabel 13 Kandidat class entity pada aplikasi pengiriman barang pada PT. X

No Requirement Class Entity

1. Operator Data Entry ingin Login terhadap sistem

dengan menginputkan data user name dan

password, maka sistem akan memvalidasi user

name dan password tersebut

Operator Data Entry

(Data User).

2. Transaksi terjadi saat pelanggan ingin melakukan

pengiriman dokumen atau paket menggunakan jasa

perusahaan tersebut kebeberapa kota tujuan dengan

berbagai bentuk pilihan jenis dan sifat pengiriman.

Transaksi, Jenis

Pengiriman dan Sifat

Pengiriman

3. Saat melakukan transaksi tentu saja dibutuhan

beberapa data, untuk itu diperlukan data pengirim

dan data penerima. Sehingga barang yang dikirim

terdapat keterangan siapa pengirimnya dan

keterangan penerimanya

Data Pengirim, Data

Penerima

4. Setelah proses memasukan data yang dibutuhkan

saat transaksi tersebut, maka akan diproses

pembayaran yang berlangsung saat itu apakah

secara tunai atau dibuat tagihan.

Pembayaran

5. Pada saat proses pembayaran yang dilakukan tidak

secara langsung (dibuatkan tagihan) bila pelanggan

tersebut sudah menjadi member dari perusahaan

tersebut. Tagihan akan ditagihkan menurut

periodenya dan berisi data trasaksi selama periode

Tagihan



tersebut

Langkah selanjutnya adalah membuat class diagram. Dengan mengacu pada ilustrasi tabel

diatas maka kita bisa melakukan pemodelan diagram class tersebut.

Gambar 7 Class Diagram



Daftar Pustaka




McGraw Hill, 1992






MODUL PERKULIAHAN

ANALISA





11 87016 Tim Dosen

Abstract Kompetensi




Perancangan Sistem Setelah membahas analisis sistem, maka tiba saatnya untuk membahas desain (perancangan)

sistem. Pada perancangan aplikasi penulis akan menggunakan tool UML dengan membangun

diagram-diagram yang akan digunakan pada sistem. Pada perancangan ini penulis hanya

membangun beberapa diagram saja. Proses perancangan bertujuan untuk :

Menggambarkan secara detail komunikasi antar objek

Menentukan objek-objek pendukung lain selain objek-objek domain persoalan.

Menentukan pemilahan sistem.

Menentukan ciri objek secara detail.

Menetapkan penggunaan objek-objek pustaka yang telah tersedia.

Selain itu untuk mengembangkan model perancangan, kita harus mengidentifikasi dan

menyelidiki konsekuensi pada lingkungan implementasi akibat langkah-langkah

perancangan. Semua keputusan-keputusan strategis perancangan, misalnya bagaimana

DBMS akan digunakan, bagaimana komunikasi proses dan penaganan kesalahan (error

handler) akan dicapai, pustaka komponen apa yang akan digunakan ulang (reusable

component) harus dibuat. Kemudian, kita menggunakan keputusan-keputusan itu untuk

beradaptasi dengan lingkungan implementasi. Shlaer dan Mellor membuat pendefinisan yang

membedakan antara problem dan solusi, apa dan bagaimana atau analisa dan desain [Coad,

1991]. Desain berorientasi objek mempunyai tiga dasar ,yaitu :

1. Notasi. Notasi digunakan untuk memberikan gambaran tentang gagasan sistem

kepada anggota team yang lain dan pihak lain yagn memerlukan.

2. Strategi. Setiap proyek tidak harus dimulai dari awal seperti pada saat memikirkan

untuk memecahkan persoalan. Desain untuk problem domain yang biasa ditemui

dapat digunakan untuk pemecahan masala.

3. Kriteria yang baik. Evaluasi suatu desain dapat dilakukan secra obyektif dengan

melihat apakah diterima, ditolak atau direvisi.

Pada tahap perancangan objek, kita mendefinisikan bagaimana analisis berorientasi

aplikasi akan direalisasikan pada lingkungan implementasi. Jacobson(1992) (dikutip dari

buku Modern Database Management, tulisan Fred McFadden, dkk) menyebutkan 3 alasan

utama mengapa kita menggunakan pendekatan perancangan berorientasi objek. Alasan-alasan

itu adalah :



1. Model analisis pada analisis dengan metoda terstruktur tidak cukup formal untuk

diimplementsikan secara langsung ke bahasa pemrogrman. Untuk

menterjemahkan ke kode computer, kita perlu melakukan langkah-langkah

penghalusan (refinement) dengan membuat keputusan-keputusan pada operasi

apa yang objek akan lakukan, bagaimana seharusnya komunikasi antara objek-

objek dalam suatu sistem dilakukan, pesan apa yang harus dilewatkan, dan apa

sebagainya.

2. Sistem nyata harus diadaptasi ke lingkungan dimana sistem kelak akan

diimplementasi. Dalam hal ini, perlu dilakukan modifikasi-modifikasi model

analisis ke beberapa faktor yang berbeda seperti kebutuhan kinerja, perangkat

keras target dan perangkat lunak sistem, DBMS (Database Management Sistem),

bahasa pemrograman yang akan digunakan, dan sebagainya.

3. Hasil analisis dapat divalidasi menggunakan perancangan berorientasi objek pada

tahap ini, kita daapat memverifikasi apakah hasil dari analisis sesuai untuk

membangun sistem dan kemudian, jika tidak sesuai, kita kembali secara iterative

ke tahap analisis, serta membuat perubahan yang perlu pada model analisis.

Untuk mengembangkan model perancangan, kita harus mengidentifikasi dan menyelidiki

konsekuensi pada lingkungan implementasi akibat langka-langkah perancangan. Semua

keputusan strategis perancangan, misalnya bagaimana DBMS akan digunakan, bagaiman

komunikasi proses dan penanganan kesalahan (error handler) akan dicapai, pustaka

komponen apa yang harus dibuat. Kemudian. Kita menggunakan keputusan-keputusan itu

untuk mendeskripsikan bagaimana objek-objek berinteraksi satu sama lain lewat suatu

sknario (use case) yang telah kita kembangkan sebelumnya.

Deskripsi Use Case Tingkat Perancangan

Tabel 1 Spesifikasi naratif untuk use case login tingkat perancangan

Use case name Login


Brief

Description

Operator Data Entry ingin Login terhadap sistem

dengan menginputkan data user name dan

password, maka sistem akan memvalidasi user

name dan password tersebut.



Exception Jika salah dalam mengimputkan user dan password

maka sistem tidak akan menampilkan menu utama

(main form).

Basic Flow 1. Tampilkan Form Login

2. Operator Data Entry meninputkan User

name.

3. Operator Data Entry menginputkan

Password

4. Operator Data Entry mengirimkan User

name dan Password dengan memilih tombol

Login agar sistem memvalidasi User name

dan Password tersebut.

5. Sistem memvalidasi User name dan

Password tersebut.

6. Sistem menampilkan informasi, jika User

name dan Password yang diinputkan benar

maka sistem akan menampilkan Form menu

utama, tetapi jika salah maka sistem akan

menampilkan pesan error.

Alternatif flow Jika dalam menginputkan User name dan Password

salah maka sistem akan menampilkan pesan error

dan memintanya untuk mengisi kembali

Pre condition Operator Data Entry harus mengetahui User name

dan Password

Post condition Tampil form Menu Utama

Tabel 2 Spesifikasi naratif untuk use case transaksi pengiriman tingkat perancangan

Use case name Transaksi Pengiriman


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 1. Operator Data Entry menampilkan data

transaksi dengan memilih menu proses

Transaksi

2. Sistem secara otomatis akan menampilkan

form tesebut yang berisi data nomor

transaksi .

3. Operator Data Entry menginputkan data-data

pada space yang telah ditentukan dengan

benar.

4. Sistem akan mengontrol setiap entri yang

masuk apakah sesuai dengan ketentuan.

5. Bila semua data yang dimasukan telah benar

maka Operator Data Entry dapat menyimpan

data tersebut dengan menekan tombol save.

6. Sistem akan menyimpan data transaksi

tersebut.

Alternatif flow Jika dalam pengisian data transaksi tidak lengkap

maka sistem akan menampilkan pesan kesalahan

dan meminta kepada Operator Data Entri untuk

mengisi informasi yang dibuthkan terlebih dahulu.

Operator Data Entry bisa memilih Reset(atau nama

lain yang sejenis) untuk mengosongkan form

transaksi.

Pre condition Operator Data Entry harus login terlebih dahulu.

Data transaksi yang akan dimasukan sudah tersedia

dan sesuai.

Post condition Jika use case sukses dijalankan, maka data akan

dicatat di database sistem. Jika tidak status tidak

berubah.



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 1. 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.






6. 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

penerima telah ditentukan.

Basic Flow 1. Untuk menambahkan, menghapus dan

mengedit data penerima maka dapat


menu Record Data Penerima.


form tesebut yang berisi data penerima yang

sebelumnya telah tersimpan.



benar.








6. 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.



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

Sistem akan menyimpan data Karyawan

tersebut.

Alternatif flow Jika dalam pengisian data karyawan tidak lengkap






penerima.

Pre condition Operator data entry harus login terlebih

dahulu.

Data yang diperlukan sudah tersedia dan

sesuai.

Post condition Data karyawan telah tersimpan

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

Perancangan



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.


form tesebut.



benar.




maka Operator Data Entry dapat memproses

data tersebut dengan menekan tombol Ok

(atau nama lain yang sejenis) .

Sistem akan menyimpan data tagihan

tersebut.

Alternatif flow Jika dalam pengisian data tagihan tidak lengkap



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



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

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.

2. Operator data entry mulai memproses



Laporan.




memproses data.





berlaku.







dahulu.


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.







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.






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



b. Entity Class

Entity class memelihara informasi-informasi yang mungkin akan kita

simpan di tempat penyimpanan yang persisten (Objek persisten adalah objek

yang tetap hadir saat perangkat lunak berakhir). Representasi UML untuk

entity terlihat pada Gambar di bawah ini.

Gambar 2. Entity class

c. Control Class

Control class bertanggung jawab untuk mengkoordinasi upaya-upaya

yang dilakukan kelas-kelas lainnya. Mereka bersifat optional, tetapi jika

control class digunakan, mereka biasanya digunakan satu untuk setiap use

case, yang fungsinya adalah mengendalikan urutan-urutan event yang menglir

pada use case. Representasi UML untuk control terlihat pada gambar di

bawah ini.

Gambar 3. Control class

Tabel 11 Spesifikasi strereotype class tingkat perancangan

Class Boundary Class Control Class Entity

MainForm

FormLogin ProsesLogin (verifikasi user,

password).

Data_User

FormTransaksiPengiriman AddTransaksiPengiriman Transaksi



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.



Data_UserProsesLogin

KoneksiDatabase

FormLogin

MainForm

FormDataPenerima

FormLaporanPenerima

FormDataPengirim

FormLaporanPengirim

FormProsesTagihan

FormLaporanTagihan

FormDataKaryawan

FormTransaksiPengiriman

FormLaporanTransaksi

AddEditDataPenerima

ProsesLaporanPenerima

AddEditDataPengirim

ProsesLaporanPengirim

ProsesTagihan

ProsesLaporanTagihan

AddEditDataKaryawan

AddTransaksiPengiriman

ProsesLaporanTransaksi

Penerima

Pengirim

Tagihan

Karyawan

Sifat

Transaksi

Jenis

Gambar 4 Class diagram tingkat desain

Tabel 12 Daftar attribut dan operasi pada class tingkat perancangan

Class Attribut Operasi

MainForm <<Komponen

Tampilan Form>>

Tampilkan Form(frame :

JFrame)

KoneksiDatabase()

BelumLogin()

LoginSukses()

UnLoadWindow()

KonneksiDatabase koneksi_database()

load_DriverJDBC()

Connection koneksiDatabase()

getData()

getResourceBundle()

FormLogin <<Komponen FormLogin()



Tampilan Form>> Close Form()

ProsesLogin dataUser

dataPassword

Status

CheckUserPassword()

Check Status()

KoneksiDatabase()

ValidasiUserdanPassword()

Data_User NamaUser

Password

Status

ValidasiUserPassword()

FormDataPengirim <<Komponen

Tampilan Form>>

FormDataPengirim(frame :

JFrame)

CreateTable()

reloadRecord(scrSQL : string)

reloadRecord()

KoneksiDatabase()

Close()

AddEditDataPengirim <<Komponen

Tampilan Form>>

Add_Edit_Data_Pengirim(fra

me : JFrame)

listener_tombol()

tampilKode()

clearFields()

KoneksiDatabase()

dispose()

Pengirim KodePengirim

NamaPengirim

Alamat

Kota

NoTelpon

KodePos

Simpan()

Update()

SelectData()

Cetak()

FormDataPenerima <<Komponen

Tampilan Form>>

FormDataPenerima(frame :

JFrame)

CreateTable()


reloadRecord()



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

KoneksiDatabase()

Dispose()

Karyawan KodeKaryawan

NamaKaryawan

TglLahir

Alamat

Simpan()

Update()

SelectData()

Cetak()



Kota

NoTelpon

KontakPerson

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

Biaya

NamaKurir

SelectData()

Cetak()

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

Tampilan Form>>

FormLapPengirim()

KoneksiDatabase()

TampilkankeTabel()

Close()

ProsesLaporanPengirim InputKriteria()

KoneksiDatabase()

TambahListerner()

ProsesSelect()

Cetak()

getData()

FormLaporanTransaksi <<Komponen FormLapTransaksi()



Tampilan Form>> KoneksiDatabase()

TampilkankeTabel()

Close()

ProsesLaporanTransaksi InputKriteria()

KoneksiDatabasev

TambahListerner()

ProsesSelect()

Cetak()

getData()

FormLaporanTagihan <<Komponen

Tampilan Form>>

FormLapTagihan()

KoneksiDatabase()

TampilkankeTabel

Close()

ProsesLaporanTagihan InputKriteria()

KoneksiDatabase()

TambahListerner()

ProsesSelect()

Cetak()

getData()



Daftar Pustaka




McGraw Hill, 1992






MODUL PERKULIAHAN

ANALISA





12 87016 Tim Dosen

Abstract Kompetensi




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



Sequence Diagram untuk Use Case Transaksi Pengiriman

Gambar 3. Sequence diagram use case transaksi pengiriman



Sequence Diagram untuk Use Case Input Data Pengirim

Gambar 4. Sequence diagram use case input data pengirim



Sequence Diagram untuk Use Case Input Data Penerima

Gambar 5. Sequence diagram use case input data penerima



Sequence Diagram untuk Use Case Input Data Karyawan

Gambar 6. Sequence diagram use case input data karyawan



Sequence Diagram untuk Use Case Proses Tagihan

Gambar 7. Sequence diagram use case proses tagihan



Sequence Diagram untuk Use Case Laporan Transaksi

Gambar 8. Sequence diagram use case laporan transaksi



Sequence Diagram untuk Use Case Laporan Pengirim

Gambar 9. Sequence diagram use case laporan pengirim



Sequence Diagram untuk Use Case Laporan Penerima

Gambar 9. Sequence diagram use case laporan penerima



Sequence Diagram untuk Use Case Laporan Tagihan

Gambar 10. Sequence diagram use case laporan tagihan

State Machine Diagram

State Machine diagram biasanya digunakan untuk memodelkan perilaku dinamis suatu class

atau obyek. State machine diagram memperlihatkan urutan state yang dilalui sebuah obyek,

kejadian yang menyebabkan sebuah transisi dari suatu state atau aktivitas ke state atau

aktivitas yang lain, dan aksi yang menyebabkan perubahan state atau aktivitas.

State machine diagram khususnya digunakan untuk memodelkan taraf-taraf diskrit suatu

siklus hidup obyek, sedangkan activity diagram paling cocok digunakan memodelkan urutan

activitas duatu proses. State machine diagram digunakan untuk memodelkan obyek dari

semenjak dibuat sampai selesai. Pada kondisi ini tidak semua class akan mempunyai state

yang menarik untuk dibahas.



State Machine Diagram Pengirim

Gambar 11 State machine diagram pengirim



State Machine Diagram Tagihan

Gambar 12. State machine diagram tagihan



State Machine Diagram Transaksi

Gambar 13. State machine diagram transaksi

Diagram Activity

Activity diagram memodelkan alur kerja (work flow) sebuah urutan aktivitas pada suatu

proses. Diagram ini sangat mirip dengan flow chart karena kita dapat memodelkan prosedur

logika, proses bisnis dan alur kerja. Perbedaan utamanya adalah flow chart dibuat untuk

menggambarkan alur kerja dari sebuah sistem, sedangkan activity diagram dibuat untuk

menggambarkan aktivitas aktor.



Diagram Activity untuk Aplikasi Pengiriman Barang

Gambar 13. Diagram Activity untuk Aplikasi Pengiriman Barang

Component Diagram

Component diagram menggambarkan alokasi semua class dan objek ke dalam komponen-

komponen fisik di sebuah sistem software. Diagram ini memperlihatkan pengaturan dan

kebergantungan diantara komponen-komponen software seperti dinamik library link (DLL),

executable component dan lain-lain. Manfaat dari penggunaan component in adalah

penggunaan kembali (reusable) suatu component pada proyek lain tanpa harus melakukan

usaha yang berarti. Dengan demikian akan bisa menghemat waktu dan biaya dalam

pengembangannya. Pada permasalahan ini, diasumsikan akan memanfaatkan teknologi COM

(Component Objek Modeling) atau DCOM melalui DTS (Data Translation Service). Berikut

ini adalah gambaran layer untuk DTS tersebut.



Secara umum, business rule services mengandung class-class bisnis dari interface-

interface yang dipakai diaplikasi. Sedangkan class data translation akan menjdi

interface CRUD(Create, Read, Update, Delete). Adapun DASVC.DLL akan

menjalankan beberapa operation yaitu :

DARetrieve akan membuat connection string dan menjalankan sebuah query

Select.

DAQuery akan menjalanakan semua tipe query yang lain (Delete, Update dn

Insert).

Mengandung class-class bisnis seperti

pelangga, pengirim, penerima, transaksi dll.

Menangani aliran kerja dan

menyiapkan user interface yang gampang

dioperasikan.

Mengkomunikasikan class di layer in

i dengan layer DTS.

Business Rul

Data Translati

Data Acce

ss



Diagram Component Sebuah Sistem

Gambar 14. Diagram component sebuah system

Deployment Diagram

Deployment diagram menyediakan gambaran bagaimana sistem secara fisik akan terlihat.

Sistem terdiri dari node-node dimana setiap node diwakili untuk sebuah kubus. Garis yang

menghubungkan antara 2 kubus menunjukan hubungan diantara hardware dan bisa juga

processor (yang mengeksekusi component) atau execution environment (software yang

menjadi hsost atau mengandung software lain.



Penerapan Diagram Deployment

Gambar 3.27. Penerapan Deployment Diagram pada Sistem

&&&&&&



Daftar Pustaka




McGraw Hill, 1992






MODUL PERKULIAHAN

ANALISA





13 87016 Tim Dosen

Abstract Kompetensi




Menggunakan Rekayasa Web

Atribut pada Aplikasi dan Sistem Berbasis Web

Menurut Pressman (2005: 502) Web application berbeda dari kategori lainnya dalam

perangkat lunak komputer. Atribut yang mengikuti sangat banyak ditemui di dalam web

application adalah:

Network intensiveness,

Concurrency,

Unpredicable load,

Performance,

Availability,

Data driven,

Content sensitive,

Continuous evolution,

Immediacy,

Security,

Aesthetics,

Sedangkan yang termasuk ke dalam kategori aplikasi yang sering ditemui di dalam kerja

rekayasa web adalah:

Informational,

Download,

Customizeable,

Interaction,

User input,

Transaction-oriented,

Service-oriented,

Portal,

Database access,

Data warehouse.



Layer-layer WebApp Engineering

Rekayasa web dapat digambarkan ke dalam tiga layer yaitu:

process,

methods, dan

tools/technology.

Web Engineering Process

Proses rekayasa web mengambil filosofi pengembangan cerdas yang menekankan pada

pendekatan teknik kecenderungan yang mudah untuk menaikan pengiriman data dari sistem

yang berkembang. Proses umum dari framework yang dapat diaplikasikan untuk rekayasa

web adalah:

Customer communication,

web customer communication

Dalam proses rekayasa digolongkan ke dalam dua tugas besar, yaitu:

1. Business Analysis menetapkan konteks bisnis / organisasi untuk web application.

Dengan tambahan, :

a. stakeholder telah dikenali,

b. perubahan yang mungkin dalam lingkungan bisnis atau syarat yang harus dipenuhi

telah diprediksi, dan

c. integrasi antara web application dan aplikasi bisnis lainnya, database, dan fungsi

telah dikenali.

d. Formulation syarat-syarat aktivitas yang harus dipenuhi untuk semua stakeholder.

2. Planning, Rencana proyek untuk pengembangan applikasi web yang telah dibuat/telah

ada . Rencana tersebut terdiri dari :

a. task definition dan

b. jadwal kerja untuk jangka waktu relative pendek.

3. Modeling, Analisis rekayasa perangkat lunak konvensional dan tugas mendisain

yang disesuaikan untuk perkembangan web application, digabungkan, dan

kemudian dimasukkan ke dalam aktivitas modeling rekayasa web.



4. Construction, Menggunakan alat dan teknologi rekayasa web untuk membangun

aplikasi web yang telah dirancang.

5. Deployment, Pemasangan dan konfigurasi aplikasi disesuaikan dengan lingkungan

tempat dimana aplikasi akan dipasang dikirimkan kepada end-user, dan kemudian

memulai masa evaluasi.

Aktivitas dari framework ini dipilah kedalam sepasang tugas-tugas rekayasa web yang

disesuaikan menurut kebutuhan dari setiap framework rekayasa Web yang diterapkan

didalam proyek. Aktivitas dari lima akrifitas process yang meliputi :

Gambar 1 Web Engineering Process (Dari Pressman: 508)

Formulating Sistem Berbasis Web

Formulation adalah aktivitas komunikasi konsumen yang menemukan masalah yang akan

dipecahkan oleh web application :

1. Kebutuhan bisnis,

2. Tujuan dan kriteria keberhasilan proyek,

3. Kategorisasi end-user,

4. fitur dan fungsi utama, dan

5. tingkat interoperabilitas dengan aplikasi lainnya

Kelompok Web Engineering (Web Engineering Group)

1. Kelompok web engineering terdiri dari anggota kelompok yang punya spesialisasi



teknis dan non-teknis yang memungkinkan kelompok ini memiliki otoritas untuk

melakukan pengambilan keputusan.

2. Manajemen proyek dibutuhkan selama web engineering, perbedaannya adalah masa

tugas yang lebih singkat, dan boleh jadi otoritasnya tidak meliputi keseluruhan Teknik

Informatika organisasi.

Requirements analysis untuk WebApps

Requirements analysis untuk WebApps mencakup tiga tugas utama:

1. formulation,

2. requirements gathering, dan

3. analysis modeling.

Selama formulation, tujuan utama dan obyek untuk WebApp telah diidentifikasi, dan kategori

dari user ditemukan. Sejak requirements gathering dimulai, komunikasi diantara tim Web

ngineering dan WebApp stakeholder semakin erat. Formulation, requirement gathering, dan

analysis modeling dilakukan untuk dapat melakukan identifikasi kebutuhan user yang akan

diterapkan/dipenuhi oleh web application :

1. Hirarki User. Kategori dari end-users yang berinteraksi dengan WebApp diidentifikasi

sebagai bagian dari tugas-tugas formulation dan equirements gathering.

2. Kategorisasi user (sering disebut actors) memberikan petunjuk pada fungsionalitas

untuk diberikan oleh WebApp dan menunjukan kebutuhan user yang digambarkan

dengan use-case yang dibangun untuk setiap end-user (actor) yang ditulis secara

hirarki.

3. Membangun Use-Cases. Menurut Franklin [FRA01] dalam pressman: 542,

menyatakan bahwa use-cases sebagai “bundles of functionality”. Deskripsi ini

memperlihatkan esensi dari pentingnya teknik analysis modeling. Use-case dibangun

untuk setiap kategori user yang digambarkan di dalam hirarki user. Di dalam konteks

Web engineering, use-case itu sendiri cenderung informal – paragraf narasi yang

menggambarkan interaksi spesifik diantara user dan WebApp.

4. Menemukan kembali Use-Case Model. Sebagaimana use-case Diagram dibuat untuk

setiap kategori user, use-case adalah katalisator untuk semua syarat aktivitas analisis

dan pemodelan. Use-cases diatur ke dalam package-package dan setiap package

dinilai untuk memastikan bahwa use-case:



5. Comprehensible (Lengkap), Semua stakeholder mengerti tujuan dari package.

5. Cohesive, fungsi alamat package yang berhubungan dekat satu dengan lainnya.

5. Loosely coupled, fungsi atau kelas dalam package bekerjasama satu

dengan lainnya, tetapi kerjasama ketergantungan antar package dijaga tetap

minimum.

5. Hierarchically shallow, fungsional hierarki yang terdalam sulit untuk mengontrol

dan susah bagi end-user untuk mengerti; oleh karena itu, jumlah dari tingkatan

dalam hirarki use-case seharusnya diminimalkan jika dimungkinkan.

Content Model

Content model menggambarkan spectrum dari content obyek yang dimasukkan kedalam web

application. Content obyek ini harus dibangun atau diperoleh untuk penggabungan ke dalam

arsitektur web application. Pohon data dapat digunakan untuk mewakili content hirarki

obyek. Kelas analisis (berasal dari use-case) memberikan arti lain untuk mewakili kunci

obyek bahwa web application akan dimanipulasi.

Interaction Model

Interaction model disusun dengan use-cases, UML sequence diagrams, dan UML state

diagrams untuk menggambarkan percakapan diantara user dan web application. Sebagai

tambahan, bentuk dasar antar muka mungkin dibangun untuk membantu dalam

pengembangan layout dan keperluan navigasi. Sebagian besar dari web application

membolehkan percakapan antara end-user dan fungsionalitas aplikasi, isi, dan perilaku.

Interaction model terdiri dari empat elemen yaitu:

1. Use-cases, Adalah elemen yang dominan dari interaction model untuk web

application. Sudah umum menggambarkan 100 atau lebih use-cases ketika sangat

besar, web application yang kompleks yang dianalisis, didisain, dan dibangun.

Bagaimanapun, persentase yang kecil secara relative use-cases ini menggambarkan

sebagian besar interaksi antara end-user categories (aktor) dan sistem. Use-cases

lainnya memperbaiki interaksi, memperbaiki secara rinci analisis yang diperlukan

untuk panduan pada disain dan pembangunan.



2. Sequence diagrams, UML sequence diagrams memberikan gambaran singkat dari cara

yang mana aksi user (elemen dinamis dari sistem yang didefinisikan oleh use-cases)

bekerjasama dengan kelas analisis (elemen structural dari sistem yang didefinisikan

oleh kelas diagram). Kelas harus dapat dijejaki ke use case.

3. State diagrams, UML state diagrams memberikan gambaran lain dari perilaku dinamis

web application sebagai interaksi yang terjadi. Seperti kebanyakan gambaran

modeling digunakan di dalam rekayasa web (atau rekayasa perangkat lunak), state

diagram dapat digambarkan dengan perbedaan tingkatan dari abstraksi.

4. User interface prototype, Tata ruang dari user interface, isinya ditampilkan, ekanisme

interaksinya dilaksanakan, dan estetika secara keseluruhan dari hubungan user dengan

web application telah banyak dilakukan dengan kenyamanan user dan dukungan

secara keseluruhan dari web application.

Functional Model

Functional model menggambarkan user dapat mengamati fungsi dan kelas operasi

menggunakan UML activity diagram. Functional model memanggil dua proses elemen dari

web application, setiap penggambaran berbeda tingkatan dari prosedure abstraksi:

1. User dapat mengamati fungsionalitas yang dikirimkan web application kepada end-

user,

2. Operation diisi dalam kelas analisis yang melaksanakan perilaku bersahabat dengan

kelas.

Configuration Model

Configuration model menggambarkan lingkungan yang web application akan digunakan

pada sistem berbasis server dan berbasis klien :

1. Relationship-Navigation Analysis Relationship–navigation analysis (RNA)

memperkenalkan hampir semua hubungan elemen isi dan fungsional ditemukan pada

analysis model dan menentukan syarat–syarat untuk menemukan link navigasi yang tepat

dari keseluruhan sistem. Rangkaian dari jawaban pertolongan untuk menentukan

hubungan dan memperkenalkan karakteristik yang akan mempengaruhi pada desain

navigasi. Pendekatan RNA diorganisir ke dalam lima tahap :

1. Stakeholder analysis = mengenali berbagai kategori user dan membuat hierarki

stakeholder yang tepat.



2. Element analysis = mengenali isi obyek dan elemen fungsional yang menarik

perhatian end-user.

3. Relationship analysis = menggambarkan hubungan kerjasama yang ada diantara

elemen web application.

4. Navigation analaysis = memeriksa bagaimana user boleh mengakses elemen

perorangan atau elemen kelompok.

5. Evaluation analysis = memutuskan pokok permasalahan secara pragmatis

dihubungkan dengan pelaksanaan hubungan kerjasama yang didefinisikan segera.

2. Desain dan Kualitas WebApp Olsina et.al [OLS99] dalam pressman: 561, telah

menyiapkan “quality requirement tree” yang mengidentifikasikan satu set atribut

untuk menilai kualitas WebApp.Kriteria yang ada pada gambar di bawah ini menjadi

bagian menarik untuk Web engineers siapa yang harus mendesain, membangun, dan

merawat WebApps melewati jangka waktu yang lama :

Gambar 2 Quality Requirement Tree (Pressman: 561)



Offut [OFF02] dalam pressman: 561, memperluas lima kualitas utama atribut yang dicatat

pada gambar di atas dengan menambah atribut yang mengikutinya, yaitu:

1. Security,

2. Availability,

3. Scalability,

4. Time-to-market.

Design Goals

Menurut Jean Kaiser [KAI02] dalam pressman: 563, untuk mencapai kualitas atribut web

application, desain web application yang baik harus menampilkan:

1. Simplicity,

2. Consistency,

3. Identity,

4. Robustness,

5. Navigability,

6. Visual Appeal,

7. Compatibility.

&&&&&&&&



Daftar Pustaka




McGraw Hill, 1992






MODUL PERKULIAHAN

ANALISA





14 87016 Tim Dosen

Abstract Kompetensi




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



ER Conceptual Data Model (CDM)

Pengirim Transaksi1,1

1,n

KaryawanCatatTransaksi1,1

0,n

TagihanTransaksi

1,1

1,n

PenerimaTransaksi

0,1

0,n

JenisTransaksi

1,11,n

SifatTransaksi1,1

1,n

KotaTransaksi

1,1

0,n

KotaPenerima

0,n

1,1

KotaKaryawan

0,n

1,1

KotaPengirim

0,n

1,1

TagihanPengirim

1,1

1,n

Transaksi

NoTransaksiTglTransaksiBeratTransaksi

<pi> A9DVA20

<M>

Pengirim

KdPengirimNamaPengirimAlamatPengirimKdPosPengirimTlpPengirimFaksPengirimKPPengirim

<pi> VA20VA50VA100VA10VA20VA20VA20

<M>

Karyawan

KdkaryawanNamaKaryawanTglLahirKaryawanSexStatusAlamatKPKaryawan

<pi> A9VA20DVA9VA20VA50VA20

<M>

Tagihan

NoTagihanTglTagihan

<pi> A9D

<M>

Kota

KdKotaNamaKota

<pi> A9VA20

<M>

Jenis

KdJenisNamaJenis

<pi> A9VA20

<M>

Sifat

KdSifatNamaSifatBiayaSifat

<pi> A9VA20DC12,2

<M>

Penerima

KdPenerimaNamaPenerimaAlamatPenerimaKdPosPenerimaTlpPenerimaFaksPenerimaKPPenerima

<pi> A9VA30VA100VA9VA9VA9VA20

<M>

Gambar 1. Conceptual data model (cdm)



Normalisasi

1NF

Keterangan :

NoTrans = NoTransaksi Nm = Nama Brt

= Berat

NoTag = No Tagihan Alm = Alamat Biy

= Biaya

TglTrans = TglTransaksi Kta = Kota Ktr

= Keterangan

K_Pgr = KodePengirim K_Pos = Kode_Pos

K_Pnr = KodePenerima Tlp = Telepon

K_Jns = KodeJenis Faks = Faksimile

K_Sft = KodeSifat K_Prs = KontakPerson

K_Kry = Kode_Karyawan Sts = Status

Jml = Jumlah TglTrm = TglTerima

2NF

Transaksi

Penerima

Pengirim



Karyawan

Tagihan

Sifat

Jenis

Kota

3NF

Transaksi

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

NoTransaksiKdJenisKdPenerimaKdkaryawanKdSifatKdKotaNoTagihanKdPengirimTglTransaksiBeratTransaksi

CHAR(9)CHAR(9)CHAR(9)CHAR(9)CHAR(9)CHAR(9)CHAR(9)CHAR(9)DATEVARCHAR(20)

<pk><fk5><fk4><fk2><fk6><fk7><fk3><fk1>

Pengirim

KdPengirimKdKotaNamaPengirimAlamatPengirimKdPosPengirimTlpPengirimFaksPengirimKPPengirim

CHAR(9)CHAR(9)VARCHAR(30)VARCHAR(100)VARCHAR(9)VARCHAR(20)VARCHAR(20)VARCHAR(20)

<pk><fk>

Karyawan

KdkaryawanKdKotaNamaKaryawanTglLahirKaryawanSexStatusAlamatKPKaryawan

CHAR(9)CHAR(9)VARCHAR(20)DATEVARCHAR(9)VARCHAR(20)VARCHAR(50)VARCHAR(20)

<pk><fk>

Tagihan

NoTagihanKdPengirimTglTagihan

CHAR(9)CHAR(9)DATE

<pk><fk>

Kota

KdKotaNamaKota

CHAR(9)VARCHAR(20)

<pk>

Jenis

KdJenisNamaJenis

CHAR(9)VARCHAR(20)

<pk>

Sifat

KdSifatNamaSifatBiayaSifat

CHAR(9)VARCHAR(20)NUMBER(12,2)

<pk>

Penerima

KdPenerimaKdKotaNamaPenerimaAlamatPenerimaKdPosPenerimaTlpPenerimaFaksPenerimaKPPenerima

CHAR(9)CHAR(9)VARCHAR(30)VARCHAR(100)VARCHAR(9)VARCHAR(9)VARCHAR(9)VARCHAR(20)

<pk><fk>

Gambar 2. Model er physical data model (pdm)

Perancangan Struktur Menu Tampilan

Struktur Menu Program Keseluruhan

Gambar 3. Perancangan struktur menu program keseluruhan



Struktur Menu Utama

Gambar 4. Perancangan struktur menu utama

Struktur Menu File

Gambar 5. Perancangan struktur menu file

Struktur Menu Record

Gambar 6. Perancangan struktur menu record

Struktur Menu Proccess

Gambar 7. Perancangan struktur menu proccess

Struktur Menu Report

Gambar 8. Perancangan struktur menu report



Struktur Menu Help

Gambar 9. Perancangan struktur menu help

Struktur Menu Utility

Gambar 10. Perancangan struktur menu utility

Perancangan Input Output

Form Login

Pada rancangan layar Login, User harus measukkan Username dan

Password untuk dapat memasuki layar menu utama. Apabila user salah

measukkan password, maka akan muncul pesan “invalid user ID or

password”. Berikut rancangan layar login pada Gambar 11

Gambar 11. Tampilan form login

Keterangan gambar :

Username

Admin harus memasukkan usernamenya dengan benar

Password

Admin harus memasukkan password dengan benar.

Login



Untuk memasuki layar menu admin apabila username dan password

sesuai.

Layar Menu Utama

Setelah login berhasil operator dapat melakukan transaksi pembayaran

atau input data baru dengan menggunakan fasilitas yang tersedia pada form

menu, dalam bentuk menubar yang ter diri atas;

File

Pada menubar File berisi menu item Loogoff dan Exit. Data Operator

digunakan untuk melakukan login untuk operator baru, dan untuk

mengakhiri program dari menu file.

Record

Pada menubar Record menyediakan fasilitas bagi operator data entry

untuk melakukan penambahan dan pengeditan beberapa data antra lai :

data pengirim, data penerima, data karyawan dan data parameter.

Proceess

Pada menubar process ini digunakan untuk memproses suatu transaksi

yang berlangsung, proses konfirmasi penerimaan dan proses penagihan

atas beberapa transaksi.

Report

Pada menubar report ini operator data entry dapat melihat bebrapa data

diantranya adalah data pengirim, data penerima, data tagihan dan data

tagihan yang kemudian dapat dicetak sebagai dibuat laporan.

Help

Apabila didalam pengoperasian aplikasi ini menemui sebuah masalah

maka menu ini mungkin bisa membantu para pengguna untuk

menyelesaikan masalah yang didapatkan dalam aplikasi ini.

BussinessSetup

Pada menubar ini bila seorang user berstatus admin maka ia dapat

menggunakan menubar ini untuk menambah user, dan mengedit data

rekening perusahaan tersebut.



Gambar 12. Tampilan Form Utama (mainform).

Tampilan Form Data Pengirim

Form ini digunakan untuk melihat data dan menginput data pengirim serta

untuk menanipulasi dan menghapus data pengirim, pada form ini berisi beberapa

data sebagai berikut :

1. Kode Pengirim, berisi kode dari pengirim.

2. Nama Pengirim, menjelaskan nama pengirim dengan

jelas.

3. Alamat, untuk mengetahui data alamat pengirim

dengan benar.

4. Telpon, untuk alat komunikasi dengan pengirim.

Form ini juga menyediakan tabel untuk kita dapat melihat dan merubah

input data juga hasil data yang sudah masuk. Form ini juga menyediakan tombol

simpan, buat baru dan hapus untuk mengkoreksi atau menghilangkan data yang

sudah ada.

Gambar 13. Tampilan form data pengirim



Tampilan Form Tambah Data Pengirim

Selain dengan menggunakan form transaksi untuk menambah data

pengirim form ini juga dapat digunakan untuk menambahkan data pengirim

diantaranya :

Gambar 14. Tampilan form tambah data pengirim

Tampilan Form Data Penerima

Form ini digunakan untuk melihat data dan menginput data penerima serta

untuk menanipulasi dan menghapus data penerima, pada form ini berisi beberapa

data sebagai berikut :

1. Kode Penerima, berisi kode dari penerima.

2. Nama Penerima, menjelaskan nama penerima dengan jelas.

3. Alamat, untuk mengetahui data alamat penerima dengan benar.

4. Telpon, untuk alat komunikasi dengan penerima.




sudah ada.



Gambar 15. Tampilan form data penerima

Tampilan Form Tambah Data Penerima


pengirim form ini juga dapat digunakan untuk menambahkan data penerima

diantaranya :

Gambar 16. Tampilan form tambah data penerima

Tampilan Form Data Karyawan

Form ini digunakan untuk melihat data dan menginput data karyawan

serta untuk menanipulasi dan menghapus data karyawan, pada form ini berisi

beberapa data sebagai berikut :

1. Kode Karyawan, berisi kode dari karyawan.

2. Nama Karyawan, menjelaskan nama karyawan dengan jelas.

3. Alamat, untuk mengetahui data alamat karyawan dengan benar.

4. Telpon, untuk alat komunikasi dengan karyawan.






sudah ada.

Gambar 17. Tampilan form data karyawan

Tampilan Form Tambah Data Karyawan


pengirim form ini juga dapat digunakan untuk menambahkan data karyawan

diantaranya :

Gambar 18. Tampilan form tambah data karyawan

Tampilan Form Data Transaksi Pengiriman


input 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

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



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.



Gambar 23. Tampilan form detail tagihan

Pada form proses penagihan

Tampilan Form Parameter untuk Kota Pengiriman

Karena pada pada proses pengiriman barang atau paket itu oleh beberapa

kriteria, akan tetapi hal yang paling menentukan banyak atau sedikitnya biaya

yang dibutuhkan yaitu kota tujuan atau jarak jauh dekatnya tujuan dari penerima

barang tersebut. Oleh karena itu dibutuhkan sebuah ukuran untuk menentukan

biaya yang dibuhkan, dan untuk keperluan tersebut maka dapat di lakukan pada

form berikut ini :

Gambar 24. Tampilan form parameter kota

Tampilan Form Parameter untuk Sifat Pengiriman

Pada form ini berguna untuk memberikan informasi sifat dari pengiriman

dan dapat dijadikan acuan untuk menghitung biaya yang dibutuhkan, sehingga

kita dapat membrikan pilhan kepada pelanggan (pengirim) untuk apat memilih

sifat pengiriman yang dipilih sesuai dengan kebutuhan.



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.



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


sesuai maka data tersebut akan ditampilkan di tabel tersebut.

Gambar 28. Tampilan form laporan data pengirim

Tampilan Form Laporan Data Transaksi

Form laporan data transaksi ini untuk mncetak data yang berfungsi untuk

laporan dari operator ke manager. Operator hanya mengimput kode pengirim dan

tanggal pengiriman lewat menu drop down yang telah disediakan. Dan bila data

yang dipilih telah sesuai maka data tersebut akan ditampilkan di tabel tersebut.



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


sesuai maka data-data transaksi yang telah berlangsung selama satu periode

tersebut akan ditampilkan di tabel tersebut.

Gambar 30. Tampilan form laporan data tagihan

Tampilan Form Data Rekening

Apabila yang login adalah seorang admin maka ia dapat membuka form

ini. Form ini digunakan untuk mengisi data rekening dari perusahaan yang

bersangkutan.



Gambar 31. Tampilan form laporan data rekening

Tampilan Form Tambah Data User

Apabila yang login adalah seorang admin maka ia dapat membuka form

ini. Form ini digunakan untuk menambah, menghapus serta mengedit data user

yang berhak untuk mngoperasikan aplikasi tersebut.

Gambar 32. Tampilan form tambah user

Tampilan Form Bantuan (Help)

Pada form bantuan ini, untuk dapat mejadi fasilitas tambahan bagi seorang

operator baru yang ingin mengetahui cara penggunaan aplikasi yang dibuat.

1. About

Merupakan menu bantuan yang memberikan informasi tentang penjelasan

pemanfaatan aplikasi tersebut.



Gambar 33. Tampilan Form Bantuan (Help) untuk About

2. Content

Merupakan menu bantuan yang memberikan informasi tentang penjelasan

beberapa hal.

1. Tata cara konfigurasi dan install

2. Tentang Aplikasi Delivery Sistem version 1.1

3. Tentang pembuat aplikasi (Programer).

4. Sedikit penjelasan tentang bahasa pemrograman Java

Gambar 34. Tampilan form bantuan (help) untuk content

Perancangan layar Output

Laporan Data Transaksi

Gambar 3.62. Rancangan output data transaksi



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



Gambar 37. Rancangan output data karyawan

Per kode karyawan

Laporan Data Penerima

Gambar 38. Rancangan output data penerima

Laporan Data Pengirim

Gambar 39. Rancangan output data pengirim



Laporan Data Tagihan

Gambar 40. Rancangan output data tagihan

Implementasi Sistem

Tahap perancangan diikuti oleh tahap implementasi. Menterjemahkan perancangan ke

kode program adalah proses yang relative sederhana dan bersifat mekanis sebab

perancangan yang baik sudah mengambarkan dengan baik apa yang harus dilakukan

dengan bahasa-bahasa pemrograman. Asalkan kita telah melakukan pemodelan

dengan baik (misalnya dengan menggunakan UML yang penulis telah gunakan ) dan

mempergunakan banyak perangakat-perangkat lunak berjenis CASE (Computer Aided

Software Engineering) yang baik, misalnya Rational Rose dan Visual Paradigm yang

penulis gunakan yang akan dengan mudah menterjemahkan model-model kita tadi

kedalam sintak beberapa bahasa pemrograman.



Daftar Pustaka




McGraw Hill, 1992






modul perkuliahan analisa perancangan...

Documents