system model presentation

Chapter 5 – System Modeling

Jan 30, 2014

940 likes | 1.95k Views

Chapter 5 – System Modeling. Objectives The aim of this chapter is to introduce some types of system model that may be developed as part of the requirements engineering and system design processes. When you have read the chapter, you will:

Share Presentation

• behavioral models
• partial system implementation
• very unlikely
• requirements engineering
• mental healthcare

Presentation Transcript

Chapter 5 – System Modeling • Objectives • The aim of this chapter is to introduce some types of system model that may be developed as part of the requirements engineering and system design processes. When you have read the chapter, you will: • understand how graphical models can be used to represent software systems; • understand why different types of model are required and the fundamental system modeling perspectives of context, interaction, structure, and behavior; • have been introduced to some of the diagram types in the Unified Modeling Language (UML) and how these diagrams may be used in system modeling; • be aware of the ideas underlying model-driven engineering, where a system is automatically generated from structural and behavioral models. Lecture 1 Chapter 5 System modeling

Topics covered • Context models • Interaction models • Structural models • Behavioral models • Model-driven engineering Chapter 5 System modeling

System modeling • System modeling is the process of developing abstract models of a system, with each model presenting a different view or perspective of that system. • System modeling has now come to mean representing a system using some kind of graphical notation, which is now almost always based on notations in the Unified Modeling Language (UML). • System modelling helps the analyst to understand the functionality of the system and models are used to communicate with customers. Chapter 5 System modeling

Existing and planned system models • Models of the existing system are used during requirements engineering. They help clarify what the existing system does and can be used as a basis for discussing its strengths and weaknesses. These then lead to requirements for the new system. • Models of the new system are used during requirements engineering to help explain the proposed requirements to other system stakeholders. Engineers use these models to discuss design proposals and to document the system for implementation. • In a model-driven engineering process, it is possible to generate a complete or partial system implementation from the system model. Chapter 5 System modeling

System perspectives • A model is an abstraction of the system being studied rather than an alternative representation of that system. • Ideally, a representation of a system should maintain all the information about the entity being represented. • An abstraction deliberately simplifies and picks out the most salient characteristics. • For example, in the very unlikely event of this book being serialized in a newspaper, the presentation there would be an abstraction of the book’s key points. If it were translated from English into Italian, this would be an alternative representation. Chapter 5 System modeling

System perspectives • An external perspective, where you model the context or environment of the system. • An interaction perspective, where you model the interactions between a system and its environment, or between the components of a system. • A structural perspective, where you model the organization of a system or the structure of the data that is processed by the system. • A behavioral perspective, where you model the dynamic behavior of the system and how it responds to events. Chapter 5 System modeling

UML diagram types • UML has become a standard modeling language for object-oriented modeling. • The UML has many diagram types and so supports the creation of many different types of system model. • A survey in 2007 (Erickson and Siau, 2007) showed that most users of the UML thought that five diagram types could represent the essentials of a system Chapter 5 System modeling

UML diagram types • Activity diagrams, which show the activities involved in a process or in data processing . • Use case diagrams, which show the interactions between a system and its environment. • Sequence diagrams, which show interactions between actors and the system and between system components. • Class diagrams, which show the object classes in the system and the associations between these classes. • State diagrams, which show how the system reacts to internal and external events. Chapter 5 System modeling

UML diagram types • The detail and rigor of a model depends on how you intend to use it. There are three ways in which graphical models are commonly used: • As a means of facilitating discussion about an existing or proposed system. • As a way of documenting an existing system. • As a detailed system description that can be used to generate a system implementation. Chapter 5 System modeling

UML diagram types • The purpose of the model is to stimulate the discussion amongst the software engineers involved in developing the system. • The models may be incomplete (so long as they cover the key points of the discussion) and they may use the modeling notation informally. • When models are used as documentation, they do not have to be complete as you may only wish to develop models for some parts of a system. • Models are used as part of a model-based development process, the system models have to be both complete and correct. The reason for this is that they are used as a basis for generating the source code of the system. Chapter 5 System modeling

Use of graphical models • As a means of facilitating discussion about an existing or proposed system • Incomplete and incorrect models are OK as their role is to support discussion. • As a way of documenting an existing system • Models should be an accurate representation of the system but need not be complete. • As a detailed system description that can be used to generate a system implementation • Models have to be both correct and complete. Chapter 5 System modeling

Context models are used to illustrate the operational context of a system - they show what lies outside the system boundaries. This involves working with system stakeholders to decide what functionality should be included in the system and what is provided by the system’s environment. Social and organisational concerns may affect the decision on where to position system boundaries. Architectural models show the system and its relationship with other systems. Context models Chapter 5 System modeling

System boundaries • System boundaries are established to define what is inside and what is outside the system. • They show other systems that are used or depend on the system being developed. • The position of the system boundary has a profound effect on the system requirements. • Defining a system boundary is a political judgment • There may be pressures to develop system boundaries that increase / decrease the influence or workload of different parts of an organization. Chapter 5 System modeling

System boundaries • For example, you are developing the specification for the patient information system for mental healthcare. This system is intended to manage information about patients attending mental health clinics and the treatments that have been prescribed. • In developing the specification for this system, you have to decide whether the system should focus exclusively on collecting information about consultations (using other systems to collect personal information about patients) or whether it should also collect personal patient information. • The advantage of relying on other systems for patient information is that you avoid duplicating data. • The major disadvantage, however, is that using other systems may make it slower to access information. If these systems are unavailable, then the MHC-PMS cannot be used. • The definition of a system boundary is not a value-free judgment. Chapter 5 System modeling

The context of the MHC-PMS Figure 5.1 is a simple context model that shows the patient information system and the other systems in its environment. From Figure 5.1, you can see that the MHC-PMS is connected to an appointments system and a more general patient record system with which it shares data. The system is also connected to systems for management reporting and hospital bed allocation and a statistics system that collects information for research. Finally, it makes use of a prescription system to generate prescriptions for patients’ medication. Chapter 5 System modeling

Process perspective • Context models simply show the other systems in the environment, not how the system being developed is used in that environment. • Process models reveal how the system being developed is used in broader business processes. • UML activity diagrams may be used to define business process models. Activity Diagram: • Activity diagram is another important diagram to describe dynamic behaviour. Activity diagram consists of activities, links, relationships etc. It models all types of flows like parallel, single, concurrent etc. • Activity diagram describes the flow control from one activity to another without any messages. These diagrams are used to model high level view of business requirements. Chapter 5 System modeling

Process model of involuntary detention Figure 5.2 is a model of an important system process that shows the processes in which the MHC-PMS is used. Sometimes, patients who are suffering from mental health problems may be a danger to others or to themselves. They may therefore have to be detained against their will in a hospital so that treatment can be administered. Such detention is subject to strict legal safeguards—for example, the decision to detain a patient must be regularly reviewed so that people are not held indefinitely without good reason. One of the functions of the MHC-PMS is to ensure that such safeguards are implemented. Figure 5.2 is a UML activity diagram. Activity diagrams are intended to show the activities that make up a system process and the flow of control from one activity to another. The start of a process is indicated by a filled circle; the end by a filled circle inside another circle. Rectangles with round corners represent activities, that is, the specific sub-processes that must be carried out. You may include objects in activity charts. In Figure 5.2, the systems that are used to support different processes. These are separate systems using the UML stereotype feature. In a UML activity diagram, arrows represent the flow of work from one activity to another. A solid bar is used to indicate activity coordination. When the flow from more than one activity leads to a solid bar then all of these activities must be complete before progress is possible. When the flow from a solid bar leads to a number of activities, these may be executed in parallel. Figure 5.2, the activities to inform social care and the patient’s next of kin, and to update the detention register Chapter 5 System modeling

Process model of involuntary detention Chapter 5 System modeling

Initial node. The filled in circle is the starting point of the diagram. An initial node isn’t required although it does make it significantly easier to read the diagram. Activity final node. The filled circle with a border is the ending point. An activity diagram can have zero or more activity final nodes. Activity. The rounded rectangles represent activities that occur. An activity may be physical, such as Inspect Forms, or electronic, such as Display Create Student Screen. Flow/edge. The arrows on the diagram. Although there is a subtle difference between flows and edges I have never seen a practical purpose for the difference although I have no doubt one exists. I’ll use the term flow. Fork. A black bar with one flow going into it and several leaving it. This denotes the beginning of parallel activity. Join. A black bar with several flows entering it and one leaving it. All flows going into the join must reach it before processing may continue. This denotes the end of parallel processing. Condition. Text such as [Incorrect Form] on a flow, defining a guard which must evaluate to true in order to traverse the node. Decision. A diamond with one flow entering and several leaving. The flows leaving include conditions although some modelers will not indicate the conditions if it is obvious. Merge. A diamond with several flows entering and one leaving. The implication is that one or more incoming flows must reach this point until processing continues, based on any guards on the outgoing flow. Chapter 5 System modeling

Interaction models • Modeling user interaction is important as it helps to identify user requirements. • Modeling system-to-system interaction highlights the communication problems that may arise. • Modeling component interaction helps us understand if a proposed system structure is likely to deliver the required system performance and dependability. • Use case diagrams and sequence diagrams may be used for interaction modelling. Chapter 5 System modeling

