UML DIfferences,Short notes

7/30/2019 UML DIfferences,Short notes

1/37

www.missionmca.com

OOMD Differences, Short Notes on Imp topics & Some IMP Ques with Ans

Difference between Inheritance and Association

Inheritance Association

1. It is identifying and defining a

system of hierarchies betweenclasses.

2. Inheritance can be:-Generalization

Specialization

3. There is concept of super class and

sub class.

4. Inheritance does not include anyconstraints.

i. Associations are relationships

between attributes & also betweenclasses.

ii. An association could be :One-To-One

One-To-Many

Many-To-One

iii. There is no concept of super & sub-

class.

iv. Associations include cardinalityconstraints on its end.

Difference between node and component

Node Component

1.

node corresponds to hardware.2.

he node can represent a piece of alarger hardware component,

represented by encapsulating the node(having one node inside the other

node).3.

node represents a physical componentof the system.

Components represent software.

Each component is representative of one or

more classes that implement one function

within the system.

Component is used to represent any part of asystem for which UML diagrams are made.

Difference between object diagrams and class diagrams

Class Diagram :

A class diagram is a static representation of your system. It shows the types of classes, and how these

classes are linked to each other

A class diagram is a graph of Classifier elements connected by their various static relationships


2/37

www.missionmca.com Class diagrams show the logical, static structure of a system and are central the Unified Modelling

Language.

Object Diagram :

A pictorial representation of the relationships between these instantiated classes at any point of time

(called objects) is called an "Object diagram."

Class diagrams can contain objects, so a class diagram with objects and no classes is an object diagram. An object diagram is a graph of instances, including objects and data values. A static object diagram is an

instance of a class diagram; it shows a snapshot of the detailed state of a system at a point in time.

Object diagrams play a smaller role in UML. They are used primarily for documenting test cases and

scenarios.

Difference between object diagrams and class diagrams?

A class diagram is a graph of Classifier elements connected by their various static relationships. Note that a

class diagram may also contain interfaces, packages, relationships, and even instances, such as objects and

links. Perhaps a better name would be static structural diagram, but class diagram is shorter and wellestablished.

An object diagram is a graph of instances, including objects and data values. A static object diagram is an

instance of a class diagram; it shows a snapshot of the detailed state of a system at a point in time. The use ofobject diagrams is fairly limited, mainly to show examples of data structures.

Tools need not support a separate format for object diagrams. Class diagrams can contain objects, so a class

diagram with objects and no classes is an object diagram. The phrase is useful, however, to characterize aparticular usage achievable in various ways.

The basic idea is that class diagrams focus on classes and object diagrams focus on objects, but it is possible tomix classes and objects on the same diagram for various purposes, so the separation is not rigid. Class diagramsshow the logical, static structure of a system and are central the Unified Modeling Language. Object diagrams

play a smaller role in UML. They are used primarily for documenting test cases and scenarios, and for discussinexamples.

Difference Between Aggregation and SpecializationAggregation :

Aggregation is to create new functionality by taking other classes and combining them into a new class

An aggregation is the "a part of" relationship in which objects represents the components in same

assembly. Aggregation may be the special form of Association.

With aggregation, you get to choose either implementation or interface, or both -- but you're not forced

into either. The functionality of an object is left up to the object itself

Example (aggregation) : A Paragraph consists of many sentences. Here Paragraph contains sentences.

Specialization :

Specialization is relationship between the classes.

Specialization is the is-a-kind-of relationship, in which the specialization is the subclass, or subtype.

Example:


3/37

www.missionmca.comIf we have class Vehicle, Automobile and Truck. Then Automobile and Truck is-a-kind-of Vehicle.

Vehicle is a super class and Automobile and Truck are subclasses.

Difference between Composition and Aggregation.Aggregation - Without whole part can exist.Composition - Without whole part can't exit.

Aggregation -One class is a kind of another class.Composition - One class has another class

Aggregation - In Design, If you remove "whole" part can exist (BUT In Code No diff.).

Composition - In Design, If you remove "whole" part can also be removed automatically (in RSA) (BUT In codno diff).

1. Composition implies real ownership of its components whereas aggregation does not necessarily own any of i

aggregates.

2.Composition has a stronger bond of its components whereas aggregation has weaker or looser bonds with its

aggregates.

3.Composition has components that exist at the inner level whereas aggregation has aggregates that live at the

outer level.

Composition : - Two objects are same life time is called composition.

Aggregation :- Two objects are different life time is called aggergation.

Aggregation uses instances of objects created outside of this class.

Composition uses instances of objects that are created as part of this object.

Aggregation heavily implies that the aggregate object already exists, to be grouped in the calling object.

Composition heavily implies that the composite object should be created by the calling object.

Difference between Event & State

Events:

State machines communicate by sending events to one another.

Events are typically treated as operations.

In some cases, an event may corrospond to a signal, such as a hardware interrupt. In other situation, it

may correspond to a message, such as a method invocation or an inter-process message.

The term event refers to the type of occurrence rather than to any concrete instance of that occurrence. Fo

example, Keystroke is an event for the keyboard, but each press of a key is not an event but a concrete

instance of the Keystroke event.

An event can have associated parameters, allowing the event instance to convey not only the occurrence

some interesting incident but also quantitative information regarding that occurrence. For example, the

Keystroke event generated by pressing a key on a computer keyboard has associated parameters that

convey the character scan code as well as the status of the Shift, Ctrl, and Alt keys.


4/37

www.missionmca.comState :

A state is an abstraction of an objects state. It can represent particular values for a subset of the objects

attributes a links.

A transition between states, therefore, represents some changes in those values.

A state captures the relevant aspects of the system's history very efficiently. For example, when you strik

a key on a keyboard, the character code generated will be either an uppercase or a lowercase character,

depending on whether the Caps Lock is active.

A state is depicted in UML as a capsule with name and/or a set of actions.

Difference between Event & State

Event State

1.

n event is something that happens at apoint in time such as user depresses the

left button of mouse.2.

n event does not have any duration.

The attribute values and links held by an

object are called its states.

A state is a condition or situation duringthe life of an object during which it

satisfies some condition, performs some

activity, or waits for some event.

Difference between macro process and micro process

Micro Processes Macro Processes

A. The micro-processes of object-oriented development are largely

driven by the stream of scenariosand architectural products.

B. It represents the daily activities ofthe individual developer or a small

