MC0069 – System Analysis & Design (SAD)Book ID: B0714Set-1

1. Explain the different kinds of classifiers to help you model in UML.

Ans:1A classifier describes a set of instances that have common behavioral and structural features.Types of UML Classifiers:

Class Component Datatype Interface Node Signal Subsystem Use Case

Class-A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics.A class is shown as a solid-outline rectangle containing the class name, and optionally with compartments separated by horizontal lines containing features or other members of the classifier. As class is the most widely used classifier, there is no need to add the "class" keyword in guillemets above the class name. Class name should be centered and in bold face, with the first letter of class name capitalized (if the character set supports upper case).

Class Customer - details suppressed Features of a class are attributes and operations. When class is shown with three compartments, the middle compartment holds a list of attributes and the bottom compartment holds a list of operations. Attributes and operations should be left justified in plain face, with the first letter of the names in lower case.

Class Search Service - analysis level details.

MC0069 – System Analysis & Design (SAD)Book ID: B0714Component-A component is a structured class representing a modular part of a system with encapsulated content and whose manifestation is replaceable within its environment. A component has its behavior defined in terms of provided interfaces and required interfaces (potentially exposed via ports). Component serves as a type whose conformance is defined by these provided and required interfaces (encompassing both their static as well as dynamic semantics). One component may therefore be substituted by another only if the two are type conformant. Larger pieces of a system’s functionality may be assembled by reusing components as parts in an encompassing component or assembly of components, and wiring together their required and provided interfaces.A component is shown as a classifier rectangle with the keyword «component».

Component WeatherService

Datatype-A type whose values have no identity, including primitive built-in type(such as numbers and strings), as well as enumeration types(such as Boolean).

Interface-An interface is a classifier that declares of a set of coherent public features and obligations. An interface specifies a contract. Any instance of a classifier that realizes (implements) the interface must fulfill that contract and thus provides services described by contract. An interface may be shown using a rectangle symbol with the keyword «interface» preceding the name.

Interface SiteSearch

Node-A physical element that exists at run time and that represent a computational resource, generally having at least some memory and often processing capability.

Signal-A signal is a classifier which specifies communication of send request instances between objects. The receiving object handles the received request instances as specified by its receptions. The data carried by a send request (which was passed to it by the send invocation occurrence that caused that request) are represented as attributes of the signal. A signal is defined independently of the classifiers handling the signal occurrence.

MC0069 – System Analysis & Design (SAD)Book ID: B0714A signal triggers a reaction in the receiver in an asynchronous way and without a reply. The sender of a signal will not block waiting for a reply but continue execution immediately. By declaring a reception associated to a given signal, a classifier specifies that its instances will be able to receive that signal, or a subtype thereof, and will respond to it with the designated behavior. A signal is depicted by a classifier symbol with the keyword «signal».

The Notify Customer signal

Subsystem-A grouping of elements of which some constitute a specification of the behavior offered by the other contained elements.

Use Case-A use case is behavioral classifier which specifies behavior of a subject (system under construction or consideration) by describing a set of sequences of actions performed by the system to yield an observable result of some value to one or more actors or other stakeholders of the system. In other words, each use case describes a unit of complete and useful functionality that the subject provides to its users. This functionality, which is initiated by an actor, must always be completed for the use case to complete. It is considered complete if after its execution the subject will be in a state in which no further inputs or actions are expected and the use case can be either initiated again or is in an error state. Each use case must have a name. Examples of use case names: Place Order Update Subscription Transfer Funds Hire Employee Use case is usually shown as an ellipse containing the name of the use case.

User Registration use case

Name of the use case could also be placed below the ellipse.

MC0069 – System Analysis & Design (SAD)Book ID: B0714

Transfer Funds use case

2. Write and explain important relationships that are used in object-oriented modeling.

Ans:2A 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 -Association-Association 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) Multiplicity2) Aggregation3) 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:

Notation

Description

1 Only One Instance

0..1 Zero or One Instance

* Many Instance

