REKAYASA PERANGKAT LUNAK (RPL)

REKAYASA PERANGKAT LUNAK (RPL)
Rekayasa Kebutuhan – Pemodelan

Tujuan perkuliahan Memahami konsep pemodelan dalam rekayasa kebutuhan
Memahami konsep pendekatan terstruktur dan berorientasi objek dalam pemodelan kebutuhan RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Agenda Konsep pemodelan kebutuhan Pemodelan terstruktur
Pemodelan berorientasi objek RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Konsep pemodelan kebutuhan
Model kebutuhan menjembatani antara deskripsi sistem secara umum dengan model perancangan Tujuan utama model kebutuhan: Menjelaskan apa yang dibutuhkan oleh customer Menjadi dasar bagi perancangan PL Menjadi referensi dalam melakukan validasi kebutuhan Metode: terstruktur (structured analysis – SA) & berorientasi objek (object oriented analysis – OOA) RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Prinsip pemodelan kebutuhan
Model yang dibuat harus fokus pada kebutuhan yang relevan dengan domain permasalahan  WHAT Setiap model kebutuhan harus bisa dilacak ke model perancangan  traceability Setiap elemen dalam model kebutuhan harus mampu memperjelas pemahaman secara utuh terhadap kebutuhan PL  domain masalah, fungsionalitas dan perilaku sistem Minimalisasi kopling  antar klas Memastikan bahwa model kebutuhan memiliki nilai manfaat untuk seluruh stakeholders Model dibuat sesederhana mungkin  notasi yang sederhana, non duplikasi informasi RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Tipe-tipe model kebutuhan
Scenario-based models Berdasarkan sudut pandang aktor Data models Menjelaskan domain informasi dari masalah Class-oriented models Merepresentasikan klas-klas yang relevan dengan kebutuhan PL Flow-oriented models Merepresentasikan proses dan data dari sistem Behavioral models Merepresentasikan perilaku sistem berdasar event RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

1 – Pemodelan Terstruktur

Konsep Pertama kali dipopulerkan oleh T. DeMarco (1979)  Structured Analysis and System Specification Perluasan notasi untuk kebutuhan real-time systems oleh Hatley dan Pirbhai (1987) – SA/RT  Strategies for Real-Time System Specification Processes Data Behavior RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Elemen-elemen pemodelan
Data Dictionary Data Flow Diagram (DFD) ER Diagram State Transition Diagram (STD) Process Specification (PSPEC) Data Object Description Control Specification (CSPEC) RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Data dictionary Representasi Simbol : = : composed of + : and
{ } : iterations of [….|…] : selection / or ( ) : optional “ “ : literal * * : comment/description Vend product (partly) : Name Element Type object [coin | slug](product) data product [ice cream | coffee | candy] data coins 0{[quarter | nickel | dime]}8 data product available [TRUE | FALSE] control [“YES” | “NO”] quarter *25 cents US currency* coin return request [TRUE | FALSE] control RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Data model – ER diagram Entitas (atribut dan nilai atribut)
Modalitas : tingkat mandatory (minimal) Kardinalitas : tingkat relasi (maksimal) Bentuk relasi Manufacturer Car Builds RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan. ,S. T, M
RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Data model – data object description
represents a composite information consists of a number of different attributes or properties encapsulates data only  no operation applied to its data can be external entity, thing, occurrence/event, role, organizational unit, structure, etc. e.g. dimensions (height, weight, depth), cars (make, model, ID, body type, color, owner) can be represented in a tabular representation RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Process model – DFD Useful for analyzing existing as well as proposed systems  process decomposition Focus on the movement of data between external entities and processes, and between processes and data stores A relatively simple technique to learn and use Model elements: terminator, process, data flow, control flow, storage, control bar The highest level (0)  Context diagram Single process Terminators Data flows, control flows RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Process model – Elemen2 DFD
Terminator Representasi entitas eksternal Notasi: persegi panjang Tidak memproses data Data flow Representasi aliran data Notasi: anak panah penuh Umumnya satu arah Hubungkan terminator, process dan storage Control flow Representasi aliran kontrol proses Notasi: anak panah putus2 Hubungkan terminator, process dan control bar Customer data control RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Process model – Elemen2 DFD (1)
Representasi aktifitas sistem Notasi: lingkaran Memproses data Storage Representasi tempat penyimpanan data Notasi: dua garis paralel Data flow in = diubah, data flow out = dibaca Control bar Representasi spesifikasi kontrol Notasi: garis tegak 1 Proses A data X RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Process model – Panduan DFD
Jumlah proses dalam satu diagram DFD : 4 + 2 Maks. 4 level dekomposisi (DFD/CFD) Dekomposisi fungsional (DFD) : fungsi-fungsi yang saling berhubungan dikelompokkan fungsi-fungsi yang tidak berhubungan dipisahkan setiap fungsi dispesifikasi hanya sekali Data flow membawa informasi yg diperlukan oleh sebuah proses untuk transformasi, control flow membawa informasi yang harus diinterpretasikan untuk merubah perilaku sistem dan/ aktifasi proses Proses pemodelan DFD/CFD adalah proses iterasi, tidak sekali jadi Penjenjangan CFD harus sesuai dengan DFD RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Data – control identification
Identify data first rather than control  to know what you are controlling first Continuous signals, and processes that act on them, are always categorized as data Discrete signals, and processes that act on them, are usually categorized as control Terms like activate, turn on, engage and execute are usually associated with control requirements RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Process model – DFD/CFD leveling
Must be consistent RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Data/Control Context Diagram (DCD/CCD)
Vend product Customer returned coins 0* object customer selection slug coin return request product available RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Data/Control Flow Diagram (DFD/CFD level 1)
1* Get customer payment 2p Get product price 3p Validate payment 4p Get valid selection 5* Dispense change 6p Dispense product price table coins products returned coins product object customer selection slug coin return request payment price valid selection change due coin detected sufficient payment product dispensed product available RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Data/Control Flow Diagram (DFD/CFD level 2)
DFD/CFD level 2 : Dispense change 5.1p Get change coin coin return request 5.2p Get payment coin product available change due coins payment payment coins change coins returned coins RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Process model – Process specification
PSPEC – Validate payment (Process 3) Inputs : payment (data in) price (data in) Outputs : change due (data out) sufficient payment (control out) Body : IF payment >= price THEN change due = payment – price sufficient payment = TRUE ELSE change due = 0 sufficient payment = FALSE END IF RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

