2012. Eko Didik Widianto

Desain Sistem Embedded Terdistribusi @2012,Eko Didik Widianto Mesin Penjual / Vending Machine Kebutuhan Sistem

Desain Sistem Embedded Terdistribusi Kuliah#6 TSK-612 Sistem Embedded Terdistribusi - TA 2011/2012

Arsitektur Sistem Kebutuhan Software Perancangan Sistem Desain Pengujian Review dan Lisensi

Eko Didik Widianto Teknik Sistem Komputer - Universitas Diponegoro

Review Kuliah 4-5

Desain Sistem Embedded Terdistribusi @2012,Eko Didik Widianto

I

Yang telah dibahas di kuliah sebelumnya: I

I

I

Pemodelan sistem embedded terdistribusi menggunakan UML Keterkaitan antara UML dengan metodologi desain yang diambil Tipe diagram UML: I

I

Struktur: component diagram, deployment diagram, class diagram Perilaku: use-case diagram, activity diagram, state diagram

I

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

I

Implementasi UML untuk desain sistem elevator

Mesin Penjual / Vending Machine Kebutuhan Sistem Arsitektur Sistem Kebutuhan Software Perancangan Sistem Desain Pengujian Review dan Lisensi

Tentang Kuliah #6 Pokok Bahasan Kuliah #6

I Mendesain sistem embedded terdistribusi, mulai

dari requirement sampai pengujian sistem I

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

I Kompetensi dasar: I

I

I

I

[C2] Mahasiswa akan mampu menjelaskan metodologi desain sistem embedded terdistribusi [C3] Mahasiswa akan mampu menjabarkan requirement ke dalam diagram UML [C3] Mahasiswa akan mampu mengimplementasikan rancangan ke hardware dan software [C6] Mahasiswa akan mampu menguji dan menganalisis modul dan sistem secara keseluruhan

Resources

Desain Sistem Embedded Terdistribusi @2012,Eko Didik Widianto Mesin Penjual / Vending Machine Kebutuhan Sistem Arsitektur Sistem

I Link I

I

Kebutuhan Software

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

Perancangan Sistem

kuliah-tsk-612-sistem-embedded-terdistribusi-2011/

Desain Pengujian

Email: [email protected]

Review dan Lisensi

I Acknowledgement: I

I

Beberapa gambar yang ada di slide ini diambil dari http://www.ece.cmu.edu/~ece649/[ECE649] Wikipedia: http://en.wikipedia.org/wiki/Vending_machine

Bahasan Mesin Penjual / Vending Machine Kebutuhan Sistem Kebutuhan Umum Pengembangan Requirement Traceability UML - Text Requirement

Desain Sistem Embedded Terdistribusi @2012,Eko Didik Widianto Mesin Penjual / Vending Machine Kebutuhan Sistem Arsitektur Sistem Kebutuhan Software Perancangan Sistem

Arsitektur Sistem Diagram Kelas Kebutuhan Software Objek Kontrol Skenario dan Diagram Urutan Perancangan Sistem Rancangan Sistem Mapping Diagram Urutan ke Perilaku Sistem Desain Statechart Desain Pengujian Review dan Lisensi

Desain Pengujian Review dan Lisensi

Desain Sistem Embedded Terdistribusi

Sistem Vending Machine It Will Give Which You Want

@2012,Eko Didik Widianto Mesin Penjual / Vending Machine Kebutuhan Sistem Arsitektur Sistem Kebutuhan Software Perancangan Sistem Desain Pengujian Review dan Lisensi

Full line of vending machine

Ticket machines: touch-screen, button

DVD vending machine

Nnewspaper vending machine


Sistem Vending Machine Vending is a multi-billion dollar industry

@2012,Eko Didik Widianto Mesin Penjual / Vending Machine

I Payment I I

I

Coin Credit Card Apriva: 57 percent of companies surveyed said they planned to expand the number of their machines outfitted with card swipers Premium SMS (Vendtxt Vending Inc)

Kebutuhan Sistem Arsitektur Sistem Kebutuhan Software