0..* Zero or Many Instance

1..* One or Many Instance

MC0069 – System Analysis & Design (SAD)Book ID: B0714Aggregation: 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.

MC0069 – System Analysis & Design (SAD)Book ID: B0714When 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 Relationships-Generalization-

The 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.

MC0069 – System Analysis & Design (SAD)Book ID: B0714A 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.

Dependency-

Dependency 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?

Ans:3

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; it’s sometimes useful to explicitly model the dynamic nature of that object’s type. In these circumstances, an object can gain and lose types during its life.

MC0069 – System Analysis & Design (SAD)Book ID: B0714

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 object’s 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 person’s type. In this fragment of an interaction diagram, p (the Person object) changes its role from Candidate to Employee.

MC0069 – System Analysis & Design (SAD)Book ID: B0714

Figure 4.16: Modeling Dynamic Types

4. What are the important factors that need to be considered to model a system from different views?

Ans:4

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 UML’s 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 modelingDesign view: Class diagrams for structural modeling, interaction diagram, statechart diagramsProcess view: Class diagrams for structural modeling, Interaction diagram for behavioral modelingImplementation view: component diagramsDeployment view: Deployment diagrams

MC0069 – System Analysis & Design (SAD)Book ID: B07145. Explain the different components of states with reference to state machines.

Ans:5State 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.

Ans:6Modeling 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 UML’s 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

MC0069 – System Analysis & Design (SAD)Book ID: B0714

StockQuoteSubscriber). This figure is an example of a sequence diagram, which emphasizes the time order of messages.

Attaché(s1)

Attach(s2) Notify()

Update()

Getstate()

Update()

Getstate()

Figure: Flow of control by Time

P:stockQuotePublisher S1:StockQuoteSubscriber S2:StockQuoteSubscriber

MC0069 – System Analysis & Design (SAD)Book ID: B0714

Set-21. Explain the role of realization with an example.

Ans:1RealizationA 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.

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.

MC0069 – System Analysis & Design (SAD)Book ID: B0714

2. Discuss the concept of Association with the help of example.

Ans:2AssociationAssociation 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. Bi-directional 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

Ans:3State 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.

MC0069 – System Analysis & Design (SAD)Book ID: B0714

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.

MC0069 – System Analysis & Design (SAD)Book ID: B0714

1. Name Software Actions Using Implementation Language Naming Conventions 2. Name Actor Actions Using Prose 3. Indicate Entry Actions Only When Applicable For All Entry Transitions 4. Indicate Exit Actions Only When Applicable For All Exit Transitions 5. Model Recursive Transitions Only When You Want to Exit and Re-Enter the State 6. Name Transition Events in Past Tense 7. Place Transition Labels Near The Source State 8. 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.

Ans:4

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.

MC0069 – System Analysis & Design (SAD)Book ID: B0714

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.

MC0069 – System Analysis & Design (SAD)Book ID: B0714The 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 = valuewhere 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 appliedusing "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.

MC0069 – System Analysis & Design (SAD)Book ID: B0714

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.

MC0069 – System Analysis & Design (SAD)Book ID: B07145. What are the important factors that need to be considered to model a system from

different views.

Ans:5

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 you’ll want to put under some sort of formal or semi formal control. These are the diagrams for which you’ll 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

MC0069 – System Analysis & Design (SAD)Book ID: B0714· Deployment view None required

If yours is a reactive system or if it focuses on process flow, you’ll probably want to include statechart diagrams and activity diagrams, respectively, to model your system’s behavior.

Similarly, if yours is a client/server system, you’ll 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, you’ll need to employ the full range of the UML’s 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

MC0069 – System Analysis & Design (SAD)Book ID: B07146. What are the necessary considerations to be taken care to forward engineer a class

diagram?

Ans:6

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 you’ll 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.

MC0069 – System Analysis & Design (SAD)Book ID: B0714

Figure : Forward Engineering

.

MC0069 – System Analysis & Design (SAD)Book ID: B0714