team of developer.C. It applies equally to the software

engineering and softwarearchitecture.

D. The traditional phases of analysis

and design are intentionally blurred,and the process is under

opportunistic control.

A. The macro process serves as thecontrolling framework for the micro

process.

B. It represents the activities of theentire development team on the

scale of weeks to months at a time.

C. Many elements of the macroprocess are simply sound software

management practice, and so applyequally to object-oriented as well as

non-object-oriented systems.D. The traditional phases of analysis

and design are to a large extentretained, and the process is

reasonably well defined.


5/37

www.missionmca.comWhite box Framework Vs Black box framework

White box Framework consists of a set of classes that define abstractions.

you define subclasses inherit that abstraction. inheritance of application.

you must understand the implementation details of the classes in the framework. subclasses add state and behaviour specific to application.

some framework classes are abstract, many are concrete and some can be used as it is.

Black box framework consists of a set of classes that operate on specific interfaces.

each interface defines a role. you introduce classes that play those roles by implementing the interfaces.

interface inheritance and polymorphism as principle specialization mechanism. you are plugging in classes to a set of interfaces.

Black-box frameworks are easier to use than white-box. You must understand only interfaces.

Functional Modelling V/S Object modelling

Functional Modelling and object modellingAns:

Functional Modelling Object Modelling

1. Functional modelling provides functional

view of the system

1. Object modelling gives static view of the system

2. It is depicted by using the DFD 2. Class diagrams are used to depict the object

modelling

3. In functional modelling aspects of the

system concerned with transformation ofvalues

3. Object model describes structure of object in a

system & their identity & relationships

1. It describes data flow & constraints to

describe business process.

2. Weaker approach, then objectmodeling.

3. It uses DFD for describing business

processes.

4. It is difficult to prototype.

5. It cannot map the model to real worldscenario.

a) It describes the structure of the objects

in the system in terms of identityrelationship, attribute and operation.

b) Strongest approach then functionalmodeling.

c) It uses class diagram to describe the

system.

d) It is easy to prototype.

e) It maps model to real worlds scenario.


6/37

www.missionmca.com4. Functional model captures what a system

does without regard for how or when it is

done

4. Object model captures those concepts from realworld that are important to applications

5. Example: DFD for photocopier software 5. Example: Class diagram for hotel management

software

ii)Inheritance and association

Association Inheritance

1. An association is a relationship betweenclasses in the class diagram. A software

designer uses an association to define thedependencies between classes in the

implementation.

1. Inheritance is the operation result ofspecialization, which is the is-a-kind-of

relationship, in which a child or (sub class)inherits all attribute, associations, and

operations of its parents (super class)

2. Association describes relationship

between the instances

2. Inheritance is solely a relationship betweenthe classes & not between instances

3. Association includes cardinality

constraints on its ends

3. No cardinality constraints are shown in

inheritance

4. Diagrammatic notation:Binary associations (with two ends) are

normally represented as a line, with eachend connected to a class box. Higher order

associations can be drawn with more thantwo ends. In such cases, the ends are

connected to a central diamond.

4. Diagrammatic notation:To show inheritance(specialization), one can

draw a separate arrow from each subclass tothe super class or use the shared target arrow.


7/37

www.missionmca.com5. UML permits the specification of

association of any degree. i.e. ternary or

reflexive. This is depicted as:

6. Some (but not all) languages permitsmultiple inheritance in which a subclass

inherits from more than one immediate superclasses, this is depicted as:

Comparison between Sequence and Collaboration diagram

Sequence Diagram Collaboration Diagram

It shows the occurrence of events in a systemwith respect to time.

It shows organization or relationship ofobjects.

Objects have a lifeline within sequencediagrams.

It consists of path between objects andsequence number.

It is shown using rectangle with all messages

involved in the interaction within therectangle

It is shown by * and stack of objects involved

in the interaction.

Condition is shown in [ ]. Branching is shownusing bifurcation and if receives a return

message, the lifeline is spitted

Condition is shown in [ ] and the branchesfrom a given object bears the same sequence

number.

Delete statement touches the object. Delete statement touches the lifeline with an

X.

Timing constraint is included. Timing constraint is not included.

Activation diagrams present. Activation diagrams not present.

In Sequence diagrams we can showSynchronous as well as Asynchronous

messages.

In Collaboration Diagram we can only shoySynchronous messages.

Sequence Diagram shows overall flow of

System event/s in a given use case.

Collaboration diagram shows how objects

interacts with each other howintercommunication b/w objects for a give use


8/37

www.missionmca.comcase.

Its difficult to fine the responsibilities ofobjects in sequence diagram.

Its ease to detect the responsibilities of objectsin collaboration diagram by just counting the

number of arrows coming into the object.

Sequence Diagrams are less spatial. Collaboration Diagram are much spatial.

Difference between collaboration and sequence diagram in UML

1)Sequence diagram gives you time based interaction between the objects.

Collaboration diagram tell how the objects are associated.

2) Sequence diagrams emphasize the time ordering of messages, whereas collaboration diagrams depict

more of an organizational structure and are more space efficient.

3) Collaboration diagrams also provide Action between to object (interaction object). Sequence steps

achieve functionalities.

4) Sequence diagrams provide the users and life time of the each object. Action between to object. Sequen

steps achieve functionalities.

5) Sequence diagram is basically a flow chart w.r.t time.

However, a collaboration diagram is very much the sequence diagram without any time.

6) In Sequence diagrams we can show Synchronous as well as Asynchronous messages.

In Collaboration Diagram we can only show Synchronous messages.

7) Sequence Diagram shows overall flow of System event/s in a given use case.

Collaboration diagram shows how objects interacts with each other how intercommunication b/w object

for a give use case

8) Its difficult to fine the responsibilities of objects in sequence diagram.

Its easy to detect the responsibilities of objects in collaboration diagram by just counting the number of

arrows coming into the object.9) Sequence Diagrams are less spatial.

Collaboration Diagram is much spatial.

10) Collaboration Diagram emphasizes the relationships between objects while Sequence diagram

emphasizes the time sequence of behaviour.

11) A sequence diagram is effectively a two-dimensional graph with time on one axis and objects of intere

on the other.

A collaboration diagram is a visualization of a collection of objects linked by interactions, arranged in

an attempt to optimize understands ability.


9/37

www.missionmca.com

