Domain-Oriented architecture design for production control software

In this paper, we present domain-oriented architectural design heuristics for production control software. Our approach is based upon the following premisses. First, software design, like all other forms of design, consists of the reduction of uncertainty about a final product by making design decisions. These decisions should as much as possible be based upon information that is certain, either because they represent laws of nature or because they represent previously made design decisions. An import class of information concerns the domain of the software. The domain of control software is the part of the world monitored and controlled by the software; it is the larger system into which the software is embedded. The software engineer should exploit system-level domain knowledge in order to make software design decisions. Second, in the case of production control software, using system-level knowledge is not only justified, it is also imposed on the software engineer by the necessity to cooperate with hardware engineers. These represent their designs by means of Process and Instrumentation Diagrams (PIDs) and Input-Output (IO) lists. They do not want to spend time, nor do they see the need, to duplicate the information represented by these diagrams by means of diagrams from software engineering methods. Such a duplication would be an occasion to introduce errors of omission (information lost during the translation process) or commission (misinterpretation, misguided but invisible design decisions made during the translation) anyway. We think it is up to the software engineer to adapt his or her notations to those of the system engineers he or she must work with. Third, work in patterns and software architectures started from the programminglanguage level and is now moving towards the higher architectural and subsystem level. At the programming-language level, one is able to define domain-independent patterns such as adapter, facade and observer [3]. At higher levels, however, architectures get more domain-specific and we need to relate software architectures to domain architectures. In the case of production control, we should reflect the structure of the production process in the architecture of the software. In this working paper, we apply these principles to the definition of a coordination architecture for production control software. In section 2, we look at the information contained in PIDs and IO lists for production systems and at the structure of a production process.

[1]  Ralph Johnson,et al.  design patterns elements of reusable object oriented software , 2019 .

[2]  Peter Sommerlad,et al.  Pattern-Oriented Software Architecture: A System of Patterns: John Wiley & Sons , 1987 .

[3]  H.J.J. Kals,et al.  A generic architecture for factory activity control , 1996 .

[4]  Michael Jackson,et al.  Domain descriptions , 1993, [1993] Proceedings of the IEEE International Symposium on Requirements Engineering.

[5]  R.G.R. Engmann,et al.  An environment for object-oriented real-time systems design , 1997, Proceedings 8th Conference on Software Engineering Environments.

[6]  Stephen M. McMenamin,et al.  Essential systems analysis , 1984 .

[7]  Roel Wieringa,et al.  Postmodern Software Design with NYAM: Not Yet Another Method , 1997, Requirements Targeting Software and Systems Engineering.

[8]  Michael A. Jackson,et al.  Software requirements and specifications - a lexicon of practice, principles and prejudices , 1995 .