当前位置:文档之家› page 1 From AOP to UML Towards an Aspect-Oriented Architectural Modeling Approach

page 1 From AOP to UML Towards an Aspect-Oriented Architectural Modeling Approach

page 1 From AOP to UML Towards an Aspect-Oriented Architectural Modeling Approach
page 1 From AOP to UML Towards an Aspect-Oriented Architectural Modeling Approach

From AOP to UML:Towards an Aspect-Oriented

Architectural Modeling Approach

Mohamed M.Kandé,J?rg Kienzle and Alfred Strohmeier

Software Engineering Laboratory

Swiss Federal Institute of Technology Lausanne

CH-1015Lausanne EPFL

Switzerland

email:{Mohamed.Kande,Joerg.Kienzle,Alfred.Strohmeier}@epfl.ch Abstract.Capturing concerns that crosscut the boundaries of multiple compo-

nents in software architecture descriptions is problematic.Standard description

languages,such as UML,do not provide adequate means to understand and

modularize such concerns,but aspect-oriented programming techniques do.

This paper explores and analyzes the suitability of UML for aspect-oriented

architectural modeling.It takes a bottom-up approach,starting from the code

level to the level of software architecture description,via aspect-oriented design,

using standard UML.

1Introduction

Aspect-oriented programming(AOP)is the name given to a set of techniques based on the idea that software is better programmed by capturing different“things that happen in a program”in different ways,and by encapsulating them into different modules[1]. This approach makes it possible to separately specify various kinds of concerns and localize them into separate units of encapsulation.One can deal with both the concerns and the modules that encapsulate them at different levels of abstraction,not only at the code-level[2].Examples of kinds of concerns in a software system include functional-ity,emerging system-level properties,and other qualities.Representing certain kinds of software concerns is well supported by modeling languages,like UML[3],if these concerns can be localized on a single component of a system,such as a class.Model-ing others kinds of concerns,e.g.,logging,transactions and security,is more difficult, as they typically cut across the boundaries of many components of a system.In this work,we consider two issues that we believe need to be fundamentally addressed when providing support for modeling crosscutting concerns:

?Understanding what concerns cut across which representational elements and where they do so.Without this information,it becomes very hard to represent and reason simultaneously about the crosscutting structure and the behavior in the sys-tem.

?Provide a means to separate crosscutting from non-crosscutting concerns and encapsulate the former into aspects.

To tackle these issues,we take a bottom-up approach that starts with the key concepts used to represent crosscutting concerns in aspect-oriented programs.Based on this and page 1

on our experience in modeling object-oriented software with UML,we analyze the suitability of UML to support aspect-oriented software modeling.

One of the main elements of an aspect-oriented programming language is the join point model.It describes the“hooks”where enhancements may be added,determining thus the structure of crosscutting concerns.To support this model,AOP languages are required to provide means to identify join points,specify behavior at join points, define units that allow one to group join point specifications and behavior enhance-ments together,as well as means for attaching such units to a program[1].

A second important element in AOP is the“weaving”capability support.When using AOP languages,the programmer relies on the underlying AOP environment to weave or compose separate concerns together into a coherent program.Separating the representation of multiple kinds of concerns in programs in such a way promises increased readability,simpler structure,adaptability,customizability and better reuse.

UML is a standard modeling language used to create and document software arti-facts.It includes many useful ideas and concepts that have their roots in various indi-vidual methods and theories.UML provides numerous modeling techniques,including several types of diagrams,model elements,notation and guidelines.These techniques can be used in various ways to model different characteristics of a software system. Key features of UML comprise:support for model refinement,extension mechanisms (stereotypes,tagged values,and constraints),and a language for expressing constraints (known as the object constraint language,OCL).UML has established itself as a well-accepted modeling language that provides adequate support for object-oriented and component-based software development[4].

Basically,there are various possibilities of using UML to model crosscutting con-cerns in a software system.For instance,join points can be represented in UML as model elements,but their effect can also be shown in different diagram types of UML, e.g.,collaboration,sequence and statechart diagrams.Now,the question that remains to be asked is how suitable is UML,in its current state,for modeling aspect-oriented software systems?

To answer this question,this paper takes a bottom-up approach,establishing paral-lels between AOP code and UML models.Section2introduces the key concepts of AspectJ,the aspect-oriented programming language we used for our experiment.Sec-tion3shows how some,but not all,AOP concepts can be modeled in standard UML. Section4identifies extensions to UML that allow us to better capture the essence of aspect-oriented modeling,and finally,in section5we draw some conclusions from this experiment.

2AspectJ

AspectJ[5]is an aspect-oriented programming environment for the Java language.It has served as a basis for our experiment.

AspectJ defines the notion of join point as a well-defined point in the execution flow of a Java program.Join points include method and constructor calls or execu-tions,field accesses,object and class initialization,and others.A set of join points is called a pointcut.To pick out a set of join points of a certain kind,a programmer uses a pointcut designator of a certain kind and pattern matching techniques to specify the page 2

method signature,classes,or packages of interest.Pointcuts can be further composed with boolean operations to construct other pointcuts.

While pointcuts allow the programmer to identify join points,the advice constructs define additional code to run at those join points.An advice contains a code-fragment that executes either before,after or around a given pointcut.Finally,aspects are pro-vided which,very much like a class,group together methods,fields,constructors,ini-tializers,but also named pointcuts and advice.Aspects are intended to be used for implementing a crosscutting concern.

3Supporting Aspect-Oriented Modeling

This section addresses UML support for object-oriented modeling,and discusses the appropriateness of current UML for modeling of aspect-oriented software systems. 3.1Using UML for Object-Oriented Modeling

Modeling object-oriented concepts is well supported by UML.Consider,for example, a simple banking system,which the following Java classes Account and Customer are part of:

public class Account{

private int balance=0;

public void withdraw(int amount){...};

public void deposit(int amount){...};

public int getBalance(){...};

}

public class Customer{

public String name;

//inside some method(a is an account)

a.withdraw(50);

}

To model the static and dynamic structure shown in the Java code,two types of UML diagrams could be used,i.e.,a collaboration diagram and a class diagram,each provid-ing a different view.The collaboration diagram shown in Figure1illustrates a behav-ioral view that focuses on the interaction between a Customer object c invoking a method of an Account object a.Collaboration diagrams typically give you an idea about how objects work together,showing both the participant objects(part of the structural characteristics)and the interactions between them(the messages they exchange).In our example,c calls the method withdraw of a,which is shown in the figure by the arrow labeled with withdraw(50).

c:Customer

a:Account

1:withdraw(50)

Fig. 1: A UML Collaboration Diagram

page 3

As in this case no further information is given on how the customer c gets to know the account a,we must assume that they are statically linked together.This results in an association link between the two classes,as depicted by the class diagram in Figure2. Thus,Figure2shows a static structure view of(this part of)the system with a particu-lar focus on how the classes relate to each other.

Fig. 2: A UML Class Diagram

In Figure1,each interacting object plays a different role.UML allows us to specify this by attaching role names to both association ends,shown as owner and ownedAc-count in Figure2.Multiplicity constraints can also be attached to association ends in order to express the possible number of occurrences of the association.Note that this information is not shown in the Java code.

As the simple banking system evolves,the requirements change.Developers might be asked to add the following new feature to the system:every access to an account object should be logged,recording the name of the accessing customer and the type of access on a log file.This logging feature is a typical example of a crosscutting concern, which can not easily be represented in an object-oriented design.The concern will inevitably be scattered throughout the model and/or entangled with other features [6][7][8].Adding such a feature is best supported by aspect-oriented software develop-ment.

3.2Using UML for Aspect-Oriented Modeling

The most intuitive join points defined by AspectJ are method calls(not including super calls).The pointcut designator that allows a programmer to pick out a set of method calls based on the static signature of a method has the form:

pointcut someName:call(Signature);

Using the pointcut construct,it becomes straightforward to write an aspect that inter-cepts all calls to object instances of a certain class,performs some preprocessing,pro-ceeds with the call,and finally does some postprocessing.

In the example below,the Logging aspect intercepts all method calls made by cus-tomers on an account object and logs the access to a file:

public aspect Logging{

private Log Account.myLog;

public void Account.setLog(String fileName){

myLog=new Log(fileName);

myLog.println

("This is the logfile for account"+this);

}

declare parents:Account implements Loggable;

page 4

pointcut MethodCall(Customer c,Account a):

call(public*Account.*(..))

&&this(c)&&target(a);

after(Customer c,Account a):MethodCall(c,a){

a.myLog.println(c+"called"+

thisJoinPoint.getSignature().getName());

a.myLog.flush();

}

}

