The Rosetta Meta-Model Framework
Cindy Kong and Perry Alexander The University of Kansas Dept of Electrical Engineering and Computer Science Information and Telecommunication Technology Center 2335 Irving Hill Road Lawrence, Kansas 66045 {ckong, alex}@ittc.ku.edu
Abstract developed with such a goal in mind. It is geared to- wards system level design and provides a framework Heterogeneous systems are naturally complex and where ontologies of computational models can be de- their design is a tedious process. The modeling of com- fined. It also provides an interaction mechanism that ponents that constitute such a system mandates the use defines inter-domain impact. of different techniques. This gives rise to the problem of In this paper, we describe the Rosetta domain methodology integration that is needed to provide a con- framework and use it to define models of computation. sistent design. In this paper, we propose a meta-model We use the notion of a unifying semantic domain [8] framework that provides such an integration. The se- to provide a domain of discourse for models. A se- mantics of different computational models can be ex- mantic domain is called unifying when it is used to pressed and used together in the Rosetta framework. represent various design paradigms. We exploit rela- We use denotational semantics to define unifying se- tions between unifying semantic domains and models mantic domains, which are themselves extended to pro- to derive interaction models. As inter-domain interac- vide ontologies for models of computation. Interaction tions depend on the nature of models involved, their relations defined between models are then used to ex- derivation and definitions cannot be automated. It is ploit and analyze model integration. We demonstrate the domain designers’ responsibility to define such in- our approach by providing applications where different teraction models. However, an interaction model need computational models are used together. be defined only once. We present two unifying seman- tic domains, define a lattice of models of computation based on them, and express interactions between some 1. Introduction of these models. We demonstrate modeling capabili- ties in the design of a vending machine in CSP [16]. We also show composition and interaction in modeling The design of computer systems increasingly in- power consumed in a state-based timer model. volves integrating models with heterogeneous seman- tics. Today’s systems involve components implemented using technologies such as software, digital hardware, 2. The Rosetta Specification Language analog hardware, optics, and MEMS (Micro Electro Mechanical Systems), each with their own domain spe- System level modeling involves integrating domain- cific semantics. When integrating such components specific models into a consistent system model. This in analysis and synthesis activities, it is necessary to integration is not easy due to the possibility of bring together such disparate models to effectively pre- inter-domain interactions, where information from one dict performance properties. Thus, ontologies sup- domain-specific model impacts models from other do- porting the specification and integration of computa- mains. Rosetta attempts to address this problem di- tion models must be developed and supported in next- rectly in its domain representation semantics. Domains generation systems level design languages. define ontologies of computational models and design The Rosetta specification language [1, 2] is being paradigms. Systems are modeled by aspects, each as- pect representing a domain specific viewpoint. A sys- syntactic platform. Semantics used in facet specifica- tem model is then obtained by assembling these as- tions is provided in domains. Therefore, specifications pects with the use of interaction models. An interac- have different meanings depending on their domains. tion model specifies what information exchange occurs We use a denotational approach [3, 24] to describe between two domains. these domain semantics. The denotational approach In Rosetta, an aspect is called a facet. It represents provides semantic valuation functions to map syntac- the basic unit of modeling. Its specification consists of tic constructs to abstract values. Using different val- a signature, a domain, and terms. The signature con- uation functions thus gives different meanings to the sists of the name of the facet and a list of parameters. same construct. The domain that the facet extends provides a domain There are several ways for defining denotational of discourse for the facet. In other words, the facet uses semantics of a program. A common approach is items defined in the domain and adds additional prop- to provide partial functions or relations on program erties to them. Terms are used to express such prop- states [3, 24]. Each state defines values for the vari- erties. A facet can also create new items and again, ables in the program. A command in the program terms can be used to define their properties. Semantic then denotes a change in state. Lee and Sangiovanni- correctness is then defined as consistency of terms with Vincentelli [20] propose another approach to denota- respect to the specified domain. If no inconsistency is tional semantics based on signals. A program, or introduced by terms and declarations within the facet, rather, a process is represented by a partial function or then the facet definition is consistent. relation over signals. This approach to denotational se- Syntactically, as shown below, a facet has a label, mantics is specifically suited to modeling concurrency. a list of parameters, a list of declarations and a list of Program denotations into different representations terms. Declarations create constants, variables, func- give rise to the idea of making these representations tions, types and even other facets. Terms are boolean available at a higher level of abstraction. By mak- expressions that describe constraints on declared items, ing these representations available, we allow design- or define and include other facets to support structural ers to decide earlier on the best representations for definition. The :: operator indicates membership and their system specifications. We consider state based is used in declarations to provide type information. In and signal based semantics to represent unifying se- the case of a facet declaration, the domain the facet mantic domains [8] that we call units of semantics. extends provides the type information of the facet. A unifying semantic domain represents a set of seman- facet
2 state-based-semantics). Since each state is discrete, there exists an injective relation (or one-to-one rela- Extensions Homomorphisms tion) between the set of states and the set of natural Partial Morphisms logic numbers. A one-to-one relation involves a function fnc Unit of that maps a state to a natural number such that if Semantics two states are different, then they map to two different
state−based−semantics signal−based−semantics numbers. Term d1 expresses this relation. There exists a function fnc, such that for any two states s1 and s2, Model of CSP if s1 and s2 are different, then their mappings under continuous discrete trace−based fnc are different. An example of a domain that extends the continuous−time Computation discrete−time signal-based unit of semantics is the csp domain. It uses items introduced in that parent domain such as: Engineering frequency finite−state Values type representing set of values associated with Modeling tags. RF digital sequential−machinesynchronous Tags type representing the set of tags. Event constructed type that consists of a value and Figure 1. Lattice of Domains a tag. A specific instance of the type is given as event(t1, e1). Accessor functions are automat- ically generated to access each field of the con- properties added concern new syntactic constructs and structed type. Therefore, tag(event(t1,v1)) re- are consistent in themselves. turns t1 and value(event(t1,v1)) returns v1. Figure 1 shows the lattice of domains that is Signals type representing the set of signals. Each sig- obtained through extension. The root of the lat- nal is a set of events. tice is the domain logic that acts as prelude to the Rosetta language. It contains definitions for @ dereferencing operator of a label with respect to a all basic types and constructs of Rosetta. The tag. This operator appears in all domains, but its rest of the domains are divided into three groups: semantics differs. unit of semantics, model of computation and en- In the csp domain, we add constraints over these items gineering modeling. State-based-semantics and to express the properties that are necessary to define signal-based-semantics represent units of semantics processes. Specification 2 provides part of the Rosetta that define state-oriented and signal-oriented unifying csp domain. Term c1 states that there is a total order- semantic domains respectively. The , discrete ing of all tags in csp (the partial ordering axioms are finite-state, discrete-time, continuous, also defined but not shown here). Therefore, although and computational continuous-time frequency Signals are sets, due to the ordering of all tags, and models extend state-based-semantics. [16] and CSP therefore of all events, Signals can be considered as are two models of computation based on trace-based ordered sets. The function put adds an event to a sig- signal-based-semantics. Some examples of engineering nal. Get is its counterpart as it takes an event from modeling domains are , , RF digital sequential the signal (we intend get to return the event in the and . machines synchronous signal with the lowest tag as shown in term c2. If evt is the event returned by get, then its tag is less than Discrete domain 1 or equal to the tags of all other events in the same domain discrete(f::facet) :: state_based_semantics is signal.) Function getSignal returns the signal with- begin d1: exists (fnc::<*(st::States)::natural*> | out the event returned by get. Term c3 states that forall(s1,s2::States| two different events within the same signal cannot have (s1 /= s2) implies (fnc(s1) /= fnc(s2)))) the same tag value. This prevents nondeterminism as end domain discrete; events are processed according to the lower tag value. We need not say that nondeterminism can be useful The discrete domain (Specification 1) repre- in modeling and therefore we may want to allow it in sents models where each state is discrete. It ex- Rosetta specifications. However, for the purpose of this tends state-based-semantics and adds an addi- paper, we do not need this additional complication. Al- tional constraint on the States set (declared in though not shown here, we also have definitions of the
3 different protocols for communication over signals, e.g. process, and ctrlSig for control events. The control rendez-vous, letterbox and so on. signal ctrlSig contains only one event at any time. The tag of the event tells the process the state in which CSP domain 2 it is and the value of the event keeps track of the last domain csp(f::facet) :: signal_based_semantics is event processed. As the control signal is not accessi- put(sig::Signals;evt::Event)::Signals; ble from outside the process, we know for sure that get(sig::Signals)::Event; the current tag can take only two values, namely 1 getSignal(sig::Signals)::Signals; tg::Tags; // current tag and 2. Therefore, we can do dereferencing as follows nextTg::Tags; // next tag ctrlSig@nextTg where nextTg is the next tag. The ... machine works as follows. Terms c1 and c2 define the begin c1: forall(t1,t2::Tags | t1 <= t2 or t2 <= t1); values of tg and nextTg. Term c3 defines the machine’s c2: forall(sig::Signals;evt::Event | behavior. If event in ctrlSig is init and if event in (get(sig) = evt) implies input is dollar, then ctrlSig@nextTg becomes a copy forall(otherEvt::Event | of the current ctrlSig from which event init was re- (otherEvt in sig) implies (tag(evt) <= tag(otherEvt)))); moved and event dollarCoin added (input becomes c3: forall(sig::Signals;evt1,evt2::Event | a new signal without the coin event). If instead, con- (evt1 in sig) and (evt2 in sig) trol event is dollarCoin, then depending on the event and (evt1 /= evt2) implies in input, either a coffee or a chocolate event is put in (tag(evt1) /= tag(evt2))) ... output. Note that ctrlSig and input are modified end domain csp; such that the machine goes back to the initial waiting state at the next tag.
4. Examples 4.2 Example of an Interaction
4.1 Example of A Coffee/Tea Vending Machine An interaction represents a relation that defines when and where information from one domain impacts We choose a vending machine as a modeling exam- another. Whenever facets using domains that interact ple, following the tradition started by Hoare [16] and are composed, the interaction specification is automat- continued in several work [18, 28]. We model a vending ically included. We demonstrate the methodology be- machine that provides the choice of a cup of coffee or a hind interaction models with an example of high level chocolate when a dollar is paid and the choice of a cup power analysis. of tea or a cookie when 75c is paid. The dollar and 75c Power is the leading constraint in embedded system events are the guards between two alternatives. Once modeling. However, as power is implementation depen- one of these events occur, an external choice (the user) dent, power analysis has been mostly done at low lev- selects the next event. The CSP model is given as: els of abstraction. We use Rosetta and its interaction VM = (dollar → (coffee [] chocolate) → VM) k (75c → mechanism to propose a new methodology for estimat- (tea [] cookie) → VM) ing power dissipation at high-level. The methodology In Specification 3, csp vending is the Rosetta CSP consists of first modeling the behaviors of a system. specification representing the above vending machine Then, the interaction between the system models and process. VendTags represents the set of tags in our technology specific power models is analyzed to derive system. There are two possible states to the vend- power consumed if the system is implemented in that ing machine: (1) the machine is expecting money, and technology. In another paper, we provide examples of (2) coin event has already happened, the machine is power analysis for implementation in the CMOS tech- expecting a choice. Therefore, VendTags consists of nology. In this paper, we are interested in analyzing two elements. Since it is totally ordered, we choose power dissipated in a software implementation. Tiwari integral values 1 and 2 that are intrinsically ordered. et al. [27] propose a method for estimating power con- The values associated with events are dollar, coffee, sumed by processors while executing some instructions. chocolate, 75c, tea and cookie, each representing an We use their results to provide estimation models for event from the CSP model (VendValues). VendEvent power consumed in a Rosetta design. We analyze the and VendSignals respectively define the event type operations that occur in a model. The instructions and signal type used in our specification. The vending that are needed for a specific operation can usually machine process uses three signals: input for events be estimated by engineers. Using empirical models de- produced elsewhere, output for events produced by the rived from Tiwari’s work, we can therefore calculate the
4 Timer model 5 Models for a coffee/tea vending machine 3 facet timer(set::in boolean;startTime::in natural; VendTags::subtype(Tags) is {1,2}; alarm::out boolean) :: discrete is VendValues::subtype(Values) is currentTime::real; enumeration[dollar, coffee, chocolate, decrement(time::natural) :: natural is time - 1; 75c, tea, cookie]; begin VendEvent::subtype(Event(VendTags,VendEvent)); init:set => currentTime’ = startTime; VendSignals::subtype(Signals) is set(VendEvent); t1: (not set) => currentTime’ = decrement(time); CtrlValues::subtype(Values) is t2: alarm = if (currentTime’=0) enumeration[init,dollarCoin,75cCoin]; then true else false end if; CtrlEvent::subtype(Event(VendTags,CtrlValues)); CtrlSignals::subtype(Signals) is set(CtrlEvent); power consumed by a model. The result is not very ac- facet csp_vending() :: csp is input,output,ctrlSig::VendSignals; curate and will also probably be underestimated. How- export input,output; ever, it should be sufficient for comparison purposes begin between implementation technology and between pos- c1: tg = tag(get(ctrlSig)); sible designs. c2: nextTg = if (tg = 1) then 2 else 1 end if; c3: case value(get(ctrlSig)) is The power domain defined in Rosetta specifies init -> how power consumption is to be calculated across case get(input) is a state change (p1: power’ = activity * nominal event(1,dollar) -> + leakage;). Depending on the implementation tech- (ctrlSig@nextTg = nology, activity either represents switching activity put(getSignal(ctrlSig), at the gate level or current drawn by instructions. event(nextTg,dollarCoin))) | ... // case 75c event similar to dollar event Leakage is a parameter provided by engineers to rep- end case | resent the static power dissipated through leakage cur- dollarCoin -> rent. Nominal is the nominal voltage. The power0 is case get(input) is a shortcut notation expressing power@next(state), i.e. event(2,chocolate) -> the value of power across a state transformation. The (output@nextTg = put(output,event(2,chocolate))) following functions and variables are also declared in and (ctrlSig@nextTg = put(getSig(ctrlSig),event(nextTg,init))) the power domain: and (input@nextTg = {}) | event(2,coffee) -> calculateOpActivity(opSet::sequence(labels)) (output@nextTg = put(output,event(2,coffee))) ::real; and (ctrlSig@nextTg = calculateStructActivity(facetSet::set(facets)) put(getSig(ctrlSig),event(nextTg,init))) ::real; and (input@nextTg = {}) outputActCoeff::real; end case | ... // case 75cCoin - similar to dollarCoin case Specification 4 provides an interaction model of end case; end facet csp_vending; what occurs between the power and discrete domains. A software power facet (swp), extending the power domain, is written. It provides terms that de- fine the functions and variables mentioned above. Interactions 4 It is important to note that declaration is differ- interaction DandP(f::discrete, g::power) ent from definition. A declaration gives the sig- :: logic is begin nature of an item, while definition provides the power_to_discrete: {}; value of a just declared or already declared item. discrete_to_power: CalculateOpActivity calculates the total average reflect.meta_if current (in mA) drawn by all the operations involved (orModified(sel(v::meta.params(g) | output(v))), outputActivity=0, outputActivity=1) in a design. CalculateStructActivity calculates the and reflect.meta_equal(operatorActivity, average current drawn by instantiated facets. Facet g.calculateOpActivity(meta.getOperators(g))) instantiation is used in structural composition. and reflect.meta_equal(structureActivity, reflect.meta_sum(g.calculateStructActivity facet new_swp(Vcc,leakage::design posreal) (meta.getInstantiatedFacets(f)))) :: power is and reflect.meta_equal(activity, calOpActivity(opSet::sequence(labels)):: posReal is outputActivity*g.outputActCoeff + if (opSet == nil) operatorActivity + structureActivity); then 0 end interaction DandP; else let (operator::label be opSet(0)) in case operator is
5 +’ -> 400 the 486DX2 is 5V. We assume a power leakage of ’-’ -> 300 0.25 W. Since outputActCoef is 0, we do not care ’not’ -> 276 about the outputActivity. As no facet is instanti- ’=’ -> 500 ’=>’ -> 700 ated in the timer example, structureActivity is also end case 0. OperatorActivity is equal to 3700 mA (one ’-’, end let two ’⇒’ and four ’=’). Therefore, total power is given + calOpActivity(tl(opSet)) endif; by 18.75 Watt (3700 * 5 + 0.25). This is only an av- calStActivity...; erage estimate and the energy consumed can then be begin calculated according to the speed of the CPU. It can t1: calculateOpActivity = calOpActivity; be made more accurate by other measurement of cur- t2: calculateStructActivity = calStActivity; t3: outputActCoef = 0; rent drawn per instruction, and by involving only the t4: nominal = Vcc; operators that are used per state, instead of simply discrete_to_power: calculating the current drawn by all operations in the if modified(alarm) facet. then outputActivity = 0 else outputActivity = 1 end if 5. Related Work and operatorActivity = calculateOpActivity(...) and structureActivity=calculateStructActivity(...) and activity = outputActivity*outputActCoef + Several efforts have been directed toward combin- operatorActivity + structureActivity; ing different methodologies and tools together. We end facet new_swp; group the related work into five categories: (1) com- Specification 5 shows a simple example of a timer putational model use and composition in one frame- that goes off whenever it decreases to zero. Such a work; (2) discrete and continuous domain modeling; timer is used in operating systems for threads that are (3) meta-modeling; (4) requirements engineering; and, given a certain CPU time budget, but do not allow (5) multiple logic. preemption. We compose this model with the software power model to analyze the power consumed by the Computational model composition is an important timer as follows: problem. Ptolemy II [7], SAL [6], and Metropolis [8] provide different approaches to this problem. Ptolemy timer(setVal,start,alarm) DandP swp(Vcc,leakage) II type system [21] is augmented by interaction types The resulting facet is one where both models co- derived from analysis of automata representing concur- exist. We obtain a software power augmented model rent computational models. Models are composed by (new-swp as shown above) by projecting this com- using specific connecting entities of these types. The posed facet into the power domain. This results SAL, Symbolic Analysis Laboratory, framework allows in adding terms (discrete-to-power) derived from the use of many tools and models by using an inter- interaction DandP into the new facet. This new mediate language. This language can be translated facet also contains terms (t1, t2, t3 and t4) and to and from the languages of different analysis tools, declarations (calOpActivity and calStActivity) and can also be used to represent different concurrent from the original software power facet. Function computational models. The Metropolis project pro- calOpActivity denotes what calculateOpActivity poses a framework where formal models can be defined does. If-then-else, let and case are functions in and compared. It uses trace algebra to compose mod- Rosetta. They return the value of the expression they els through connecting channels. Rosetta differs from evaluate to. For example, if the sequence opSet is these approaches in that it allows vertical integration empty (nil), the whole if expression evaluates to 0. of models. Vertical integration does not need commu- CalOpActivity is a recursive function. It returns 0 nicating channels between models. if the sequence is empty, else it evaluates the current There are several approaches focused on combin- drawn by the first operator in the sequence, and adds ing discrete and continuous modeling. A hybrid au- this value to a recursive call on the rest (tl(opSet)) of tomaton [15] is a generalization of timed automa- the operators in the sequence. The values in the case ton [4]. Continuous behavior is modeled according expression are derived from Tiwari’s [27] estimation of to differential equations within a state, while discrete current drawn in a 486DX2 processor. For more de- behavior is modeled as jumps across states. Model- tails on the Rosetta syntax, please refer to the Usage checking techniques can be applied to hybrid automata. Guide [1]. HYTECH [26] provides a model checker for hybrid au- We simulate this augmented power model to es- tomata, while UPPAAL [5] provides a model checker timate power consumption for the timer. Vcc for for networks of timed automata. VHDL 1076.1 [9], also
6 known as VHDL-AMS, is a language for mixed-signal the relation between logical systems. Some sentences design. It is a hardware description language that sup- can be consistently translated from one logical system ports the description and simulation of digital, analog to another. Isabelle is a generic theorem prover [23]. and mixed analog/digital systems within one environ- It provides a logical framework, i.e. a meta-logic, that ment. It defines a concept of quantity, to represent can be used to formalize several objects-logic. Rosetta continuous variation. Rosetta also provides a frame- focuses on combining computational models instead of work for hybrid or mixed system modeling. However, logics. Rosetta’s framework is open and allows definition and use of other computational models. 6. Conclusion The notion of meta-modeling is an object-oriented paradigm and UML [13] is often used for its imple- We introduce the Rosetta meta-model framework mentation. A meta-model defines objects that can as a framework where different computation models be instantiated to obtain objects of models. The can be used and composed. We provide definitions MultiGraph Architecture [22] is a toolkit for creat- for some computational models and demonstrate their ing model integrated program synthesis (MIPS) that use in designing a simple vending machine. We also allows experts to integrate models that represent define an interaction relation between power and dis- domain-specific systems through a methodology called crete domain to demonstrate a new methodology for model-integrated computing (MIC). The Generic Mod- estimating power dissipated by software. We observe eling Environment (GME) [19] provides a tool that im- that an interaction needs to be written only once. The plements the MultiGraph Architecture. Terrasse et al. discrete-power interaction is reused whether we are in- propose another UML metamodeling architecture to vestigating power in a CMOS implementation or soft- define abstract bases of agreement for interoperabil- ware implementation. ity of information systems [25]. Rosetta’s framework Numerous Rosetta analysis tools are under develop- can also be considered as a meta-modeling architec- ment. A Java simulator and a verifier will soon be avail- ture. It provides semantic meta-models for computa- able to provide formal verification support to Rosetta. tional models. Commercial test vector and test case generation tools In requirements engineering, we relate Rosetta to are available for generating VHDL test vectors and will viewpoints, feature engineering and aspect-oriented soon be available for C++. Prototype IP reuse and programming. The Viewpoints [10] framework allows matching tools have been developed to aid designers different perspectives of a system to be expressed with in automatically determining if a component meets a different representation. Consistency check instruc- collection of problem requirements. In support of these tions provide conditions that need to hold for composi- activities, Rosetta is currently undergoing standardiza- tion of the viewpoints into a complete system. Feature tion by the Accellera EDA standards organization. engineering consists of describing a system (mainly in telephony) by features, with a feature being a unit of References functionality [29]. The idea is to specify features as if they were independent and then use composition op- [1] P. Alexander, D. Barton, and C. Kong. Rosetta erators to combine them together. In Aspect-Oriented Usage Guide. The University of Kansas / ITTC, 2335 Component Requirements Engineering (AOCRE) [14], Irving Hill Rd, Lawrence, KS, 2000. components are categorized according to the “aspects” [2] Perry Alexander and Cindy Kong. Rosetta: Semantic that they either provide or need. Engineers use these support for model-centered systems-level design. aspects to reason about inter-component relationships. IEEE Computer, 34(11):64–70, November 2001. In aspect-oriented programming, the same notion of [3] L. Allison. A practical introduction to denotational an aspect is applied on methods [17] instead of com- semantics. Number 23 in Cambridge Computer ponents. Rosetta differs from Viewpoints and feature Science Texts. Cambridge University Press, 1986. engineering as it provides consistency checks automati- [4] R. Alur and D. Dill. A theory of timed automata. cally in its type checking. Rosetta does aspect-oriented Theoretical Computer Science, 126:184–235, 1994. modeling at a higher level of abstraction (specification [5] Johan Bengtsson, Kim Larsen, Fredrik Larsson, Paul instead of programming). Pettersson, and Wang Yi. UPPAAL - a tool suite for Institution theory and Isabelle provide approaches automatic verification of real-time systems, December to combining multiple logics. The concept of an institu- 1996. http://www.brics.dk/RS/96/58/. tion [11] is introduced to formalize the notion of a “log- [6] Saddek Bensalem, Vijay Ganesh, Yassine Lakhnech, ical system” and provides a foundation for exploiting Cesar Munoz, Sam Owre, Harald Rueb, John
7 Rushby, Vlad Rusu, Hassen Saidi, N. Shankar, Eli pages 527–530. Elsevier Science Publishers B.V., Singerman, and Ashish Tiwari. An overview of SAL. 1991. In C. Michael Holloway, editor, Fifth NASA Langley [19] A. Ledeczi, M. Maroti, A. Bakay, G. Karsai, Formal Methods Workshop, Williamsburg, VA, June J. Garrett, C. Thomason, G. Nordstrom, J. Sprinkle, 2000. and P. Volgyesi. The generic modeling environment. http://shemesh.larc.nasa.gov/fm/Lfm2000/Proc/. In In Proceedings of WISP 2001, Budapest, Hungary, [7] J. T. Buck, S. Ha, E. A. Lee, and D. G. May 2001. Messerschmitt. Ptolemy: A framework for simulating [20] Edward A. Lee and Alberto Sangiovanni-Vincentelli. and prototyping heterogeneous systems. Int. Journal A framework for comparing models of computation. of Computer Simulation, 4:155–182, April 1994. IEEE Transactions on Computer-Aided Design of [8] J. R. Burch, R. Passerone, and A. L. Integrated Circuits and Systems, 17(12):1217–1229, Sangiovanni-Vincentelli. Overcoming heterophobia: December 1998. Modeling concurrency in heterogeneous systems. In [21] Edward A. Lee and Yuhong Xiong. System-level Proceedings of the second International Conference on types for component-based design. Technical report, Application of Concurrency to System Design, June University of California at Berkeley, February 2000. 2001. [22] Greg Nordstrom, Janos Sztipanovits, Gabor Karsai, [9] Ernst Christen. The VHDL 1076.1 language for and Akos Ledeczi. Metamodeling - rapid design and mixed-signal design. EE Times, June 1997. Analogy, evolution of domain-specific modeling environments. Inc. In Proceedings of the IEEE Conference and Workshop [10] A. Finkelstein, J. Kramer, B. Nuseibeh, on Engineering of Computer-Based Systems, L. Finkelstein, and M. Goedicke. Viewpoints: A Nashville, Tennessee, March 1998. framework for integrating multiple perspectives in [23] Lawrence C. Paulson. The foundation of a generic system development. International Journal of theorem prover. Journal of Automated Reasoning, Software Engineering and Knowledge Engineering, 5(3):363–397, 1989. 2(1):31–58, March 1992. World Scientific Publishing Co. [24] Joseph E. Stoy. Denotational Semantics: The Scott-Strachey Approach to Programming Language [11] J. A. Goguen and R. M. Burstall. Introducing Theory. The MIT Press, 1977. institutions. Lecture Notes in Computer Science, 164:221–255, 1984. [25] Marie-Noelle Terrasse, Marinette Savonnet, and George Becker. An uml-metamodeling architecture [12] James Gosling and Henry McGilton. The Java for interoperability of information systems. In 4th Language Environment: A White Paper. Sun International Conference on Information Systems Microsystems, Mountain View, CA, May 1996. Modelling, Hradec nad Moravici, Czech Republic, http://java.sun.com/docs/white/langenv/. May 2001. [13] The UML Group. UML Metamodel. Rational [26] Pei-Hsin Ho Thomas A. Henzinger and Howard Software Corporation, Santa Clara, CA, 1.1 edition, Wong-Toi. Hytech: A model checker for hybrid September 1997. http://www.rational.com. systems. Software Tools for Technology Transfer, [14] John Grundy. Aspect-oriented requirements 1:110–122, 1997. engineering for component-based software systems. In [27] Vivek Tiwari, Sharad Malik, Andrew Wolfe, and Proceedings of RE’99, Limerick, Ireland, June 1999. Mike Tien-Chen Lee. Instruction level power analysis IEEE. and optimization of software. Journal of VLSI Signal [15] Thomas A. Henzinger. The theory of hybrid Processing, pages 1–18, 1996. Kluwer Academic automata. In Proceedings of the 11th Annual IEEE Publishers, Boston. Symposium on Logic in Computer Science, pages [28] Mark Utting. An Object-Oriented Refinement 278–292, 1996. Calculus with Modular Reasoning. PhD thesis, [16] C. A. R. Hoare. Communicating Sequential Processes. University of New South Wales, Kensington, Prentice-Hall, Englewood Cliffs, 1985. Australia, October 1992. [17] Gregor Kiczales, John Lamping, Anurag Mendhekar, [29] Pamela Zave. Feature-oriented description, formal Chris Maeda, Cristina Lopes, Jean-Marc Loingtier, methods, and dfc. In Stephen Gilmore and Mark and John Irwin. Aspect-oriented programming. Ryan, editors, Language Constructs for Describing Technical report, Xerox Palo Alto Research Center, Features, pages 11–26. Springer-Verlag London Ltd, 1997. 2000/2001. Feature Integration in Requirements [18] C. Kirkwood and K. Norris. Formal Description Engineering. Techniques, volume III, chapter Some Experiments using Term Rewriting Techniques for Concurrency,
8