UML Process From Requirement Software Requirement Requirements engineering

UML Process From Requirement

Software Requirement • Requirements engineering adalah fase terdepan dari proses rekayasa perangkat lunak (software engineering), dimana software requirements (kebutuhan) dari user (pengguna) dan customer (pelanggan) dikumpulkan, dipahami dan ditetapkan. • Kebanyakan kegagalan pengembangan software disebabkan karena adanya: – Ketidakkonsistenan (inconsistent), – Ketidaklengkapan (incomplete), maupun – Ketidakbenaran (incorrect) dari requirements specification (spesifikasi kebutuhan)

Software Requirement • Studi di The Standish Group mencatat bahwa prosentase akumulatif kegagalan sebuah project pengembangan software sebagian besar disebabkan oleh masalah requirements dan spesifikasinya [Standish-94].

Software Requirement - Definisi • Requirements engineering adalah cabang dari software engineering yang mengurusi masalah yang berhubungan dengan: tujuan (dunia nyata), fungsi, dan batasan-batasan pada sistem software. Termasuk hubungan faktor tersebut dalam menetapkan spesifikasi yang tepat dari suatu software, proses evolusinya baik berhubungan dengan masalah waktu maupun dengan software lain [Zave-97]

Software Requirement • Requirements engineering dibagi dalam 3 proses besar yaitu: – elicitation, – specification, – validation and verification. • Formula ini kemudian juga dikenal dengan nama The Three Dimensions of Requirements Engineering • Proses requirements engineering ini dilakukan secara iterasi dengan mengakomodasi adanya feedback dari customer (user).

Software Requirement Process

Requirements Elicitation • Adalah proses mengumpulkan dan memahami requirements dari user. Kadang masalah yang muncul berakar dari gap masalah knowledge domain (perbedaan disiplin ilmu yang dimiliki). Customer adalah expert pada domain yang softwarenya ingin dikembangkan (domain specialist), dilain pihak sang pengembang (requirements analyst) adakalanya sama sekali buta terhadap knowledge domain tersebut • Gap knowledge domain tersebut yang diharapkan bisa diatasi dengan adanya interaksi terus menerus dan berulang (iterasi) antara pengembang dan customer

Requirements Specification • Setelah masalah berhasil dipahami, pengembang mendeskripsikannya dalam bentuk dokumen spesifikasi. Spesifikasi ini berisi tentang fitur dan fungsi yang diinginkan oleh customer, dan sama sekali tidak membahas bagaimana metode pengembangannya. • IEEE mengeluarkan standard untuk dokumen spesifikasi requirements yang terkenal dengan nama IEEE Recommended Practice for Software Requirements Specifications [IEEE-830]. • Dokumen spesifikasi requirements bisa berisi functional requirements, performance requirements, external interface requirements, design constraints, maupun quality requirements.

Requirements Validation and Verification • Setelah spesifikasi requirements berhasil dibuat, perlu dilakukan dua usaha: – Validation (validasi), yaitu proses untuk memastikan bahwa requirements yang benar sudah ditulis. – Verification (verifikasi), yaitu proses untuk memastikan bahwa requirements sudah ditulis dengan benar. • Proses validasi dan verifikasi ini melibatkan customer (user) sebagai pihak yang menilai dan memberi feedback berhubungan dengan requirements.

Requirement (Persyaratan) • Requirement adalah pernyataan yang mendefinisikan tujuan atau batasan sistem yang harus terpenuhi – Perlu dipahami oleh tim pengembang dan divalidasi oleh para stakeholder dan pengguna (user) – Sebagai kriteria penentuan lolos / gagal yang dapat diverifikasi oleh tim penguji – Prioritas yang ditetapkan dalam kaitannya dengan persyaratan lain

Requirement (Persyaratan) Requirement dibagi menjadi 2 (dua): 1. Functional Requirement (persyaratan fungsional) “Functional requirements define what the system or application will do” 2. Non-functional Requirement (persyaratan non fungsional) “A software requirement that describes not what the software will do, but how the software will do it, for example software performance requirements, software external interface requirements, design constraints, and software quality attributes” IEEE Definition

