Based-on slide Ivan Marsic

(1)

Mohammad Iqbal

Untuk SISTEM KOMPUTER

Kuliah 4: Memahami Masalah dan

Membagi Pekerjaan

(2)

2

Topik



Dekomposisi : Partitioning vs. Projection



Divisi pekerja



Mengurangi komunikasi intra-team

(3)

3

Mengapa Harus membagi

Problem/Proyek



“…main value [of social skills] lies in the relationship

between colleagues:

people who can divide up tasks

quickly and effectively between them form more

productive teams

.”—

David Deming (Harvard U. & NBER)



Strategi umum

problem-solving

:

“divide

-and-

conquer”



Divisi pekerja pada tim developer



Mendukung fleksibilitas dan evolusi masa datang

dengan memisah-kan bagian yang tidak berhubungan,

sehingga dapat diselesaikan secara individual

(“Pemisahan konsentrasi pekerjaan”)

(4)

(5)

Bagaimana Pemula membagi

Pekerjaannya



List the

components

of the system-to-be



Each sub-group of one or more team members

is assigned a different component to develop

–

One or more team members is assigned to

“write documentation”



“Chain” organization—

every link is critical

If any link fails, the whole project fails

–

Separation of concerns is impossible

5

User Interface _{Business Logic}

and Algorithms

Database/

(6)

6

Dekomposisi:

Projection vs. Partitioning

Projection:

:Partitioning

(7)

Contoh : Otomatisasi Dekomposisi

Restoran dengan Teknik

Partitioning

7

User Interface Business Logic

and Algorithms

Database/

Network Documentation

Developer Team α Developer Team Φ

(8)

Contoh : Otomatisasi

Restoran

Beban Komunikasi

8

User Interface Business Logic

and Algorithms

Database/

Network Documentation

Interface for

what functions?

What to write about? Function-1:

description Function-2: description …

Tables for

(9)

Contoh : Otomatisasi

Restoran

Kekurangan Pendekatan

Team

α



Communication overhead:

– Most time spent in communication and “documentation

writing”

–

No time for creative software development



Failure-prone:

–

If any sub-

group doesn’t deliver, the whole project fails



Each student learns only one aspect of

software development



Ownership fuzzy or one “leader”

claims all the credit

I did all coding!

(10)

Contoh :

Otomatisasi Dekomposisi

Projection



Different way of

“slicing” the project:

– Instead of horizontal slicing, we have vertical slicing—”stacks”



Each “stack” can be

done independently of

other stacks,

as a mini-project



Separation of concerns!

10

Subgroup

Φ-RED

Subgroup

Φ-GREEN

Subgroup

Φ-BLUE

(11)

Contoh :

Otomatisasi Dekomposisi

Projection

 Team communication is

simple:

 They only need to define

shared interfaces (“APIs”) and can focus on creative software development

 What is inside of each

“stack” is not discussed

with other sub-teams

—for others, the contents

of your “stack” is hidden—

they see a black box with defined interface / APIs

(“information hiding”) ₁₁

Subgroup

Φ-RED

Subgroup

Φ-GREEN

Subgroup

Φ-BLUE

Shared Infrastructure Customer-related functions Kitchen-related functions Management-related functions

(12)

Contoh :

Otomatisasi Restoran

Kelebihan Pendekatan Team

Φ

 Increased productivity:

Minimizes the amount of communication needed to coordinate the work

–  more time to focus on creative software development

 Failure resilience:

Reduces the dependency on other team members—if they fail to deliver,

you can still succeed and demonstrate your mini-project

(Unlike chain-organization, where a link failure leads to project failure,

each “stack” can succeed independently of others)

 Each student learns all aspects of software development

 Ownership visibility:

Each mini-project can be demonstrated alone

(If expert-based, who demonstrates UI, or dBase, or …?)

 Customer friendly:

The customer (or class instructor) knows whom to talk about every aspect of a given functional feature

 Requirements traceability, from inception to implementation

(13)

Apakah

“Shared Infrastructure”?



Needs to be discovered, as we will learn in

subsequent lectures



May be a relational database, so whole team

needs to discuss together the design of the

shared tables



May be data items communicated via messages



May be “services” accessed by method calls

(14)

Membagi Pekerjaan dengan Problem

atau dengan Solusi

 By problem: Different team members responsible to solve different sub-problems or develop different “features” of the system

