July 2011 Master of Computer Application (MCA) Semester 2 MC0069 System Analysis & Design (SAD) 4 Credits

(Book ID: B0714)

Assignment Set 1 (60 Marks)

Answer all Questions
1. Describe the following: A) Modeling Simple Dependencies B) Modeling Single Inheritance C) Modeling Structural Relationships Answer: A) Modeling Simple Dependencies :- While entity types describe independent artifacts, relationship types describe meaningful associations between entity types. To be precise, the relationship type describes that entities of entity types participating in the relationship can build a meaningful association. The actual occurrence of the association between entities is called a relationship. It is important to understand that although we defined a relationship type, this does not mean that every pair of entities builds a relationship. A relationship type defines only that relationships can occur. An example of a relationship type is the Employee owns Product. In this example the relationship type is Owns. The relationship itself is: The Employee Joe Ward owns a Product, the yellow Telephone, with the Serial Number 320TS03880. Dependency refers to a situation in which a particular entity can not meaningfully exist without the existence of another entity as specified within a relationship. The entity type is dependent on another entity type when each entity of a dependent entity (subtype) depends on the existence of the corresponding parent entity in the super type. A mandatory dependency relationship has to be specified by explicitly defining the lower limit for cardinality that is not equal to 0 or by a fixed cardinality that is not equal to 0. B) Modeling Single Inheritance :- To understand OO you need to understand common object terminology. The critical terms to understand are summarized in Table 1. I present a much more detailed

Each question carries TEN marks

explanation of these terms in The Object Primer 3/e. Some of these concepts you will have seen before, and some of them you havent. Many OO concepts, such as encapsulation, coupling, and cohesion come from software engineering. These concepts are important because they underpin good OO design. The main point to be made here is that you do not want to deceive yourself just because you have seen some of these concepts before, it dont mean you were doing OO, it just means you were doing good design. While good design is a big part of object-orientation, there is still a lot more to it than that. Single Inheritance Represents is a, is like, and is kind of relationships. When class B inherits from class A it automatically has all of the attributes and operations that A implements (or inherits from other classes) Associations also exist between use cases in system use case models and are depicted using dashed lines with the UML stereotypes of <<extend>> or <<include>>, as you see in.It is also possible to model inheritance between use cases, something that is not shown in the diagram. The rectangle around the use cases is called the system boundary box and as the name suggests it delimits the scope of your system the use cases inside the rectangle represent the functionality that you intend to implement. C) Modeling Structural Relationships :- The class is the basic logical entity in the UML. It defines both the data and the behaviour of a structural unit. A class is a template or model from which instances or objects are created at run time. When we develop a logical model such as a structural hierarchy in UML we explicitly deal with classes. When we work with dynamic diagrams, such as sequence diagrams and collaborations, we work with objects or instances of classes and their inter-actions at run-time. The principal of data hiding or encapsulation is based on localisation of effect. A class has internal data elements that it is responsible for. Access to these data elements should be through the class's exposed behaviour or interface. Adherence to this principal results in more maintainable code.

2. Write and explain important relationships that are used in object-oriented modeling. Answer: A relationship is a general term covering the specific types of logical connections found on class and objects diagrams. A relationship references one or more related elements. There is no general notation for a relationship. In most cases the notation is some kind of a line connecting related elements. Specific subclasses of the relationship define their own notation. Instance Level Relationships AssociationAssociation is a relationship between classifiers which is used to show that instances of classifiers could be either linked to each other or combined logically or physically into some aggregation. Association defines the relationship between two or more classes in the System. These generally relates to the one object having instance or reference of another object inside it. Associations in UML can be implemented using following ways: 1) Multiplicity 2) Aggregation 3) Composition

Multiplicity in UML: Multiplicity indicates the no of instance of one class is linked to one instance of another class. The various multiplicity values are listed below: Notati on 1 0..1 * 0..* 1..* Description Only One Instance Zero or One Instance Many Instance Zero or Many Instance One or Many Instance

Aggregation: Aggregation represents the set of Main Classes that are dependent on Sub-Classes, the Main class cannot exist without Sub-Class but the Sub-Class can exists without the Main Class. Aggregation (shared aggregation) is a "weak" form of aggregation when part instance is independent of the composite: the same (shared) part could be included in several composites, and if composite is deleted, shared parts may still exist. Shared aggregation is shown as binary association decorated with a hollow diamond as a terminal adornment at the aggregate end of the association line. The diamond should be noticeably smaller than the diamond notation for N-ary associations.

