July 2011 Master of Computer Science (MSCCS) Semester 1 MC0069 System Analysis & Design (SAD) 4 Credits (Book

ook ID: B0714) Assignment Set 2 (60 Marks)

Answer: 1(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 objects 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. Answer: 1(b) Modeling the realization of an operation: - The class diagram is the main building block in object oriented modeling. It is used both for general conceptual modeling of the systematic of the application, and for detailed modeling 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 as per given below. 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 statically 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. Answer: 1(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 drives the model elements and diagrams (such as written use cases). UML diagrams represent two different views of a system model:

Page 1 of 8

Roll No. 521126647

July 2011 Master of Computer Science (MSCCS) Semester 1 MC0069 System Analysis & Design (SAD) 4 Credits (Book ID: B0714) Assignment Set 2 (60 Marks)
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.

tools by using the XMI interchange format.

Q.2) Discuss the concept of Association with the help of example Associations An association is a structural relationship that specifies that objects of one thing are connected to objects of another. Given an association connecting two classes, you can relate objects of one class to objects of the other class. It's quite legal to have both ends of an association circle back to the same class. This means that, given an object of the class, you can link to other objects of the same class. An association that connects exactly two classes is called a binary association. Although it's not as common, you can have associations that connect more than two classes; these are called n-any associations. Graphically, an association is rendered as a solid line connecting the same or different classes. Use associations when you want to show structural relationships. Beyond this basic form, there are four adornments that apply to associations. Name: An association can have a name, and you use that name to describe the nature of the relationship. So that there is no ambiguity about its meaning, you can give a direction to the name by providing a direction triangle those points in the direction you intend to read the name, as shown in Figure. Although an association may have a name, you typically don't need to include one if you explicitly provide end names for the association. If you have more than one association connecting the same classes, it is necessary to use either association names or association end names to distinguish them. If an association has more than one end on the same class, it is necessary to use association end names to distinguish the ends. If there is only one association between a pair of classes, some modelers omit the names, but it is better to provide them to make the purpose of the association clear. Role: When a class participates in an association, it has a specific role that it plays in that relationship; a role is just the face the class at the far end of the association presents to the class at the near end of the association. You can explicitly name the role a class plays in an association. The role played by an end of an association is called an end name (in UML1, it was called a role name). In Figure the class Person playing the role of employee is associated with the class Company playing the role of employer. The same class can play the same or different roles in other associations. An attribute may be regarded as a one-way

Page 2 of 8

Roll No. 521126647

July 2011 Master of Computer Science (MSCCS) Semester 1 MC0069 System Analysis & Design (SAD) 4 Credits (Book ID: B0714) Assignment Set 2 (60 Marks)
association owned by a class. The attribute name corresponds to the end name on the association end away from the class. Multiplicity: An association represents a structural relationship among objects. In many modeling situations, it's important for you to state how many objects may be connected across an instance of an association. This "how many" is called the multiplicity of an association's role. It represents a range of integers specifying the possible size of the set of related objects. It is written as an expression with a minimum and maximum value, which may be the same; two dots are used to separate the minimum and maximum values. When you state a multiplicity at the far end of an association, you are specifying that, for each object of the class at the near end, how many objects at the near end may exist. The number of objects must be in the given range. You can show a multiplicity of exactly one (1), zero or one (0..1), many (0..*), or one or more (1..*). You can give an integer range (such as 2..5). You can even state an exact number (for example, 3, which is equivalent to 3..3). For example, in Figure, each company object has as employee one or more person objects (multiplicity 1..*); each person object has as employer zero or more company objects (multiplicity *, which is equivalent to 0..*). Aggregation: A plain association between two classes represents a structural relationship between peers, meaning that both classes are conceptually at the same level, no one more important than the other. Sometimes you will want to model a "whole/part" relationship, in which one class represents a larger thing (the "whole"), which consists of smaller things (the "parts"). This kind of relationship is called aggregation, which represents a "has-a" relationship, meaning that an object of the whole has objects of the part. Aggregation is really just a special kind of association and is specified by adorning a plain association with an unfilled diamond at the whole end, as shown in Figure The meaning of this simple form of aggregation is entirely conceptual. The open diamond distinguishes the "whole" from the "part," no more, no less. This means that simple aggregation does not change the meaning of navigation across the association between the whole and its parts, nor does it link the lifetimes of the whole and its parts. Q.3) Describe the following: a. State machines b. Advanced States and Transitions Answer: 3 (a) 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

Page 3 of 8

Roll No. 521126647

July 2011 Master of Computer Science (MSCCS) Semester 1 MC0069 System Analysis & Design (SAD) 4 Credits (Book ID: B0714) Assignment Set 2 (60 Marks) 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.

Answer: 3 (b) 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, which could occur in one or more possible states. Hereby "each diagram usually represents objects of a single class and tracks 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. Q.4) Define stereotype, tagged value and constraint in detail. Answer: 4) Stereotypes The UML provides a language for structural things, behavioral things, grouping things, and notational things. These four basic kinds of things address the overwhelming majority of the systems you'll need to model. However, sometimes you'll want to introduce new things that speak the vocabulary of your domain and look like primitive building blocks. A stereotype is an extension of the vocabulary of the UML, allowing you to create new kinds of building blocks similar to existing ones but specific to your problem. Graphically, a stereotype is

