A Metamodel for Aspect-Oriented Modeling

合集下载

characterize a model

characterize a modelCharacterizing a ModelIntroductionModels play a crucial role in various fields, including science, engineering, and social sciences. They are used to represent and understand real-world phenomena, making it easier to analyze and predict outcomes. Characterizing a model involves identifying its key features, limitations, and applications. In this article, we will explore the concept of characterizing a model and its significance. Defining a ModelA model can be defined as a simplified representation of a complex system or process. It captures the essential elements and relationships of the system, allowing researchers to study and analyze it in a controlled manner. Models can be mathematical, physical, or conceptual, depending on the nature of the system being studied.Key Features of a Model1. Assumptions: Models are built based on a set of assumptions that simplify the system under investigation. These assumptions help in reducing complexity and makingthe model more manageable.2. Variables: Models consist of variables that represent different aspects of the system. These variables can be quantitative or qualitative, and they interact with each other according to specified relationships.3. Parameters: Models often include parameters that define the characteristics of the system. These parameters can be constant or variable and are essential for calibrating the model to match real-world observations.4. Equations: Mathematical models are characterized by a set of equations that describe the relationships between variables and parameters. These equations can be simple or complex, depending on the complexity of the system being modeled.5. Validation: Models need to be validated by comparing their outputs with real-world data. This process ensures that the model accurately represents the system and can be used to make reliable predictions.6. Sensitivity Analysis: Characterizing a model involves conducting sensitivity analysis to understand how changes in input parameters affect the model's outputs. This analysis helps in identifying the most influentialparameters and understanding the model's behavior under different conditions.Limitations of a Model1. Simplifications: Models often make simplifying assumptions to reduce complexity. While these simplifications make the model more manageable, they may lead to inaccuracies or omissions.2. Uncertainty: Models are subject to uncertainty due to the inherent variability in real-world systems. Uncertainty arises from measurement errors, incomplete data, and the limitations of the model itself.3. Scope: Models have a specific scope and may not capture all aspects of the system being studied. It is essential to understand the limitations of the model and its applicability to different scenarios.4. Interpretation: Interpreting the outputs of a model requires careful consideration. The model's predictions are based on the assumptions and equations used, and they may not always align with real-world observations.Applications of a Model1. Prediction: Models are used to predict future outcomesbased on current conditions. For example, climate models are used to predict long-term weather patterns, helping in planning and decision-making.2. Optimization: Models can be used to optimize processes and systems by identifying the best possible solutions. For instance, operational research models are used to optimize production schedules and resource allocation.3. Policy Analysis: Models play a crucial role in policy analysis by simulating the impact of different policies on the system under consideration. This helps policymakers make informed decisions and assess the potential outcomes of their actions.4. Understanding Complex Systems: Models are used to understand and study complex systems that are difficult to observe directly. For example, economic models help economists analyze the behavior of markets and predict economic trends.ConclusionCharacterizing a model involves understanding its key features, limitations, and applications. Models are valuable tools for studying and analyzing complex systems, enabling us to make predictions, optimize processes, andgain insights into various phenomena. By understanding the characteristics of a model, researchers can use them effectively and interpret their outputs accurately. While models are not perfect representations of the real world, they provide valuable insights and help in advancing knowledge in various fields.。

A new model for predicting the depth of cut in abrasive

R
proﬁle curvature radius (mm)
Sd
standoff distance (mm)
u
nozzle traverse speed (mm/s)
v
particle velocity (m/s)
vj
waterjet velocity (m/s)
Vs
volume of material removal by a particle (m3)
© 2008 Elsevier B.V. All rights reserved.
1. Introduction
Machining performance, including depth of cut (or depth of jet penetration) and cut quality, is a major technological challenge to the abrasive waterjet (AWJ) machining technology. This challenge becomes more intensiﬁed as the technology is more widely used in industry. A continual research and development effort has been made to explore its underlying science with an aim to increase its machining performance and application domain, as documented by Kovacevic et al. (1997), Momber and Kovacevic (1998) and Wang (2003a). Liu et al. (2004) carried out a computational ﬂuid dynamics (CFD) study to understand the jet and particle dynamic characteristics so as to optimize the jetting and process parameters for enhancing the cutting performance. Wang and Liu (2008) later developed a jet characteristic model that enabled to evaluate the particle velocity distribution along and across an

A Framework for Schema Evolution by Meta Object Manipulation

ystems, after the design of the database schema is committed, no more changes to the structure are allowed. More advanced systems support schema update facilities. There is no longer a clear cut between the design and application phases. Nevertheless, schema evolution possibilities are very limited and are normally restricted to simple changes, realized by a given set of special purpose schema update operators. Furthermore, changing the schema information is often only allowed, if the database is empty. If they allow to modify populated databases, they either include a data migration utility to adapt existing data objects to the changed schema, or some other mechanism has to ensure consistency between data and structure. An early investigation of changing types in populated database exists for the ENCORE database management system SZ86, SZ87]. This work addresses the e ects of type changes to objects and to programs that use objects of the type. The rst systematic analysis of desirable schema evolution possibilities was done for the ORION data model in BKKK87, BCG 87]. A set of all necessary schema updates was listed and organized in a taxonomy. Similar enumerations can also be found for the O Zic90] and the GemStone DBMS PS87], actually forming a subset of ORION's taxonomy. The schema update primitives of the above taxonomy are realized as special purpose operators for schema management. That is, for every possibility there is a function. So nally, the collection of these operators build a "schema update language". Our approach is di erent in that we try to use a transparent meta level: In our objectoriented data model COCOON, we consider schema objects as objects like others, and have the meta types and meta classes available at any time. We allow the use of our object algebra COOL in the same way on the meta level as on the primary object level. So there is no di erence in the syntax of the descriptive algebra operators, whether they query or update data-, schema-, or meta objects. In fact, representation of the meta schema within the same model is an old idea. However, usually such meta data serve only for documentation purposes. That is, only queries are allowed. In contrast, here we investigate the feasibility of updates to meta objects and their propagation to the instances. The paper is organized as follows. In the next section, we sketch our object model and its algebra. We introduce the schema and meta level objects in Section 3. In Section 4 we discuss the problems that arise, if we allow the algebra to work on the meta objects.

ABSTRACT Aspects and Transformations to Support Evolution in Model-Driven Engineering