Non Functional Requirement (NFR) • Persyaratan perangkat lunak yang menggambarkan bagaimana perangkat lunak akan melakukannya, misalnya, persyaratan kinerja perangkat lunak, persyaratan antarmuka eksternal perangkat lunak, dan atribut kualitas perangkat lunak. • Persyaratan nonfungsional sulit untuk diuji oleh karena itu, mereka biasanya dievaluasi secara subyektif

Contoh Functional & Non Functional • Contoh Functional & Non Functional requirements dalam pengembangan Mobile Application: • Functional Requirement: – Cross platform compatible and works on most mobile browser – Integrates a selected number of popular social networking sites in one place – Communicates with social networking APIs – Uses login and OAuth mechanisms to authorize – Records and monitors social networking activity – Stores the data locally Displays total statistics for the user

Contoh Functional & Non Functional • Non functional requirements – Record statistics accurately – Fast navigation – Flexibility to choose which sites they want to integrate out of 3 and do not always have to use all 3. For example; the user should still be able to use Facebook and Twitter in the App and leave out You. Tube (if they are not interested in. You. Tube). – App should be able to function with chosen sites. – Should be flexible in terms of being able to integrate other popular social networking sites too – Should be available to users to use anytime

Analisis Berorientasi Objek • Berfokus pada pendefinisian kelas-kelas dan cara bagaimana mereka saling bekerjasama satu dengan yang lainnya untuk memenuhi kebutuhan para pelanggan. • Pada Paradigma Analysis Design Unified Modeling Language (UML) merupakan perkakas (tools) yang digunakan untuk melakukan pemodelan berorientasi objek

What is the UML? • UML: Unified Modeling Language • UML dapat digunakan untuk memodelkan semua proses dalam siklus hidup pengembangan dan seluruh teknologi implementasi yang berbeda • UML adalah bahasa standar untuk memvisualisasikan, menspesifiksi, konstruksi, dan mendokumentasikan artifak dari sistem perangkat lunak • UML adalah suatu alat komunikasi untuk team dan para stakeholders

Object-oriented Systems UML Diagram dibagi menjadi 3 kategori: 1. Structure diagrams 2. Behavior diagrams 3. Interaction diagrams

Structure diagrams Termasuk pada Structure Diagram meliputi: • Class diagrams • Composite structure diagrams • Component diagrams • Deployment diagrams • Object diagrams • Package diagrams

Structure diagrams

Behavior diagrams Termasuk pada Behavior diagrams meliputi: 1. Activity diagrams 2. Use case diagrams 3. State machine diagrams

Interaction diagrams Termasuk pada Interaction diagrams meliputi: 1. Sequence diagrams 2. Timing diagrams 3. Communication diagrams 4. Interaction overview diagrams

UML Process (Kendal, 2011) 1. Sebuah use case diagram, menggambarkan bagaimana sistem yang digunakan. Analis memulai dengan use case diagram 2. Sebuah activity diagram, menggambarkan aliran keseluruhan kegiatan. Setiap use case dapat membuat satu diagram aktivitas 3. Sequence diagram, menunjukkan urutan kegiatan dan hubungan kelas. Setiap use case dapat membuat satu atau lebih sequence diagram 4. Class diagrams, menunjukkan kelas dan hubungan. Sequence diagram digunakan untuk menentukan kelas 5. Statechart diagram, menunjukkan keadaan transisi. Setiap kelas dapat membuat statechart diagram, yang berguna untuk menentukan class method

(Kendall and Kendall, 2011)

STATE MACHINE DIAGRAM

