44
Introduction Pemodelan Berorientasi Obyek

OOP 1 Introduction

Embed Size (px)

Citation preview

Page 1: OOP 1 Introduction

Introduction

Pemodelan Berorientasi Obyek

Page 2: OOP 1 Introduction

Tujuan

● Dapat menggunakan syntax dan semantic OOP

● Memahami konsep pengembangan perangkat lunak berorientasi obyek

● Dapat membuat aplikasi perangkat lunak berorientasi obyek

Page 3: OOP 1 Introduction

Materi

● Konsep Dasar OOD● Class dan Method● Inheritance dan polimorphism● Dasar UML● Use Case Diagram● Activity Diagram● Sequence Diagram● Class Diagram● Deployment Diagram

Page 4: OOP 1 Introduction

Software Development

Page 5: OOP 1 Introduction

Methodology

● A methodology is a systematic way of doing things.● a repeatable process that we can follow from the

earliest stages of software development (the germ of an idea or a new business opportunity) through to the maintenance of an installed system.

● a methodology should specify what we’re expected to produce as we follow the process

● include advice or techniques for resource management, planning, scheduling and other management tasks

Page 6: OOP 1 Introduction

Methodology

● A methodology can help to impose discipline on the coding effort.

● Going through even the basic steps of a methodology increases our understanding of the problem, improving the quality of our solution.

● Writing lines of code is only one of the many activities in software development: performing some of the other activities helps us to spot conceptual and practical mistakes before we commit them to source code.

Page 7: OOP 1 Introduction

Methodology

● At every stage, a methodology specifies what we should do next, so we’re not left scratching our heads, thinking ‘Okay, what now?’

● A methodology helps us to produce code that is more extensible (easier to change), more reusable (applicable to other problems) and easier to debug (because it has more documentation).

Page 8: OOP 1 Introduction

Good Methodology

● Planning: Deciding what needs to be done.● Scheduling: Mapping out when things will be

done.● Resourcing: Estimating and acquiring the

human, software, hardware and other resources that are needed.

● Workflows: The subprocesses within the wider development effort (for example, designing the system architecture, modeling the problem domain and planning the development effort).

Page 9: OOP 1 Introduction

Good Methodology

● Activities: Individual tasks within a workflow, such as testing a component, drawing a class diagram or detailing a use case, too small or indefinable to be a workflow in their own right.

● Roles: The parts played by personnel within the methodology (developer, tester or sales person).

● Artifacts: The products of the development effort: pieces of software, design documents, training plans and manuals.

● Education: Deciding how to train personnel, if necessary, to fulfill their required roles;deciding how end users (staff, customers, sales people) will learn how to use the new system.

Page 10: OOP 1 Introduction

CLASSICAL PHASES IN SOFTWARE PRODUCTION

● Requirement● Analysis● Design● Specification● Implementation● Testing● Deployment● Maintenance

Page 11: OOP 1 Introduction

Key Questions

● Requirements phase:– What is our context?’

– What are we trying to achieve?’

● Analysis phase:– What entities are we dealing with?’

– How can we be sure we have the right ones?’

● System design phase:– ‘How are we going to solve the problem?’

– ‘What hardware and software will we need in the finished system?’

Page 12: OOP 1 Introduction

Key Questions

● Subsystem design phase:– ‘How are we going to implement the solution?’

– ‘What will the source code and supporting files look like?’

● Specification phase:– ‘What rules govern the interfaces between the

system components?’

– ‘Can we remove ambiguity and ensure correctness?’

Page 13: OOP 1 Introduction

Key Questions

● Implementation phase:– ‘How can we code the components to meet the

specification?’

– ‘How do we write stylish code?’

● Testing phase:– ‘Does the finished system satisfy the

requirements?’

– ‘Can we break the system?’

● Deployment phase:– ‘What do the system administrators have to do?’

– ‘How can we educate the end users?’

Page 14: OOP 1 Introduction

Key Questions

● Maintenance phase:– ‘Can we find and fix the faults?’

– ‘Can we improve the system?’

Page 15: OOP 1 Introduction

15

We Need a Plan!

SOFTWARE DEVELOPMENT METHOD

http://sern.ucalgary.ca/courses/cpsc/451/W98/Complexity3.gif

