ANALISIS DAN PERANCANGAN SISTEM (APS)

  Pemodelan Kebutuhan: Pendekatan Berorientasi Objek

  Tujuan perkuliahan

Memahami konsep pendekatan berorientasi objek

dalam pemodelan kebutuhan

Agenda

  Konsep pemodelan berorientasi objek Elemen-elemen pemodelan berorientasi objek Dokumentasi 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

  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

  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)

  identity

• – Sebuah objek memiliki karakteristik :

  (identitas-pembeda), state (sekumpulan atribut) &

  behaviour (sekumpulan operasi, aksi, servis) Nama Objek

  Notasi : Atribut2 Operasi2

  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

  Object, Class

• – Apa Itu ?

  Mahasiswa _{- NIM}

• Nama _{- Buat skripsi}
• Ujian

  Mahasiswa _{- NIM : 001}

  Mahasiswa : Andi Mahasiswa

• _{- NIM : 002}

  Mahasiswa : Eko Mahasiswa

• _{- NIM : 003}

  Mahasiswa : Susi Instansiasi : penciptaan objek

• ^{Nama : Andi} _{- Buat skripsi}
• ^{Nama : Eko} _{- Buat skripsi}
• ^{Nama : Susi} _{- Buat skripsi}
• ^Ujian
• ^Ujian
• ^Ujian

  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

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

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>> _OpenIncident <<include>> _{Base Use Case <<include>>} ViewMap _Supplier AllocateResources _{Use Case} Base Use _{Case B A <<extend>>} Help

  ReportEmergency

  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

  Actor-generalization

  Class diagram Menggambarkan struktur statis dari sistem Terdiri dari node (klas) dan relasi Jenis 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 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

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

  : Customer : SelectionScreen : SelectionController ^{: Products :} _{DispenserProduct selectProduct( )} getValidSelection(String) _{isProductAvailable(String)} dispenseProduct(String, int)

  Sequence diagram

• – example

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

  Waiting for a _coin Waiting for _selection

  Statechart diagram

• – example

  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} 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.3. Definition, acronyms and abbreviations 1.2. Scope of the product}

  1.1. Purpose of the requirements document _{2. General Description 2.1. Product perspective}

  1.4. References _{2.3. User characteristics 2.4. General constraints}

  2.2. Product functions

  3. Specific Requirements _{STD, Use-Case, Class, Sequence, Statechart diagrams), performance, database}

_{All functional and non-functional requirements, system models (eg. DFD/CFD, ERD,}

_{4. Appendices/Bibliography 3. Qualification/Validation Requirements} requirements, design constraints, security.

  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