ANALISIS DAN PERANCANGAN SISTEM (APS)

(1)

ANALISIS DAN PERANCANGAN

SISTEM (APS)

Pemodelan Kebutuhan:

(2)

Tujuan perkuliahan

(3)

Agenda

Konsep pemodelan berorientasi objek

(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

(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

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

(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

(8)

Object, Class

– Apa Itu ?

Mahasiswa

- NIM

- Nama

- Buat skripsi - Ujian

Mahasiswa

- NIM : 001 - Nama : Andi

Mahasiswa : Andi

Mahasiswa

- NIM : 002 - Nama : Eko

Mahasiswa : Eko

Mahasiswa

- NIM : 003 - Nama : Susi

Mahasiswa : Susi Instansiasi :

(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

(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

(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

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

(13)

Diagram UML

Use-case diagram

(statis)

Class diagram

(statis)

Collaboration/sequence 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

(15)

Use-case diagram

Select product

Get return coins Customer

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

(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

(18)

(19)

Actor-generalization

Two/more sub-actors generalized into a

super-actor

Have both behavior and attributes in common –

described under the super-actor

(20)

(21)

Class diagram

Menggambarkan struktur statis dari sistem

Terdiri dari node (klas) dan relasi

Jenis relasi

– Generalization (‘is a’ – inheritance) – Association

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

(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

(24)

(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

(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

(27)

Class stereotypes

Model interaction between the system and its environment

Actor 1 <<boundary>>

<<control>>

<<boundary>>

<<entity>> <<entity>>

Actor 2

(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

(29)

Sequence diagram – example

: Customer : SelectionScreen : SelectionController : Products _{DispenserProduct} :

selectProduct( )

getValidSelection(String)

isProductAvailable(String)

(30)

Statechart diagram

A statechart diagram shows the behavior of

classes in response to external stimuli

(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

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

(33)

Dokumentasi

IEEE Standard+ (IRS/SRS):

1. Introduction

1.1. Purpose of the requirements document 1.2. Scope of the product

1.3. Definition, acronyms and abbreviations 1.4. References

2. General Description

2.1. Product perspective 2.2. Product functions 2.3. User characteristics 2.4. General constraints

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

3. Qualification/Validation Requirements

(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