Functional Modelling

& Structural Modelling

Pengembangan Berorientasi Objek
Pertemuan 8
Funcitional Modelling
• Functional model menjelaskan business process dan interaksi dari sistem
informasi dengan lingkungannya. Didalam OOAD ada dua buah model yang
digunakan didalam analisis dan disain :
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 sistem informasi yang berjalan pada sebuah
business sistem.
 Funcitional Modelling
2. Use Case.
Use case digunakan untuk menjelaskan fungsi dasar sistem informasi. Notasi ini digunakan untuk menjelaskan apa yang telah
berlaku sekarang dan yang akan berlangsung pada sistem yang baru. Sebuah use case adalah cara formal untuk menjelaskan
bagaimana sebuah business system berinteraksi dengan lingkungannya.
Sebuah use case menjelaskan aktifitas yang dilakukan oleh pengguna didalam sebuah sistem informasi. Use case dapat dilihat
sebagai gambaran eksternal atau gambaran functional sebuah proses business dimana didalamnya diperlihatakan bagaimana
pandangan pengguna terhadap sistem

• 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. Disamping itu Activity diagram dan use case juga
merupakan physical model yang menggambarkan aktifitas fisik terinci yang memungkinkan sistem berjalan
dengan baik. 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 :
• Di dalam 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.
• 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).
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.
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
Contoh Activity Diagram
untuk Pendaftaran Pasien
Elemen-elemen dari activity diagram adalah

• Action • Decision node

Behaviour sederhana yang tidak bisa dipecah lagi Digunakan untuk menggambarkan test condition untuk
(secara conceptual). memastikan bahwa control flow atau object flow
Diberi label dengan nama mengalir ke lebih dari satu jalur
• Activity • Merge node
Digunakan untuk menggambarkan sehimpunan Action Digunakan untuk menggabungkan kembali decision
Diberi label dengan nama path

• Control flow • Fork Node

Memperlihatkan urut-urutan eksekusi Digunakan untuk memecah sebuah behaviour menjadi
activity atau action pararel yang pararel.
• Object flow
• Join node
Memperlihatkan aliran object jadi sebuah action atau
activity ke action atau activity lain. digunakan untuk menggabungkan kembali activity atau
action yang pararel
• Initial node (Memperlihatkan titik awal)
• Swimlane
• Final Activity node (Akhir dari sebuah activity diagram) Digunakan untuk memecah activity diagram kedalam
• Final flow node baris dan kolom untuk membagi tanggung jawab
kepada object-object yang melakukan aktifitas
Digunakan untuk menghentikan sebuah control flow tersebut.
atau object flow yang spesific
Diberi label dengan nama object yang bertanggung
jawab untuk menjalankan activity atau action.
 Garis besar yang harus diikuti untuk membuat
activity diagram
• Karena Activity Diagram dapat digunakan untuk memodelkan segala jenis proses,
Anda harus mengatur konteks atau ruang lingkup aktivitas yang dimodelkan.
Setelah Anda menentukan ruang lingkup, Anda harus memberikan judul pada
diagram yang sesuai.
• Anda harus mengidentifikasi aktivitas, mengontrol aliran, dan aliran objek yang
terjadi di antara aktivitas.
• Anda harus mengidentifikasi setiap keputusan yang merupakan bagian dari proses
yang dimodelkan.
• Anda harus berusaha mengidentifikasi prospek paralelisme dalam proses tersebut.
• You should draw the activity diagram.
 Use Case

• 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
• Use case adalah penjelasan dari fungsi sistem dilihat dari kaca mata penggunanya.
• Use case diagram merupakan sebuah functional diagram yang menggambarkan fungsi
dasar dari system, 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

• 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.
Noted
• 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.
Noted
• 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.
Jenis-Jenis Use Case (1. Overview use
case )
• Overview use case digunakan untuk memungkinkan analis dan user
setuju atas requirement secara umum.
• Jika sudah dipahami bersama-sama maka requirement tadi akan
dikonversi menjadi detail use case :
1. Presents an important business process.
2. The use case supports revenue generation or cost reduction.
3. Technology needed to support the use case is new or risky and
therefore will require considerable research.
Jenis-Jenis Use Case (2. Essential use case )
• Essential versus real. Pada essential use case yang dijelaskan adalah
minimal essential issues untuk memahami required functinality,
sedangkan pada real use case yang harus dijelaskan adalah lengkah-
langkah terinci dari sistem informasi.
 Write each step in “SVDPI (Subject – Verb – Direct Object or Preposition –
W Indirect Object)" form. Setiap langkah didalam Use case dituliskan secara
lengkap dengan aturan tata bahasa yang baik