The Logging aspect introduces a new method,called setLog(),into the Account class.This new method associates an account object with a log that writes the logging information into a text file.The reference to the log is stored in the private attribute named myLog.A UML class diagram that captures this change from the static structure point of view is shown in Figure3.

Fig. 3: Class Diagram for Account Logging Aspect

To capture the interaction going on during a method call with an aspect,we need to modify the collaboration diagram presented in Figure1to explicitly show the method call interception.

A typical way of modeling interception of method calls,when using UML,is to add a new class,whose instance will be interposed between the interacting objects. This technique is illustrated in Figure4.An interceptor object i is placed between the customer and the account objects.In addition to implementing the logging feature itself,the object i must:

?Offer an interface that supports all methods of the account object that are invoked by the customer object.

?Provide a mechanism to forward intercepted calls to the account object.

Instead of calling the account object directly,the customer object now actually calls the interceptor object(1:withdraw(50)).In our example,the logging action is per-formed in the after advice.Therefore,the message1:withdraw(50)is first forwarded to the account object as1.1:withdraw(50),and upon return the call is logged by page 5

page 6

sending the message 1.2:println(..)and 1.3:flush()to the log file associated with the account object.

3.3Discussion

UML,in its current state,allows us to capture the structure and interactions of our aspect-oriented program.However,the resulting model presents some major draw-backs:

?Crosscutting concerns can not be well modularized:The design of the logging capability is scattered throughout the diagrams.It is partially modeled in both the Loggable interface and the new association between the Account and the Log class,as shown in the class diagram.In the collaboration diagram,it is represented by the Interceptor object,and the messages it exchanges with the other objects.Note also that the two diagrams are inconsistent,since the Interceptor class does not appear in the class diagram.

?According to the diagrams,there is no difference between modularization by class and by aspect.The basic concepts of AspectJ,such as pointcuts,introduction and advice,are not explicitly modeled.

?The model does not capture the fact that the interception of the call is done trans-parently.In Figure 4,the code of the Customer class must be modified to call the interceptor object instead of calling the account object.As a consequence,any per-manent attributes referencing account objects must be changed to reference inter-ceptor objects.

?The model does not show that the logging aspect is a “pluggable”entity,i.e.,that the account can be used with or without logging,depending on the application semantics.Both diagrams give the impression that aspects are static entities,although,in reality,aspects are configured at weave-time,and triggering them can be based on various kinds of execution flows or conditions.

These drawbacks actually come with no surprise.During design,the aim is to model a specific solution for a given problem.As a result,the standard UML diagrams model the static and dynamic structure of the Java code after the weaving process,since it is only in its woven form that the code implements the logging capability.

Unfortunately,this leads to some form of abstraction inversion,since the nicely separated logging code in the implementation is scattered throughout the design model.The only solution to this problem,in our opinion,is to separate concerns also during design,and to define a design-weaving process.

In summary,our intention in this section was to address two essential issues:a:Account

c:Customer 1:withdraw(50)Fig. 4: Collaboration Diagram With an Interceptor

i:Interceptor 1.1:withdraw(50)

myLog:Log

1.2:println(..)

1.3:flush(..)

page 7

1.explain how a code-driven design approach allows one to understand some key characteristics of aspect-oriented modeling and compare them to object-oriented modeling;

2.argue for the use of advanced separation of concerns (e.g.,separating crosscutting concerns from non-crosscutting concerns)as a technique to complement object-oriented modeling with the notion of aspects.

4Extending UML for AOSD

Code-driven design,as presented in the previous section,limits the ability to under-stand various kinds of concerns,since it enables expressing the crosscutting nature of software concerns from only one single perspective (a low-level,static and textual view of the system).This makes it difficult to integrate aspects with other software artifacts and to reason about modules of crosscutting concerns from different perspec-tives or viewpoints.Indeed,developing aspect-oriented software requires thinking of an aspect as an abstraction that defines a certain interaction context,and offers behav-ior that can vary depending on certain conditions at run-time.Fulfilling such a require-ment necessitates the ability to understand and describe the system from multiple viewpoints.

To overcome the shortcomings of current modeling techniques,aspects need to be treated as first-class citizens in advanced modeling languages.We propose to define an aspect as a UML model element that modularizes crosscutting concerns at various lev-els of abstraction,not only at the code-level.

Consider,for example,the logging aspect introduced previously.To capture the logging aspect in a single module using UML,we need to introduce a representational unit that encapsulates the role of the interceptor object as well as the interactions between the participant objects of the classes Customer ,Account and Log .

Let’s go back to our collaboration diagram.Figure 5is similar to Figure 4,except that the additional structure introduced by the logging aspect is highlighted in grey.We will now proceed and make this grey part a first-class citizen,and determine what must be part of this aspect,and what not.

Clearly,the participants c ,a ,and myLog are not part of the aspect,since they per-form computation on the outside.It is the role of the interceptor object to mediate the interactions between these objects,linking them together.The interceptor therefore should be part of the aspect.The mediation itself happens at the connection points highlighted in Figure 5by CP 1,CP 2and CP 3.a:Account

c:Customer 1:withdraw(50)Fig. 5: Identifying Connection Points

i:Interceptor 1.1:withdraw(50)

myLog:Log

1.2:println(..)

CP 1CP 2CP 3

1.3:flush(..)

The aspect is executed when reaching CP1,that is when a call join point is reached.From the interceptor point of view,CP1is an incoming(or passive)connec-tion point.The control flow enters the aspect from the outside.CP2and CP3on the other hand are outgoing(or active)connection points.The control flows from the aspect to the outside.CP2has a special relationship with CP1,since the calls that enter through CP1can exit through CP2.Therefore,they both present the same sig-natures,with opposite flow directions.They are conjugated.To actually perform log-ging,the aspect requires an instance of the Log class to be present,providing the println and flush methods,which are called at execution time.This is done through the connection point CP3.The signature of CP3is completely independent from CP1and CP2.

By making the notion of connection points explicit,we are now able to define stand-alone aspects and reason about them as a particular kind of UML collaboration. They clearly separate crosscutting interaction concerns from computation as per-formed by participant objects.The connection points being well-defined parts of the aspect,it is possible to bind them to individual objects.In UML,a binding corresponds to the concept of attaching a classifier role to an association role end.In our case,the association role end corresponds to a connection point.However,in contrast to stan-dard UML,our model focuses on explicit modeling of the association role end as part of the aspect construct,allowing one to clearly separate modeling of interaction con-cerns from the“dominant”structure of classifier roles.

We propose to define a new stereotype of UML collaboration to support aspect-ori-ented modeling with UML.This enables us to instantiate the new aspect classifier to model interaction concerns in an explicit and reusable way.

Figure6illustrates this idea.It consists of four types of elements:the aspect itself, the associated connection points,normal UML classes,and the binding relationship.

The aspect itself,highlighted in the figure by a dotted oval,specifies the actions to be performed at the connection points and along the interconnections,along with static information that will be woven into the objects of the classes it binds to.For example, in Figure6,the first two compartments of the aspect represent two elements of the log-ging feature,an attribute and a method,which need to be woven into the Account class at binding time.The Advice compartment defines an action to be executed after return-ing from a method call to an account object instance.This action encapsulates the actual code calling the log.

page 8

The connection points are shown in Figure6using white and black circles.White circles are incoming connection points.Black circles are outgoing connection points.

A white and a black circle connected by a line means that the connection points are conjugated.A connection point is the construct designed to model pointcuts,but it is general enough to cover also other kinds of points of interactions.

Connection points can be composed to build the interface of an aspect in the same way multiple UML interfaces can be combined to form the interface of a class.How-ever,there are two major differences between a connection point and a UML interface: first,connection points can be instantiated,whereas UML interfaces cannot;second, UML interfaces define signatures of operations,while connection points declaratively specify invocations to these operations and the compositions thereof.Moreover,con-nection points allow us to define attributes.These are typically used as parameters for binding objects to the connection points of the aspect.

Examples of connection points shown in Figure6are logCall and methodCall. The logCall connection point(CP3in Figure5)is outgoing,meaning that the aspect will make use of it during execution.It specifies what the aspect requires from its envi-ronment during execution.In an implementation,it maps to a Java interface or abstract class.Its properties,i.e.,attributes and methods,are shown in the attribute and Call compartment.

