Parking Payment Machine Guide

Active Workshop
Dr. Amir Tomer
Software Engineering Department Head
amir@amirtomer.com
052-8890202
©Dr. Amir Tomer 1 Functional Specification with Use Cases

Exercise 1 – Operational Specification
• Write a short “operational specification” (operational instructions,
user manual) for the following parking payment machine

Exercise follow-up questions
1. Who is the “operator”? Could there be any other “operators”?
2. What is a “successful” operation? Is it unique?
3. Are there any “unsuccessful” operations? How are they
recognized?
4. What are the conditions under which the operation can start?
5. Did you refer to all the instructions/exceptions given by the
additional stickers?
6. Who benefits from a successful operation? Do all the benefiters
participate in the operation? If not, what does the system do to
ensure their benefit?

Purpose (why are you here?)
• The purpose of this workshop is to introduce a simple, practical
and precise method for writing functional/operational
specifications for software-intensive systems
Simple: Can easily be applied and understood by a variety of
stakeholders, with no necessary technical knowledge
Practical: Worth the effort of doing it, by greatly contributing to the
entire development life-cycle
Precise: Provides a clear and well-defined format, which minimizes
doubts, ambiguities and debates
Software-intensive Systems: Systems whose functionality is mainly
implemented by software (most interactive systems)

Theory and Practice in this Workshop
• The workshop is based upon established theoretical concepts,
mainly from UML/SysML
However…
• Theory does not always cover all the actual cases in real life
Therefore…
• Some of the terms and notations introduced in this workshop are
not always aligned with the theory,
But…
• Everything here is based upon many real-life cases and is intended
to provide practical and fit-for-use methodology for writing use-case-
based requirement specifications

And remember…

Workshop Agenda
• Requirements: The basis for system development
• The use-case model
• The UnderMiner case-study
• The use-case model and system architecture
• From system use-cases to software use-cases
• Use-case realization

Requirement – Definition*
1. Condition or capability needed by a user to solve a problem or
achieve an objective
2. Condition or capability that must be met or possessed by a
system … to satisfy an agreement, standard, specification, or
other formally imposed documents
Provides solution
System
Development
Process
Users
Documents
(representing other stakeholders)
Satisfies
* ISO/IEC/IEEE 24765:2010 Systems and software engineering – Vocabulary

Functional vs. Non-Functional Requirements
Non-functional Requirements
• Define attributes and constrains over
the way the solution content is
designed/implemented
– Are met when the solution (design/code)
satisfy the attributes and constraints
Functional Requirements
• Define the solution content
– Implemented directly and
specifically in the solution
(design/code)
Non-functional Requirements
Design /
Implementation
Functional Requirements
Solution Domain

Typical Software-Related Functional Requirements
• Operational Requirement
– A requirement specifying operation, interaction or behavior of the
software
• Anything the software has to “do”
– Actions, scenarios, reaction to events, etc.
• Data Requirement
– A requirement specifying entities of information which the software
needs to deal with
• Anything the software has to “know”
– Values, parameters
– Data items, data structures
– Databases, repositories

Typical Software-Related Non-Functional Requirements (1)
• Performance requirements
– Measurable parameters about the performance of the software
• Response time, storage capacity, processor usage, etc.
• Quality attributes
– Characteristics of the overall product
• Reliability – faultless long term operation
• Availability – continuous service, fast recovery from faults
• Safety – not risking the life/health of users
• Security – protecting the system components and the data hanled
• Maintainability – the ease to make corrections and changes
• Usability – contribution to the users in performing tasks or avhieving
goals
– Quality attributes should be defined quantitatively!

Typical Software Non-functional requirements (2)
• Constraints
– Hardware constraints
• The hardware platform to which the software should adapt
• Usually provided by system engineers through the system design
– Implementation constraints
• Any provisional solution which is imposed on the developer (e.g., algorithm,
reused component, certain brand etc.)
– Management constraint
• Any administrative consideration imposed on the developer
– Budget
– Due date
– Resource availability
– Standard
– …

Exercise 2: Requirement Types
• Regarding the parking payment machine, give examples for the
following types of requirements
– An operational requirement
– A data requirement
– A performance requirement
– A quality attribute (which one?)
– A hardware constraint

Requirements Repository vs. Requirements Model
• A requirements repository is a list/table/database of discrete
requirements, which may be classified into categories and/or organized
into groups
– The requirements repository is useful as
• A checklist for design/implementation coverage
• A checklist for system verification/validation
• A basis for requirements allocation to system components
– E.g., DOORS, Excel tables, etc.
• An operational-requirements model is a representation of the actions and
interactions of the system, based on the discrete operational
requirements
– The operational-requirements model is useful for designing and
implementing the behaviour of the system
• The system’s behaviour is usually implemented by software