Extends Include/Uses

Extension use case references the base

use case.

Base use case refers the inclusion use case.

Extension may be invoked

independently.

Inclusion may be invoked independently.

The base use case must be well formed

even if extension use case is not

invoked.

Base use case may depend on the effects of

inclusion use case.

Extension usually takes care of

alternate scenario (which might happen

to be exception)

Includes relationship may be linked to

aggregation of classes.

1. The uses arrow is drawn from a

use case A to another use case Bto indicate the process of doing

A always involves doing B atleast once.

2. A uses relation from use case Ato use case B indicates that an

instance of the use case A willalso be include in the behaviour

as specified by use-case B.

3. The notation is a close-headed

arrow annotated with the stereotype name uses.

4. Symbol:

5. Example:

1) The extends arrow is drawn if a use

case A to a use case B, indicate thatthe process A is a special case

behaviour of the same as the moregeneral process B.

2) An Extends relationship from a usecase A to use case B indicate that an

instance of use case may include thebehaviour.

3) The notation is the enclosed headed

arrow directed arrow from theextension with the

stereotype annotation.

4) Symbol:

5) Example:


10/37

www.missionmca.comArchitecture pattern versus Design pattern

1. Architectural pattern:-

It is a problem independent way of organizing a system or subsystem. It describes astructure by which different parts of system are organized or interact.

1. Design pattern:-

A design pattern is a solution to small problem i.e. independent of any problem domain. I

represents a solution to a design problem that to occur in any kind of application. Somedesign pattern can be applied to different areas like order processing, online shopping car

banking application or any other system.2. Architecture pattern:-

Architectural means how data is flowing in your application.2. Design pattern:-

Design pattern means how you are approaching to problem.

3. Architectural pattern:-

Architectural pattern concentrate on what.3. Design pattern:-

Design pattern concentrate on how.

4.

Architectural pattern:- Architecture means flow of particular business logic or project.

4. Design pattern:-

Design means approach for that particular business logic or project.5. Architecture pattern:-

Architectural states how that particular logic to be implemented.5. Design pattern:-

Design pattern states the rules and regulation to be followed while implementing somesoftware.

6. Architecture pattern:-

Architecture is concern with the selection of architectural elements, their interaction and

the constraints on those elements and their interaction.6. Design pattern:-

Design is concern with the modularization and detects interfaces of design element, theirprocedure and data type needed to support the architecture and to satisfy the requirements

What are the advantages of object oriented approach?

A) Higher levels of abstractionb) Seamless transition among different phases of software development

c) Encouragement of good programming techniques

D) Promotion of reusability

What is Association class.?An association class is an association that also as class properties. The name in the class symbol and the name strin

attached to the association path are the same. If an association class has attributes but no operations or other associations, ththe name may be displayed on the association path and omitted from the association class to emphasize its associatinature". If it has operations and attributes then the name may be omitted from the path and placed in the class rectangle emphasize its "class nature".


11/37

www.missionmca.comWhat is an Association rule?

An association may have an association name. This name may have an optional black triangle in it, the poinof the triangle indication the direction in which to read the name. The end of an association where it connects to a clasis called the association role.

What do you mean by difference between patterns and frameworks.Ans: A pattern is instructive information that captures the essential structure and insight of a successfully family proven solutions to a recurring problem that arises within certain context and system of forces. Pattern solves

problem, is a proven concept, describes relationships, and has significant human component.A framework is a way of presenting a generic solution to a problem that can be applied to all levels in a developmen

It represents a set of classes that make up a reusable design for a specific class of software. It partitions the design into abstrclasses and also defines relationships between them. They emphasize design reuse over code reuse.

What is a Qualifier?A qualifier is an association attribute. For example, a person object

may be associated to a Bank object. An attribute of this association is the account#. The account# is the qualifierof this association.

Bank

Account#

*0..1

Person

A qualifier is shown as a small rectangle attached to the end of an association path, between the final pathsegment and the symbol of the class to which it connects. The qualifier rectangle is part of the association path, not

part of the class. The qualifier rectangle usually is smaller than the attached class rectangle.

What are the diagrams used in Booch methodology?The Booch methodology consists of the following diagrams:

Class diagrams.Object diagrams.

State transition diagrams.Module diagrams.

Process diagrams.Interaction diagrams

What are the advantages of Modeling?Good models are essential for communication among project teams. As the complexity of systems increases, sodoes the importance of good modeling techniques. Some of the advantages are as follows:

Models make it easier to express complex ideas.The main reason for modeling is to reduction of complexity.

Models enhance and reinforce learning and training.The cost of modeling analysis is much lower than the cost of similar perimentation conducted in real

system.Manipulation of the model is much easier.


12/37


13/37

www.missionmca.com Another way to perform this logic, however, would have been to have Student simply request Seminar to

enroll himself into itself. Then have Seminar do the work of determining if a seat is available and, if so,then enrolling the student and, if not, then informing the student that he was not enrolled.

ABSTRACT CLASS

An abstract class is a class that is declaredabstractit may or may not include abstract methods. Abstract classescannot be instantiated, but they can be subclassed.

An abstract method is a method that is declared without an implementationAn abstract method is one that defines an interface but no implementation.each subclass must provide its

own implementation of that method.

An abstract class is one for which instances cannot be createdi.e, an object of it cannot be created.Any class withan abstract method must be abstract.it is not necessary to have an abstract method in an abstract class.

When an abstract class is subclassed, the subclass usually provides implementations for all of the abstractmethods in its parent class. However, if it does not, the subclass must also be declaredabstract.

Features of an Abstract Class

1. Abstract Class cannot be instantiated.2. An Abstract Class must be inherited.3. It may have Concrete Methods.

4. It may have Abstract Methods.5. An Abstract Method of an Abstract Class must be overridden.

6. An Abstract Class can only contain Abstract Method.

History StatesA history state is used to remember the previous state of a state machine when it was interrupted. The followingdiagram illustrates the use of history states. The example is a state machine belonging to a washing machine.

In this state machine, when a washing machine is running, it will progress from "Washing" through "Rinsing" to

"Spinning". If there is a power cut, the washing machine will stop running and will go to the "Power Off" state.Then when the power is restored, the Running state is entered at the "History State" symbol meaning that it

should resume where it last left-off.


14/37

www.missionmca.comRealizations