Vendtxt Vending Inc. Machine


I User interaction I I I

button touchscreen computer vision (touchless) I

Rice vending machines

Intuisense: custom built CPU, MDB monitor, and the IS Gesture Recognition system

I Product delivery after payment I

release product, unlocking door, rotate & release

Perancangan Sistem

Library-A-Go-Go library book


State Diagram Pembayaran

@2012,Eko Didik Widianto Mesin Penjual / Vending Machine Kebutuhan Sistem Arsitektur Sistem Kebutuhan Software Perancangan Sistem Desain Pengujian Review dan Lisensi

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

Bahasan Mesin Penjual / Vending Machine Kebutuhan Sistem Kebutuhan Umum Pengembangan Requirement Traceability UML - Text Requirement Arsitektur Sistem Diagram Kelas Kebutuhan Software Objek Kontrol Skenario dan Diagram Urutan Perancangan Sistem Rancangan Sistem Mapping Diagram Urutan ke Perilaku Sistem Desain Statechart Desain Pengujian Review dan Lisensi

Desain Sistem Embedded Terdistribusi @2012,Eko Didik Widianto Mesin Penjual / Vending Machine Kebutuhan Sistem Kebutuhan Umum Pengembangan Requirement Traceability UML - Text Requirement


Top Level Requirement Soda Vending Machine

Desain Sistem Embedded Terdistribusi @2012,Eko Didik Widianto Mesin Penjual / Vending Machine Kebutuhan Sistem Kebutuhan Umum

I

Make it work like a real vending machine

I

Simplification: I I

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

Pengembangan Requirement Traceability UML - Text Requirement

Arsitektur Sistem Kebutuhan Software Perancangan Sistem Desain Pengujian

I

Assume a Distributed System per given class diagram I

Review dan Lisensi

Processor for each button, coin return controller, vending controller

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

Metodologi Desain Hybrid UML + Text I System-level requirements I I

Use cases High-level text requirements

I Architecture – emphasis on “nouns” I I

I

Class Diagrams Define network variables that define architectural interfaces (message dictionary) Sensors, actuators, software objects

I Software Requirements – emphasis on “verbs” I I

Text-Based Scenarios – different scenarios for each use case Sequence Diagrams – graphical scenarios with emphasis on interaction “messages”

I Design I I I

Textual software requirements specification – per-module behaviors State Charts – state transitions Test Design

I Implementation I I

Write the code Module testing

I Integration I

Integration test; Acceptance test




Traceability

@2012,Eko Didik Widianto

I Traceability is checking to ensure that steps of

the process fit together I

I

I

Forward Traceability: Next step in process has everything in current step, “Nothing got left out” Backward Traceability: Previous step in process provoked everything in current step, “Nothing spurious included” Using traceability matrices to trace: System req., behavioral req., implementations, integration tests System req., acceptance tests Using spreadsheet

Mesin Penjual / Vending Machine Kebutuhan Sistem Kebutuhan Umum Pengembangan Requirement Traceability UML - Text Requirement





Diagram Use Case untuk Deskripsi Kebutuhan



Use Case untuk Sistem Embedded Terdistribusi



Use Case untuk Mesin Penjual Soda



System-Level Text Requirement I

Goal: implement a soda vending machine R1 Pushing a button shall vend a soda of the type corresponding to that button. R2 The machine shall permanently retain exactly SODACOST coins for each can of soda vended R3 Coin return shall return all deposited coins since the last vend cycle R4 The machine shall return all deposited money in excess of SODACOST coins before a vend cycle



R5 The machine shall flash the light for a selected item while vending is in progress to indicate acceptance of a selection to the buyer R6 The machine shall illuminate the light for any out-of-stock item I

Assume a Fully Distributed System I

Processor for each button, coin return controller, vending controller




Traceability: UML dan Text Requirement


I

Put an “X” in every box with a related Use Case and Requirements



Catatan Traceability dari UML ke Requirement I

Lack of backward traceability for R2 : “The machine shall permanently retain exactly SODACOST coins for each can of soda vended” I