http://www.vantagepoint.ca/images/blueprint.jpg

http://www.emb.org.hk/irooms/eservices/eserviceshelp/eServices%20Help%20Maual/RoBoHelp/School/en/!SSL!/WebHelp/appendixIa.JPG

Page 16: OOP 1 Introduction

16

SOFTWARE DEVELOPMENT METHOD

1. Specify the problem requirements

2. Analyze the problem

3. Design the algorithm

4. Coding

5. Testing and verification

6. MaintenanceAlso known as the Waterfall Method;

one step is dependent on the previous step.

The process of developing a computer program to solve a specific problem:

Page 17: OOP 1 Introduction

17

SOFTWARE DEVELOPMENT METHOD Fun Example: Assemble a Swing Set

I. Problem Specification – to assemble a swingset from a kitII. Problem Analysis

What are the inputs? The objects! The Things!Need a kit (go buy one)Does it have all the parts in the kit?

Screws, braces, directions, etc.Need tools – scissors, screw driver, wrenchWhat is the output? The result? A swing set

III. Design – Plan for doing the work Step 1: Major tasks refinement into more detailed subtasks

1. Assemble the individual componentsAssemble the frameAssemble the seatsAssemble the teetertooterAssemble the slide

2. Put the components together Step 2: Now, Convert the outline of the steps into a detailed step-by-step list, the algorithm.

IV. Follow the detailed steps/directionsImplement the algorithm!

V. Test the swingIs it safe? Any sharp edges? What is the max weight?OK kids come play!!! Released for use

VI. Check on it occasionally – maintenance

Add a chin-up barCheck for broken partsUpgrade the slide, etc.

Page 18: OOP 1 Introduction

18

SOFTWARE DEVELOPMENT METHOD

1. Specify the problem requirements http://www.combourg.com/granit/4.jpg

Establish the level of abstraction:

Understand the problem.

What is NOT the problem?

What is essential to solve the problem?

Eliminate unnecessary unimportant information.

Gather missing information.

State the “Problem Specification”

We will simplify the specification to a formal one-line statement of the problem. Be clear and concise -

“To calculate … “To produce …” “To determine …”

State the “Problem Specification”We will simplify the specification

to a formal one-line statement of the problem. Be clear and concise -

“To calculate … “To produce …” “To determine …”

Page 19: OOP 1 Introduction

19

SOFTWARE DEVELOPMENT METHOD

2. Analysis

Identify the output data (outputs) Outputs are the desired results of the processing. How are the results to be presented to the user? May need to specify formulae and special constants.

What is the general appearance of the output?Report headings, summary information, etc.

Identify the output data (outputs) Outputs are the desired results of the processing. How are the results to be presented to the user? May need to specify formulae and special constants.

What is the general appearance of the output?Report headings, summary information, etc.

Identify the input data needed (inputs) What are the ”things” or “objects”?

Ex. Names, stock numbers, quantities What is the data you must work with or manipulate?

How should the data be input? What is the format or appearance of the data? What is the range of acceptable values?

Identify the input data needed (inputs) What are the ”things” or “objects”?

Ex. Names, stock numbers, quantities What is the data you must work with or manipulate?

How should the data be input? What is the format or appearance of the data? What is the range of acceptable values?

Page 20: OOP 1 Introduction

20

SOFTWARE DEVELOPMENT METHOD

2. Analysis continued Identify data needed for processing only. Begin a descriptive list of the data elements required.

The list will grow in detail as the process continues. Contains: data that is input,

data used in processing,data to be output.

Data Dictionary: a formal list documenting the data elements required to solve the problem.

VariableName Use/Description Acceptable Values Data Type-------------------------------------------------------------------------------------------------------------StuName name of a student alphabet ??SocSecurityNum social security number pos 8 digits ??

Data Dictionary: a formal list documenting the data elements required to solve the problem.

VariableName Use/Description Acceptable Values Data Type-------------------------------------------------------------------------------------------------------------StuName name of a student alphabet ??SocSecurityNum social security number pos 8 digits ??

Page 21: OOP 1 Introduction

21

SOFTWARE DEVELOPMENT METHOD3. Design – Develop an algorithm

Algorithm a list of steps, that when followed will solve the problem.Specifies actions & sequence (one after another).Usual Technique: Divide and Conquer

