Aspect-oriented requirements with UML

广东工业大学工学硕士学位论文面向方面的实时系统开发方法郭东亮二零零五年四月三十日分类号：学校代码：11911 UDC：密级：学号：2110205159广东工业大学学位论文面向方面的实时系统开发方法郭东亮指导教师：张立臣教授广东工业大学计算机学院学科门类：工学专业名称：计算机软件与理论申请学位级别：硕士论文提交日期： 2005 年 4 月论文答辩日期： 2005 年 5 月学位授予单位：广东工业大学摘要现代软件开发都要把整个系统按功能分解为小的单元，然后开发这些小单元，这些小的单元隐藏内部实现，对外提供接口，最后组合这些单元为整个系统，实现整个系统的功能。

但是系统中有的方面是横切整个系统的非功能关注点，无法很好地封装在单个模块中。

如日志、性能问题、安全、上下文相关错误处理、QoS 监测等等，这些方面分散在整个系统中，并且与系统的功能代码纠缠在一起，这样降低了模块的可追踪性、模块的可重用性、系统的可维护性等一系列问题，所以需要分离并模块化这些非功能关注点。

面向方面编程在实现上分离和模块化横切关注点，面向方面建模在软件开发的其它阶段用一致的方法来详述、可视化、构造和文档化方面相关制品，这样在整个软件开发过程可以使用面向方面技术。

实时系统是面向方面技术很好的应用场所，因为在实时系统中，有很多非功能需求，且这些非功能需求往往横切整个系统。

在实时系统中关键的就是时间要求了，这些时间要求散布在整个系统的功能部件里，带来了代码混乱和代码分散问题。

本文分析介绍了AspectJ、组合过滤器、多维关注点分离和自适应编程等典型的分离关注点的方法。

比较完整的介绍了面向方面建模领域的研究。

阐述了实时系统中的主要实时需求，以及与实时系统有关的UML框架集。

提出了一个新的扩展UML进行面向方面建模的方法，它以合适的语义表达了AspectJ和AspectC++的元素和织入机制。

在这个方法中，方面继承自类，切入点和通知继承自特征，这样切入点和通知是方面的一部分，方面与基本类的关系用横切依赖表示。

评阅教师得分“软件工程导论”课程半期考试题一、单项选择题（本大题共20小题，每小题2分，共40分)提示：在每小题列出的四个备选项中只有一个是符合题目要求的，请将其代码填写在下表中。

错选、多选或未选均无分。

