Many beginners learn and do modeling by studying a particular modeling language, such as Unified Modeling Language (UML). In my experience, this is not good. It makes it harder to understand and grasp the basic concepts and ideas. This results in a significant waste of time and misuse of modeling techniques. Learning modeling by studying a modeling language forces you to focus on how to model something rather than focusing on what should be modeled first. The most effective way learn modeling is by learning and understanding what exactly should be modeled first, and only then how it should be modeled! In this article I’d like to share with you some basics of what to model.
In order to effectively use different modeling techniques, it is important to understand different system aspects that have to be modeled. Most modeling techniques focus on modeling a particular aspect of a domain system. Although, in many articles in software and systems engineering literature, this division is represented slightly differently, there are five main aspects of a system that should be modeled:
- functional aspects,
- behavioral aspects,
- conceptual decomposition aspects,
- communicational aspects, and
- interface aspects.
Functional aspects describe functions that a system or a component provides. Behavioral aspects describe how functions are temporally or logically related. Conceptual decomposition aspects describe a breakdown of a system into subsystems, components, data entities, devices, etc. Communicational aspects describe how functions and concepts interact, i.e., how they are spatially related. Interface aspects describe protocols for accessing a system’s or a component’s functionality, i.e., the intersection of the conceptual decomposition and the communication concerns.
A typical further division is on the system and internal aspects. System aspects describe the system as a black box, and thus we have system functions, system behavior, system communication with the system’s environment, system interfaces, and system conceptual decomposition with respect to system’s environment. Internal aspects describe the properties of the internal components of the system. At this level, we usually see component functions, component behavior, component communication, component interface, and internal conceptual decomposition specifications. This division on the system and internal aspects, although important, is not particularly relevant from the perspective of the modeling techniques as the same techniques are typically used to specify both system and internal aspects of the system. So, the same techniques apply for modeling of the system as a whole as well as for the modeling of its components. The same applies to any intermediate decomposition levels.
Another typical division is on analysis models and design models. Analysis models describe a domain system, while design models describe software system that will partially or fully automate the domain system. Again, from the perspective of the modeling techniques, this division does not make any difference since you’ll be using the same modeling techniques both for modeling of the domain system (analysis model) and software system (design model).
So, before studying a particular modeling language and how to model, try to learn what has to be modeled. Learning the basic aspects of systems helps in handling the difficulties that arise from the fact that systems are composite in nature and that we commonly deal with multiple systems, i.e. domain systems and the systems that we are currently building.
Reference and an excellent further reading:
R.J. Wieringa. A survey of structured and object-oriented software specification methods and techniques. ACM Computing Surveys, 30(4):459-527, December 1998.