Breaks a large problem into many smaller ones. Also called algorithm refinement.

-----------------------------------------------------STEP 1: List major tasks and refine

then, in successive steps, define the subtasks,then define subtasks under the subtasks,

…Tasks are expressed as descriptive English statements.

http://mathcs.holycross.edu/~croyden/csci150spr03/notes/lec15_divideConquer.gif

Page 22: OOP 1 Introduction

22

3. Design continuedSimple programs follow this generic pattern:Major Task Identification

1.0 Get the data2.0 Perform the computation(s)

(Processing)3.0 Display the results

Now refine; use indentation for subtasks:1.0 Get the data

1.1 Prompt for the data1.2 Get the data

……..http://faculty.frostburg.edu/cosc/htracy/UML/IPO_flowchart.gif

SOFTWARE DEVELOPMENT METHOD

Subtasks

Page 23: OOP 1 Introduction

23

3. Design continuedStep 1: Major task, subtask identificationSTEP 2: Convert tasks into the algorithm

Algorithm: A series of instructions, which if performed in order, will solve a problem.

An algorithm must: 1. terminate,

2. be precisely defined (no ambiguity),3. effectively solves the problem.

Write the algorithm using pseudocode, using informal English-like statements.

Each line of the algorithm will be converted into the chosen implementation (high-level) language – most of the time.

SOFTWARE DEVELOPMENT METHOD

Page 24: OOP 1 Introduction

24

3. Design continuedSTEP 1: Major task, subtask identification

STEP 2: Convert tasks into the algorithm

DO NOT USEDO NOT USE programming language syntaxDO USEDO USE variable names as an abstraction of memory locations.

Variable: a named data element in a program.The compiler will associate a relative memory location

with the name.

Variables have values that change over time.

Walk through the algorithm to simulate execution.- Create a Trace Table to show how the values

of data elements will change during execution.- Show the Expected Output

SOFTWARE DEVELOPMENT METHOD

Page 25: OOP 1 Introduction

25

3. Design continuedSTEP 1: Major task, subtask identification

STEP 2: Convert tasks into the algorithm

Examples of Good Pseudocode Statements:Examples of Good Pseudocode Statements: GOODGOOD: : Display “Enter Weight (lbs)”Display “Enter Weight (lbs)” PatientWeight

GOODGOOD:: Set SumScores to sum of Test1 and Test2 and Test3

GOODGOOD:: Display “Sum of Test Scores:” SumScores

BAD:BAD: Add all the test scores.

BAD: BAD: Print all of the test scores

Use the following English commands:

To Get Data: “input”, “read”, “get from keyboard, “get”

To Output Data: “display”, “print”, “put on monitor”, “put”

To Calculate: “calculate”, “set”, “determine”, “compute”

SOFTWARE DEVELOPMENT METHOD

Prints contents of memory location

called “SumScores”

Page 26: OOP 1 Introduction

26

Where are we?

1. Specify the problem requirements

2. Analyze the problem3. Design the algorithm

Major task / Subtask Identification & Algorithm Design

4. Coding5. Testing and verification

6. Maintenance

SOFTWARE DEVELOPMENT METHOD

Page 27: OOP 1 Introduction

27

4. Coding (Implement the Algorithm more on this later…)

Step 1: Choose the C++ data types based on the internal storage representation and the max and min values of the data

Is it an Integer? Real? or Character? Step 2: Convert the algorithm to C++ code.

Write out the C++ code by hand!Step 3: Compile the program

Create your source file, compile, execute.Debug the code: locate and correct errors. Code (a little at a time),

Compile, and Debug in increments.

SOFTWARE DEVELOPMENT METHOD

Page 28: OOP 1 Introduction

28

5. Testing and VerificationVerification: Is the output correct? Are the results what they should be? Have I done it “right”?

Output here should match Design Output.http://www.first-to-fly.com/Adventure%20Images/1901%20Glider%20Replica/Testing%20pitch.jpg

5. Testing and VerificationVerification: Is the output correct? Are the results what they should be? Have I done it “right”?

Output here should match Design Output.http://www.first-to-fly.com/Adventure%20Images/1901%20Glider%20Replica/Testing%20pitch.jpg

SOFTWARE DEVELOPMENT METHOD

