Software Engineering:[Process]

disadur dari ilmukomputer.com

OUTLINE

2. P rocess2 .1 S oftware D evelopment L ife C ycle2 .2 S oftware E ffort E stimation

Analysis and Design 1

Analysis Design Paradigm and Diagrams

Paradigm Diagrams

1 Data-oriented DFD

2 Process-oriented Flowchart

3 Object-oriented(data + process)

UML

Sejarah UML

• In the 90s many peoplecreating OO diagramming languages

• Three different ones created by Grady Booch, Ivar Jacobson, James Rumbaugh

• Joined forces with Rational (company) to create Unified Modeling Langauge (UML)

SEJARAH UML

What is the UML?

• UML: Unified Modeling Language

• UML can be used for modeling all processes in thedevelopment life cycle and across different implementationtechnologies (technology and language independent)

• UML is the standard language for visualizing, specifying,constructing, and documenting the artifacts of a software-intensive system

• UML is a communication tool – for the team, and otherstakeholders

The Triangle of Success in Software Dev.

Notation: Standard

Tools: Support Standard and

Process

Process: Customer-Oriented

Methodology

UML Tools• Rational Rose

• Visual Paradigm

• Enterprise Architect

• Microsoft Visio

• Star UML

• Netbeans UML Plugin

UML 2.0 DiagramsUML version 2.0 has 14 diagrams in 2 major groups:

1. Structure Diagrams

2. Behavior Diagrams

UML 2.0 Diagram

UML Structure Diagrams

Represent the data and static relationships in an information system

1. Class Diagram

2. Object Diagram

3. Package Diagram

4. Deployment Diagram

5. Component Diagram

6. Composite Structure Diagram

Structure Diagrams

1. Class Diagrams• Common vocabulary used by analyst and users• Represent things (employee, paycheck,…)• Shows the relationships between classes

2. Object Diagrams• Similar to class diagrams• Instantiation of a class diagram• Relationships between objects

3. Package Diagrams

• Group UML elements together to form higher levelconstructs

Structure Diagrams

4. Deployment Diagrams

• Shows the physical architecture and software components of system

• For example, network nodes

5. Component Diagrams

• Physical relationships among software components

• Example – Client/Server (Which machines run which software)

6. Composite Structure

• Illustrates internal structure of a complex class

UML Behavior Diagrams

• Depict the dynamic relationships among the instances or objectsthat represent the business information system

1. Activity Diagram

2. Sequence Diagram

3. Communication Diagram

4. Interaction Diagram

5. Timing Diagram

6. Behavior State Machine

7. Protocol State Machine

8. Use Case Diagrams

Behavior Diagrams

1. Activity Diagrams

• Model processes in an information system

• Example: Business workflows, business logic

2. Interaction Diagrams

• Shows interaction among objects

3. Sequence Diagrams

• Time-based ordering of the interaction

4. Communication Diagrams

• Communication among a set of collaborating objects ofan activity

Behavior Diagrams

5. Interaction Diagrams• Overview of flow of control of a process

6. Timing Diagrams• Show how an object changes over time

7. State Machines• Examines behavior of one class• Models the different states and state transitions an object

can experience

8. Use-Case Diagrams• Shows interaction between the system and environment• Captures business requirements

UML Problems

1. UML is modeling notation, it is not a development process ora methodology

• UML driven development process?

2. UML is too complex, difficult to understand quickly

• Should we use all UML diagrams?

UML Process (EA Sparx)1. Display the boundary of a system and its major functions

using use cases and actors

2. Model the organization’s business process with activitydiagram

3. Illustrate use case realizations with sequence diagrams

4. Represent a static structure of a system using classdiagrams

5. Reveal the physical implementation architecture withdeployment diagrams

UML Process (EA Sparx)

1. Use Cases Diagram

2. Activity Diagram

3. Sequence Diagram

4. Class Diagram

5. Deployment Diagrams

UML Process (Kendal, 2011)

1. A use case diagram, describing how the system is used. Analysts startwith a use case diagram

2. An activity diagram, illustrating the overall flow of activities. Each usecase may create one activity diagram

3. Sequence diagrams, showing the sequence of activities and classrelationships. Each use case may create one or more sequencediagrams

4. Class diagrams, showing the classes and relationships. Sequencediagrams are used to determine classes

5. Statechart diagrams, showing the state transitions. Each class maycreate a statechart diagram, which is useful for determining classmethods