Aspects and Transformations toSupport Evolution in Model-Driven EngineeringJeff Gray, Yuehua Lin, Jing ZhangUniversity of Alabama at BirminghamABSTRACTA key benefit of system and software modeling is the ability to explore various design alternatives to reach a fixed-point representation of a concrete system design. Among a diverse set of configuration possibilities, a model engineer must be able to explore the effects of a design decision (e.g., the effect of a specific communication protocol on systemic properties such as throughput) in a rapid manner and be able to revert back to a previous configuration. Each new design configuration can be simulated or analyzed to determine the effect on a set of observed properties. There are two key challenges in supporting evolution in model-driven engineering: 1) the emergence of crosscutting properties that are projected across a model hierarchy, and 2) scalability issues that concern the expansion of a base model. We have applied model transformation to provide an automated solution that addresses these two modeling challenges.KEYWORDS/TAXONOMYD.2.2 [Software Engineering]: Design Tools and Techniques – Object-oriented design methods.D.2.5 [Software Engineering]: Programming Environments – graphical environments.A s the size of system models grow, the limits of model-driven engineering practice are being pressed to address increasingly complex management issues that pertain to change evolution within the model representation [1]. Consequently, modeling tools are being challenged to provide new capabilities to assist in model evolution. A general metric for determining the effectiveness of a modeling toolsuite comprises the degree of effort required to make a correct change to a set of models. A goal of model evolution is to improve productivity while reducing the potential for error that is typically associated with a manual process. To reduce the complexity of the modeling activity, an approach to model evolution should limit the amount of mouse clicking and typing required to realize a change.There are two categories of change evolution that present specific problems for the modeling process. The first category pertains to concerns that crosscut the hierarchy of the model representation. Such changes require the model engineer to visit multiple locations in the model in order to address a specific concern. For example, the effect of fluctuating bandwidth on the quality of service in a video stream may crosscut multiple components that are defined in a model. The application of aspect-oriented techniques [2] at the modeling level can provide a solution to this type of evolution by modularizing the crosscutting property. A second category of change evolution concerns the issue of scalability, where a base model is replicated to expand the size of a model. For example, a core model may capture the essential connections and properties of a sensor network that can then be scaled to an arbitrary number of sensors. This type of change requires the creation of multiple modeling elements and the appropriate connections between them.A manual approach to address these two categories of change is typically inadequate. As an alternative to manual model evolution, we have applied a model transformation approach to assist in the automation of evolving modeling concerns. In this article we motivate the need for change evolution among these two categories through specific examples from models in the mission-computing avionics domain. The practical benefits of applying aspects and transformations at the modeling level are emphasized by the significant reduction of manual effort.AUTOMATED MODEL TRANSFORMATIONModel transformation provides an opportunity to automate several of the tasks that are typically performed manually in model-driven engineering. Such automation is a key to the concepts associated with a software factory [3], which aims to remove several remaining accidental complexities associated with software development. Numerous techniques and tools have been developed to support model transformation (please see accompanying sidebar for an overview). To perform model transformations in an automated manner, modeling tools need to offer a specific language for model developers to define their own transformations and execute these transformations on demand [4]. Our investigation into the development of a model transformation engine suggests that such a language needs to possess the following two characteristics:•The language should be domain- and user-centered. The primary goal for the design of a transformation specification language should allow users to describe a transformation using concepts from their own domain.Among the language considerations of conciseness and comprehension, the key to the design of a transformation language is a set of core abstractions that are intuitive and cover the largest possible range of situations implied by current modeling practice. To achieve this goal, a user-centered transformation language should consist of a small set (ideally a minimized set) of concepts and constructs, but be powerful enough to express a complete set of desired transformation activities.•The language should be specific to model transformation. A model transformation language needs to have full power to specify all types of modeling objects and transformation behaviors, including model navigation, model querying and model modification. This requires both a robust type system and a set of functionally rich operators. In addition to full expressiveness, such a language should provide specific constructs and mechanisms for users to describe model transformations in an efficient way. In other words, a transformation language is also a domain-specific language that captures all the features of the model transformation domain. The Constraint-Specification Aspect Weaver (C-SAW) was designed with these two characteristics in mind. Figure 1 presents the model transformation process from the perspective of C-SAW. A set of input models, as defined by a specific domain represented by a metamodel, serve as input to C-SAW. A transformation specification is also required to define the specific changes to be made to the source models. The language that is used by C-SAW to describe a transformation specification is the Embedded Constraint Language (ECL), which was created as an extension to the Object Constraint Language (OCL). The output of C-SAW is a set of transformed target models. C-SAW is implemented as a plugin for the Generic Modeling Environment (GME), which provides an environment for defining new modeling environments [5]. The implementation issues associated with C-SAW are presented in the middle of Figure 1, which illustrate the connection between the GME modeling API with the ECL parser and interpreter. Additional information about C-SAW (including papers, software, and videos) can be found at /gray/Research/C-SAW/Key Constructs of a Model Transformation LanguageECL provides many capabilities to assist a model engineer in writing transformation specifications that reflectively refer to concepts from the user’s modeling domain in order to refine a model in a stepwise manner [6]. This allows transformations to be written concisely and intuitively because the transformations refer to domain elements recognized by the model engineer. The ECL constructs that support such transformation include a type system, a mechanism for selecting modeling elements, and a set of operators to manipulate the source models.Figure 1. The model transformation process with the Constraint-Specification Aspect Weaver (C-SAW). Source models and a transformation specification serve as input to a transformation engine that derives new target models.Type System. In GME terminology, a model is structurally a graph where its elements are the nodes of the graph and the relationships between elements are the edges of the graph. An atom is a model element that can not contain any other model elements. A model may be a container in which there may be a combination of submodels and atoms. Both models and atoms have a set of properties. ECL provides a basic type system to describe values and model objects in a transformation. The data types in ECL include standard primitive data types (e.g., boolean, integer, real and string) and model object types (e.g., atom, model, object and connection) that can reflectively refer to domain concepts specified in the metamodel.Model selection and aggregation. A common activity during model transformation is to find the elements in a model that may need to be modified. There are two different approaches to locating model elements. The first approach - querying - evaluates a predicate expression over a model, returning those elements of the model for which the expression holds. The other common approach uses pattern matching where a term or a graph pattern containing free variables is matched against the model. ECL supports model queries by providing the select operator and a set of special operators on model aggregations to select a collection of model objects. There are also a set of operators to find a single model object.The select operator is frequently used in ECL to specify a selection from an existing collection, which can be the result of previous operations and navigations. The result of the select operation is always a subset of the original collection. There are also numerous operators to support model aggregation. For example, models(<expression>) is used to select all the submodels that satisfy the constraint specified by theexpression. Other query operators include atoms(<expression>), connections(<expression>) andattributes(<expression>). Operators like findAtom and findModel are used to find a single atom or model; source and destination are used to return the source object and the destination object in a connection. Transformation operations. The primary model transformation operations include adding model objects, removing model objects and changing model object properties. Standard OCL does not provide such capabilities because it does not allow side effects to a model. However, a transformation language should be able to alter the state of a model. ECL extends the standard OCL by providing a series of operators for changing the structure of a model. To add new elements (e.g., a model, atom or connection) to a model, ECL provides such operators as addModel, addAtom and addConnection. Similarly, to remove a model, atom or connection, there are operators like removeModel, removeAtom and removeConnection. To change the value of any attribute of a model element, setAttribute can be used.Sidebar: Model TransformationAs a core component of Model-Driven Engineering, model transformation represents the process of applying a set of transformation rules that take one or more source models as input to produce one or more target models as output [1]. There are two major categories of model transformation: model-to-code transformation and model-to-model transformation [2]. Model-to-code transformation generates source code (e.g., Java or C++) from models. The focus of such transformation is to generate artifacts at a lower level of abstraction that can be executed. Model-to-model transformation occurs at the same level of abstraction by translating between source and target models. Many modeling activities can be automated by model transformation to improve the productivity of model engineers and ensure the quality of models. Typical model transformation activities include model refactoring, model optimization, model refinement and model scalability.To support the automation of model transformation, development tools need to offer a language for model engineers and developers to specify and execute the desired transformations. In general, there are three different approaches for defining transformations, as summarized from [1]: •Direct Model Manipulation – developers access an internal model representation and use a general purpose programming language (GPL), such as Java or C++, to manipulate the representation from a set of procedural APIs provided by the host modeling tool.•Intermediate Representation – a modeling tool can export the model into an intermediate representation format (e.g., XML).Transformations can then be performed on the exported model by an external transformation tool (e.g., XSLT), and the output models can be imported back into the host modeling tool.•Specialized Transformation Language – a specialized transformation language provides a set of constructs for explicitly specifying the behavior of the transformation. A transformation specification can typically be written more concisely than direct manipulation with a GPL.Currently, numerous specialized model transformation languages have been proposed by both academic and industrial researchers. These languages are used to define transformation rules and rule application strategies that can be either graphical or textual. Additionally, model transformation languages may be either imperative or declarative [2]. In addition to our C-SAW, some representative examples of other transformation systems follow:•Graph Rewriting and Transformation Language (GReAT)[3] is a graphical transformation language based on graph grammars and graph transformations. In this approach, models are treated as graphs and model transformations are specified as graph transformations. Graph transformations are realized by the application of transformation rules, which are rewriting rules for graphs. A transformation rule consists of two parts: the Left Hand Side (LHS) is a graph to match, and the Right Hand Side (RHS) is a replacement graph. If a match is found for the LHS graph, then the rule is fired, which results in the matched sub-graph of the graph under transformation being replaced by the RHS graph. GReAT provides graphical notations to specify graph patterns, model transformation rules and control flow of transformation execution.•ATLAS Transformation Language (ATL) [4] is a hybrid transformation language, which combines declarative and imperative constructs.Declarative constructs are used to specify source and target patterns as transformation rules (e.g., filtering model elements), and imperative constructs are used to implement sequences of instructions (e.g., assignment, looping and conditional constructs).Although there exist different approaches to model transformation, the Object Management Group (OMG) initiated a standardization process by issuing a request for proposals on Query/Views/Transformations (QVT), which is near finalization [5].References1.S. Sendall and W. Kozaczynski, “Model Transformation - the Heart and Soul of Model-Driven Software Development,” IEEE Software,September/October 2003, pp. 42-45.2.K. Czarnecki and S. Helsen, “Classification of Model Transformation Approaches,” OOPSLA Workshop on Generative Techniques in theContext of Model-Driven Architecture, Anaheim, California, October 2003.3. A. Agrawal, G. Karsai, and A. Lédeczi, “An End-to-End Domain-Driven Software Development Framework,” 18th Annual ACM SIGPLANConference on Object-Oriented Programming, Systems, Languages, and Applications (OOPSLA), Anaheim, California, October 2003, pp.8-15.4.I. Kurtev, K. van den Berg, and F. Jouault, “Rule-based Modularization in Model Transformation Languages Illustrated with ATL,” ACMSymposium on Applied Computing (SAC) - Model Transformation Track, Dijon, Bourgogne, France, March 2006.5.MOF 2.0 Query/Views/Transformations RFP, Object Management Group, 2002. /docs/ad/05-07-01.pdf.CROSSCUTTING DESIGN PROPERTIESWhen a concern is spread across an artifact it can be difficult to comprehend and change. Aspect-oriented software development (AOSD) [2] is focused on techniques to modularize concerns that crosscut the decomposition of a system. Although the original application of aspects was focused at the programming language level, there is a growing community investigating aspect-oriented modeling (e.g., the Aspect-Oriented Modeling workshop has met eight times - rmatik.uni-essen.de/events/AOM_AOSD2006/). The most prominent work in aspect modeling is concentrated on notational aspects for the UML [7], but there are also opportunities to provide automation within modeling tools using AOSD principles. In fact, our original development of C-SAW five years ago was motivated by the need to specify constraints that were found to be crosscutting within the model of a distributed real-time embedded system (DRE) [8]. C-SAW has evolved into a general model transformation tool that is capable of addressing a wide range of transformations.Aspects of Embedded Systems ModelsThe top of Figure 2 shows the interaction among components in a mission computing avionics application that is modeled in the Embedded Systems Modeling Language (available from /tools/). The internal representation of two components are shown in the middle of the figure, which reveals the data elements and other constituents that are specifically intended to describe the infrastructure of component deployment and distribution middleware. The infrastructure implements an event-driven model of computation where components update and transfer data to each other through event notification and call-back methods.A concurrency atom and two data atoms are circled within the selected components in Figure 2. Each of these atoms represents a concern of the system that is spread among the components across the modeling hierarchy. The concurrency atom (highlighted by a red circle) identifies a property of the system that corresponds to the synchronization strategy that is distributed across the components. The collection of atoms circled in blue defines the recording policy of a black box flight data recorder. A precondition is attached to some of the data elements (indicated by the green circle) to assert a set of valid values upon component invocation.The challenge of model evolution with respect to crosscutting properties can be understood by considering the effort that is needed to change the synchronization or black box data recorder policies. To make a change to an existing policy in order to analyze the affect of an alternative design decision requires that the model engineer visit every component to make the change manually. This results in much mouse clicking and typing in the modeling tool in order to navigate across the model hierarchy, especially when the size of the models are large (e.g., the specific system modeled in Figure 2 represents a subset of an application that has over 6,000 components).Figure 2. A subset of a model hierarchy with crosscutting model properties. Concerns related to synchronization (red circle), black-box data recording (blue circle), and preconditions (green circle) are scattered across many submodels.As an alternative to manual evolution, ECL can be used to define an aspect that assists in the automated evolution of the model. For example, to specify that all data2_ atoms must have a precondition defining the valid range of values, the following modeling aspect can be defined:aspect PreData2(){rootFolder().findFolder("ComponentTypes").models()->select(m|().endWith("Impl"))->AddPre(“data2_”, “Data2Cond”, “value<200”); }This modeling aspect can be interpreted as, “From the root folder, collect all of the models that are of type ComponentTypes. From this collection, select all of the components whose name ends with ‘Impl’ and apply the AddPre strategy.” In C-SAW, an aspect is applied by traversing a model and matching elements of the model that satisfy a predicate (e.g., the selection predicate in the PreData2 aspect). Those elements that satisfy a given predicate are then transformed according to the rules in the associated strategy. A strategy is a modular construct provided by ECL to define the transformation within a model. Each strategy should be performed in a specific modeling context, which is provided by the aspect. The context of a strategy call can be an entire project; a specificmodel, atom, or connection; or a collection of assembled modeling elements. Using the ECL, aspects are defined toquantify those modeling elements that are to be changed, and a strategy is applied to perform the required transformation.The AddPre strategy shown in Listing 1 is applied to each component selected from the PreData2 aspect. This strategy finds all of the atoms in the component that are of type Data which match the name passed in as an argument from the aspect. All of the Data atoms that match this predicate will have a new precondition attached by the AddCond strategy. Line 12 of AddCond retrieves a placeholder for the actual Data that will be transformed. The parent component that contains the Data atom is reflectively obtained in line 13. The transformation sequence defined in lines 15 through 17 creates a new Condition atom (line 15) and sets those attributes defining a precondition with an associated expression (lines 16 and 17). The final task of the AddCond strategy adds a connection to the parent component that links the Data atom to the new Condition.1strategy AddPre(atomName, condName, condExpr : string)2{3 atoms()->select(a | a.kind() == "Data" and () == atomName)->4 AddCond(condName, condExpr);5}67strategy AddCond(condName, condExpr : string)8{9 declare p : model;10 declare data, pre : atom;1112 data := self;13 p := parent();1415 pre:=p.addAtom("Condition", condName);16 pre.setAttribute("Kind", "PreCondition");17 pre.setAttribute("Expression", condExpr);18 p.addConnection("AddCondition", pre, data);19}Listing 1. ECL transformation to add a precondition expression to a Data atom.AUTOMATED MODEL SCALABILITYA second form of design exploration involves scaling up different parts of a model. Scalability of modeling tools is of utmost concern to designers of large-scale DRE systems. From our personal observation, models can have multiple thousands of coarse grained components (others have reported similar experience, please see [1]). System modeling using traditional manual techniques and tools can approach the limits of the effective capability of humans. The issue of scalability affects the performance of the modeling activity, as well as the correctness of the model representation. Consider a base model consisting of a few modeling elements and their corresponding connections. To scale a base model to hundreds, or even thousands, of duplicated elements would also require a lot of clicking and typing within the associated modeling tool. Furthermore, the tedious nature of manually replicating a base model may also be the source of many errors (e.g., forgetting to make a connection between two replicated modeling elements). A comparison of approaches to support automated model scalability can be found in [9]. Replicating a CORBA Event Channel ModelFigure 3 provides an illustration of scalability applied to the Event QoS Aspect Language (EQAL), which has been used to configure a large collection of federated event channels for mission computing avionics applications (EQALis available for download at /cosmic). The scalability issues in EQAL arise when a small federation of CORBA event services must be scaled from a base model to accommodate a larger number of publishers and subscribers. As can be seen in Figure 3, scaling an EQAL model from three sites (with two gateways per site) to a larger model containing 8 sites (with 7 gateways per site) requires the addition of many new modeling elements. Our experience has shown that model transformations serving as replicators can significantly automate this manual task.Figure 3. Replication among a federation of CORBA gateways. At the outermost level, three federation sites are replicated to eight sites, with each internal site replicated from two to seven gateways.The expandSite strategy in Listing 2 illustrates a transformation that replicates the internal CORBA gateways for a specific site. The site and number of desired gateways are passed as parameters in line 1 of the strategy, which then finds the specific site in line 3 and calls a recursive strategy. The addGateWay_r strategy ensures that the proper number of gateways is added. The addGateWay strategy performs the actual transformation on the model by creating a new gateway (line 19), locating the site’s core event channel (line 20) and connecting the new gateway to the existing channel (line 21).The collection of interacting strategies in Listing 2 accomplishes the transformation that is shown in the upper-right of Figure 3 (i.e., the internal expansion of Site 2). These strategies are also reusable and can be utilized by a model engineer to flexibly explore a design by applying the transformation to several different sites. Although not shown here, a different set of transformations have been specified to scale the outermost number of sites (i.e., moving from three sites to eight sites, as shown in the bottom-right of Figure 3). The parameterization of expandSite is a key to defining the alternative designs. These strategies are not an “aspect” in the sense of Listing 1, but represent a different type of model evolution that can also be specified in a transformation language like ECL.Considering Figure 3, to perform the equivalent transformation manually would require the insertion of over 120 new modeling elements and almost 150 connections between all of the new elements. Such a manual task is time consuming and prone to error. Furthermore, the real disadvantage of a manual process to replication can be seen when the next design alternative needs to be considered (e.g., scaling to 20 sites with 12 gateways per site), which requires a whole new set of manual modifications. The model transformation of Listing 2 can flexibly handle such replication through parameterization of the specific strategies.1strategy expandSite(site, numGW : integer)2{3 findModel("Site " + intToString(site)).addGateWay_r(1, numGW);4}56strategy addGateWay_r(curr, numGW : integer)7{8 if (curr <= numGW) then9 addGateWay(curr);10 addGateWay_r(curr+1, numGW);11 endif;12}1314strategy addGateWay(num : integer)15{16 declare site_gw : atom;17 declare ec : model;1819 site_gw := addAtom("CORBA_Gateway", "CORBA_Gateway" + intToString(num));20 ec := findModel("Event_Channel");21 addConnection("LocalGateway_EC", site_gw, ec);22}Listing 2. Model transformation to expand the number of CORBA gateways at a specific site.T ool support for programming language environments is much more advanced than the current capabilities offered in modeling tools. Integrated Development Environments (IDEs) for programming languages provide numerous features for comprehending and evolving large code bases (e.g., automated refactoring, code navigation and visualization). Despite recent advances in modeling tools, there are still many tasks that can benefit from increased automation. Our experience has led us to believe that model transformation can provide a common technology for implementing various kinds of model evolution. In particular, our C-SAW transformation engine has been applied to several modeling languages in the domain of distributed real-time and embedded system in order to modularize crosscutting properties and replicate elements of a core model. We are exploring several additions that will provide extra value to the transformation process, such as testing and debugging support for the ECL to detect and find errors that may exist in a transformation specification.AcknowledgementsThe initial investigation of this research was made possible by previous support from the DARPA PCES program. Current support from the NSF CSR-SMA program is enabling the application of these ideas toward evolution of performance modeling for distributed design patterns.。