I I

I

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

I

There is a missing actor on the Use Case diagram – the soda delivery person Could add “U5. Collect Money” Possibly add “U6. Refill Machine”

U1 – too many quarters inserted U2 – soda button pressed without a quarter U2 – two soda buttons pressed concurrently U3 – coin return pressed with no money inserted

UML gradually eases from requirements to design I

I

Details of the use case become apparent as requirements are elaborated Scenarios and sequence diagrams are partway between requirements and design



Revisi Diagram Use Case



Revisi Traceability


I

Put an “X” in every box with a related Use Case and Requirements




Desain Sistem Embedded Terdistribusi @2012,Eko Didik Widianto Mesin Penjual / Vending Machine Kebutuhan Sistem Arsitektur Sistem Diagram Kelas

Kebutuhan Software

Arsitektur Sistem Diagram Kelas

Perancangan Sistem Desain Pengujian Review dan Lisensi

Kebutuhan Software Objek Kontrol Skenario dan Diagram Urutan Perancangan Sistem Rancangan Sistem Mapping Diagram Urutan ke Perilaku Sistem Desain Statechart Desain Pengujian Review dan Lisensi

Arsitektur Mesin Penjual Soda I I

Modelled using UML Class Diagram Used to show system in terms of objects, attributes, and relationships I

I

Objects are “nouns” in the system; Attributes are local state data within objects Implicit, trivial controllers are assumed built in to uncontrolled components I

I

This is a simplified class diagram – VendMotor and VendPosition not there

Classes: with association and aggregation/composition relationship I

Soda Vending Machine I I I I

I

I

Coin_in Sensor Coin Return Switch Empty Soda Sensor Button Control - Button: Button Sensor, Button Light CoinOut Control - Coin Change dispenser Vend Control - Soda Dispenser


Kebutuhan Software Perancangan Sistem Desain Pengujian Review dan Lisensi

Diagram Kelas

Diagram Arsitektur Mesin Penjual Soda

Sensor Sistem


Kebutuhan Software

I Button[s](v): Soda selection button – Physical state sensor

v={True, False}. I One button per type of soda. All are False at initialization. S is an integer 1..8 I 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 False I 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) I


Environment-Only System State


I SodaCount[s](n): The number of sodas in each chute I

Each count is set to 50 at startup

I What does “environment-only” mean?

Mesin Penjual / Vending Machine Kebutuhan Sistem Arsitektur Sistem

I

The entire system I I I I

I

I

Computing nodes Network Sensors & actuators Physical world

The physical world model keeps track of how many sodas are in a chute The embedded computers do not know how many sodas are in the chute I

I I

They only can infer it from sensors and build a model of the physical world In this system, they only know if a chute is empty or not empty In some other, fancier system the delivery person might program in number and the controllers could keep count – but they still wouldn’t “know” the actual value of SodaCount – they would be inferring it from external information

Diagram Kelas



Aktuator Sistem

@2012,Eko Didik Widianto Mesin Penjual / Vending Machine Kebutuhan Sistem

I ButtonLight[s](v): Soda selection light.


I I

I

v={True, False}. One per type of soda. When set to True turns on the light in the button for soda s; when set to False turns that light off. S is an integer 1..8 All lights set to False at initialization.

I Note: soda refill & money collection is

done manually I Note – there are more sensors and

actuators I

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



Objek Kontrol Software


I ButtonControl[s] I

I I

One per soda selection (S is an integer [1]..[8]) Controls button lights Controls sending button selections to VendControl

I CoinControl I

Controls coin return dispenser

I VendControl I

Controls dispensing the soda cans

I VendPositionControl I I

Controls the movement of the VC A mechanical device that moves across chutes to select a soda

Kebutuhan Sistem Arsitektur Sistem Diagram Kelas



Message Dictionary


I

Kebutuhan Sistem

Notation: I


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

Kebutuhan Software

I

Environmental Object Messages I

Perancangan Sistem

This message are sent by environment objects and smart sensors provided in the system