1. Which design model elements are used to depict a model of informationrepresented from the user’s view？a. Architectural design elementsb. Component—level design elementsc. Data design elementsd. Interface design elementsAnswer：c (Section 8。

4.1)2. Which of the following are not areas of concern（考虑）in the design model?a. architectureb. datac. interfacesd. project scopeAnswer: d (Section 8.1)3. The importance of software design can be summarized in a single worda. accuracyb. complexityc. efficiencyd. qualityAnswer: d (Section 8。

1）4. Which of the following is not a characteristic common to all design methods？a. configuration managementb. functional component representationc. quality assessment guidelinesd. refinement heuristicsAnswer: a （Section 8.2.2）5. What types of abstraction are not used in software design？a. controlb. datac. environmentald. proceduralAnswer：c (Section 8。

A Toolkit for WeavingAspect Oriented UML DesignsWai-Ming Ho , Jean-Marc Jézéquel, François Pennaneac’h and Noël PlouzeauIrisa (INRIA & University of Rennes)Campus de Beaulieu+33 2 99 84 71 92Contact: jezequel@irisa.frABSTRACT*Separation of concerns is a basic engineering principle that is also at the core of object-oriented analysis and design methods in the context of the Unified Modeling Language (UML). The UML gives the designer a rich, but somehow disorganized, set of views on her model as well as many features, such as design pattern occurrences, stereotypes or tag values, allowing her to add non-functional information to a model. Aspect-oriented concepts are applied to manage the multitude of design constraints. However, it can then be an overwhelming task to reconcile the various aspects of a model into a working implementation. In this paper, we present our UMLAUT framework as a toolkit for easily building application specific “weavers” for generating detailed design models from high level, aspect oriented UML models. This is illustrated with a toy example of a distributed multimedia application with a weaving generating an implementation model. More ambitious applications are briefly outlined in the conclusion.1.INTRODUCTIONSeparation of concerns [12] is a basic engineering principle that can provide many benefits: additive, rather than invasive, change; improved comprehension and reduction of complexity; adaptability, customizability, and reuse. With its nine views that can be though of as projections of a whole multi-dimensional system onto separate plans, the Unified Modeling Language (UML) [22] provides the designer with an interesting separation of concerns that Kruchten calls the 4+1 view model (Design view, Component view, Process view, Deployment view, plus Use Case view) [15]. In turn , each of these views has two dimensions, one static and one dynamic. Furthermore the designer can add non-functional information (e.g. persistency requirements) to a model by “stamping” model elements, for instance with design pattern occurrences [8], stereotypes or tag values. It is appealing to think of many concerns as being independent or “orthogonal”, but this is rarely the case in practice. It is essential to be able to support interacting concerns, while still achieving useful separation. An Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. AOSD 2002, Enschede, The Netherlands. Copyright 2002 ACM 1-58113-469-X/02/0004...$5.00aspect-oriented approach to design can help to express these concerns explicitly and we propose our UMLAUT framework as a methodological support for building and manipulating UML models with aspects1, (Section 2). In Section 3, we describe the UML All pUrpose Transformer (UMLAUT) a framework which allows the engineer to program the “weaving” of the aspects at the level of the UML meta-model. In Section 4, we illustrate our aspect-oriented design (AOD) approach with a distributed multimedia application by giving parts of a weaver implementation. We then show how our approach fits into a reflexive viewpoint on the UML in Section 5, illustrating the way users may define transformations in UMLAUT. We discuss related work in Section 6 and conclude on the interest and perspectives of our approach.2.DESIGNING WITH ASPECTS AND UML The aim of this section is to extend the ideas expressed in aspect-oriented programming (AOP) [14] to the software modeling level. In [2], the authors explicit the gap that exists between requirements and design on the one hand, and between design and code on the other hand. AOP should then be extended to the modeling level where aspects could be explicitly specified during the design process. Indeed, we believe that with the support of an open transformation framework, it is possible to weave these aspects into a final implementation model.We use UML as our design language because it is an open standard [22], as well as general purpose object-oriented modeling language. UML supports the concept of multiple views that allow a software designer to express various requirements, design and implementation decisions using each view independently. The design is founded on the meta-model of UML, ensuring the coherence of the various views. The extension features of UML also allows it to be customized for a specific modeling environment.2.1Expressing Aspects with UMLThe various modeling dimensions of UML can already provide a good separation of concerns when modeling software. But in order to specify additional non-functional information or cross-cutting behavior (e.g. persistency), we need to resort to UML built-in 1 This work is partly funded by the European QCCS project, IST-1999-20122.extension mechanisms. Using these, the designer can add a great deal of non-functional information to a model by “hooking”annotations to model elements. Three annotation mechanisms are commonly used: stereotypes, tag values and design pattern occurrences.Stereotypes can often be used to subtype a given model element type, e.g. for a class to specify that its instances should be persistent (see class History in Figure 1). Automatic tools can then identify this element among the other model elements of the same type and process them specifically.Design pattern occurrence can be use to specify that a given design pattern shall be applied in a specific place in the model [19]. For instance, we may mark in Figure 1 each one of the operations of class ServiceProvider that should participate in the application of the Command design pattern [8]. In the same example, the class itself may be adorned with the design pattern occurrence. With this annotation, a weaver can be constructed to select out classes that participate in this design pattern occurrence, and use the information annotated on the operations to create the appropriate command classes, one for each ServiceProvider action i methods.Tag values are key-value pairs. Such pairs provide the weaver with additional information to guide the weaving process. Going back to our previous example, tag values could be put on ServiceProvider to specify a choice among existing implementations of the Command design pattern at weaving time. This extension and annotation mechanism gives us the flexibility of modeling all the necessary aspects into our AOD model. The final implementation decision consists in telling the weaver which group of aspects to compose, and how they should be composed according to this non-functional information.2.2Aspects at Various Levels of AbstractionAs outlined above, transformations rank into two categories: the ones related to the application domain and those involved in generating efficient implementations for the target platform.Let’s take another example to illustrate the difference: if the designer knows a collection of objects has to be notified when another object changes, then she annotates the corresponding classes as collaborating into an Observer pattern. A generic transformation supporting this pattern adds an update method to every class playing the role observer in this pattern occurrence. Specific transformations for implementing the pattern offer designers choices that fit implementation trade-offs: execution speed vs. memory footprint, and point-to-point notification vs. broadcasting depending on requirements on the underlying hardware. This last transformation is not at all related to the application, and must not distract the designer from its application refinement.The two categories are not exclusive : some transformations bridge the application domain and the implementation domain, thus falling into both categories. These transformations perform the ``weaving'' of the two aspects into a single implementation model.3.WEAVING UML DESIGNSUMLAUT is a framework dedicated to the manipulation of UML models. Since UML is itself described by a meta-model in UML, manipulating the meta-model is the same as manipulating any model. Hence we deal with the weaving of AOD designs by handling the model at the meta-model level. To this aim we are developing an open framework where the weaving process can be adapted and extended: new weavers can be constructed simply by changing the weaving rules. The framework takes care of the weaver implementation. In our UMLAUT toolbox, a weaving process is implemented as a model transformation process: each weaving step is a transformation step applied to a U ML model. Hence the final output is a U ML model too (endomorphic transformation). The model transformation engine is itself designed as a configurable and extendible framework.3.1General Architecture and Core Engine UMLAUT's architecture is a three-layered one. The input front end consists of a graphical user interface for interactive editing; another interface deals with importing UML models described in various formats (XMI, Rational Rose™ MDL, Eiffel source, Java source). The middle core engine is made up of the UML meta-model repository and the extendible transformation engine. Finally, the output back end contains various generators (including code generators and an XMI generator). The design concept of UMLAUT is a basic core (the middle layer) that communicates with its surroundings via hot spots (i.e. interfaces). Functional modules can be plugged in order to specialize the tool’s behavior and to meet specific requirements.3.2The Extendible Transformation FrameworkThe transformation engine of UMLAUT is responsible for the weaving process. In an earlier article [11], we have shown that automated transformations of UML models can be used by a designer to derive different refined views of a given software model. We would like to further develop the idea on how it can aid in performing design level aspect-oriented weaving. A weave operation is described as a transformation of an initial model to a final one. A designer specifies the required transformation byexplicitly composing a set of operators from the UMLAUT transformation library. Since the transformation engine is an open framework, users may add new operators and extend the existing library to support new weaving operations. The framework is designed to cater for three different kinds of user:Model designers are interested in performing a set of weaving operations. Their main concern is what transformation operators are available and useful to the model, and how they should be used.Transformation architects are responsible for defining how to implement a given transformation for a given implementation requirement. They extend the transformation library by adding new transformation operators.Framework implementers aim at enhancing the weaverframework to support specific needs of the previous two groups of users.The transformation framework uses a mix of object-oriented and functional programming paradigms. The object-oriented paradigm allows us to encapsulate our operators as discrete entities, and the functional paradigm provides us with a composition mechanism for these operators. The main architecture consists of three major components:1. A core structure that provides the logic for operatorcomposition and implicit control flow when atransformation is initiated.2. A library of iterators for traversing a UML model. Aniterator builds a path through a UML model graph sothat lazy list operations can be applied.3. A library of primitive operators for querying, modifyingand creating UML model elements.Each of these components can be augmented and enhanced. In particular, the operator library is likely to be extended by an transformation architect whereas the iterator library will more likely be extended by a framework implementer knowledgeable about the UML meta-model2.4. A DISTRIBUTED MULTIMEDIA APPLICATIONAs an illustration of how our framework weaves UML designs, we present in this section an application designed with aspects. Figure 2 shows a simple design of a distributed multimedia player. The PLAYER type defines an interface from which two implementations are derived: a proxy, PLAYER_PROXY, and a server implementation, PLAYER_IMPL. The PLAYER_SUBJECT type is the server side stub that relays the client requests to the implementation by means of a Command design pattern instance. This application is represented by a dotted ellipse with the word Command, and dotted lines indicate the role played by the objects involved in the pattern. As in Figure 1, operations in PLAYER participating in the Command design pattern are stereotyped with «Command ». Both PLAYER_PROXY and PLAYER_SUBJECT are stereotyped with « REMOTE » to indicate that the association 2 See details at http://www.irisa.fr/UMLAUT between the two classes are related by a physical distribution medium. For the dynamic aspect, we include in PLAYER_IMPL a statechart to represent its behavior when responding to play and stop requests (0). To reify this behavior model, we annotate our design with the State design pattern.Once we have attached weaving information to some of our model entities, we need to generate an implementation model, e.g.; the implementation model of Figure 4 where the classes enclosed in the dotted rectangle on the right implement the State design pattern.4.1Weaving the Implementation ModelIn order to generate the implementation model of Figure 4 from the design model of Figures 2 and 3, our weaver has to perform the two following steps, one for the Remote aspect, and one for the Command aspect.1.First, we produce a concrete implementation model inU ML using the « REMOTE » stereotype as a“guideline”. In our example, we shall simply move theclient association from the PLAYER interface to thePLAYER_PROXY. However, more transformationdetails are needed to produce a full implementation for« REMOTE ». These details include the choice of anunderlying architecture. For example, if CORBA ischosen as a middleware layer then its built-inimplementation of the Proxy pattern should be used.2.Second, we implement the Command pattern on top ofthe concrete implementation by attaching associationroles to the participants of the pattern. In our example,we choose to add the invoker and receiver roles to theparticipants, and add a hierarchy of command classes foreach of the operations marked with the «COMMAND »stereotype in Figure 2. It is important to note that thereis often more than one way to implement a designpattern, and a discussion of the possible choices isbeyond the scope of this example. In particular, our tooldoes not try to choose the best design patternimplementation but just to provide the designer with aframework that helps her to implement her choice.We now explicit these two transformation steps using a composition of map and filter expressions. The expressions are evaluated on the model in order to transform it by adding, removing model items such as associations, attributes, or classes. The map operator applies an operation on each element of an input sequence and returns the results’ sequence. It should be noted that the operation applied on each element may have side effects and alter the element (which is an object).The filter operator “lazily” returns a subsequence from an input sequence, retaining only the elements for which a boolean function yields true. This filter operation is purely functional (no side-effects).Operators are concatenated using the composition operator noted “o” below. The first step is to move the association of CLIENT/PLAYER to CLIENT/PLAYER_PROXY. We use the map and filter operators with the two following transformations in sequence:-- Find all model elements named Client and associated-- to a an interface playing a proxy role.(map removeAssociation) o (filter isClient) allElements-- Then move the user association down to the class-- implementing this interface(map associate) o (map getClntNProxy) o(filter isClient) allElementsThe allElements term denotes the sequence of all model elements. Such a sequence is generated by an iterator (traversal operation).The filter operation is then applied to the element sequences, retaining only those that are clients on a class with the « REMOTE » stereotype. Lastly, the map removeAssociation expression removes all associations between the client class and player proxy.The isClient and getClntNProxy operators are predicates developed specifically to pinpoint the AOD elements in our model. These application-specific operators may either be written from scratch or adapted from existing operators. On the other hand, operators like removeAssociation and associate are general library operators that can be reused for similar circumstances. It should be noted that the second expression (map associate…) is evaluated on the model obtained from the first expression evaluation (map removeAssociation…).The second step is to create the command classes from the Command pattern and to add the role associations for the participants. We use the following code:-- Make a new abstract class named CommandbaseClass = newClass ‘Command’-- Find all classes playing a receiver role in the-- Command design pattern instance, then for each of-- them build the list of operations that are stereotyped with-- Command then transform these operations into classes (map map opToClass) o (map allCmdOps)o (filter isReceiver) all Elements-- Find all classes that play an invoker role in the-- Command design patterninstance, then associate each of-- them with the Command class created above(map associate baseClass) o (filter isInvoker) allElements-- Do the same with the classes playing a receiver role(map associate baseClass) o (filter isReceiver) allElementsThe isReceiver, isInvoker and allCmdOps operations are specific to the weaving of all Command design pattern instances, and they must be implemented by the weaver designer. As shown in Section 5, these operations are easily described in UMLAUT thanks to the full access to the U ML metamodel.The sequence of transformations described in this section becomes our weaver for composing the distribution model and command pattern into our implementation model. In other words an application is defined using separate design aspects, our weaving process is also designed using separate transformation steps like the ones described above.4.2SummaryFrom this example, we show that it is possible to develop an application specific weaver by redefining the transformations to be applied to a design model. The base transformation framework of UMLAUT provides the user with a set of primitive, general purpose operators that can be extended and reused for different application specific needs. Each aspect-oriented design may be developed with an application specific weaver that optimizes the weaving process. As illustrated in our previous example, anapplication specific weaver need not be developed from scratch. For instance, the weaver for Command design pattern instances needs to be implemented only once. Moreover, since our transformations operations (map, filter, etc) are implemented with classes, a transformation designer can easily build upon existing weavers to build new ones, using inheritance, delegation or any other object-oriented programming technique.5.TOWARDS REFLECTION IN UMLIn the previous section, we introduced a formalism based on set processing to express transformations on a UML model in a functional style. In a tool providing support for such a powerful mechanism of reasoning on models, it would be overwhelming for users if they had to learn new tool-specific languages for the description of these transformations. We advocate that the UML has enough expressive power to fulfil all our needs. In particular, the Object Constraint Language (OCL) [27] which is a standardized part of the UML is the language of choice for expressing the selection criterion of a transformation, as it was specifically designed to provide powerful constructs (such as select, forAll and other iterate operators) dedicated to collection processing.Filter and map operations are easily realized with a iterate construct over a Collection, returning another Collection (or one of its derivatives: collect, select, etc).Reduce operations are realized with a iterate construct over a Collection, returning a basic OCL type i.e.Integer, Boolean, String). Such predefined OCL operations already exists (size, isEmpty,…).Writing transformations mostly consists in navigating through instances of U ML meta-elements. 05 shows an extracted view of the application of the Command pattern depicted in Figure 4, in terms of instances of meta-model elements (and this is the way it is stored in the UMLAUT tool).For example, retrieving applications of the Command pattern (which are Collaborations) in a Package may be realized with the following filtering operation declaration:context Package::commands()post: result = self.contents()->select(item:ModelElement |item.oclIsKindOf(Collaboration)) ->select(name=“Command”)Then finding Classifiers playing the role of a receiver in the Command pattern is done with the following receivers() operation, navigating through the UML metamodel, from Collaboration to ClassifierRole, then via ClassifierRole to Classifier:context Package::receivers()post : result = commands()->ownedElement ->select(name =“receiver”) ->baseAn OCL interpreter integrated in UMLAUT performs the evaluation of these operations on a model.However, most transformation operations on UML involves addition, modification or removal of model elements. These operations are not side-effect free and cannot be expressed with the OCL. To deal with this situation, we propose to describe actions with the help of the Action Semantics proposal which is currently being standardized at the OMG [22]. This proposal aims at formalizing the dynamic semantics of the UML, introducing in the UML metamodel classes such as CreateAction, DeleteAction, CreateLinkAction, DeleteLinkAction, or AssignmentAction, and strongly encourages the use of OCL.The AS has originally been designed for precisely specifying the behavior of models. We advocate the extension of its scope beyond this basic role, to enable reflexivity in UML for both its static and dynamic definition.An UML execution engine, i.e. an implementation of the AS model of execution is originally dedicated to the manipulation of instances of UML models (so called M0 level). Such manipulations are specified at the model level (so called M1 level), as part of the whole model of the application. But since both (1) the UML meta-model (M2 level) and (2) the UML execution model for the AS are themselves UML models, we can use the AS to specify the evolution of these models:?In the first case, thanks to the four-level architecture of the UML, an AS specification would manipulate instances of M2 level, i.e. UML models. Then, an AS specification describesa model transformation (meta-programming).?In the second case, an AS specification would manipulate instances of the execution model, i.e. the objects at runtime (a representation of M0 level called a snapshot). Then, the AS specification describes the transformation from one snapshot to the resulting one, that is the semantics of the AS itself (reflexivity applied to the execution engine specification).Using the UML meta-modeling architecture and the Action Semantics for specifying transformations is appealing: the development of meta-tools capitalizes on experience designers have gained when modeling UML applications.Some recurrent problems then disappear: portability of transformations is ensured for all UML-compliant tools with access to the meta-model, there is no learning-curve for the writing of new meta-tools, as it is pure UML and any development process supporting the UML applies to the building and reuse of transformations. This paves the way towards off-the-shelf transformation components.6. RELATED WORK6.1Aspect and Subject-Oriented ProgrammingAdaptive programming [21], aspect-oriented programming [14], and subject-oriented programming [10] have taken software development beyond the class concept of object-oriented programming. They address explicitly additional dimensions that constitute the inherent complexity of software. We believe that these works at the implementation level can be broaden to the entire software cycle and lead to aspect-oriented design (AOD). The use of UML in the context of AO modeling is already evident in [13], [2], [3], [26] and [3] has proposed to explicit multi-dimensional concerns for the entire software development cycle. Our work aims at providing an automated tool to support the expression of aspects at the design model level. The provision of an open framework has the added advantage that the user can redefine weaving strategy by re-composing the transformation operations. Using transformations during the weaving process is demonstrated by [19] and [7]. Relative to their source code oriented approach, UMLAUT addresses transformation with a design oriented, meta-modeling approach.In short, we use UMLAUT to apply aspect-oriented concepts for the entire software development cycle. We express weaving of software aspects in terms of model transformations. Its implementation as a framework makes it open for extension and customization.6.2UML Model TransformationUsing a functional programming paradigm in an object-oriented context has been proven to be a versatile technique (see [4], [18], [16]), especially when flexible composition and list-like processing are involved. The UMLAUT transformation framework has taken this idea to provide an extensible AOD environment. The main interest of this extensibility is the possibility of defining the weaving strategy by recomposition of primitive transformation operators. The transformation of software models is widely applied in tool automation for design patterns , software refactoring [23][24], equivalence transformations [9], [1], [25], and formal reasoning [17]. UMLAUT's transformation incorporates ideas from these works, and extends them to automate the definition of weaving operations in the context of AOD. In addition, UMLAUT exposes the concept of explicit model transformation to a software designer so that she can benefit from the versatility of this open approach.7.CONCLUSIONWe believe that aspect-oriented programming should be extended to the entire software development cycle. Each aspect of design and implementation should be declared during the design phase so that there is clear traceability from requirements through source code. We propose to use UML as the design language and with the help of an open framework as our weaver, to provide an aspect-oriented design environment. We have applied this approach to the development of two real applications:? A part of the Information System of a large Telecom Company, with the handling of aspects such as concurrency and persistency (taking into account various persistency frameworks that have been previously developed to interface commercial DBMS).?The UMLAUT tool itself, that has been bootstrapped from the “official” UML 1.3 specification. Because the UML meta-model is expressed as a UML model, we could add many features such as model management (consistent creation/deletion of model elements), user interface connection or XMI generation as so many aspects that have been woven together by UMLAUT to build itself in a classical bootstrapping scheme.8.REFERENCES[1]Michael Blaha and William Premerlani. A catalog of objectmodel transformation. In 3rd Working Conference onReverse Engineering, november 1996[2]Siobhán Clarke, William Harrison, Harold Ossher, and PeriTarr. Separating concerns throughout the developmentlifecycle. In ECOOP '99 Workshop Proceedings on Aspect-Oriented Programming Proceedings, 1999.[3]Siobhán Clarke and John Murphy. Developing a tool tosupport the application of aspect-oriented programmingprinciples to the design phase. In ICSE '98 WorkshopProceedings on Aspect-Oriented Programming Proceedings,1998.[4]Laurent Dami. Software Composition: Towards anIntegration of Functional and Object-Oriented Approaches.Ph.D. thesis, University of Geneva, 1994.[5]Philippe Desfray. Automation of design pattern: Concepts,tools and practices. In Jean Bézivin and Pierre-Alain Muller, editors, The Unified Modeling Language, UML'98. FirstInternational Workshop, Mulhouse, France, June 1998,volume 1618 of LNCS, pages 107–114. Springer, 1998. [6]Andy Evans. Reasoning with the Unified ModelingLanguage. In Proc. Workshop on Industrial-Strength Formal Specification Techniques (WIFT'98)}, 1998.[7]Pascal Fradet and Mario Südholt. Aop: towards a genericframework using program transformation and analysis. InECOOP'98 Workshop Proceedings on Aspect-OrientedProgramming Proceedings, 1998.。

