Desain Sistem Embedded Terdistribusi - .: Eko Didik Widianto...

Desain SistemEmbeddedTerdistribusi

@2012,Eko DidikWidianto

Mesin Penjual /Vending Machine

Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Desain Sistem Embedded TerdistribusiKuliah#6 TSK-612 Sistem Embedded Terdistribusi - TA

2011/2012

Eko Didik Widianto

Teknik Sistem Komputer - Universitas Diponegoro




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Review Kuliah 4-5

I Yang telah dibahas di kuliah sebelumnya:I Pemodelan sistem embedded terdistribusi menggunakan

UMLI Keterkaitan antara UML dengan metodologi desain yang

diambilI Tipe diagram UML:

I Struktur: component diagram, deployment diagram,class diagram

I Perilaku: use-case diagram, activity diagram, statediagram

I Prinsip kerja sistem elevator: prinsip dasar, profil danunjuk kerja, arsitektur kontrol, sistem keselamatan,antarmuka pengguna dan pertimbangan desain

I Implementasi UML untuk desain sistem elevator

Tentang Kuliah #6Pokok Bahasan Kuliah #6

I Mendesain sistem embedded terdistribusi, mulaidari requirement sampai pengujian sistem

I Kasus: mesin penjual snack/soda(automated retail kiosk)

I Kompetensi dasar:I [C2] Mahasiswa akan mampu menjelaskan

metodologi desain sistem embeddedterdistribusi

I [C3] Mahasiswa akan mampu menjabarkanrequirement ke dalam diagram UML

I [C3] Mahasiswa akan mampumengimplementasikan rancangan kehardware dan software

I [C6] Mahasiswa akan mampu menguji danmenganalisis modul dan sistem secarakeseluruhan




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Resources

I LinkI Website: http://didik.blog.undip.ac.id/2012/03/06/

kuliah-tsk-612-sistem-embedded-terdistribusi-2011/I Email: [email protected]

I Acknowledgement:I Beberapa gambar yang ada di slide ini diambil dari

http://www.ece.cmu.edu/~ece649/[ECE649]I Wikipedia: http://en.wikipedia.org/wiki/Vending_machine

http://didik.blog.undip.ac.id/2012/03/06/kuliah-tsk-612-sistem-embedded-terdistribusi-2011/

http://didik.blog.undip.ac.id/2012/03/06/kuliah-tsk-612-sistem-embedded-terdistribusi-2011/

mailto:[email protected]

http://www.ece.cmu.edu/~ece649/

http://en.wikipedia.org/wiki/Vending_machine




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Bahasan

Mesin Penjual / Vending Machine

Kebutuhan SistemKebutuhan UmumPengembangan RequirementTraceability UML - Text Requirement

Arsitektur SistemDiagram Kelas

Kebutuhan SoftwareObjek KontrolSkenario dan Diagram Urutan

Perancangan SistemRancangan SistemMapping Diagram Urutan ke Perilaku SistemDesain Statechart

Desain Pengujian

Review dan Lisensi




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Sistem Vending MachineIt Will Give Which You Want

Full line of vending machine

Ticket machines: touch-screen,button

DVD vending machine

Nnewspaper vending machine




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Sistem Vending MachineVending is a multi-billion dollar industry

I PaymentI CoinI Credit Card

Apriva: 57 percent of companiessurveyed said they planned toexpand the number of theirmachines outfitted with card swipers

I Premium SMS (Vendtxt Vending Inc)I User interaction

I buttonI touchscreenI computer vision (touchless)

I Intuisense: custom built CPU,MDB monitor, and the ISGesture Recognition system

I Product delivery after paymentI release product, unlocking door,

rotate & release

Vendtxt Vending Inc. Machine

Rice vending machines

Library-A-Go-Go library book




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

State Diagram Pembayaran

https://sites.google.com/site/zhongrenshomepage/course-projects/vending-machine-

simulator