Source Node Name

Message Name

Replication

Number of fields

Empty

mEmpty

s

1

Coin_Return

mCoinReturn

none

1

VendPosition

mVendPosition

s

1



Message Dictionary


I

Controller Messages I

Mesin Penjual / Vending Machine

These messages are sent by the controllers

Kebutuhan Sistem

Source Node Name

Message Name

Replication

Number of fields

Description


Kebutuhan Software

ButtonControl

mButton

s

1

State of the soda selection button

VendControl

mVend

none

1

True when vending a soda

CoinControl

mCoinCount

none

1

Integer number of coins received

VendPosition Control

mVendMotor

none

1

State of the vend motor

I


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

Kebutuhan Software


I Emphasis on “verbs”: Structured representation of control objects I I I I

ButtonControl[s] CoinControl VendControl VendPositionControl

Kebutuhan Software Objek Kontrol Skenario dan Diagram Urutan


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

“messages”


Desain Sistem Embedded Terdistribusi @2012,Eko Didik Widianto Mesin Penjual / Vending Machine Kebutuhan Sistem Arsitektur Sistem Kebutuhan Software Objek Kontrol


Skenario dan Diagram Urutan

Perancangan Sistem Desain Pengujian


Review dan Lisensi

2. Objek ButtonControl I

Replication: I

I

Instantiation: I

I

I

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

Input Interface: I I I

I

ButtonControl[s] commands Button_Light[s] to False at initialization.

Assumptions: I

I

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

Button[s](v) mEmpty[s](v) mVend[s](v) (assume that any Vend message received indicates an actual vend event)

Output Interface: I I

mButton[s](v) ButtonLight[s](v)

Desain Sistem Embedded Terdistribusi @2012,Eko Didik Widianto Mesin Penjual / Vending Machine Kebutuhan Sistem Arsitektur Sistem Kebutuhan Software Objek Kontrol Skenario dan Diagram Urutan


2. Objek ButtonControl


I

Constants: I

FlashLimit (integer): determines the rate that the light flashes during vend.

Mesin Penjual / Vending Machine Kebutuhan Sistem Arsitektur Sistem Kebutuhan Software Objek Kontrol

I

State: I

I

I

I

IsEmpty (True, False); initialized to False; indicates when selection has no soda cans left. ButtonState (True, False); initialized to False; indicates whether the button has been pressed. FlashCounter: used to keep track of time while flashing the light druing Vend

Constraints: I

Skenario

None




Desain Sistem Embedded Terdistribusi @2012,Eko Didik Widianto Mesin Penjual / Vending Machine Kebutuhan Sistem Arsitektur Sistem Kebutuhan Software Objek Kontrol





Review dan Lisensi

Use Case 2: Customer Pushes a Soda Button I I I

I I

I

The soda machine is not vending. No button is pressed. The system has received the correct number of coins for the cost of a soda since the last vend cycle. The VendCarriage is parked in front of chute r, r < s.

Scenario: 1. 2. 3. 4. 5.

I


See: Mesin Penjual / Vending Machine http://www.ece.cmu.edu/~ece649/project/sodamachine/portfolio/scen_sd/sc Kebutuhan Sistem Scenario 2A: Customer pushes a soda button when Arsitektur Sistem the correct amount has been paid Kebutuhan Software Objek Kontrol Pre-Conditions: I

I


The Customer pushes soda button s. The light on the soda button s begins flashing. The VendPositionControl aligns with soda chute s. The soda is vended. The light on the soda button s stops flashing.

Post-Conditions: I

I

The system retains the cost of the soda and has one less soda of type s 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/sc

Kelemahan dan Kekurangan Diagram Sebelumnya


I

Pro: Everything is there I

I

Con: It is complex I

I

I

You can see all the components of the system interacting

If it is difficult to show in powerpoint, it is difficult to understand (the “Powerpoint Engineering” principle) It is a very specific case (e.g., what if it wasn’t the last soda?)

Possible ways to improve I I I

