In this topic you will be introduced to System Modelling as it applies to software engineering. In the next topic you will look in some detail at a specific type of system modelling called UML.
In many disciplines models are using to provide a graphical representation of phenomena or systems. Through the COVID pandemic regular reference was made to role of modeller in the tracking of the virus and the anticipated trajectory of case given certain factors occurring.
In software development the use of models is prevalent throughout the process. In the last topic on Requirement Engineering, you were introduced to a number of models for example. In this topic system modelling will be defined and its role and purpose in the software development lifecycle. Models are actually necessary to provide better understanding of the system being developed.
Models are used during the requirements engineering process to help derive the requirements for a system, during the design process to describe the system to engineers implementing the system and after implementation to document the system’s structure and operation.
You may develop models of both the existing system and the system to be developed:
- 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.
System modelling is the process of developing abstract models of a system, with each model presenting a different view or perspective of that system. It is used to help stakeholders understand how system functions.
It is commonly understood that system modelling refers to use of graphical notation to represent the software. Unified Modelling Language is the most commonly used notation system and is discussed in detail in the next topic.
The most important aspect of a system model is that it leaves out detail. 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 but unfortunately, the real world is complex, so you need to take steps to simplify things. An abstraction consciously simplifies and picks out the most evident characteristics of the system whilst remaining accurate.
You may develop different models to represent the system from different perspectives (Sommerville, 2010). Let’s look briefly at these system perspectives:
- External Perspective: this involves the modelling of the context or environment of the system
- Interaction Perspective: considers the interactions between a system and its environment, or between the components of a system
- Structural Perspective: focuses on modelling the organisation of a system or the structure of the data that is processed by the system
- Behavioural Perspective: this where you model the dynamic behaviour of the system and how its responds to events
When developing system models, you can often be flexible in the way that the graphical notation is used. You do not always need to stick rigidly to the details of a notation. 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. They can be used as a means of facilitating discussion about an existing or proposed system. In these cases, using incomplete and incorrect models are OK as their role is to support discussion. When using models to document an existing system they should be an accurate representation of the system, but they don’t need to complete. Correct and complete models are used to provide a detailed system description that can be used to generate a system implementation.
There are a number of system models that are used. Sommerville (2010) identifies four important model types. Each model has a specific purpose, and they will be outlined in this section of the topic. We will look at the following models:
- Context Models
- Behavioural Models
- Interaction Models, and
- Structural Models
Context Model
At an early stage in the specification of a system, you should decide on 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.
You may decide that automated support for some business processes should be implemented but others should be manual processes or supported by different systems. You should look at possible overlaps in functionality with existing systems and decide where new functionality should be implemented. These decisions should be made early in the process to limit the system costs and the time needed for understanding the system requirements and design.
In some cases, the boundary between a system and its environment is relatively clear. For example, where an automated system is replacing an existing manual or computerized system, the environment of the new system is usually the same as the existing system’s environment. In other cases, there is more flexibility, and you decide what constitutes the boundary between the system and its environment during the requirements engineering process.
Once some decisions on the boundaries of the system have been made, part of the analysis activity is the definition of that context and the dependencies that a system has on its environment. Normally, producing a simple architectural model is the first step in this activity.
Context models are used to illustrate the operational context of a system - they show what lies outside the system boundaries. They are often depicted as box and line diagrams since such simple diagrams are enough to put the system into context with other systems.
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. It is important to note that the position of the system boundary has a profound effect on the system requirements, and the definition of boundaries can get quite ‘political’ at time as there may be pressures to develop system boundaries that increase / decrease the influence or workload of different parts of an organization for example.
Let’s look at an example to illustrate.
In this case we are looking at the process for an online ordering system, or rather some aspects of that system. In this case the proposed system deals with neither the details of payment (e.g., allowing payment with credit card, the issuing bank's system needs to be accessed) nor the shipment of the purchased product. It is outside the responsibilities of the system to maintain up-to-date information on the stock items. This information is contained in an inventory database that can be updated if new items arrive to stock separately from the online store application.
Let’s create a context model for the case study below:
Can you see where the boundaries of this system are? Which functionalities are part of system and which ones are external to the system. Did you note that the system bounded by the box is divided into two parts – the online store and the admin application. The online store is what customers meet and contains all the functionalities they required by customers and the admin application captures all the administrative duties of the system. Note that no information is given about how often the admin application will be used, or the fact that different technologies might be used for the online store, but this is not the system modelling that used in the development phase where those decisions are made, but the rationale for the separation is evident.
A context model is used to show that the system's environment contains other systems but the types of relationships between the systems of the environment and the system that is being specified are not shown.
Interaction Model
All systems involve interaction of some kind. Interaction models can used to show user interaction which is important as it helps to identify user requirements, or they can model system-to-system interaction which are used to highlight the communication problems that may arise. Component interaction help you understand if a proposed system structure is likely to deliver the required system performance and dependability.
With regard to interaction modelling Sommerville (2010) posits two (complementary) approaches:
- Use case modeling, which is mostly used to model interactions between a system and external actors (users or other systems), and
- Sequence diagrams, which are used to model interactions between system components, although external agents may also be included.
These models are complementary because they present interaction at different levels of detail and so may be used together. For example, the details of the interactions involved in a high-level use case may be documented in a sequence diagram.
Let’s look at Use Case modelling.
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, and they can be represented diagramatically to provide an overview of the use case and in a more detailed textual form. Here is more information on Use Case Modelling. You cover these models in the next topic in some more detail.
Behavioural Model
Behavioral models are models of the dynamic behavior of the 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: Data arrives that has to be processed by the system, and
- Events: Some kind of event happens that triggers system processing. Events may have associated data, but this is not always the case.
Data-driven models show the sequence of actions involved in processing input data and generating an associated output. These models are particularly useful during the analysis of requirements as they can be used to show end-to-end processing in a system.
Event-driven modeling shows how a system responds to external and internal events. These models are based on the assumption that a system has a finite number of states and that events (stimuli) may cause a transition from one state to another.
Structural Model
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. These are not the same things—the dynamic organization of a system as a set of interacting threads may be very different from a static model of the system components.
You create structural models of a system when you are discussing and designing the system architecture. Architectural design is a particularly important topic in software engineering and UML component, package, and deployment diagrams may all be used when presenting architectural models. Deeper details on architectural modeling will be covered in the next chapter. Here we focus on the creation of the analysis-level class diagrams only that are useful for better understanding of the problem domain.
Domains represent the different subject matters that we need to understand to build a system. A domain is an autonomous, real, hypothetical, or abstract world inhabited by a set of conceptual entities that behave according to characteristic rules and policies. (Mellor & Balcer 2002].) We abstract like things and call them classes. In forming such abstractions, we ignore most of the things as our aim is to leave out details and concentrate only on the important aspects. The remaining things are are grouped according to some perceptions about what is means to be "like".
Domains and classes are discussed in greater detail in the next topic, along with the UML notation for structural models
In Topic 6 you will explore the application of system modelling using UML notation. The concepts discussed in this topic describe some of the aspects of system modelling that is taken further in the next topic. You will have also note the links to all the topics in this module as system modelling is one of the keys to accurately conceptualising the development of a software system from concept to production.