A realization from a source element (called the realization element) to a target element (called the specificationelement) indicates that the source element supports at least all the operations of the target element without

necessarily having to support any attributes or associations of the target element. For example, an undifferentiateclass or implementation class may play the role defined by a type and may provide the service defined by an

interface, if the class supports the operations defined by the type and interface. A realization allows us to reuse toperations of types and interfaces where a realization element is said to realize its specification elements.

A realization is shown as a dashed-line path from the source element to the target element, with a large hollow

triangle at the end of the path connected to the target element. When the target element is an interface shown as small circle, the realization is shown as a solid-line path connecting the source and interface.

Swimlanes

Activity diagrams tell you what happens, but they do not tell you who does what. In programming, this meansthat the diagram does not convey which class is responsible for each activity.

In domain modeling, this means that the diagram does not convey which people or departments are responsiblefor each activity. One way around this is to label each activity with the responsible class or human. This works,

but does not offer the same clarity as interaction diagrams for showing communication among objects. Swimlanes are a way around this.

To use swimlanes, you must arrange your activity diagrams into vertical zones separated by lines. Eachzone represents the responsibilities of a particular class or a particular department.

Swimlanes are vertical or horizontal bands in a diagram that divide the diagram into logical areas orpartitions. In the example below the activities relating to particular entities within the model (such as the User, o

the back end Repository) are placed within a containing swim lane to indicate their association.


15/37

www.missionmca.com

Extend and Include in use cases

Extend and Include define relationships between use cases. Below figure Extend and Include shows how

these two fundamentals are implemented in a project. The below use case represents a system which is used to

maintain customer. When a customer is added successfully it should send an email to the admin saying that a ne

customer is added. Only admin have rights to modify the customer. First lets define extend and include and thensee how the same fits in this use case scenario.

Include: Include relationship represents an invocation of one use case by the other. If you think from the coding

perspective its like one function been called by the other function.

Extend: This relationship signifies that the extending use case will work exactly like the base use case only that

some new steps will inserted in the extended use case.

Below figure Extend and Include shows that add customer is same as the add discounted customer. The Ad

discounted customer has an extra process, to define discount for the discounted customer which is not available

for the simple customer. One of the requirements of the project was that when we add a customer, the systemshould send an email. So after the customer is added either through Add simple customer use case or Add

discounted customer use case it should invoke send a email use case. So we have defined the same with a

simple dotted line with as the relationship.


16/37

www.missionmca.com

Figure: Extend and Include

Note: One of the points to be noted in the diagram Extend and Include is we have defined inheritance

relationship between simple and admin user. This also helps us defining a technical road map regarding

relationships between simple and admin user.

Representation of private, public and protected in class diagrams

In order to represent visibility for properties and methods in class diagram we need to place symbols next to eac

property and method as shown in figure Private, Public and Protected. + indicates that its public

properties/methods. -indicates private properties which means it can not be accessed outside the class. #

indicate protected/friend properties. Protected properties can only be seen within the component and not outside

the component.

Figure: Private, public and protected


17/37

www.missionmca.comComposite structure diagram and reflexive association in class diagrams

Composite structure diagram

When we try to show Aggregation and Composition in a complete project the diagram becomes very complicate

so in order to keep it simple we can use Composite structure diagram. In the below figure we have shown two

diagrams one is normal diagram other is Composite structure diagram and the simplicity can easily be identified

In the composite diagram the aggregated classes are self contained in the main class which makes it simpler to

read.

Figure: Composite Structure diagram

Reflexive associations

In many scenarios you need to show that two instances of the same class are associated with each other and this

scenario is termed as Reflexive Association. For instance in the below figure shows Reflexive Association in the

real project. Here you can see customer class has multiple address class and addresses can be a Head office,

corporate office or Regional office. One of the address objects is Head office and we have linked the address

object to show Reflexive Association relationship. This is the way we can read the diagram Regional address

object is blocked by zero or one instance of Head office object.

Kinds of reflexive association :

asymmetric reflexive association (4 facts) - A reflexive association in which the roles at either end aredifferent.

symmetric reflexive association (3 facts) - A reflexive association in which the roles at either end are identica


18/37

www.missionmca.com

Figure: Reflexive association

Generalization and specialization

In Generalization and Specialization we define the parent-child relationship between the classes. In many instan

you will see some of the classes have same properties and operation these classes are called super class and later

you can inherit from super class and make sub classes which have their own custom properties. In the below

figure there are three classes to show Generalization and Specialization relationship. All phone types have phone

number as a generalized property but depending upon landline or mobile you can have wired or simcard

connectivity as specialized property. In this diagram the clsphone represent Generalization whereas clslandline

and clsmobile represents specialization.

Figure: Generalization and Specialization

Package diagrams

Packages are like folders in a system which allows you to logically group UML diagrams. They make complexUML diagram readable. In actual projects they are used to logically group use cases and classes. So we can say

there are two types of package diagrams one is class package diagram and other is use case package diagram.Package diagram depict a high level of overview for class and use cases.

Class package diagram: - Class package diagram are used to logical group classes. You can think that package

technically map to Package in JAVA and Namespaces in C# and VB.NET. Packages are denoted by small


19/37


20/37

www.missionmca.comSBI of an object

SBI stands for State, Behavior and Identity. Since every object has the above three.

State: It is just a value to the attribute of an object at a particular time.

Behaviour:It describes the actions and their reactions of that object.

Identity: An object has an identity that characterizes its own existence. The identity makes it possible to

distinguish any object in an unambiguous way, and independently from its state.

Coupling:1) Coupling is the measure of interconnection among modules in a software structure like cohesion; couplin

may also be represented on a spectrum.

2) Coupling depends on the interface complexity between modules, the point at which entry or reference is

made and what data passes across the surface.

3) Then lowest possible coupling is optimum.

4) Simple connectivity amongst modules results in software, that is easier to understand and less prone to a

ripple effect caused when error occurs at one location and propagates through the system.5) Types of coupling:

1. Data coupling:

1) If the modules communicate via an elementary data item, which is passed as parameter between

the two then the modules are called as data coupled.

2) This data item should be problem related and not used for the control purpose.

3) Example: passing an integer to a function which computes a square root.

2. Stamp coupling:

If modules communicate via a composite data item such as a structure in C, then they are stamp

coupled.

3. Control coupling:

1) If data from the module is used to direct the order of execution of instructions in another module,

then the modules are control coupled.

