---------------------------------------------------------------------- Domain-Specific Software Architecture Specification A Simple Manufacturing Applications Example ---------------------------------------------------------------------- Logic-based software requirements and architecture specification offers many advantages to the software developer. It not only simplifies requirements definition, but also provides an integrated framework for the software development and reuse process. Logical specification does not introduce artifacts in the specification, such as complex diagrams and symbols, unique node representations, specialized networks, complex database schema representations, etc. Instead, it deals directly with the goals, plans, capabilities, and constraints of the application domain. Logical specification does not require information modeling as the first step in developing the specifications. Thus, there is no need for object diagrams, DFDs (Data Flow Diagrams), E-Rs (Entity-Relationship Diagrams), STDs (State Transition Diagrams), etc. All of these representations are implicit in the declarative-style logical specification. To illustrate the use of logical specification, we will present a highly simplified, but still a realistic example. In this excample, we will consider typical business decisions, resource capabilities, and resource allocation to a task. _Application Domain._ Our example is set in a manufacturing domain. An abstract representation of this manufacturing environment is shown in Figure 1. ----------------------------------------------------------------------------- Orders->[TaskScheduler]<->[TaskDispatcher]<-->[ShopControl]<-->[WorkCenter] | | [Plans] {Operators,Material,Equipment} ----------------------------------------------------------------------------- FIGURE 1. Abstract Representation of the Operating Environment When manufacturing orders are received, they are passed through the scheduling-dispatching channel to the shop-control activity. One of the activities that shop control is responsible for is 'material move' operation. In our example we will assume that the manufacturing plant uses JIT (Just-In-Time) approach, where an immediate response to all of the incoming work orders is required. Thus, when a move order is received from the Shop Control specifying a certain material to be moved, the work center accepts the order if it has the necessary resources; else the Shop Control is notified that sufficient resources are not available and that the material move order cannot be accepted. In the latter case the Shop Control will try other alternatives. Our work center consists of small warehouse, transportation equipment, and transportation equipment operators. To keep our illustration simple, only some of the normally available resources will be considerd. _Domain Model._ A domain model specifies the behavior of the entities making up the domain. As such, the domain model is also the representation of the process, because it describes what is taking place in the domain. It considers functions, data, rules, and the various entities (objects) and their capabilities and constraints. The primary purpose of the domain model is to describe generic problems. Our 'material move' operation can be considered in this context, because it can represent a family of 'move' operations that have the same generic structure. A domain model is a logical model because it does not assign functions to specific components. It only specifies the applicable interface and the information that flows through this interface. Domain model can be specified informally (textual description), graphically (diagram description), or formally. We started with an informal description of our manufacturing domain. Next, we will examine a graphical representation, and then look at the formal (logical) representation. A simple block diagram (context diagram) of the operational environment and the initially available resources is presented in Figure 2. This diagram provides an overview of the domain and the starting point for a detailed specification. ---------------------------------------------------------------------------- [Shop Control] <---> To other Work Centers | ^ Move material order | | Reply (+ or -) V | [Dispatch Work Center] OPERATORS MATERIAL --------- -------- carl stand jill parts tom EQUIPMENT storage_tank --------- cart crane truck ---------------------------------------------------------------------------- FIGURE 2. Dispatch Work Center The next step is to represent the above model formally. The external interface of our work center is very simple. The domain model for the material move function (work order request) can be expressed as: move(Material) where 'Material' is a parameter that will be specified when the move order is requested. The 'move' function, of course, is only one of the many functions applicable to our work center. Others include restocking, acquisition of transportation equipment, etc. _Reference architecture._ Reference architecture specifies the allocation of tasks needed to meet the desired goal. It also supports the development of a family of related systems. Thus, it is important to keep it in a generic form, so that it can be extended, reconfigured, and reused. We can also look at the reference architecture as an extension of the domain model. Whereas the domain model specifies WHAT is needed, the reference architecture specifies HOW to accomplish it. The logical architecture model is layered, with each layer providing additional detail and less abstraction. Continuing with our example, the next step is to specify the reference architecture for our 'move' operation. Again, our objective in specifying the reference architecture will be to keep it general, generic, and parametrized. At the same time we also want to relate it directly to our domain model. We will define the reference architecture as a logical specification. Instead of developing a new Architecture Description Language (ADL), we will use a conventional logic programming language. Our choice is Prolog, but another logic programming language could be used as well. But before we proceed with the specification, a few comments about the Prolog notations and the unique conventions. Prolog is basically a first order logic (FOL) programming language with a number of non-logical extensions. A Prolog sentence has a head (left side) and a body (right side), separated by the symbol ':-' (meaning if). The Prolog declaration, 'p :- q,s.'. states that the assertion p is true if the assertions q and s are true. From a goal viewpoint we can interpret the above assertion as a goal and two subgoals. In an alternate interpretation, we could consider the goal as a responsibility and the individual plans as obligations associated with the specific responsibilities. Yet in another interpretation, the goal could be considered to be a strategy. The specific interpretation will normally be application and user environment dependent. In the conventional Prolog notation, names starting with a lower-case letter represent predicates and constants and those starting with an upper-case letter represent variables (these are initially unbound). Lists are enclosed in square brackets. Thus [a,b,c] is a list consisting of three elements a, b, and c. The individual elements may represent parts, equipment, etc. Lines beginning with a '%' are comments. Logical specification can support system decomposition at all levels of representation. Hierarchy levels are variable and different parts of the system may not be expanded to the same level. As we will note later, there will be both horizontal and vertical decomposition. The same decomposition approach also provides the capabilities for including a number of alternatives, such as alternate plans, backup tasks, or error recovery actions in the process plan. These alternatives are selected if a goal cannot be satisfied using the primary path (normal operating procedures). Since preconditions and postconditions are implicit in the declarations, special notation is not required. However, any applicable constraints must be declared explicitly. We can express the relationship between the domain model and the reference architecture as a logical predicate: move(+Material) :- % Response+ find_transport(+Material,-Transport), find_operator(+Transport,-Operator), make_assignment(+Operator,+Transport,+Material). The top level goal (or responsibility) is 'move(Material)'. The right hand side of the predicate states the specific tasks (or obligations) that need to be performed to determine if the move request can be accepted by the work center. The goal is satisfied if we can find the proper transport, locate an available qualified operator, and then make the move assignment (resulting in an affirmative Response+). Note, that these are also the preconditions for a successful material move operation. The plus and minus signs preceding the variables are used to indicate data flow in our model. They are not part of the standard Prolog notation. The above expression represents a horizontal composition, with the meaning of the individual terms to be defined at the next lower level in the definition hierarchy. For example, to determine if the proper transportation means are available, we have to find out first what kind of transport is needed to move the requested material and then we have to check if that particular transport is available. Similar considerations apply to the selection of an operator, where we first have to determine if an operator is available and then have to check if that particular operator has the needed operational skills. However, if one or more of these requirements are not met, then the work center will need to issue a negative response (Response-). In a full system implementation this message would go to Shop Control, where alternate means would have to be found to move the needed material to the shop floor. move(+Material) :- % Response- decline_request(+Material). In the logical specification resource allocation constraints are defined by the rules that will assign an operator and the appropriate transport equipment to the material move operation. This assignment will occur only if the resource availability constraints are met. The Dispatch Work Center specification, written in Prolog language, is presented in Figure 3. The write statements are not actually part of the specification, but are included for animation and testing purposes. % ---------------------- Logical Specification --------------------------- % Dispatch Work Station Logical Specification % move is the responsibility; find_transport, etc. -- are obligations move(Material) :- % Response+ find_transport(Material,Transport), find_operator(Transport,Operator), make_assignment(Operator,Transport,Material),!. move(Material) :- % Response- decline_request(Material). find_transport(Material,Transport) :- % Response+ move_by(Material,Transport), equipment(Transport,available). find_operator(Transport,Operator) :- % Response+ operator(Operator,available), operator_skills(Operator,Skills), have_skill(Transport,Skills). make_assignment(Operator,Transport,Material) :- % Response+ assign_operator(Operator), assign_transport(Transport), issue_work_order(Operator,Transport,Material). decline_request(Material) :- write('resources are not available to move '), write(Material),nl. assign_operator(Operator) :- retract(operator(Operator,available)), assert(operator(Operator,busy)). assign_transport(Transport) :- retract(equipment(Transport,available)), assert(equipment(Transport,busy)). issue_work_order(Operator,Transport,Material) :- assert(assignment(Operator,Transport,Material)), write(Operator), write(' has been assigned to move '), write(Material),nl. move_completed(Operator) :- assignment(Operator,Transport,_), release_transport(Transport), release_operator(Operator), assignment_completed(Operator),!. release_operator(Operator) :- retract(operator(Operator,busy)), assert(operator(Operator,available)). release_transport(Transport) :- retract(equipment(Transport,busy)), assert(equipment(Transport,available)). assignment_completed(Operator) :- retract(assignment(Operator,_,_)), write(Operator),write(' has completed move assignment'),nl. %auxiliary logic (used to find if an operator has the needed skill) have_skill(X, [X|_]). have_skill(X, [_|Y]) :- have_skill(X,Y). % -------------------- data base specification ------------------------- % Sample Dispatch Work Station knowledge base facts % transportation needs (capabilities) move_by(storage_tank,crane). move_by(stand,truck). move_by(parts,cart). % operator availability status operator(carl,available). operator(jill,available). operator(tom,available). % operator skills (capabilities) operator_skills(carl,[truck,cart]). operator_skills(jill,[crane,cart]). operator_skills(tom,[truck,cart]). %equipment availability status equipment(crane,available). equipment(truck,available). equipment(cart,available). % -------------------- test specification ------------------------------ % a simple behaviour test scenario test:- move(storage_tank), move(parts), move(stand), move_completed(jill), move(parts). % --------------------- End of Logical Specification ----------------------- FIGURE 3. Material Move Specification in Prolog We note that the top level specifies the "WHAT" type requirements (responsibilities and obligations). The "HOW" details are defined and elaborated at the lower levels in the specification. The "WHO" question will answered during the system implementation phase. It is important to note the "information hiding" aspects of the logical representation. In our example 'move(Material)', declared at the top level, is the only link to the external environment and hides the internal operations. It is also important to note that all the potential interconnections are part of the hierarchical representation. Thus, there is no need for a specialized Module Interconnect Language (MIL) and separate Data Flow Diagrams (DFD). Our problem representation, as shown in Figure 3, is an executable specification because it is an operational Prolog program. To test it (using the simple 'test' predicate which is defined at the end of the specification listing), we can load it and run it under a Prolog interpreter or compiler. For example, using the SWI Prolog compiler, we obtain the following results: -------------------------------------------------------------------------- Welcome to SWI-Prolog (Version 2.5.2) Copyright (c) 1993-1996 University of Amsterdam. All rights reserved. 1 ?- [msi7]. msi7 compiled, 0.17 sec, 5,624 bytes. Yes 2 ?- listing(test). test :- move(storage_tank), move(parts), move(stand), move_completed(jill), move(parts). Yes 3 ?- test. jill has been assigned to move storage_tank carl has been assigned to move parts tom has been assigned to move stand jill has completed move assignment resources are not available to move parts Yes --------------------------------------------------------------------------- FIGURE 4. Testing the Logical Specification Examining the results of this test (actually a trace), we note that the first three move requests are satisfied, but the fourth fails because all of the needed resources have already been allocated. Note that although Jill is available as an operator, the cart is still in use. Thus, the fourth request fails. A similar approach can be used to specify other manufacturing operations. For example, we could develop a specification for a make operation, 'make(Gizmo,Quantity)'. The higher level specification, for example, could include a number of make and move operations. Again, the individual tasks (goals) will be decomposed as needed. Our example illustrated a simple approach to handling constraints and capabilities. The constraints considered included the availability of suitable transportation equipment and a qualified operation. In a more complex situation, we will need to consider other types of resources that may be physical (consumable or permanent) or logical (such as support activities). Resources also may be shared by several tasks. In this case the resource model contains the specifications and the status of all resources -- material, equipment, and their current capabilities. In addition to resource and capability constraints, it will be necessary to specify time and priority constraints, such as response time to a task request or the task priority level. In some situations, response time will be expressed as a function of priority. When developing the specifications, we must remember that all of these constraints need to be expressed in logical form. The logical description of a manufacturing operations leads to requirements specification and architecture reusability. For example, we could modify our dispatch example for a different application, such as machine selection. In this situation, we would consider machine operators instead of equipment operators. A task in this case would denote an operation performed on a machine and the skill list could specify the capabilities associated with a specific machine or a machine operator. Logical specifications are easily extendable (composable). For example, in our illustrative example we did not consider material availability. However, this additional constraint can be included by modifying the top level specification as shown below (note the added line #2): ---------------------------------------------------------------------------- move(Material) :- % Response+ material_available(Material), find_transport(Material,Transport), find_operator(Transport,Operator), make_assignment(Operator,Transport,Material). ---------------------------------------------------------------------------- FIGURE 5. Adding Material Availability Constraint and then adding the appropriate expansion for 'material_available(Material)'. _Implementation Architecture._ The logical specification that was developed above is a generic one. However, it provides the foundation for developing specific applications. The applications-level software architecture definition provides a precise statement of the specific problem, It clearly defines components, their interconnections, specific application constraints, etc. Issues such as architectural styles, operating system selection, programming language, etc. are implementation decisions and as such they should not be appear in the reference architecture definition. This approach will permit the same abstract model to serve as a framework for implementation in different operating environments using different architectural styles. The development of the applications architecture is the last step in the stepwise refinement process that starts with the domain model (highly abstract) and ends with a definition (highly specific) that is suitable for implementation in software components. Conclusion The logical specification of a software system is easily understandable because user-friendly naming can be used and the specification is directly executable. It uses a single language for specifying requirements, defining architecture, behavior modeling, and simulation. It also meets the desire for simplicity, unambiguity, and completeness in a single (integrated) requirements specification and provides an economical alternative for software requirements and architecture specification. There are no differences between the domain, requirements and architecture specification languages, and tools. Thus, the logic programming environment provides the needed support capabilities, without the need to develop or to purchase complex and very expensive CASE tools. In "Mathematical Models for Computing Science," C.A.R. Hoare states (August 1994): -- Propositional and predicate logic provide all the basic concepts needed for a systematic engineering design methodology. -- The operation of each component can be described scientifically by a separate predicate. -- A non-deterministic product is described by the disjunction of predicates describing its alternative modes of behaviour. It is the use of the logical constructs instead of the algebraic ones that greatly simplify the software architecture specification and model development. Our example illustrates one practical application of these logical constructs. Jan Pukite pukite@daina.com