Use case modeling • Use cases were developed originally to support requirements elicitation and now incorporated into the UML. • Each use case represents a discrete task that involves external interaction with a system. • Actors in a use case may be people or other systems. • Represented diagrammatically to provide an overview of the use case and in a more detailed textual form. • Interaction modelling use two approaches; • Use case modelling, which is mostly used to model interactions between a system and external actors (users or other systems). • Sequence diagrams, which are used to model interactions between system components, although external agents may also be included Chapter 5 System modeling

Use case Modelling • Use case modelling is widely used to support requirements elicitation. • A use case can be taken as a simple scenario that describes what a user expects from a system. • Each use case represents a discrete task that involves external interaction with a system. Chapter 5 System modeling

Transfer-data use case • A use case in the MHC-PMS • Figure shows a use case from the MHC-PMS that represents the task of uploading data from the MHC-PMS to a more general patient record system. This more general system maintains summary data about a patient rather than the data about each consultation, which is recorded in the MHC-PMS. Chapter 5 System modeling

Tabular description of the ‘Transfer data’ use-case Chapter 5 System modeling

Use cases in the MHC-PMS involving the role ‘Medical Receptionist’ Chapter 5 System modeling

Use case Example’ Chapter 5 System modeling

Sequence diagrams • What is a UML Sequence Diagram? • Sequence diagrams describe interactions among classes in terms of an exchange of messages over time. • A sequence diagram shows actors, objects (instances of classes) and the messages sent between them Chapter 5 System modeling

Sequence diagrams • Sequence diagrams are part of the UML and are used to model the interactions between the actors and the objects within a system. • A sequence diagram shows the sequence of interactions that take place during a particular use case or use case instance. • The objects and actors involved are listed along the top of the diagram, with a dotted line drawn vertically from these. • Interactions between objects are indicated by annotated arrows. Chapter 5 System modeling

Sequence diagram for View patient information Chapter 5 System modeling

Sequence diagram for View patient information 1. The medical receptionist triggers the ViewInfo method in an instance P of the PatientInfo object class, supplying the patient’s identifier, PID. P is a user interface object, which is displayed as a form showing patient information. 2. The instance P calls the database to return the information required, supplying the receptionist’s identifier to allow security checking (at this stage, we do not care where this UID comes from). 3. The database checks with an authorization system that the user is authorized for this action. 4. If authorized, the patient information is returned and a form on the user’s screen is filled in. If authorization fails, then an error message is returned. Chapter 5 System modeling

Sequence diagram for Transfer Data Second example of a sequence diagram from the same system that illustrates two additional features. These are the direct communication between the actors in the system and the creation of objects as part of a sequence of operations. 1. The receptionist logs on to the PRS. 2. There are two options available. These allow the direct transfer of updated patient information to the PRS and the transfer of summary health data from the MHC-PMS to the PRS. 3. In each case, the receptionist’s permissions are checked using the authorization system. 4. Personal information may be transferred directly from the user interface object to the PRS. Alternatively, a summary record may be created from the database and that record is then transferred. 5. On completion of the transfer, the PRS issues a status message and the user logs off Chapter 5 System modeling

Sequence diagram for Transfer Data Chapter 5 System modeling

Structural models • Structural models of software display the organization of a system in terms of the components that make up that system and their relationships. • Structural models may be static models, which show the structure of the system design, or dynamic models, which show the organization of the system when it is executing. • You create structural models of a system when you are discussing and designing the system architecture. • Structural model: a view of an system that emphasizes the structure of the objects, including their classifiers, relationships, attributes and operations Chapter 5 System modeling

Class diagrams • Class diagrams are used when developing an object-oriented system model to show the classes in a system and the associations between these classes. • A class diagram is a UML structural diagram. Depending on the complexity of a system, you can use a single class diagram to model the entire system, or you can use several class diagrams to model the components of the system. • Class diagrams are the blueprints of your system. Use class diagrams to model the objects that make up the system, to display the relationships between the objects, and to describe what those objects do • An object class can be thought of as a general definition of one kind of system object. • An association is a link between classes that indicates that there is some relationship between these classes. • When you are developing models during the early stages of the software engineering process, objects represent something in the real world, such as a patient, a prescription, doctor, etc. Chapter 5 System modeling

UML classes and association • Figure 5.8 is a simple class diagram showing two classes: Patient and Patient Record with an association between them. • In Figure 5.8, I illustrate a further feature of class diagrams—the ability to show how many objects are involved in the association. • In this example, each end of the association is annotated with a 1, meaning that there is a 1:1 relationship between objects of these classes. That is, each patient has exactly one record and each record maintains information about exactly one patient. Chapter 5 System modeling

Classes and associations in the MHC-PMS • You can define that an exact number of objects are involved or, by using a *, as shown in Figure 5.9, that there are an indefinite number of objects involved in the association. • Figure 5.9 develops this type of class diagram to show that objects of class Patient are also involved in relationships with a number of other classes. In this example, I show that you can name associations to give the reader an indication of the type of relationship that exists. • The UML also allows the role of the objects participating in the association to be specified. • When showing the associations between classes, it is convenient to represent • these classes in the simplest possible way. • To define them in more detail, you add information about their attributes (the characteristics of an object) and operations (the things that you can request from an object). • For example, a Patient object will have the attribute Address and you may include an operation called ChangeAddress, which is called when a patient indicates that they have moved from one address to another. Chapter 5 System modeling

Classes and associations in the MHC-PMS Chapter 5 System modeling

The Consultation class • In the UML, you show attributes and operations by extending the simple rectangle that represents a class. • The figure shows following • 1. The name of the object class is in the top section. • 2. The class attributes are in the middle section. This must include the attribute names and, optionally, their types. • 3. The operations (called methods in Java and other OO programming languages) associated with the object class are in the lower section of the rectangle. • Figure shows possible attributes and operations on the class Consultation. In this example, assume that doctors record voice notes that are transcribed later to record details of the consultation. • To prescribe medication, the doctor involved must use the Prescribe method to generate an electronic prescription. Chapter 5 System modeling

Key points • A model is an abstract view of a system that ignores system details. Complementary system models can be developed to show the system’s context, interactions, structure and behavior. • Context models show how a system that is being modeled is positioned in an environment with other systems and processes. • Use case diagrams and sequence diagrams are used to describe the interactions between users and systems in the system being designed. Use cases describe interactions between a system and external actors; sequence diagrams add more information to these by showing interactions between system objects. • Structural models show the organization and architecture of a system. Class diagrams are used to define the static structure of classes in a system and their associations. Chapter 5 System modeling

Chapter 5 – System Modeling Lecture 2 Chapter 5 System modeling

Generalization • Generalization is an everyday technique that we use to manage complexity. • Rather than learn the detailed characteristics of every entity that we experience, we place these entities in more general classes (animals, cars, houses, etc.) and learn the characteristics of these classes. • This allows us to infer that different members of these classes have some common characteristics e.g. squirrels and rats are rodents. Chapter 5 System modeling

Generalization • In modeling systems, it is often useful to examine the classes in a system to see if there is scope for generalization. If changes are proposed, then you do not have to look at all classes in the system to see if they are affected by the change. • In object-oriented languages, such as Java, generalization is implemented using the class inheritance mechanisms built into the language. • In a generalization, the attributes and operations associated with higher-level classes are also associated with the lower-level classes. • The lower-level classes are subclasses inherit the attributes and operations from their superclasses. These lower-level classes then add more specific attributes and operations. Chapter 5 System modeling

A generalization hierarchy The UML has a specific type of association to denote generalization, as illustrated in Figure 5.11. The generalization is shown as an arrowhead pointing up to the more general class. This shows that general practitioners and hospital doctors can be generalized as doctors and that there are three types of Hospital Doctor—those that have just graduated from medical school and have to be supervised (Trainee Doctor); those that can work unsupervised as part of a consultant’s team (Registered Doctor); and consultants, who are senior doctors with full decision making responsibilities. Chapter 5 System modeling

A generalization hierarchy with added detail In a generalization, the attributes and operations associated with higher-level classes are also associated with the lower-level classes. The lower-level classes are subclasses inherit the attributes and operations from their super classes. These lower-level classes then add more specific attributes and operations. For example, all doctors have a name and phone number; all hospital doctors have a staff number and a department but general practitioners don’t have these attributes as they work independently. They do however, have a practice name and address. This is illustrated in Figure which shows part of the generalization hierarchy that have extended with class attributes. The operations associated with the class Doctor are intended to register and de-register that doctor with the MHC-PMS. Chapter 5 System modeling

An aggregation model shows how classes that are collections are composed of other classes. Aggregation models are similar to the part-of relationship in semantic data models. Objects in the real world are often composed of different parts. For example, a study pack for a course may be composed of a book, PowerPoint slides, quizzes, and recommendations for further reading. Sometimes in a system model, you need to illustrate this. Object class aggregation models Chapter 5 System modeling

The aggregation association • The UML provides a special type of association between classes called aggregation that means that one object (the whole) is composed of other objects (the parts). • To show this, we use a diamond shape next to the class that represents the whole. The figure shows that a patient record is a composition of Patient and an indefinite number of Consultations. Chapter 5 System modeling

