Anda di halaman 1dari 62

CSH3E4

Implementasi dan Pengujian


Tim Dosen
KK SIDE

Pertemuan 01

Introduction

8/26/2016

Profile Dosen

8/26/2016

Profil Dosen
Nama

: Veronikha Effendy, M.T.

Kode dosen

: VRE

KK

: SIDE;

Peminatan

Data Mining
UI/UX
Software Engineering
Artificial Intelligent
Ruang

: IF03.02.02/ F202

HP/WA

: 0817424777

Email

veffendy@telkomuniversity.ac.id
veffendy@gmail.com

8/26/2016

Jadwal Perkuliahan

Aturan Kelas, RPS,


Referensi

8/26/2016

Kontrak Belajar

Jadwal:
o 3 SKS: 3 jam kuliah (3 x 50 menit per minggu)
o 14 minggu (14 pertemuan kelas + 10 pertemuan lab)
o Toleransi keterlambatan 15 Menit (min presensi 75%)

Minimum Presensi 75%


Penilaian: Quiz
UTS
UAS (Presentasi Tubes)
TUBES1 (Dokumen Analisis dan Desain)
TUBES2 (Dokumen Implementasi dan Pengujian)
Praktikum

10%
25%
30%
10%
10%
15%

Batas nilai akhir fleksibel (sesuai distribusi nilai tiap kelas)

Tidak ada kuis/tugas/tugas besar susulan/perbaikan/tambahan

Jika ditemukan indikasi plagiarism dalam tugas/quiz/ujian, nilai akhir MK ini


adalah E

Man Jadda Wajada, Going Extra Miles, Man Shabara Zhafira


8/26/2016

Grading Procedure

Sistem belajar kita:


Student Centered Learning + Problem Based Learning

Capaian Pembelajaran & Deskripsi MK


Capaian Pembelajaran
Setelah mengikuti mata kuliah ini mahasiswa dapat:
Melakukan analisis, perancangan, implementasi (pengkodean) dan
pengujian serta membuat dokumentasi pembangunan perangkat lunak
dengan pendekatan terstruktur.

Deskripsi Mata kuliah


Mata kuliah ini menekankan aspek-aspek yang harus dipenuhi untuk
menghasilkan perangkat lunak yang dirancang bangun dengan baik.
Pendekatan yang digunakan adalah berorientasi objek (OO) yang
mencakup topik-topik: Pengantar Object Oriented, Rationale Unified
Process (RUP), Pemodelan OO (UML), prinsip desain OO, OO programming,
OO Testing, Refactoring, OOMetric, Design Pattern

RENCANA PEMBELAJARAN
SEMESTER

Minggu ke

Bahan Kajian (materi ajar)


Kelas

Introduction:
1. Aturan Kelas, RPS, Referensi, dst
2. Review Analisis dan Perancangan Terstruktur
3. OO Paradigm Introduction
1
4. Review Model Proses
5. Model Proses OO (Fountain, RUP, Agile, ect)
6. Why We Model?
7. UML Introduction
8. Requirement Ditermination
Kelas
1. Structured Diagram
a. Class Diagram
b. Object Diagram
c. Component diagram
d. Deployment diagram
2
2. Behavioral Diagram
a. Sequence Diagram
b. Collaboration diagram
c. Statechart diagram
d. Activity diagram
e. Use Case Diagram
Kelas
Use case diagram:
1. Actor
3
2. Use Case
3. Relasi Use Case
4. Use Case Scenario
Object Diagram
Lab
3 (1)
Pengenalan Lingkungan Tools yang digunakan

RENCANA PEMBELAJARAN
SEMESTER

Minggu ke

Bahan Kajian (materi ajar)


Kelas
1. Class
2. Relasi Class
3. Object

Lab
1.
2.
4 (2)
3.
4.
5.

5-7

7
UTS

Define Actor
Define Use Case
Asosiasi Use Case
Use Case Diagram
Use Case Scenario