The methodCall connection point is a special form of connection point that groups together two conjugated connection points(CP1and CP2shown in Figure5).It directly maps to a call pointcut in AspectJ.The pointcut definition can be shown in the Call compartment.

At weave-time,objects bind to the connection points offered by aspects.The bind-ing relationship specifies what class of objects an instance of the aspect can be bound to.In our example,the aspect must be bound to instances of the classes Customer, Account and Log.Therefore,our aspect could,at weave-time,interconnect customer c with account a and the log object named mylog.

5From Aspects to Connectors

So far,we have not addressed the weaving process as such from the modeling point of view.In the previous models,the actual combining of the connection points with the participant objects is not explicit.It is“hidden”in the binding concept,and as a conse-quence we can not reason about it explicitly.For example in Figure6,we can not see that a customer actually interacts with an account.We therefore do not have sufficient information about possible aspect configurations.

The situation is similar to the one found in component-based software develop-ment,when bringing together heterogeneous,existing components.These components are usually considered as black boxes.They are stand-alone elements that can be con-figured in different ways to fit some specific interaction contexts.A component offers features that are used by others components within a particular context of interactions. The behavior that can be observed in various contexts of interactions(“who”does “what”and“when”)can vary considerably,depending on a number of run-time condi-tions.It is therefore the duty of the“composition environment”to provide mechanisms for interconnecting the components and coordinating their interactions.Such mecha-page 9

nisms have been addressed by the notion of software connector,as defined by architec-ture description languages(ADLs)[12][13]§.

In this paper,we consider the following definition of connectors given by Shaw and Garlan[11]:

“Software connectors…mediate interactions among components;that is,they establish the rules that govern component interactions and auxiliary mechanisms required.”

This definition induces a number of requirements that need to be fulfilled by formal-isms supporting the modeling of software connectors.According to these authors,typ-ical examples of requirements on connectors include,the ability to:

?give guarantees about delivery of packets in a communication system;?describe restrictions on event ordering and procedure calls;

?describe incremental production and consumption rules about pipelines;?distinguish between roles of interconnected components,such as clients and serv-ers;and

?describe constraints on parameter matching and binding rules for conventional and remote procedure calls.

These requirements,compared to those identified for aspects in the previous section, reveals a deep similarity between a connector and an aspect.Like connectors,aspects are stand-alone modularization units that mediate interactions among a set of compo-nents that are crosscut by the concerns encapsulated by the https://www.doczj.com/doc/0d14043816.html,ing software con-nectors,interconnections among components can be initiated by different means.For example,some communication services can be used by invoking some specific proce-dures.Similarly,the actions of an aspect are triggered by an occurrence of one or more join points.

However,the aspect might also require presence of some auxiliary mechanisms that must be realized by additional objects,interfaces or communication services in order to function properly.To coordinate activities among a set of interconnected com-ponents,connectors provide sets of interaction protocols.Likewise,based on the notion of advice,aspects declaratively specify sets of actions that can be performed before,around or after join points are reached.Thus,the pointcut and advice con-structs,as defined by aspects,can be valuably used to establish the rules that govern the component interactions.

Just as the provider of a component can not anticipate the way it will be used in dif-ferent interaction contexts,the programmer of the Customer and Account objects can not anticipate the communications related to the logging feature.However,when adding crosscutting features to a component-based system,a possible,but error-prone, architectural solution could be to reverse engineer the components,analyze the struc-ture of the code and decide where to add the new feature by hand.However,it becomes difficult to make the components work together to support the realization of the new feature.This is a typical example encountered when architectural decisions are driven by the program code.

page 10

To surmount these limitations,we introduce the notion of ports on classes for rep-resenting the interface elements of individual components.In a sense,we keep the black-box view,but provide additional,externally visible,extension points.This solu-tion is based on previous work presented in[14],inspired by the ROOM method[15] and RM-ODP[16].It consists of applying separation of concerns at the level of inter-faces,allowing us to define different interaction points for different kinds of communi-cations.At this stage,as the communication between the components is based on sending and receiving messages in terms of UML,we focus on operational ports.To understand various facets of this solution,we discuss the logging example in two dif-ferent architectural models:a aspect design model and a configuration model.

5.1Aspect Design Model

The aspect design model is based on one presented in section4,but this time,each par-ticipant object is treated as a separate black-box component.

Figure7shows the aspect design model of our Logging aspect.In addition to Figure6,it now contains three ports.They are named CustomerPort,AccountPort and LogPort.Ports have strong similarities with UML Interfaces.However,like con-nection points,ports may have attributes and can be instantiated.Also,each port defines two compartments,specifying the services it provides to,but also the ones it requires from the environment,unlike UML Interfaces.

5.2Configuration Model

The configuration model shown in Figure8describes the system from the static struc-ture point of view.In contrast to the aspect design model,it focuses on the representa-tion of instances rather than types,modeling thus a particular system rather than a page 11

family of systems.To differentiate the instances from types,all the names of the ele-ments in a configuration model need to be underlined.

Fig. 8: Configuration Model Before the Weaving Process

Figure8illustrates a particular configuration of the system before the weaving pro-cess.At this point,we show the explicit binding between connection points and ports. It allows us to perform“type checking”,i.e.,it is possible to verify that connection points are bound to compatible ports only.The binding,however,is not instantiated yet.

Finally,Figure9shows the resulting configuration after the weaving process.In this view,the binding in not explicitly shown anymore.It has been instantiated by plugging the connection points into the ports.We also show the established connec-tions between the participant components.

Last,but not least,the model shows the realization of the introduction concept,as defined by aspect-oriented programming languages.This is illustrated in Figure9, where the setLog capability has been plugged into the AccountPort.

Fig. 9: Configuration Model After the Weaving Process

5.3Composition of Aspects

In the configuration model,we can also nicely show aspect composition.To illustrate this idea,we assume that our system must provide the possibility to block access to certain objects in certain situations.For instance,an account must be blocked in case the balance drops below a certain threshold,or if the associated debit card has been reported stolen.Such a crosscutting Blocking feature can easily be implemented as an aspect intercepting all calls to an account,forwarding them only if the account has not been blocked.In this simple example the model of the Blocking aspect has only two conjugated connection points,with exactly the same signature as the conjugated connection points of the Logging aspect.This makes it possible to compose both page 12

page 13

aspects by “plugging”the passive Blocking connection point into the active Log-ging connection point.

Figure 10shows the composition of the two aspects.In this case,the composite aspect first performs logging,and then blocking.This means that blocked calls will also be logged.If blocked calls should be omitted from the log,then the composition can be done in the opposite order.From the outside,the composition can be seen as a new aspect.The intermediate connection points,shown in grey in Figure 10,are hidden.6Conclusion

In this paper we have analyzed the suitability of UML for modeling aspect-oriented software.We have taken a bottom-up approach,starting from a small piece of code as found in aspect-oriented programming languages,and then tried to model the design of this code using standard UML.

Since UML does not define the idea of weaving,the nicely separated concerns in the aspect-oriented program ended up scattered throughout the design model.In addi-tion,we showed that by making aspects first-class citizens,we can nicely separate crosscutting concerns.To capture different facets of an aspect,we proposed two archi-tectural models:the aspect design model and the configuration model.

The Aspect Design Model shows the static structure of the aspect at type level.It specifies well-defined connection points,which are the basis for pluggability,since they specify the aspect interface.Likewise,ports are added to participant components,stating both provided and required services,and exposing possible extension points.Connection points and ports together determine what components the aspect can con-nect.

The Configuration Model describes a particular way to combine instances of the aspect with the components it interconnects.The combination is shown before and after the weaving process,as both are significant.Before the actual weaving,the bind-ing construct allows us to perform “type checking”,insuring adherence to the plugga-bility rules.After the weaving,we are able to show the established connections and the additional features introduced into the components by the aspect.

We discovered a strong similarity between aspects and software connectors as found in architectural description languages.However,existing connector models do not explicitly support modeling of crosscutting concerns.We believe that further investigations in this direction will allow us to consolidate the relationship between :Customer :Account

:Log

<>:Logging Fig. 10: Composing Aspects in the Configuration Model

<>:Blocking

aspects and connectors.Our ultimate goal is to produce extensions to UML that make it suitable for aspect-oriented architectural descriptions.

References

[1]T.Elrad,M.Aksits,G.Kiczales,K.Lieberherr,and H.Ossher:“Discussing

Aspects of AOP”.Communications of the ACM44(10),pp.33–38,October 2001.

[2]P.Tarr,H.Ossher,W.Harrison,and S.M.Sutton,Jr.:“N Degrees of Separa-

