Interfaces in Modular Systems: Some Research Questions

Leif Bonorden Universität Hamburg [email protected]

Abstract special case, which will not be further considered here, are user interfaces. Thus, in the following the environ- Modularity of software systems is well-known and supported by various theories. Interfaces and interactions between such ment also consists of other software modules and sys- software modules are differently seen and treated from differ- tems. ent points of view. Meyer’s five criteria for modularity yield three rules This article briefly surveys semi-formal models, formal for modular that deal with interfaces specifications and technical implementations, and intro- [5]: duces corresponding research questions regarding the com- • Few Interfaces. For each module, communication patibility of these perspectives with each other and their role is limited to as few other modules as possible. in the software development process. • Small Interfaces. The communicated information between modules is as small as possible. 1 Modularity in Software Systems • Explicit Interfaces. The communication of two The division of software systems into components or modules should be done explicitly and compre- modules to deal with complexity has been observed hensibly. for decades [7]. In particular, object-oriented software Based on these rules and similar results, software ar- development is an instrument to structure software chitects design systems, modules and interfaces. Be- into components – classes and objects –, but nowa- sides module interfaces, the more general subject of days the term module is used to describe larger ele- module interaction may also be considered. ments of software. In 1988, Bertrand Meyer presented five criteria for such modularity in a software develop- 2.1 A Semi-formal Modelling Perspective ment process [5]: Using the Unified (UML), inter- • Decomposability. Division into less complex faces may be depicted in class diagrams or in compo- structures that can be examined and developed nent diagrams. In class diagrams, interfaces may be separately. explicitly marked with the stereotype «interface» and • Composability. Modules can be combined with are otherwise identical to classes. In component dia- others in different settings, in particular outside grams, the interaction between components or mod- the original setting. ules is highlighted by explicit notation of interfaces. • Understandability. A human can understand each Due to the semi-formal notation of UML, the seman- module without knowing about others or only a tics of these notation may differ significantly. few others. 2.2 Formal Perspectives • Continuity. Small architectural changes in one module affect no or only some other modules. Mathematical foundations have been developed in or- der to reason abstractly about interfaces. Among the • Protection. Problems at run-time in one module areas of active research on such formal instruments affect no or only some other modules. are the following. The five criteria are used together with five rules and five principles to characterise modular soft- Modal Specification Modal automata specifications ware design. Following this approach, various ideas distinguish two types of transitions: must and may – S = (A, → , → ) of modularization have emerged – either technical, formally a tupel must may with an alpha- A e.g. service-oriented architecture (since 1998)[8], and bet and partial functions ∗ A micro-services (since 2014)[2], or organizational, e.g. →must, →may: A 7→ 2 domain-driven design (since 2004)[3]. with the condition of

2 Interfaces for Software Modules →must (a) ⊆ →may (a) In general, interfaces are considered to be the part of for each a ∈ A. A system implementing such specifica- a module that is common to – or commonly used by tions has to include all must transitions, but does not – the module implementation and its environment. A need to include all may transitions [4]. Interface Automata The transitions of an interface How can the different perspectives on interfaces and automaton are labeld as input or output – formally a module interaction be considered jointly? P = (X, x , A, →) X tuple 0 with state set , an initial • To what extend are the several formal views on in- x A state 0, an alphabet and a transition relation terfaces compatible? → ⊆ X × A × X. • Can formal specifications of interfaces and mod- ule interaction be profitably connected to semi- The theory of these automata is game-based, i.e. two formal models? players represent the environment (Input) and the module (Output), respectively [1]. • How do programming and technical details result from (semi-)formal models of module interfaces In contrast to modal specifica- and module interaction? How can this be sup- tions and interface automata, contract theory focuses ported in practice? on pre and post conditions for interactions. A contract is defined as a set of variables (input variables and out- How can theories with formal basis further advance put variables) together with their types as well as as- general (not necessarily formal) software develop- sumptions and guarantees, which lay out the respon- ment with respect to module interfaces and module sibilities of the environment and the module, respec- interaction? tively: While the environment needs to ensure the as- • Can certain flaws in the design of a system bede- sumptions, it may expect the guarantees. On the other tected through formally based analysis? hand, the module may expect the assumptions, but • How can formal theories aid the software devel- needs to realize the guarantees [6]. opment in checking whether an implementation 2.3 Implementation Perspectives satisfies its specification? On the programming and technical level, there are a Are the additional considerations describable in the variety of different perspectives on module interfaces different perspectives? and module interaction. Ranging from usage of pro- • How can security aspects be integrated into gramming language features and middleware to the (semi-)formal models of module interfaces and choice of transmission protocols, module communica- module interaction? tion needs to be considered in various development ac- tivities. • How can models and implementations of module interfaces and module interaction be linked? 3 Further Considerations on Interfaces • How can architectural knowledge be made avail- able through models and implementation? Apart from different perspectives on interfaces and module communication, additional considerations are References needed: [1] Luca de Alfaro, Thomas A. Henzinger. Interface Automata. ACM • Linkage between modules may be determined SIGSOFT Notes, vol. 26, no. 5, pp. 109–120, statically – favoring analysis – or dynamically – in- 2001. creasing flexibility. [2] Nicola Dragoni, Saverio Giallorenzo, Alberto Lluch Lafuente, • Provided interfaces and communication between Manuel Mazzara, Fabrizio Montesi, Ruslan Mustafin, Larisa Sa- fina. Microservices: Yesterday, Today, and Tomorrow. In: Manuel modules need to be considered from a security Mazzara, Bertrand Meyer (eds). Present and Ulterior Software perspective as they offer usual attack vectors. Engineering. Cham: Springer, 2017, pp. 195–216. • Design and implementation of interfaces and [3] Eric Evans. Domain-Driven Design: Tackling Complexity in the communication need to be traceable across devel- Heart of Software. Boston: Addison-Wesley, 2004. opment phases and artifacts. [4] Kim G. Larsen. Modal Specifications International Conference on Computer Aided Verification. Berlin, Heidelberg: Springer. 1989. • Interfaces need to be considered together with, [5] Bertrand Meyer. Object-oriented software construction. New but also separated from their implementations in York: Prentice Hall, 1988. order to allow future changes to the implementa- [6] Bertrand Meyer. Applying “Design by Contract”. Computer, vol. tion or the system. 25, no. 10, pp. 40–51, Oct. 1992. [7] David L. Parnas. On the Criteria To Be Used in Decomposing Sys- tems into Modules. Commun. ACM, vol. 15, no. 12, Dec. 1972, pp. 4 Research Questions 1053–1058. The intended research considers software construction [8] Mohammad H. Valipour, Bavar Amirzafari, Khashayar N. Maleki processes with a special highlight on interfaces. In this and Negin Daneshpour. A brief survey of concepts and service oriented architecture. 2009 2nd IEEE In- setting, the following research questions arise. To the ternational Conference on and Information best of the author’s knowledge, they have not been Technology, Beijing, pp. 34–38, 2009. sufficiently answered in this context, but the results that have already been achieved, for instance in , need to be taken into account.