Behavioral models • Behavioral models are models of the dynamic behavior of a system as it is executing. They show what happens or what is supposed to happen when a system responds to a stimulus from its environment. • You can think of these stimuli as being of two types: • Data Some data arrives that has to be processed by the system. • Events Some event happens that triggers system processing. Events may have associated data, although this is not always the case. Chapter 5 System modeling

Behavioral models • For example, a phone billing system will accept information about calls made by a customer, calculate the costs of these calls, and generate a bill to be sent to that customer. • By contrast, real-time systems are often event driven with minimal data processing. For example, a landline phone switching system responds to events such as ‘receiver off hook’ by generating a dial tone, or the pressing of keys on a handset by capturing the phone number, etc. Chapter 5 System modeling

Data-driven modeling • Many business systems are data-processing systems that are primarily driven by data. They are controlled by the data input to the system, with relatively little external event processing. • Data-driven models show the sequence of actions involved in processing input data and generating an associated output. • They are particularly useful during the analysis of requirements as they can be used to show end-to-end processing in a system. • Data-driven models were amongst the first graphical software models. • Data-flow diagrams (DFDs) as a way of illustrating the processing steps in a system. • Data-flow models are useful because tracking and documenting how the data associated with a particular process moves through the system helps analysts and designers understand what is going on. • Data-flow diagrams are simple and intuitive and it is usually possible to explain them to potential system users who can then participate in validating the model. Chapter 5 System modeling

Order processing Chapter 5 System modeling

• More by User

Chapter 2, Modeling with UML, Part 2

Chapter 2, Modeling with UML, Part 2. Outline of this Class. Use case diagrams Describe the functional behavior of the system as seen by the user Class diagrams Describe the static structure of the system: Objects, attributes, associations Sequence diagrams

730 views • 47 slides

Spatial Modeling with GIS

Spatial Modeling with GIS. Longley et al., Chapter 16. Spatial Modeling with GIS. Introduction Types of Model Modeling Technology Multicriteria Methods Accuracy and Validity . Spatial modeling. Modeling: An overworked term

806 views • 39 slides

Introduction to System Modeling and Control

Introduction to System Modeling and Control. Introduction Basic Definitions Different Model Types System Identification Neural Network Modeling. Mathematical Modeling (MM). A mathematical model represent a physical system in terms of mathematical equations

1.52k views • 52 slides

Chapter 2, Modeling with UML

Chapter 2, Modeling with UML. Overview . What is modeling? What is UML? Use case diagrams Class diagrams Sequence diagrams Activity diagrams Summary. Systems, Models, and Views. A model is an abstraction describing system or a subset of a system

726 views • 45 slides

Chapter 3. Requirements Modeling. Phase Description. Systems analysis is the 2nd of 5 phases in the systems development life cycle (SDLC) Uses requirements modeling and enterprise modeling to represent the new system

615 views • 40 slides

Modeling. ECE 417/617: Elements of Software Engineering. Stan Birchfield Clemson University. Overview. Modeling provides abstraction to bridge the gap between High-level (world) Low-level (code) Types of modeling: Analysis modeling Models problem domain (users, world) System modeling

419 views • 19 slides

Chapter 5 – System Modeling. Lecture 1. Topics covered. Context models Interaction models Structural models Behavioral models Model-driven engineering. System modeling.

651 views • 51 slides

703 views • 53 slides

735 views • 55 slides

Chapter 5 System Modeling

Chapter 5 System Modeling. Topics covered. Context models Structural models Behavioral models. Introduction. Model is abstract view of a system. We create a model : To Gain a better understanding of an entity. For example, a model of a plane is a small plane.

767 views • 57 slides

Chapter 1. Modeling Change. Mathematical Models. Mathematical construct designed to study a particular real-world system or behavior of interest. Proportionality. Examples Cylindrical containers Strength Flea Jump. 1.1 Modeling Change with Difference Equations.

365 views • 21 slides

Chapter 8. Data Modeling and Analysis. Data Modeling. Data modeling – a technique for organizing and documenting a system’s data. Sometimes called database modeling .

704 views • 50 slides

Introduction to the WRF Modeling System

Introduction to the WRF Modeling System. Wei Wang NCAR/MMM. WRF Modeling System Overview. Modeling System Components. WRF Standard Initialization (WRF SI) For real-data runs Inputs Terrain/land-use/soil texture/albedo Grid location/levels Gridded fields (in GRIB format) Output

539 views • 13 slides

Lab 2: Heterogeneous System Modeling in Ptolemy - Session 6 -

Lab 2: Heterogeneous System Modeling in Ptolemy - Session 6 -. Peter Marwedel Heiko Falk TU Dortmund Informatik 12 Germany. Heterogeneous System Modeling (1). The following assignments use the Ptolemy modeling framework. Be sure to use the block diagram mode where appropriate.

223 views • 3 slides

IT 21103/41103

IT 21103/41103. System Analysis & Design. Chapter 03. Process Modeling. Process Modeling. The analyst must fully understand the current system. Process Modeling. We use the Data Flow Diagram (DFD) to help us understand the current system. Process Modeling.

506 views • 36 slides

Chapter 4 Requirement Modeling

Chapter 4 Requirement Modeling. Phase Description. Systems analysis is the second of five phases in the systems development life cycle (SDLC) Uses requirements modeling and data and process modeling to represent the new system

1.52k views • 45 slides

Chapter 12 Information System Development

Chapter 12 Information System Development. Chapter 12 Objectives. Next. List the phases in the system development cycle. Describe the various tools used in object modeling. Identify the guidelines for system development. Explain the activities performed in the design phase.

742 views • 54 slides

Modeling. Eng. Sara El- Refaay Eng. Sara Farghal. What is Modeling?. Modeling is the process of producing a model; a model is a representation of the construction and working of some system of interest. A model is similar to but simpler than the system it represents. One purpose of a

312 views • 12 slides

Chapter 4: Predictive Modeling

Chapter 4: Predictive Modeling. Chapter 4: Predictive Modeling. Objectives. Explain the concepts of predictive modeling. Illustrate the modeling essentials of a predictive model. Explain the importance of data partitioning. Catalog Case Study. Analysis Goal:

2.47k views • 196 slides

Chapter 5 – System Modeling. Fall 2014. Chapter 5 – System Modeling. Lecture 1. Topics covered. Context models Interaction models Structural models Behavioral models Model-driven engineering. System modeling.

773 views • 56 slides

• Publications
• News and Events
• Education and Outreach

Software Engineering Institute

Cite this post.

AMS Citation

Shevchenko, N., 2020: An Introduction to Model-Based Systems Engineering (MBSE). Carnegie Mellon University, Software Engineering Institute's Insights (blog), Accessed April 2, 2024, https://insights.sei.cmu.edu/blog/introduction-model-based-systems-engineering-mbse/.

APA Citation

Shevchenko, N. (2020, December 21). An Introduction to Model-Based Systems Engineering (MBSE). Retrieved April 2, 2024, from https://insights.sei.cmu.edu/blog/introduction-model-based-systems-engineering-mbse/.

Chicago Citation

Shevchenko, Nataliya. "An Introduction to Model-Based Systems Engineering (MBSE)." Carnegie Mellon University, Software Engineering Institute's Insights (blog) . Carnegie Mellon's Software Engineering Institute, December 21, 2020. https://insights.sei.cmu.edu/blog/introduction-model-based-systems-engineering-mbse/.

IEEE Citation

N. Shevchenko, "An Introduction to Model-Based Systems Engineering (MBSE)," Carnegie Mellon University, Software Engineering Institute's Insights (blog) . Carnegie Mellon's Software Engineering Institute, 21-Dec-2020 [Online]. Available: https://insights.sei.cmu.edu/blog/introduction-model-based-systems-engineering-mbse/. [Accessed: 2-Apr-2024].

BibTeX Code