tion:Multi-Dimensional Separation of Concerns”.In Proceedings of the1999 International Conference on Software Engineering,pp.107–119,Los Ange-les,CA,USA,1999,IEEE Computer Society Press.

[3]J.Rumbaugh,I.Jacobson,and G.Booch:The Unified Modeling Language Ref-

erence Manual.Object Technology Series,Addison Wesley Longman,Read-ing,MA,USA,1999.

[4]G.Booch,J.Rumbaugh,and I.Jacobson:The Unified Modeling Language

User Guide.Addison–Wesley,Reading,Massachusetts,USA,1ed.,1999. [5]G.Kiczales,E.Hilsdale,J.Hugunin,M.Kersen,J.Palm,and W.G.Griswold:

“An Overview of AspectJ”.In15th European Conference on Object–Oriented Programming(ECOOP2001),pp.327–357,June18–22,2001,Budapest, Hungary,2001.

[6]M.Aksit,L.Bergmans,and S.Vural:“An Object-Oriented Language-Database

Integration Model:The Composition-Filters Approach”.In O.L.Madsen(Ed.), 6th European Conference on Object–Oriented Programming(ECOOP’92), pp.372–395,Utrecht,The Netherlands,June1992,Lecture Notes in Com-puter Science615,Springer Verlag.

[7]S.Clarke,W.Harrison,H.Ossher,and P.Tarr:“Subject-Oriented Design:

Towards Improved Alignment of Requirements,Design and Code”.In Pro-ceedings of the Conference on Object-Oriented Programming,Systems,Lan-guages,and Applications,pp.325–339,Addison–Wesley,1999.

[8]G.Kiczales,https://www.doczj.com/doc/0d14043816.html,mping,A.Mendhekar,C.Maeda,C.Lopes,J.-M.Loingtier,

and J.Irwin:“Aspect-Oriented Programming”.In M.Aksit and S.Matsuoka (Eds.),11th European Conference on Object–Oriented Programming (ECOOP’97),pp.220–242,Jyváskylá,Finland,1997,Lecture Notes in Com-puter Science1241,Springer Verlag.

[9]OMG Unified Modeling Language:“UML with Action Semantics,Final

Adopted Specification”,January2002.https://www.doczj.com/doc/0d14043816.html,/

[10]G.Kiczales,https://www.doczj.com/doc/0d14043816.html,mping,A.Mendhekar,C.Maeda, C.Lopes,J.Loingtier and

J.Irwin:“Aspect-Oriented Programming.”In Proceedings ECOOP’97, Springer-Verlag,June1997.

page 14

[11]M.Shaw and D.Garlan:Software Architecture-Perspectives on an Emerging

Discipline.Prentice-Hall,New Jersey(1996).

[12]N.Medvidovic and R.N.Taylor.A Classification and Comparison Framework

for Software Architecture Description Languages.IEEE Transactions on Soft-ware Engineering,V ol.26,No.1,January2000.

[13]Mehta N.,Medvidovic N.,and Phadke S.Towards a Taxonomy of Software

Connectors.Proceedings of the International Conference on Software Engi-neering-ICSE'00(2000).

[14]M.Kande,A.Strohmeier:“Towards an UML Profile for Software Architecture

Descriptions”.UML'2000-The Unified Modeling Language:Advancing the Standard,Third International Conference,York,UK,October2-6,2000,Kent, S.,Evans,A.,Selic,B.(Ed.),LNCS(Lecture Notes in Computer Science) [15] B.Selic,G.Gullekson,and P.Ward:“Real-Time Object-Oriented Modeling”.

Wiley,1994.

[16]ISO/IEC10746-1/2/3:“Reference Model for Open Distributed Processing-

Part1:Overview/Part2:Foundations/Part3:Archictecture”.ISO/IEC(1995). page 15

UML设计模式考试题

UML设计模式考试题 简单工厂模式的实质是由一个工厂类根据传入的参数,动态决定应该创建哪一个产品类(这些产品类继承自一个父类或接口)的实例。 该模式中包含的角色及其职责 工厂(Creator)角色 简单工厂模式的核心,它负责实现创建所有实例的内部逻辑。工厂类可以被外界直接调用,创建所需的产品对象。 抽象(Product)角色 简单工厂模式所创建的所有对象的父类,它负责描述所有实例所共有的公共接口。 具体产品(Concrete Product)角色 简单工厂模式的特点: 简单工厂模式的创建目标,所有创建的对象都是充当这个角色的某个具体类的实例。 在这个模式中,工厂类是整个模式的关键所在。它包含必要的判断逻辑,能够根据外界给定的信息,决定究竟应该创建哪个具体类的对象。用户在使用时可以直接根据工厂类去创建所需的实例,而无需了解这些对象是如何创建以及如何组织的。有利于整个软件体系结构的优化。 请问什么是责任链器模式,责任链模式包含哪些角色、可以应用在哪些场景?定义:使多个对象都有机会处理请求,从而避免请求的发送者和接受者之间的耦合关系,将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。角色:处理者、具体处理者。场景:有许多对象可以处理用户的请求,希望程序在运行期间自动确定处理用户的那个对象;希望用户不必明确指定接受者的情况下,向多个接受者一个提交请求;程序希望动态指定可处理用户请求的对象集合 设计模式六大原则-单一职责原则、开放封闭原则、依赖倒转原则、里氏代换原则、迪米特法则、合成/聚合复用原则 标签:扩展编程设计模式class测试工作 2012-07-31 09:26 1823人阅读评论(0) 收藏举报 分类:OO(1) 原则,故名思议则是本质的意思。所谓擒贼先擒王,研究设计模式自然要先了解设计原则,所有的模式都是在这些原则的基础之上发展起来的,有的是侧重一个,有的是多个都有所涉及。看完设计模式之后,我感觉到每个模式都有这些原则的影子,还渗透着面向对象的三大属性,也觉得这些原则也都有相通之处,,正是有了他们才使我们由代码工人转为艺术家。下面我来点评一下六大原则,望各位拍砖: 1、单一职责原则(Single Responsibility Principle,简称SRP) 单一职责原则,就一个类而言,应该仅有一个引起它变化的原因。如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会消弱或者一直这个类完成其他职责的能力。这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破

23种设计模式_UML_类图及对应示例代码

