This document discusses software modeling from a system perspective. It defines key concepts such as a system, system element, and block. A system is composed of interacting elements organized to achieve a purpose. A system element may itself be a system or an atomic entity. The document recommends using unified modeling concepts like "block" to represent a system, subsystem, component or other entity. It presents different modeling views including context, services, structure and behavior, and discusses modeling techniques like use case diagrams, activity diagrams and more.

1. Software Modeling from System Perspective
Prof. Dr. Amir Tomer, CSEP
Head, Dept. of Software Engineering
Achi Racov Engineering Schools
Kinneret Academic College on the Sea of Galilee, Israel
amir@amirtomer.com
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 1
Hallo Bayern
Studenten!
Wir warten auf
euch in Kinneret

2. “System” – a recursive-hierarchical Structure*
*ISO/IEC/IEEE 15288
system
element
system
element
system
element
system
system
element
system
element
system
element
system
element
system
element
systemsystemsystem
system
element
system
element
system
system
element
system
element
system
element
system
elementsystemsystem
system-of-interest
     
Hierarchy
(The depth of the hierarchy
depends on the scope of
interest)
Recursion
A system is comprised
of systems
(and elements)
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 2

3. Properties of a System
• System – Definition*
– combination of interacting elements organized to achieve one or more
stated purposes
• Thus, each system has the following properties
– Purpose(s)
– Elements
– Interaction (among its elements)
– Organization (over its elements)
• System Element – Definition*
– member of a set of elements that constitutes a system
• Thus, according to the recursive-hierarchical structure, a system element may
be either
– A system by itself – possessing all system properties
– An elementary (atomic) entity – possessing just purpose(s)
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 3
*ISO/IEC/IEEE 15288

4. “Block” – a unified notion
• In order to obtain unified modeling concepts for systems and elements at all
levels
– i.e. System-of-system, system, subsystem, assembly, component, unit, etc.
we define a unified entity, noted as “Block”, as follows:
1. A system is a block
2. A system is composed of one or more blocks
3. An element (system element) is a block, which is atomic (non-decomposable)
4. Every block has one or more purposes
5. A system has an organization (over its blocks)
6. A system has an interaction (among its blocks)
Based on the “composition” design pattern: Vlissingen et al, Design Patterns, 1994
1
2
3
4
5
6
<<abstract>>
Block
+ Purpose [1...*]
System
- organization
- interaction
Element
1..*
Legend
inheritance relation
composition relation
+ P public property
- P private property
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 4

5. System in its Environment*
Enabling
System A
Enabling
System B
Enabling
System CInteraction with enabling
systems, usually in other
life-cycle stages rather
than operation
System of
Interest
System B in
Operational
Environment
System A in
Operational
Environment
System C in
Operational
Environment
Interaction with systems
comprising the
operational environment
Interaction with
Users / Operators
Stakeholders
Have no interaction but impose
needs, constraints and interests
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 5
*ISO/IEC/IEEE 15288

6. Model-Based Systems Engineering (MBSE)
• Model-based systems engineering (MBSE) is the formalized
application of modeling to support system requirements, design,
analysis, verification and validation activities beginning in the
conceptual design phase and continuing throughout development
and later life cycle phases
[INCOSE]
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 6