Clarify initiator and receivers of action. Siapa yang memulai action harus
C jelas, dan siapa yang menjawab tindakan tersebut juga harus dijelaskan
dengan terinci. (System Response harus jelas)

Write from independent observer perspective. Ditulis secara independent

WIO tidak secara judgemental.

Langkah
Write at same level of abstraction. Tingkat abstraksi harus sama dengan
membuat Use WSL responden yang ditanya.
Case
Ensure a sensible set of steps. Urut-urutan langkah harus masuk akal. Secara
ESS logis urutan-urutan harus benar berurut

Apply KISS principle liberally. Use case harus dibuat sederhana, dan mudah
KISS dipahami(Keep it simple stupid).

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

Repeated instruksi untuk mengulang sesudah langkah penjelasan langkah yang harus
dilakukan.
Notasi yang digunakan
• Actor/Role.
• Use Case.
• System
• Association yang dapat berjenis :
• Association Relationship
• Include Relationship
• Extend Relationship
Notasi Use
Case
Contoh
Use Case
Contoh Use Case dengan Extend dan Include
 Cara
identifikasi
Use Case
Structural Modelling
State the purpose of this reflection.
• 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.
• The structure of data used in the system is represented through CRC
cards, class diagrams, and object diagrams.
Tujuan dari Pemodelan
• Reduce the “semantic gap” between the real world and the world of
software.
• Create a vocabulary for analysts and users
• Represent things, ideas, and concepts of importance in the
application domain
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.
Class and Object
Methods dan
Messages
• Method merupakan implementasi dari
behaviour(kelakukan) sebuah object.
• Method adalah 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.
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.
• Di dalam 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 di mana 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.
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 di dalam 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, di mana Class tersebut merupakan abstract class.
Class Hierarchy

• Pada contoh Person adalah

abstract class sedangkan Doctor
dan Patient merupakan concrete
class
Inheritance
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 spesifik untuk sebuah problem domain
• Relationship :
• Generalization Enables inheritance of attributes and operations
• Aggregation Relates parts to wholes
• Association Miscellaneous relationships between classes
Class Responsibilities and Collaboration
• Menunjukkan kerjasama dari classes untuk melakukan pemenuhan
kebutuhan dari client
• Responsibilites adalah
• Knowing. Mengetahui apa yang harus dikerjakan untuk melayani permintaan
client
• Doing. Melakukan apa yang diminta client
• Collaboration Objects working together to service a request
• Jenis-jenis attribute :
• Derived atau attribute turunan yang diturunkan dari attribute primitive. Contoh tanggal lahir
adalah primitive. Umur adalah derived attributes
• Visibility
• Public bisa dilihat siapa saja
• Protected hanya bisa dihubungi oleh class yang menjadi friend/teman
• Private hanya bisa dilihat oleh class itu sendiri
• Jenis-jenis operasi selain fungsi methods yang biasa
• Constructor. :
• Secara otomatis akan dijalankan pada saat oject dibuat
• Biasanya juga membuat object yang lain
• Query : Menanyakan state dari object
• Update : Merubah nilai dari beberapa atau seluruh attribute.
• Relationship adalah hubungan antar object/class. Jenis hubungannya
bermacam-macam :
• Sebuah class dapat berhubungan denga dirinya sendiri atau disebut recursive
• Multiplicity :
• One to one
• Zero to many
• One to many
• Zero to one
• Specified Range
• Multiple disjoint range Association
• 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
Class Diagram

Object Diagram
 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
• Hubungan antar class yang dapat dikelompokkan berdasarkan :
• 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
• Create CRC cards.
• Examine common object lists.
• Role-play the CRC cards.
• Create the class diagram.
• Review the class diagram.
• Incorporate patterns.
• Review the model.