Kebutuhan SistemKebutuhan Umum

PengembanganRequirement

Traceability UML - TextRequirement

Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

BahasanMesin Penjual / Vending Machine





Desain Pengujian

Review dan Lisensi







Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Top Level Requirement Soda VendingMachine

I Make it work like a real vending machineI Simplification:

I Sodas cost some number of quartersI All other coins are rejected (invisible to your control system)

I Assume a Distributed System per given class diagramI Processor for each button, coin return controller, vending

controller

See:http://www.ece.cmu.edu/~ece649/project/sodamachine/portfolio/reqs/requirements1.html







Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Metodologi DesainHybrid UML + Text

I System-level requirementsI Use casesI High-level text requirements

I Architecture – emphasis on “nouns”I Class DiagramsI Define network variables that define architectural interfaces

(message dictionary)I Sensors, actuators, software objects

I Software Requirements – emphasis on “verbs”I Text-Based Scenarios – different scenarios for each use caseI Sequence Diagrams – graphical scenarios with emphasis on

interaction “messages”I Design

I Textual software requirements specification – per-module behaviorsI State Charts – state transitionsI Test Design

I ImplementationI Write the codeI Module testing

I IntegrationI Integration test; Acceptance test







Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Traceability

I Traceability is checking to ensure that steps ofthe process fit together

I Forward Traceability: Next step inprocess has everything in current step,“Nothing got left out”

I Backward Traceability: Previous step inprocess provoked everything in currentstep, “Nothing spurious included”

I Using traceability matrices to trace:System req., behavioral req.,implementations, integration testsSystem req., acceptance testsUsing spreadsheet







Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi






Desain Pengujian

Review dan Lisensi







Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Diagram Use Case untuk DeskripsiKebutuhan







Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Use Case untuk Sistem EmbeddedTerdistribusi







Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Use Case untuk Mesin Penjual Soda







Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

System-Level Text RequirementI Goal: implement a soda vending machine

R1 Pushing a button shall vend a soda of the typecorresponding to that button.

R2 The machine shall permanently retain exactlySODACOST coins for each can of soda vended

R3 Coin return shall return all deposited coins sincethe last vend cycle

R4 The machine shall return all deposited money inexcess of SODACOST coins before a vend cycle

R5 The machine shall flash the light for a selecteditem while vending is in progress to indicateacceptance of a selection to the buyer

R6 The machine shall illuminate the light for anyout-of-stock item

I Assume a Fully Distributed SystemI Processor for each button, coin return controller, vending

controller







Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi






Desain Pengujian

Review dan Lisensi







Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Traceability: UML dan Text Requirement

I Put an “X” in every box with a related Use Case andRequirements







Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Catatan Traceability dari UML keRequirement

I Lack of backward traceability for R2 : “The machine shallpermanently retain exactly SODACOST coins for each canof soda vended”

I There is a missing actor on the Use Case diagram – thesoda delivery person

I Could add “U5. Collect Money”I Possibly add “U6. Refill Machine”

I Requirements must address off-nominal behaviors(exceptional and failure situations)

I U1 – too many quarters insertedI U2 – soda button pressed without a quarterI U2 – two soda buttons pressed concurrentlyI U3 – coin return pressed with no money inserted

I UML gradually eases from requirements to designI Details of the use case become apparent as requirements

are elaboratedI Scenarios and sequence diagrams are partway between

requirements and design







Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Revisi Diagram Use Case







Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Revisi Traceability

I Put an “X” in every box with a related Use Case andRequirements




Kebutuhan Sistem


Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi






Desain Pengujian

Review dan Lisensi




Kebutuhan Sistem


Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Arsitektur Mesin Penjual SodaI Modelled using UML Class DiagramI Used to show system in terms of objects, attributes, and

relationshipsI Objects are “nouns” in the system; Attributes are local state

data within objectsI Implicit, trivial controllers are assumed built in to

uncontrolled componentsI This is a simplified class diagram – VendMotor and

