• Tidak ada hasil yang ditemukan

Pemodelan Kebutuhan Pendekatan Berorientasi Objek

N/A
N/A
Protected

Academic year: 2022

Membagikan "Pemodelan Kebutuhan Pendekatan Berorientasi Objek"

Copied!
35
0
0

Teks penuh

(1)

Pemodelan Kebutuhan

Pendekatan Berorientasi Objek

Fajar Pradana S.ST., M.Eng

(2)

Tujuan perkuliahan

• Memahami konsep pendekatan berorientasi objek dalam

pemodelan kebutuhan

(3)

Agenda

• Konsep pemodelan berorientasi objek

• Elemen-elemen pemodelan berorientasi objek

• Dokumentasi dan alat bantu

(4)

Object Oriented Approach

• Mulai populer akhir ’80an – ’90an (Booch, Rumbaugh-OMT, Jacobson-OOSE, Coad+Yourdon, Wirfs-Brock) :

▪ Elisitasi kebutuhan customer

▪ Identifikasi skenario / use-case (use-case diagram)

▪ Identifikasi klas berdasarkan kebutuhan customer

▪ Identifikasi atribut dan operasi setiap klas

▪ Definisi struktur klas (class diagram)

▪ Definisi model relasi antar klas (collaboration/sequence diagram)

▪ Definisi perpindahan status sistem (statechart diagram)

• 1996 : UML (Unified Modeling Language) – Grady Booch+James

Rumbaugh+Ivar Jacobson

(5)

Keuntungan

• Sangat natural, sesuai dengan cara berpikir manusia  improve analyst and problem domain expert interaction

• Meningkatkan konsistensi hasil analisis  abstraksi atribut-operasi dalam sebuah objek

• Konsep penurunan klas memberikan kemudahan dalam generalisasi objek

• Kemudahan dalam perubahan

• Terjaganya konsistensi model antara analisis dan perancangan

• Konsep reusability

(6)

Object, Class – Apa Itu ?

• Objek (Object) :

▪ A concept, abstraction, or thing with crisp boundaries and meaning for the problem at hand [Rumbaugh]

▪ Benda (tangible & intangible thing)

▪ Contoh : Andi, Eko, Susi (sistem akademik)

▪ Sebuah objek memiliki karakteristik : identity (identitas-pembeda), state (sekumpulan atribut) & behaviour (sekumpulan operasi, aksi, servis)

• Notasi :

Nama Objek

Atribut2

Operasi2

(7)

Object, Class – Apa Itu ?

• Klas (Class) :

▪ A description of one or more objects with a uniform set of attributes and services, including a description of how to create new objects in the class [Yourdon]

Gambaran umum (template, blue-print) yang menjelaskan

sekumpulan objek yang memiliki kesamaan karakteristik (atribut dan operasi)

▪ Merupakan cetakan dari objek

▪ Digunakan untuk menginstansiasi objek yang memiliki identitas yang berbeda

▪ Contoh : Klas Mahasiswa  objek Andi, Eko, Susi

Abstract & concrete class

(8)

Object, Class – Apa Itu ?

Mahasiswa

- NIM

- Nama

- Buat skripsi

- Ujian

Mahasiswa

- NIM : 001

- Nama : Andi

- Buat skripsi

- Ujian

Mahasiswa : Andi

Mahasiswa

- NIM : 002

- Nama : Eko

- Buat skripsi

- Ujian

Mahasiswa : Eko

Mahasiswa

- NIM : 003

- Nama : Susi

- Buat skripsi

- Ujian

Mahasiswa : Susi Instansiasi :

penciptaan objek

(9)

Where to look ?

• Investigasi domain masalah

• Langkah-langkah:

▪ Observe first-hand  observasi langsung ke lap.

▪ Actively listen to problem domain experts  what, who, why, when and how

▪ Check previous OOA results

▪ Check other systems  comparison

▪ Read, read, read  getting some more information

(10)

What to look for ? Nouns

• Structures

▪ Relasi antar objek -> generalisasi, agregasi

• Other systems

▪ Sistem lain yang berinteraksi dg proposed system

• Things or events remembered

▪ Data, status, kejadian yang harus disimpan

• Roles played

▪ Identifikasi peran manusia dalam sistem -> berinteraksi langsung, tidak berinteraksi tetapi informasinya disimpan sistem

• Sites

▪ Informasi lokasi/posisi yang harus diingat oleh sistem

(11)

Identifikasi atribut

• Some data (state information) for which each object in a class has its own value [Yourdon]

• Langkah-langkah:

▪ Identifikasi atribut umum (adjectives, possessives)