7. The Concept of “Modeling”
• What is Modeling?
– A means to capture ideas, relationships, decisions and requirements in a well-
defined notation that can be applied to many different domains
[Pilone, D., UML 2.0 in a Nutshell, O’REILLY®, 2005
• Models are used for simplified and abstract description of complex entities
– Models focus on principle elements, leaving out unnecessary details
– Models need to be “translated” into the real world
– A model leaves degrees of freedom to different interpretations
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 7

8. Static and Dynamic Models
• Static / Structural Model
– A model describing entities with relations among them
• Organizational chart
• Mechanical drawing
• Molecular structure
• Database table
• Dynamic / Behavioral Model
– A model describing flow / changes along time
• Flowchart
• Graphical representation of a time function
• Automaton (in Computer Science)
• Animation / Simulation
• A model may be visual, textual or combined
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 8

9. The Use of Modeling
• Modeling is useful in two directions
– Forward Modeling: Modeling before implementation
• Sketching new ideas
• Brainstorming about solutions
• Evaluating solution alternatives
• Directing the development
– Reverse Modeling: Modeling after implementation
• Documenting the system “as built”
• Explaining the system to others
• Supporting system production / maintenance / upgrading
• Reusing as forward modeling in future projects
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 9

10. The 4 Modeling Views of a “Block”
Context
The location of the block in its
environment and the
connection points (interfaces)
between the block and its
external entities
Services (Functions)
The provided/acquired services
(functions) to/from external
entities and the way these
services are obtained
Structure*
The elements comprising
the block and their
interrelations
Behavior
The activities the block needs to
perform in order to provide its
services
Static Viewpoint Dynamic Viewpoint
External
Viewpoint
(Black Box)
Internal
Viewpoint
(White Box)
purpose
Interaction*Organization
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 10
Environment
*Compound block only!

11. “Business”
5 “Levels of Interest” of Software-Intensive System Modeling
• The general definition of a “system” allows unlimited depth of hierarchical breakdown
– Although this is applicable also for SWISs, there are 5 typical levels, for which certain model types
are preferred for the sake of modeling effectiveness
Software Intensive System (SWIS)
Hardware Platforms & Devices
(Hardware Configuration Items = HWCIs)
These will be considered as either:
- atomic elements
- SWISs, requiring further breakdown
Software Applications
Software Components
Software Units
Humans
Equipment
Users and other Stakeholders
Other SWISs
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 11
See details in the complementary slides

12. UML Modeling
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 12

13. Which Models to Use?
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 13

14. Case Study: Car Navigation System
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 14

15. Smartphone – Physical Interfaces
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 15

16. Smartphone Navigation Application – Functional Interfaces
?
Provided
Interfaces
Required
Interfaces
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 16

17. Modeling the Purpose and the Environment
• The purpose and the environment of a block are best modeled by Use-
Case Model, comprising
– Use Case Diagram (overview)
• Actors
• Services
• Actor/Service relation
– Use-Case Specification (each use-case)
• Pre-conditions
• Post-conditions
• Trigger
• Main Success Scenario
• Alternative (success) scenarios
• Exception (failure) scenarios
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 17
Context Services
Structure Behavior
Static Dynamic
External
Internal
Static
Model
Dynamic
Model

18. Car Navigation System
Define Trip
Locate Self
Send Report
Driver
Navigate along
Route
Maps Provider
Get Map
Get Road Status
GPS
Deviation from
Route
Reports Provider
Calculate Route
Auto-report
«include»
«include»
«include»
«include»
«include»
«include»
«extend»
«include»
Use Case Diagram (Static/Contextual Model)
• Who is the actor of “Auto-report”?
• Where are the non-actor stakeholders?
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 18
Other
Drivers
<<satisfy>>
?

19. Use-Case Specification (Dynamic/Beavioural)
UC-1 Define Trip
Actors & Goals Driver – PA: Defining a new trip and select a route
GPS – SA: provides self location (via included UC " Locate Self ")
Map Provider – SA: Provides updated map (via inc. UC "Get Map")
Report Provider – SA: Provides updated road status (via inc. UC "Get Road Status")
Other Stakeholders System Providers: User Satisfaction (usability, performance, reliability, availability)
Pre-conditions  System is operational
 A "Define Trip" option is available for the driver
Post-Conditions 1-3 possible routes are displayed over a map on the screen, with the recommended
one highlighted
Trigger The driver selects the Define Trip option
Main Success Scenario
(MSS)
1. The system prompts the driver for origin (O)
2. The driver enters a partial address (textually or vocally)
3. The system suggests possible addresses
4. The driver makes a selection
5. The system retrieves and displays a map (size TBD) around O
6. The system prompts the driver for destination (D)
7. The driver enters a partial address (textually or vocally)
8. The system suggests possible addresses
9. The driver makes a selection
10. The system calculates 1-3 possible routes from O to D
11. The system retrieves and displays a map on the screen, containing O and D
12. The system displays the suggested routes over the map on the screen, with the
recommended route highlighted
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 19

20. Use-Case Specification (Dynamic/Beavioural) – cont.
Branch A Alternative in step 2 of MSS: The driver points at the origin on the screen
Continue from step 5
Branch B Alternative in step 2 of MSS: The driver requests the list of saved locations
3B1. The system retrieves and displays the list saved location
3B2. The driver selects a saved location from the list
Continue from step 5
Branch C Alternative in step 2 of MSS: The driver requests O to be the current location
3C1. The system locates the car (using inc. UC "Locate Self")
Continue from step 5
Branch D Alternative in step 7 of MSS: The driver points at the destination on the screen
Go to step 10
Branch E Exception in step 5 or 11 of MSS: A map is not available
5E1/11E1. The system notifies the driver for map unavailability
Scenario terminates
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 20

21. Which Static (Structural) Model to Choose?
• The guiding question: What do you want to show
– Hardware architecture and physical interfaces
• Deployment Diagram
– Software architecture and logical/functional/data
interfaces
• Component Diagram
– Containment/allocation structure at various levels
(e.g. HW/SW)
• Composite Structure Diagram
– Object-oriented software structure
• Class Diagram
– Development effort allocation
and mutual dependencies
• Package Diagram
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 21
Context Services
Structure Behavior
Static Dynamic
External
Internal

22. Car Navigation System – Hardware Architecture
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 22
«Processor»
Smartphone
«artifact»
GPS.dll
«artifact»
Navigation app
GPS sattelite
Navigation Server
«artifact»
Maps DB
«artifact»
Repors DB
Reports
Provider
Maps
Provider
«device»
Hand-free
«artifact»
RouteFinder app
«device»
Touch Screen
«device»
Microphone
«device»
Keys
1..*
internet
1..*internet
1..*
3..*
GPS signals bluetooth 0..1
0..*
internet
1..*

23. Car Navigation Application – Software Architecture
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 23
Route Tracker
GPS Signals
GPS.dll
GPS Signals
Graphic
display
Display
Graphic
display
User interface
"Touch"
oprations
Key
presses
Vocal
commands
Reports upload
Reporting
Reports upload
Maps & reports
download
Arena
Management
Maps & reports
download
Vocal
directions
Voice Directions
Vocal
directions
Driving
directions
Maps & reports
retrieval
User
reports
User
commands
Display
updates
Car location

24. Combined SW/HW Architecture
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 24
GPS
Bluetooth Touch Screen Microphone
Internet
Keys
«processor»
Smartphone
GPS
Bluetooth Touch Screen Microphone
Internet
Keys
Route Tracker
GPS Signals
GPS.dll
GPS Signals
Graphic
display
Display
Graphic
display
User interface
"Touch"
oprations
Key
presses
Vocal
commands
Reports upload
Reporting
Reports upload
Maps & reports
download
Route Request
Arena
Management
Maps & reports
download
Route Request
Vocal
directions
Voice Directions
Vocal
directions
Car location
Display
updates
User
commands User
reports
Maps & reports
retrieval
Driving
directions
«delegate»
«delegate» «delegate»
«delegate»
«delegate»
«delegate»
«delegate»
«delegate»
«delegate»

25. Object-Oriented Software Design (Partial Class Diagram)
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 25
Report
- Source :user
- Type :{police, accident, jam}
Coordinate
- Lattitude :int
- Longitude :int
+ setFromGPS() :void
Location
- Name :string
Route
- Destination :Coordinate
- Source :Coordinate
- addPoint(P :Coordinate) :void
- removePoint() :void
+ setDestination(C :Coordinate) :void
+ setSource(C :Coordinate) :void
Map
+ displayOnScreen(upperRight :Coordinate, bottomLeft :Coordinate) :void
+ updateFromServer() :void
PointOfInterest
- Type :{gasStation, restaurant, ATM}
Background
1
0..1
1
2..*
0..*

26. Which Dynamic (Behavioural) Model?
• The guiding questions:
– Monolithic or compound entity?
– Structure maturity
– The nature of block control
Block Type
Control Nature
State Machine
Activity Diagram
Without
swim lanes
Activity Diagram
with swim lanes
Structure
Maturity
Sequence
Diagram
Event-
driven
Compound
Flow-
driven
Abstract
(e.g. logical)
Concrete
(e.g. physical
Monolithic
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 26
Context Services
Structure Behavior
Static Dynamic
External
Internal

27. Activity Diagrams without Swim Lanes
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 27
Get Destination
from User
Get Location
from GPS
Calculate
Route
Get Location
from GPS
On Route?
Display Route
on Map
End of Route?
End trip
Notify User
Start new Trip
[no]
[yes]
[no]
[yes]

28. Example of Activity Diagrams with Swim Lanes
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 28
Get Destination
from User
Get Location
from GPS
Calculate
Route
Get Location
from GPS
On Route?
Display Route
on Map
End of Route?
End trip
Notify User
Start new Trip
[no]
[no]
[yes]
[yes]
Smartphone Nav. Service

29. A Dynamic (Behaviour) Model at the SW Application Level
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 29
Driver
User interface Route Tracker Arena
Management
Navigation Server
Display GPS.dll
opt
[missing map area]
loop
[while Active(ON) & not arrived]
opt
[off route]
par
[seq1]
[seq2]
KeyPress("Start Navigation")
Active(ON)
GetDefinedRoute()
DefineArea()
GetMap(Area) :Map
MapDownload(Area) :Map
DisplayMap()
DisplayRoute()
GetCurrentLocation() :Location
DisplayLocation()
ReCalculateRoute(location)
KeyPress("StopNavigation")
Active(OFF)
Larger
SW Arch.
components
This is a UC-Scenario for the “Route
Tracker” Component
This is a
realization
of a
system-
level UC
scenario

30. Structural/Behavioural Consistency between Models
• B provides a service to A,
using a sub-service required from C
BA C
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 30

31. To Summerize
• Software modeling is required for various levels of the system
design
• Properties of good models (at every level):
– Proper level of abstraction
– Correctness
– Completeness
– Consistency!
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 31

32. Thank you for listening!
Any questions?
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 32

33. Complementary Slides
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 33

34. The Business Level
• A Business is an organization providing benefits for its users and other stakeholders
– E.g. A cellular communication provider
“Business”
Software Intensive System (SWIS)
humans
Equipment
Users and
other Stakeholders
Other SWISs
View Content Examples
Services
(purposes)
Interactions with users and
other stakeholders
connecting people, debiting credit cards
Environment Access points to the business placing calls, approaching a service center
Structure Elements
• SWISs
• Equipment
• People
Organization
cell phone system, IS, website
cars, furniture, buildings
salespersons, technicians
communication links, HMI
Behavior Business processes Connecting phone users
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 34

35. The Software Intensive System (SWIS) Level
• A SWIS is a computerized system, constitutes of hardware and software ONLY
– E.g. The cell communication system
View Content Examples
Services
(purposes)
Interactions with humans,
equipment and other SISs
making calls, sending SMS, supporting technical
maintenance
Environment Access points to the system phones, internet access, …
Structure Elements
• Hardware
• Software
Organization
Computers, storage, peripherals
Software applications
network, cables, bluetooth
Behavior System Processes E.g. carrying a call between subscribers
Software Intensive System (SWIS)
HW PlatformsSW Applications
Humans
Equipment
Other SWISsExternal to the organization = users
Internal to the organization = operators
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 35

36. The Application Level
• An application is an aggregation of software that provides a set of end use functions
– E.g. The cellphone’s phone-call software
View Content Examples
Services
(purposes)
End use functions placing calls, receiving calls, sending SMS
Environment Commands, data and signals
via hardware ports
Receive/Transmit messages, touch screen
Structure Elements
Software Components
Organization
SW-SW communication
Rx/Tx drivers, GUI, DLLs, …
message passing, internal mailboxes
Behavior Algorithms/Procedures Dial-send-connect-talk-hangup
SW Applications
SW Components
HW Devices
Other SW
Applications
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 36

37. The Software Component Level
• A SW Component is a (physical) piece of software that provides a set of defined functions
– E.g. The cellphone GUI
View Content Examples
Services
(purposes)
Defined functions Edit a number, search a contact
Environment Function calls, data messages send(“0598732567”), display(contact)
Structure Elements
Software units
Organization
Program structure, API
Classes, blocks, procedures
Behavior Execution threads
SW Component
SW Units
HW Devices
Other SW
Components
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 37

38. The Software Unit Level
• A SW Unit is a piece of code, implementing certain function(s), usually
constructed and tested by a single programmer
– E.g. The dialing dialog box
View Content Examples
Services
(purposes)
Defined functions
Environment function(X,Y,Z)
Structure Code structure
Behavior Code flow
SW Unit Other SW
Units
©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 38

39. ©Prof.Dr.AmirTomer
Bavarian University Visits, June 2015 39
Driver
User interface Route Tracker Arena
Management
Navigation Server
Display GPS.dll
opt
[missing map area]
loop
[while Active(ON) & not arrived]
opt
[off route]
par
[seq1]
[seq2]
KeyPress("Start Navigation")
Active(ON)
GetDefinedRoute()
DefineArea()
GetMap(Area) :Map
MapDownload(Area) :Map
DisplayMap()
DisplayRoute()
GetCurrentLocation() :Location
DisplayLocation()
ReCalculateRoute(location)
KeyPress("StopNavigation")
Active(OFF)