Break it up vertically into multiple steps Break it up vertically by not showing every piece interacting There is no perfect, “best” way to do this – these are just ideas

Arsitektur Sistem Kebutuhan Software Objek Kontrol Skenario dan Diagram Urutan


Kompleksitas Sequence Diagram

Desain Sistem Embedded Terdistribusi @2012,Eko Didik Widianto Mesin Penjual / Vending Machine Kebutuhan Sistem Arsitektur Sistem Kebutuhan Software

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

Objek Kontrol Skenario dan Diagram Urutan


I

There is no single right way to do it I

But in general, simpler and fewer scenarios are better than many complex ones

Review dan Lisensi

Sequence Diagram Traceability

Desain Sistem Embedded Terdistribusi @2012,Eko Didik Widianto Mesin Penjual / Vending Machine

I Sequence Diagrams to Use Cases I I

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

I Sequence Diagrams to objects I

Are all objects in at least one sequence diagram?

Kebutuhan Sistem Arsitektur Sistem Kebutuhan Software Objek Kontrol Skenario dan Diagram Urutan


I Sequence Diagrams to messages I

Are all messages in at least one sequence diagram?

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

avoid mistake gaps I

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

Review dan Lisensi

Bahasan Mesin Penjual / Vending Machine Kebutuhan Sistem Kebutuhan Umum Pengembangan Requirement Traceability UML - Text Requirement Arsitektur Sistem Diagram Kelas

Desain Sistem Embedded Terdistribusi @2012,Eko Didik Widianto Mesin Penjual / Vending Machine Kebutuhan Sistem Arsitektur Sistem Kebutuhan Software Perancangan Sistem Rancangan Sistem Mapping Diagram Urutan ke Perilaku Sistem Desain Statechart



Tahapan yang Dilakukan


1. Write down constraints & behaviors I

I

Constraints are assumptions that other components can make Behaviors are functions designed in to the component

2. Synthesize a statechart I I

Transitions have to account for all behavior triggers Transitions have to account for all behaviors (alternately, states could account for all behaviors; depends on approach)

Arsitektur Sistem Kebutuhan Software Perancangan Sistem Rancangan Sistem Mapping Diagram Urutan ke Perilaku Sistem Desain Statechart


Formula untuk Sistem Event-Driven







Diagram Urutan ke Perilaku Sistem



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 I

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


I ER2.3. If mEmpty[s] is received False and ButtonState <- False, then

Kebutuhan Software

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

Perancangan Sistem

I I

I ER 2.4. If Button[s] is received True and IsEmpty is False, then I I

I

ER2.4a. ButtonState shall be set to True. ER2.4b. ButtonLight[s] shall be commanded to blink with a period of 0.25s. ER2.4c. mButton[s] shall be set to True.

I ER 2.5. If mVend[s] is received True and IsEmpty is False, ButtonLight

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

shall be commanded to False. I ER 2.7. If mVend[s] is received True, then I I

ER 2.7a mButton[s] shall be set to False. ER 2.7b ButtonState shall be set to False.

Rancangan Sistem Mapping Diagram Urutan ke Perilaku Sistem Desain Statechart






Desain Statechart


I

Design Statecharts for each software object I I

I

I

Design states for each object Behavior requirements become conditions for state transitions Cover every behavior requirement in state chart

Traceability I

Every behavior requirement should map to a state transition arc

Kebutuhan Software Perancangan Sistem Rancangan Sistem Mapping Diagram Urutan ke Perilaku Sistem Desain Statechart


Perilaku Time-Triggered


I R2.1. mButtonState[s] shall be set to the current value of ButtonState.

Arsitektur Sistem

I R2.2. If ButtonState is equal to False AND mEmpty[s] is equal to True,

Kebutuhan Software

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, then I I

R2.4a. ButtonState shall be set to True. 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.

Perancangan Sistem Rancangan Sistem Mapping Diagram Urutan ke Perilaku Sistem Desain Statechart


ButtonControl Time Triggered Statechart



Event Triggered vs. Time Triggered?