Modeling Aspect-Oriented Compositions

Modeling Aspect-Oriented CompositionsThomas Cottenier1, 2, Aswin van den Berg1, Tzilla Elrad21 Software and Systems Engineering Research, Motorola Labs1300 E Algonquin Road, 60173 Schaumburg, IL, USA{thomas.cottenier, aswin.vandenberg}@2 Concurrent Programming Research Group, Illinois Institute of Technology3300 S Federal Street, 60616 Chicago, IL, USA{cotttho, elrad}@Abstract. Crosscutting concerns are pervasive in embedded software, becauseof the various constraints imposed by the environment and the stringent QoS re-quirements on the system. This paper presents a framework for modularizingcrosscutting concerns in embedded and distributed software, and automatingtheir composition at the modeling level, for simulation and validation purposes.The proposed approach does not extend the semantics of the UML in order torepresent aspects. Rather, it dedicates a metamodel to the representation of thecomposition semantics between aspects and core models. The paper illustratesthis approach by presenting a model weaver for SDL statecharts developed atMotorola Labs. Crosscutting behavior is designed with plain SDL statechartsand encapsulated into modules called aspect beans. The weaver looks at the as-pect beans and the core SDL statecharts from a perspective that is defined bylightweight extensions to the SDL and UML metamodels. A connector meta-model defines the structure of the aspect-to-core binding definition. Finally, aweaver behavioral metamodel defines composition primitives for specifyingweaving strategies.1 IntroductionModel-Driven Development (MDD) is a software development methodology that emphasizes precise modeling for automated generation of optimized code. MDD techniques also target automated simulation, verification, use-case validation and test case generation. MDD approaches have been widely adopted in the industry, espe-cially for the development of applications that have stringent performance require-ments, such as embedded control software for telecommunication devices. Embedded Software applications are especially difficult to design and build be-cause of the constraints placed on them and because of the problem domain. The telecommunication industry has therefore driven a research effort towards a standard specification language for real-time, stimulus response systems, the Specification and Description Language (SDL) [1]. SDL is standardized as an ITU recommendation, and has continually evolved since its first version in 1980 to now include Object-Oriented features. In SDL, the basis for description of behavior is communicating Extended State Machines that are represented by processes. Communication is repre-sented by signals that can take place between processes or between processes and theenvironment of the system. Under pressure of the industry, the UML 2.0 has adopted some core features that are inspired by the SDL, such as a framework for dealing with Actions. The UML profile for Communicating Systems (UML-CS) [2] complements these extensions, to provide full support for SDL modeling, within the UML. For example, the UML-CS provides support for the definition of timers. Over the years, the industry has developed powerful code generators that take SDL models as input, map the models to some internal code representation and perform aggressive code optimizations. The generated code is mostly C code.Typically, the process from requirement analysis to implementation and testing in-volves the following steps. The initial requirements are collected in a text document. System analysis results in UML models and Message Sequence Charts (MSC) [3] that capture the typical scenarios. The classes are mapped to SDL semi-automatically, and the SDL diagrams are completed manually to a level where they can be checked for consistency, simulated and validated. A test suite is generated from the SDL specifi-cation and finally, executable code is generated fully automatically.Yet, the modeling process is time-consuming and error prone. All implementation details need to be reflected at the modeling level, before the application models can be simulated, and code can be generated. Many of these implementation details relate to the non-functional requirements of these applications, such as fault-tolerance, logging or security. In many cases, the hierarchical decomposition paradigm of SDL does not enable those concerns to be well modularized into separate SDL modules.The Aspect-Oriented Software Development (AOSD) [4] community identifies those concerns as being crosscutting concerns. Their implementation cannot be well encapsulated within the modularity units of the language, because they follow differ-ent composition rules. Crosscutting concerns are pervasive in embedded software, because of the various constraints imposed by the environment and the stringent QoS requirements on the system. During the initial design phases, these concerns cannot be mapped from requirement to design in isolation, and end up tangled with model elements that implement other requirements.This work proposes a framework for modularizing crosscutting concerns in em-bedded software, and automating their composition at different phases of the code generation process, including the modeling level, the different intermediary code representation levels and at the level of the final generated code. This paper discusses aspect modeling within the framework.2 Approaches to AO Modeling2.1 Lightweight UML ExtensionThe lightweight extension to the UML approaches take advantage of the UML exten-sion mechanisms (stereotypes, tagged values and constraints) to refine the UML meta-model as to support AOP language constructs. The works of Pawlak [6], Aldawud [7] and Stein [8] fall into this category. These approaches provide graphical notations for aspects, for example, by defining pointcut associations, which link advices to join-points. The aspects tend to be tightly coupled to the core model. For large projects,the relations might involve many classes of the application, and the visual representa-tion of crosscutting does not scale well. The result of composition is complex and difficult to read and comprehend. The design model looks like a woven model.The authors’ position is that joinpoints are a validation and verification issue. This implies that during the design phase, we do not want to know where the joinpoints are, and hence, we do not need an explicit modeling construct for them.2.2 Heavyweight UML ExtensionThe proponents of heavyweight extensions to the UML argue that aspects need to be first-class elements in the UML, because lightweight extension mechanisms are not expressive enough to capture weaving semantics by themselves, The heavyweight UML extension approaches define a self-contained metamodel that fits AOSD. The metamodel is obtained by tailoring the UML kernel metamodel. Heavyweight exten-sions provide graphical notations for aspects, but do not define the weaving concept explicitly. The works of Kandé [9], Han [10] and Lions [11] fall into this category. Heavyweight approaches are complex to implement. Furthermore, when extending the UML metamodel, all the tools that realize test case generation, model validation and code generation need to be refactored to support the new AO metamodel.2.3 Model Transformation ApproachesModel transformation approaches recognize the weaving process as a concept in the expanded metamodel of the UML. Model weaving approaches realize the coordina-tion of crosscutting concerns with a base model through model transformation. Model weaving provides the capability to describe the essence of a concern into a separate model and transform other models accordingly. These approaches have the disadvan-tage that the AOP language constructs have no clear counterpart at the modeling level. The work of Gray [12] falls into this category.2.4 Hybrid ApproachesHybrid approaches to AOM recognize weaving as a concept in the modeling process, but leverage the weaving process by extending the UML metamodel. Typically, the metamodel for modeling core program elements is extended to support a join point model. The metamodel for modeling aspects is extended to support the notion of aspect, advice, pointcut and intertype declaration. A model weaver composes the aspect models with the core models by associating advice bodies to joinpoints, and intertype declaration to core model elements.Tkatchenko [13] proposes a simple joinpoint model that is implemented through a heavyweight UML extension. The weaving process can partly be made implicit, be-cause the extended metamodel extension captures part of the weaving semantics. The work of Clarke and Baniassad [14] proposes a UML design model that en-compasses different separation-of-concern techniques, including aspect-oriented de-compositions. A Theme represents a modularized view of a requirement or concern in the system. The behavior of aspects is modeled using diagram templates. Themes are coordinated semi-automatically by an engine that applies merge and replace rules, and parameterizes the diagram templates, by binding adviced methods to concrete joinpoints.The work of Reddy [15] also takes advantage of UML templates for designing ge-neric crosscutting features. Before composing the models the weaver instantiates the aspect models by binding application-specific elements to the template parameters.2.5 AOM and MDAThe hybrid approach has interesting connections with the OMG Model Driven Archi-tecture (MDA) [6]. The MDA separates platform independent details from the plat-form specific details of the system in a series of models. The approach is for each concern, to automatically expand more abstract diagrams by substituting the more concrete sub-diagrams into the abstract one. MDA proceeds by defining model trans-formation specifications that will automatically introduce, for example, platform spe-cific behavior into a platform independent model. The transformation maps model elements of one domain metamodel to model elements of a target metamodel. The transformation is defined according to a transformation metamodel that defines the primitives of the transformation.The hybrid approach defines a domain metamodel (a metamodel for modeling as-pects), a target metamodel (a metamodel to visualize crosscutting behavior) and model transformation rules that conform to an AOSD metamodel. Aspects inject some more specific concern implementations into a more abstract model.The relationship between MDA model transformations and model weaving is analogous to the relationship between AOP languages and Meta Object Protocol (MOP) languages. MOP’s enable more powerful transformations, but are hard to write. AOP restricts the transformation space to a limited set of transformations, on a limited set of language elements. Aspects are less powerful, but provide better modu-larization units, and cover much of the MOP transformation space.3 Aspect-Oriented Composition for Communicating Systems3.1 RequirementsIn an MDD setting, the SDL statechart weaver needs to accommodate the following constraints:-The semantics of the SDL metamodel elements used to model the core application can not be modified to accommodate aspect weaving. It should be possible to simulate, validate and generated code from those models with the existing MDD tool suite.-The aspect behavior needs to be specified in standard SDL, so that crosscutting behavior can be simulated and validated independently, and that code can be gen-erated with the existing MDD tool suite. The metamodel used to model aspect be-havior can therefore not break the semantics of SDL.-It should be possible to validate and simulate the result of the composition be-tween core models and aspect models using the existing MDD tool suite. The statechart weaver should therefore produce models that conform to the SDL metamodel.Within an industrial setting and a specific domain, many crosscutting concerns tend to have common implementations from an application to another. The models that implement crosscutting concerns are themselves reusable from one application to another. What differs from one application to another are the bindings between aspect and core model. Therefore, we adopt an Aspect-Oriented architecture that involves a connector – a component that binds generic (within the domain) advices to applica-tion specific joinpoints. It encapsulates pointcut expressions and context binding definitions between joinpoints and named advices. The aspect advices are therefore made more reusable, as they do not depend on application-specific pointcut expres-sions.This approach differs from the previous ones in that neither the core models, nei-ther the aspect models require specific support for aspect-orientation. The author’s position is that much of the complexity of aspect-oriented modeling is due to the difficulty of representing the aspect/core semantic interactions. This complexity can be overcome by defining separate diagrams that model the composition between the aspect behavioral diagrams and the core models.3.2 AspectSDL: An SDL Statechart WeaverThe crosscutting behavior is modeled using regular SDL statecharts. Those models are referred to as SDL Aspect Beans. A connector defines the bindings between as-pect bean statecharts and the core model statecharts. Figure 1 illustrates the architec-ture of the AspectSDL weaving engine. The SDL statechart weaver operates accord-ing to four distinct metamodels:- A lightweight extension to the SDL profile that defines the joinpoint concept for SDL statecharts- A lightweight extension to the UML metamodel that defines the concepts of aspect bean, advice, and intertype declaration.- A connector metamodel that specifies how the bindings between aspect beans and model elements are defined. The connector metamodel is a structural weaving metamodel. It defines the static concepts the model weaver uses to identify cross-cutting, such as pointcut and advice declaration.- A behavioral weaving metamodel that specifies how weaving strategies are de-fined. A weaving strategy defines the operations to be performed to bind an aspect bean element to the core model. Weaving strategies define the weaving semantics.The behavioral weaving metamodel defines a metaprogramming API for the weav-ing engine.Fig. 1. Architecture of the AspectSDL weaving engine. The SDL statechart weaver operates according to four distinct metamodels: a joinpoint metamodel, an aspect bean metamodel, a connector metamodel and a behavioral metamodel of the weaver 3 AspectSDL Metamodels4.1 Aspect Bean ProfileThe Aspect Bean profile defines how the AspectSDL weaver looks at the Aspect Bean SDL statecharts. Aspect Beans are defined as Class stereotypes. We adopt an aspect model where advices have an explicit name. This allows advices to be defined independently of pointcut expressions. Advices are defined as Operation stereotypes. This is consistent with Stein’s UML notation for Aspect-Oriented Design [8]. An advice is a special kind of operation that may not be called explicitly. InterType at-tributes are defined as Attribute stereotypes and InterType operations are defined as Operation stereotypes.4.2 Joinpoint ProfileThe extensions to the SDL metamodel described in this section are defined with re-spect to the UML profile for SDL [2], as represented in Telelogic TAU G2 [16]. The Joinpoint profile defines which elements in the SDL statecharts can be consid-ered as joinpoints. The joinpoint metamodel should be as simple as possible. A simple joinpoint metamodel is one that allows various types of joinpoints to be treated uni-Behavioral Metamodel of Weaver Engine MetaPrograming Models Transformationformly. The Action concept of UML 2.0 matches the concept of a joinpoint well. An action is the finest level of granularity for the specification of a method. All methods directly or indirectly contain actions. When a method is executed, all or some of these actions are executed. The action concept captures all the caller side types of joinpoints in an Aspect language.The Joinpoint profile defines a call joinpoint as an Action stereotype. The “Call-Joinpoint” stereotype applies to all Actions that have an “Action Expression”. During the weaving process, all actions whose action expression matches a call pointcut ex-pression are selected as active joinpoints.Method execution joinpoints are not captured by the Action concept. A method execution joinpoint can be seen as a UML 2.0 Method. A Method is the implementa-tion of an operation, describing how it is executed at runtime. A method is associated to an expression that identifies the operation it implements.The Joinpoint profile defines an execution joinpoint as a Method stereotype. Dur-ing the weaving process, all methods whose expression matches an execution pointcut expression are selected as active joinpoints.Fig. 2. The Joinpoint ProfileAs shown in Figure 2, there is a nice symmetry between caller side and execution joinpoints. While execution joinpoints own an entry and an exit operation, caller side joinpoints are owned by an entry State and an exit State. The entry and exit relation-ships correspond to the location where before, after and around advice elements are woven. Most types of joinpoints are covered by the metamodel, while it does not capture elements that are irrelevant to aspect weaving. In [13], Tkatchenko proposes a Joinpoint metamodel, where all elements that include a declaration signature are con-sidered joinpoints. Yet, this metamodel captures elements that are irrelevant to aspect weaving, while it does not cover method return or method execution joinpoints. Figure 3 depicts some of the joinpoints that are captured by the caller side joinpoint stereotype. Aside from the usual types of joinpoints such as method call (Expres-sionAction), exception throwing (ThrowAction), and the return joinpoint (ReturnAc-tion) it also supports new types of joinpoints that are useful for embedded and distrib-uted software development, such as Set Timer, Reset Timer, Send Signal and Receive Signal.Fig. 3. Caller side joinpoint typesFig. 4. The Connector Metamodel4.3 Connector MetamodelThe connector is used in the first phase of the weaving process, to identify all active joinpoints in the core model, and the advices of the aspect bean. The connector also defines the binding between advice arguments and pointcut parameters. It captures context passing between the core model elements and the aspect bean model ele-ments. The connector metamodel of Figure 4 defines the structure of the aspect-to-core binding definition. An Advice definition is bound to one or more pointcuts. A pointcut is composed of a pointcut expression and a scope expression which narrows the scope of the pointcut. Scope expressions include ‘within’ and ‘cflow’ expressions.4.3 Weaver Behavioral MetamodelSDL statechart weaving primary serves simulation and validation purposes. The goal of the AspectSDL framework is larger. The framework intends to provide pluggability of crosscutting concerns at different phases of the code generation process, including the modeling level, the different intermediary code representation levels and at the level of the final generated code. Weaving at the level of the intermediary code repre-sentation needs to be consistent with model weaving, as to not affect the simulation, verification and validation processes. There is therefore a need for mechanisms that provide traceability between the weaving semantics at the model level, the intermedi-ary code representation level and the code level. The weaver behavioral metamodel intends to provide a common set of primitives to describe the weaving semantics at those different levels, using weaving strategies. The metamodel would enable the actions of the weavers of the framework to be consistent. At the second phase of the weaving process, joinpoints and advices have been identified, and their bindings are defined. Weaving strategies define the operations to be performed on the core model to implement the binding definition. These operations may vary from one type of joinpoint to another and from one type of diagram to another.5 ConclusionsWe distinguish between modeling crosscutting behavior (Aspect Beans) and modeling the aspect composition. The authors’ position is that the UML is suited for modeling aspect beans, but that it cannot accommodate the complex semantics of the weaving process. Therefore, we dedicate a separate metamodel for an aspect connector, whose role is to define primitives for modeling the composition between models that encap-sulate the behavior of aspects and the models that capture the core concerns of the application. The paper illustrates this approach by presenting a model weaver for SDL statecharts. AspectSDL adopts an aspect modeling approach that recognizes weaving as a specific type of model transformation. The AspectSDL composes core models and aspect bean models according to a binding definition (connector) and weaving strategy definitions. Lightweight extension to the SDL profile are proposed, a connec-tor metamodel is presented and a weaver behavioral metamodel is discussed.AcknowledgementsThis work is partially supported by CISE NSF grant No. 0137743, and performed at Motorola Labs.References1.ITU, Z. 100: Specification and Description Language (SDL), ITU-T, Geneva (2000)2.ETSI: UML Profile for Communicating Systems, DTR/MTS-00085 (2004)3.ITU, Z.120: Message Sequence Charts (MSC), ITU-T, Geneva (2000)4.Kiczales, G., et Al.: Aspect-Oriented Programming. Proceedings of the European Confer-ence on Object-Oriented Programming, Springer-Verlag (1997)5.OMG: Model-Driven Architecture homepage /mda/ (2000)6.Pawlak, R., et Al.: A UML Notation for Aspect-Oriented Software Design. 1st InternationalWorkshop on Aspect Oriented Modeling at the 1st International Conference on Aspect-Oriented Software Development, Enschede, The Netherlands (2002)7.Aldawud, O., Elrad, T., Bader, A.: A UML Profile for Aspect- Oriented Software Design.3rd International Workshop on Aspect Oriented Modeling at the 2nd International Confer-ence on Aspect- Oriented Software Development, Boston, USA (2003)8.Stein, D., Hanenberg, S., Unland, R.: A UML-Based Aspect-Oriented Design Notation forAspectJ. Proceedings of the 1st international conference on Aspect-Oriented Software De-velopment, Enschede, The Netherlands (2002)9.Kand , M..M., Kienzle, J.,Strohmeier, A.: From AOP to UML , A Bottom-Up Approach,Aspect-Oriented Modeling with UML workshop at the 1st International Conference on Aspect-Oriented Software Development, Enschede, The Netherlands (2002)10.Han, Y., Kniesel G., Cremers A.: Towards Visual AspectJ by a Meta Model and ModelingNotation, 6th International Workshop on Aspect-Oriented Modeling at the 4th Interna-tional Conference on Aspect-Oriented Software Development, Chicago, USA (2004) 11.Lions, J.M., Simoneau, D., Pilette, G., Moussa, I.: Extending OpenTool/UML Using Meta-modeling : An aspect-oriented programming case study, 2nd International Workshop on Aspect Oriented Modeling, UML 2002, Dresden, Germany (2002)12.Gray, J.: Aspect-Oriented Domain-Specific Modeling: A Generative Approach Using aMeta-weaver Framework, Ph.D. Dissertation, Department of Electrical Engineering and Computer Science, Vanderbilt University, Nashville (2002)atchenko, M., Kiczales, G.: Uniform Support for Modeling Crosscutting Structure, 6thInternational Workshop on Aspect-Oriented Modeling at the 4th International Conference on Aspect-Oriented Software Development, Chicago, USA (2004)14.Clarke, S., Baniassad, E.: Aspect-Oriented Analysis and Design. The Theme ApproachAddison-Wesley, Object Technology Series, ISBN: 0-321-24674-8 (2005)15.Reddy, R., France, R., Georg, G.: An Aspect-Oriented Modeling Approach to AnalyzingDependability Features, 6th Workshop on Aspect-Oriented Modeling at the 4th Interna-tional Conference on Aspect-Oriented Software Development, Chicago, USA (2002) 16.Telelogic: TAU G2 homepage, /products/tau/index.cfm (2005)。