23种设计模式UML 类图及对应示例代码(一) 收藏 1.DoFactory.GangOfFour.Abstract.Structural Abstract Factory:提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。 工厂模式:客户类和工厂类分开。消费者任何时候需要某种产品,只需向工厂请求即可。消费者无须修改就可以接纳新产品。缺点是当产品修改时,工厂类也要做相应的修改。如:如何创建及如何向客户端提供。 using System; namespace DoFactory.GangOfFour.Abstract.Structural { ///

/// MainApp startup class for Structural /// Abstract Factory Design Pattern. ///

class MainApp { ///

/// Entry point into console application. /// public static void Main() { // Abstract factory #1 AbstractFactory factory1 = new ConcreteFactory1(); Client client1 = new Client(factory1); client1.Run(); // Abstract factory #2 AbstractFactory factory2 = new ConcreteFactory2(); Client client2 = new Client(factory2); client2.Run(); // Wait for user input Console.Read(); } } // "AbstractFactory" abstract class AbstractFactory { public abstract AbstractProductA CreateProductA(); public abstract AbstractProductB CreateProductB(); } // "ConcreteFactory1" class ConcreteFactory1 : AbstractFactory { public override AbstractProductA CreateProductA() { return new ProductA1(); } public override AbstractProductB CreateProductB() { return new ProductB1(); } }

uml与设计模式

返回总目录
目 录
第 10 章 UML 与设计模式 ...................................................................................2 10.1 10.2 10.3 10.4 10.5 10.6 10.7 10.8 10.9 10.10 10.11 什么是模式 ................................................................................................2 为什么要使用设计模式 ............................................................................3 模式的分类 ................................................................................................4 模式的组成元素 ........................................................................................6 模式的质量 ................................................................................................7 一个简单的模式例子 代理模式 ............................................................8 UML 对模式的支持 ..................................................................................9 应用设计模式进行系统设计 ..................................................................14 模式选择举例 评估项目 ......................................................................15 模式应用举例 形状编辑器 ................................................................20 小 结 ..................................................................................................36

实验一 设计模式综合应用(一)附源码+UML图

注:班里的可以向我要工程文件 实验一设计模式综合应用(一) 一、实验目的: 熟练掌握Java设计模式中的命令模式和观察者模式,并培养学生将两者综合应用到具体软件项目中的能力。 二、实验内容: 制作如图1所示GUI界面,需求如下: 1. 鼠标左键点击界面时,在鼠标所在位置填充一个直径为20像素的圆, 并在界面上方的标签上显示“新增圆点位于:(x,y)”; 2. 鼠标右键点击时,则实现undo操作,将最后填充的圆点从界面中删除, 并在界面上方的标签上显示“删除圆点位于:(x,y)”; 3. 界面下方的标签随时显示“鼠标位于:(x,y)”; 图1 GUI界面 三、实验要求: 1. 绘制和撤销圆点使用命令模式; 2. 两个标签内容的变更使用观察者模式; 3. 在代码实现之前,进行UML类图设计;

4. 根据UML类图,在eclipse中编程实现程序的功能。 四、实验学时:2+2学时(课外2个学时) 五、提示: 1.设计一个Circle类,该类对象用来记录某个填充圆的信息; 2. 每填充一个圆点,就实例化一个Circle类对象,并将其放置到具体命令对 象关联的List对象中,用来作为undo操作的依据; 3. 填充圆可以使用Graphics的fillOval方法; 4. 删除圆可以先将Graphics对象的颜色设置为画布的背景色,再使用 Graphics的fillRect方法; 5. 标签显示内容的需求不用观察者模式就可以轻松实现,但要求使用观察者 模式进行设计; 5. 实验完成后,将UML文件和程序的工程文件打包,命名为“实验一.rar”, 并上传至ftp://10.10.3.72。 六UML图 七源代码 1. package lsu.egg.sy1; public class Circle { private int x; private int y;

UML选择题

UML选择题

-、选择题 1.封装是指把对象的(A)结合在一起,组成一个独立的对象。 A. 属性和操作 B.信息流 c.消息和事件 D.数据的集合 2.封装是一种(C)技术,目的是使对象的生产者和使用者分离,使对象的定义和实現分1开。 A. 」_程化 B.系统维护 C.信息隐敞 D.产生对象 3.面向对象方法中的(D)机制使子类可以自动地例有(复制)父类全部属性和操作。 A.约東 B.对象映射 c.信息隐蔽 D.继承 4.在c++中,使得在多个类中能够定义同一个操作或属性名,并在每一个类中有不同的实現的一种方法是(B)。 A.继承 B.多态性 C.约束 D.接口 1.UML的软件开发以(A)为中心,以系统体系结构为主线,采用循环、迭代、渐增的方式进

行开发。 A.用例 B.对象 C.类 D.程序 2.uML的(B)模型图由类图、对象图、包图、构件图和配置图组成。 A.用例 B.静态 C.动态 D.系统 3.uML的(c)模型图由活动图、顺序图、状态图和协作图组成。 A.用例 B.静态 C.动态 D.系统 4.UML的最终产物就是最后提交的可执行的软 件系统和(D)。 A.用户手册 B.类图 C.动态图 D.相应的软件文档资料 5.在u ML的需求分析建模中,(B)模型图必 须与用户反复交流并加以确认。 A.配置 B.用例 C.包 D.动态 1.可行性研究分析包括经济可行性分析、技术可行性分析和(B)。

A.风险可行性分析 B.法律可行性分析 c.资源可行性分析 D.效益可行性分析 2.uML的客户需求分析模型包括(A)模型、初始类图、初始对象图和活动图组成。 A.用例 B.静态 C.动态 D.系统 3. uML客.J·?需求分析使用的 CRC卡上“责任”一栏的内容主要描述类的( C )和操作。 A.对象成员 B.关联对象 C.属性 D.私有成员 4.uML客户需求分析产生的用例模型描述了系 统的(D)。 A.状态 B.体系结构 c.静态模型 D.功能要求 5.在u ML的需求分析建模中,用例模.型必须与 (D)反复交流并加以确认。 A.软件生产商 B.用户单位领导 C.软件开发人员 D.问题领域专家 6.在u ML的需求分析建模中,对用例模.型中的 用例进行细化说明应使用(A)《图一>文字一>

江西理工大学UML与设计模式复习题(答案参考版)

UML 与设计模式复习题 题型:单项选择题、多项选择题、简答题、设计题 1、简述GRASP 模式的内容。 答:GRASP 是General Responsibility Assignment Software Pattern(通用责任分配软件模式)的缩写。GRASP 模式可以用来设计类,这个模式包括9个基本原则:创建者、信息专家、低耦合、控制器、高内聚、多态性、纯虚构、间接性、防止变异。 2、掌握如何阅读、绘制活动图的基本方法。 答:1.阅读活动图: 活动图的主要元素 ?初始节点和活动终点:用一个实心圆表示初始节点,用一个圆圈内加一个实心圆来表示活动终点 ?活动节点:是活动图中最主要的元素之一,它用来表示一个活动 ?转换:当一个活动结束时,控制流就会马上传递给下一个活动节点,在活动图中称之为“转换”,用一条带箭头的直线来表示 活动图的主要元素 ?分支与监护条件:分支是用菱形表示的,它有一个进入转换(箭头从外指向分支符号),一个或多个离开转换(箭头从分支符号指向外)。而每个离开转换上都会有一个监护条件,用来表示满足什么条件的时候执行该转换。 2.绘制活动图 ?绘制时首先决定是否采用泳道:主要根据活动图中是否要体现出活动的不同实施者?然后尽量使用分支、分岔和汇合等基本的建模元素来描述活动控制流程 ?如果需要,加入对象流以及对象的状态变化,利用一些高级的建模元素(如辅助活动图、汇合描述、发送信号与接收信号、引脚、扩展区)来表示更多的信息 ?活动图的建模关键是表示出控制流,其它的建模元素都是围绕这一宗旨所进行的补充工作流程,控制流程,业务流程中使用。 3、掌握如何阅读顺序图,如图所示,类Reservation,Window 必须实现哪些方法? : Participant

uml设计模式三个工厂类图代码详解

工厂模式在《Java与模式》中分为三类: 1)简单工厂模式(Simple Factory):不利于产生系列产品; 2)工厂方法模式(Factory Method):又称为多形性工厂; 3)抽象工厂模式(Abstract Factory):又称为工具箱,产生产品族,但不利于产生新的产品; 这三种模式从上到下逐步抽象,并且更具一般性。 GOF在《设计模式》一书中将工厂模式分为两类:工厂方法模式(Factory Metho d)与抽象工厂模式(Abstract Factory)。将简单工厂模式(Simple Factory)看为工厂方法模式的一种特例,两者归为一类。 二、简单工厂模式 简单工厂模式又称静态工厂方法模式。重命名上就可以看出这个模式一定很简单。它存在的目的很简单:定义一个用于创建对象的接口。 在简单工厂模式中,一个工厂类处于对产品类实例化调用的中心位置上,它决定那一个产品类应当被实例化, 如同一个交通警察站在来往的车辆流中,决定放行那一个方向的车辆向那一个方向流动一样。 先来看看它的组成: 1) 工厂类角色:这是本模式的核心,含有一定的商业逻辑和判断逻辑。在java中它往往由一个具体类实现。 2) 抽象产品角色:它一般是具体产品继承的父类或者实现的接口。在java中由接口或者抽象类来实现。 3) 具体产品角色:工厂类所创建的对象就是此角色的实例。在java中由一个具体类实现。 三、工厂方法模式 工厂方法模式是简单工厂模式的进一步抽象化和推广,工厂方法模式里不再只由一个工厂类决定那一个产品类应当被实例化,这个决定被交给抽象工厂的子类去做。 来看下它的组成: 1)抽象工厂角色:这是工厂方法模式的核心,它与应用程序无关。是具体工厂角色必须实现的接口或者必须继承的父类。在java中它由抽象类或者接口来实现。 2)具体工厂角色:它含有和具体业务逻辑有关的代码。由应用程序调用以创建对应的具体产品的对象。 3)抽象产品角色:它是具体产品继承的父类或者是实现的接口。在java中一般有抽象类

23常用设计模式的UML

Factory模式 1.简单工厂模式,又称静态工厂模式 2.工厂方法模式 3. 抽象工厂模式 抽象工厂模式与工厂方法模式的最大区别在于,工厂方法模式针对的是一个产品等级结构;而抽象工厂模式则需要面对多个产品等级结构。

Singleton模式 要点: 类只能有一个实例 必须自行创建这个实例 必须自行向外界提供这个实例

