analisis dan perancangan sistem...

ANALISIS DAN PERANCANGAN SISTEM (APS)

Pemodelan Kebutuhan: Pendekatan Berorientasi Objek

Bahan Kuliah APS - Pemodelan Kebutuhan: OO | Tri A. Kurniawan, S.T, M.T, Ph.D 2/34

Tujuan perkuliahan

Memahami konsep pendekatan berorientasi objek dalam pemodelan kebutuhan


Agenda

Konsep pemodelan berorientasi objekElemen-elemen pemodelan berorientasi objekDokumentasi dan alat bantu


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


Keuntungan

Sangat natural, sesuai dengan cara berpikir manusia improve analyst and problem domain expert interactionMeningkatkan konsistensi hasil analisis abstraksi atribut-operasi dalam sebuah objekKonsep penurunan klas memberikan kemudahan dalam generalisasi objekKemudahan dalam perubahanTerjaganya konsistensi model antara analisis dan perancanganKonsep reusability


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



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



Mahasiswa- NIM- Nama- Buat skripsi- Ujian

Mahasiswa- NIM : 001- Nama : Andi- Buat skripsi- Ujian

Mahasiswa : AndiMahasiswa

- NIM : 002- Nama : Eko- Buat skripsi- Ujian

Mahasiswa : EkoMahasiswa

- NIM : 003- Nama : Susi- Buat skripsi- Ujian

Mahasiswa : Susi

Instansiasi : penciptaan objek


Where to look ?

Investigasi domain masalahLangkah-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


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


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.


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


Diagram UML

Use-case diagram (statis)Class diagram (statis)Collaboration/sequence diagram (dinamis)Statechart diagram (dinamis)


Use-case diagram

Menjelaskan perilaku sistem dari tampak luarMenyediakan fungsi-fungsi yg harus dipenuhi sistem sesuai dengan aktornyaElemen: actor (orang, sistem lain) dan use-caseSetiap use-case dilengkapi dengan skenario (deskripsi)Langkah-langkah:– Identifikasi aktor– Identifikasi use-case per aktor


Use-case diagram

Select product

Get return coins

Customer

Enter object


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


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


<<include>> and <<extend>>

ViewMapOpenIncident

AllocateResources

<<include>>

<<include>>

Base UseCase

SupplierUse Case

ReportEmergency

Help

<<extend>>A

BBase Use

Case


Actor-generalization

Two/more sub-actors generalized into a super-actorHave both behavior and attributes in common –described under the super-actorSuper-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


Actor-generalization


Class diagram

Menggambarkan struktur statis dari sistemTerdiri dari node (klas) dan relasiJenis relasi– Generalization (‘is a’ – inheritance)– Association– Aggregation (‘part-of’)– Composition


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?


Aggregation – composition

Aggregation represents a part-whole or part-of relationshipAggregation 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 notComposition is more specific than aggregationComposition 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


Class relationships – examples


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


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


Class stereotypes

Model interaction between the system and its environment

Actor 1<<boundary>>

<<control>><<boundary>>

<<entity>> <<entity>>

Actor 2

boundary entity control


Sequence diagram

An interaction diagram that emphasizes the time ordering of messagesShows a set of objects and the messages sent and received by those objectsElements– 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


Sequence diagram – example

: Customer : SelectionScreen : SelectionController : Products : DispenserProduct

selectProduct( )getValidSelection(String)

isProductAvailable(String)

dispenseProduct(String, int)


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


Statechart diagram – example

Waiting for a coin

Waiting for selection

Dispensing product

Returning payment

initial

accept new coin

payment returned

accept new coincoin detected

accept customer request

product dispensed

accept new coin

sufficient payment

dispense product

product available=FALSEreturn payment

coin return request

return payment


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.


Dokumentasi

IEEE Standard+ (IRS/SRS):1. Introduction

1.1. Purpose of the requirements document1.2. Scope of the product1.3. Definition, acronyms and abbreviations1.4. References

2. General Description2.1. Product perspective2.2. Product functions2.3. User characteristics2.4. General constraints

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

3. Qualification/Validation Requirements4. Appendices/Bibliography


Summary

Pemodelan berorientasi objek meliputi use-case, class, sequence dan state dari sistem yang sedang dikembangkanAlat bantu yang digunakan dalam pemodelan terstruktur dan berorientasi objek terdapat perbedaanDokumentasi yang dihasilkan dari RE terdiri IRS dan SRS

analisis dan perancangan sistem...

Documents