Developing Safety-Critical Systems with UMLJan J¨u rjens⋆Software&Systems Engineering,TU Munich,GermanyAbstract.Safety-critical systems have to be developed carefully to pre-vent loss of life and resources due to system failures.Some of their mech-anisms(for example,providing fault-tolerance)can be complicated todesign and use correctly in the system context and are thus error-prone.We show how one can use UML for model-based development of safety-critical systems with the aim to increase the quality of the developedsystems without an unacceptable increase in cost and time-to-market.Specifically,we describe how to use the UML extension mechanisms toinclude safety-requirements in a UML model which is then analyzed forsatisfaction of the requirements.The approach can thus be used to en-capsulate safety engineering knowledge.It is supported by a prototypicalXMI-based tool performing the analysis.1IntroductionThere is an increasing desire to exploit theflexibility of software-based systems in the context of critical systems where predictability is essential. Examples include the use of embedded systems in various application do-mains,such asfly-by-wire in Avionics,drive-by-wire in Automotive and so on.Given the high safety requirements in such systems(such as a maximum of10−9failures per hour in the avionics sector),a thorough design method is necessary.In particular,the use of redundancy mecha-nisms to compensate the faults that occur in any operational system may require complex protocols whose correctness can be non-obvious[Rus94]. Therefore,safety mechanisms cannot be“blindly”inserted into a criti-cal system,but the overall system development must take safety aspects into account.Furthermore,sometimes safety mechanisms cannot be used off-the-shelf,but have to be designed specifically to satisfy given require-ments.This can be non-trivial,as spectacular examples for software fail-ures in practice demonstrate(such as the explosive failure of the Ariane 5rocket in1997).Any support to aid safe systems development would thus be useful. In particular,it would be desirable to consider safety aspects already in ⋆http://www.jurjens.de/jan–juerjens@in.tum.dethe design phase,before a system is actually implemented,since remov-ingflaws in the design phase saves cost and time.This is significant;for example,in avionics,verification costs represent50%of the overall costs [Ran00].There has been a significant amount of successful research into using formal methods for the development of safety-critical systems.Un-fortunately,part of the difficulty of critical systems development is that correctness is often in conflict to cost.It would thus be beneficial to use rigorous means in the context of an industrially efficient development method.The Unified Modeling Language(UML)[UML01]offers an unprece-dented opportunity for high-quality critical systems development that is feasible in an industrial context.–As the de facto standard in industrial modeling,a large number of developers is trained in UML,making less training necessary.Also, UML specifications may already be available for safety analysis,which again would save time and cost.–Compared to previous notations with a user community of comparable size,UML is relatively precisely defined,opening up the possibility for advanced tool-support to assist the development of safety-critical systems.Problems in critical systems development often arise when the con-ceptual independence of software from the underlying physical layer turns out to be an unfaithful abstraction(for example in settings such as real-time or more generally safety-critical systems,see[Sel02]).Since UML allows the modeller to describe different views on a system,including the physical layer,it seems promising to try to use UML to address these problems by modeling the interdependencies between the system and its physical environment.While there has been a significant amount of work addressing real-time systems with UML(including for example[SR98]),and increasing attention to using UML for security(see for example[J¨u r03c]),in the present work we consider safety and fault-tolerance requirements.To sup-port safe systems development,safety checklists have been proposed in [HJL96,Lut96,Hel98].Here,we tailor UML to this application domain by precisely defining some such checks with stereotypes capturing safety requirements and related physical properties.This way we encapsulate knowledge on prudent safety engineering and thereby make it available to developers who may not be specialized in safety.One can also check whether the constraints associated with the stereotypes are fulfilled ina given specification.A prototypical tool supporting this will shortly be introduced at the end of this paper.Safety In safety-critical systems,an important concept also used here is that of a safety level(see e.g.[Ran00]).Safety goals for safety-critical systems are often expressed quantitatively via the maximum allowed fail-ure rate.We exemplarily consider the following kinds of failure semantics in this paper(other kinds have to be omitted for space reasons).–crash/performance failure semantics means that a component may crash or may deliver the requested data only after the specified time limit,but it is assumed to be partially correct.–value failure semantics means that a component may deliver incorrect values.Possible failures include:message loss which may be due to hardware failures or software failures (for example,buffer overflows)message delay which may in turn result into the reordering of messages if the delay is variablemessage corruption when a message is modified in transit.Forms of redundancy commonly employed include space redundancy (physical copies of a resource),time redundancy(rerunning functions) and information redundancy(error-detecting codes).UML extension mechanisms We use the three main“lightweight”extension mechanisms(stereotypes,tagged values and constraints)to in-clude safety-requirements in a UML specification,together with the con-straints formalizing the requirements.To evaluate a model against the requirements,we refer to a precise semantics for the used fragment of UML extended with a notion of failures sketched in Sect.2.Related work Some of the ideas reported here were or will be presented in the unpublished[J¨u r02,J¨u r03b,J¨u r03a].[J¨u r03c]proposes to use UML for developing security-critical systems.In the related area of real-time systems there has been a substantial amount of work regarding the usage of UML.For example,[SR98]describes constructs to facilitate the design of software architectures in this domain which are specified using UML. [JCF+02]contains several approaches to developing systems with vari-ous criticality requirements using UML.In particular,[HG02]discussesa pattern-based approach for using UML use cases for safety-critical sys-tems.The focus is on the development of a testing strategy rather than model analysis.[PMP01]discusses methods and tools for the checking of UML statechart specifications of embedded controllers.The focus is on the use of statecharts and on efficient methods for automated checking and does not include the use of other UML diagrams or the inclusion of safety requirements using stereotypes.Also relevant is the work towards a formal semantics of UML(see the proceedings of related conferences, including the UML and FASE conferences,GROOM UML workshop’98, OOPSLA’98,PSMT’98,ECOOP’00workshop reader,AMCIS’00,and other conferences).Furthermore,there are techniques for requirements elicitation that can be used fruitfully with the current approach.An ex-ample is the approach of goal-oriented requirements engineering[vL01] which is specifically useful for non-functional requirements and which is related to UML in[SC02].Outline In Sect.2we explain the foundation for checking the constraints associated with the stereotypes suggested for safety-critical systems de-velopment which are presented in Sect.3,together with examples of their use.In Sect.3.1,we shortly describe the tool assisting our approach.2Safety Evaluation of UML DiagramsWe briefly give an idea how the constraints used in the UMLsec profile can be checked in a precise and well-defined way.A precise semantics for a(restricted and simplified)fragment of UML supporting these ideas can be found in[J¨u r03c],building on the statecharts semantics in[BCR00].It includes activity diagrams,statecharts,sequence diagrams,static struc-ture diagrams,deployment diagrams,and subsystems,each restricted and simplified to keep a mechanical analysis that is necessary for some of the more subtle behavioral safety requirements feasible.The subsystems in-tegrate the information between the different kinds of diagrams and be-tween different parts of the system specification.For safety analysis,the safety-relevant information from the safety-oriented stereotypes is then incorporated as explained below.Outline of precise semantics In UML the objects or components com-municate through messages received in their input queues and released to their output queues.Thus for each component C of a given system,the semantics defines a function C ()which–takes a multi-set I of input messages and a component state S and –outputs a set C (I,S)of pairs(O,T)where O is a multi-set of output messages and T the new component state(it is a set of pairs because of the non-determinism that may arise)together with an initial state S0of the component.The behavioral se-mantics D ()of a statechart diagram D models the run-to-completion semantics of UML statecharts.As a special case,this gives us the se-mantics for activity diagrams.Given a sequence diagram S,we define the behavior S.C ()of each contained component C.Subsystems group together diagrams describing different parts of a system:a system compo-nent C given by a subsystem S may contain subcomponents C1,...,C n. The behavioral interpretation S ()of S is defined by iterating the fol-lowing steps:(1)It takes a multi-set of input events.(2)The events are distributed from the input multi-set and the linkqueues connecting the subcomponents and given as arguments to the functions defining the behavior of the intended recipients in S. (3)The output messages from these functions are distributed to the linkqueues of the links connecting the sender of a message to the receiver, or given as the output from S ()when the receiver is not part of S. When performing safety analysis,after the last step,the failure model may corrupt the contents of the link queues in a certain way explained below.Safety analysis For a safety analysis of a given UMLsec subsystem specification S,we need to model potential failure behavior.We model specific types of failures that can corrupt different parts of the system in a specified way,depending on the used redundancy model.For this we assume a function Failures R(s)which takes a redundancy model R and a stereotype s∈{ crash/performance , value }and returns a set of expressions Failures R(s)⊆{delay(t):t∈N∧t>0}∪{loss(p):p∈[0,1]}∪{corruption(q):q∈[0,1]}.Here R is a name representing a re-dundancy mechanism(such as duplication of components together with a voting mechanism),which is semantically defined through the Failures() sets.The natural number t represents the maximum delay to be expected in time units.p gives the probability that an expected data value is not delivered after the t time units specified in delay(t).Given a value deliv-ered within this time period,q denotes the probability that this value is corrupted.Then we model the actual behavior of a failure,given a redundancy model R,as a failure function that,at each iteration of the system ex-ecution,non-deterministically maps the contents of the link queues in S and a state S to the new contents of the link queues in S and a new state T as explained below.For this,for any link l,we use a sequence(lq l n)n∈N of multi-sets such that at each iteration of the system,for any n,lq l n con-tains the messages that will be delayed for further n time units.Here lq l0 stands for the actual contents of the link queue l.At the beginning of the system execution,all these multi-sets are assumed to be empty.Also,for any execution trace h(that is,a particular sequence of system states and occurring failures describing a possible history of the system execution), we define a sequence(p h n)n∈N of probabilities such that at the n th itera-tion of the system,the failure considered in the current execution trace happened with probability p h n.Thus the probability p h that a trace h of length n will take place is the product of the values p h1,...,p h n(since in our presentation here,we assume failures to be mutually independent,to keep the exposition accessible).Then for an execution trace h,the failure function is defined as follows.It is non-deterministic in the sense that for each input,it may have a set of possible outputs.–For any link l stereotyped s where loss(p)∈Failures R(s)we •either define lq l0:=∅and append p to the sequence(p h n)n∈N,•or append1−p to the sequence(p h n)n∈N.–For any link l stereotyped s where corruption(q)∈Failures R(s)we •either define lq l0:={2}and append q to the sequence(p h n)n∈N,•or append1−q to the sequence(p h n)n∈N.–For any link l stereotyped s where delay(t)∈Failures R(s)and lq l0=∅, we define lq l n:=lq l0for some n≤t and append1/t to the sequence (p h n)n∈N.–Then for each n,we(simultaneously)define lq l n:=lq l n+1.The failure types define which kind of failure may happen to a com-munication link with a given stereotype,as explained above.Note that for simplicity we assume that delay times are uniformly distributed.Also,cor-rupted messages(symbolized by2)are assumed to be recognized(using error-detecting codes).To evaluate the safety of the system with respect to the given type of failure,we define the execution of the subsystem S in presence of a redundancy model R to be the function S R()defined from S ()by applying the failure function to the link queues as a fourth step in the definition of S ()as follows:(4)The failure function is applied to the link queues as detailed above.Table1.StereotypesStereotype Base Class Tags Constraints Descriptionrisk link,node failure riskscrash/link,node crash/performance performance failure semantics value link,node valuefailure semantics guarantee link,node goal guarantees redundancy dependency,model redundancy model componentsafe links subsystem dependency safety enforces safematched by links communication links safe subsystem call , send respect structural dependency data safety data safetycritical object(level)critical objectsafe behavior subsystem behavior fulfills safety safe behavior containment subsystem provides containment containmenterror handling subsystem error object handles errors Containment A system ensures containment if there is no unsafe inter-ference between components on different safety levels(this is called non-interference in[DS99]).Intuitively,providing containment means that an output should in no way depend on inputs of a lower level.For this we as-sume an ordering on the set Levels of safety levels.Then the containment constraint is that in the system,the value of any data element of level l may only be influenced by data of the same or a higher safety level:Write H(l)for the set of messages of level l or higher.Given a sequence m of messages,we write m⇂H(l)for the sequence of messages derived from those in m by deleting all events the message names of which are not in H(l). For a set M of sequences of messages,we define M⇂H def={m⇂H:m∈M}.Definition1.Given a component C and a safety level l,we say that C provides containment with respect to l if for any two sequences i,j of input messages,i⇂H(l)=j⇂H(l)implies C i⇂H(l)= C j⇂H(l).3Stereotypes for Safety Analysis:The“Safety Checklist”In Table1we give the stereotypes,together with their tags and con-straints,that we suggest to be used in the model-based development of safety-critical systems with UML,based on experience in the model-based development of safety-critical systems at our group(for example,from an avionics project[BHL+02])and on work on safety checklists in the lit-erature[HJL96,Lut96,Hel98].Thus,in a way,we define a UML-basedTable2.TagsTag Stereotype Type Multipl.Descriptionfailure risk P({delay(t),loss(p),*specifies riskscorruption(q)})goal guarantee P({immediate(t),*specifies guaranteeseventual,correct})model redundancy{none,majority,fastest}*redundancy model error object error handling string1error object “Safety Checklist”(which one can verify mechanically on the design level). The constraints,which in the table are only named briefly,are formu-lated and explained in the remainder of the section.Table2gives the corresponding tags.The relations between the elements of the tables are explained below in detail.Note that some of the concepts introduced below are easier to apply at component rather than object level.Instead of class models,one could also use capsules from[SR98](but we restrict ourselves to using standard UML1.5to remain as general as possible).We explain the stereotypes and tags given in Tables1and2and give examples(which for space restrictions have to be kept simple).Note that the constraints considered here span a range in sophistication:Some of the constraints are relatively simple(comparable to type-checking in programming languages)and can be enforced at the level of abstract syntax(such as safe links )and can be used without the semantics sketched in Sect.2.Others(such as containment )refer to the semantics and can only be checked reliably using tool-support.Overview We give an overview of the syntactic extensions together with an informal explanation of their meaning. redundancy ,with associ-ated tag{model},describes the redundancy model that should be im-plemented. risk describes the risks arising at the physical level using the associated tag{failure}. guarantee requires the goals described in the associated tag{goal}for communicated data. safe links ensures that safety requirements on the communication are met by the physical layer. critical labels critical objects using the associated tags{level} (for each safety level level). safe dependency ensures that communica-tion dependencies respect safety requirements on the communicated data. safe behavior ensures that the system behaves safely as required by guarantee ,in the presence of the specified failure model. containment ensures containment as defined in Definition1. error handling with tag {error object}provides an object for handling errors.Table3.Failure semanticsRisk Failures none()Crash/performance{delay(t),loss(p)}Value{corruption(q)}We define the stereotypes and their constraints in detail.Redundancy The stereotype redundancy of dependencies and compo-nents and its associated tag{model}can be used to describe the redun-dancy model that should be implemented for the communication along the dependency or the values computed by the component.Here we con-sider the redundancy models none,majority,fastest meaning that there is no redundancy,there is replication with majority vote,or replication where the fastest result is taken(but of course there are others,which can easily be incorporated in our approach).Risk,crash/performance,value With the stereotype risk on links and nodes in deployment diagrams one can describe the risks arising at these links or nodes,using the associated tag{failure},which may have any subset of{delay(t),loss(p),corruption(q)}as its value.In the case of nodes,these concern the respective communication links connected with the node.Alternatively,one may use the stereotypes crash/performance or value ,which describe specific failure semantics(by giving the rel-evant subset of{delay(t),loss(p),corruption(q)}):For each redundancy model R,we have a function Failures R(s)from a given stereotype s∈{ crash/performance , value }to a set of strings Failures R(s)⊆{delay(t),loss(p),corruption(q)}.If there are several such stereotypes relevant to a given link(possibly arising from a node connected to it),the union of the relevant failure sets is considered.This way we can evaluate UML specifications.We make use of this for the constraints of the remaining stereotypes.As an example for a failures function,Table3gives the one for the absence of any redundancy mechanism(R=none).Guarantee call or send dependencies in object or component di-agrams stereotyped guarantee are supposed to provide the goals de-scribed in the associated tag{goal}for the data that is sent along them as arguments or return values of operations or signals.The goals may be any subset of{immediate(t),eventual(p),correct(q)}.This stereotype is used in the constraints for the stereotypes safe links and safe behavior .client/server client machine server machine performance»«crash/client apps«call»{immediate(T)}}{goal=«guarantee»server apps«safe links»Fig.1.Example safe links usageSafe links The stereotype safe links ,which may label subsystems,is used to ensure that safety requirements on the communication are met by the physical layer.More precisely,the constraint enforces that for each dependency d with redundancy model R stereotyped guarantee between subsystems or objects on different nodes n,m ,we have a communication link l between n and m with stereotype s such that–if {goal }has immediate (t )as one of its values then delay (t ′)∈Failures R (s )entails t ′≤t ,–if {goal }includes eventual (p )as one of its values then loss (p ′)∈Failures R (s )entails p ′≤1−p ,and–if {goal }has correct (q )as one of its values then corruption (q ′)∈Failures R (s )entails q ′≤1−q .Example In Fig.1,given the redundancy model R =none ,the con-straint for the stereotype safe links is fulfilled if and only if T ≤t ,where t is the expected delay according to the Failures none (crash/performance )scenario in Fig.3.Critical We assume that we are given an ordered set Levels of safety levels .Then the stereotype critical labels classes whose instances are critical in some way,as specified by the associated tags {level }(for each level level ∈Levels ),the values of which are data values or attributes of the current object with the required to be protected by the given safety level.This protection is enforced by the constraints of the stereotypes safe dependency and containment which label subsystems that con-tain critical objects.Safe dependency The stereotype safe dependency ,used to label sub-systems containing object diagrams or static structure diagrams,ensures that the call and send dependencies between objects or subsystems respect the safety requirements on the data that may be communicatedswitch(): BoolController {realtime={measure()}}«critical»switch(): BoolSensor/controllermeasure(): Value «call»«safe dependency»Sensor Fig.2.Example safe dependency usagealong them.Exactly,we assume that each l ∈Levels has an associated set of goals goals (l )⊆{immediate (t ),eventual (p ),correct (q )}.Then the constraint enforced by this stereotype is that if there is a call or send dependency from an object (or subsystem)C to an object (or subsystem)D then the following conditions are fulfilled.–For any message name n offered by D ,the goals associated with the safety level of n in D imply those in C .–If a message name offered by D has safety level l in C and g ∈goals (l ),then g is implied by the goals provided by the dependency.Example Figure 2shows a sensor/controller subsystem stereotyped with the requirement safe dependency .We assume that immediate ∈goals (realtime ).The given specification violates the constraint for this stereotype,since Sensor and the call dependency do not provide the realtime goal immediate for measure()required by Controller.Safe behavior The stereotype safe behavior ensures that the specified system behavior in the presence of the failure model under consideration does provide the safety goals stated in the tag {goal }associated with the stereotype guarantee as follows,by referring to the semantics sketched in Sect.2.immediate(t)In any trace h of the system,the value is delivered afterat most t time steps in transmission from the sender to the receiver along the link l .Technically,the constraint is that after at most tsteps the value is assigned to lq l 0.eventual(p)In any trace h of the system,the probability that deliveredvalue is lost during transmission is at most 1−p .Technically,the sum of all p h for such histories h is at most 1−p .correct(q)In any trace h of the system,the probability that deliveredvalue is corrupted during transmission is at most 1−q .Technically,the sum of all p h for such histories h is at most 1−q .Fig.3.Example containment usageContainment The stereotype containment of subsystems ensures that it satisfies the containment constraint defined in Definition1.For this,we order the set Levels:For l,l′∈Levels we have l≤l′if goals(l)⊆goals(l′).A subsystem S correctly carries the stereotype containment if S satisfies containment with respect to every safety level l∈Levels.Example Figure3shows a Fuel Controller that computes the amount of used fuel of an airplane from the distance travelled so far.This is done(quite simplistically for the purpose of the example)by multiplying the distance with a constant(the amount of fuel consumed per length unit).Because of different air resistance,this constant depends on the fact whether the wheels of the plane were pulled in-board or(mistak-enly)left outside.This is modelled by having two states corresponding to the state of the wheels,and having different constants c=d.Now the result of the message fuel is supposed to be of the level safe.However, the message wheelsin giving the state of the wheels is not assigned any safety level.Therefore this example violates containment ,because a safe value depends on a value not at least of level safe.This can be checked as follows:Considering the sequences i=(wheelsin(true),fuel(1))and j=(wheelsin(false),fuel(1)),and the safety level l=safe,we have i⇂H(l)=j⇂H(l),but p i⇂H(l)={return(c)}={return(d)}= p j⇂H(l) since c=d by assumption on c,d.Error handling In UML,an event that does not trigger a transition is ignored.For safety-critical systems the arrival of an unexpected message or of a message with an out-of-range value may indicate a serious fail-ure.Similar to[SP00],we suggest to use a stereotype error handling of subsystems with a tag{error object}pointing to a statechart defining the behavior of an error component.This could be compiled directly from the UML model to an aspect-oriented language.For traditional programming languages,we have to“weave”it in on the level of the UML model.For statecharts S1defining the component and S1defining the error object(both assumed to beflattenable to contain only simple states[LCAK00]) the state set of the result S is the cartesian product of the state sets of S1and S2.There is a transition t from a state(s1,s2)to a state(s′1,s′2) in S if one of the following conditions holds:–if there is a transition with the same event,guard,and action from s1 to s′1in S1and s2=s′2,or–if there is a transition t′with the same event and action from s2to s′2 in S2and the guard of t is the conjunction of the guard of t′and the negation of each guard of a transition t′′in S1with the same event, and s1=s′1.3.1Tool SupportWe describe a prototypical tool currently under development for criti-cal systems development for checking constraints such as those associ-ated with the stereotypes defined above.Afirst version has been demon-strated at[J¨u r03a];a web-interface is currently being made available at http://www4.in.tum.de/csduml.The tool works with UML1.4models stored in a XMI1.2(XML Metadata Interchange)format by a suitable UML design tools.To avoid having to process UML models directly on the XMI level,the MDR(MetaData Repository,)is used,allowing one to operate on the UML model level(this is,for exam-ple,used by the UML CASE tool Poseidon,). The MDR library implements a repository for any model described by a modeling language compliant to the MOF(Meta Object Facility).This approach should easen the transition to future UML versions.To use the tool,a developer creates a model and stores it in the UML1.4/ XMI1.2file format.The tool imports thefile into the internal MDR repository and accesses the model through the JMI interfaces generated by the MDR library.The checker parses the model and checks the con-straints associated with the stereotype.The results are delivered as a text report for the developer describing problems found,and as a mod-ified UML model,where the stereotypes whose constraints are violated are highlighted.Specifically,the syntactic checks(such as safe links and safe dependency are implemented in Java,whereas the semantic checks(such as safe behavior and containment )need more special-ized tool-support(we are currently working on a connection with Spin and Prolog).。