accept customer request product available=FALSE
Behavior model State Transition Diagram (STD) initial accept new coin Waiting for a coin payment returned accept new coin coin detected accept customer request coin return request return payment product dispensed accept new coin Waiting for selection Returning payment product available=FALSE return payment sufficient payment dispense product Dispensing product RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Behavior model (1) CSPEC – Dispense change : Process Activation Table
coin return request product available get change coin get payment coin TRUE 1 D/C FALSE RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

DFD -0 RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Tugas kelompok Berikan contoh studi kasus aplikasi yang menggunakan permodelan terstruktur sesuai dengan topik praktikum Buat ERD, DFD, STD dari contoh kasus tersebut Kumpulkan hari Selasa sebelum jam 12 siang via . RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

2 – Pemodelan Berorientasi Objek

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 RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Diagram UML Use-case diagram (statis)  scenario-based models
Class diagram (statis)  class models Collaboration/sequence diagram (dinamis)  behavioral models Statechart diagram (dinamis)  behavioral models RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

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 RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Object, Class – Apa Itu ? Objek (Object) : Notasi :
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) & behavior (sekumpulan operasi, aksi, servis) Notasi : Nama Objek Atribut2 Operasi2 RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

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 RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Instansiasi : penciptaan objek
Object, Class – Apa Itu ? Mahasiswa NIM Nama Instansiasi : penciptaan objek 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 RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

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 RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

What to look for ? Nouns Structures Other systems
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 RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

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. RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

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 RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

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 RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Use-case diagram RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

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 The customer selects a button product. The system displays an entry prompt of number of product to order. Alternative flows If the selected product is not available, the system will display a message “Your selected product is not available”. 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 RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Use-case association Include Extend
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 RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