Kelas
Prinsip Perancangan OO (open closed principe, segregate interface principle
Design Pattern:
1. Design pattern creational: factory method, abstract factory, builder, prototype, singleton.
2. Design pattern structural: adapter, bridge, composite, decorator, facade, flyweight, proxy.
3. Design pattern behavioral: interpreter, template method, chain of responsibility, command
iterator.
Lab
1. Activity diagram
(3)
2. Component diagram
3. Deployment diagram
Lab
1. Define Class
(4) 2. Define Atribut Class
3. Define Class Method
4. Asosiasi
Lab
(5)
Sequence Diagram
Materi analisis dan perancangan dengan OO modelling

RENCANA PEMBELAJARAN
SEMESTER

Minggu ke
Bahan Kajian (materi ajar)
9
Presentasi TUBES 1: Dokumen Analisis dan Perancangan OO
Lab
9 (6)
Design Pattern : Startegi Pattern
1. Review Implementasi Prosedural
2. Bahasa Pemorgraman OO
10
3. Implementasi OO
4. Refactoring
Lab
10 (7)
Design Pattern : MVC
11
Implementasi berdasarkan:
1. Structural Diagram
2. Behavioral Diagram
Lab
11 (8)
Implementasi OO
12
Review Pengujian Prosedural
Intro Pengujian OO
OO metrics:
1. Number of line code.
2. Number of class.
3. Deep of inheritance.
Lab
12 (9)
Implementasi OO
Pembuatan rencana pengujian berdasarkan :
1. Class Diagram
2. Sequence Diagram
13
3. Use Case Scenario
4. dan diagram lain.
Lab
12 (10)
Pengujian: OO Metrics
14-15
Presentasi TUBES 2: Analisis - Pengujian
UAS
Tugas Besar yang dikerjakan

Project

Your final project is to build an


application based on object-oriented
software-engineering paradigm

References

References

Referensi tambahan:
1. http://www.tutorialspoint.com/object_oriented_analysis_design/
2. http://ecomputernotes.com/software-engineering
3. http://www.tutorialspoint.com/design_pattern/design_pattern_overview.htm
4. http://www.oodesign.com/
5. dst

OO Paradigm
Introduction

Object-Oriented System Development


OO information system development involves:
OOA
Using an OO approach to system analysis

OOD
Using an OO approach to system design

OOP
Using an OO approach to programming

18

Understanding OO Development
OO approach
System is defined as a collection of objects that work
together to accomplish tasks
Objects carry out actions when asked
Each object maintains its own data

Procedural approach
System is defined as a set of procedures that interact with
data
Data is maintained separately from procedures

19

Understanding OO Development

20

Understanding OO Development

21

Understanding OO Development

22

Understanding OO Development
OO Analysis and Design
Unified Modeling Language (UML)
Standard OOA&D modeling notation
Defined by: Grady Booch, James Rumbaugh & Ivar Jacobson
Uses model-driven approach:
Enables creation of graphical models of the system requirements and system design

OO Analysis and Design


Unified Modeling Language (UML)
Components
Class diagrams
Use Case diagrams
Sequence diagrams
Statecharts

23

24

Unified Modeling
Language (UML)
Component

Understanding OO Development
OO Analysis and Design
System Development Life Cycle (SDLC)
Project management framework that defines project phases and activities
Phases:
Planning
Analysis
Design
Implementation
Support

OO Analysis and Design


Prototyping
Creating a working model of one or more parts of the system for user evaluation
and feedback

Joint Application Development (JAD)


Key system stakeholders and decision makers work together to rapidly define
system requirements and designs
25

Understanding OO Development
OO Analysis and Design
Other requirements:
Project management
Interviewing
Data collection
User interface (UI) design
Testing
Conversion techniques

26

Process and Method:


An Introduction to the
Rational Unified Process

Traditional Structured Analysis


Described by W. W. Royce, 1970, IEEE WESCON, Managing
the development of large software systems.
Decomposition in terms of Function and Data
Modularity available only at the file level
cf. C language's static keyword (=="file scope")

Data was not encapsulated:


Global Scope
File Scope
Function Scope (automatic, local)

Waterfall Method of Analysis and Design

Waterfall Method
Requirements Analysis
Analysis Specification
Design Specification
Coding from Design Specification
Unit Testing
System Testing
UAT Testing
Ship It (????)

Measuring rod is in the form of formal


documents (specifications).

Waterfall Process Assumptions


Requirements are known up front before design
Requirements rarely change
Users know what they want, and rarely need
visualization
Design can be conducted in a purely abstract
space, or trial rarely leads to error
The technology will all fit nicely into place when
the time comes (the apocalypse)
The system is not so complex. (Drawings are for
wimps)

Structured Analysis Problems


Reuse is complicated because Data is strewn
throughout many different functions
Reuse is usually defined as code reuse and is
implemented through cutting and pasting of the
same code in multiple places. What happens
when the logic changes?
coding changes need to be made in several different places
changing the function often changes the API which breaks
other functions dependent upon that API
data type changes need to be made each time they are used
throughout the application

Waterfall Process Limitations


Big Bang Delivery Theory
The proof of the concept is relegated to the very end of a
long singular cycle. Before final integration, only documents
have been produced.
Late deployment hides many lurking risks:
technological (well, I thought they would work together...)
conceptual (well, I thought that's what they wanted...)
personnel (took so long, half the team left)
User doesn't get to see anything real until the very end, and
they always hate it.
System Testing doesn't get involved until later in the process.

The Rational Unified Process


RUP is a method of managing OO Software Development
It can be viewed as a Software Development Framework
which is extensible and features:
Iterative Development
Requirements Management
Component-Based Architectural Vision
Visual Modeling of Systems
Quality Management
Change Control Management

RUP Features
Online Repository of Process Information and
Description in HTML format
Templates for all major artifacts, including:
RequisitePro templates (requirements tracking)
Word Templates for Use Cases
Project Templates for Project Management
Process Manuals describing key processes

The Phases

An Iterative Development Process...


Recognizes the reality of changing requirements
Caspers Joness research on 8000 projects

40% of final requirements arrived after the analysis phase, after


development had already begun

Promotes early risk mitigation, by breaking down the system into


mini-projects and focusing on the riskier elements first
Allows you to plan a little, design a little, and code a little
Encourages all participants, including testers, integrators, and
technical writers to be involved earlier on
Allows the process itself to modulate with each iteration, allowing
you to correct errors sooner and put into practice lessons learned
in the prior iteration
Focuses on component architectures, not final big bang
deployments

An Incremental Development Process...


Allows for software to evolve, not be produced in one huge
effort
Allows software to improve, by giving enough time to the
evolutionary process itself
Forces attention on stability, for only a stable foundation can
support multiple additions
Allows the system (a small subset of it) to actually run
much sooner than with other processes
Allows interim progress to continue through the stubbing of
functionality
Allows for the management of risk, by exposing problems
earlier on in the development process

Goals and Features of Each Iteration


The primary goal of each iteration is to slowly chip away at
the risk facing the project, namely:
performance risks
integration risks (different vendors, tools, etc.)
conceptual risks (ferret out analysis and design flaws)
Perform a miniwaterfall project that ends with a delivery
of something tangible in code, available for scrutiny by the
interested parties, which produces validation or correctives
Each iteration is risk-driven
The result of a single iteration is an increment--an
incremental improvement of the system, yielding an
evolutionary approach

Risk Management
Identification of the risks
Iterative/Incremental Development
The prototype or pilot project
Boochs Tiger Team
Early testing and deployment as opposed
to late testing in traditional methods

The Development Phases


Inception Phase
Elaboration Phase
Construction Phase
Transition Phase

The Development Phases (contd)


Inception Phase Iteration

Initiate Project

Plan and Manage Iteration

Identify and Refine Requirements

Agree on Technical Approach

Objective of Inception phase


Understand what to build
Identify key system functionality
Determine at least one possible solution
Understand the cost, schedule and risks associated with the
project

The Development Phases (contd)

Elaboration Phase Iteration


Plan and Manage Iteration
Identify and Refine Requirements
Define the Architecture
Develop Solution Increment
Test Solution
Ongoing Tasks

Objective of Elaboration phase

Get a more detailed understanding of the requirements


Design, implement, validate, and baseline an Architecture
Mitigate essential risks, and produce accurate schedule and
cost estimates

The Development Phases (contd)


Objective of Elaboration phase
Get a more detailed understanding of the requirements
Design, implement, validate, and baseline an Architecture
Mitigate essential risks, and produce accurate schedule
and cost estimates

The Development Phases (contd)


Construction Phase Iteration
Plan and Manage Iteration
Identify and Refine Requirements
Develop Solution Increment
Test Solution
Ongoing Tasks

Objective of Construction phase


Iteratively develop a complete product that is ready
to transition to its user community
Minimize development costs and achieve some
degree of parallelism

The Development Phases (contd)


Transition Phase Iteration
Plan and Manage Iteration
Develop Solution Increment
Test Solution
Ongoing Tasks

Objective of Transition phase


Beta test to validate that user expectations are met
Achieve stakeholder concurrence that deployment is
complete

The Development Phases (contd)

Inheritance
and
polymorphism
Encapsulation
and
information
hiding

Aggregation

Abstract Data
Types (ADT)

Objects and
classes

Review of OO Concepts
concepts of encapsulation, abstraction, inheritance, and
polymorphism

48

Pure Object Oriented Languages


Five rules [Source: Alan Kay]:

1.

Everything is an object.

2.

A program is a set of objects telling each other what to do


by sending messages.

3.

Each object has its own memory (made up by other


objects).

4.

Every object has a type.

5.

All objects of a specific type can receive the same


messages.

Java breaks some of these rules in the name of efficiency.

The Object Concept


An object is an encapsulation of data.
An object has
identity (a unique reference),
state, also called characteristics
behavior

An object is an instance of an abstract data


type.
An abstract data type is implemented via a
class.

Abstract Data Type (ADT)


An ADT is a collection of objects (or values) and a
corresponding set of methods.
An ADT encapsulates the data representation and
makes data access possible at a higher level of
abstraction.
Example 1: A set of vehicles with operations for
starting, stopping, driving, get km/liter, etc.
Example 2: A time interval, start time, end time,
duration, overlapping intervals, etc.

Encapsulation and Information Hiding


Data can be encapsulated such that it is invisible
to the "outside world".
Data can only be accessed via methods.

Encapsulation and Information Hiding,


cont.

What the "outside world" cannot see it cannot depend on!


The object is a "fire-wall" between the object and the
"outside world".
The hidden data and methods can be changed without
affecting the "outside world".

Class vs. Object


Class

Object

A description of the common


properties of a set of objects

A representation of the
properties of a single instance

A concept.

A phenomenon.

A class is a part of a program

An object is part of data and a


program execution.

Example 1: Person

Example 1: Bill Clinton, Bono,


Viggo Jensen.

Example 2: Album

Example 2: A Hard Day's Night,


Joshua Tree, Rickie Lee Jones.

Type and Interface


An object has type and an interface.

To get an object: Account a = new Account()


To send a message: a.withdraw()

Aggregation and Decomposition


An aggregation consists of a number of (sub)concepts which collectively is considered a new
concept.
A decomposition splits a single concept into a
number of (sub-) concepts.

Aggregation and Decomposition,


Example

Idea: make new objects by combining existing


objects.
Reusing the implementation!

Generalization and Specialization


Generalization creates a concept with a broader scope.
Specialization creates a concept with a narrower scope.
Reusing the interface!

Generalization and Specialization,


Example

Inheritance: get the interface from the general


class.
Objects related by inheritance are all of the same
type.

Reference
http://people.cs.aau.dk/~torp/Teaching/E03/OOP/
handouts/introduction.pdf

THANK YOU
8/26/2016
61