Validation: Have I done the “right thing”? Does the solution meet the client’s expectation? Have the requirements been met?

Validation: Have I done the “right thing”? Does the solution meet the client’s expectation? Have the requirements been met?

Page 29: OOP 1 Introduction

29

6. MaintenanceFix Problems: Logic errors

Make improvements,Upgrade or replace equipment

(tech change),Most expen$ive part of Software,

Legacy code: old code that has had many changes and revisions.

Especially difficult to follow.http://www.deerparkmanagement.com/images/maintenance.jpg

SOFTWARE DEVELOPMENT METHOD

Page 30: OOP 1 Introduction

30

6. Maintenance continued

ALWAYS CONSIDER MAINTENANCEALWAYS CONSIDER MAINTENANCE,especially in design and coding steps.

The following contribute to low maintenance:Reusability of code,Good documentation,Structured programming,“Kiss” method.

SOFTWARE DEVELOPMENT METHOD

Page 31: OOP 1 Introduction

31

1. Specify the problem requirements

2. Analyze the problem

3. Design the algorithm

4. Coding

5. Testing and verification

6. Maintenance

End Software Development Method

SOFTWARE DEVELOPMENT METHOD

Page 32: OOP 1 Introduction

SOFTWARE ENGINEERING AND THE WATERFALL METHODOLOGY

Page 33: OOP 1 Introduction

SOFTWARE ENGINEERING AND THE WATERFALL METHODOLOGY

How you would eat this elephant?

would you prefer to open wide and swallow the beast whole or to eat a

manageable portion, have a rest, eat another portion, have a rest, and so on?

Page 34: OOP 1 Introduction

New Methodologies

● We need to accept that it is impossible to develop a piece of software in one pass

● However hard we try, the first time around our software will be incomplete or imperfect or both

● We need to perform the classical phases of software development several times, adding to and perfecting the system as we go.

Page 35: OOP 1 Introduction

Spiral Methodology

Page 36: OOP 1 Introduction

Iterative Methodology

Page 37: OOP 1 Introduction

Incremental Methodology

Page 38: OOP 1 Introduction

Combining the Methodologies

● At the highest level, we know from the incremental methodology that we must plan a succession of increments.

● Within each increment, the spiral methodology suggests that we should have at least two attempts to produce each increment.

● Within each spiral, the waterfall methodology specifies the phases and the order in which they occur.

● Within each mini-waterfall, the iterative methodology allows us to repeat phases, or combinations of phases, as we see fit (for example, several cycles of requirements and analysis); the iterative methodology also allows us to fix a problem as soon as we discover it (for example, we might discover during subsystem design that the system design makes some piece of functionality impossible, so we fix the system design before we carry on).

Page 39: OOP 1 Introduction

Combining the Methodologies

Page 40: OOP 1 Introduction

OBJECT-ORIENTED METHODOLOGIES

● Object-oriented methodologies tend not to be too prescriptive: – the developers are given some choice about

whether they use a particular type of diagram, for example

● Development team must select a methodology and agree which artifacts are to be produced, before they do any detailed planning or scheduling.

Page 41: OOP 1 Introduction

Each methodology addresses:

● Static modeling involves deciding what the logical or physical parts of the system should be and how they should be connected together.

– static modeling describes how we construct and initialize the system

● Dynamic modeling is about deciding how the static parts should collaborate.

– dynamic modeling describes how the system should behave when it’s running

Page 42: OOP 1 Introduction

The Need for Development Tools

● To be effective, any spiral, iterative and incremental methodology requires an end-to-end development tool.

● The need to amend project artifacts iteratively is a strong justification for the use of a software tool.

● Such a tool should allow members of the project team to produce the artifacts and then to store them.

Page 43: OOP 1 Introduction

Development Tools should support :

● Traceability● Change history● Multiuser access control● Reduced redundancy● Consistency checking● Networked operation● Testing the artifacts that we produce, as we go

along

Page 44: OOP 1 Introduction

Development Tools

● Rational Corporation developed a tool called Rose, based on RUP and UML. Rose became probably the best-known object-oriented development tool.

● In 2003, Rational was bought by IBM and the tool has been reworked as a set of modular products (and is now called Rational Application Developer).

● Of course, there are many development tools available – Rational products are only mentioned here because of the historical perspective.