Page 4 of 8

Roll No. 521126647

July 2011 Master of Computer Science (MSCCS) Semester 1 MC0069 System Analysis & Design (SAD) 4 Credits (Book ID: B0714) Assignment Set 2 (60 Marks)
rendered as a name enclosed by guillemets (French quotation marks of the form ), placed above the name of another element. A stereotype is not the same as a parent class in a parent/child generalization relationship. Rather, you can think of a stereotype as a metatype (a type that defines other types), because each one creates the equivalent of a new class in the UML's metamodel. For example, if you are modeling a business process, you'll want to introduce things like workers, documents, and policies. Similarly, if you are following a development process, such as the Rational Unified Process, you'll want to model using boundary, control, and entity classes. This is where the real value of stereotypes comes in. When you stereotype an element such as a node or a class, you are in effect extending the UML by creating a new building block just like an existing one but with its own special modeling properties (each stereotype may provide its own set of tagged values), semantics (each stereotype may provide its own constraints), and notation (each stereotype may provide its own icon). In its simplest form, a stereotype is rendered as a name enclosed by guillemets (for example, name) and placed above the name of another element. As a visual cue, you may define an icon for the stereotype and render that icon to the right of the name (if you are using the basic notation for the element) or use that icon as the basic symbol for the stereotyped item. All three of these approaches are illustrated in Figure. Tagged Values Everything in the UML has its own set of properties: classes have names, attributes, and operations; associations have names and two or more ends, each with its own properties; and so on. With stereotypes, you can add new things to the UML; with tagged values, you can add new properties to a stereotype. A tagged value is a property of a stereotype, allowing you to create new information in an element bearing that stereotype. Graphically, a tagged value is rendered as a string of the form name = value within a note attached to the object. You define tags that apply to individual stereotypes so that everything with that stereotype has that tagged value. A tagged value is not the same as a class attribute. Rather, you can think of a tagged value as metadata because its value applies to the element specification, not to its instances. For example, as Figure shows, you can specify the required capacity of a server class or require that only one kind of server be used in a given system. Tagged values are placed in a note attached to the affected element, as shown in Figure. Each tagged value comprises a string that includes a name (the tag), a separator (the symbol =), and a value (of the tag). Constraints A constraint is a textual specification of the semantics of a UML element, allowing you to add new rules or to modify existing ones. Graphically, a constraint is rendered as a string enclosed by brackets and placed near the associated element or connected to

Page 5 of 8

Roll No. 521126647

July 2011 Master of Computer Science (MSCCS) Semester 1 MC0069 System Analysis & Design (SAD) 4 Credits (Book ID: B0714) Assignment Set 2 (60 Marks)
that element or elements by dependency relationships. As an alternative, you can render a constraint in a note. Everything in the UML has its own semantics. Generalization (usually, if you know what's good for you) implies the Liskov substitution principle, and multiple associations connected to one class denote distinct relationships. With constraints, you can add new semantics or extend existing rules. A constraint specifies conditions that a run-time configuration must satisfy to conform to the model. For example, as Figure shows, you might want to specify that, across a given association, communication is secure; a configuration that violates this constraint is inconsistent with the model. Similarly, you might want to specify that among a set of associations connected to a given class, a particular instance may have links of only one association in the set. Constraints may be written as free-form text. If you want to specify your semantics more precisely, you can use the UML's Object Constraint Language (OCL), A constraint is rendered as a string enclosed by brackets and placed near the associated element. This notation is also used as an adornment to the basic notation of an element to visualize parts of an element's specification that have no graphical cue. For example, some properties of associations (order and changeability) are rendered using constraint notation. Q.5) What are the important factors that need to be considered to model a system from different views? Answer: 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 oth ers, 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.

o Use case view o Design view

Use ease diagrams Class diagrams (for structural modeling)

o Process view o Implementation view o Deployment view

None required None required None required

Page 6 of 8

Roll No. 521126647

July 2011 Master of Computer Science (MSCCS) Semester 1 MC0069 System Analysis & Design (SAD) 4 Credits (Book ID: B0714) Assignment Set 2 (60 Marks)
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.

o Use case view o Design view

Use case diagrams Activity diagrams (for behavioral modeling) Class diagrams (for structural modeling) Interaction diagrams (for behavioral modeling) State chart diagrams (for behavioral modeling)

o Process view o Implementation view o Deployment view

Class diagrams (for structural modeling) Interaction diagrams (for behavioral modeling) Component diagrams Deployment diagrams

Q.6) What are the necessary considerations to be taken care to forward engineer a class diagram? Answer: 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 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 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.

Page 7 of 8

Roll No. 521126647

July 2011 Master of Computer Science (MSCCS) Semester 1 MC0069 System Analysis & Design (SAD) 4 Credits (Book ID: B0714) Assignment Set 2 (60 Marks)
EventHandler has the usual operation expected of this pattern (handleRequest), although two private attributes have been added for this instantiation.

All of these classes specify a mapping to Java, as noted in their lagged value. Forward engineering the classes in this diagram to Java is straight forward, using a tool. Forward engineering the class EventHandler yields the following code. public abstract class EventHandler { EventHandler successor; private Integer currentEventlD; private String source; EventHandler() {} public void handleRequest() {}

Page 8 of 8

Roll No. 521126647