中科院机器学习题库-new

机器学习题库一、极大似然1、 ML estimation of exponential model (10)A Gaussian distribution is often used to model data on the real line, but is sometimesinappropriate when the data are often close to zero but constrained to be nonnegative. In such cases one can fit an exponential distribution, whose probability density function is given by()1xb p x e b-=Given N observations x i drawn from such a distribution:(a) Write down the likelihood as a function of the scale parameter b.(b) Write down the derivative of the log likelihood.(c) Give a simple expression for the ML estimate for b.2、换成Poisson 分布：()|,0,1,2,...!x e p x y x θθθ-==()()()()()1111log |log log !log log !N Ni i i i N N i i i i l p x x x x N x θθθθθθ======--⎡⎤=--⎢⎥⎣⎦∑∑∑∑3、二、贝叶斯假设在考试的多项选择中，考生知道正确答案的概率为p ，猜测答案的概率为1-p ，并且假设考生知道正确答案答对题的概率为1，猜中正确答案的概率为1，其中m 为多选项的数目。

计算机专业英语考试试题及答案

计算机专业英语考试试题及答案一、选择题1. Which of the following is NOT a programming language?A. JavaB. PythonC. HTMLD. CSS2. What does the acronym "SQL" stand for?A. Structured Query LanguageB. Simple Query LanguageC. Script Query LanguageD. Secure Query Language3. Which protocol is commonly used for sending and receiving emails?A. FTPB. HTTPC. SMTPD. TCP4. What does the term "CPU" refer to?A. Central Processing UnitB. Computer Processing UnitC. Central Program UnitD. Computer Program Unit5. Which of the following is NOT a type of network topology?A. StarB. RingC. MeshD. Scroll二、填空题1. HTML stands for Hypertext Markup Language, which is used for ____________.2. The process of converting source code into machine code is called ____________.3. IP address stands for ____________.4. The act of copying files from a remote server to a local computer is known as ____________.5. The programming language developed by Apple Inc. for iOS and macOS is ____________.三、简答题1. What is the difference between a compiler and an interpreter? Provide examples of programming languages that use each of these methods.2. Explain the concept of object-oriented programming (OOP) and provide an example of a programming language that utilizes this paradigm.3. Describe the client-server model and provide an example of a commonly used protocol within this model.四、论述题Discuss the impact of artificial intelligence (AI) on various industries. Provide examples of how AI is being used in fields such as healthcare, finance, and transportation. Analyze the potential benefits and challenges of implementing AI in these industries.答案：一、选择题1. C. HTML2. A. Structured Query Language3. C. SMTP4. A. Central Processing Unit5. D. Scroll二、填空题1. creating and structuring the content of a webpage2. compilation3. Internet Protocol4. downloading5. Swift三、简答题1. A compiler translates the entire source code into machine code before the program is executed. Examples of languages that use compilers are C, C++, and Java. On the other hand, an interpreter translates and executes the source code line by line. Python and Ruby are examples of languages that use interpreters.2. Object-oriented programming (OOP) is a programming paradigm that organizes data and functions into reusable objects. It focuses on the concept of classes and objects, allowing for code reuse and encapsulation. An example of a programming language that uses OOP is Java, where objects are instances of classes and can interact with each other through methods and attributes.3. The client-server model is a distributed computing architecture wherea server provides services or resources to multiple clients. The clients request and receive these resources through the network. An example of a commonly used protocol within this model is the Hypertext Transfer Protocol (HTTP), which is used for communication between web browsers (clients) and web servers.四、论述题Artificial intelligence (AI) has had a significant impact on various industries. In healthcare, AI is being used for diagnoses and treatments, analyzing medical images, and personalized medicine. For example, AI-powered algorithms can help detect diseases like cancer at an early stage, leading to better treatment outcomes. In finance, AI is utilized for fraud detection, algorithmic trading, and customer service. AI algorithms can analyze large amounts of financial data to identify patterns and make accurate predictions. In transportation, AI is being employed for autonomous vehicles, traffic management, and logistics optimization. Self-driving cars, for instance, use AI algorithms to navigate and make decisions on the road.The implementation of AI in these industries brings about many benefits, such as increased efficiency, improved accuracy, and cost savings. AI systems can process and analyze vast amounts of data much faster than humans, leading to faster and more accurate results. However, there are also challenges to consider. Privacy and security concerns arise as AI systems handle sensitive information. There is also the worry of job displacement, as AI automation may replace certain human tasks. Additionally, ethical considerations need to be addressed, such as bias in algorithms and the potential for AI to be used for malicious purposes.Overall, the impact of AI on various industries is undeniable. It has the potential to revolutionize healthcare, finance, transportation, and many other sectors. However, careful implementation and regulation are necessary to ensure its responsible and beneficial use.。

