SUBMITTED INPARTIAL FULFILMENT OF THE REQUIREMENTS FOR THE

AWARD OF Master of Camputer Application (M.C.A)MCA-2nd Semester

SESSION : 2011

Mahobia Campus of IT,RajnandgaonAffiliated to

SIKKIM MANIPAL UNIVERSITY Submitted To : Submitted By : Sikkim Manipal University Ubedulla Naved Azmi Roll No……………………

AssignmentON

“MC0069 – System Analysis & Design (SAD) “

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 Each question carries TEN marks

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 ameaningful 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 entitiesbuilds 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. Therelationship 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 anotherentity as specified within a relationship. The entity type is dependent on another entity type when each entity of a dependententity (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 notequal 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 explanation of these

terms in The Object Primer 3/e. Some of these concepts you will have seen before, and some of them you

haven’t. 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 don’t 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 InheritanceRepresents “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.

3. Discuss the concept of dynamic type modeling and how is different from static type?

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.

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.

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:4Modeling 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

5. 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 StockQuoteSubscriber). This figure is an example of a sequence diagram, which emphasizes the time order of messages.

Attaché(s1)

Attach(s2) Notify()

Update()

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 Each question carries TEN marks

1. Describe the following with suitable examples:

A) Modeling the realization of a Use case B) Modeling the realization of an operationC) Modeling a Mechanism

Ans:1 RealizationA relationship is a general term covering the specific types of logical connections found on class and object diagrams. UML shows the following relationships:

P:stockQuotePublisher S1:StockQuoteSubscriber S2:StockQuoteSubscriber

Getstate()

Update()

Getstate()

Figure: Flow of control by Time

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.

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.

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

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

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.

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

· 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

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

Figure : Forward Engineering

.