面向方面MDA的实时系统开发方法刘敬勇1,2 , 张立臣1 , 陈成1(1广东工业大学计算机学院，广东广州510006 )(2中国科学院成都计算机应用研究所，四川成都 610041 )摘要：实时系统有许多横切整个系统的非功能需求，如果不能很好的处理，它将使系统的开发复杂化。

仅采用面向对象的方法不能很好的处理这些横切关注点，要处理好这些横切关注点需要将面向方面编程技术与MDA结合起来。

本文提出了在实时系统开发中使用面向方面MDA的方法，这种方法在设计阶段将系统的非功能需求从功能需求中分离出来，降低了实时系统开发的复杂性，提高了系统的可重用性、可维护性和横切关注点的模块化程度。

最后给出了应用实例。

关键词：面向方面，模型驱动架构，实时系统，非功能需求中图法分类号: TP311.52 文献标识码: AApplying Aspect-oriented MDA to Development of Real-time SystemsLIU Jing-Yong1,2, ZHANG Li-Chen1, CHEN-Cheng1(1.College of Computer , Guangdong University of Technology, Guangzhou 510006, China)(2.Chengdu Institute of Computer Application Academia sinica, Chengdu 610041, China) Abstract:Real-time systems have some non-functional requirements, which crosscut entire system that can complicate the development if they are not properly handled. Pure object-oriented methods do not address successfully those crosscutting concerns, so handling these crosscutting concerns of Real-time systems requires integrating the principles of Aspect-Oriented programming with MDA. This paper presents a proposal to use Aspect-oriented MDA in the development of the Real-time Systems, which uses MDA and concepts of the aspect-oriented paradigm to separate the handing of non-functional requirements from the functional ones since earlier design phases, in order to reduce the complexity of Real-time systems development and improve reusability and maintainability of real-time systems, and modularization of crosscutting concerns. At last, the paper presents the use of Aspect-oriented MDA on a case study.Keywords: aspect-oriented; MDA; Real-time systems; Non-Functional Requirements1引言随着信息技术的发展，实时系统的应用领域越来越广泛，像家用电器、通信、交通运输以及军事领域都大量采用实时系统。