@misc{shevchenko_2020, author={Shevchenko, Nataliya}, title={An Introduction to Model-Based Systems Engineering (MBSE)}, month={Dec}, year={2020}, howpublished={Carnegie Mellon University, Software Engineering Institute's Insights (blog)}, url={https://insights.sei.cmu.edu/blog/introduction-model-based-systems-engineering-mbse/}, note={Accessed: 2024-Apr-2} }

An Introduction to Model-Based Systems Engineering (MBSE)

Nataliya Shevchenko

December 21, 2020.

This post has been shared 62 times.

Model-based systems engineering (MBSE) is a formalized methodology that is used to support the requirements, design, analysis, verification, and validation associated with the development of complex systems. In contrast to document-centric engineering , MBSE puts models at the center of system design. The increased adoption of digital-modeling environments during the past few years has led to increased adoption of MBSE. In January 2020, NASA noted this trend by reporting that MBSE, "has been increasingly embraced by both industry and government as a means to keep track of system complexity." In this blog post, I provide a brief introduction to MBSE.

One area of concern within complex systems is cybersecurity . The SEI CERT Division has begun researching how MBSE can be used to mitigate security risks early in the system-development process so that systems are secure by design , in contrast to the common practice of adding security features later in the development process. Capturing system attributes in models enables systems engineers to perform threat-modeling analysis of the system early and incorporate mitigation strategies into the system design, thereby reducing the system's overall security-related risks.

MBSE in a digital-modeling environment provides advantages that document-based systems engineering cannot provide . For example, in a document-based approach, many documents are generated by different authors to capture the system's design from various stakeholder views, such as system behavior, software, hardware, safety, security, or other disciplines. Using a digital-modeling approach, a single source of truth for the system is built in which discipline-specific views of the system are created using the same model elements.

A digital-modeling environment also creates a common standards-based approach to documenting the system that can be programmatically validated to remove inconsistencies within the models and enforce the use of a standard by all stakeholders. This common modeling environment improves the analysis of the system and reduces the number of defects that are commonly injected in a traditional document-based approach. The availability of digitalized system data for analysis across disciplines provides consistent propagation of corrections and incorporation of new information and design decisions (i.e., state it once and automatically propagate to various views of the data) to all stakeholders. When MBSE is done properly, the result is an overall reduction of development risks.

MBSE brings together three concepts: model, systems thinking, and systems engineering:

• A model is a simplified version of something--a graphical, mathematical, or physical representation that abstracts reality to eliminate some complexity . This definition implies formality or rules in simplifying, representing, or abstracting. To model a system, a systems architect must represent the system with less detail so that its structure and behavior are apparent and its complexity is manageable. In other words, models should sufficiently represent the system, and the system should confirm the model s.
• Systems thinking is a way of looking at a system under consideration not as a self-sufficient entity, but as part of a larger system. Systems thinking is not the same as a systematic adherence to following good plans, collecting statistics, or being methodical . The systems engineer observes the system from a distance; explores its boundaries, context, and lifecycle; notes its behavior; and identifies patterns. This method can help the engineer to identify issues (e.g., missing interaction, a missing step in a process, duplication of effort, missed opportunity for automation) and manage a system's complexity. Although systems engineers must break down and analyze the system in the beginning--identify parts and describe connections between them--with systems thinking, they later synthesize the parts back into a coherent whole. Parts are not just connected to other parts, they depend on each other to work properly. Systems thinking emphasizes this interconnectedness. The behavior of the system emerges from the activities of the system's subparts. Observing the system's interconnections, the systems engineer identifies feedback loops and causality patterns that may not be apparent at first . Systems thinking can help make issues more apparent and easier to identify, balance the system, and manage the system's complexity.
• Systems engineering is a transdisciplinary and integrative approach to enable the successful realization, use, and retirement of engineered systems , using systems principles and concepts, and scientific, technological, and management methods. It brings together a number of techniques to make sure that all requirements are satisfied by the designed system. It concentrates on architecture, implementation, integration, analysis, and management of a system during its lifecycle. It also considers software, hardware, personnel, processes, and procedural aspects of the system.

If an organization has decided to adopt MBSE as an internal systems-engineering approach and chosen one of the four or five existing products for digital modeling that are on the market, the organization's systems engineers should consider whether it is going to follow any architectural frameworks. Although a comprehensive discussion of this topic is beyond the scope for this blog post, the choice of a particular architectural framework will provide additional guidance and structure to the modeling activities, especially if the systems engineers are already familiar with the framework.

MBSE is a multidisciplinary and multifaceted endeavor. It requires its own actors, processes, environment, and information flows. To create a successful model of a complex system or system of systems , an organization must support the modeling process. The support needed is not much different from what is required for an organization to successfully develop and deliver a complex system or system of systems. MBSE can be effectively integrated into a development process, but the organization must commit to the effort that will be required to model the system.

Applying systems thinking, we can recognize that there are three systems involved in the modeling process : the designed system, the designed system's context, and the modeling organization for the designed system. The designed system operates in the context of a larger system, and the modeling organization must understand both the designed system and the designed system's context. The organization must also be aware of its own behavior, successes, and failures.

We have all seen, used, or created models throughout our lives, ranging from toys that represent cars or planes to mathematical formulas that describe and explain physical phenomena such as thermodynamics or gravity. While fundamentally different, those models all connect an idea to a reality and provide sufficient abstraction for the purpose . When modeling a system, the systems engineer decides what aspects of the production system are most important, such as structure, energy or matter flow, internal communication, or safety and security. Those types of aspects will become the focus of the model. The top objective of the modeling activity is to model the salient aspects on which the model is focused as closely to the real system as is possible and feasible.

Modeling as a technique uses four instruments :

• argumentation
• presentation

A modeling language is a common terminology for clearly communicating an abstract idea that the model captures. The modeling language can be formal, with strict syntax and rules. A few system-modeling languages exist, including general-purpose languages such as the Systems Modeling Language (SysML) and Unified Modeling Language (UML) , as well as specialized languages such as Architecture Analysis Design Language (AADL) . Although SysML and UML are not mathematically formal, a valid model requires that the modeling language's rules for entities and relationships be followed. SysML has strict syntax and rules for relationships and connections between elements, which helps to avoid ambiguity. If a model is well built, several types of standard SysML diagrams can be dynamically simulated, and at least one type of SysML diagram can be mathematically simulated. UML is semi-formal; SysML is similar to UML, but more formal .

A model must have a structure. A well-structured model can make the model understandable, usable, and maintainable, which is particularly important for complex systems. The goal of a model is to show stakeholders that the presented design satisfies the system's requirements. The model should demonstrate, in an easily comprehensible way, how the system must be built to be successful. Visualization is a key way to ensure comprehensibility. Visualizing abstract ideas enables people to take the leap of imagination that is needed to "see" the system.

Modeling Domains

Even though MBSE does not dictate any specific process, essentially any process chosen should cover four systems-engineering domains :

• requirements/capabilities
• architecture/structure
• verification and validation

Descriptions of these domains are well documented and discussed by, among others, Defense Acquisition University (DAU) , NASA , and Avi Sharma . The difference that MBSE makes is that these fundamental systems-engineering domains are defined not as a set of documents, but in the model itself, i.e., in a formal way using a modeling language. The model represents an argument for how the system must be designed for it to be successful.

MBSE also fosters communication among stakeholders, systems engineers, and developers. Since system design is performed in the integrated modeling environment, all systems engineers, managers, and other stakeholders can have access to the generated information--such as requirements, behavior flows, and architecture--as soon as necessary.

The most common modeling activity is the creation of diagrams representing some part of the system--a view. This activity is so common that some engineers mistakenly equate creating a view with creating a model. This mistake is so pervasive that there is even an emerging term for it: zombie model . This term refers to a model that is full of diagrams, but with no interconnectivity and dependencies identified among the elements.

Anyone who is about to start modeling must realize that a set of views is not a model. Although a view or even a set of views can represent a part of the system's design and can be useful for documenting and communicating some aspects of the system, views are only facets or portions of the true system model. A real model can produce many views and matrices, perform analyses, and run simulations.

Language of System Modeling

While a system-modeling language such as SysML is a formal syntactic language, it is still based on elements of human language. Its formality adds clarity and discipline that are critical for describing the design of a system. Such a language is easy to read and understand. Terms of MBSE's language simply map to parts of speech :

• noun: actors, blocks, components, requirements
• verb: operational activities, functions, use cases
• adjective: attributes
• adverb: relationships, needlines , exchanges, interfaces

This view of the modeling language helps its users to mentally map real-life concepts to abstract ideas, and eases the formalization of the modeling process.

Four Quadrants of the MBSE Model

Now that I have described the basics of a model's language and domains, I will describe the modeling approach. A model must describe both a problem that the designed system solves, and the designed system itself (the solution). The model must have these two sides, the problem side and the solution side . These are sometimes referred to as the operational and system points of view.

The operational point of view is the perspective of users, operators, and business people. It should represent business processes, objectives, organizational structure, use cases, and information flows. The operational side of the model can contain the description of "the world as-is" and the future state.

The system point of view is the solution, the architecture of the system that solves the problem posed in the operational side of the model. It should describe the behavior of the system, its structure, dataflows between components, and allocation of functionality. It should describe how the system will be deployed in the real world. It can contain solution alternatives and analyses of them.

Each of these points of view has two parts, logical and physical. Separating logical and physical aspects of the model is a way to manage a system's complexity. Logical parts of the model usually change little over time, while physical changes are often initiated by technology advances.

If the model is built properly, all four quadrants should be tightly connected, as shown in Figure 1 below. Statements of the problem should be traced to elements of the solution, and logical elements allocated to physical structures. The user of the model should be able to see clearly how the top-level concepts and components decompose to the lower level features. Users should be able to perform system analysis, create dependency matrices, run simulations, and produce a view of the system for every stakeholder. If the physical part of the system must change, the logical side of the model identifies exactly what functionality will be affected. If a requirement or business process must be changed, the model will easily discover the impact on the solutions.

Wrapping Up and Looking Ahead

In this post, I explained what MBSE is, showed how it relates to systems engineering, and discussed the fundamentals of model and modeling. My next post will take a more practical approach and discuss requirements and requirements models.

Additional Resources

Watch the SEI video, What Would Convince DoD Program Managers to Use Model-Based System Engineering?

Read the SEI blog post, Modeling Capabilities with Model-Based Systems Engineering (MBSE)

Read the SEI blog post, Requirements in Model-Based Systems Engineering (MBSE)

Read the SEI blog post, Evaluating Threat-Modeling Methods for Cyber-Physical Systems .

Read the SEI blog post, Threat Modeling: 12 Available Methods .

Author Page

Digital library publications, send a message, more by the author, modeling capabilities with model-based systems engineering (mbse), november 28, 2022 • by nataliya shevchenko, a case study in applying digital engineering, april 18, 2022 • by nataliya shevchenko , peter capell, requirements in model-based systems engineering (mbse), february 22, 2021 • by nataliya shevchenko, evaluating threat-modeling methods for cyber-physical systems, february 4, 2019 • by nataliya shevchenko, threat modeling: 12 available methods, december 3, 2018 • by nataliya shevchenko, get updates on our latest work..

Sign up to have the latest post sent to your inbox weekly.

Each week, our researchers write about the latest in software engineering, cybersecurity and artificial intelligence. Sign up to get the latest post sent to your inbox the day it's published.

Browse Course Material

Course info, instructors.

• Prof. Franz Hover
• Prof. David Gossard
• Prof. George Barbastathis

Departments

• Mechanical Engineering

As Taught In

• Dynamics and Control
• Computational Modeling and Simulation
• Differential Equations

Learning Resource Types

Systems, modeling, and control ii, lecture01.pdf.

Lecture slides with an introduction to the course and overview of system modeling, system dynamics, and system control.

You are leaving MIT OpenCourseWare

Lesson 1 – Introduction to Systems and Models

• Introduction to Systems Unit Plan Lesson 1 – Cell Phone Network Introduction Lesson 2 – Cytoscape Cell phone Network Contributors
• Systems Are Everywhere Unit Plan Lesson 1 – Introduction to Systems and Models Lesson 2 – Systems Thinking Lesson 3 – Becoming a Systems Thinker Contributors
• Bioengineering a Sustainable World Unit Plan Lesson 1 – Carbon Footprints Lesson 2 – Bioengineering and Sustainability Lesson 3 – Bioengineering and Gene Regulation Lesson 4 – Solutions and Sustainability Contributors
• Computational Modeling
• Demystifying Machine Learning Contributors
• Ecological Networks Unit Plan Lesson 1 – Introduction to Extremophiles Lesson 2 – GSL case study introduction Lesson 3 – Spectrophotometer and Micropipette Use Lesson 4 – Conducting Halo Salinity Experiment Lesson 5 – Data Analysis Halo Salinity Experiment Lesson 6 – Revisiting the GSL Network Contributors
• Environmental Influence on Gene Networks Unit Plan Lesson 1 – Scientists Prepare and Plan Lesson 2 – Response of Halo in Different Environmental Conditions Lesson 3 – Data Analysis to Propose Network Function Lesson 4 – Analysis of Lab Results to Verify Network Interactions Contributors
• Invisible Forest Unit Plan Lesson 0.5 – It’s Only a Drop of Water (Project Based Learning Plan) Lesson 1 – A Breath of Oxygen Lesson 2 – Who’s who in the photosynthetic world from macro to microscale Lesson 3 – Tools of the Trade Exploratorium: Collecting Oceanographic Data From Where We Cannot See Lesson 3.5 Phytoplankton, Spectrophotometry & Microscopy Labs Lesson 4 – Scaling up: Linking cells in a drop of seawater to global patterns Lesson 5 – Dive into Data: Raw to Results Contributors
• Modeling Sustainable Food Systems Food Security Module Overview Lesson FS1: Introduction to Food Security Lesson FS2: Critically Evaluating Food Production Techniques Application: Designing, constructing, and reengineering a system Lesson FS3: Who Cares? Stakeholders! Lesson FS4: Food Security as a System Lesson FS5: Why Don’t We Just Grow More? Lesson FS6: Where Does Our Food Come From? Lesson FS7: Summative Assessment – United Nations Council Meeting Contributors
• Observing Beyond Our Senses Unit Plan Lesson 1 – Introduction to Saline Environments & Microbial Halophiles Lesson 2 – Design Process-Measuring Wind Speed Lesson 3 – Inferences From Proxy Variable Mock AFM Lesson 4 – Signal and Noise Lesson 5 – Inferring Properties and Calibrations Lesson 6 – Death Valley Middle Basin Case Study Contributors
• Ocean Acidification Unit Plan Lesson 1 – Critical and Systems Evaluation of News Articles Lesson 2 – Exploring CO2 to Better Understand Ocean Acidification Lesson 3 – Defining the Problem: Ocean Acidification Lesson 4 – Planning Cohesive Experiments Lesson 5a – Ocean Acidification Experimentation Lesson 5b – Online Data and Supplemental Evidence Lesson 5b – Online Data and Supplemental Evidence (pre-2018 version) Lesson 5c – Using Ocean Acidification Models to Make Predictions Lesson 6 – Global Ocean Acidification Summit Contributors
• Carbon’s Fate
• Systems Medicine Education
• Standards Addressed
• Community-Contributed Curriculum Adaptations

Instructions

Career connection, accommodations.

COURSE: Any science / STEM course that uses systems. Examples of courses where this has been used are: Physical Science, Life Science, Biological Science, Environment Science, Physics, Chemistry, Biology, Oceanography, Engineering, Economics, Mathematics, General Elementary Education.

UNIT: Units that include applications of cycles, feedback loops, circuits, processes, equilibrium, homeostasis, or response for any STEM content. Additionally, units that focus on building 21st-century skills, “soft skills”, problem-solving, design thinking, systems thinking, career connections, career awareness, and career development skills. Systems models have dimensionality that can be used to represent math variables in a visual way, therefore the activities in this lesson can be integrated into courses requiring math and mathematical thinking.

OBJECTIVES: See the Standards Addressed page for information about the published standards and process we use when aligning lessons with NGSS and other Science, Math, Literacy and 21st Century skills). In addition to the aligned objectives listed in buttons on the upper-left of this page and in the table below, for this lesson, here is a breakdown of :

• A system is a collection of interconnected and interdependent parts.
• Systems can be found in all aspects of life, and can be simple or complex.
• Modeling systems provides insight into the relationships and contributions of each part of a system.
• Computer modeling tools allow for the visualization of the flow of information in a system.
• A systems model includes nodes to represent the parts of a system, and edges to represent the relationships between those parts.
• Systems generally have mechanisms for balancing growth and stability.
• Change in a systems model can be positive, negative, or neutral.
• Students evaluate a list of items to determine whether they are a system.
• Students explain what a system is.
• Students build understanding of real-world systems by analyzing parts of an urban farm system.
• Students use an online tool, Loopy, to model a subsystem of the urban farm.
• Students build on their Loopy model to generate ideas for mitigating the negative effects and / or elaborate on impacts to the system

Systems Thinking Skills: Systems thinking developed through this lesson trains students to apply these skills to defining problems, building and testing models with application to all science core subjects. The skills include: Exploring boundaries; Appreciating multiple perspectives;Understanding relationships; Thinking in terms of systems themselves.

Common Core: HSN.Q.A.2: Define appropriate quantities for the purpose of descriptive modeling. (HS-ESS3-4)

Pacing Guide: 1, 50-minute class period

PURPOSE / INTRODUCTION

Lesson 1 serves to foster students’ understanding of systems and systems models. Students begin by exploring and defining what a system is ( Activity 1.1 ), then learning about and modeling a complex urban farm system ( Activity 1.2 ). To model the system students apply their knowledge of systems to brainstorm the parts and connections of the system, then use an online tool (Loopy) to model the interactions of those parts and connections. Lastly, students work in groups to build on the model by brainstorming ways to mitigate the negative effects of the system and / or elaborate on impacts to the system.

The urban farm example is used to provide context for how systems approaches are used in real life to address complex problems, as well as to introduce students to diverse STEM careers and workplaces. Additional activities are suggested for more career connections related to the activities in this lesson (see the Career Connections section).

PREREQUISITES / BACKGROUND INFORMATION

There are no prerequisites for Lesson 1.

ADVANCED PREPARATION / BEFORE CLASS

• While this lesson can be delivered in-person, it was developed intentionally to be delivered as a remote learning experience. Therefore if leading remotely, students and educators should have access to and familiarity with using video conferencing tools (Zoom, teams, Google Meet, etc.) including using chat, sharing screens, and breakout rooms. We also suggest using online collaborative tools (Google Docs, Google Slides, OneNote, Jamboard, etc.) to share ideas and brainstorm. These may require you to request access from your IT specialist or administrator. We have only suggested tools that are free and have been accessed by other schools and districts.
• The lesson includes use of breakout rooms for small group collaboration. Follow your district’s policies for using and managing breakout rooms with students.
• The lesson includes students sharing their screen to share their models and presentations with the class. If screen sharing is not allowed, students can share a link to their model or presentations with you and you can share for them.
• Lesson 1 slide presentation
• Yes Farm YouTube video ( https://youtu.be/ZMI1zOraNjU ) or 1-page profile ( https://bit.ly/3wySelj )
• Loopy online modeling tool
• Unit Pre-Assessment – 1 per student
• “Is it a System” worksheet – 1 per student

INSTRUCTIONAL ACTIVITIES / LESSON SEQUENCE

The following instructions outline steps for leading each activity as well as suggested speaker notes (in italics ) and background information. Speaker notes have also been added to the presentation slide notes when applicable.

Prior to starting the unit have students complete the Unit Assessment . This can be done on paper or questions can be added to an online form, such as Google Forms. Allow 5-10 minutes for students to complete the assessment. The pre-assessment will allow you to gather evidence of students’ readiness before beginning the unit. This evidence can help you identify and meet learners’ needs. Students will take the Unit Assessment again at the end of the unit. Comparison of the Pre and Post-Unit Assessments can provide you with evidence of student learning and engagement with the unit. The Pre and Post Unit Assessments can also be shared with students as a means for them to reflect on their learning.

In this activity, students begin to define the characteristics of a system.

Present the Lesson 1 presentation

Slide 2: Every day we face complex problems related to health and medicine, nutrition and agriculture, the environment, social justice, and many other important topics. What is an important complex problem you have noticed? (potential student responses: opioid crisis, plastics in the oceans, gun violence, etc.) To address these complex problems we need all members of our society working collaboratively to make informed decisions, design innovative solutions, and to prevent new challenges from arising.  To do this will require collaboration, systems approaches and systems thinking skills. So, what is a system?

Slide 3: Have students complete the “Is it a System?” worksheet . This can be done on paper, or the questions and items listed can be transferred to an online survey or polling tool. You can also post this slide and have students write their answers on paper or annotate the slide if using Zoom. Have students select all the items on the list they think are a system. There is no absolute correct answer; this is just an opportunity for students to start thinking about what a system is. After they have completed that task they should spend a few more minutes writing what they think defines a system, or how they would explain a system to someone else. Once students are finished, assess which items students selected as a system. This can be done by raising hands, or if using online tools, showing survey or poll results, or sharing via a chat box. Point out any items that were selected by only a few or no students. Facilitate a discussion amongst the group about why these items should or should not be selected as a system. This leads into students sharing their definitions of what a system is.

*Note: A system is a group or collection of things or elements (including processes) that are interrelated and interdependent, thus have some influence on one another and the whole (AAAS 1989; Arnold & Wade Procedia CS 2015).  Systems can be manufactured objects (thermometer, bicycle, cell phone, electrical circuit), life-forms (grasshopper, human body, seed, cell), combinations of living and nonliving things (food web, aquarium, ocean, soil, Earth), physical bodies (volcano, Earth and its Moon), processes (water cycle, hurricane, digestion), or quantitative relationships (Density = Mass/Volume, A + B = C, graph). In this list, the only 2 things that most people determine are not a system are the pile of sand and the box of nails because the individual nails don’t influence one another, if you removed one, it would still be a box of nails. Same for the pile of sand.  However, some students will defend that they are. As long as students can justify their answer there is no right or wrong answer.

Slide 4: Summarize for students that systems are made of parts, connections between those parts, and dynamics. This will provide structure for thinking about systems for the remainder of the module.

In this activity, students learn how models can be used to understand systems, and how to use the online modeling tool, Loopy.

>Continue to present the Lesson 1 presentation

Slide 5: Prepare the students that they are now going to explore a complex system. This is Ray Williams, Managing Director of the Black Farmers Collective in Seattle, WA, and an Urban Farmer.

Slide 6 : While watching the video together students should write down the part’s of Ray’s system that they see and/or hear.

Slide 7: Watch the video featuring Ray Williams and the urban farm, Yes Farm. The video is embedded in the presentation, but can also be played on its own @ https://youtu.be/ZMI1zOraNjU

*Note: if you are unable to use the video, you can access a 1-page profile of Yes Farm that contains similar information. If you want to have a deeper discussion on Yes Farm or urban farming in general you can use this 1-page question sheet or the general questions listed in Option 3 of the Career Connections Overview page . Also see suggested activities in the Career Connections section below.

Slide 8: In the video, Ray talks about his goals of engaging the community and affecting change. He also discusses many different parts of his system and the many people and organizations that contribute. After the video students will share the parts that they noticed. This can be done as a think-pair-share in-person, or if you are remote students can add the parts to chat.

*Note: Showcase the complexity of the system by sharing with students your notice of similarities and differences amongst the parts they identified as well as the diversity of the parts.

Slide 9: In the video, Ray talks about engaging with students to build knowledge about systems [1:00 – 1:53]. Continue the discussion with students by asking them “How does identifying the parts of the system help us understand how systems work and how they can be affected?”

*Note: By identifying the parts of a system, we can start thinking about relationships between these parts, and areas we can leverage to better understand how the system works and how to make improvements if they are wanted or needed.

Explain to students that to truly understand relationships and contributions of each part of a system, Ray and other STEM professionals would create a model of their system.

Slide 10: Modeling systems can be a powerful process and tool as we strive to improve understanding, make choices, and take action. To demonstrate that process, today we are going to build a model of one subsystem from Ray’s complex system.

Slide 11: Before we begin that process I want us to think a bit more about the power and limitations of models.  “All models are wrong, but some are useful” is a famous quote by statistician George E.P. Box. Any thoughts on what this quote means?

A model is just a simplified representation of a system. Models always fall short of the complexities of reality but are still useful in helping us create a visual representation of a complex system so we can understand and predict the way the system works. As our knowledge about the system grows so does our model. So in that way models are always changing. This is important to emphasize to students as they begin building systems models.

*Note: You can learn more about this quote and its meaning on Wikipedia . You can read more about models and the importance of models in science and science education in Chapter 6 of  NSTA’s “ Helping Students Make Sense of the World Using Next Generation Science & Engineering Practices ”, as well as Chapter 6 of “ Ambitious Science Teaching ” by Windschitl, Thompson and Braaten (2018).

Slide 12: This activity will be composed of two parts. In part 1, I will demonstrate how to use the online modeling tool, Loopy , by modeling part of Ray’s system. In part 2, you will work in small groups to generate ideas and build on the model.

Slide 13: As a reminder, systems include parts, connections between those parts, and dynamics or movement. So when we create a systems model we need to include all of those pieces. 

Slide 14: In our model, we represent the parts as “nodes”, which are depicted as circles. The slide shows 2 of the parts from Ray’s system, traffic and pollution.

Slide 15: Connections and dynamics are represented by edges, which are depicted by lines. And in some cases arrows, if we know the cause and effect relationship between the nodes. In Ray’s system we know that traffic causes pollution, so our arrow goes from traffic, the cause, to pollution, the effect

Slide 16: In our model, we also want to indicate whether a part is adding to or taking away something from the system. This is depicted by “+” and “-” signs over the edges. Since traffic is adding pollution to our system, we add a + sign over the edge.

Slide 17: In contrast, if our model instead was looking at the effects of traffic on our ability to be on time, we would add a minus sign over the edge because traffic is taking away or negating our ability to be on time.

Note: More information about systems and systems modeling can be found on our Computational Modeling module “ Introduction to Systems and Modeling ”

Slide 18: Loopy is an online tool that allows us to create models and easily visualize the dynamics of a system

Systems models can be created on paper, you don’t have to use Loopy. However, Loopy is a fun tool that can easily be integrated into an online learning space. And, in the professional world computational tools eventually become a necessity as models get more and more complex, so using Loopy can be a way to introduce students to professional tools. As you demonstrate how to use Loopy, students can listen, or try Loopy out as you talk. You will want to demonstrate how to create a simple model in 3 steps. You can create your own model or use one of the 3-node models we have developed for you.

• Model 1 includes: stay home – traffic – pollution ( http://bit.ly/YesFarm1 )
• Model 2 includes: trespassing – Urban farm – community ( http://bit.ly/YesFarm2 )

Note: There are many tutorials on the Loopy site to help you. You can also refer to the instructions in our other module  “ “>Introduction to Loopy – Modeling a Bad Day”

Step 1 – Draw the first 2 nodes with a positive edge connecting them to model the cause and effect relationship. Play the model to demonstrate this relationship.

• Model 1: traffic -> pollution
• Model 2: Urban farm -> community

Step 2 – Introduce a phenomena.

• Model 1: Show this Seattle Times article demonstrating how early stay-at-home orders due to COVID led to decreases in Seattle traffic.
• Model 2: Replay a portion of the Yes Farm tour video [2:07 – 2:28]

Step 3 – Integrate this phenomenon into the model

• Model 1: To explore the relationship between staying home and our model in Step 1, we are going to add a new “stay home” node. The “stay home” node should be a different color than the “traffic” and “pollution” nodes to depict the addition of a new part into an existing system. Create a new edge to connect “stay home” and “traffic”. Ask the students whether this should be a positive or negative edge and why. It will be a negative edge because staying home causes a reduction in traffic. Once the model is complete show them how to save the model as a short bit.ly link and share the link with them.
• Model 2: Ray discusses many challenges faced on an urban farm. One of those challenges is people cutting through the fence and trespassing through the gardens. To explore the impacts of these challenges and how their mitigation steps help to address these challenges we are going to add a new “trespassing” node into our model. The “trespassing” node should be a different node to depict the addition of a new part into an existing system. Create a new edge to connect “trespassing” and “Urban farm”. Ask the students whether this should be a positive or negative edge and why. It will be a negative edge because trespassing causes damage to the urban farm. Once the model is complete show them how to save the model as a short bit.ly link and share the link with them.

Slide 19: Now we’re going to put you into breakout groups to build on this model for about 15 minutes. Start by brainstorming with your group what parts you want to build into the model – discuss ways to mitigate the negative effects and / or elaborate on impacts to this system. Choose a “Loopy Leader” who will share their screen and modify the Loopy model based on node and edge suggestions from the group.  Be sure to pause periodically to test your model to ensure the dynamics of your model look how you want them to.  When you are done, be sure to save your model as a new bit.ly link, otherwise, the changes will not be saved. When we all come back together, each group will share their bit.ly link and give a brief overview of their model and thought process.

Divide students up into small groups to brainstorm how to add to the Loopy model. They can discuss ways to mitigate the negative effects and / or elaborate on impacts to this system. The main idea is for them to start thinking about connections to this system and to become familiar with using Loopy as a modeling tool. Provide students with at least 15 minutes for this activity. Remind them to save their modified model as a new bit.ly link or they will lose all of their work. Here are some examples of built-out models. These should be used to guide your professional learning, not as “correct” models students should be able to replicate.

• Model 1: https://bit.ly/YesFarm1example1 ; https://bit.ly/YesFarm1example2 ; https://bit.ly/YesFarm1example3
• Model 2: http://bit.ly/YesFarm2example

Slide 20: Each group will share their model with the class. Members of the group will give a brief overview of their thinking and approach. Give each group 1-3 minutes to present. Allow 1-2 minutes after each presentation for the class to provide positive feedback on what they liked and ways they could incorporate ideas from that model into their own model. Be sure to collect the bit.ly links from each group if you want to review their work in greater detail. You can provide feedback to each group during their presentation or as a follow-up. The feedback should provide students with ideas on ways they could add to the model, or ask more questions on why they chose to model things in a particular way.

Modeling is an iterative process. If time allows, you can have students further develop their model after receiving feedback and seeing other models.

At the end of Lesson 1, your students will be ready for their first Career Connected Activity (CCA). These are called Career Connected Activities because they: 1) highlight STEM careers, and 2) are connected specifically to the learning that took place in the lesson. These activities have been crafted to build awareness (especially for unique STEM careers and pathways), identity and to build “soft” skills such as 21st Century Learning Skills.

To plan for this, first consider how much time you want to devote to this additional content. For each lesson, we offer four options, listed in columns as A-D. You can mix and match the options for each lesson. This means you can have some of these activities take place in class and some out of class (as homework). Based on how much time you have available, choose one section of the career connected activity below. For every one of these four options, prior to beginning the CCA, first recap what your students learned in the lesson they just completed. This will help them internalize the content of the CCA to improve the positive impact of these activities.

What to do if you have this much time available:

How will I know they know?

A Unit Assessment is provided to summatively assess student learning. We recommend having students take this unit assessment before starting the module (Pre-assessment) and after completing all three lessons of the module (Post-assessment). Comparison of the Pre and Post assessments can be used to demonstrate growth in student learning.

There are several formative assessments that are built within this lesson.  These include the:

• “Is it a System?” worksheet (which includes options for an online survey, polling, annotations and/or discussion)
• Notes and discussion around Ray Williams’ video and profile and the Lesson 1 presentation
• Loopy models created and submitted by individual students and/or groups of students and the group share-out after these are created in breakout rooms

And/or you can formatively assess student learning in these lessons using your choice of exit ticket format. Suggested questions:

• What did you learn today that surprised you?
• What are you excited to learn more about?
• What questions do you have at this point?
• Model 1 includes: stay home – traffic – pollution ( http://bit.ly/YesFarm1 )
• Model 2 includes: trespassing – Urban farm – community ( http://bit.ly/YesFarm2 )
• Seattle Times article  demonstrating how early stay-at-home orders due to COVID led to decreases in Seattle traffic.
• Unit Pre-Assessment  – 1 per student
• “Is it a System” worksheet  – 1 per student
• For a deeper discussion on Yes Farm or urban farming, you can also use this 1-page question sheet or the general questions listed in  Option 3 of the Career Connections Overview page .
• Wikipedia page on positive feedback loops: https://en.wikipedia.org/wiki/Positive_feedback
• Wikipedia page on negative feedback: https://en.wikipedia.org/wiki/Negative_feedback
• “All models are wrong, but some are useful” quote and its meaning: Wikipedia .
• Chapter 6 of  NSTA’s “ Helping Students Make Sense of the World Using Next Generation Science & Engineering Practices ”
• Chapter 6 of “ Ambitious Science Teaching ” by Windschitl, Thompson and Braaten (2018)
• ISB Computational Modeling modules referenced:
• “ Introduction to Systems and Modeling ”
• “ Introduction to Loopy – Modeling a Bad Day”
• Jamboard Google collaboration tool: https://gsuite.google.com/products/jamboard/
• Systems Thinkers in STEM Career Connection resources: https://see.isbscience.org/systems-thinkers/career-connection-overview
• Bitly Custom URL Shortener: https://bitly.com/

ELL students may benefit from a vocabulary list and peer notes that correspond with the module. Also, the videos can be viewed with closed captioning via YouTube.

• Student Program Design Principles
• Curriculum Development
• Publications
• Testimonials
• For Students
• High School Intern Programs
• System Thinkers in STEM Ambassador Program
• Ambassador Showcase
• High School Student Opportunities FAQ
• High School Intern Websites
• Computational Modeling Workgroups
• STEAM Towards a Healthier World
• For Partners
• For Teachers
• Teacher Opportunities
• Community Contributed Modules
• Curriculum Module Adaptations
• Curriculum Modules
• Bioengineering a Sustainable World
• Ecological Networks
• Environmental Influence on Gene Networks
• Food Security
• Introduction to Systems
• Invisible Forest
• Modeling Sustainable Food Systems
• Observing Beyond our Senses:Inquiry Drives Technology
• Ocean Acidification: A Systems Approach to a Global Problem
• Systems are Everywhere
• Systems Medicine
• Systems Thinkers in STEM
• Project Feed 1010

Institute for Systems Biology is a nonprofit scientific research organization located in Seattle © 2024 · All Rights Reserved · Baliga Systems Education Experiences

RSS Feed · Log in

Powerpoint Templates

Icon Bundle

Kpi Dashboard

Professional

Business Plans

Swot Analysis

Gantt Chart

Business Proposal

Marketing Plan

Project Management

Business Case

Business Model

Cyber Security

Business PPT

Digital Marketing

Digital Transformation

Human Resources

Product Management

Artificial Intelligence

Company Profile

Acknowledgement PPT

PPT Presentation

Reports Brochures

One Page Pitch

Interview PPT

All Categories

Systems Design Powerpoint Presentation Slides

Improve product quality and performance along with providing the value to the company using content-ready Systems Design PowerPoint Presentation Slides. Create a customize application or design with existing or new hardware through ready-to-use systems designs PPT presentation templates. This professionally designed systems integration PowerPoint presentation deck covers topics like star integration, common data format, vertical and horizontal integration, and more. Incorporate relevant system integration process steps to help your company save time and money. Choose the best system to manage business operations. With systems design PPT presentation, enhance employee communication and collaboration, increase productivity, intensify real time data visibility, etc. Improve data accuracy, organizational change readiness by executing the system design process accurately. Add system integration PowerPoint templates for better products and services. Not just this, it will help you evaluate your business, have all data in one place, improve system security, accelerate growth and innovation, and more. Get access to the system design PowerPoint presentation slides for improved systems to enhance performance of the business. Find the design that highlights your cause in our Systems Design Powerpoint Presentation Slides. Insert the image of your choice.

These PPT Slides are compatible with Google Slides

Compatible With Google Slides

• Google Slides is a new FREE Presentation software from Google.
• All our content is 100% compatible with Google Slides.
• Just download our designs, and upload them to Google Slides and they will work automatically.
• Amaze your audience with SlideTeam and Google Slides.

Want Changes to This PPT Slide? Check out our Presentation Design Services

Get Presentation Slides in WideScreen

Get This In WideScreen

• WideScreen Aspect ratio is becoming a very popular format. When you download this product, the downloaded ZIP will contain this product in both standard and widescreen format.

• Some older products that we have may only be in standard format, but they can easily be converted to widescreen.
• To do this, please open the SlideTeam product in Powerpoint, and go to
• Design ( On the top bar) -> Page Setup -> and select "On-screen Show (16:9)” in the drop down for "Slides Sized for".
• The slide or theme will change to widescreen, and all graphics will adjust automatically. You can similarly convert our content to any other desired screen aspect ratio.
• Add a user to your subscription for free

You must be logged in to download this presentation.

Do you want to remove this product from your favourites?

PowerPoint presentation slides

Presenting system designs PowerPoint presentation slides. This deck comprises of 28 uniquely designed slides. Our PowerPoint experts have included all the necessary templates, designs, icons, graphs and other essential material. This deck is curated after an extensive research. Slides consists of amazing visuals and appropriate content. These PPT slides can be instantly downloaded with just a click. Easily editable. Compatible with all screen types and monitors. Supports Google Slides. Premium Customer Support available.

People who downloaded this PowerPoint presentation also viewed the following :

• Business Slides , Flat Designs , Technology and Communication , Complete Decks , All Decks , General , Mini Decks , General
• System Integration ,
• Systems Design ,
• Systems Engineering

Content of this Powerpoint Presentation

Slide 1 : This slide introduces Systems Design. State Your Company Name and begin. Slide 2 : This slide shows Our Agenda. Use it to add your business agenda. Slide 3 : This slide showcases System Integration Template 1. We have mentioned some of the relavant icon with text boxes. You can use as per your requirement. Slide 4 : This slide presents System Integration Template 2. Given are some of the parameters in slide- Products from different vendors, Application from different vendors, Cloud (Private, Public, Hybrid), New feature Implementation, Customization,  Data from diverse domains. Slide 5 : This slide shows System Integration Template 3. Some the important facors we have put in slide, you can add as per requirement. ERP, Internal Applications, Business Processes, Legacy Systems, Database, CRM. Slide 6 : This slide showcases System Integration Template 4. Major steps for integration we have mentioned such as- Planning, Implementation, Support, System Integration. Slide 7 : This slide presents System Integration Template 5. This is presenting in flow diagram with these parameters- System Integration Services, Understand Business Context, Identify Supporting Applications, Identify required Infrastructure, Gauge your Readiness, Create a Governance System. Slide 8 : This slide showcases System Integration Template 6 which is showing these main parameters- System Integration, Strategic Integration. Slide 9 : This slide displays System Integration Template 7 with relevant icons it is showing. You can add your content and use as per your requirement. Slide 10 : This slide showcases System Integration Template 8. This slide also include - Data Acquisition, Visualisation, Networking, Control & Automation. Slide 11 : This slide diplays Icons. You can use as per requirement. Slide 12 : This slide is a Coffee Break image for a halt. Slide 13 : This slide is titled Additional Slides. Slide 14 : This slide showcases Our Team with Name and Designation to fill. Slide 15 : This slide displays Our Target with a background image. Slide 16 : This is a Venn diagram image slide to show information, specifications etc. Slide 17 : This is a Quotes slide to convey message, beliefs etc. Slide 18 : This slide showcases a Puzzle with imagery. Slide 19 : This slide displays a Bulb or idea image. Slide 20 : This slide showcases Project Locations with a World map and text boxes to make it explicit. Slide 21 : This slide shows a Magnifying glass with text boxes. Slide 22 : This is a Timeline slide to show milestones, growth or highlighting factors. Slide 23 : This slide forwards to Charts & Graphs. Slide 24 : This slide diplays pie chart for comparison of four products.  Slide 25 : This is a Bar Graph image slide to show product comparison, growth etc. Slide 26 : This slide shows Critical areas to be assessed and worked on. Slide 27 : This is a Radar Chart slide for product/entity comparison. Slide 28 : This is a Thank You slide with Address# street number, city, state, Contact Numbers, Email Address.

Systems Design Powerpoint Presentation Slides with all 28 slides:

Ensure gains all around with our Systems Design Powerpoint Presentation Slides. They help you dole it out.

Ratings and Reviews

by Taylor Hall

July 21, 2021

by Curtis Herrera

July 20, 2021

• Preferences

System models - PowerPoint PPT Presentation

System models

Data flow models may be used to show the processes and the flow of ... state machine models show system states as nodes and events as arcs between these nodes. ... – powerpoint ppt presentation.

• Abstract descriptions of systems whose requirements are being analysed
• Context models
• Behavioural models
• DFD diagrams and process models
• state machine diagrams or statecharts or state transition diagrams
• sequence and collaboration diagrams
• Data models
• Class models
• associations, inheritance, aggregation
• Different models present the system from different perspectives
• External perspective showing the systems context or environment
• Behavioural perspective showing the behaviour of the system
• Structural perspective showing the system or data architecture
• Structured methods incorporate system modelling as an inherent part of the method
• Methods define a set of models, a process for deriving these models and rules and guidelines that should apply to the models
• CASE tools support system modelling as part of a structured method
• They do not model non-functional system requirements
• They do not usually include information about whether a method is appropriate for a given problem
• Data processing model showing how the data is processed at different stages
• Composition model showing how entities are composed of other entities - aggregation
• Architectural model showing principal sub-systems
• Classification model showing how entities have common characteristics
• Stimulus/response model showing the systems reaction to events
• Process models show the overall process and the processes that are supported by the system
• Data flow models may be used to show the processes and the flow of information from one process to another
• Behavioural models are used to describe the overall behaviour of a system
• Three types of behavioural model are shown here
• Data processing models that show how data is processed as it moves through the system
• State machine models that show the systems response to events
• Interaction diagrams showing object communication and behaviour
• More than one of these models are required for a description of the systems behaviour
• Data flow diagrams are used to model the systems data processing
• These show the processing steps as data flows through a system
• Intrinsic part of many analysis methods
• Simple and intuitive notation that customers can understand
• Show end-to-end processing of data
• DFDs model the system from a functional perspective
• Tracking and documenting how the data is associated with a process is helpful to develop an overall understanding of the system
• These model the behaviour of the system in response to external and internal events
• They show the systems responses to stimuli so are often used for modelling real-time systems
• In structured A D, state machine can show which unit of functionality is activated in response to an event or interupt or control item see photocopier example
• State machine models show system states as nodes and events as arcs between these nodes. When an event occurs, the system moves from one state to another
• Statecharts are an integral part of the UML
• In the UML, a state machine diagram can show possible states of an object or be an activity diagram
• Allow the decomposition of a model into sub-models (see following slide)
• A brief description of the actions is included following the do in each state
• Can be complemented by tables describing the states and the stimuli
• Used to describe the logical structure of data processed by the system
• Entity-relation-attribute model sets out the entities in the system, the relationships between these entities and the entity attributes
• Widely used in database design. Can readily be implemented using relational databases
• No specific notation provided in the UML but classes and associations can be used
• Data dictionaries are lists of all of the names used in the system models. Descriptions of the entities, relationships and attributes are also included
• Support name management and avoid duplication
• Store of organisational knowledge linking analysis, design and implementation
• Many CASE workbenches support data dictionaries
• Object models describe the system in terms of object classes
• An object class is an abstraction over a set of objects with common attributes and the services (operations) provided by each object
• Various object models may be produced
• Inheritance models
• Association models
• Aggregation models
• Interaction models
• Natural ways of reflecting the real-world entities manipulated by the system
• More abstract entities are more difficult to model using this approach
• Object class identification is recognised as a difficult process requiring a deep understanding of the application domain
• Object classes reflecting domain entities are reusable across systems
• Organise the domain object classes into a hierarchy
• Classes at the top of the hierarchy reflect the common features of all classes
• Object classes inherit their attributes and services from one or more super-classes. these may then be specialised as necessary
• Class hierarchy design is a difficult process if duplication in different branches is to be avoided
• Devised by the developers of widely used object-oriented analysis and design methods
• Has become an effective standard for object-oriented modelling
• Object classes are rectangles with the name at the top, attributes in the middle section and operations in the bottom section
• Relationships between object classes (known as associations) are shown as lines linking classes
• Inheritance is referred to as generalisation and is shown upwards rather than downwards in a hierarchy
• Rather than inheriting the attributes and services from a single parent class, a system which supports multiple inheritance allows object classes to inherit from several super-classes
• Can lead to semantic conflicts where attributes/services with the same name in different super-classes have different semantics
• Makes class hierarchy reorganisation more complex
• Aggregation model shows how classes which are collections are composed of other classes
• Similar to the part-of relationship in semantic data models
• A behavioural model shows the interactions between objects to produce some particular system behaviour that is specified as a use-case
• Sequence and collaboration diagrams in the UML are used to model interaction between objects

PowerShow.com is a leading presentation sharing website. It has millions of presentations already uploaded and available with 1,000s more being uploaded by its users every day. Whatever your area of interest, here you’ll be able to find and view presentations you’ll love and possibly download. And, best of all, it is completely free and easy to use.

You might even have a presentation you’d like to share with others. If so, just upload it to PowerShow.com. We’ll convert it to an HTML5 slideshow that includes all the media types you’ve already added: audio, video, music, pictures, animations and transition effects. Then you can share it with your target audience as well as PowerShow.com’s millions of monthly visitors. And, again, it’s all free.

About the Developers

PowerShow.com is brought to you by  CrystalGraphics , the award-winning developer and market-leading publisher of rich-media enhancement products for presentations. Our product offerings include millions of PowerPoint templates, diagrams, animated 3D characters and more.

Welcome to the MIT CISR website!

This site uses cookies. Review our Privacy Statement.

Scaling AI: Sustaining AI @Scale—Session Presentation

Why can't i view this research.

This presentation from MIT CISR's 2024 European International Executive Forum event is available only to logged-in members and attendees of the event.

See the list of MIT CISR members

Related publications.

Research Briefing

Building ai explanation capability for the ai-powered organization.

Building Advanced Data Monetization Capabilities for the AI-Powered Organization

Working Paper: Vignette

Microsoft’s ai scaling journey for occupancy prediction.

About the Researcher

Barbara H. Wixom, Principal Research Scientist, MIT Center for Information Systems Research (CISR)

Mit center for information systems research (cisr).

Founded in 1974 and grounded in MIT's tradition of combining academic knowledge and practical purpose, MIT CISR helps executives meet the challenge of leading increasingly digital and data-driven organizations. We work directly with digital leaders, executives, and boards to develop our insights. Our consortium forms a global community that comprises more than seventy-five organizations.

MIT CISR Associate Members

MIT CISR wishes to thank all of our associate members for their support and contributions.

MIT CISR's Mission Expand

MIT CISR helps executives meet the challenge of leading increasingly digital and data-driven organizations. We provide insights on how organizations effectively realize value from approaches such as digital business transformation, data monetization, business ecosystems, and the digital workplace. Founded in 1974 and grounded in MIT’s tradition of combining academic knowledge and practical purpose, we work directly with digital leaders, executives, and boards to develop our insights. Our consortium forms a global community that comprises more than seventy-five organizations.