Operational Requirements and the Use-Case Model
• The Use-case model, which is the focus of this workshop, is intended to
provide a complete specification of the system behaviour in view of its
operational requirements
– The operational requirements are gathered into operational scenarios
– Other aspects of the operational context are addressed, such as
• Conditions before and after performing an operation
• Interaction with the environment
• Stakeholders interests/concerns regarding system operation
• Other types of requirements are addressed by the use-case model
whenever they are relevant for the system’s operation
• The use-case model is intended to provide full coverage of the system’s
operational requirements
– While sorting out conflicts, shortfalls etc.

Workshop Agenda

System Stakeholders
• A system stakeholder* is an individual, team, or organization (or classes
thereof) with interests in, or concerns relative to, a system
– In the operational/functional context the stakeholders’ interests/concerns are with
respect to the system’s operation
– The stakeholders’ interests/concerns should be expressed in measureable terms
• MoE = Measurement of Effectiveness (will be discussed later)
• Examples
– Users/operators
• Achieving goals, using services, producing outputs
– Regulators
• Impose/constrain system behaviour and/or output (e.g. safety, data security)
– Testers, maintainers, installers, etc.
• May require additional system actions wile servicing other stakeholders (e.g. event logs)
* IEEE 1471-2000: IEEE Recommended Practice for Architectural Description of Software-Intensive Systems

• An actor is an entity of the system’s external environment
which can directly interact with the system
– Actors are system stakeholders or representatives of system
stakeholders
• E.g., an external computer interacting with the system is not a
stakeholder by itself because it has no interests/concerns of its
own but it rather represents the interests/concerns of some
“real” stakeholder(s)
– Not all stakeholders are actors!
– HMI devices (e.g. keyboard, mouse, microphone, card reader
etc.) should be considered as part of the actor itself
• i.e. Although the human is not directly connected to the
machine, it is still the actual actor, and not the keyboard
Actors
UML notation
Actor Name

Is the target an actor of the interceptor?
• The target produces some kind of emission
which is detected by the missile
• The missile “follows” the target,
and intercepts it
• Therefore, the target must be an actor of
the missile…
• No.
– An actor is an entity which cooperates
with the system and is aware of its
interaction with it!
So, who is the
Interception
actor?

Use Cases
• A use case (UC) is a complete task performed by a system for the purpose
of producing defined measurable results for one or more system
stakeholders
– A use case may either be initiated by an actor or by the system itself
• A spontaneous (or internal) use case is a use case which is initiated as a result
of a system’s internal event or condition
– A use case is a description of an agreed-upon interaction with system
actors
• The interaction and its results are visible to the system stakeholders
– A use case includes all the possible interactions performed for achieving
the same results, whether the results have been achieved or not
– Multiple instances of the same UC may be performed concurrently
UML notation
Use Case Name

Use Cases and Actors
• Every use case is associated with a set of actors, as follows
– A Primary Actor is an actor who interacts with the system in order to achieve one or
more goals
• The primary actor initiates the use case through a provided interface of the system
• Multiple primary actors mean that each one can initiate the UC independently
– A Supporting Actor is an actor whom the system interacts with in order to assist in the
fulfillment of its goals
• The initiation of the interaction is done by the system through one of its required interfaces
– A use case with no primary actors is a spontaneous use case
• Spontaneous use cases are internally initiated (internally) by the system in order to satisfy
stakeholders’ interests
– An actor can inherit another actor
• When Actor A inherits actor B it means that A can do everything B can, in addition to its own
unique actions
• In addition, a use case is also associated with a set of relevant stakeholders
– A relevant stakeholder has specific interest(s) in the use case

System of Interest
Use Case1
Actor1’s roles:
• Primary actor of UC1
• Supporting actor of UC2
Use case
initiation
Actor1 Use Case2
Use Case3
System
Boundary
Actor2’s roles:
• Primary actor of UC2
• Supporting actor of UC1
• Relevant stakeholder of UC1
Actor2
Stakeholder3
«satisfy»
«satisfy»
Use Case Diagram (UML)
• A Use Case Diagram (UCD) is a visual representation of the set of a
system’s use cases and their relations with the set of system’s
actors (stakeholders)
UC name: Reflects the UC’s purpose
Stakeholder3’s roles:
• Relevant stakeholder of UC3
UC 3 is a spontaneous UC:
It has no primary actor!

