1. 1. Software Intensive Systems Modeling A Methodological Approach for MBD Dr. Amir Tomer, PMP, CSEP, CSQE Head, Software Engineering Department Kinneret Academic College on the Sea of Galilee, Jordan Valley, Israel amir@amirtomer.com Dr. Amir Tomer, Kinneret College 1 Software Intensive Systems Modeling
2. 2. Motivation The quality of a product depends much on the quality of its requirement and design specifications Missing, vague or sloppy specifications lead to wrong implementation, inaccurate testing and poor product usability Modeling techniques and languages are increasingly used for software engineering, replacing textual specifications with visual ones However In many software-intensive systems, modeling is not applied properly, according to Lack of modeling methodology Complexity of languages and tools Inconsistencies between development levels Particularly between the system and the software level Dr. Amir Tomer, Kinneret College Software Intensive Systems Modeling2
3. 3. Our Approach We propose a methodological approach to software-intensive system modeling, which provides Systematic modeling for all system breakdown levels Consistency within and between system and software level models Simple and just enough application of modeling elements (UML/SysML) Dr. Amir Tomer, Kinneret College Software Intensive Systems Modeling3
4. 4. 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) Dr. Amir Tomer, Kinneret College 4 Software Intensive Systems Modeling
5. 5. 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) *ISO/IEC/IEEE 15288 Dr. Amir Tomer, Kinneret College 5 Software Intensive Systems Modeling
6. 6. 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 Block + Purpose [1...*] System - organization - interaction Element 1..* Legend inheritance relation composition relation + P public property - P private property Dr. Amir Tomer, Kinneret College 6 Software Intensive Systems Modeling
7. 7. The Four Views of a Block (System/Element) Environment 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 (non-atomic blocks only ) 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 Dr. Amir Tomer, Kinneret College 7 Software Intensive Systems Modeling
8. 8. A Systematic Systems Engineering Process (SEP)* * Systems Engineering Fundamentals, DOD, 2001 and IEEE-Std-1220 Dr. Amir Tomer, Kinneret College 8 Software Intensive Systems Modeling
9. 9. Modeling in the Requirements Analysis Phase Requirements Analysis Analyze Missions and Environments Identify Functional Requirements Define/Refine Performance and Design Constraint Requirements Environment Services Structure Behavior Static Dynamic External Internal Functional Requirements Design Constraints And non-functional requirements Dr. Amir Tomer, Kinneret College 9 Software Intensive Systems Modeling
10. 10. Modeling in the Functional Analysis Phase Functional Analysis Decompose to Lower-Level Functions Allocate Performance and Other Limiting Requirements to All Functional Levels Define/Refine Functional Interfaces (Internal/External) Define/Refine/Integrate Functional Architecture Environment Services Logical Structure Physical Logical Behavior Physical Static Dynamic External Internal Functional (Logical) Design Dr. Amir Tomer, Kinneret College 10 Software Intensive Systems Modeling
11. 11. Modeling in the Design Synthesis Phase Design Synthesis Transform Architectures (Functional to Physical) Define Alternative System Concepts, Configuration Items and System Elements Select Preferred Product and Process Solutions Define/Refine Physical Interfaces (Internal/External) Environment Services Logical Structure Physical Logical Behavior Physical Static Dynamic External Internal Physical Design (Architecture) Subject to design constraints And other non-functional requirements Dr. Amir Tomer, Kinneret College 11 Software Intensive Systems Modeling
12. 12. From Block to Sub-Block Modeling The requirements of a sub-blocks are directly derived from the parent-blocks design Environment Services Structure Behavior A-1 A-3 A-2 A-1 A-3 A-2 f f A-1 A-2A-3 Environment Services Structure Behavior Block A: Design Sub-Block A-3: Requirements Design constraints + non-functional requirements Dr. Amir Tomer, Kinneret College 12 Software Intensive Systems Modeling
13. 13. Business The Five Levels of Interest of a Software-Intensive System (SWIS) The general definition of a system allows unlimited depth of hierarchical breakdown Although this is applicable also for SWISs, there are 5 types of 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 (Computer SW Configuration Items = CSCIs) Computer Software Components (CSCs) Computer Software Units (CSUs) Humans Equipment Users and other Stakeholders Other SWISs Dr. Amir Tomer, Kinneret College 13 Software Intensive Systems Modeling
14. 14. Related Topics and Issues Choosing the right model for each view The use-case/state-machine/activity-diagram dillema Model consistency Between models on the same breakdown level Between breakdown levels Model verification Correctness, quality, applicability etc. Life-cycle architecture modeling Test architecture, production architecture, maintenance architecture, Balancing visual and textual specifications One picture vs. 1000 words Non-top-down engineering modeling (re-engineering, reverse engineering, ) Open-source style, unsynchronized system arrays Dr. Amir Tomer, Kinneret College Software Intensive Systems Modeling14
15. 15. Any questions? 15 Software Intensive Systems ModelingDr. Amir Tomer, Kinneret College amir@amirtomer.com 052-8890202