模拟ai英文面试题目及答案

模拟ai英文面试题目及答案模拟AI英文面试题目及答案1. 题目: What is the difference between a neural network anda deep learning model?答案: A neural network is a set of algorithms modeled loosely after the human brain that are designed to recognize patterns. A deep learning model is a neural network with multiple layers, allowing it to learn more complex patterns and features from data.2. 题目: Explain the concept of 'overfitting' in machine learning.答案: Overfitting occurs when a machine learning model learns the training data too well, including its noise and outliers, resulting in poor generalization to new, unseen data.3. 题目: What is the role of a 'bias' in an AI model?答案: Bias in an AI model refers to the systematic errors introduced by the model during the learning process. It can be due to the choice of model, the training data, or the algorithm's assumptions, and it can lead to unfair or inaccurate predictions.4. 题目: Describe the importance of data preprocessing in AI.答案: Data preprocessing is crucial in AI as it involves cleaning, transforming, and reducing the data to a suitableformat for the model to learn effectively. Proper preprocessing can significantly improve the performance of AI models by ensuring that the input data is relevant, accurate, and free from noise.5. 题目: How does reinforcement learning differ from supervised learning?答案: Reinforcement learning is a type of machine learning where an agent learns to make decisions by performing actions in an environment to maximize a reward signal. It differs from supervised learning, where the model learns from labeled data to predict outcomes based on input features.6. 题目: What is the purpose of a 'convolutional neural network' (CNN)?答案: A convolutional neural network (CNN) is a type of deep learning model that is particularly effective for processing data with a grid-like topology, such as images. CNNs use convolutional layers to automatically and adaptively learn spatial hierarchies of features from input images.7. 题目: Explain the concept of 'feature extraction' in AI.答案: Feature extraction in AI is the process of identifying and extracting relevant pieces of information from the raw data. It is a crucial step in many machine learning algorithms, as it helps to reduce the dimensionality of the data and to focus on the most informative aspects that can be used to make predictions or classifications.8. 题目: What is the significance of 'gradient descent' in training AI models?答案: Gradient descent is an optimization algorithm used to minimize a function by iteratively moving in the direction of steepest descent as defined by the negative of the gradient. In the context of AI, it is used to minimize the loss function of a model, thus refining the model's parameters to improve its accuracy.9. 题目: How does 'transfer learning' work in AI?答案: Transfer learning is a technique where a pre-trained model is used as the starting point for learning a new task. It leverages the knowledge gained from one problem to improve performance on a different but related problem, reducing the need for large amounts of labeled data and computational resources.10. 题目: What is the role of 'regularization' in preventing overfitting?答案: Regularization is a technique used to prevent overfitting by adding a penalty term to the loss function, which discourages overly complex models. It helps to control the model's capacity, forcing it to generalize better to new data by not fitting too closely to the training data.。

Model Composition - A Signature-Based Approach