State Machine Diagram • State Machine Diagram merupakan teknik yang umum digunakan untuk menggambarkan behavior sebuah sistem • Berbagai bentuk State telah ada sejak tahun 1960 -an dan teknik berorientasi objek yang paling awal mengadopsinya untuk menampilkan behavior • Dalam pendekatan berorientasi objek, State Machine Diagram digambarkan untuk suatu Kelas tunggal yang menunjukkan behavior sebuah objek tersebut

Notasi State Machine Diagram

Story • Dalam suatu kastil yang gelap tersimpanlah barang-barang berharga dalam suatu lemari besi. Untuk menunjukkan lubang kunci pada lemari besi tersebut, harus menggunakan obor sebagai media penerangan. Hal ini berlaku bila pintu dalam keadaan tertutup. Jika lubang kunci sudah terlihat, kunci dapat dimasukkan untuk membuka lemari besi. Sebagai prosedur keamanan, lemari tersebut dapat terbuka jika obor terpasang. Namun jika obor tsb tidak terpasang, maka akan kastil akan mengeluarkan monster.

Example State Machine Diagram Lemari besi tertutup Buka Note: State Kunci diputar[Obor terpasang] / Membuka lemari besi Tunggu Note: Titik Awal (Start) Note: Point / Transisi Obor diambil [Pintu tertutup] / Menunjukkan lubang kunci Kunci diputar[Obor tidak terpasang] / Mengeluarkan monster Note: Event [Guard] / Activity Note: Titik akhir (end) Terkunci

Penjelasan • Diagram di atas menunjukkan adanya 3 (tiga) State: Tunggu, Terkunci, dan Buka. • Diagram di atas juga menjelaskan mengenai aturan-aturan untuk berpindah dari satu State ke State lain (Aturan tertulis dalam Transisi) • Transisi menunjukkan pergerakan dari suatu State ke State lain. Transisi memiliki label yang terdiri dari 3 (tiga) bagian: event [guard] / activity • Event berupa trigger/pemicu terjadinya peralihan pada state • Guard menunjukkan adanya kondisi (jika mensyaratkan adanya kondisi) dalam bentuk boolean • Activity merupakan behavior yang dieksekusi selama transisi

Penjelasan [lanj] • Dalam state Tunggu jika obor diambil dengan pintu tertutup, maka akan melakukan aktivitas menunjukkan lubang kunci dan pindah ke state ter. Kunci • Pada state Terkunci jika kunci diputar dengan kondisi obor terpasang maka akan melakukan aktivitas membuka lemari besi, namun jika kunci diputar dengan kondisi obor tidak terpasang maka akan mengeluarkan monster dan selesai

State UML mendefinisikan beberapa macam State: • Simple State • Composite State

Simple State • Suatu Simple State merupakan state yang tidak memiliki substate, region • Simple State boleh memiliki Compartment (ruang), compartment beserta Ruang Aktivitas Internal / Internal aktivities compartment Simple state Waiting for Customer Input.

Simple State Internal activities compartment • Terdapat beberapa label sudah ada pada sistem yang tidak boleh digunakan • Beberapa lebel tersebut meliputi: – Entry – Do – Exit Simple state Waiting for Customer Input dengan nama dan ruang aktivitas internal (entry dan exit)

Composite State didefinisikan sebagai state yang memiliki substates (nested states) Composite State terdiri dari 2 (dua) jenis: 1. Simple Composite State: memuat hanya 1 region 2. Orthogonal Composite State: memiliki lebih dari 1 region Simple composite state Serving Customer has two substates.

Contoh Online Banking System • Contoh model diagram untuk login yang merupakan bagian dari Online Banking System. • Logging in terdiri atas masukan input Social Security Number dan Personal Id Number yang berlaku, lalu memutuskan kesahan dari informasi tersebut.

Contoh Online Banking System • Logging in dapat dibagi menjadi empat tahapan proses, yaitu : – Getting SSN (masukkan SSN), – Getting PIN (masukkan PIN), – Validating (periksa kesahannya), dan – Rejecting (keluar).

Online Banking System