<<include>> and <<extend>>
ViewMap OpenIncident AllocateResources <<include>> Base Use Case Supplier Use Case ReportEmergency Help <<extend>> A B Base Use Case RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

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 RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

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 - Generalisasi berarti target dari hubungannya ke kelas yang lebih general (umum). Sebagai contoh jika kita memiliki kelas bernama Cat dan kelas bernama Dog, kita dapat membuat generalisasi dari keduanya dengan nama Animal. Generalisasi biasanya dibaca “… adalah …” dimulai dari kelas yeng lebih spesifik menuju kelas yang lebih umum (general class). Jadi dapat dikatakan “suatu Cat adalah suatu Animal”. - Association Terkadang hubungan antara dua elemen tidak sederhana. Misalnya, suatu tim pemain bola (football player) berasosiasi dengan liga (league) lewat suatu regu. Jika hubungannya terlalu rumit, bisa dibuatkan hubungan asosiasi antar kelas. Yang perlu diperhatikan dari gambar diatas adalah FootballPlayer tidak memiliki referensi langsung kepada FootballLeague tapi memiliki referensi terhadap FootballTeam. footballTeam akan memiliki referensi terhadap FootballLeague. Composit : Misalnya, jika Window yang kita buat harus memeliki Titlebar maka kita dapat merepresentasikan suatu kelas bernama Titlebar yang merupakan “bagian dari” kelas Window. Agregasi adalah versi kuat dari asosiasi. Tidak seperti asosiasi, agregasi mengimplikasikan kepemilikansuatu kelas. Agregasi bisa dibaca “ … memilik … “. RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

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? Association : Sebuah asosiasi merupakan sebuah relationship paling umum antara 2 class dan dilambangkan oleh sebuah garis yang menghubungkan antara 2 class. Garis ini bisa melambangkan tipe-tipe relationship dan juga dapat menampilkan hukum-hukum multiplisitas pada sebuah relationship.(Contoh: One-to-one, one-to-many,many-to-many). RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

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 Composition: Jika sebuah class tidak bisa berdiri sendiri dan harus merupakan bagian dari class yang lain, maka class tersebut memiliki relasi Composition terhadap class tempat dia bergantung tersebut. Sebuah relationship composition digambarkan sebagai garis dengan ujung berbentuk jajaran genjang berisi/solid. Aggregation Denpendency Composition RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

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 Boundary class menangani komunikasi antara lingkungan sistem dan kedalam sistem. Mereka dapat menjamin interface ke pengguna atau sistem lain ( misalnya, interface ke actor ). Boundary class digunakan untuk memodelkan sistem interface. RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Class stereotypes Entity classes Control 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 - Entity class memodelkan informasi dan operasi yang biasanya berumur panjang/lama. Tipe class ini menggambarkan entitas dunia nyata atau entitas yang dibutuhkan untuk melakukan tugas internal sistem. - Control class memodelkan urutan kelakukan ( behavior ) khusus untuk satu atau lebih use case. Pada awal phasa Elaboration, sebuah control class ditambahkan untuk setiap pasangan actor atau use case. Control class bertanggung jawab untuk aliran kejadian-kejadian dalam use case. RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Class stereotypes <<control>> <<boundary>> <<boundary>> Actor 1 Actor 2 <<entity>> <<entity>> Model interaction between the system and its environment boundary entity control RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

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 Actor merepresentasikan entitas yang berada di luar system. Mereka bisa berupa manusia, perangkat keras atau system lain. General life line Merepresentasikan entitas tunggal dalam sequence diagram, digambarkan dengan kotak. Entitas ini memiliki nama, stereotype atau berupa instance (menggunakan instance:class) RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

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 RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Statechart diagram – example
initial accept new coin Waiting for a coin payment returned accept new coin coin detected accept customer request coin return request return payment product dispensed accept new coin Waiting for selection Returning payment product available=FALSE return payment sufficient payment dispense product Dispensing product RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

Penutup Pemodelan kebutuhan diperlukan untuk meningkatkan pemahaman terhadap kebutuhan yang sedang dianalisis Pemodelan terstruktur meliputi pemodelan data models, process models dan behavioral models dari sistem yang sedang dikembangkan Pemodelan berorientasi objek mencakup scenario-based models, class models dan behavioral models dari sistem yang sedang dikembangkan Alat bantu yang digunakan dalam pemodelan terstruktur dan berorientasi objek terdapat perbedaan RPL - Rekayasa Kebutuhan PL - Pemodelan / Tri A. Kurniawan.,S.T, M.T, Ph.D

REKAYASA PERANGKAT LUNAK (RPL)

Presentasi serupa

Presentasi berjudul: "REKAYASA PERANGKAT LUNAK (RPL)"— Transcript presentasi:

Presentasi serupa

Tentang proyek

Tanggapan

Masuk

Otorisasi melalui jaringan sosial:

REKAYASA PERANGKAT LUNAK (RPL)

Presentasi serupa

Presentasi berjudul: "REKAYASA PERANGKAT LUNAK (RPL)"— Transcript presentasi:

Presentasi serupa

Tentang proyek

Tanggapan