Desain Sistem Embedded Terdistribusi @2012,Eko Didik Widianto Mesin Penjual / Vending Machine

I

Event triggered I

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

I

I I

I

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

Each message arrival is an “event” which triggers a statechart transition Networks deliver only one message at a time “Asynchronous state machines” from hardware design

Time triggered I I I

Arriving message values put into memory buffers State chart transitions based on most recent message value “Synchronous state machines” from hardware design

Kebutuhan Sistem Arsitektur Sistem Kebutuhan Software Perancangan Sistem Rancangan Sistem Mapping Diagram Urutan ke Perilaku Sistem Desain Statechart


Traceablilty Desain

Desain Sistem Embedded Terdistribusi @2012,Eko Didik Widianto Mesin Penjual / Vending Machine Kebutuhan Sistem Arsitektur Sistem Kebutuhan Software

I

I

Does every requirement map to at least one state or transition? Does every state or transition map to at least one requirement?

Perancangan Sistem Rancangan Sistem Mapping Diagram Urutan ke Perilaku Sistem Desain Statechart


(Implementation) CoinOutControl Code



Desain Pengujian


I Suggestion: design tests before actual implementation I

May uncover errors in your design before coding

Mesin Penjual / Vending Machine Kebutuhan Sistem Arsitektur Sistem

I Test at least two levels before you run a full simulation I I

Unit/module tests System integration tests

I Unit Tests I I I

Design tests to cover every state transition in every state chart Make sure erroneous state transitions aren’t taken Cover every possible message/event received by each object

I Traceability I

Document traceability between tests and state transitions for unit tests

I System Integration Tests I

Test specified operation sequences / UML scenarios


Unit Test

Desain Sistem Embedded Terdistribusi @2012,Eko Didik Widianto Mesin Penjual / Vending Machine Kebutuhan Sistem Arsitektur Sistem Kebutuhan Software Perancangan Sistem Desain Pengujian Review dan Lisensi

Pengujian Terintegrasi


Acceptance Test


I

Ensure system as a whole actually meets requirements I I

I

In simple systems, testing all scenarios suffices In real systems, need to test sequences of Use Cases

First define meaningful sequences of use cases

Mesin Penjual / Vending Machine Kebutuhan Sistem Arsitektur Sistem Kebutuhan Software Perancangan Sistem

I I

I

Next, execute tests and compare results to system requirements I I

I

Example: insert coin, push soda button Example: insert coin, push coin return, push soda button

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

Additional test strategies: I I

I

Design tests to attempt requirement failure Reset system partway through a scenario or between use cases ...


Simulasi


I

vmcsrepo: Vending Machine Simulator Project using JavaSE and OOAD I

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


Review I Requirements I

I

Use cases (which are exemplary, but not necessarily coherent/definitive) System-level text requirements

I Architecture I

I

I

Class Diagrams – model “nouns” in system as classes & “architecture diagram” Define network variables that define architectural interfaces (message dictionary) Sensors, actuators, software objects

I Software Requirements I I

Scenarios – details inside use cases Sequence Diagrams

I Design I I I

Detailed text behavioral requirements State Charts (state transitions) Test Design

I Implementation I I

Write the code Module testing (unit tests)

I Integration I

Integration tests; acceptance tests



Lisensi


Creative Common Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0) I

Anda bebas: I

I

I

Di bawah persyaratan berikut: I

I

I

untuk Membagikan — untuk menyalin, mendistribusikan, dan menyebarkan karya, dan untuk Remix — untuk mengadaptasikan karya

Atribusi — Anda harus memberikan atribusi karya sesuai dengan cara-cara yang diminta oleh pembuat karya tersebut atau pihak yang mengeluarkan lisensi. Pembagian Serupa — Jika Anda mengubah, menambah, atau membuat karya lain menggunakan karya ini, Anda hanya boleh menyebarkan karya tersebut hanya dengan lisensi yang sama, serupa, atau kompatibel.

Lihat: Creative Commons Attribution-ShareAlike 3.0 Unported License


2012. Eko Didik Widianto

Recommend Documents