– Suitable for any level of expertise, particularly if uncertain about other team members’ skills and ability to deliver on time ( highly recommended for novices/students)

– Advantage: dependency on other team members is reduced—the development of different features can progress independently, at their own pace

– Drawback: Potential redundancies because different teammates may need to develop same/similar parts to make their “feature” work independently of others

 By solution: Different team members responsible for different parts of the system

– Advantage: everyone can focus on one area of expertise

– Drawbacks:

• Developers need to know a lot about the solution (i.e., parts of the “system” and their relationships) before detailed analysis of the sub-problems.

• If solution parts are not precisely specified, there will be a great uncertainty about interfacing the parts and integrating into the whole system.

– Suitable for highly-experienced specialists, not for beginners (i.e., not for students), working on a familiar problem

– Always watch for fallback solutions in case some parts are not ready on time or problematic

– Right now, you have no “area of expertise”—otherwise you wouldn’t be a student in this class!

(15)

Contoh Yang Berlawanan



Car subsystems -- different companies

produce different subsystems!



Why cannot we do the same?!



… but, you are not at this level of

(16)

Tanggapan Pada Contoh Yang

Berlawanan (1)



Actually, you are at this level of understanding

(17)

Tanggapan Pada Contoh Yang

Berlawanan (2)

Before we could do this…

…there was a lot of trial

-and-error

and each subsystem

evolved independently

to solve a different sub-problem

(18)

18

Dekomposisi Problem

(19)

Dekomposisi Problem



We assume that the computer/software helps the user

to achieve a business goal in the problem domain



Problem domains can be virtual (e.g., text documents,

relational databases), or physical world (a device to

control, a person to notify and prompt to action)



Problem types:

1. Transforming one virtual object to another (document format

conversion, e.g., from MS Word to PDF)

2. Modifying a virtual object (e.g., document editing)

3. Automatically controlling behavior of a physical object (e.g.,

thermostat)

4. Manually controlling behavior of a physical object (e.g., drone

flying)

5. Observing behavior of a physical object (e.g., traffic monitoring)

(20)

Kebutuhan Sistem Umum



REQ-1

: Map input data to output data as said by

given rules



REQ-2

: Allow repository (or

document

) editing,

where “repository” is a collection of data



REQ-3

: Automatically control a physical

object/device



REQ-4

: Interactively control a physical

object/device



REQ-5

: Monitor and display information about an

object



Only a “5

-

dimensional” problem space!

(Problem complexity can vary independently along each dimension)

Note:

(21)

21

Problem Umum Software Eng.

1. User works with computer system

(problem domain is “virtual”, not physical)

2. Computer system controls the (physical) problem domain (user not involved)

3. Computer system intermediates between the user and the problem domain

User System

System Problem domain

User System Problem domain

User

System

Repository

User System Problem domain

User System Problem domain System

IN doc OUT doc

1.a) System transforms input document to output document

1.b) User edits information stored in a repository

3.a) System observes the problem domain and displays information

3.b) System controls the problem domain as commanded by the user REQ-1: Map input data to output

data as said by given rules

REQ-2: Allow repository editing, where

“repository” is a collection of data

REQ-3: Automatically control a physical object/device

REQ-5: Monitor and display information about an object

(22)

Contoh : Dekomposisi Problem

•

REQ1: keep door locked and auto-lock

• REQ2: lock when “LOCK” pressed

•

REQ3: unlock when valid key provided

•

REQ4: allow mistakes but prevent dictionary attacks

•

REQ5: maintain a history log

•

REQ6: adding/removing users at runtime

•

REQ7: configuring device activation preferences

•

REQ8: inspecting the access history

•

REQ9: filing inquiries

Required Behavior

Commanded Behavior

Information Display (database is the “display”)

Simple Editing

Information Display

Simple Editing

(23)

Contoh : Dekomposisi Problem

• REQ1: view market prices and volumes

– Domains: exchange, display

• REQ2: place a trade

– Domains: investor, tradable-securities, pending-trades

• REQ3: execute trades when conditions matched

– Domains: exchange, pending-trades

• REQ4: generate periodic report

– Domains: portfolio, report

• REQ5: generate leaderboard

– Domains: all-portfolios, leaderboard

• REQ6: view leaderboard

– Domains: leaderboard, display

• REQ7: start a trading group/clique

– Domains: investor, group

• REQ8: invite to a trading group/clique

– Domains: investor, friends, group