VendPosition not there

I Classes: with association and aggregation/compositionrelationship

I Soda Vending MachineI Coin_in SensorI Coin Return SwitchI Empty Soda SensorI Button Control

- Button: Button Sensor, Button LightI CoinOut Control

- Coin Change dispenserI Vend Control

- Soda Dispenser

Diagram Kelas

Diagram Arsitektur Mesin Penjual Soda




Kebutuhan Sistem


Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Sensor Sistem

I Button[s](v): Soda selection button – Physical state sensorI v={True, False}.I One button per type of soda. All are False at initialization. S is an

integer 1..8I Button[s](True) is sent when button s is depressed; Button[s](False)

is sent when button s is released.I The button sensors have a physical interlock that prevents more

than one being pressed at a time.I Empty[s](v): Item empty sensor – Smart Sensor

I v={True, False}.I One empty sensor per type of soda vended. True when out of

stock. S is an integer [1]..[8]I One per type of soda. Initialized to be FalseI This is a smart sensor, so its implicit function is: transmit

mEmpty[s](v) = Empty[s](v)(i.e., broadcast state to rest of system)




Kebutuhan Sistem


Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Environment-Only System State

I SodaCount[s](n): The number of sodas in each chuteI Each count is set to 50 at startup

I What does “environment-only” mean?I The entire system

I Computing nodesI NetworkI Sensors & actuatorsI Physical world

I The physical world model keeps track of how many sodas are in achute

I The embedded computers do not know how many sodas are in thechute

I They only can infer it from sensors and build a model of thephysical world

I In this system, they only know if a chute is empty or not emptyI In some other, fancier system the delivery person might

program in number and the controllers could keep count – butthey still wouldn’t “know” the actual value of SodaCount – theywould be inferring it from external information




Kebutuhan Sistem


Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Aktuator Sistem

I ButtonLight[s](v): Soda selection light.I v={True, False}.I One per type of soda. When set to

True turns on the light in the buttonfor soda s; when set to False turnsthat light off. S is an integer 1..8

I All lights set to False at initialization.I Note: soda refill & money collection is

done manuallyI Note – there are more sensors and

actuatorsI CoinOut(v), Vend(v), VendMotor(d)




Kebutuhan Sistem


Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Objek Kontrol Software

I ButtonControl[s]I One per soda selection (S is an

integer [1]..[8])I Controls button lightsI Controls sending button selections to

VendControlI CoinControl

I Controls coin return dispenserI VendControl

I Controls dispensing the soda cansI VendPositionControl

I Controls the movement of the VCI A mechanical device that moves

across chutes to select a soda




Kebutuhan Sistem


Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Message Dictionary

I Notation:I s is button index number: s=1..8

I Environmental Object MessagesI This message are sent by environment objects and smart

sensors provided in the system

Source NodeName

Message Name Replication Number offields

Empty mEmpty s 1

Coin_Return mCoinReturn none 1

VendPosition mVendPosition s 1




Kebutuhan Sistem


Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Message Dictionary

I Controller MessagesI These messages are sent by the controllers

Source NodeName

MessageName

Replication Numberof fields

Description

ButtonControl mButton s 1 State of thesoda selectionbutton

VendControl mVend none 1 True whenvending a soda

CoinControl mCoinCount none 1 Integer numberof coinsreceived

VendPositionControl

mVendMotor none 1 State of thevend motor

I See:http://www.ece.cmu.edu/~ece649/project/sodamachine/portfolio/reqs/requirements1.html




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan SoftwareObjek Kontrol

Skenario dan DiagramUrutan

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Kebutuhan Software

I Emphasis on “verbs”: Structured representation of control objectsI ButtonControl[s]I CoinControlI VendControlI VendPositionControl

I Text-Based Scenarios – different scenarios for each use caseI Sequence Diagrams – graphical scenarios with emphasis on interaction

“messages”