Builder模式 Builder模式利用一个Director对象和ConcreteBuilder对象一个一个地建造出所有的零件,从而建造出完整的Product。Builder模式将产品的结构和产品的零件建造过程对客户端隐藏起来,把对建造过程进行指挥的责任和具体的建造者零件的责任分割开来,达到责任划分和封装的目的。 使用Builder模式的场合: 需要生成的产品对象有复杂的内部结构。每一个内部成分本身可以是对象,也可以紧紧是产品对象的一个组成部分。 需要生成的产品对象的属性相互以来。Builder模式可以强制实行一种分步骤进行的建造过程,因此,如果产品对象的一个属性必须在另一个属性被赋值之后才可以被赋值,使用建造模式便是一个很好的设计思想。 在对象创建过程中会使用到系统中的其他一些对象,这些对象在产品对象的创建过程中不易得到。

Prototype模式 通过给出一个原型对象来指明所要创建的对象的类型,然后用赋值这个原型对象的办法创建出更多同类型的对象。 Cloneable

Adapter模式 把一个类的接口变换成客户端所期待的另一种接口,从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作,也就是说把接口不同而功能相同或相近的多个接口加以转换。 1.类的Adapter模式的结构 2.对象的Adapter模式的结构 注意两种结构的区别:主要就是Adaptee和Adapter的关系,一个为继承关系,一个为依

uml中的关系

uml中的关系 1、关联 双向关联: C1-C2:指双方都知道对方的存在,都可以调用对方的公共属性和方法。 在GOF的设计模式书上是这样描述的:虽然在分析阶段这种关系是适用的,但我们觉得它对于描述设计模式内的类关系来说显得太抽象了,因为在设计阶段关联关系必须被映射为对象引用或指针。对象引用本身就是有向的,更适合表达我们所讨论的那种关系。所以这种关系在设计的时候比较少用到,关联一般都是有向的。 使用ROSE 生成的代码是这样的: class C1 ...{ public: C2* theC2; }; class C2 ...{ public: C1* theC1; }; 双向关联在代码的表现为双方都拥有对方的一个指针,当然也可以是引用或者是值。 单向关联: C3->C4:表示相识关系,指C3知道C4,C3可以调用C4的公共属性和方法。没有生命期的依赖。一般是表示为一种引用。 生成代码如下:

class C3 ...{ public: C4* theC4; }; class C4 ...{ }; 单向关联的代码就表现为C3有C4的指针,而C4对C3一无所知。 自身关联(反身关联): 自己引用自己,带着一个自己的引用。 代码如下: class C14 ...{ public: C14* theC14; }; 就是在自己的内部有着一个自身的引用。 2、聚合/组合 当类之间有整体-部分关系的时候,我们就可以使用组合或者聚合。

聚合:表示C9聚合C10,但是C10可以离开C9而独立存在(独立存在的意思是在某个应用的问题域中这个类的存在有意义。这句话怎么解,请看下面组合里的解释)。 代码如下: class C9 ...{ public: C10 theC10; }; class C10 ...{ }; 组合(也有人称为包容):一般是实心菱形加实线箭头表示,如上图所示,表示的是C8被C7包容,而且C8不能离开C7而独立存在。但这是视问题域而定的,例如在关心汽车的领域里,轮胎是一定要组合在汽车类中的,因为它离开了汽车就没有意义了。但是在卖轮胎的店铺业务里,就算轮胎离开了汽车,它也是有意义的,这就可以用聚合了。在《敏捷开发》中还说到,A组合B,则A需要知道B的生存周期,即可能A负责生成或者释放B,或者A通过某种途径知道B 的生成和释放。 他们的代码如下: class C7 ...{ public: C8 theC8; }; class C8 ...{ }; 可以看到,代码和聚合是一样的。具体如何区别,可能就只能用语义来区分了。 3、依赖

UML系统建模与分析设计(刁成嘉)课后习题整理

一、选择 1、封装是指把对象的(A)结合在一起,组成一个独立的对象。 A.属性和操作B.信息流C.消息和事件D.数据的集合2、封装是一种(C)技术,目的是使对象的生产者和使用者分离,使对象的定义和实现分开。 A.工程化B.系统维护C.信息隐蔽D.产生对象3、面向对象方法中的(D)机制是子类可以自动地拥有复制父类全部属性和操作。 A.约束B对象映射C.信息隐蔽D.继承 4、使得在多个类中能够定义同一个操作或属性名,并在每一个类中有不同的实现的一种方法(B)。 A.继承B.多态性 C.约束 D.接口 5、UML 的软件以(A)为中心,以系统体系结构为主线,采用循环、迭代、渐增的方式进行开发。 A. 用例 B.对象 C.类 D.程序 6、UML 的(B)模型图由类图、对象图、包图、构件图和配置图组成。 A. 用例 B. 静态 C. 动态 D. 系统 7、UML的(C)模型图由活动图、顺序图、状态图和合作图组成。 A. 用例 B. 静态 C. 动态 D.系统 8、UML的最终产物就是最后提交的可执行的软件系统和(D)。 A.用户手册B.类图C.动态图D.相应的软件文档资料 9、在UML的需求分析建模中,(B)模型图必须与用户反复交流并加以确认。 A. 配置B. 用例C.包D. 动态 10、可行性研究分析包括经济可行性分析、技术可行性分析和(B)。 A.风险可行性分析 B.法律可行性分析 C.资源可行性分析 D.效益可行性分析 11、UML的客户分析模型包括(A)模型、类图、对象图和活动图组成。 A.用例 B.分析 C.属性 D.系统 12、UML客户需求分析使用的CRC卡上“责任”一栏的内容主要描述类的(C)和操作。 A.对象成员 B.关联对象 C.属性 D.私有成员 13、UML客户需求分析产生的系统模型描述了系统的(D) A.状态 B.体系结构 C.静态模型 D.功能要求 14、在UML的需求分析建模中,用例模型必须与(B)反复交流并加以确认。 A.软件生产商 B.用户 C.软件开发人员 D.问题领域专家 15、在UML的需求分析建模中,对用例模型中的用例进行细化说明应使用(A)。 A.活动图 B.状态图 C.配置图 D.构件图 16、活动图中的分劈和同步接合图符是用来描述(A) A.多进程的并发处理行为 B.对象的时序 C.类的关系 D.系统体系结构框架

利用UML描述常见的几种设计模式

软件体系结构实验六 利用UML描述常见的几种设计模式 一:实验目的 掌握设计模式在软件设计中的作用,熟悉并了解一些常用的设计模式,进一步熟悉并巩固Rational Rose 2003与Visio2003工具的使用,熟悉并了解IBM Rational Software Architecture 6.0工具的建模方法。 二:实验准备 (1)熟悉利用UMLRose2003与Visio2003建模的方法 (2)熟悉并了解软件设计模式 (3)熟悉并了解IBM Rational Software Architecture 6.0的建模方法。 三:实验内容 设计面向对象软件比较困难,而设计可复用的面向对象软件就更加困难。你必须找到相关的对象,以适当的粒度将它们归类,再定义类的接口和继承层次建立对象之间的基本关系。在设计时,应该对手头的问题有针对性,同时对将来的问题和需求也要有足够的通用性,同时也希望避免重复设计或尽可能少做重复设计。 一个设计模式是软件开发中重复出现问题的解决方案;一种来源于具体问题形式的抽象,这种抽象在特定环境中出现;在给定的问题环境和约束条件下,对通用问题的重复解决方案;一种经过证明的、在给定条件下问题的有效的重复解决方案。它象一个“大金块”传递了解决方案的本质。(点石成金的方法)。经过多次成功使用,已经被证明的“最佳实践方法”;用文字、图表描述的方式来捕捉设计专家的智慧和经验,并把这些经验传递给新手。对通用设计问题的重复解决方案,对真实世界问题的实践的/具体的解决方案面向特定的问题环境权衡利弊之后得到的“最佳”解决方案,领域专家和设计老手的“杀手锏”,用文档的方式记录的最佳实践,在讨论问题的解决方案时,一种可交流的词汇,在使用(重用)、共享、构造软件系统中,一种有效地使用已有的智慧/经验/专家技术的方式。在面向对象的软件设计中,可以利用UML对设计进行建模,对设计模式的建模包括建立内部视图和外部视图 ①设计模式的内部视图是一组类图和一组交互图。 ②设计模式的外部视图是一个参数化协作,协作参数命名。是模式的用户必须绑定的元素。 本次实验要求同学们理解常见的组合模式(结构类型)、工厂模式(构造类型)、责任链模式(行为类型)。并能根据具体的案例,选择相应的设计模式,并根据该设计模式所定义的组成元素,组成元素之间的关连关系、约束关系,利用UML作出具体的设计。 在IBM Rational Software Architecture 6.0中,提供了Goff所总结的23种常见模式的模板,我们可以根据这些模板,实例化模板的参数,最后得到一个具体的某种模式的设计。图1-图3描述了组件的一个设计。