UML Process (Barclay, 2004)

System Analysis and Design with UML

System Analysis1. Business Process Identification

▪ Use Case Diagram

2. Business Process Modeling▪ Activity Diagram or Business Process

Modeling Notation (BPMN)

3. Business Process Realization▪ Sequence Diagram (Buat untuk setiap

use case dengan menggunakan pola Boundary-Control-Entity)

S ystem D esig n1. P rog ram D esig n

C lass D iag ram (G abung kan B oundary-C ontrol-E ntity C lass dan susun story dari sistem yang dibangun)P ackage D iag ram (G abungan class yang sesuai, boleh meng gunakan pola B -C -E )Deployment D iag ram (arsitektur software dari sistem yang dibangun)

2. U ser Interface Design (B uat U I desig n dari B oundary C lass)

3. E ntity-R elationship Model (B uat E R diag ram dari E ntity C lass)

SDLC and Artifacts1. Planning

1.1 System Request

1.2 Feasibility Analysis

2. Analysis

2.1 Use Case Diagram

2.2 Activity Diagram

2.3 Sequence Diagram

3. Design

3.1 Class Diagram

3.2 Deployment Diagram

3.3 User Interface Design

3.4 Data Model

4. Implementation4.1 Program Code4.2 Testing Plan4.3 Documentation

SystemProposal

SystemSpecification

NewSoftware

Use Case Diagram

Use Case Diagrams

• Summarized into a single picture

• All of the use cases for the part of the system being modeled

• Use case represents the discrete activities performed by the user

• Use Case Diagram tells what the system will do

• Good for communicating with users

Syntax for an Use Case Diagram

• Actor• person or system that derives benefit

from and is external to the subject

• Use Case• Represents a major piece of system

functionality

• Association Relationship

• Include Relationship

• Extend Relationship

• Generalization Relationship

• Assosiaton : komunikasi antara aktor dan use case yang berpartisipasi pada use caseatau use case memiliki interaksi dengan aktor

• Extend : relasi use case tambahan ke sebuah use case, dimana use case yang ditambahkan dapat berdiri sendiri walau tanpa use casetambahan itu

• Generalization : hubungan generalisasi dan spesialisasi antara 2 buah use case, dimana fungsi yang satu adalah fungsi yang lebih umum dari lainnya.

• Include : use case yang tambahan akan selalu melakukan pengecekan, apakah use case yang ditambahkan telah dijalankan sebelum use case tambahan dijalankan

Syntax for an Use Case Diagram

Use Case

• A major piece of system functionality

• Can extend other Use Cases

• Placed inside system boundary

• Labeled with descriptive verb - noun phrase

Use Case

System Boundary

• Includes the name of the systeminside or on top

• Represents the scope of the system

• Actors are outside the scope of the system

Boundary

Actor

• A person or another system that interactswith the current system

• A role, not a specific user

• Provides input,

• receives output, or both

actor

Actor/Role

Association Relationship

• Links actor and the Use Case

• Shows two-way communication

• If one-way, arrows are used

• * is for "multiplicity of the Association"

* *

Extends Relationship

• Extends Use Case to include Optional behavior

• Arrow points from the extension Use Case to the base Use Case

extendMake Payment

Arrangement

extend

Make Appointment

Include Relationship• Include one Use Case from within another

• Arrow points from base Use Case to the included Use Case

include

Create New PatientincludeMake New

Patient Appointment

Generalization Relationship

• A specialized Use Case to a more generalized Use Case

• Arrow points from specialized to general Use Case

Make

Appointment

Make Old

Appointment

Use Case Diagram –Case Study

uc UCD Sistem ATM

Online ATM System

Sistem Core Banking

Melakukan Logout

Mengirim Uang

Mengecek Saldo

Memasukan PIN

Nasabah

Menambah Koleksi

Undergrad

Student

Librarian

LecturerPostgrad

Student

Browse Catalog

Meng-konfirmasi

Transaksi

Memesan Buku

Meminjam Buku

Memesan Copy

Memperpanjang

Pinjaman

Sistem Informasi Perpustakaan

Latihan Studi Kasus

• Pahami kembali System Request yang sudah dibuat

• Lanjutkan dengan membuat Use Case Diagram dari System Request yang dibuat

Activity Diagram

Syntax for an Activity Diagram