2) Example: a flag id set in one module and is tested in another module

4. Common coupling:

If two modules share some global data area then they are common coupled.

5. Content coupling:

1) If the modules share their code then they are content coupled.

2) Example: a branch from one module into another module

6)

The degree of coupling is in ascending from data coupling to content coupling.

Stereotypes in uml1) A stereotype defines a constraint that i similar to some other construct, but has special semantics.

2) Any notational construct can be stereotyped.

3) The name of the stereotype appears in guillemets (or double angle brackets if guillemets are unavailable)


21/37

www.missionmca.com4) Actors are normally modelled in a class diagram as stereotyped classes, where the name of the stereotype

is .

5) Actor classes are like normal classes in that they have instances, can be associated with other classes, and

can have a public interface.

6) They differ from regular classes, however, in that they are not implemented.

7) They are black boxes to ones design.

8) Any UML construct can be stereotyped.

9) The specialization relationship for the uses and extends relationships between use cases is alsostereotyped.

10)Dependencies can be stereotyped for template instantiation.

The following example includes a stereotyped dependency (binds) for template instantiation also contains a modelfragment with a stereotyped class and stereotyped dependencies. The

Order Not Pending Exception class is special, because its instances are exceptions.

Guidelines for flexible design A flexible design is one that is extensible or reusable.

New features can be added to an extensible design relatively painlessly.

Ideally, adding a new capability should affect as few classes as possible.

A reusable design is one that can be used, either entirely or in part, in another system or application.

To increase its flexibility, an object-oriented design should exhibit several properties:

1. High cohesion:

1) Cohesion is a measure of the degree to which an entity does just one kind of thing.

2) The more cohesive it is, the more it limits itself to one area of interest.

3) Classes should be cohesive in that they should represent a single abstraction.

4) A class that is not cohesive is more difficult to understand and, in some cases, to extend.

5) Operations should also be cohesive in that each should handle a single responsibility.

2. Low coupling:

1) Coupling measures what an entity needs to know about the world around it.

2) Coupling involves what a class or object knows about other classes or objects.

order

orderNumber

timePlaced

cancel()

commit()

addLineItem()

totalPrice()

Telephone

Agent

0..1

Order Not

Pending


22/37

www.missionmca.com3) Low coupling means that the classes and objects know as little as possible about other classes and

objects.

4) If one class is coupled to another and the public interface of that second class changes, the

implementation of the first class may be affected.

5) Reducing coupling can limit the scope of a change to the design.

3. An even distribution of behaviour:

1) One must strive to keep state and behaviour together in an object and to have that object do things fo

itself.2) In doing so, one can avoid objects that control other objects.

4. Strong modularity:

1) This is the degree to which like things are grouped together.

2) One strives to group objects into meaningful packages, subsystems, processes, and so forth.

Artifacts

An artifact in the Unified Modeling Language (UML) is the specification of a physical piece ofinformation that is used or produced by a software development process, or by deployment and operation

of a system. Examples of artifacts include model files, source files, scripts, and binary executable files, a table in a

database system, a development deliverable, or a word-processing document, a mail message. In UML 2.0, artifacts are the physical entities that are deployed on Nodes, Devices, and Execution

Environments. Other UML elements such as classes and components are first manifested into artifacts aninstances of these artifacts are then deployed. Artifacts can also be composed of other artifacts.

Patterns

1. Patterns are parameterized collaborations; that is, they are a group of collaborating objects/classes that ca

be abstracted from a general set of modeling scenarios.

2. Patterns are an excellent means of achieving re-use and building in robustness.

3. As patterns are discovered in any new project, the basic pattern template from previous engagements can

be re-used with the appropriate variable names modified for the current project.

4. Patterns generally describe how to solve an abstract problem, and it is the task of the pattern user tomodify the pattern elements to meet the demands of the current engagement.

5. Before using a pattern it must first be created as a standard UML diagram and then saved as an XMLpattern file. This XML file can then be imported as a UML Resource that can be used in any model.

Actor Class

An actor in the Unified Modeling Language (UML) "specifies a role played by a user or any other systemthat interacts with the subject."

An Actor models a type of role played by an entity that interacts with the subject (e.g., by exchangingsignals and data), but which is external to the subject."


23/37

www.missionmca.com Actors may represent roles played by human users, external hardware, or other subjects. Note that an act

does not necessarily represent a specific physical entity but merely a particular facet (i.e., role) of somentity that is relevant to the specification of its associated use cases.

UML treats actors as special stereotyped classes.

A atereotype class is like a normal class, but it has special semantics.

Like normal class, an actor class can have instances; it instances can communicate with objects in thesystem.

Unlike a normal clacc, however, an actor class is a black box because you dont have to implement it orunderstand its internal details.

The normal notation for a stereotype is to place the name of the stereotype within guillemets.

In case of the actor class stereotype, UML provides a special graphical adornment : the stick figure.

Join Fork1. The Fork/Join elements have different modes of use, as follows:

a) To fork or split the flow into a number of concurrent flows.

b) To join the flow of a number of concurrent flows.c) To both join and fork a number of incoming flows to a number of outgoing flows.

2. A fork node is a control node that splits a flow into multiple concurrent flows... A fork node has oneincoming edge and multiple outgoing edges.

3. A join node is a control node that synchronizes multiple flows... A join node has multiple incoming edges

and one outgoing edge.

4. Fork vertices in the UML Statechart Diagram serve to split an incoming transition into two or moretransitions terminating on orthogonal target vertices. The segments outgoing from a fork vertex must not havguards or triggers. Join vertices serve to merge several transitions emanating from source vertices in differen

orthogonal regions. The transitions entering a join vertex cannot have guards or triggers.

5. A Fork notation in a UML Activity Diagram is a control node that splits a flow into multiple concurrentflows. This will have one incoming edge and multiple outgoing edges. A join node is a control node that

synchronizes multiple flows.This will have multiple incoming edges and one outgoing edge.

Q) Compare and contrast the approaches for developing class diagrams.

Ans:Class Diagram:class diagrams are the mainstay of object-oriented analysis and design.class diagrams show the classes of the system, their interrelationships (including inheritance, aggregation, and

association), and the operations and attributes of the classes.Class diagrams are used for a wide variety of purposes, including both conceptual/domain modeling and detaile

design modeling.eg:


24/37

www.missionmca.com