23种设计模式 UML 类图及对应示例代码(一)

23种设计模式UML 类图及对应示例代码(一) 1.DoFactory.GangOfFour.Abstract.Structural Abstract Factory:提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。 工厂模式:客户类和工厂类分开。消费者任何时候需要某种产品,只需向工厂请求即可。 消费者无须修改就可以接纳新产品。缺点是当产品修改时,工厂类也要做相应的修改。如:如何创建及如何向客户端提供。 Code 2.DoFactory.GangOfFour.Adapter.Structural Adapter:将一个类的接口转换成客户希望的另一个接口,使得原来由于接口不兼容而不能一起工作的那些类可以一起工作。 适配器(变压器)模式:把一个类的接口变换成客户端所期待的另一种接口,从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作。适配类可以根据参数返还一个合适的实例给客户端。

Code 3.DoFactory.GangOfFour.Bridge.Structural Bridge:将抽象部分与它的实现部分分离,使之可以独立变化。 桥梁模式:将抽象化与实现化脱耦,使得二者可以独立的变化,也就是说将他们之间的强关联变成弱关联,也就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系,从而使两者可以独立的变化。 Code 4.DoFactory.GangOfFour.Builder.Structural Builder:将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。

建造者模式:将产品的内部表象和产品的生成过程分割开来,从而使一个建造过程生成具有不同的内部表象的产品对象。建造模式使得产品内部表象可以独立的变化,客户不必知道产品内部组成的细节。建造模式可以强制实行一种分步骤进行的建造过程。 Code 5.DoFactory.GangOfFour.Chain.Structural Chain of Responsibility:为解除请求的发送者和接收者之间的耦合,而使多个对象有机会处 理这个请求。将这些请求连成一个链,并沿着这条链传递该请求,直到有个对象处理它。 责任链模式:在责任链模式中,很多对象由每一个对象对其下家的引用而接起来形成一条链。请求在这个链上传递,直到链上的某一个对象决定处理此请求。客户并不知道链上的哪一个对象最终处理这个请求,系统可以在不影响客户端的情况下动态的重新组织链和分配责任。处理者有两个选择:承担责任或者把责任推给下家。一个请求可以最终不被任何接收端对象所接受。

UML考试试题及答案

2008-2009第2学期《UML与面向对象方法学》复习题 二、单选题 1.( A )不是UML体系的组成部分。 A.应用领域B.规则C.基本构造块D.公共机制 2.在UML中,有四种事物,下面哪个不是( B )。 A.结构事物B.静态事物C.分组事物D.注释事物 3.以下(C )不是RUP中的优秀方法。 A.迭代的开发软件B.不断的验证软件质量 C.配置管理与变更管理D.支持正向与逆向工程 4.下面( D)属于UML中的动态视图。 A.类图B.用例图C.对象图D.状态图 5.在UML中,()把活动图中的活动划分为若干组,并将划分的组指定给对象,这些对象必须履行该组所包括的活动,它能够明确地表示哪些活动是由哪些对象完成的。A A.泳道B.同步条C.活动D.组合活动 6.用例之间有几种不同的关系,下列哪个不是他们之间可能的关系()。B A.include B.connect C.generalization D.extend 7.event表示对一个在时间和空间上占据一定位置的有意义的事情的规格说明,下面哪个不是事件的类型()。 C A.信号B.调用事件C.源事件D.时间事件 8.通常对象有很多属性,但对于外部对象来说某些属性应该不能被直接访问,下面哪个不是UML中的类成员访问限定性()。D A.public B.protected C.private D.friendly 9.在UML中,类之间的关系有一种关系称为关联,其中多重性用来描述类之间的对应关系,下面哪个不是其中之一()。A A.*....*B.0....* C.1....* D.0. (1) 10.关于包的描述,不正确的是()。B A.和其他建模元素一样,每个包必须有一个区别于其他包的名字 B.export使一个包中的元素可以单向访问另一个包中的元素 C.包的可见性分为public、protected、private D.包中可以包含其他元素,比如类、接口、组件、用例等等 11.Use Case用来描述系统在事件做出响应时所采取的行动。用例之间是具有相关性的。在一个“订单输入子系统” 中,创建新订单和更新订单都需要检查用户帐号是否正确。那么,用例“创建新订单”、“更新订单”与用例“检查用户帐号”之间是()关系。C A.aggregation B.extend C.include D.classification 12.UML中,用例图展示了外部Actor与系统所提供的用例之间的连接,UML中的外部Actor是指()。D A.人员B.单位C.人员和单位D.人员或外部系统 13.在UML中,用例可以使用()来描述。A A.活动图B.类图C.状态图D.协作图 14.下列关于UML叙述正确的是()。B A.UML是一种语言,语言的使用者不能对其进行扩展 B.UML是独立于软件开发过程的 C.UML仅是一组图形的集合 D.UML仅适用于系统的分析与设计阶段 15.UML中,对象行为是通过交互来实现的,是对象间为完成某一目的而进行的一系列消息交换。消息序列可用两种类来表示,分别是()。C

UML与设计模式需求分析与用例建模

《UML与设计模式》实验报告

角色之间的关系 (4)绘制用例之间的包含和扩展关系(给出UML用例图) 用例之间如果存在包含关系,则通过拖拽“UML用例”标签页中的“用” 图标来连接两个用例;用例之间如果存在扩展关系,则通过拖拽“UML 用例”标签页中的“扩展”图标来连接两个用例。 用例图作为一种UML模型元素,也必须用包来组织。本例中将两个用例图都放到了用例模型顶层包中,还可以用注释元素对用例图作简单说明。 结果:

用例之间的包含和扩展关系 (5)每个用例进行用例描述 用例增加课程 参与者管理员 操作流(1)管理员选择进入管理界面,用例开始 (2)系统提示输入管理员密码 (3)管理员输入密码 (4)系统检验密码 (5)进入管理界面,系统显示当前所建立全部课程信息 (6)管理选择添加课程,管理输入新课程信息 (7)系统验证是否与已有课程冲突 (8)系统添加新课程,并提示添加成功 (9)系统回到管理主界面,显示所有课程,用例结束。 用例修改课程 参与者管理员 操作流(1)管理员选择进入管理界面,用例开始 (2系统提示输入管理员密码 (3)管理员输入密码 (4)系统检验密码 (5)进入管理界面,系统显示当前所建立全部课程信息

思考题【思考问题】 1.绘制用例图的步骤是什么? 创建新的UML用例图 1.在“体系结构”菜单上,单击“新建关系图”。 2.在“模板”下,单击“UML 用例图”。 3.命名该关系图。 4.在“添加到建模项目”中,从您的解决方案中选择一个现有建模项目,或者选择“创建新的建模项目”,然后单击“确定” 绘制UML用例图 1.将“子系统”边界从工具箱拖到关系图中,它可以表示整个系统或其中的主要组件。 如果不希望描述系统或其组件支持哪些用例,用例图中可以不绘制系统边界。 根据需要,拖动系统的四角将其扩大。 对其适当地重命名。 2.将“参与者”从工具箱拖到关系图中(将其放在所有系统边界之外)。 参与者表示与您的系统进行交互的各类用户、组织和外部系统。 重命名这些参与者。例如:“顾客”、“餐馆”、“信用卡机构”。 3.将“用例”从工具箱拖到适当的系统中。 用例表示参与者在系统的帮助下所执行的活动。 使用参与者自身能够理解的名称重命名这些用例。不要使用与代码有关的名称。例如:“订餐”、“付餐费”、“送餐”。 从主要的事务(如“订餐”)开始,直到后面较小的事务(如“点菜”)为止。 将每个用例放入支持它的系统或主要子系统(忽略任何只与用户有关的外观模式或组件模式)。 可以在系统边界外绘制用例,以表明系统(可能在特定版本中)不支持该用例。 4.单击工具箱上的“关联”,然后单击用例,再单击该用例的参与者。以此方式将每个参与者与其用例相链接。

《UML建模与设计模式》试卷

XX 大学XX 学院2015—2016第一学期期末考试 《UML 建模与设计模式》考试试卷(A 卷) 一、 单项选择题(本大题共20 小题,每小题 3 分,共 60 分) 1、 面向对象方法中的( D )机制使子类可以自动地拥有父类全部属性和操作。 A 、 封装 B 、多态性 C 、 重载 D 、继承 2、 以下关于软件的说法,错误的是( A ) A 、软件就是程序。 B 、与硬件不同,软件不存在磨损和老化问题。 C 、大多数软件是根据客户需求定做的,而不是利用现成的部件组装成所需要的软件。 D 、软件是复杂的。 3、在进行( A )相关领域的应用开发时,不推荐使用UML 建模。 A 、数值计算 B 、工业系统 C 、信息系统 D 、软件系统 4、以下( D )不属于软件的生存期。 A 、维护 B 、需求分析 C 、软件设计 D 、意向 5、关于下图,说法错误的是( D ) A 、Reader 是类名 B 、borrowBook 是类的方法 C 、name 是类的属性 D 、name 是公有的 6、以下图中,表示“包”这种事物的是( D ) A 、 B 、 C 、 D 、 _________ ________________系______级________________________专业______班 姓名:_____________ 学号:____________________ -密-----------------封----------------线-------------------内-------------------不---------------------要-----------------------答-------------------题 -------------------------------------- ----------------------------------------------------------------------------------------------------------------------------

软件工程的种设计模式的UML类图

二十三种设计模式 0 引言 谈到设计模式,绝对应该一起来说说重构。重构给我们带来了什么?除了作为对遗留代码的改进的方法,另一大意义在于,可以让我们在写程序的时候可以不需事先考虑太多的代码组织问题,当然这其中也包括了应用模式的问题。尽管大多数开发者都已经养成了写代码前先从设计开始的习惯,但是,这种程度的设计,涉及到到大局、到总体架构、到主要的模块划分我觉得就够了。换句话说,这时就能写代码了。这就得益于重构的思想了。如果没有重构的思想,有希望获得非常高质量的代码,我们就不得不在开始写代码前考虑更多其实并非非常稳定的代码组织及设计模式的应用问题,那开发效率当然就大打折扣了。在重构和设计模式的合理应用之下,我们可以相对较早的开始写代码,并在功能尽早实现的同时,不断地通过重构和模式来改善我们的代码质量。所以,下面的章节中,在谈模式的同时,我也会谈谈关于常用的这些模式的重构成本的理解。重构成本越高意味着,在遇到类似的问题情形的时候,我们更应该提前考虑应用对应的设计模式,而重构成本比较低则说明,类似的情形下,完全可以先怎么方便,怎么快怎么写,哪怕代码不是很优雅也没关系,回头再重构也很容易。 1 创建型 思想:Factory Method的主要思想是使一个类的实例化延迟到其子类。 场景:典型的应用场景如:在某个系统开发的较早阶段,有某些类的实例化过程,实例化方式可能还不是很确定,或者实际实例化的对象(可能是需要对象的某个子类中的一个)不确定,或者比较容易变化。此时,如果直接将实例化过程写在某个函数中,那么一般就是if-else或select-case代码。如果,候选项的数目较少、类型基本确定,那么这样的if-else还是可以接受的,一旦情形变得复杂、不确定性增加,更甚至包含这个构造过程的函数所在的类包含几个甚至更多类似的函数时,这样的if-else代码就会变得比较不那么容易维护了。此时,应用本模式,可以将这种复杂情形隔离开,即将这类不确定的对象的实例化过程延迟到子类。 实现:该模式的典型实现方法就是将调用类定义为一个虚类,在调用类定义一个专门用于构造不确定的对象实例的虚函数,再将实际的对象实例化代码留到调用类的子类来实现。如果,被构造的对象比较复杂的话,同时可以将这个对象定义为可以继承、甚至虚类,再在不同的调用类的子类中按需返回被构造类的子类。 重构成本:低。该模式的重构成本实际上还与调用类自己的实例化方式相关。如果调用类是通过Factory 方式(此处“Factory方式”泛指对象的实例化通过Factory Method或Abstract Factory这样的相对独立出来的方式构造)构造的,那么,重构成本相对就会更低。否则,重构时可能除了增加调用类的

UML与设计模式 2015-2016第一学期试卷(A)

━ ━ ━ ━ ━ ━ ━ ━ ━ 装 ━ ━ ━ ━ ━ ━ ━ 订 ━ ━ ━ ━ ━ ━ ━ 线 ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━ ━━ ━ ━━ 防灾科技学院 2015 ~ 2016 学年 第一学期期末考试 UML 与设计模式 试卷(A ) 使用班级:1250411/412/413/414 答题时间:120分钟 注意事项:闭卷 一、单项选择题(本大题 10小题,每题 2分,共 20 分,请将答案填写在题后的答案填写处) 1 、描述如何将对象的创建和使用分离,可以使用( C )模式。 A 行为型 B 结构型 C 创建型 D 以上都可以 2、下面( A )图元哪个一个表示依赖关系。 A B C D 仔细审视下图,完成3-5题目 3、上图中的参与者有( A ) A 1 和4 B 2 和3 C 3 和5 D 5和6 4、上图中2和3之间是什么关系?( B ) A 平行 B 包含 C 继承 D 扩展 5、上图中5和6之间是什么关系?( D ) A 平行 B 包含 C 继承 D 扩展 6、下面关于接口的表述错误的是:( D ) A 当一个接口太大时,需要将它分割成一些更细小的接口 B 接口里不能有方法的实现体 C 每一个接口应该承担一种相对独立的角色,不干不该干的事,该干的事都要干 D 接口里可以有成员变量 7、一般来说,可采用( D )模式运用共享技术有效地支持大量细粒度对象的复用? A 外观 B 观察者 C 组合 D 享元

UML学习重点

考试内容涵盖了全部的上次测验题,所有的内容都在教材上能找到答案。另外文档中用红色部分都给出了提示。 单项选择题 1.有关构造型(stereotype)的理解,错误的是__D__。 A.类有一种构造型是<>,它用于表达参与者。 B.构造型本质上是一种类型的具体名称,代表该类的一种情形和类别,可以自己定义新的构造型。 C.用例间关联有两种常用构造型,其中<>用于对例外情况的用例细化建模。 D.<>是类的一种构造型,表示边界类,该类型的对象紧靠系统边界与外部交互。 2.有关类间的四种关系,说法正确的是_D___。 A.继承是耦合的一种。B.聚集是较弱的固定使用关系。 C.关联和聚集在程序上可区分。 D.聚集是特殊的关联。 3.UML分析的静态建模不包括__A__。 A.顺序图。 B.用例图。 C.类图。D.对象图。 4.对接口理解错误的是__A__。 A.JA V A语言中, 一个类继承接口时, 必须实现其全部的方法。 B.JA V A语言中, 接口能够继承一个接口而不加以实现。 C.接口是一种对外部可见的功能抽象声明, 某类继承一个接口, 表明该类实体具有该功能。 D.C++里的“纯”抽象类只有纯虚函数成员,等同于java里的interface。 5.对类间关联的理解,以下错误的是__B__。 A.类间关联表达的是一种对象间的消息。 B.复杂的关联可识别为一个类来表达。 C.关联的多重性在实际设计实现时,不允许出现M:N即多对多关系。 D.数据库概要设计常用到的E-R图中的联系和面向对象中的关联是同一个范畴的不同方面,一个用于启发发现实体及联系,最终形成关系表;一个用于表达名词对象间的联系。6.对于软件开发过程模型,对几种过程模型的描述正确的是_ A__。 A.螺旋模型是快速原型法和瀑布模型的结合。 B.XP忽视建模,去掉了用例分析等OO环节。 C.RUP强调用例驱动,测试驱动,集体拥有。 D.XP的首次迭代中,需求分析占了近30%的耗费,主要是因为用户故事理解在初次迭代耗费较大。 7.关于用例,理解错误的是__C__。 A.用例是scenario的抽象,是使用的例子和情况。 B.扩展用例对基本用例的可选附加增量行为。 C.包含用例指的是对顶层用例图的例外情况建模。 D.用例分析是从现实世界出发,从系统边界以外如何使用该系统的角度来观察系统。8.关于同步消息与异步消息,理解正确的是__C__。 A.同步消息是很快返回的,系统不会停顿,效率高,其返回值就是消息处理的结果。 B.同步消息没有返回值。 C.当很长时间来做消息处理时,同步消息浪费了CPU的时间。使用异步消息可以使

相关主题
相关文档 最新文档