2. Activity Diagram: Memasukkan PIN

act 2 AD Memasukan PIN

Sistem ATMNasabah

Mulai

Selesai

Memasukan PIN

di Menu PIN

Memv alidasi

PIN

PIN Valid?

Menampilkan

Menu Utama

Mengecek

Jumlah Input PIN

Lebih dari 3x?

Memblokir

Account

yatidak

tidak

ya

2. Activity Diagram: Mengecek Saldo

act 3 AD Mengecek Saldo

Sistem Core BankingSistem ATMNasabah

Mulai

Selesai

Memilih Mengecek

Saldo di Menu Utama

Merequest

Jumlah SaldoMemproses request

jumlah saldo

Menampilkan Jumlah

Saldo di Layar

2. Activity Diagram: Mentransfer Uang

act 5 AD Mentransfer Uang

Sistem Core BankingSistem ATMNasabah

Mulai

Selesai

Memilih Mentransfer

Uang di Menu Utama

Menampilkan Isian No

Rekening Tujuan

Mengisikan No

Rekening Tujuan

Memv alidasi No

Rekening Tujuan

Rekening Valid?

Menampilkan Isian

Jumlah Uang

Mengisikan

Jumlah Uang

Mengecek

Kecukupan Saldo

Saldo Cukup?

Memproses

Pengiriman Uang

Merequest Validasi

Account

Merequest

Kecukupan Saldo

tidak

tidak

ya

ya

2. Activity Diagram: Melakukan Logout

act 6 AD Melakukan Logout

Sistem ATMNasabah

Mulai

Selesai

Memilih

Logout

Memproses

Logout

Mengeluarkan Kartu

di Kotak Kartu

Mengeluarkan Kuitansi

di Kotak Kuitansi

Latihan Studi Kasus

• Pahami kembali System Request yang sudah dibuat

• Lanjutkan dengan membuat Activity Diagram dari System Request yang dibuat

Sequence Diagram

Sequence Diagrams

• Illustrate the objects that participate in a use case

• Show the messages that pass between objects for a particular use-case over time

Sequence Diagram Syntax

AN ACTOR

AN OBJECT

A LIFELINE

A FOCUS OF CONTROL

A MESSAGE

OBJECT DESTRUCTION

anObject:aClass

x

3. Sequence Diagram: Memasukkan PINsd 1 SD Memasukan PIN

Nasabah

MenuPIN PengelolaValidasi Login MenuUtama

alt PIN Valid?

[ya]

[tidak]

alt lebih dari3x?

[tidak]

[ya]

blokirAccount()

validasiPIN()

errorAccountDiblokir()

masukanPIN()

tampilkan()

getPIN()

tampilkan()

Type of Class

1. Boundary Class

• Class yang berhubungan dengan actor (user interface)

2. Control Class

• Class yang berhubungan dengan pemrosesan, komputasi, penghitungan, dsb

3. Entity Class

• Class yang berhubungan dengan data (flat file or database)

3. Sequence Diagram: Mengecek Saldosd 2 SD Mengecek Saldo

Nasabah

MenuUtama MenuMengecekSaldoPengelolaPengecekanSaldo

Sistem Core Banking

Balance Transaction

pilihMengecekSaldo()

setSaldo(saldo)

setTransaksi(id, date, type)

requestCekSaldo(id)

tampilkanSaldo()

cekSaldo(id)

3. Sequence Diagram: Mentransfer Uangsd 4 SD Mengirim Uang

Nasabah

MenuUtama MenuMengirimUang PengelolaPengirimanUang AccountPengirim:Balance Penerima:Balance Transaction

alt Account Valid?

[tidak]

[ya]

masukanAccountTujuan()

tampilkanHasil()

kirimUang(idPengirim, idPenerima, jumlah)

masukanJumlahUang()

pil ihMengirimUang()

tampilkan()

cekKecukupanSaldo()

getSaldo()

getID()

tampilkan()

setTransaksi(id, date, type)

setSaldo(saldo)

validasiAccount()

setSaldo(saldo)

3. Sequence Diagram: Melakukan Logoutsd 5 SD Melakukan Logout

Nasabah

MenuUtama PengelolaLogout MenuLogout

logout()

tampilkan()

pil ihLogout()

Latihan Studi Kasus

• Pahami kembali System Request yang sudah dibuat