Kebutuhan Sistem

Arsitektur Sistem



Perancangan Sistem

Desain Pengujian

Review dan Lisensi






Desain Pengujian

Review dan Lisensi




Kebutuhan Sistem

Arsitektur Sistem



Perancangan Sistem

Desain Pengujian

Review dan Lisensi

2. Objek ButtonControlI Replication:

I There is one button controller per Button/Button_Light pair(8 total).

I Instantiation:I ButtonControl[s] commands Button_Light[s] to False at

initialization.

I Assumptions:I Only one Button[s] is sent as True at a time to VendControl.I Each ButtonControl[s] has a physical interface to exactly

one Button[s] and ButtonLight[s].

I Input Interface:I Button[s](v)I mEmpty[s](v)I mVend[s](v) (assume that any Vend message received

indicates an actual vend event)

I Output Interface:I mButton[s](v)I ButtonLight[s](v)




Kebutuhan Sistem

Arsitektur Sistem



Perancangan Sistem

Desain Pengujian

Review dan Lisensi

2. Objek ButtonControl

I Constants:I FlashLimit (integer): determines the rate that the light

flashes during vend.

I State:I IsEmpty (True, False); initialized to False; indicates when

selection has no soda cans left.I ButtonState (True, False); initialized to False; indicates

whether the button has been pressed.I FlashCounter: used to keep track of time while flashing the

light druing Vend

I Constraints:I None

Skenario




Kebutuhan Sistem

Arsitektur Sistem



Perancangan Sistem

Desain Pengujian

Review dan Lisensi






Desain Pengujian

Review dan Lisensi




Kebutuhan Sistem

Arsitektur Sistem



Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Use Case 2: Customer Pushes a SodaButton

I See:http://www.ece.cmu.edu/~ece649/project/sodamachine/portfolio/scen_sd/scen_sd.html

I Scenario 2A: Customer pushes a soda button whenthe correct amount has been paid

I Pre-Conditions:I The soda machine is not vending.I No button is pressed.I The system has received the correct number of coins for the

cost of a soda since the last vend cycle.I The VendCarriage is parked in front of chute r, r < s.

I Scenario:1. The Customer pushes soda button s.2. The light on the soda button s begins flashing.3. The VendPositionControl aligns with soda chute s.4. The soda is vended.5. The light on the soda button s stops flashing.

I Post-Conditions:I The system retains the cost of the soda and has one less

soda of type sI The system is out of soda of type s

Diagram Urutan (Sequence Diagram)I See:

http://www.ece.cmu.edu/~ece649/project/sodamachine/portfolio/scen_sd/scen_sd.html#usecase2




Kebutuhan Sistem

Arsitektur Sistem



Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Kelemahan dan Kekurangan DiagramSebelumnya

I Pro: Everything is thereI You can see all the components of the system interacting

I Con: It is complexI If it is difficult to show in powerpoint, it is difficult to

understand (the “Powerpoint Engineering” principle)I It is a very specific case (e.g., what if it wasn’t the last

soda?)

I Possible ways to improveI Break it up vertically into multiple stepsI Break it up vertically by not showing every piece interactingI There is no perfect, “best” way to do this – these are just

ideas




Kebutuhan Sistem

Arsitektur Sistem



Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Kompleksitas Sequence Diagram

I Most Use Cases have more than one scenario for useI And therefore more than one sequence diagramI Keep making scenarios until you cover all the functions that matter

I There is no single right way to do itI But in general, simpler and fewer scenarios are better than

many complex ones




Kebutuhan Sistem

Arsitektur Sistem



Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Sequence Diagram Traceability

I Sequence Diagrams to Use CasesI Is there at least one sequence diagram for each Use Case number?I If so, you’ve satisfied traceability

I Sequence Diagrams to objectsI Are all objects in at least one sequence diagram?

I Sequence Diagrams to messagesI Are all messages in at least one sequence diagram?