There areapproaches to develop class diagram:1) from Noun Phrase

2)using Abstraction3)Using Use Cases

Developing class diagrams from Noun Phrases: One approach of identifying classes is to use syntactic elements of a problem statement.

The abstraction that represent classes appear as Noun Phrases in the description/Specification of thesyntax.

Examples of such abstractions:

i)Physical Objects: credit card scanners, automobiles etc

ii)Roles: Customer, patient and doctor.iii)Concepts: Review processes, tax tables.

EG: Library Checkout System

Developing class diagrams using Abstraction: This method is more efficient but one should be problem domain expert to abstract the system.

Several methods adopt this technique. Each method provides a set of identification keys to identify majo

abstractions.

keys such as:

i)find kind-of or part-of relations. List the relationship and the classes involved in them.ii)find what other systems interact in them.

iii)find other devices interacting with system. Object Oriented System Analysis(Modelling the world in DATA, SHLAER and MELLOR)

Object Oriented Development : The fushion method.

Developing class diagrams using Use Cases:

The Use case diagram is used to identify the primary elements and processes that form the system. The primary elements are termed as "actors" and the processes are called "use cases."

The Use case diagram shows which actors interact with each use case.

A use case diagram captures the functional aspects of a system.

Use case diagrams define the requirements of the system being modeled and hence are used to write test

scripts for the modeled system

EG: Tracking the States of Machines.

Comparing the Approaches :


25/37

www.missionmca.com

Approaches Advantages Disadvantages

Noun Phrases i) The Process is almost

mechanical, it is helpful in thesituation when you are not

certain how to start.

ii) Little problem domainknowledge required because

problem definition itself givesthe idea.

iii) There is a very clear

stopping rule: as one will lookat all noun phrases will

identify classes.

i) Very tedious process if

problem definition is toolarge.

ii)It requires written problem

definition but allorganisations are not

providing it.

iii) Quality of the modelhighly depends on quality of

problem definition and many

other descriptions are notgood enough.

Abstraction i) It is very efficient in termsof development time and

effort compared to Nounphrases and Use cases.

ii) It is good use of problem

domain expertise.

i) It is difficult to trace designand implementation back to

requirements.

ii) It requires deep knowledge

of problem domain.

Use-Cases i) The model contains featuresthat are justified by

behaviour.

ii) Use cases are goodvehicles for explaining and

validating requirements.

i) For large systems toidentify Use cases is

discouraging.

ii) Written Classes for Usecases is not straight forward.

Q) The Booch methodology prescribes a macro development process and a micro development process.

1.The Macro Development Process

The macro process serves as a controlling framework for the micro process and can take weeks or even months.

The primary concern of the macro process is technical management of the system. Such management is interesteless in the actual object-oriented design than in how well the project corresponds to the requirements set for it an

whether it is produced on time.

The macro development process consists of the following steps:


26/37

www.missionmca.com1. Conceptualization

2. Analysis and development of the model3. Design or create the system architecture

4. Evolution or implementation5. Maintenance

2.The Micro Development Process

The micro process is a description of the day-to-day activities by a single or small group of software developers.

The micro development process consists of the following steps:

1.Identify class and objects2.Identify class and objects semantics

3.Identify class and object relationships4.Identify class and object interfaces and implementation.

Q) Relationships Between Classes

In a class diagram, obviously you can't have classes just floating around; you need to see the relationship betwee

them. The following table shows the kinds of relationships between classes, their notation, and what they mean.

Sr.

No.

Relation Symbol Description

1 Association When two classes are connected to each

other in any way, an association relation established. For example: A "studentstudies in a college" association can be

shown as:

1 a. Multiplicity An example of this kind of association is

many students belonging to the samecollege. Hence, the relation shows a star

sign near the student class (one to many,many to many, and so forth kind of

relations).

1 b. Directed Association Association between classes is bi-

directional by default. You can define theflow of the association by using a directe

association. The arrowhead identifies thecontainer-contained relationship.

1 c. Reflexive Association No separate symbol. However, therelation will point back at the sameclass.

An example of this kind of relation iswhen a class has a variety ofresponsibilities. For example, an employ

of a college can be a professor, ahousekeeper, or an administrative

assistant.

2 Aggregation When a class is formed as a collection of

other classes, it is called an aggregationrelationship between these classes. It is


27/37

www.missionmca.comalso called a "has a" relationship.

2 a. Composition Composition is a variation of theaggregation relationship. Composition

connotes that a strong life cycle isassociated between the classes.

3 Inheritance/Generalization Also called an "is a" relationship, becausthe child class is a type of the parent clas

Generalization is the basic type ofrelationship used to define reusable

elements in the class diagram. Literally,the child classes "inherit" the common

functionality defined in the parent class.

4 Realization In a realization relationship, one entity

(normally an interface) defines a set offunctionalities as a contract and the other

entity (normally a class) "realizes" thecontract by implementing the functionali

defined in the contract.

Different views of the system that UML allows to constructs:

1. Use-Case View:

The use case view of a system encompasses the use cases that describe the behaviour of the system as seen by it

end users, analysis and testers.

2. Design View:

The design view of the system encompasses the classes, interfaces and collaborations that form the vocabulary othe problem and its solution. It supports the functional requirements of the system.

3. Process view:

The process view of a system encompasses the processes that form the systems concurrency and synchronizatio

mechanisms. It addresses the performance, scalability and throughput of the system.

4. Implementation view:

The implementation view of a system encompasses the components and files that are used to assemble and relea

the physical system. It addresses the configuration management of the systems releases, made up of somewhatindependent components and files that can be assembled in various ways to produce a running system.

5. Deployment view:The deployment view of a system encompasses the nodes that joins the systems hardware topology on which th

system executes. It addresses the distribution, delivery and installation of the parts that make up the physicalsystem.


28/37

www.missionmca.com

Q) Discuss top-down and bottom-up approaches.Ans.

Top down Design of System Dynamics It is originates from use cases. It is top-down because you start with general items, use cases then you walk

through scenarios to identify very specific items, object methods and required links between objects. It employsuse cases to drive the overall process. It moves from general (use cases) to specific (methods).

Top down design of system dynamics can be illustrated with a stock trading example.Steps of Top Down approach are as follows

1. Identify the use cases of system behavior.2. Specify and refine each use case.

3. Define a scenario for each interesting path through use case.4. Draw interaction diagram for each scenario.