• Lanjutkan dengan membuat Sequence Diagram dari System Request yang dibuat

Class Diagram

Class Diagram Elements

1. Classes

2. Attributes

3. Operations

4. Relationships

Classes

• Templates for creating instances or objects

• All objects of a class have same structure and behavior, but contain different attributes

1. Concrete: used to create actual objects

2. Abstract: extended to create other classes

Attributes

• Units of information relevant to the description of the class

• Only attributes important to the task should be included

• Attributes should be primitive types (integers, strings, doubles, date, time, Boolean, etc.)

Operations (Methods)

• Defines the behavior of the class

• Action that instances/objects can take

• Focus on relevant problem-specific operations (at this point)

Relationships• Generalization

• “Is-A” relationship• Enables inheritance of attributes & oper's• Subclasses and superclasses• Principle of substitutability

• Subclass be substituted for superclass

• Aggregation• “Has-A” relationship• Relates parts to wholes• Uses decomposition

• Association

• Relationships that don't fit “Is-A” or “Has-A”

• Often a weaker form of “Has-A”

• Miscellaneous relationships between classes

• Example:

• Patient schedules an appointment

• So the appointment has a patient

• This is weak

Example Class Diagram

More on Attributes• Derived attributes

• /age, for example can be calculated from birth date and current date

• Visibility of attributes

• +Public: not hidden from any object

• #Protected: hidden from all but immediate subclasses

• –Private: hidden from all other classes

• Default is private

Relationship Multiplicity

Exactly one

Zero or more

One or more

Zero or one

Specified range

Disjoint ranges

Dept

Employee

Boss

Employee

Employee

Employee

Boss

Child

Employee

Spouse

Vacation

Committee1..3, 5

2..4

0..1

1..*

0..*

1

Class Diagram – Case Studyclass CD Sistem ATM

Account

~ alamat: String

~ id: int

~ nama: String

~ pekerjaan: String

+ getAlamat(): String

+ getId(): int

+ getNama(): String

+ getPekerjaan(): String

+ setAlamat(String): void

+ setId(int): void

+ setNama(String): void

+ setPekerjaan(String): void

Balance

Login

MenuLogout

MenuMengecekSaldo

MenuMengirimUang

MenuPIN

MenuUtama

PengelolaLogout

PengelolaPengecekanSaldo

PengelolaPengirimanUang

PengelolaValidasi

+ blokirAccount(): void

+ validasiKartu()

+ validasiPIN(): void

Transaction

SistemATM

is-a

access

do

has-a

access

is-a

access

do

is-a

access

do

do

Latihan Studi Kasus

• Pahami kembali System Request yang sudah dibuat

• Lanjutkan dengan membuat Class Diagram dari System Request yang dibuat

Deployment Diagram – Case Studydeployment DD Sistem ATM

Rich Client

«artifact»

JFC

«artifact»

JVM

Application Serv er

Web Container EJB Container

«artifact»

JSP

«artifact»

JSF

«artifact»

Serv let

«artifact»

SessionBean

DBMS

«artifact»

MySQL

«artifact»

Zend Optimizer

User Interface Design – Case Study

Data Model – Case Studyclass DM Sistem ATM

Account

«column»

*PK id: INTEGER

nama: VARCHAR(50)

jeniskelamin: VARCHAR(50)

pekerjaan: VARCHAR(50)

FK idLogin: INTEGER

FK idBalance: INTEGER

FK idTransaction: INTEGER

«FK»

+ FK_idBalance(INTEGER)

+ FK_idLogin(INTEGER)

+ FK_idTransaction(INTEGER)

«PK»

+ PK_Account(INTEGER)

Login

«column»

*PK idLogin: INTEGER

pin: INTEGER

«PK»

+ PK_Login(INTEGER)

Transaction

«column»

*PK idTransaction: INTEGER

tanggal: DATE

tipe: INTEGER

transaksi: VARCHAR(50)

«PK»

+ PK_Transaction(INTEGER)

Balance

«column»

*PK idBalance: INTEGER

saldo: INTEGER

«PK»

+ PK_Balance(INTEGER)

+idBalance

+PK_Balance

+idLogin

+PK_Login

+idTransaction

+PK_Transaction

Latihan Studi Kasus

• Pahami kembali System Request yang sudah dibuat

• Lanjutkan dengan membuat Deployment Diagram, User Interface Design dan Data Model dari System Request yang dibuat