面向方面（aspect）的程序设计方法程虎摘要 面向方面的程序设计（Aspect—Oriented Programming， AOP）是一种很有前途的新型程序设计方法，它是面向过程、面向对象方法的进一步发展。

通过引入方面概念，改进关注点的分离（separation of concerns），减少代码缠结（code tangling）解决横切关注点（cross cutting concerns）的问题，提高软件质量和效率。

自1997年AOP以来的7年间，全球已开展大量有关研究与开发工作，并自2002年起每年召开专门的国际学术会议（International conf .on Aspect－Oriented Software Development，AOSD）探讨问题，交流取得的成果。

关键词 方面，面向方面的程序设计（AOP），关注点，横切关注点，面向方面的软件开发（AOSD）。

1引言计算机软件包括程序及其文档。

程序设计包括设计、编制和调试程序的方法与过程。

程序设计方法涉及用于指导程序设计工作的原理和原则，以及基于这些原理和原则的设计方法和技术。

数十年来，经历公式翻译、过程式程序设计、结构化程序设计、逻辑式程序设计、函数式程序设计以及面向对象程序设计等。

程序设计方法学可以对程序设计人员选用具体的程序设计方法起指导作用，而具体的程序设计方法对象程序设计工作的质量以及所设计出来的程序（即软件）的质量影响巨大。

世间事物总是在不断发展变化，螺旋式上升。

程序设计方法也如此，近年来流行面向对象程序设计方法。

面向对象的方法起源于面向对象的编程语言，可以追溯到20世纪60年代后期的Simula67语言。

到20世纪末，面向对象方法已逐步发展成为一类完整的方法学和系统化的技术体系。

它不仅指导编程设计，还指导开发操作系统、数据库、网络和编译系统等。

使用面向对象语言来实现面向对象设计相对而言比较容易，用非面向对象语言也可实现面向对象设计。