5. Identify object methods from object interactions in the interaction diagrams.6. Define each state-based objects behavior with a state transition diagrams using interaction diagrams for

guidance.

Bottom upDesign of System Dynamics

It is starting with specific object responsibilities like methods, attributes, links. Then move to use scenarios tovalidate and expand those responsibilities. Starting point is objects(links, attributes and methods. It moves from

specific to general. This process is the opposite of the top-down approach because it starts with specific objectmethods and then uses scenario primarily as a validation.

Bottom up approach described by library system example.

Steps of Bottom up approach are as follows1. Identify the classes in the system.

2. Make a list of the responsibilities of the objects of each class.3. Identify interesting scenarios that you will use to validate your enumeration of responsibilities.

4. Draw an interaction diagram for each scenario, validating that you have all necessary responsibilities. Addresponsibilities as necessary.

Q) Using examples compare and contrast the various relationships that can exist between

classes.

In UML, object interconnections (logical or physical), are modeled as relationships. There are three kinds ofrelationships in UML:

Dependencies

Generalizations

Associations

1. Dependency Relationships

A dependency indicates a semantic relationship between two or more elements. The dependency from

CourseSchedule to Course exists because Course is used in both the add and remove operations ofCourseSchedule.


29/37

www.missionmca.com

2.

Generalization Relationships

A generalization connects a subclass to its superclass. It denotes an inheritance of attributes and behavior from th

superclass to the subclass and indicates a specialization in the subclass of the more general superclass.

UML permits a class to inherit from multiple superclasses, although some programming languages (e.g., Java) dnot permit multiple inheritance.

3. Association Relationships

If two classes in a model need to communicate with each other, there must be link between them. An association

denotes that link.

We can indicate the multiplicity of an association by adding multiplicity adornments to the line denoting the

association.The example indicates that a Student has one or more Instructors:

The example indicates that every Instructor has one or more Students:


30/37

www.missionmca.comWe can also indicate the behavior of an object in an association (i.e., the role of an object) using

rolenames.

We can also name the association.

We can specify dual associations.

A class can have a self association.

We can model objects that contain other objects by way of special associations called aggregations andcompositions.

AggregationAn aggregation specifies a whole-part relationship between an aggregate (a whole) and a constituent part, where

the part can exist independently from the aggregate. Aggregations are denoted by a hollow-diamond adornmenton the association.

CompositionA composition indicates a strong ownership and coincident lifetime of parts by the whole (i.e., they live and die

as a whole). Compositions are denoted by a filled-diamond adornment on the association.


31/37

www.missionmca.com

UML Extension Mechanism

UML is a universal software modeling language that provides an abundance of well-defined modeling concepts

and notations to meet all the requirements of general software modeling. Nevertheless, the softwaremodeling/development environment today can take many different forms, and there may be requirements for

elements or semantics that do not exist in the UML standard. By default, UML provides concepts for supportingsuch requirements, and they are called the UML Extension Mechanisms.

Extensibility Mechanisms help to add new building blocks,create new properties and specify new semantics.[2]

Extensibility mechanisms provided by UML are as follow:

Stereotypes

Tagged Values Constraints

The UML provides a textual representation for stereotypes, tagged values, and constraints.

UML Extension Mechanisms use Stereotypes, Constraints, Tag Definitions,andTagged Values to extend thesemantics of UML modeling elements or define the UML modeling elements with new semantics.

Stereotypes

Stereotypes help to introduce new graphical symbols.It is an extension of list of words and their meaning used inUML. Diagrammatically, a stereotype is rendered as a name enclosed by guillemets (French quotation marks ofthe form ), placed above the name of another element or by using new icon or both.The stereotyped element

may be rendered by using a new icon associated with that stereotype.[2]

Node or a class like elements arestereotyped by creating a new building block just like an existing one but with its own special modeling

properties, semantics and notation. Stereotypes help to add new things to the UML.

Operation Stereotypes

Stereotypes used to group together operations with common characteristics are called operation stereotypes. The

represent a metaclassification of the operation.[2]

Tagged Values

A tagged value is a property of a stereotype.It helps to create new information in an element bearing that

stereotype.It help to add new properties to a stereotype.Different types of tag can be defined that can be applied

different stereotypes.Diagrammatically, a tagged value is rendered as a string of the form name = value within a note attached to the

object.[2]

The values of properties of model elements is referred to as tagged values when a stereotype is applied to it. It


32/37

www.missionmca.comrepresent arbitrary information which is expressed in text form.It is commonly used to store Project Managemen

information.

Constraints

A constraint is a textual specification of the semantics of a UML element.[2]It help to add new rules or to redefin

the existing ones.Constraints may be written as free-form text.A constraint specifies conditions that a run-timeconfiguration must satisfy to conform to the model. Time and space constraints are used for modeling real time

systems.It restrict the values that object or links can assume.Constraints may be attached to more than oneelement by using dependencies.

[2]Diagrammatically, a constraint is rendered as a string enclosed by brackets an

placed near the associated element or connected to that element or elements by dependency relationships.Also aan alternative,constraint can be rendered in a note. Constraints between two elements are depicted using a dotted

labeled line.

Q) What are the benefits and drawbacks of identifying classes using Abstraction and NounPhase approach?

The benefits of Abstraction are as follows:1. It is very efficient in terms of development time and effort because you do not underline nouns or describ

use cases.

2. It is therefore a good use of problem domain expertise.

The drawbacks of Abstraction are as follows:1. It requires extensive knowledge of the problem domain. Only a domain expert can use this approach

effectively. Furthermore, the quality of the model is highly dependent on both the knowledge and skill of

the domain expert.

2. It can be difficult to trace design and implementation constructs back to requirements. If use cases are

employed, classes can be traced to use cases to written requirements. If noun phrases are isolated from a

problem statement, classes can be traced back to noun phrases. With abstraction, however, there is nothin

available to which to trace classes.

3. It can result in analysis paralysis: agonizing over details that arent in the model.

4. The certainty that everything is being thought of is not there i.e. when to stop is not obvious.


33/37

www.missionmca.comThe benefits of Noun Phase are as follows:

1. The process is almost mechanical and, hence, is appealing in situations where how to start is uncertain.

2. It requires little, if any, problem domain knowledge, provided a written description of the system is

available.

3. There is a very clear stopping rule: when all the noun phrases have been looked upon, the identification o