• Proses peralihan digambarkan dengan panah dari satu state ke yang lainnya. Event (peristiwa) atau condition (keadaan) yang menyebabkan perubahan dituliskan pada samping panah • Diagram ini mengandung dua self-transition (transisi sendiri), satu pada getting SSN dan lainnya pada getting PIN

• Keadaan awal Start (black circle /lingkar hitam) adalah dummy (model) untuk memulai action (kegiatan). Keadaan akhir juga keadaan model yang menghentikan kegiatan • Aksi yang terjadi sebagai hasil dari suatu peristiwa atau keadaan ditandai dalam bentuk /action.

• Pada Validating State, obyek tidak menunggu peristiwa dari luar untuk menyebabkan suatu perubahan. Sebagai gantinya melakukan suatu activity (aktifitas). Hasil dari aktifitas tersebut menentukan keadaan berikutnya dari obyek tersebut.

SEQUENCE & COLLABORATION DIAGRAM

Example Sequence Hotel Reservation

Penjelasan Sequence • Gambar di atas adalah diagram Sequence untuk pembuatan Hotel Reservation. Obyek yang mengawali urutan message adalah ‘a. Reservation Window • ‘Reservation window’ mengirim pesan make. Reservation() ke ‘Hotel. Chain’. Kemudian ‘Hotel. Chain’ mengirim pesan yang sama ke ‘Hotel’. Bila ‘Hotel’ punya kamar kosong, maka dibuat ‘Reservation’ dan ‘Confirmation’.

Penjelasan Sequence • Pada gambar diagram , terlihat bahwa ‘Hotel’ telah melakukan pemanggilan diri sendiri untuk pemeriksaan jika ada kamar kosong. Bila benar, maka ‘Hotel’ membuat ‘Reservation’ dan ‘Confirmation’. • Pemanggilan diri sendiri disebut dengan iterasi. Expression yeng dikurung dengan “[ ]”, adalah condition (keadaan kondisi).

• Diagram Collaboration juga merupakan diagram interaction. • Diagram membawa informasi yang sama dengan diagram Sequence, tetapi lebih memusatkan atau memfokuskan pada kegiatan obyek dari waktu pesan itu dikirimkan

Collaboration Diagram

PACKAGE DIAGRAM

Package Diagram • Untuk mengatur pengorganisasian diagram Class yang kompleks, dapat dilakukan pengelompokan kelas-kelas berupa package (paket-paket). • Package adalah kumpulan elemen-elemen logika UML. Gambar di bawah ini mengenai model bisnis dengan pengelompokan kelas dalam bentuk paket-paket

Contoh Package Diagram

COMPONENT DIAGRAM

Component Diagram • Component diagram menggambarkan struktur dan hubungan antar komponen piranti lunak, termasuk ketergantungan (dependency) di antaranya. • Komponen piranti lunak adalah modul baik berisi source code, binary code, library maupun executable • Pada umumnya komponen terbentuk dari beberapa class dan/atau package, tapi dapat juga dari komponen-komponen yang lebih kecil. • Komponen dapat juga berupa interface, yaitu kumpulan layanan yang disediakan sebuah komponen untuk komponen lain.

Contoh Component Diagram Demo. html applet 1. class applet 1. java applet 2. class applet 2. java logo. gif

DEPLOYMENT DIAGRAM

Deployment Diagram • Deployment/physical diagram menggambarkan detail bagaimana komponen di-deploy dalam infrastruktur sistem, di mana komponen akan terletak (pada mesin, server atau piranti keras apa) • Sebuah node adalah server, workstation, atau piranti keras lain yang digunakan untuk men-deploy komponen dalam lingkungan sebenarnya. Hubungan antar node (misalnya TCP/IP) dapat didefinisikan dalam diagram ini. • Artifak merupakan manifestasi fisik dari perangkat lunak yang di-deploy. Atifak dapat berupa file-file seperti. exe, binary, jar, assemby, script, file data, file konfigurasi, dokuman html dsb

Contoh Deployment Diagram

Contoh Deployment