The UCD is not a Behavioural Model!
• The use case diagram does not specify any operational or behavioural
aspects of the system
– Each use case represents an independent complete (end-to-end) task,
regardless of the other use cases
• The use case diagram is a graphical representation of a relation between a
set of use cases and a set of actors/stakeholders
• The use case diagram can be replaced by a table, without losing any
information
Actor1 Actor2 Stakeholder3
UseCase1 PA RS
UseCase2 SA PA RS
UseCase3 SA
PA = Primary Actor
SA = Supporting Actor
RS = Relevant Stakeholder

Exercise 3 – Use Case Diagram
• Suppose that the parking payment system has 3 use cases
– System Installation
– Parking Payment
– System Admin. & Maintenance
1. Define the purpose of each use case
2. Define the set of stakeholders
3. Draw a use case diagram for the system, reflecting the
stakeholders’ roles in each use case

The Use-Case Operation Cycle
Actors Stakeholders

Post-
Conditions
Pre-conditions
What must exist
in order to
enable the UC
Trigger
The
initiating
event
Alternative
A different
scenario which
leads to successful
Main Success Scenario - MSS
The shortest and simplest way to
achieve successful completion
completion
Post-Conditions
What must exist
after successful
completion
Exception
A scenario which
leads to
unsuccessful
completion
Successful Completion =
Goals achieved and interests assured