Search Service has a Query Builder using shared aggregation Composition in UML: Composition represents the set of Main Classes that are dependent on Sub-Classes, the Main class cannot exists without Sub-Class and the Sub-Class cannot exists without the Main Class. The Sub-Class can represent only one composite relation with the Main class. Composition (composite aggregation) is a "strong" form of aggregation. Composition requirements/features listed in UML specification are: it is a whole/part relationship, it is binary association, part could be included in at most one composite (whole) at a time, and if a composite (whole) is deleted, all of its composite parts are "normally" deleted with it. Note, that UML does not define how, when and specific order in which parts of the composite are created. Also, in some cases a part can be removed from a composite before the composite is deleted, and so is not necessarily deleted as part of the composite. Composite aggregation is depicted as a binary association decorated with a filled black diamond at the aggregate (whole) end.

Folder could contain many files, while each File has exactly one Folder parent. If Folder is deleted, all contained Files are deleted as well.

When composition is used in domain models, both whole/part relationship as well as event of composite "deletion" should be interpreted figuratively, not necessarily as physical containment and/or termination. UML specification needs to be updated to explicitly allow this interpretation.

Class Level RelationshipsGeneralizationThe Generalization relationship indicates that one of the two related classes (the subclass) is considered to be a specialized form of the other (the super type) and superclass is considered as 'Generalization' of subclass. In practice, this means that any instance of the subtype is also an instance of the superclass. An exemplary tree of generalizations of this form is found in binomial nomenclature: human beings are a subclass of simian, which are a subclass of mammal, and so on. The relationship is most easily understood by the phrase 'an A is a B' (a human is a mammal, a mammal is an animal). The UML graphical representation of a Generalization is a hollow triangle shape on the superclass end of the line (or tree of lines) that connects it to one or more subtypes. The generalization relationship is also known as the inheritance or "is a" relationship. The superclass in the generalization relationship is also known as the "parent", superclass, base class, or base type. The subtype in the specialization relationship is also known as the "child", subclass, derived class, derived type, inheriting class, or inheriting type. Note that this relationship bears no resemblance to the biological parent/child relationship: the use of these terms is extremely common, but can be misleading. Generalization-Specialization relationship A is a type of B E. g. "an oak is a type of tree", "an automobile is a type of vehicle" Realization In UML modeling, a realization relationship is a relationship between two model elements, in which one model element (the client) realizes (implements or executes) the behavior that the other model element (the supplier) specifies. A realization is indicated by a dashed line with an unfilled arrowhead towards the supplier. Realizations can only be shown on class or component diagrams. A realization is a relationship between classes, interfaces, components, and packages that connects a client element with a supplier element. A realization relationship between classes and interfaces and between components and interfaces shows that the class realizes the operations offered by the interface. DependencyDependency relationship is used to show that some element or a set of elements depends on other model element(s), and on class diagrams is usually represented by usage dependency or abstraction. A dependency is rendered as a dashed arrow between elements. The element at the tail of the arrow (the client) depends on the model element at the arrowhead (the supplier). The arrow may be labeled with an optional stereotype and an optional name.

Data Access depends on Connection Pool It is possible to have a set of elements for the client or supplier. In this case, one or more arrows with their tails on the clients are connected to the tails of one or more arrows with their heads on the suppliers. A small dot can be placed on the junction if desired. A note on the dependency should be attached at the junction point. 3. Discuss the concept of dynamic type modeling and how is different from static type?

