Weitere ähnliche Inhalte Ähnlich wie Functional Specification with Use-Cases (20) Mehr von Prof. Amir Tomer (10) Kürzlich hochgeladen (20) Functional Specification with Use-Cases1. Active Workshop
Dr. Amir Tomer
Software Engineering Department Head
amir@amirtomer.com
052-8890202
©Dr. Amir Tomer 1 Functional Specification with Use Cases
2. Exercise 1 – Operational Specification
• Write a short “operational specification” (operational instructions,
user manual) for the following parking payment machine
©Dr. Amir Tomer 2 Functional Specification with Use Cases
3. 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?
©Dr. Amir Tomer 3 Functional Specification with Use Cases
4. 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)
©Dr. Amir Tomer 4 Functional Specification with Use Cases
5. 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
©Dr. Amir Tomer 5 Functional Specification with Use Cases
7. 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
©Dr. Amir Tomer 7 Functional Specification with Use Cases
8. 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
©Dr. Amir Tomer 8 Functional Specification with Use Cases
9. 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
©Dr. Amir Tomer 9 Functional Specification with Use Cases
10. 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
©Dr. Amir Tomer 10 Functional Specification with Use Cases
11. 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!
©Dr. Amir Tomer 11 Functional Specification with Use Cases
12. 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
– …
©Dr. Amir Tomer 12 Functional Specification with Use Cases
13. 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
©Dr. Amir Tomer 13 Functional Specification with Use Cases
14. 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
©Dr. Amir Tomer 14 Functional Specification with Use Cases
15. 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.
©Dr. Amir Tomer 15 Functional Specification with Use Cases
16. 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
©Dr. Amir Tomer 16 Functional Specification with Use Cases
17. 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
©Dr. Amir Tomer 17 Functional Specification with Use Cases
18. • 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
©Dr. Amir Tomer 18 Functional Specification with Use Cases
19. 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?
©Dr. Amir Tomer 19 Functional Specification with Use Cases
20. 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
©Dr. Amir Tomer 20 Functional Specification with Use Cases
21. 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
©Dr. Amir Tomer 21 Functional Specification with Use Cases
22. 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!
©Dr. Amir Tomer 22 Functional Specification with Use Cases
23. 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
©Dr. Amir Tomer 23 Functional Specification with Use Cases
24. 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
©Dr. Amir Tomer 24 Functional Specification with Use Cases
25. 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
©Dr. Amir Tomer 25 Functional Specification with Use Cases
26. 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”
©Dr. Amir Tomer 26 Functional Specification with Use Cases
27. 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”
©Dr. Amir Tomer 27 Functional Specification with Use Cases
28. Exercise 4 – Pre- & Post- Conditions
• Regarding the 3 parking payment system’s use cases
– System Installation
– Parking Payment
– System Admin. & Maintenance
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?
©Dr. Amir Tomer 28 Functional Specification with Use Cases
29. 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”
©Dr. Amir Tomer 29 Functional Specification with Use Cases
30. 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
©Dr. Amir Tomer 30 Functional Specification with Use Cases
31. 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…”
©Dr. Amir Tomer 31 Functional Specification with Use Cases
32. 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?
©Dr. Amir Tomer 32 Functional Specification with Use Cases
33. 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
©Dr. Amir Tomer 33 Functional Specification with Use Cases
34. 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
©Dr. Amir Tomer 34 Functional Specification with Use Cases
35. “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
©Dr. Amir Tomer 35 Functional Specification with Use Cases
36. 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
©Dr. Amir Tomer 36 Functional Specification with Use Cases
37. “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
©Dr. Amir Tomer 37 Functional Specification with Use Cases
38. 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
©Dr. Amir Tomer 38 Functional Specification with Use Cases
39. 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!
©Dr. Amir Tomer 39 Functional Specification with Use Cases
40. 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
©Dr. Amir Tomer 40 Functional Specification with Use Cases
41. Exercise 6 – Non-Functional Requirements
• Regarding the 3 parking payment system use cases
– System Installation
– Parking Payment
– System Admin. & Maintenance
• Suggest NFRs (quality attributes) which might be associated with
each use-case, for consideration during its implementation
©Dr. Amir Tomer 41 Functional Specification with Use Cases
42. 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.)
©Dr. Amir Tomer 42 Functional Specification with Use Cases
43. 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
©Dr. Amir Tomer 43 Functional Specification with Use Cases
44. 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
©Dr. Amir Tomer 44 Functional Specification with Use Cases
45. 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
©Dr. Amir Tomer 45 Functional Specification with Use Cases
46. 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
©Dr. Amir Tomer 46 Functional Specification with Use Cases
47. 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
©Dr. Amir Tomer 47 Functional Specification with Use Cases
48. “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)
©Dr. Amir Tomer 48 Functional Specification with Use Cases
49. 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)
©Dr. Amir Tomer 49 Functional Specification with Use Cases
50. 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…
©Dr. Amir Tomer 50 Functional Specification with Use Cases
51. 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
©Dr. Amir Tomer 51 Functional Specification with Use Cases
52. 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
©Dr. Amir Tomer 52 Functional Specification with Use Cases
53. 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
©Dr. Amir Tomer 53 Functional Specification with Use Cases
54. 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»
©Dr. Amir Tomer 54 Functional Specification with Use Cases
55. 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
©Dr. Amir Tomer 55 Functional Specification with Use Cases
56. 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»
©Dr. Amir Tomer 56 Functional Specification with Use Cases
57. 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
©Dr. Amir Tomer 57 Functional Specification with Use Cases
58. 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»
מפקד חתרנית
מערכת חתרנית - מצב מבצעי
הכנה לפעולה
ביצוע משימת סריקה
העברת פקודה
תכנון מבצע
מפעיל חולד
ביצוע משימת מילכוד
ביצוע משימת טיהור
איתחול חולד
ביצוע השמדת חולד
מפקדה ממונה
קבלת דיווח ע"פ
סיום מבצע
דרישה
הקצאת משימות
©Dr. Amir Tomer 58 Functional Specification with Use Cases
מודיעין
מבצעים
בטיחות
«include»
«extend»
«extend»
«extend»
«has_interest»
«include»
«has_interest»
«has_interest»
«has_interest»
59. 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
©Dr. Amir Tomer 59 Functional Specification with Use Cases
60. 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
©Dr. Amir Tomer 60 Functional Specification with Use Cases
61. 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)
©Dr. Amir Tomer 61 Functional Specification with Use Cases
62. 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
©Dr. Amir Tomer 62 Functional Specification with Use Cases
63. 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»
רשת
פנימית
כרטיס
חיישנים
1.. מחשב חולד 8
«delegate»
תנועה
©Dr. Amir Tomer 63 Functional Specification with Use Cases
מנגנון
תנועה
מנגנון
ירי
מנגנון
מיקוש
מנגנון
השמדה
חישה
תפעול
ירי
תפעול
מיקוש
תפעול
השמדה
תמונות
ומסלולים
תוכנת חולד
פיקוד
חולד
חישה
ניווט חולד
ניהוג ידני
«delegate»
«delegate»
בקרת
תנועה
«delegate»
«delegate»
«delegate»
«delegate»
«delegate»
Software-level
Use-cases
64. 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
©Dr. Amir Tomer 64 Functional Specification with Use Cases
65. 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
©Dr. Amir Tomer 65 Functional Specification with Use Cases
66. 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)
©Dr. Amir Tomer 66 Functional Specification with Use Cases
67. 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!
©Dr. Amir Tomer 67 Functional Specification with Use Cases
68. 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
©Dr. Amir Tomer 68 Functional Specification with Use Cases
69. 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.
©Dr. Amir Tomer 69 Functional Specification with Use Cases
70. 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
©Dr. Amir Tomer 70 Functional Specification with Use Cases
71. 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)
©Dr. Amir Tomer 71 Functional Specification with Use Cases
72. 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
©Dr. Amir Tomer 72 Functional Specification with Use Cases
73. That’s all folks!
Thank you for attending.
Keep in touch!
©Dr. Amir Tomer 73 Functional Specification with Use Cases
75. Use Case Diagram – חתרנית
מפקד חתרנית
מערכת חתרנית - מצב מבצעי
הכנה לפעולה
ביצוע משימת סריקה
העברת פקודה
תכנון מבצע
מודיעין
«has_interest»
מפעיל חולד
ביצוע משימת מילכוד
ביצוע משימת טיהור
איתחול חולד
«include»
«extend»
ביצוע השמדת חולד
מפקדה ממונה
קבלת דיווח ע"פ
«include»
סיום מבצע
דרישה
הקצאת משימות
מבצעים
«has_interest»
בטיחות
«extend»
«extend»
«has_interest»
«has_interest»
©Dr. Amir Tomer 75 Functional Specification with Use Cases
76. חתרנית – ארכיטקטורה מערכתית
רשת
טקטית
תצוגת
מפקד
תצוגת
מפעיל
[1..8]
פיקוד
מפקד
פיקוד
מפעיל
[1..8]
רשת
פנימית
רשת
פנימית
מחשב שו"ב
מנגנון
תנועה
כרטיס
חיישנים
«delegate»
תנועה
חישה
«delegate»
«delegate»
חישה
תפעול
ירי
«delegate»
מנגנון
ירי
1.. מחשב חולד 8
תוכנת ניווט
בקרת
תנועה
תוכנת חולד
תפעול
מיקוש
«delegate»
מנגנון
מיקוש
תפעול
השמדה
«delegate»
מנגנון
השמדה
אגירת
תמונות
ומסלולים
פיקוד
חולד
פיקוד
עליון
«delegate»
«delegate»
תוכנת שו"ב תצוגות
פיקוד
«delegate»
יצירת מפות
עיבוד תמונה
ניהוג ידני
«delegate»
תמונות
ומסלולים
פיקוד
חולד
«delegate»
«delegate»
«delegate»
«delegate»
«delegate»
«delegate»
©Dr. Amir Tomer 76 Functional Specification with Use Cases
77. לתוכנת חולד )א( UCD – חתרנית
ניהול ובקרת משימות
תוכנת חולד
הגדרת משימה
שינוי משימה
הפסקת משימה
ביצוע משימת סריקה
ביצוע משימת טיהור
ביצוע משימת מילכוד
ביצוע השמדת חולד
כרטיס חיישנים
מנגנון ירי
מנגנון מיקוש
<<CSCI>> ב"וש
מנגנון השמדה
«extend»
«extend»
«extend»
אדמיניסטרציה תנועה במנהרה
©Dr. Amir Tomer 77 Functional Specification with Use Cases
78. לתוכנת חולד )ב( UCD – חתרנית
תנועה במנהרה
תוכנת חולד
תנועה בניווט
אוטונומי
תנועה במסלול נתון
תנועה בניהוג ידני
אדמיניסטרציה ניהול ובקרת משימות
כרטיס חיישנים
<<CSCI>> דלוח טווינ
<<CSCI>> ב"וש
אדמיניסטרציה
תוכנת חולד
איתחול חולד
העברת נתונים לשו"ב
כיבוי חולד
«i ncl ude»
BIT עוציב
ניהול ובקרת משימות תנועה במנהרה
<<CSCI>> ב"וש
©Dr. Amir Tomer 78 Functional Specification with Use Cases
79. לתוכנת שו"ב )א( UCD – חתרנית
תוכנת שו"ב
תכנון ובקרה
עריכת תוכנית
מבצע
פיקוד עליון
סיום מבצע
הקצאת
משימות
מפעיל חולד מפקד חתרנית
השתלטות על
מפעיל
בקרת משימה
העברת מידע
וסטטוס
אדמיניסטרציה
<<CSCI>> דלוח
<<CSCI>> תנומת תיינב
מנהרה
©Dr. Amir Tomer 79 Functional Specification with Use Cases
80. לתוכנת שו"ב )ב( UCD – חתרנית
תוכנת שו"ב
פיקוד עליון
העברת פקודת
מבצע
הפסקת מבצע
שינוי מטרת
מבצע
אדמיניסטרציה
מפקד חתרנית מפקדה ממונה
קבלת דיווח ע"פ
דרישה
דיווח סיום
מבצע
תכנון ובקרה
תוכנת שו"ב
אדמיניסטרציה
איתחול מערכת
«include»
הכנה להמתנה
למבצע
מפקד חתרנית
1..8
1..8
מפעיל חולד
פיקוד עליון תכנון ובקרה
©Dr. Amir Tomer 80 Functional Specification with Use Cases
Hinweis der Redaktion הגדרת דרישות הגדרת דרישות הגדרת דרישות ניתוח דרישות וארכיטקטורת מערכת