Post-Conditions
• Post-Conditions determine what should be the results of a
successful accomplishment of a use case
– Success is defined from the viewpoint of the stakeholders, reflecting
the achievement of the expected results
• Actor’s goal (e.g. receiving cash)
• Stakeholders’ interests (e.g. debiting user’s account)
– Post-Conditions are phrased as predicates (boolean statements which
has definite TRUE or FALSE value
• E.g. “user has cash”, “user’s account debited”

Pre-Conditions
• Pre-Conditions are prerequisites for the use case
to start its operation
– This is a list of assumptions that if they don’t exist
then the UC cannot operate or does not make
sense
• E.g. The user has an ATM card
– Pre-conditions may cease to exist during the use
case operation. In this case it is the concern of the
system to deal with the situation
– Pre-Conditions are phrased as predicates
(boolean statements which has definite TRUE or
FALSE value
• E.g. “The ATM is on”

Exercise 4 – Pre- & Post- Conditions
• Regarding the 3 parking payment system’s use cases
– Parking Payment
1. What are the Post-Conditions of each use case?
– How do they reflect the primary actors’ goals and the relevant
stakeholders’ interests?
2. What are the Pre-Conditions for each use case?
– Are any of them identical to post-conditions of other use cases?

Trigger
• Trigger is the event that “starts-up” the use case
– The trigger can be either
• An action performed by a primary actor
• An event or a condition inside the system (for spontaneous UC)
• An event or a condition occurred at an extension point in another use
case
– Extending UCs will be discussed later
– A trigger can be fired only if permitted by the pre-conditions
• E.g. the trigger “select WITHDRAW option from the menu” can only occur
under subject to the pre-condition “The menu is presented to the user”

Scenarios
• A Scenario is a course of interaction between the system and its actors, as
perceived from the viewpoint of the systems’ stakeholders
– A scenario is written as a sequence of steps, each of which is an action
performed either by the system or by an actor
• All the actions performed by the system are visible to the stakeholders
• This means that scenarios do not reflect the internal behaviour of the system!
– The internal behaviour of the system is a design issue, which may be specified
later by design models, such as Activity and Sequence Models
– Scenarios may contain loops (“for…”, “while…”, “until”, etc.)
– Scenarios may contain conditionals (“if … then …”),
but no branching (no “else”)
• Every branch is a separate scenario

Main Success Scenario
• The Main Success Scenario (MSS) describes the shortest and most
straightforward interaction by which the post-conditions can be
achieved
– The MSS is the “reason” for the use case
– All other scenarios branch from the MSS
– The MSS immediately follows the trigger
• It does not repeat it, neither the pre-conditions
• The MSS is written in “success oriented” fashion
– Not “the system checks if…” but rather “the system verifies that…”

Branching Scenarios
• An alternative (another success scenario) is a different
scenario, branching from the MSS, or from another scenario,
and ending up in success (i.e. post-conditions achieved)
• An exception (a failure scenario) is a scenario branching from
the MSS, or from another scenario, and ending up in failure
(i.e. one or more post-conditions were not achieved)
• Note:
– Scenario success/failure are determined only by means of
the post-conditions
– The system must successfully perform the failure scenarios!
• Question:
– When an intruder is detected and blocked by the system
while trying to log into it. Is it a success or a failure?

Exercise 5 – Scenarios
• Regarding the “parking payment” use case
1. Specify the trigger
• The trigger is either performed by a primary actor or an
internal event/condition inside the system
2. Write the Main Success Scenario (MSS)
• A sequence of actions, each of which is performed either
by the system or by an actor
3. Suggest Alternatives and Exceptions
• For each, specify their branching point, describe in short
what will happen and refer to the achieved/forfeited

Conditional Relations between Use-Cases
• Post-Conditions, resulted by one UC, may be Pre-Conditions for one or more other UCs
– E.g. ATM
User identified
Menu displayed
User
Identification
ATM in order
User has card
Money
Withdrawal
• This does not necessarily impose a pre-determined operational flow!
• Pre-conditions may by provided by other UCs
– E.g. Elevator
User has cash
Account debited
Elev. at floor
Door open
Call
Elevator
User at floor
System operational
Ride
Elevator

“include” Relation between Use Cases
• UC A (a base UC) includes UC B (an included UC) if B is an integral
part of A
– B can still perform as an independent UC, having multiple triggers
• E.g, Built-in-Test (BIT)
System Start-up
operator BIT
tester
Base UC
Included UC
UML notation
<<include>>
System
Start-up
BIT

When to use “include”?
• Extracting a part of a use-case and defining it as a separate
“included” use-case may be useful in one or more of the following
cases
1. The included use-case is large
2. The included behaviour is common to more than one base use-cases
3. The included use-case may be initiated independently of the base
use-case

“extend” Relation between Use Cases
• UC B (an extending UC) extends UC A (a base UC) if B is optionally
invoked during the performance of A
– B is initiated at a pre-defined extension point in A’s scenario(s)
– B can still perform as an independent UC, having multiple triggers
• E.g, Rescue a user from a stuck elevator
Riding Elevator
Base UC
?
Rescuing users
user
Extending UC
Rescuer
Extension Point
(call rescue)
(supporting actor)
UML notation
<<extend>>
Rescuing
Users
Riding
Elevator

When to use “extend”?
• In most cases the need for “extensions” is provided by scenario
branches (alternatives, exceptions) within the bas use-case itself
• Extending the flow of scenarios by an external use-case may be
useful in the following cases
1. The extending behaviour is large
2. The extending behaviour is common to more than one base use-case
3. The extending use-case may be initiated independently of the base
use-case

Use-Cases and Operational Requirements
• Use-cases are the basis for the implementation of the entire
system behaviour, therefore
– Each use-case should address at least one functional requirement
• Otherwise it is redundant
– Every functional requirement should be allocated to at least one use-case
• Otherwise it will not be implemented in the system
– Thus, the complete use-case model of a system-of-interest covers all
the operational requirements
• Bi-directional traceability between the use-case model and the
operational requirements (e.g. in Doors) is essential!

Use-Cases and Non-Functional Requirements
• Non-functional requirements (aka Quality Attributes) specify “how well”
the system will perform its functionality
– Performance
– Reliability / availability
– Safety / security
– Measurement of Effectiveness (MoE)
• The quality attributes are granted to the system in the design phase
– Selecting a design that will provide the required attribute
• Therefore, the use-case model usually cannot address non-functional
requirements
• However, relevant non-functional should be associated with use-cases in
order to be considered during use-case implementation
• Exceptionally, the usability quality attribute may be greatly affected by
the human-machine interaction as specified in the use-cases

Exercise 6 – Non-Functional Requirements
• Regarding the 3 parking payment system use cases
– Parking Payment
• Suggest NFRs (quality attributes) which might be associated with
each use-case, for consideration during its implementation

Writing Use-Case Specifications: Putting it all Together
• A [textual] use-case specification is a structured text which includes the
following elements:
 Use-case ID and name (reflecting its purpose in 2-3 words)
 Purpose
 Actors
• Primary actors and their goals
• Supporting actors and their roles
 Relevant stakeholders and their specific interests in this use-case
 Trigger(s)
 Main Success Scenario (MSS)
 Branching scenarios (alternatives/exceptions)
 Requirements traceability
• Functional/operational requirements addressed in this use-case
• Non-functional requirements relevant to the implementation of this use-case
 Complementary documentation (open issues etc.)

Workshop Agenda

The UnderMiner Case Study: Brief Overview
• Purpose
– UnderMiner is a military system supporting a unit of the Engineering Corps in
dealing with a set of suspected tunnels
• Capabilities
– Scanning: providing a 3D tunnel map + motion track
– Trapping: Scattering mines inside a tunnel
– Clearing: Shooting at objects within a tunnel
• Structure
– Mole: The end unit – a small robot with navigation, sensing, shooting, mine-scattering
and self-explosion capabilities
• Each Mole is operated by a mole operator
– C4I: The central command and control computer, controlling up to 8 moles
• The C4I and the commander’s and operators’ workstations are located in a C4I wagon

UnderMiner: Operational Highlights
• Carrying out an operation
– An operation command is received from Headquarters
– The UM commander plans the operation and assign
missions to moles
– Each operator inserts its mole into a tunnel and controls
its mission from his workstation in the C4I wagon
– Upon mission completion each mole returns to tunnel
entrance and collected by its operator
– Moles can identify and report problematic situations;
when necessary destruction may be directed by the
commander
– The operation status is reported continuously and on-demand
to Headquarters

Exercise 7 – UnderMiner: Operational Overview
• Read the Operational Specification document of the UnderMiner
(in Hebrew)
• Make a list of system stakeholders and their main
interests/concerns about the operation of the system
• Draw a UC Diagram for the UnderMiner system, showing the
primary actors, supporting actors and relevant stakeholders for
each use-case
"חתרנית"
אפיון מבצעי
UCD

Workshop Agenda

“System” – a recursive-hierarchical Structure*
     
system
element
system
element
system
system
element
system
element
system
element
system-of-interest
system
element
system
element
The method introduced in this workshop is applicable
for any type and any scale of a “system of interest”
* ISO/IEC 15288:2008: Systems and software engineering – System life cycle processes
system
element
system system system
system
element
system
element
system
system
element
system
element
system
element
system
system system element
Hierarchy
(The depth of the
hierarchy depends on
the scope of interest)
Recursion
A system is
comprised of
systems
(and elements)

System in its Environment*
Stakeholders
Have no interaction but impose
needs, constraints and interests
Enabling
System A
Enabling
System B
Enabling
Interaction with enabling System C
systems, usually in other
life-cycle stages rather
than operations
System B in
Operational
Environment
System of
Interest
System A in
Operational
Environment
System C in
Operational
Environment
Interaction with systems
comprising the
operational environment
Interaction with human
Users / Operators
* ISO/IEC 15288:2008: Systems and software engineering – System life cycle processes (+ adaptations)

Interfaces
• The connections between the system-of-interest and its external
environment are called interfaces
• However,
– The operational interaction between entities is defined in terms of
functional interfaces, whereas
– The actual contact between the entities is by means of physical
interfaces
• Therefore, the interface issue should be sorted out in accordance
with the operational specification
• So, let’s talk about interfaces…

Physical Interfaces
• A physical interface is an exposure of the system to the external
environment for the purpose of interaction, interoperability,
exchange, supply or acquisition
• Example: Typical physical interfaces of a mobile device

Functional (Logical) Interfaces
• A functional (logical) interface is a mutually agreed form of signal/data
interchange used for obtaining/providing services among communicating parties
– A Provided Interface is an interface exposed by a functional entity, through which it
can provide services to other entities
– A Required Interface is an interface exposed by a functional entity, through which it
can acquire services from other entities
• Example: Typical functional interfaces of a navigation application on a mobile
device
?
Provided
Interfaces
Required
Interfaces

Functional and Physical Interface – UML Notation
• Physical Interfaces: Composite Structure Diagram
Bluetooth
Part
Port
• Functional/Logical Interfaces: Component Diagram
Component /
Artifact
Dynamic display
Sat.
Data
Navigation Application
Required
Interface
Vocal Directions Maps/Routes
Search
Zoom
GSM
Display
Touch
Speaker
Microphone
Mains
Earphones
USB
Home Key
GPS
Mobile Device
Provided
Interface
API =
Application
Program
Interface

Interface Delegation – The Entire Picture
• Delegation is the association of functional (internal) interfaces with
physical (external) interfaces
– External entities use physical interfaces (ports) to access functional
interfaces
Mains
GSM
Display
Touch
Speaker
Earphones
Bluetooth
Microphone
USB
Mobile Device
«delegate»
Navigation Application
«delegate»
«delegate»
Vocal Directions Maps/Routes
Search
Home Key
GPS
Sat.
Data
Dynamic display
«delegate»
Zoom
«delegate»
«delegate»
«delegate»

Exercise 8 - Interfaces
• Specify the physical (port) and the functional interfaces of the
parking payment machine and their delegations
Parking Payment Machine
Parking Payment Application

System Architecture
• System architecture* is the fundamental organization of a system embodied in its
components, their relationships to each other, and to the environment, and the principles
guiding its design and evolution
• For the purpose of the operational model we will model the architecture as
– The set of all physical platforms and their internal and external physical interfaces (ports)
– The set of all software components and their internal and external functional interfaces
– All the delegation relations between functional and physical interfaces
Port B1
Component
BX
«delegate»
«delegate»
Port B2
Platform B
Port A1
Component
«delegate»
Port A2
Port A3
Platform A
Port C1 Port C2
Platform C
AX
«delegate»
Component
AY
«delegate» «delegate»
Component CX
Component
BZ
«delegate»
* ISO/IEC 15288:2008 Systems and software engineering – System life cycle processes
Port B3
Component
BY
«delegate»

Exercise 9 – UnderMiner: System Architecture
• Read the Technical Specification document of the UnderMiner (in
Hebrew)
• Draw the physical architecture model which includes
– The two platforms (C4I Computer, Mole Computer)
– The physical interfaces (ports) of the platforms
– The four software components (within the platforms)
• Based on the Operational Specification, add
– Functional interfaces (provided/required)
– <<delegate>> relations
"חתרנית"
אפיון טכני
• Compare the UC diagram with the system architecture, and identify the
functional and physical interfaces through which every actor interacts
with the system
System
Architecture

The Use-Case Model is Part of the Architecture
• The Use-Case Model specifies the behavioural (operational) principles of the system
– It focuses on the external interaction between the system and its external environment (including
human users/operators)
• The consistency between the UC model and the system architecture and the tight association
between the system interaction and the system interfaces makes it part of the system architecture
• Note that not all the system ports are used for interaction – some of them are used by the system
itself
– E.g. the various mole mechanisms
רשת
טקטית
תצוגת
מפקד
תצוגת
מפעיל
[1..8]
פיקוד
מפקד
פיקוד
מפעיל
[1..8]
רשת
פנימית
רשת
פנימית
מחשב שו"ב
מנגנון
תנועה
כרטיס
חיישנים
«delegate»
תנועה
חישה
«delegate»
«delegate»
חישה
תפעול
ירי
«delegate»
מנגנון
ירי
1.. מחשב חולד 8
תוכנת ניווט
בקרת
תנועה
תוכנת חולד
תפעול
מיקוש
«delegate»
מנגנון
מיקוש
תפעול
השמדה
«delegate»
מנגנון
השמדה
אגירת
תמונות
ומסלולים
פיקוד
חולד
פיקוד
עליון
«delegate»
«delegate»
תוכנת שו"ב תצוגות
פיקוד
«delegate»
יצירת מפות
עיבוד תמונה
ניהוג ידני
«delegate»
תמונות
ומסלולים
פיקוד
חולד
«delegate»
«delegate»
«delegate»
«delegate»
«delegate»
«delegate»
מפקד חתרנית
מערכת חתרנית - מצב מבצעי
הכנה לפעולה
ביצוע משימת סריקה
העברת פקודה
תכנון מבצע
מפעיל חולד
ביצוע משימת מילכוד
ביצוע משימת טיהור
איתחול חולד
ביצוע השמדת חולד
מפקדה ממונה
קבלת דיווח ע"פ
סיום מבצע
דרישה
הקצאת משימות
מודיעין
מבצעים
בטיחות
«include»
«extend»
«extend»
«extend»
«has_interest»
«include»
«has_interest»
«has_interest»
«has_interest»

Exercise 10 – UnderMiner: Writing a Complete System Use-Case
• Write a complete UC specification for one of the following use-cases
(at your discretion)
– Performing Scan Mission
– Mission Allocation

Workshop Agenda

From System-Level UCs to Software-Level UCs
• In large systems each software component/application might be
considered as a CSCI (Computer Software Configuration Item)
– In this case the CSCI is developed on its own and is later integrated
with other CSCI
• The CSCI is then considered as a “System of Interest”
– The external environment of the CSCI comprises
• Entities in the main system’s external environment with whom the CSCI
interacts directly through the physical interfaces
• Other CSCIs, with whom it interacts through its functional interfaces
• The CSCI’s interactions may be revealed from the realization of
system-level use cases
– E.g. Sequence Diagrams (see next)

CSCI A CSCI B
Deriving Software-Level UC Specification
from System-Level UC Realization
PA 1 SA 2
1.0 Service X()
1.1
1.2
1.3
1.4
1.5
1.6
1.7 Service Y()
1.8
1.9
1.10
1.11
PA 1
SA 2
CSCI B
CSCI A
Serv ice X
Serv ice Y

Exercise 11 – UnderMiner: Software-Level Use Cases
• Based on details in the operational specification suggest a refined
use-case diagram for the Mole Software component, regarding
mission
תוכנת חולד «delegate»
רשת
פנימית
כרטיס
חיישנים
«delegate»
תנועה
מנגנון
תנועה
מנגנון
ירי
מנגנון
מיקוש
מנגנון
השמדה
חישה
תפעול
ירי
תפעול
מיקוש
תפעול
השמדה
תמונות
ומסלולים
תוכנת חולד
פיקוד
חולד
חישה
ניווט חולד
ניהוג ידני
«delegate»
«delegate»
בקרת
תנועה
«delegate»
«delegate»
«delegate»
«delegate»
«delegate»
Software-level
Use-cases

Workshop Agenda

Use-Case Realization
• Once the operational specification is complete the use-cases need to be
realized by means of the system’s detailed-design components
– The components perform functions allocated to the
• A scenario prescribes a specific sequence of functions applied for the sake
of the UC purpose
– These functions are performed by design components, either by internal
or external interaction
• Use-case realization comprises the following:
– Identifying the functions applied in each scenario
– Allocating the functions to design components (if not already allocated)
– Realizing the scenario by detailed behavioral models

Use Case Realization Models (UML/SysML)
• There are three main behavioural models by which use cases can
be realized
– Activity Diagram
• Control/data flow
– State Machine Diagram
• Transition between states in response to events
– Sequence Diagram
• Synchronous/A-synchronous message/function exchange between
components
• Which one(s) to choose?
– Depends on the system’s control type (see next)

Control Types
• The behaviour of a system/component is driven by its control type
• There are three main types of control
– Pre-determined (algorithmic) flow
• The system/component follows a pre-defined order of actions (a program)
• This is best modeled by Activity Diagram
– Event-driven flow
• The system/component reacts randomly to external or internal events
• This is best modeled by State-Machine Diagram
– Distributed (interactive) flow
• The overall behaviour of the system/component is obtained as interaction
between its sub-components and between sub-components and the external
environment
• This is best modeled by Sequence Diagram
– Provided that the internal breakdown into sub-component is known!

Activity Diagram Example: Parking Payment Machine
Read
parking card
Eject card
[card valid]
Calculate
fee
Display fee
Accept cash
[cash<fee]
Print ticket
Decision
<<datastore>>
Dispense
change
fee
cashbox
Start
(trigger)
(parallel flows)
End
Data
Fork
(success)
End
(failure)
The activity diagram
captures both the MSS
and all the branching
scenarios

Using Swim-Lanes in Activity Diagram
Card Reader Printer Processor Cash Box Display
Read
parking card
Eject card
[card valid]
Calculate
fee
Display fee
Accept cash
Print ticket
Dispense
change
[cash<fee]
Swim lanes are partitions
within an activity diagram
which represent the
provisional allocation of
functions to components
in the functional analysis
stage.

State-Machine Example: Printer
File-received
/ notify
Busy
idle
Printing
cancel
End-of-file
Do/ loop
{print page, eject page}
Stuck paper
/ notify
Feeder_empty
/ notify
Feeder_full
Jammed Out of paper
Cover_opened Cover_closed
Repairing
[stuck paper]
Cover_closed [clear]
State
Action
(performed while
in the state)
Event
Since events are naturally
associated with use-case
triggers, UC realization by
state-machine should be
considered when there is
significant activity inside
each state, and then
states may be associated
with use-cases

Sequence Diagram Example: UnderMiner [a]
פיקוד
עליון
ממשק פיקוד ממונה
«GUI»
פיקוד
ממשק מפקד
פיקוד מפקד
The internal
structure of the
“C4I SW” component
שרותי
מידע
מפות והשתלטות
ומסלולים
ניהוג
ידני
פיקוד
תפעול
חולד
«GUI»
ממשק מפעיל
פיקוד מפעיל
«datastore»
ניהול מידע
דגימות
חיישנים
שרותי
מידע
שרותי
מידע
מפת מנהרה
תוכנת שו"ב
פיקוד עליון
העברת פקודת
מבצע
הפסקת מבצע
שינוי מטרת
מבצע
אדמיניסטרציה
The UC
To be realized
מפקד חתרנית מפקדה ממונה
דרישה
דיווח סיום
מבצע
תכנון ובקרה
sd העברת פקודה
()הדוקפ_רוגיש 1.0
(from Business Level UC)
תוכנת שו"ב::ממשק פיקוד
ממונה
«datastore»
תוכנת שו"ב::ניהול מידע
«GUI»
תוכנת שו"ב::ממשק מפקד
()הדוקפ_ןוסחיא 1.1
()הדוקפ_לע_העדוה 1.2
()הלבק_רושיא_תשקב 1.3
1.4
1.5
1.6
(see next)

Sequence Diagram Example: UnderMiner [b]
sd העברת פקודה
()הדוקפ_רוגיש 1.0
(from Business Level UC)
תוכנת שו"ב::ממשק פיקוד
ממונה
«datastore»
תוכנת שו"ב::ניהול מידע
«GUI»
תוכנת שו"ב::ממשק מפקד
()הדוקפ_ןוסחיא 1.1
()הדוקפ_לע_העדוה 1.2
()הלבק_רושיא_תשקב 1.3
1.4
1.5
1.6

That’s all folks!
Thank you for attending.
Keep in touch!

Auxiliary slides
(examples)

Use Case Diagram – חתרנית
מערכת חתרנית - מצב מבצעי
הכנה לפעולה
העברת פקודה
תכנון מבצע
מודיעין
«has_interest»
מפעיל חולד
«include»
«extend»
«include»
סיום מבצע
דרישה
הקצאת משימות
מבצעים
«has_interest»
בטיחות
«extend»
«extend»
«has_interest»
«has_interest»

חתרנית – ארכיטקטורה מערכתית
רשת
טקטית
תצוגת
מפקד
תצוגת
מפעיל
[1..8]
פיקוד
מפקד
פיקוד
מפעיל
[1..8]
רשת
פנימית
רשת
פנימית
מחשב שו"ב
מנגנון
תנועה
כרטיס
חיישנים
«delegate»
תנועה
חישה
«delegate»
«delegate»
חישה
תפעול
ירי
«delegate»
מנגנון
ירי
תוכנת ניווט
בקרת
תנועה
תוכנת חולד
תפעול
מיקוש
«delegate»
מנגנון
מיקוש
תפעול
השמדה
«delegate»
מנגנון
השמדה
אגירת
תמונות
ומסלולים
פיקוד
חולד
פיקוד
עליון
«delegate»
«delegate»
תוכנת שו"ב תצוגות
פיקוד
«delegate»
יצירת מפות
ניהוג ידני
«delegate»
תמונות
ומסלולים
פיקוד
חולד
«delegate»
«delegate»
«delegate»
«delegate»
«delegate»
«delegate»

לתוכנת חולד )א( UCD – חתרנית
ניהול ובקרת משימות
תוכנת חולד
הגדרת משימה
שינוי משימה
הפסקת משימה
כרטיס חיישנים
מנגנון ירי
מנגנון מיקוש
<<CSCI>> ב"וש
מנגנון השמדה
«extend»
«extend»
«extend»
אדמיניסטרציה תנועה במנהרה

לתוכנת חולד )ב( UCD – חתרנית
תנועה במנהרה
תוכנת חולד
תנועה בניווט
אוטונומי
תנועה במסלול נתון
תנועה בניהוג ידני
אדמיניסטרציה ניהול ובקרת משימות
כרטיס חיישנים
<<CSCI>> דלוח טווינ
<<CSCI>> ב"וש
תוכנת חולד
העברת נתונים לשו"ב
כיבוי חולד
«i ncl ude»
BIT עוציב
ניהול ובקרת משימות תנועה במנהרה
<<CSCI>> ב"וש

לתוכנת שו"ב )א( UCD – חתרנית
תוכנת שו"ב
עריכת תוכנית
מבצע
סיום מבצע
הקצאת
משימות
מפעיל חולד מפקד חתרנית
השתלטות על
מפעיל
בקרת משימה
העברת מידע
וסטטוס
<<CSCI>> דלוח
<<CSCI>> תנומת תיינב
מנהרה

לתוכנת שו"ב )ב( UCD – חתרנית
תוכנת שו"ב
העברת פקודת
מבצע
הפסקת מבצע
שינוי מטרת
מבצע
מפקד חתרנית מפקדה ממונה
דרישה
דיווח סיום
מבצע
תוכנת שו"ב
איתחול מערכת
«include»
הכנה להמתנה
למבצע
1..8
1..8
מפעיל חולד
פיקוד עליון תכנון ובקרה

Parking Payment Machine Guide

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Parking Payment Machine Guide

Similaire à Parking Payment Machine Guide (20)

Plus de Prof. Amir Tomer

Plus de Prof. Amir Tomer (10)

Dernier

Dernier (20)

Parking Payment Machine Guide

Notes de l'éditeur