Answer: UML diagrams represent two different views of a system model: Static (or structural) view: emphasizes the static structure of the system using objects, attributes, operations and relationships. The structural view includes class diagrams and composite structure diagrams.. Dynamic (or behavioral) view: emphasizes the dynamic behavior of the system by showing collaborations among objects and changes to the internal states of objects. This view includes sequence diagrams, activity diagrams and state machine diagrams. Most object-oriented programming languages are statically typed, which means that the type of an object is bound at the time the object is created. Even so, that object will likely play different roles over time. This means that clients that use that object interact with the object through different sets of interfaces, representing interesting, possibly overlapping, sets of operations. Modeling the static nature of an object can be visualized in a class diagram. However, when you are modeling things like business objects, which naturally change their roles throughout a workflow; its sometimes useful to explicitly model the dynamic nature of that objects type. In these circumstances, an object can gain and lose types during its life. To model a dynamic type, . Specify the different possible types of that object by rendering each type as a class stereotyped as type (if the abstraction requires structure and behavior) or as interface (if the abstraction requires only behavior). Model all the roles the class of the object may take on at any point in time. You can do so in two ways: 1. First, in a class diagram, explicitly type each role that the class plays in its association with other classes. Doing this specifies the face instances of that class put on in the context of the associated object. 2. Second, also in a class diagram, specify the class-to-type relationships using generalization. In an interaction diagram, properly render each instance of the dynamically typed class. Display the role of the instance in brackets below the objects name. To show the change in role of an object, render the object once for each roie it plays in the interaction, and connect these objects with a message stereotyped as become. For example, Figure 4-15 shows the roles that instances of the class Person might play in the context of a human resources system.

Figure 4.15: Modeling Static Types This diagram specifies that instances of the Person class may be any of the three types namely. Candidate, Employee, or Retiree Figure 4-16 shows the dynamic nature of a persons type. In this fragment of an interaction diagram, p (the Person object) changes its role from Candidate to Employee.

Figure 4.16: Modeling Dynamic Types 4. What are the important factors that need to be considered to model a system from different views? Modeling Different Views of a System:

When we model as system from different views, we are in effect construction our system simultaneously from multiple dimensions. By choosing the right set of views, we set up a process that forces us to ask good questions about our system and to expose risks that need to be attacked. If we do a poor job of choosing these views or if we focus on one view at the expense of all others, we run the risk of hiding issues and deferring problems that will eventually destroy any chance of success. To model a system from different views; - Decide which views we need to best express the architecture of our system and to expose the technical risks of our project. The five views: Use case, Design, Process, Implementation and Deployment. - For each of these views, decide which artifacts we need to create to capture has essential details of that view. - As part of our process planning, decide which of these diagrams we will want to put under some sort of formal or semi forma control. These are the diagrams for which we will want to schedule reviews and to preserve as documentation for the project. - Allow room for diagrams that are thrown away. Such transitory diagrams are still useful for exploring the implications of your decisions and for experimenting with changes. Example: If we are modeling a complex, distributed system, we will need to employ the full range of the UMLs diagrams in order to express the architecture of our system and the technical risks to our project as: Use case view: Use case diagrams, Activity diagrams for behavioral modeling Design view: Class diagrams for structural modeling, interaction diagram, statechart diagrams Process view: Class diagrams for structural modeling, Interaction diagram for behavioral modeling Implementation view: component diagrams Deployment view: Deployment diagrams 5. Explain the different components of states with reference to state machines Answer: State Machines: A state machines is a behavior that specifies the sequences of states an object goes through during its lifetime in response to events, together with its responses to those events. We use state machines to model the dynamic aspects of a system. The state of an object is a condition or situation during the life of an object during which it satisfies some condition, performs some activity, or waits for some events. An event is the specification of a significant occurrence that has a location in time and space. In the context of state machines, an event is an occurrence of a stimulus that can trigger a state transition. A transition is a relationship between two states indicating that an object is the first state will perform certain actions and enter the second state when a specified nonatomic execution within a state machine. A action is an executable atomic computation that results in a change in state of the model or the return of a value. A state has several parts: Name- A textual string that distinguishes the state from other states; a state may be anonymous, meaning that it has no name. Entry/Exit actions-Actions executed on entering and ending the state, respectively. Internal transitions- Transitions that are handled without causing a change in state. Substates- The nested structure of a state, involving disjoint or concurrent substates. Deferred event- A list of events that are not handled in that state but, rather, are postponed and queued for handling by the object in another state. 6. Explain the different stages to model a flow of control Answer: Modeling a Flow of Control: To model a flow of control - Set the context for the interaction, whether it is the system as a whole, a class, or an individual operation.

Set the stage for the interaction by identifying which objects play a role. Set their initial properties, including their attribute values, state, and role. If your model emphasizes the structural organization of these objects, identify the links that connect them, relevant to the paths of communication that take place in this interaction. Specify the nature of the links using the UMLs standard stereotypes and constraints, as necessary. In time order, specify the messages that pass from object to object. As necessary, distinguish the different kinds of messages, include parameter and return values to convey the necessary detail of this interaction. Also to convey the necessary detail of this interaction, adorn each object at every moment in time with its state and role. For example: Figure shows a set of objects that interact in the context of a publish and subscribe mechanism. This figure includes three objects: p(a StockQuotePubliser), s1 and s2(both instances of StockQuoteSubscriber). This figure is an example of a sequence diagram, which emphasizes the time order of messages.