Model Composition-A Signature-Based ApproachRaghu Reddy,Robert France,SudiptoGhoshComputer Science DepartmentColorado State UniversityFort Collins,CO,USAraghu@ Franck Fleurey,Benoit BaudryIRISACampus Universitaire de Beaulieu35042Rennes Cedex,FranceABSTRACTThe aspect oriented modeling(AOM)approach provides mecha-nisms for separating crosscutting functionality from core function-ality in design models.Crosscutting functionality is described by aspect models and the core application functionality is described by a primary model.The integrated system view is obtained by com-posing the primary and aspect models.In this paper,we present a model composition technique that relies on signature matching: A model element is merged with another if their signatures match.A signature consists of some or all properties of an element as de-ﬁned in the UML metamodel.The technique proposed in this paper is capable of detecting some conﬂicts that can arise during compo-sition.KeywordsAspect oriented modeling,Composition,Conﬂicts,EMOF,Ker-Meta,Signature,UML1.INTRODUCTIONA major factor behind the complexity of developing dependable software is the need to incorporate multiple interdependent features in a design(e.g.,access control,availability,and error recovery).In this paper,a design feature is a logical unit of behavior,i.e.,it is a piece of functionality that realizes a design objective.A feature that has elements that are spread across a design description and inter-twined with elements from other features is called a crosscutting feature.The Aspect-oriented modeling(AOM)approach provides mechanisms for separation of crosscutting features from other fea-tures[7,16].In the AOM approach,core application features are described in a primary model and features that crosscut core application features are described by aspect models.Aspect and primary models are de-scribed using the Uniﬁed Modeling Language(UML)[19].Com-position of aspect models and a primary model yields an integrated design position is necessary to identify conﬂicts that may arise as a result of interactions between aspect and primary model elements.The composition procedure used in our previous AOM approach was -based composition can give rise to con-ﬂicts in the cases where the element name is not enough to identify matching concepts.For example,when two attributes from differ-ent models have the same name but different types,the name-based composition will attempt to merge position directives [17]were used to resolve some of these conﬂposition directives modify aspect and primary models,so that their compo-sition yields desired results.In this paper,we provide a signature-based composition technique that can be used to avoid some of the conﬂicts that can arise from using only name-based matching.A signature consists of some or all of the properties associated with an element in the UML meta-model.For example,the signature of an attribute can be deﬁned as consisting of its name and type.The developer can deﬁne signa-tures that determine matching model elements.The default signa-ture consists of only the model element name.In signature-based matching,elements of a type with matching signatures represent different views of the same concept and are thus merged in the composed model.This new approach does not remove the need for composition directives but it reduces the composition cases that require their use.In this paper we present a signature-based composition metamodel that describes static and behavioral properties of composable model elements,an algorithm for composing two models and,a KerMeta [20]implementation of the signature-based composition algorithm.The rest of the paper is organized as follows.Section2provides background information on AOM and KerMeta.Section3gives an overview of signature-based composition.Section4describes the composition metamodel.Section5outlines the algorithm for signature-based model composition and provides a simple illustra-tive example.Section6presents some related work and section7 presents the conclusions and future work.2.BACKGROUNDThis section provides an overview of the aspect oriented modeling (AOM)approach,extended metamodeling facilities(EMOF),and KerMeta.We implement the signature-based AOM approach using KerMeta which manipulates metamodels written in EMOF.2.1Aspect Oriented ModelingIn the AOM approach,aspect models are pattern descriptions of crosscutting features.The aspect models consist of structural and behavioral UML template diagrams[7].The template notation is a specialized form of a pattern speciﬁcation language called the Role-Based Metamodeling Language(RBML)[6].An aspect model must be instantiated before it can be composed with a primary model. The instantiated forms of aspect models are referred to as context-speciﬁc aspects.The instantiation of an aspect model is determined by bindings,where a binding associates a value of an application-speciﬁc concept with a template position directives [17]can be used to inﬂuence how context-speciﬁc aspects are com-posed with the primary posing context-speciﬁc aspects and a primary model produces an integrated view of the design.2.2Essential Meta-Object Facilitates Essential Meta-Object Facilities(EMOF)2.0is a minimal meta-modeling language designed to specify metamodels[13].It pro-vides the set of elements required to model object-oriented systems. The minimal set of EMOF constructs required for the composition algorithm is presented in Figure1.Figure1:EMOF classes required for compositionAll objects have a class which describes their properties and oper-ations.An Object extends an Element.The getMetaClass()oper-ation returns the Class that describes this object.The container() operation returns the containing parent object.It returns null if there is no parent object.The equals(element)determines if the element(an instance of Element class)is equal to this Element in-stance.The set(property,element)operation sets the value of the property to the element.The get(property)operation returns a List or a single value depending on the multiplicity.The isComposite attribute under class Property returns true if the object is contained by the parent object.Cyclic containment is not possible,i.e.an object can be contained by only one other object. The getAllProperties()operation(not shown in theﬁgure)of the Class returns all the properties of instances of this Class along with the inherited properties.The attributes,upper and lower,of class MultiplicityElement,represent the multiplicities of the associations at the metamodel level.For example,“0..1”represents a lower bound“0”and an upper bound“1”.If the upper bound is less than or equal to“1”then the property value is null or a single object; otherwise its a collection of objects.2.3KerMetaKerMeta[20]is an open source metamodeling language developed by the Triskell team at IRISA.It has been designed as an extension to the EMOF2.0.KerMeta extends EMOF with an action language that allows specifying semantics and behavior of metamodels.The action language is imperative and object-oriented.It is used to pro-vide an implementation of operations deﬁned in metamodels.A more detailed description of the language is presented in[11]. The KerMeta action language has been specially designed to pro-cess models.It includes both Object-Oriented(OO)features and model speciﬁc features.KerMeta includes traditional OO static typing,multiple inheritance and behavior redeﬁnition/selection with a late binding semantics.To make KerMeta suitable for model pro-cessing,more speciﬁc concepts such as opposite properties(i.e.as-sociations)and handling of object containment have been included. In addition to this,convenient constructions of the Object Con-straint Language(OCL),such as closures(e.g.each,collect,se-lect),are also available in KerMeta.To implement the composition algorithm we have chosen to use KerMeta for two reasons.First,the language allows implementing composition by adding the algorithm in the body of the operations deﬁned in the composition metamodel.Second,KerMeta tools are compatible with the Eclipse Modeling Framework(EMF)which allows us to use Eclipse tools to edit,store,and visualize models.3.SIGNATURE-BASED COMPOSITIONIn signature-based composition,information in model elements with matching signatures is merged to form a single model element in the composed model.The signature of a model element is a set of property values,where the properties are a subset of properties (e.g.,attributes and association ends)associated with the class of the model element in the UML metamodel.The set of properties used to determine a signature is called a signature type.For ex-ample,the signature type for an operation can be deﬁned as a set consisting of the operation name and its sequence of parameters.Signature Type:Operation:(name,Parameter{name,Type}) Using the signature type given,the signature for two update opera-tions with different sets of parameters is written as:Signature:(update,{(x,int)(y,int)})Signature:(update,{(s,String)})The properties that deﬁne that signature type can vary from being just the name of the element to all the constituent properties asso-ciated with the element.In the example given above,curly braces indicate that the property is associated with a set of values.Note that the two update operations will not match using the operation signature type given above.Consider the simple example shown in Figure2in which a model contains a class named Customer with attributes name and address (see Figure2(a)),and another model that contains a class named Customer with an attribute name and a reference to an Account ob-ject(see Figure2(b)).Assuming the signatures match at the model level,if the signature type at the class level is deﬁned as consist-ing of the properties name,attributes and association ends,then the two classes do not match and thus are not merged.Note that under the assumption that the signature accurately determines the classes that represent the same concept,this composition produces a faulty model(see Figure2(c)):Two classes in a namespace have the same name but represent different concepts.If the signature type of a class consists only of the class name property then the two classes match and their contents are merged to form a single class(see Figure2(d)).classes in Model 1 and Model 2 are mergedoperations. Result is a faulty model in which two different concepts arerepresented by classes with the same nameFigure 2:A simple merge exampleIf a model element property is not included in a signature then it is subject to its own matching rules during the merge.So,care should be taken to specify the signature types for all model elements that need to be composed.In general,the following rules determine how properties in matching model elements are merged:•If properties represented by model elements (e.g.,class at-tributes)have matching signatures then they appear only once in the containing merged element.•If a property in one matching element is not in the other,then it appears in the composed model ing the above rules and signatures for attribute and association ends that require exact matches (i.e.,each signature type contains all properties of the element type),merging of the two Customer classes in Figure 2(a)and (b)produces a model with two classes Customer and Account.The Customer class will have two at-tributes,name and address,an operation updateAcct(),and a ref-erence to the Account class (see Figure 2(d)).POSITION METAMODELThe composition metamodel describes how signature-based com-position can be accomplished.The metamodel shown in Figure 3describes the static and behavioral properties needed to support signature-based model composition in AOM.In this paper,we de-scribe the behavioral properties in terms of class operations and narrative descriptions of the operations.Alternatively,sequence and activity diagrams can be used to describe the interactions and activities that take place during composition.The core concepts of the composition metamodel can be used to compose any two models.In AOM,the composition starts with the primary model being the initial model.The aspect model is merged with the primary model.At any given time,only one aspect model is composed with the primary model and the order in which multiple aspect models are composed with the primary model can be speciﬁed using model composition directives.The core concepts shown in Figure 3are described below:•Element :Element is an extension of the UML metaclass,Element.It is extended by the operation getMatchingEle-ments(e[]:Element).Other operations container(),get(property),set(property,element),getMetaClass()of the EMOF Object class shown in Figure 1are used by the Element.•getMatchingElements :This operation takes in a set of ele-ments and returns an element or set of elements that have the same syntactic type and signature as the element that invokes it.The syntactic type check is performed by invoking the get-MetaClass()and the getAllPropeties()operation of EMOF Object class.The signature is obtained using getSignature().•Mergeable :This is an abstract class.Instances of Mergeable class are elements that are mergeable.Examples of merge-able elements shown in the ﬁgure are Classiﬁers,Operations,and Models .•merge :This operation merges the element with another merge-able element.•sigEquals :This operation checks if the element’s signature is equal to the signature of another element.•getSignature :This operation gets the signature of the ele-ment based on the signature type.•Signature :This class is used to obtain the signature of the mergeable elements.This class is linked to every mergeable element.The composition metamodel is primarily used for the development of a model composition tool.We have implemented the model composition technique using KerMeta.The composition metamodel classes were added to the UML metamodel and the operational fea-tures associated with it were implemented using POSITION ALGORITHMThe composition algorithm takes in two models and outputs the resultant model.In AOM,primary model and aspect model are the two models.The composition results in a composed model that in turn will become the primary model for adding other aspect models.The algorithm presented below describes how two models can be composed based on signatures.The algorithm assumes that the model elements are represented as objects (instances of EMOF::Object class).This is necessary be-cause the algorithm is written independent of the model element types.The algorithm uses reﬂection to obtain structures of objects.For example,in Figure 5a the metaclass of Customer is Class and metaclass of update is Operation.The algorithm implicitly uses the metamodel instance for all the elements speciﬁed and then merges the model elements based on the metamodel instances.The meta-model instance diagram for Figure 5a is shown in Figure 4.The models are merged only when the elements are of the same syntactic type and have the same signature.The sigEquals()op-eration is shown as a pre-condition to the merge method (see Fig-ure 6).Each type of model element deﬁnes its own procedure forFigure 3:Composition metamodelMetamodel Instance for Model 1 shown in fig 1aFigure 4:Metamodel Instance for the Figure 5achecking equality of signatures,that is,specializations of Merge-able can override the inherited sigEquals().The models are merged by invoking the merge method.The merge method (shown in the appendix)returns a new element that is the merge of mergeable element m and the element on which the merge is called.The merge method in the algorithm proceeds as follows for all properties of the objects to be merged:•If the property is of simple type,then the contained property values must be the same;otherwise a conﬂict is detected.The conﬂict needs to be handled explicitly by the developer.•If the property is composite,then the merge method is in-voked recursively on all property values that have the same signature.The recursive merge call depends on the upper bound of the property.–If the number of elements contained is equal to 1,the properties are merged depending on the signature.If the signatures do not match,then a conﬂict is detected.–If the number of elements contained is greater than 1,then each element of the collection of object properties will be checked for matching element properties.If the property values do not have the same signature they are added individually to the merged model element.5.1Illustrative exampleConsider the example shown in Figure 5in which there are two packages each containing a model.The ﬁrst package contains Model 1which has a class named Customer,with attributes name and custID ,operations addAmount ,update with a string parameter,and update with an integer parameter (see Figure 5(a)).The second package contains a model,Model 1,which has a class named Cus-tomer and a class named Account.The Customer class contains an attribute,name ,a reference to an Account object named Cus-tAcc ,and an operation named update with a string parameter.The Account class contains an attribute accID and a reference to a Cus-tomer object named ActAcc (see Figure 5(b)).If the model composition algorithm is applied on the packages,the algorithm will compose the packages based on the signature type.If the signature type has been deﬁned as model name,class name,and operation name with parameter name and type,the al-gorithm will produce the composed model shown in Figure 5(c).On the other hand if the signature type is deﬁned as the model name,class name,and operation name without the parameter name and type,the composition will produce the model shown in Figure 5(d).There will be an explicit warning before such a merge is per-formed because the parameters do not match.The tool performsFigure5:A simple example illustrating composition variants a default merge under such circumstances.If the signatures match and the parameters do not match,the default basically appends the all parameters to the operation in the composed model.This can be overriden when the developer handles the conﬂict explicitly by either choosing the primary model element or the aspect model el-ement.The example given above is fairly intuitive and the composition for the example can be done manually.In cases where there are a large number of classes and associations,this becomes extremely complex.The KerMeta implementation of the algorithm can re-solve the problem.The developer can input the signature type and the composition can be varied based on the signature type.Since the conﬂicts are detected during the composition itself,they can be handled as the developer desires.We have used the implementation to compose other models.We have applied the tool on a partial banking application and com-posed it with a context-speciﬁc Role Based Access Control aspect to obtain the composed model.6.RELATED WORKAspect oriented composition approaches can be categorized as asym-metric and symmetric approaches[9].In asymmetric approaches, aspects are different from the base model that captures the core functionality of the system.The aspects are composed into the base model dynamically.It does not support aspect-aspect,and class-class composition.In symmetric approaches,there is no distin-guishing factor between an aspect and a base model,since there is no base model[9].The composition approaches used in viewpoints [12],subject-oriented programming[8,14],and multi-dimensional separation of concerns(MDSOC)[18]are symmetric approaches. Most other approaches proposed in the aspect oriented community, such as AspectJ[10]are asymmetric.Some approaches like com-positionﬁlters[2,1]and theme[3]are a hybrid of symmetric and asymmetric approaches.Our aspect oriented modeling approach is also a hybrid approach.We have the notion of primary model that captures the core functionality but the composition itself is sym-metric because our approach composes models statically and any model element can act as a join point for composition.Subject-oriented programming[8,14]approach which later on led to MDSOC and is supported using HyperJ,composes program ele-ments such as classes and methods,and by composing correspond-ing elements.The correspondence is established based on the com-position rules speciﬁed.The default correspondence is name-based and this can be altered by writing additional composition rules.The composition rules used to control this process can be classiﬁed un-der three categories:rules that establish correspondence,rules that control combination,rules that control both correspondence and combination.The composition directives speciﬁed in our paper compliment the subject oriented program composition rules,at the design level.Our composition procedure depends on the properties speciﬁed in the signature rather than just names of model elements. This becomes important because some of the model elements may not have a name property associated with them.In the approach proposed by Clarke et al.,[4,5]a design,called a subject or theme,is created for each system requirement.A com-prehensive design is created by composing all po-sition includes adding and overriding named elements in a model. Conﬂict resolution mechanisms consist of deﬁning precedence and override relationships between conﬂicting elements.Our compo-sition procedure is more advanced in that we use signatures rather than names and also our the conﬂicts that occur during composition can be explicitly handled.As part of the early aspects initiative,Rashid et al.have targeted multi-dimensional separation throughout the software cycle[15]. Their work supports modularization of broadly scoped properties at the requirements level to establish early trade-offs,and provide decision support at later development stages.Our AOM approach complements their approach at the design level by providing mech-anisms for composition and detecting conﬂicts.7.CONCLUSIONS AND FUTURE WORK In this paper we presented a composition technique for composing aspect and primary class models that uses a signature-based mech-anism rather than name-based position of aspect models and a primary model may produce conﬂicts and undesirable emergent behavior,some of which can be detected by the compo-sition technique.We have described a composition metamodel that extends the UML metamodel for this purpose.We have developed a tool using KerMeta to support the signature-based composition technique.The inputs to the tool are an aspect model and a primary model.The output is a composed model that can be used as a primary model to compose with another aspect model.The composition procedure can detect conﬂicts but the res-olution of conﬂicts still needs to be handled explicitly by the position directives can be used to resolve conﬂicts.We are currently working on incorporating the changes required to the algorithm to include composition directives.The composition approach described in this paper currently han-dles only class models.We plan to adapt our approach and extend the metamodel(if necessary)to address other UML models(e.g. sequence diagrams and state charts).We are also in the process of categorizing the different type of conﬂicts that can occur when class models are composed.This systematic approach will help us in deﬁning the default composition rules and also in exploring the composition directives needed to alter the default composition.8.REFERENCES[1]M.Aksit and B.Tekinerdogan.Solving the modelingproblem of object-oriented languages by composing multiple aspect using compositionﬁlters.In AOP1998workshoppaper,1998.[2]M.Aksit,K.Wakita,J.Bosch,L.Bergmans,andA.Yonezawa.Abstracting Object Interactions UsingComposition Filters.In R.Guerraoui,O.Nierstrasz,andM.Riveill,editors,Proceedings of the ECOOP’93Workshop on Object-Based Distributed Programming,volume791,pages152–184.Springer-Verlag,1994.[3]E.Baniassad and S.Clarke.Theme:An approach foraspect-oriented analysis and design.In Proceedings of theInternational Conference on Software Engineering,pages158–167,2004.[4]S.Clarke and position patterns:Anapproach to designing reusable aspects.In The23rdInternational Conference on Software Engineering(ICSE),Toronto,Canada,2001.[5]S.Clarke and R.J.Walker.Towards a standard designlanguage for AOSD.In The1st International Conference on Aspect-Oriented Software Development,Enschede,TheNetherlands,April2002.[6]R.B.France,D.Kim,S.Ghosh,and E.Song.A UML-BasedPattern Speciﬁcation Technique.IEEE Trans.on SoftwareEng.,30(3):193–206,March2004.[7]R.B.France,I.Ray,G.Georg,and S.Ghosh.Anaspect-oriented approach to design modeling.IEEProceedings-Software,Special Issue on Early Aspects:Aspect-Oriented Requirements Engineering and Architecture Design,151(4):173–185,August2004.[8]W.Harrison and H.Ossher.Subject oriented programming(acritique of pure objects).In Proc.of the8th AnnualConference on Object-Oriented Programming:Systems,Languages,and Applications(OOPSLA’93),pages411–428,Washington,D.C.,September1993.[9]W.Harrison,H.Ossher,and P.Tarr.Asymmetrically vs.symeetrically organized paradigms for software composition.Technical report,IBM-RC22685(W0212-147),December302002.[10]G.Kiczales,mping,A.Mendhekar,C.Maeda,C.Lopes,J.Loingier,and J.Irwin.Aspect orientedprogramming.In Proc.of the European Conference onObject-Oriented Programming(ECOOP),Springer VerlagLNCS1241,pages220–242,Finland,June1997.[11]P.Muller,F.Fleuery,and J.J´e z´e quel.Weaving executabilityinto object-oriented meta-languages.In Proceedings ofMODELS/UML2005-to appear,Montego Bay,Jamaica,October2005.[12]B.Nuseibeh,J.Kramer,and A.Finkelstein.A framework forexpressing the relationships between multiple views inrequirements speciﬁcation.IEEE Transactions on SoftwareEngineering,20(10):760–773,1994.[13]OMG Adopted Speciﬁcation ptc/03-10-04.The Meta ObjectFacility(MOF)Core Speciﬁcation.Version2.0,OMG,.[14]H.Ossher,M.Kaplan,A.Katz,W.Harrison,and V.Kruskal.Specifying subject-oriented composition.Theory andPractice of Object Systems,Wiley and Sons,2(3),1996. [15]A.Rashid,P.Sawyer,A.Moreira,and J.Araujo.Earlyaspects:A model for aspect-oriented requirementsengineering.In IEEE Joint Intl.Conference on Requirements Engineering,pages199–202,Essen,Germany,September2002.[16]Y.R.Reddy,R.B.France,and G.Georg.An aspect-basedapproach to modeling and analyzing dependability features.Technical Report CS04-109,Colorado State University,November2004.[17]G.Straw,G.Georg,E.Song,S.Ghosh,R.B.France,andJ.Bieman.Model composition directives.In Seventh Intl.Conference on the UML Modeling Languages andApplications,Lisbon,Portugal,October.Springer. [18]P.Tarr,H.Ossher,W.Harrison,and S.Jr.N degrees ofseparation:Multi-dimensional separation of concerns.InProceedings of the21st International Conference onSoftware Engineering(ICSE’99),pages107–119,May1999.[19]The Object Management Group.UML2.0:SuperstructureSpeciﬁcation.Version2.0,OMG,ptc/04-10-02,2004. [20]TRISKELL.The KerMeta Project Home Page.URL.****************************************************************************************** //e1and e2are the model elements that need to be mergede1.merge(e2:ModelElement)//precondition:e1.sigEquals(e2)returns true****************************************************************************************** result:=e1.getMetaClass.new//create the merged instance in the context of e1//Iterate on all properties of the objects to be merged//e1and e2have the same metaclass.So they have me same set of properties.foreach Property p in e1.getMetaClass.getAllPropertiesif type of p is primitive//Primitive type is the basic datatype like string,int,etc,.//If an object does not have a value for a property then//the value val is taken from the other object and vice versa.This is not a conflict.//If neither object has values,then val is null in the merged object.if e1.get(p)is null or e2.get(p)is null thenresult.set(p,val)else//if the values are the same then it is ok otherwise a conflict has been detected.if e1.get(p)=e2.get(p)thenresult.set(p,e1.get(p))elseA conflict has been detectedelse//Type of p is not primitive.//If the property refers to a single objectif the property upper bound is1if e1.get(p)is null or e2.get(p)is null thenresult.set(p,val)//val is the same as aboveelseif sigEquals(e1.get(p),e2.get(p))then//If the object e1.get(p)is contained by e1and same for e2//(p.isComposite=true)then the objects should be merged,otherwise,//one is choosen.//Either one can be chosen because they both have the same signatureif p.isComposite is true thenresult.set(p,merge(e1.get(p),e2.get(p)))elseresult.set(p,e1.get(p).clone())elseA conflict has been detectedelse//The property refers to a collection of objects.//The merged object should contain property values that are only//in e1or only in e2,and the merged version of objects that are in both e1and e2.for each value v1in e1.get(p)for each matching element v2in e2.get(p)if p.isComposite thenresult.get(p).add(merge(v1,v2))elseresult.get(p).add(v1.clone())if no element foundresult.get(p).add(v1.clone())for each value v2in e2.get(p)if NO matching element found in e1.get(p)result.get(p).add(v2.clone())Figure6:Merge part of the Composition Algorithm。