I Traceability doesn’t prove you have everything; but it helps youavoid mistake gaps

I For example: if there were no scenario 4A (soda is available), thenUse Case 4 (Customer observes soda availability) isn’t covered




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software

Perancangan SistemRancangan Sistem

Mapping Diagram Urutan kePerilaku Sistem

Desain Statechart

Desain Pengujian

Review dan Lisensi






Desain Pengujian

Review dan Lisensi




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software



Desain Statechart

Desain Pengujian

Review dan Lisensi

Tahapan yang Dilakukan

1. Write down constraints & behaviorsI Constraints are assumptions that other components can

makeI Behaviors are functions designed in to the component

2. Synthesize a statechartI Transitions have to account for all behavior triggersI Transitions have to account for all behaviors

(alternately, states could account for all behaviors; dependson approach)




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software



Desain Statechart

Desain Pengujian

Review dan Lisensi

Formula untuk Sistem Event-Driven




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software



Desain Statechart

Desain Pengujian

Review dan Lisensi






Desain Pengujian

Review dan Lisensi




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software



Desain Statechart

Desain Pengujian

Review dan Lisensi

Diagram Urutan ke Perilaku Sistem




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software



Desain Statechart

Desain Pengujian

Review dan Lisensi

Kebutuhan Event-Triggered: Button Control[s]I ER2.1. If mEmpty[s] is received as v, then IsEmpty shall be set to v.I ER2.2. If mEmpty[s] is received True and ButtonState <- False, then

I ER2.2a. ButtonLight[s](v) shall be commanded to False.I ER2.2b. mButton[s] shall be set to False.

I ER2.3. If mEmpty[s] is received False and ButtonState <- False, thenI ER2.3a. ButtonLight[s](v) shall be commanded to True.I ER2.3b. mButton[s] shall be set to False.

I ER 2.4. If Button[s] is received True and IsEmpty is False, thenI ER2.4a. ButtonState shall be set to True.I ER2.4b. ButtonLight[s] shall be commanded to blink with a period

of 0.25s.I ER2.4c. mButton[s] shall be set to True.

I ER 2.5. If mVend[s] is received True and IsEmpty is False, ButtonLightshall be commanded to True.

I ER 2.6. If mVend[s] is received True and IsEmpty is True, ButtonLightshall be commanded to False.

I ER 2.7. If mVend[s] is received True, thenI ER 2.7a mButton[s] shall be set to False.I ER 2.7b ButtonState shall be set to False.




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software



Desain Statechart

Desain Pengujian

Review dan Lisensi






Desain Pengujian

Review dan Lisensi




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software



Desain Statechart

Desain Pengujian

Review dan Lisensi

Desain Statechart

I Design Statecharts for each software objectI Design states for each objectI Behavior requirements become conditions for state

transitionsI Cover every behavior requirement in state chart

I TraceabilityI Every behavior requirement should map to a state transition

arc




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software



Desain Statechart

Desain Pengujian

Review dan Lisensi

Perilaku Time-Triggered

I R2.1. mButtonState[s] shall be set to the current value of ButtonState.I R2.2. If ButtonState is equal to False AND mEmpty[s] is equal to True,

then ButtonLight[s] shall be commanded to False.I R2.3. If ButtonState is equal to False AND mEmpty[s] is equal to False,

then ButtonLight[s] shall be commanded to True.I R2.4. If Button[s] is equal to True AND mEmpty[s] is equal to False and

mCoinCount is equal to SODA_COST and mVend is equal to False, thenI R2.4a. ButtonState shall be set to True.I R2.4b. ButtonLight[s] shall be commanded to blink with a period of

1s.I R2.5. If mVend[s] is equal to True then ButtonState shall be set to False.




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software



Desain Statechart

Desain Pengujian

Review dan Lisensi

ButtonControl Time Triggered Statechart




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software



Desain Statechart

Desain Pengujian

Review dan Lisensi