P:stockQuotePublisher

S1:StockQuoteSubscriber
Attach(s1)

S2:StockQuoteSubscriber

Attach(s2)

Notify() Update() Getstate()

Update() Getstate() Figure: Flow of control by Time

July 2011 Master of Computer Application (MCA) Semester 2 MC0069 System Analysis & Design (SAD) 4 Credits (Book ID: B0714) Assignment Set 2 (60 Marks) Answer all Questions 1. A) B) C) Describe the following with suitable examples: Modeling the realization of a Use case Modeling the realization of an operation Modeling a Mechanism Each question carries TEN marks

Answer: A) Modeling the realization of a Use case :- A relationship is a general term covering the specific types of logical connections found on class and object diagrams. UML shows the following relationships: In UML modeling, a realization relationship is a relationship between two model elements, in which one model element (the client) realizes (implements or executes) the behavior that the other model element (the supplier) specifies. A realization is indicated by a dashed line with a unfilled arrowhead towards the supplier. Realizations can only be shown on class or component diagrams. A realization is a relationship between classes, interfaces, components, and packages that connects a client element with a supplier element. A realization relationship between classes and interfaces and between components and interfaces shows that the class realizes the operations offered by the interface. B) Modeling the realization of an operation :- The class diagram is the main building block in object oriented modelling. It is used both for general conceptual modelling of the systematics of the application, and for detailed modelling translating the models into programming code. The classes in a class diagram represent both the main objects and or interactions in the application and the objects to be programmed. In the class diagram these classes are represented with boxes which contain three parts: A class with three sections. The upper part holds the name of the class The middle part contains the attributes of the class The bottom part gives the methods or operations the class can take or undertake In the system design of a system, a number of classes are identified and grouped together in a class diagram which helps to determine the statical relations between those objects. With detailed modeling, the classes of the conceptual design are often split in a number of subclasses. In order to further describe the behavior of systems, these class diagrams can be complemented by state diagram or UML state machine. Also instead of class diagrams Object role modeling can be used if you just want to model the classes and their relationships. C) Modeling a Mechanism :- It is important to distinguish between the UML model and the set of diagrams of a system. A diagram is a partial graphic representation of a system's model. The model also contains documentation that drive the model elements and diagrams (such as written use cases). UML diagrams represent two different views of a system model: Static (or structural) view: emphasizes the static structure of the system using objects, attributes, operations and relationships. The structural view includes class diagrams and composite structure diagrams. Dynamic (or behavioral) view: emphasizes the dynamic behavior of the system by showing collaborations among objects and changes to the internal states of objects. This view includes sequence diagrams, activity diagrams and state machine diagrams. UML models can be exchanged among UML tools by using the XMI interchange format.

2. Discuss the concept of Association with the help of example Answer: Association Association defines the relationship between two or more classes in the System. These generally relates to the one object having instance or reference of another object inside it.

Class diagram example of association between two classes An Association represents a family of links. Binary associations (with two ends) are normally represented as a line, with each end connected to a class box. Higher order associations can be drawn with more than two ends. In such cases, the ends are connected to a central diamond. An association can be named, and the ends of an association can be adorned with role names, ownership indicators, multiplicity, visibility, and other properties. There are five different types of association. Bidirectional and uni-directional associations are the most common ones. For instance, a flight class is associated with a plane class bi-directionally. Associations can only be shown on class diagrams. Association represents the static relationship shared among the objects of two classes. Example: "department offers courses", is an association relation. 3. Describe the following: A) State machines B) Advanced States and Transitions Answer: State machines: UML state machine diagrams depict the various states that an object may be in and the transitions between those states. In fact, in other modeling languages, it is common for this type of a diagram to be called a state-transition diagram or even simply a state diagram. A state represents a stage in the behavior pattern of an object, and like UML activity diagrams it is possible to have initial states and final states. An initial state, also called a creation state, is the one that an object is in when it is first created, whereas a final state is one in which no transitions lead out of. A transition is a progression from one state to another and will be triggered by an event that is either internal or external to the object.