一种基于模型和模板融合的自动代码生成方法

一种基于模型和模板融合的自动代码生成方法王博; 华庆一; 舒新峰【期刊名称】《《现代电子技术》》【年(卷),期】2019(042)022【总页数】6页(P69-74)【关键词】自动代码生成; 模板; 模型驱动; 模型转换; 混合自动代码; 生成设置【作者】王博; 华庆一; 舒新峰【作者单位】西安邮电大学计算机学院陕西西安 710121; 西安邮电大学陕西省网络数据智能处理重点实验室陕西西安 710121; 西北大学信息科学与技术学院陕西西安 710127【正文语种】中文【中图分类】TN911-34; TP301.60 引言随着信息产业的不断深入发展，应用软件需求和开发环境变得越来越复杂。

传统软件开发方法开发周期漫长且工作重复较大，为系统演进和维护造成较大困难[1]。

与此同时，新软件开发方法和思想以及工具，导致软件工程方法论发生深刻变化，尤其是以对象管理组织（Object Management Group，OMG）提出的模型驱动构架（Model Driven Architecture，MDA）为代表的方法论。

在DavidS.Frankel 的《应用MDA》一书中指出：“把宝贵的时间浪费在‘纸上谈兵’上是一种罪恶。

”[2]如果能够把设计直接转换成代码，亦即把设计和实现对应起来，那么无论对于代码质量和效率都会有较高提升。

