Swis modeling
Download as PPTX, PDF1 like783 views
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.
![“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](https://image.slidesharecdn.com/swis-modeling-150704061749-lva1-app6891/85/Swis-modeling-4-320.jpg)
![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](https://image.slidesharecdn.com/swis-modeling-150704061749-lva1-app6891/85/Swis-modeling-6-320.jpg)
![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]](https://image.slidesharecdn.com/swis-modeling-150704061749-lva1-app6891/85/Swis-modeling-27-320.jpg)
![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](https://image.slidesharecdn.com/swis-modeling-150704061749-lva1-app6891/85/Swis-modeling-28-320.jpg)
![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](https://image.slidesharecdn.com/swis-modeling-150704061749-lva1-app6891/85/Swis-modeling-29-320.jpg)
![©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)](https://image.slidesharecdn.com/swis-modeling-150704061749-lva1-app6891/85/Swis-modeling-39-320.jpg)
Swis modeling
- 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 [email protected] ©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)