Advanced States :-Advanced state diagram is a type of diagram used in computer science and related fields to describe the behavior of systems. State diagrams require that the system described is composed of a finite number of states; sometimes, this is indeed the case, while at other times this is a reasonable abstraction. There are many forms of state diagrams, which differ slightly and have different semantics. Advanced State diagrams are used to give an abstract description of the behavior of a system. This behavior is analyzed and represented in series of events, that could occur in one or more possible states. Hereby "each diagram usually represents objects of a single class and track the different states of its objects through the system". a flowchart to an assembly line in manufacturing because the flowchart describes the progression of some task from beginning to end (e.g., transforming source code input into object code output by a compiler). A state machine generally has no notion of such a progression. The door state machine shown at the top of this article, for example, is not in a more advanced stage when it is in the "closed" state, compared to being in the "opened" state; it simply reacts differently to the open/close events. A state in a state machine is an efficient way of specifying a particular behavior, rather than a stage of processing. Transitions :- A transition is a progression from one state to another and will be triggered by an event that is either internal or external to the entity being modeled. For a class, transitions are typically the result of the invocation of an operation that causes an important change in state, although it is important to understand that not all method invocations will result in transitions. An action is something, in the case of a class it is an operation that is invoked by/on the entity being modeled. 1. 2. 3. 4. 5. 6. 7. 8. Name Software Actions Using Implementation Language Naming Conventions Name Actor Actions Using Prose Indicate Entry Actions Only When Applicable For All Entry Transitions Indicate Exit Actions Only When Applicable For All Exit Transitions Model Recursive Transitions Only When You Want to Exit and Re-Enter the State Name Transition Events in Past Tense Place Transition Labels Near The Source State Place Transitions Labels Based on Transition Direction. To make it easier to identify which label goes with a transition, place transition labels according to the following heuristics: Above transition lines going left-to-right Below transition lines going right-to-left Right of transition lines going down Left of transition lines going up

4. Define stereotype, tagged value and constraint in detail. Answer: Stereotype is a profile class which defines how an existing metaclass may be extended as part of a profile. It enables the use of a platform or domain specific terminology or notation in place of, or in addition to, the ones used for the extended metaclass. A stereotype cannot be used by itself, but must always be used with one of the metaclasses it extends. Stereotype cannot be extended by another stereotype. A stereotype uses the same notation as a class, with the keyword stereotype shown before or above the name of the stereotype. Stereotype names should not clash with keyword names for the extended model element.

Servlet Stereotype extends Component. Stereotype can change the graphical appearance of the extended model element by using attached icons represented by Image class.

Stereotype Servlet with attached custom icon.

Actor is extended by stereotype Web Client with attached custom icon. Because stereotype is a class, it may have properties. Properties of a stereotype are referred to as tag definitions. When a stereotype is applied to a model element, the values of the properties are referred to as tagged values.

Device extended by Server stereotype with tag definitions and custom icon. Tagged Value: UML 1.x defined tagged value as one of UML extensibility mechanisms permitting arbitrary information (which could not be expressed by UML) to be attached to models. Tagged value is a keyword-value pair that may be attached to any kind of model element. The keyword is called a tag. Each tag represents a particular kind of property applicable to one or many kinds of model elements. Both the tag and the value are usually encoded as strings though UML tool allow to use other data types for values. Tagged value specification in UML 1.x has the form name = value where name is the name of a tag or metamodel attribute and value is an arbitrary string that denotes its value. For example, {author="Joe Smith", deadline=31-March-1997, status=analysis} Boolean tags frequently have the form isQuality, where quality is some condition that may be true or false. In these cases, the form "quality" may usually appear by itself, without a value and defaulting to true. For example, {abstract} is the same as {isAbstract=true}. To specify a value of false, omit the name completely. Tags of other types require explicit values. Tagged value (as well as metamodel attribute) is displayed as a comma delimited sequence of properties inside a pair of curly braces "{" and "}".

Stereotype Computer applied using "traditional" tag values notation. In UML 1.3 tagged values could extend a model element without requiring the presence of a stereotype. In UML 1.4, this capability, although still supported, was deprecated, to be used only for backward compatibility reasons. Since UML 2.0, a tagged value can only be represented as an attribute defined on a stereotype. Therefore, a model element must be extended by a stereotype in order to be extended by tagged values.