Event Triggered vs. Time Triggered?

I Event triggeredI Exactly one message on left hand side of “shall”

I Ex: ER2.1. If mEmpty[s] is received as v, then IsEmpty shallbe set to v.

I Each message arrival is an “event” which triggers astatechart transition

I Networks deliver only one message at a timeI “Asynchronous state machines” from hardware design

I Time triggeredI Arriving message values put into memory buffersI State chart transitions based on most recent message valueI “Synchronous state machines” from hardware design




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software



Desain Statechart

Desain Pengujian

Review dan Lisensi

Traceablilty Desain

I Does everyrequirement map toat least one state ortransition?

I Does every state ortransition map to atleast onerequirement?




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software



Desain Statechart

Desain Pengujian

Review dan Lisensi

(Implementation) CoinOutControl Code




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Desain Pengujian

I Suggestion: design tests before actual implementationI May uncover errors in your design before coding

I Test at least two levels before you run a full simulationI Unit/module testsI System integration tests

I Unit TestsI Design tests to cover every state transition in every state chartI Make sure erroneous state transitions aren’t takenI Cover every possible message/event received by each object

I TraceabilityI Document traceability between tests and state transitions for unit

testsI System Integration Tests

I Test specified operation sequences / UML scenarios




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Unit Test




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Pengujian Terintegrasi




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Acceptance Test

I Ensure system as a whole actually meets requirementsI In simple systems, testing all scenarios sufficesI In real systems, need to test sequences of Use Cases

I First define meaningful sequences of use casesI Example: insert coin, push soda buttonI Example: insert coin, push coin return, push soda button

I Next, execute tests and compare results to systemrequirements

I Generate many simulated customers and see what happensI Were each of R1 - R6 met during the course of each test?

I Additional test strategies:I Design tests to attempt requirement failureI Reset system partway through a scenario or between use

casesI ...




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Simulasi

I vmcsrepo: Vending Machine Simulator Project usingJavaSE and OOAD

I http://code.google.com/p/vmcsrepo/




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

ReviewI Requirements

I Use cases (which are exemplary, but not necessarilycoherent/definitive)

I System-level text requirementsI Architecture

I Class Diagrams – model “nouns” in system as classes &“architecture diagram”

I Define network variables that define architectural interfaces(message dictionary)

I Sensors, actuators, software objectsI Software Requirements

I Scenarios – details inside use casesI Sequence Diagrams

I DesignI Detailed text behavioral requirementsI State Charts (state transitions)I Test Design

I ImplementationI Write the codeI Module testing (unit tests)

I IntegrationI Integration tests; acceptance tests




Kebutuhan Sistem

Arsitektur Sistem

Kebutuhan Software

Perancangan Sistem

Desain Pengujian

Review dan Lisensi

Lisensi

Creative Common Attribution-ShareAlike 3.0 Unported (CCBY-SA 3.0)

I Anda bebas:I untuk Membagikan — untuk menyalin, mendistribusikan,

dan menyebarkan karya, danI untuk Remix — untuk mengadaptasikan karya

I Di bawah persyaratan berikut:I Atribusi — Anda harus memberikan atribusi karya sesuai

dengan cara-cara yang diminta oleh pembuat karyatersebut atau pihak yang mengeluarkan lisensi.

I Pembagian Serupa — Jika Anda mengubah, menambah,atau membuat karya lain menggunakan karya ini, Andahanya boleh menyebarkan karya tersebut hanya denganlisensi yang sama, serupa, atau kompatibel.

I Lihat: Creative Commons Attribution-ShareAlike 3.0Unported License

http://creativecommons.org/licenses/by-sa/3.0/

http://creativecommons.org/licenses/by-sa/3.0/

Desain Sistem Embedded Terdistribusi - .: Eko Didik Widianto...

Documents

Transcript of Desain Sistem Embedded Terdistribusi - .: Eko Didik Widianto...