Static semantics. Once we had developed useful syntactical constructs for specifying interface com- munication, defining the specification language’s syntax was straightforward: ba- sically, we just extended the statement definition of Japl by the new specification statements. In order to meet the language requirements from the beginning of this chapter, however, we have to further confine the valid specifications by means of the type system. Recall, in particular, that executability requires a specified test to be imple- mentable in terms of a Japl program and, respectively, satisfiability demands the existence of a Japl component which passes the test. With these requirements in mind consider the following specification snippet consisting of two nested outgoing method call statements: o1!m1(v1) { o2!m2(v1) { ... }
Static semantics. We want to allow “cross-importing”, i.e., components should be able to mutually import their classes. To this end, we have to reformulate the typing judgment on the program/component level such that it does not just state the program’s well-typedness but it also explicitly mentions the program’s classes committed to its environment in terms of a type mapping Θ. Moreover, we require that the assumed type context ∆ of a program’s type check already includes the types of the imported (assumed ) classes. In other words, a program is now type-checked in an assumption-commitment context as it can be seen in typing rule T-Prog’ in Table 2.9. This is closely related to the required and provided interfaces in UML compoment diagrams[65]. Finally, we have to add a new rule for the import construct. However, since the import construct only mentions the name of the class but no further typing information, we only have to check whether the imported class name is in the domain of ∆. All other rules of Table 2.2 and Table 2.3 remain the same. As open programs are now typed in an assumption-commitment context, we have to reformulate the well-typedness definition for program.