自动代码生成，即根据用户任务需求建模而自动生成源代码的程序或软件。

本文所特指自动代码生成技术是在软件开发过程中由经验而形成的一种软件工程技术，通过自动生成工具或者程序半自动/全自动的生成应用系统所用到的原始框架和代码，一般生成文本形式的源代码[3]。

自动代码生成主要的优点和意义在于：减少重复的编码工作，生成代码风格一致良好，系统设计成为开发的主导，易于修改和升级，设计和实现具有连贯性。

本文提出一种采用模型驱动构架的设计思想，灵活配置的、融合模板和模型驱动的自动代码生成方案，称之为混合自动代码生成（Hybrid Automatic Code Generation，HACG）。

1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。

A Metamodel for Aspect-Oriented ModelingChristina Chavez Carlos LucenaMarch20,20021IntroductionAspect-oriented programming(AOP)is reaching maturity after almost a decade of research[9,1,7,8,10,2].The term AOP has been used in[6]to denote“the space of programmatic mechanisms for expressing crosscutting concerns”,in-cluding Kiczales et al.work as well as related work(adaptive programming, compositionﬁlters,subject-oriented programming and multi-dimensional sep-aration of concerns).We use the term aspect-oriented modeling to denote the space of modeling elements for specifying crosscutting concerns at a higher level of abstraction.Aspect-oriented modeling(AOM)should be built upon a concep-tual framework that we refer to as the aspect model[4].We adopt a terminology for AOP based on the core concepts presented in[8]as the main representa-tives for modeling elements:component(base element),aspect(crosscutting element),join point,crosscutting,and weaving.It is quite natural to investigate UML’s suitability as a modeling language for supporting Aspect-Oriented Modeling.First,UML[3]is acquainted to be the industry-standard modeling language for specifying,visualizing,constructing, and documenting the artifacts of software systems for the software engineering community.Second,UML is a general purpose modeling language to be usable in a wide range of application domains.As such,it includes a rich set of modeling techniques for analysis and design as well as structural and behavioral modeling, organized into several complementary views,expressed as diagrams,to model a system.Third,UML is an extensible modeling language to facilitate domain-speciﬁc modeling.As such,there is a set of built-in extension mechanisms to extend or customize the UML for a speciﬁc domain or process.AOP represents a paradigm shift in terms of programming rationale and, consequently,in terms of high-level modeling.This way,any extension required on a modeling language to support aspects and crosscutting corresponds to the deﬁnition of a new language,with additional syntax,semantics and pragmatics; therefore,we are talking about not subsets of UML-related families of languages, but rather,supersets.In this context,using built-in extension mechanisms pro-vided by the UML(such as stereotypes,tag values and constraints)to support AOM is rather a compromise solution to support the transition from pure OO models to OO models combined with aspect models(the paradigm shift),than1Figure1:Backbone.a conceptually sound solution.For us,the inviting challenge is the extension of the UML metamodel to cope with AOM.In the next section,we present aﬂavor of the extensions to the UML meta-model that we have been working on.2Structural ModelingFigure1shows the backbone we provide for structural modeling.2.1Base ElementsBaseElement describes modeling elements that may participate in a Crosscut-ting relationship with one or more elements of type CrosscuttingElement.2.2Crosscutting ElementsCrosscuttingElement describes modeling elements that may participate in a Crosscutting relationship with one or more elements of type BaseElement(Fig-ure2).2Figure2:CrosscuttingElement.Figure3:Crosscutting Relationship.2.3Crosscutting RelationshipCrosscutting is a relationship that denotes a new extension mechanism for com-bining incremental descriptions of structure and behavior localized in Crosscut-tingElement into a BaseElement.In the metamodel,the Crosscutting relationship is a directed relationship, from a CrosscuttingElement to one or more base elements,with a list of ac-tual parameters that indicate points in the base elements where the additional structure and behavior will be combined(Figure3).Some rules of well-formedness deﬁned are:1.The number of base elements must be equal to the number of crosscuttinginterfaces of the aspect.2.The number of arguments in each set of top-level arguments must be equal3Figure4:Aspect,CrosscuttingInterface,CrosscuttingFeature.to the number of formal parameters of each crosscutting interfaces.3.A Crosscutting has one extension and at least one base.2.4AspectsAspects are deﬁned as parameterized model elements.Aspects comprise a set of local features and a set of crosscutting interfaces.A crosscutting interface mod-els join points and crosscutting features deﬁned over these join points.Aspect is a kind of Classiﬁer that describes attributes and operations(CrosscuttingFea-ture)to be combined to other modeling elements(BaseElement),through some weaving mechanism,denoted by the Crosscutting relationship.An aspect has a set of interactions(Interaction),to describe interactions among instances and aspect instances.Figure4shows the metaclasses that describe aspects.2.5Crosscutting InterfacesA crosscutting interface models an archetypical representation of a set of cross-cut objects under the aspect’s perspective(Figure4).A crosscutting interface models interface-level,static join points and the crosscutting interface opera-tions model crosscutting operations over these join points.Each crosscutting interface describes the minimal set of properties required to the classes whose state and behavior are supposed to be extended by aspect’s structure and behavior.A crosscutting interface speciﬁes:4•a set of attributes and operations that the aspect introduces in the base classes.•a set of signatures of class methods expected to be used by the aspect •a set of aspect operations expected to reﬁne class methods.The pronoun base denotes the crosscut base object.A crosscutting interface isolates the part of an object that is relevant to an aspect from the rest of the object.Instances from diﬀerent classes can be extended by the same aspect,as long as they provide operations expected by one of the aspect’s crosscutting interfaces.2.6Cros s cutting FeatureA crosscutting feature is a model element that describes a feature to be com-bined to one or more base elements.Each crosscutting feature has attributes that deﬁne an ExtensionKind(add,reﬁne,override)and a CrosscuttingKind (before,after,around).Features that reﬁne or override base operations also have interaction patterns associated(reﬁne-before,reﬁne-after,reﬁne-around, override).Interaction patterns comprise behavioral modeling and are not pre-sented here.Aspect operations that reﬁne or override are speciﬁed as parameterized el-ements,i.e.,they contain one or more unbound parameters that represent op-eration name and signature.A base operation may be explicitly invoked inside the aspect operation’s body using the pronoun base.3Final RemarksThere are similarities between our work and the Composition Patterns approach [5].The composition patterns model evolved from the concepts found in subject-oriented programming[7]and composition is based on merge semantics;our as-pect model has evolved from the core concepts of AOP[8](we are very concerned about characterizing aspects asﬁrst-class entities and expressing the relation-ships among aspects and components,and also interacting aspects,under the base-aspect dichotomy perspective).Ongoing work includes extensions to the metamodel to express structural re-lationships among aspects(precedence,aspect interaction,etc.)and behavioral modeling(aspect instances,join points,interactions).References[1]M.Aksit,K.Wakita,J.Bosch,L.Bergmans,and A.Yonezawa.AbstractingObject Interactions Using Composition Filters.In R.Guerraoui,O.Nier-strasz,and M.Riveill,editors,ECOOP’93Workshop on Object-Based Dis-tributed Programming,pages152–184.Springer-Verlag,1994.5[2]Aspect-Oriented Software Development Web site./.[3]G.Booch,J.Rumbaugh,and I.Jacobson.The Uniﬁed Modeling LanguageUser Guide.Addison-Wesley,1999.[4]C.Chavez and C.Lucena.Design-level Support for Aspect-oriented Soft-ware Development.In International Workshop on Advanced Separation of Concerns at OOPSLA,2001.[5]S.Clarke.Designing Reusable Patterns of Cross-cutting Behavior withComposition Patterns.In OOPSLA’00,Workshop on Advanced Separation of Concerns,2000.[6]T.Elrad,R.E.Filman,and A.Bader.Aspect-Oriented Programming.Commun.ACM,44(10):29–32,2001.[7]W.Harrison and H.Ossher.Subject-Oriented Programming(A Critiqueof Pure Objects).In OOPSLA93,pages411–428,1993.[8]G.Kiczales,mping,A.Mendhekar,C.Maeda,C.Lopes,J.Loingtier,and J.Irwin.Aspect-Oriented Programming.In M.Aksit and S.Mat-suoka,editors,European Conference on Object-Oriented Programming,vol-ume1241of LNCS,pages220–242.Springer Verlag,1997.[9]K.J.Lieberherr.Adaptive Object-Oriented Software:The Demeter Methodwith Propagation Patterns.PWS Publishing Company,Boston,1996.ISBN 0-534-94602-X.[10]P.L.Tarr,H.Ossher,W.H.Harrison,and S.M.S.Jr.N Degrees of Sep-aration:Multi-Dimensional Separation of Concerns.In21st International Conference on Software Engineering,pages107–119,May1999.6。