▪ Identifikasi atribut yang relevan dg domain masalah

▪ Identifikasi atribut yang relevan dg peran atau tanggung jawab dalam sistem

Restrukturisasi atribut sehingga atomic  kemudahan

▪ Reposisi atribut yang sesuai dengan hirarki klas nya  pewarisan klas

▪ Spesifikasi atribut presisi, nilai default, batasan, dll.

(12)

Identifikasi operasi/servis

• A specific behavior that an object is responsible for exhibiting [Yourdon]

• Langkah-langkah:

▪ Identifikasi tanggung jawab umum sebuah klas (verbs)

▪ Identifikasi operasi yang spesifik untuk domain masalah

▪ Identifikasi operasi yang relevan dg peran atau tanggung jawab dalam sistem

▪ Spesifikasi operasi  argumen, batasan/aturan, logika/algoritma

(13)

Diagram UML

• Use-case diagram (statis)

• Class diagram (statis)

• Collaboration/sequence diagram (dinamis)

• Statechart diagram (dinamis)

(14)

Use Case Diagram

• Menjelaskan perilaku sistem dari tampak luar

• Menyediakan fungsi-fungsi yg harus dipenuhi sistem sesuai dengan aktornya

• Elemen: actor (orang, sistem lain) dan use-case

• Setiap use-case dilengkapi dengan skenario (deskripsi)

• Langkah-langkah:

▪ Identifikasi aktor

Identifikasi use-case per aktor

(15)

Use Case Diagram

Select product

Get return coins Customer

Enter object

(16)

Use-case scenario

Flow of events for the Select product use-case

Objective Allow customer to select a certain product to dispense

Actors Customer

Pre-condition Coin detected and valid

Main flow 1. The customer selects a button product.

2. The system displays an entry prompt of number of product to order.

Alternative flows 1. If the selected product is not available, the system will display a message “Your selected product is not available”.

2. If the selected product is available but there isn’t enough number to order, the system will display a message “The number isn’t enough, max. x”. X is the existing number of the product.

Post-condition The selected product dispensed as the number needed

(17)

Use-case association

• Include

▪ A use case uses another use case (functional decomposition)  reuse

▪ A function in the original problem statement is too complex to be solvable immediately  describe the function as the aggregation of a set of simpler functions (mandatory)

• Extend

▪ A use case extends another use case

▪ The functionality in the original problem statement needs to be extended

▪ The extended use-case plays an optional use-case

(18)

<<include>> and <<extend>>

ViewMap OpenIncident

AllocateResources

<<include>>

<<include>>

Base Use

Case Supplier

Use Case

ReportEmergency

Help

<<extend>>

A

B Base Use

Case

(19)

Actor-generalization

• Two/more sub-actors generalized into a super-actor

• Have both behavior and attributes in common – described under the super-actor

• Super-actor should interact with use cases when ALL of its sub- actors interact in the same way

• Sub-actors should interact with use cases when their individual

interactions differ from that of the super-actor

(20)

Actor-generalization

(21)

Class diagram

• Menggambarkan struktur statis dari sistem

• Terdiri dari node (klas) dan relasi

• Jenis relasi

▪ Generalization (‘is a’ – inheritance)

▪ Association

▪ Aggregation (‘part-of’)

▪ Composition

(22)

Association

• For “real-world objects” is there an association between classes?

• Classes A and B are associated if:

▪ An object of class A sends a message to an object of B

▪ An object of class A creates an instance of class B

▪ An object of class A has an attribute of type B or collections of objects of type B

▪ An object of class A receives a message with an argument that is an instance of B (maybe…)  will it “use” that argument?

• Does an object of class A need to know about some object of class

B?

(23)

Aggregation – composition

• Aggregation represents a part-whole or part-of relationship

• Aggregation can occur when a class is a collection or container of other classes, but where the contained classes do not have a strong life cycle dependency on the container – essentially, if the container is destroyed, its contents are not

• Composition is more specific than aggregation

• Composition usually has a strong life cycle dependency between

instances of the container class and instances of the contained

class(es)  if the container is destroyed, normally every instance

that it contains is destroyed as well

(24)

Class relationships – examples

(25)

Class stereotypes

• Boundary classes

▪ model the interaction and manage communication between the computer system and its actors, but don’t directly represent the specific interface object in the implementation

▪ used to identify the main logical interfaces with users and other systems (including e.g. other software packages, printers)

▪ main task is to translate information across system boundaries

▪ partition the system so that interface is kept separate from business logic

(26)

Class stereotypes

• Entity classes