classes finishes.

The drawbacks of Noun Phase are as follows:1. It is a very tedious process, and the written description of a large system could be hundreds of pages long

2. It requires a written description of the problem to be solved. Many development organizations are never

provided such a description.

3. The quality of the model highly depends upon the quality of the problem statement, and many problem

descriptions are not very good.

Q) Describe architectural pattern and design patterns.1.Architectural Patterns:

1) An architectural pattern is a problem-independent way of organizing a system or subsystem.

2) It describes a structure by which the different parts of a system are organized or interact.

3) When organized using the Pipes and Filters pattern, an application consists of a set of filters that

communicate with one another using data streams, or pipes.

4) Each filter reads data from one or more input pipes, transforms that data, and then writes its results to on

or more output pipes. In most cases, an output pipe of one filter is an input pipe of another.

2.Design Patterns:

1) A design pattern is a solution to a small problem that is independent of any problem domain.

2) It represents an attractive solution to a design problem that could occur in any kind of application.

3) The same design pattern can be applied in areas as diverse as order processing, factory control, and

meeting room scheduling.4) Different design patterns solve different kinds of problems.

5) Object-oriented design patterns typically show relationships and interactions between classes or objects,

without specifying the final application classes or objects that are involved.

6) Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable

in functional programming languages, in which data is immutable or treated as such.

7) Design patterns reside in the domain of modules and interconnections.

8) At a higher level there are architectural patterns that are larger in scope, usually describing an overall

pattern followed by an entire system.

Q )What are the benefits of reuse? What the various forms of reuse in object orienteddevelopment. Explain.

Ans:

Reuse of design and code is often cited as a principle benefit of object-oriented development.Reuse is not asingle concept it comes in different sizes and shapes.The scale of the reusable item can be anything from a

single class to a large component consisting internally of hundreds of classesSeveral forms of reuse in object-oriented developments are:

Reuse of classes


34/37

www.missionmca.com Reuse of components

Reuse of frameworks

Reuse of patterns

REUSE OF CLASSES: The simplest and probably most common form of reuse is the reuse of individual classes

These classes are packed in the form of a class library (package in java)

Classes are typically grouped in terms of functional cohesion

i.e. all the classes in one functional area are placed in one library

Like in data structure class library, it includes classes for linked list,stacks,queues etc..

Consider class lirbrary of financial classes

One such class is the Account class

This class defines the interface & implementation of a basic cash-bearing account

This Account maintains a cash balance, it has method to deposit cash itself,withdraw cash from itself &

return its current balance.

Disadvantage Class based reuse is that the scale of reuse is very small

Much of the state & behavior of some class is specific to application, but as you add more fetures, you

make the class less reusable in other domains

Reuse of Components: Whereas a class is relatively small reusable part, a component is building block, is reused as a single unit

An application can include a set of component whose execution-time instances(binaries) collborate by

invoking operations in one another

A components scale is much larger than that of a class.

A component may be composed of many classes internally.

A component is a non-trival,nearly independent and replaceble part of system that fullfills a clear functio

in the context of a well-defined architecture.

A component conforms to and provides the physical realization of a set of interfaces.

Reuse of Framework:

Diffrence between component & framework:


35/37

www.missionmca.com A component represents an attempt to achieve large-scale reuse. For most part, component is a monolithi

entity.

Whereas framework is a set of classes that work together to achieve a purpose but that must be specialize

internally by the designer.

A framework defines a family of related application in a general way

It contains the element that are common to those application

e.g. Handling sales order & service orders are similar activities that act on very similar entities

Two types of framework:White-Box framework:

It consist a set of classes that define abstraction

Each class defines both the interface & implementation of its abstraction

When you specialize a white-box framework,you define subclasses that inherit that abstraction

Black-box Framework: It consist of a set of classes that operate on specific interfaces

Each interface defines role

Specializing the framework entails introducing classes that play those roles by implementing the

interfaces Whereas a white-box framework defines common abstraction as classes, a black-box

framework specifies common roles as interfaces classes

Reuse of Patterns

The classes,components and frameworks are share same property

i.e. reusing code

The codification & application of patterns reuse the knowledge

A pattern is a way of solving a problem

A pattern typically promotes a design principle while solving a problem

Some patterns strengthen encapsulation

i.e. employing a pattern not only provides a solution that you might not have formulated on your own

But also makes your design more flexible.

Because a pattern embodies the reuse of knowledge rather than code

Developing catalogs of patterns has become an important point of emphasis in the object-oriented

community


36/37

www.missionmca.comThere are 2 types of pattern:

-Architectural pattern-Design pattern

Architectural Pattern:

It is a problem-independent way of organizing a system or subsystem

It describe a structure by which the different parts of system are organized or interact.

Buschmann,Meunier,Rohnert,Sommerlad have been the pioneers in cataloging architectural patterns

such as Pipes & Filters.

Consider the application consisting the set of filters that communicate with one another using data

stream or pipes

Each filter reads data from one or more input pipes

Transform that data

Then writes its result to one or more output pipes.

Design Patterns: A design pattern is a solution to a small problem that is independent of any problem domain

It represent an attractive solution to a design problem that could occure in any kind of application

Same design applied in order processing,factory control & meeting room scheduling

Reuse benefitsIncreased dependability:Reused software, that has been tried and tested in working systems, should be more dependable than new

software. The initial use of the software reveals any design and implementation faults. These are thenfixed, thus reducing the number of failures when the software is reused.

Reduced process risk:If software exists, there is less uncertainty in the costs of reusing that software than in the costs of

development. This is an important factor for project management as it reduces the margin of error inproject cost estimation. This is particularly true when relatively large software components such as

sub-systems are reused.

Effective use of specialists:Instead of application specialists doing the same work on different projects, these specialists candevelop reusable software that encapsulate their knowledge.

Standards compliance:

Some standards, such as user interface standards, can be implemented as a set of standardreusable components. For example, if menus in a user interfaces are implemented using reusablecomponents, all applications present the same menu formats to users. The use of standard user

interfaces improves dependability as users are less likely to make mistakes when presented with afamiliar interface.

Accelerated development:Bringing a system to market as early as possible is often more important than overall developmen

costs. Reusing software can speed up system production because both development and validationtime should be reduced.


37/37

www.missionmca.com

All the Best!!!

Documents

UML DIfferences,Short notes