Table of Contents
System modeling is the process of developing abstract models of a system, with each model presenting a different view or perspective of that system [SOMMERVILLE2010]. System modeling has generally come to mean representing the system using some kind of graphical notation, which is now almost always based on notations in the Unified Modeling Language (UML). However, it is also possible to develop formal (mathematical) models of a system, usually as a detailed system specification.
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.
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 (also knows as the universe of discourse) is utterly complex so weed to simplify. An abstraction consciously simplifies and picks out the most evident characteristics.
You may develop different models to represent the system from different perspectives [SOMMERVILLE2010]. For example:
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.
These perspectives have much in common with Krutchen’s 4 + 1 view of system architecture, where he suggests that you should document a system’s architecture and organization from different perspectives.
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:
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.
In the first case, 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. This is how models are normally used in so-called ‘agile modeling’.
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. However, these models have to be correct—they should use the notation correctly and be an accurate description of the system.
In the third case, where 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. Therefore, you have to be very careful not to confuse similar symbols, such as stick and block arrowheads, that have different meanings.
[SOMMERVILLE2010] identifies four important types of system models, namely, context models, interaction models, structural and behavioral models are introduced.
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.
Our case study does not deal with all aspects of passing an ordered item to its customer. The proposed system deals with neither the details of payment (e.g., for 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. Context models are often depicted as box and line diagrams since such simple diagrams are enough to put the system into context with other systems. The context model for our case study is shown in the following figure.
If we take a look at this picture, it is very easy the figure out where the boundaries of this system are. We can tell which functionalities belong to the system and which are those that are external to it. Due to the fact that we have users with quite different characteristics (and, hopefully, number) the system was split into two parts: the online store itself (this is what customers meet) which contains all the functionalities required by customers and an admin application that captures the administrative duties. The latter does not need to be used so frequently and there will be a lot less users with admistrative privileges therefore it seems to be a wise idea to separate them. It is also possible that different technologies will be used for these parts. However, this is not the systems modeling phase where such decisions need to be made but we wanted to give a rationale of this separation. The separated representation was the result of an analysis activity (i.e., we have found that parts with different characteristics exist) that does not tell anything about implementation technologies.
Context models normally 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. That is why it is common to create some models describing business processes showing what activities humans or automated processes will execute. UML provides activity diagrams in order to describe those high-level usiness processses.