Software Modeling from System Perspective

Prof. Dr. Amir Tomer, CSEPHead, Dept. of Software Engineering

Achi Racov Engineering SchoolsKinneret Academic College on the Sea of Galilee, Israel

amir@amirtomer.com

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 1

Hallo Bayern

Studenten!

Wir warten auf euch

in Kinneret

“System” – a recursive-hierarchical Structure*

*ISO/IEC/IEEE 15288

system element

system element

system element

systemsystem 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)

RecursionA system is comprised

of systems(and elements)

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 2

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)©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 3

*ISO/IEC/IEEE 15288

“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

56

<<abstract>>Block

+ Purpose [1...*]

System

- organization- interaction

Element

1*..

Legend inheritance relation composition relation+ P public property- P private property

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 4

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 withUsers / Operators

Stakeholders

Have no interaction but impose needs, constraints and interests

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 5

*ISO/IEC/IEEE 15288

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]

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 6

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

H2O

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 7

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

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 8

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

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 9

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 comprisingthe block and their

interrelations

Behavior

The activities the block needs to perform in order to provide its

services

Static Viewpoint Dynamic Viewpoint

ExternalViewpoint

(Black Box)

InternalViewpoint

(White Box)

purpose

Interaction*Organization

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 10

Environment

*Compound block only!

“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

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 11

See details in the complementary slides

UML Modeling

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 12

Which Models to Use?

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 13

Case Study: Car Navigation System

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 14

Smartphone – Physical Interfaces

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 15

Smartphone Navigation Application – Functional Interfaces

?

ProvidedInterfaces

RequiredInterfaces

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 16

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

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 17

Context Services

Structure Behavior

Static Dynamic

External

Internal

StaticModel

DynamicModel

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?©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 18

OtherDrivers

<<satisfy>>?

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 addresses4. The driver makes a selection5. The system retrieves and displays a map (size TBD) around O6. The system prompts the driver for destination (D)7. The driver enters a partial address (textually or vocally)8. The system suggests possible addresses9. The driver makes a selection10. 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 D12. The system displays the suggested routes over the map on the screen, with the

recommended route highlighted

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 19

Use-Case Specification (Dynamic/Beavioural) – cont.

Branch A Alternative in step 2 of MSS: The driver points at the origin on the screenContinue from step 5

Branch B Alternative in step 2 of MSS: The driver requests the list of saved locations3B1. The system retrieves and displays the list saved location3B2. The driver selects a saved location from the listContinue from step 5

Branch C Alternative in step 2 of MSS: The driver requests O to be the current location3C1. 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 screenGo 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

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 20

Bavarian University Visits, June 2015 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 allocationand mutual dependencies

• Package Diagram

©

Pro

f. D

r. A

mir

Tom

er

Context Services

Structure Behavior

Static Dynamic

External

Internal

Car Navigation System – Hardware Architecture

©

Pro

f. D

r. A

mir

Tom

er

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..*internet1..*internet1..*

3..*GPS signals bluetooth 0..1

0..*

internet

1..*

Car Navigation Application – Software Architecture

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 23

Route Tracker

GPS Signals

GPS.dll

GPS Signals

Graphicdisplay

Display

Graphicdisplay

User interface

"Touch"oprations

Keypresses

Vocalcommands

Reports upload

Reporting

Reports upload

Maps & reportsdownload

Arena Management

Maps & reportsdownload

Vocaldirections

Voice Directions

Vocaldirections

Driv ingdirections

Maps & reportsretriev al

Userreports

Usercommands

Displayupdates

Car location

Combined SW/HW Architecture

©

Pro

f. D

r. A

mir

Tom

er

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

Graphicdisplay

Display

Graphicdisplay

User interface

"Touch"oprations

Keypresses

Vocalcommands

Reports upload

Reporting

Reports upload

Maps & reportsdownload

Route Request

Arena Management

Maps & reportsdownload

Route Request

Vocaldirections

Voice Directions

Vocaldirections

Car location

Displayupdates

Usercommands User

reports

Maps & reportsretriev al

Driv ingdirections

«delegate»«delegate» «delegate»

«delegate»

«delegate»

«delegate»

«delegate»

«delegate»

«delegate»

Object-Oriented Software Design )Partial Class Diagram(

©

Pro

f. D

r. A

mir

Tom

er

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..*

Which Dynamic (Behavioural) Model?

• The guiding questions:– Monolithic or compound entity?

– Structure maturity

– The nature of block control

Block Type

Control Nature

State MachineActivity Diagram

Withoutswim lanes

Activity Diagramwith swim lanes

StructureMaturity

SequenceDiagram

Event-driven

Compound

Flow-driven

Abstract(e.g. logical)

Concrete(e.g. physical

Monolithic

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 26

Context Services

Structure Behavior

Static Dynamic

External

Internal

Activity Diagrams without Swim Lanes

©

Pro

f. D

r. A

mir

Tom

er

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]

Example of Activity Diagrams with Swim Lanes

©

Pro

f. D

r. A

mir

Tom

er

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

A Dynamic )Behaviour( Model at the SW Application Level

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 29

Driver

User interface Route Tracker ArenaManagement

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

Structural/Behavioural Consistency between Models

• B provides a service to A,using a sub-service required from C

B

Serv ice

A C

A B CL1 L2

BA C

L1L2

L1L2

b :B

«delegate»«delegate»

B

+ service() :void

void service( ){ ... call C.ext_service( ) ...}

A C

+ ext_service() :void

a :A b :B c :C

1.0 service()

1.1 ext_service()

1.2

1.3

BA C

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 30

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!

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 31

Thank you for listening!

Any questions?

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 32

Complementary Slides

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 33

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

EquipmentUsers 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, websitecars, furniture, buildingssalespersons, technicians

communication links, HMIBehavior Business processes Connecting phone users

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 34

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, peripheralsSoftware applications

network, cables, bluetoothBehavior System Processes E.g. carrying a call between subscribers

Software Intensive System (SWIS)

HW PlatformsSW ApplicationsHumans

Equipment

Other SWISsExternal to the organization = users

Internal to the organization = operators

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 35

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 ElementsSoftware Components

OrganizationSW-SW communication

Rx/Tx drivers, GUI, DLLs, …

message passing, internal mailboxesBehavior Algorithms/Procedures Dial-send-connect-talk-hangup

SW Applications

SW ComponentsHW Devices Other SW

Applications

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 36

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 ElementsSoftware units

OrganizationProgram structure, API

Classes, blocks, procedures

Behavior Execution threads

SW Component

SW UnitsHW Devices Other SW

Components

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 37

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 SWUnits

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 38

©

Pro

f. D

r. A

mir

Tom

er

Bavarian University Visits, June 2015 39

Driver

User interface Route Tracker ArenaManagement

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)