▪ used to model data and behavior of some real life system concept or entity e.g. member, bank account, order, employee

▪ these will sometimes require more persistent storage of information e.g. a student’s details are ultimately stored as a student record

• Control classes

▪ represent coordination, sequencing, transactions and control of other objects

▪ glue between boundary elements and entity elements, describing the logic required to manage the various elements and their interactions

▪ roughly one per use case

(27)

Class stereotypes

Actor 1

<<boundary>>

<<control>>

<<boundary>>

<<entity>> <<entity>>

Actor 2

boundary entity control

(28)

Sequence diagram

• An interaction diagram that emphasizes the time ordering of messages

• Shows a set of objects and the messages sent and received by those objects

• Elements

▪ Object  represented in a box

▪ Dashed line  called the object lifeline, and it represents the existence of an object over a period of time

▪ Message  rendered as horizontal arrows being passed from object to object as time advances down the object lifelines

(29)

Sequence diagram – example

: Customer : SelectionScreen : SelectionController : Products :

DispenserProduct

selectProduct( )

getValidSelection(String)

isProductAvailable(String)

dispenseProduct(String, int)

(30)

Statechart diagram

• A statechart diagram shows the behavior of classes in response to external stimuli

• This diagram models the dynamic flow of control from state to

state within a system

(31)

Statechart diagram – example

Waiting for a coin

Waiting for selection

Dispensing product

Returning payment initial

accept new coin

payment returned accept new coin coin detected

accept customer request product dispensed

accept new coin

sufficient payment dispense product

product available=FALSE

return payment coin return request

return payment

(32)

Alat Bantu

• Structured Analysis :

▪ Aplikasi pengolah model : Visio, dll.

▪ Aplikasi pengolah kata : MS Word, dll.

▪ CASE Tool : StP (Software through Picture), PSL/PSA (Problem

Statement Language/Problem Statement Anaylzer), ILeaf, SPMS, dll.

• OO Analysis :

▪ Aplikasi pengolah model : Visio, dll.

▪ Aplikasi pengolah kata : MS Word, dll.

▪ CASE Tool : Rational RequisitePro, Rational Soda for Word, Rational Rose, ArgoUML, dll.

(33)

Dokumentasi

• Introduction

1.1. Purpose of the requirements document

1.2. Scope of the product

1.3. Definition, acronyms and abbreviations

1.4. References

• General Description

2.1. Product perspective

2.2. Product functions

2.3. User characteristics

2.4. General constraints

• Specific Requirements

All functional and non-functional requirements, system models (eg. DFD/CFD, ERD, STD, Use-Case, Class, Sequence, Statechart diagrams), performance, database requirements, design constraints, security.

• Qualification/Validation Requirements

• Appendices/Bibliography

(34)

Summary

• Pemodelan berorientasi objek meliputi use-case, class, sequence dan state dari sistem yang sedang dikembangkan

• Alat bantu yang digunakan dalam pemodelan terstruktur dan berorientasi objek terdapat perbedaan

• Dokumentasi yang dihasilkan dari RE terdiri IRS dan SRS

(35)

Terima Kasih

Ada Pertanyaan

Referensi

Dokumen terkait

Dari hasil perbandingan kepuasan pelanggan dengan layanan internet pada atribut Emphaty (mudah dalam menghubungi customer service dalam layanan internet yang

1) Neraca meringkaskan posisi keuangan suatu perusahaan pada tanggal tertentu dan menampilkan sumber daya ekonomis ( asset ), kewajiban ekonomis (hutang), modal saham dan

Merumuskan prinsip-prinsip berkelanjutan untuk seluruh jenis proyek infrastruktur yang belum terformulasikan secara komprehensif dan menyusun instrumen untuk meng-

Karakteristik gulma dan komponen hasil tanaman padi sawah ( Oryza sativa L.) sistem SRI pada waktu keberadaan gulma yang berbeda.. Jurnal Agribisnis dan

Indonesia juga memiliki ciri khas memiliki karakter ramah tamah yang dapat ditonjolkan sehingga nantinya dapat menjadi nilai kualitas pribadi yang tidak dimiliki oleh

Apa yang dimaksud dengan sistem aliran push dan pull a.. Persamaan model matematikadari

Jalur Seleksi Penelusuran Minat dan Prestasi adalah jalur seleksi bagi calon maha- siswa baru berdasarkan seleksi prestasi akademik dan minat yang tinggi,

Keeratan Hubungan Pemberian ASI Eksklusif dengan Kejadian TB Paru Nilai koefisien kontingensi yang diperoleh dalam penelitian ini sebesar 0,247 menunjukkan keeratan hubungan