To support compatibility with the UML 1.3 some UML tools can automatically define a stereotype to which "unattached" attributes (tagged values) will be attached. Tag values could be shown in class compartment under stereotype name. An additional compartment is required for each applied stereotype whose values are to be displayed. Each such compartment is headed by the name of the applied stereotype in guillemets.

Stereotype Computer applied with tag values in compartment Tag values could be shown in attached comment under stereotype name.

Stereotype Computer applied with tag values in comment note When displayed in compartments or in a comment symbol, each name-value pair should appear on a separate line. Constraint: A constraint is used to express a condition, restriction or assertion related to some of the semantics of a model element. Constraint is a condition which must evaluate to true by a correct design of the system. For example, bank account balance constraint could be expressed as: {balance >= 0} Constraint in UML is usually written in curly braces using any computer or natural language including English, so that it might look as: {account balance is positive} UML prefers OCL as constraint language. 5. What are the important factors that need to be considered to model a system from different views. Answer: Modeling Different Views of a System:When you model a system from different views, you are in effect constructing your system simultaneously from multiple dimensions. By choosing the right set of views, you set up a process that forces you to ask good questions about your system and to expose risks that need to be attacked. If you do a poor job of choosing these views or if you focus on one view at the expense of all others, you run the risk of hiding issues and deferring problems that will eventually destroy any chance of success. To model u system from different views, Decide which views you need to best express the architecture of your system and to expose the technical risks to your project. The five views of an architecture described earlier are a good starting point. For each of these views, decide which artifacts you need to create to capture the essential details of that view. For the most part, these artifacts will consist of various UML diagrams. As part of your process planning, decide which of these diagrams youll want to put under some sort of formal or semi formal control. These are the diagrams for which youll want to schedule reviews and to preserve as documentation for the project. Allow room for diagrams that are thrown away. Such transitory diagrams are still useful for exploring the implications of your decisions and for experimenting with changes.

For example, if you are modeling a simple monolithic application that runs on a single machine, you might need only the following handful of diagrams. Use case view Use ease diagrams Design view Class diagrams (for structural modeling) Interaction diagrams (for behavioral modeling) Process view None required Implementation view None required Deployment view None required If yours is a reactive system or if it focuses on process flow, youll probably want to include statechart diagrams and activity diagrams, respectively, to model your systems behavior. Similarly, if yours is a client/server system, youll probably want to include component diagrams and deployment diagrams to model the physical details of your system. Finally, if you are modeling a complex, distributed system, youll need to employ the full range of the UMLs diagrams in order to express the architecture of your system and the technical risks to your project, as in the following. Use case view Use case diagrams Activity diagrams (for behavioral modeling) Design view Class diagrams (for structural modeling) Interaction diagrams (for behavioral modeling) Statechart diagrams (for behavioral modeling) Process view Class diagrams (for structural modeling) Interaction diagrams (for behavioral modeling) Implementation view Component diagrams Deployment view Deployment diagrams 6. What are the necessary considerations to be taken care to forward engineer a class diagram? Answer: Forward engineering is the process of transforming a model into code through a mapping to an implementation language. Forward engineering results in a loss of information, because models written in the UML are semantically richer than any current object oriented programming language. In fact, this is a major reason why you need models in addition to code. Structural features, such as collaborations, and behavioral features, such as interactions, can be visualized clearly in the UML, but not so clearly from raw code. To forward engineer a class diagram. . Identify the rules for mapping to your implementation language or languages of choice. This is something youll want to do for your project or your organization as a whole. Depending on the semantics of the languages you choose, you may have to constrain your use of certain UML features. For example, the UML permits you to model multiple inheritance, but Smalltalk permits only single inheritance. You can either choose to prohibit developers from modeling with multiple inheritances (which makes your models language dependent) or develop idioms that transform these richer features into the implementation language (which makes the mapping more complex). Use tagged values to specify your target language. You can do this at the level of individual classes if you need precise control. You can also do so at a higher level, such as with collaborations or packages. Use tools to forward engineer your models. Figure 6-3 illustrates a simple class diagram specifying an instantiation of the chain of responsibility pattern. This particular instantiation involves three classes: Client, EventHandler, and GUIEventHandler. Client and EventHandler are shown as abstract classes, whereas GUI EventHandler is concrete. EventHandler has the usual operation expected of this pattern (handleRequest), although two private attributes have been added for this instantiation.

Figure : Forward Engineering