object oriented analysis-unit5

8/8/2019 Object Oriented Analysis-Unit5

1/34

Object Oriented Analysis & Design

Unit -5

UML

The Unified Modeling language (UML) is used to specify, visualize, modify, construct and document the

artifacts of an object oriented software intensive system under development.UML offers a standard way

to visualize a systems architectural blueprints, including elements such as:

y Actorsy Business processesy Componentsy Activitiesy Programming language statementsy Database schemasy Reusable software components

UML combines techniques from data modeling (entity-relationship diagram), business modeling (work

flows), object modeling and component modeling. It can be used with all processes throughout the

software development life cycle and across different implementation technologies.UML has synthesized

the notations of the Booch method, the object-modeling technique(OMT) and object oriented software

engineering(OOSE) by fusing them into a single, common and widely usable modeling language.UML

aims to be a standard modeling language which can model concurrent and distributed systems.UML is a

de facto industry standard and is evolving under the auspices of the object management group(OMG).


2/34

Structure diagrams

Structure diagrams emphasize the things that must be present in the system being modeled.

Since structure diagrams represent the structure they are used extensively in documenting the

architecture of software systems.

y Class Diagram: describes the structure of a system by showing the system's classes, theirattributes, and the relationships among the classes.

y Component diagram: describes how a software system is split up into components andshows the dependencies among these components.

y Composite structure Diagram: describes the internal structure of a class and thecollaborations that this structure makes possible.

y Deployment Diagram: describes the hardware used in system implementations and theexecution environments and artifacts deployed on the hardware.

Behavior diagrams

Behavior diagrams emphasize what must happen in the system being modeled. Since behavior

diagrams illustrate the behavior of a system, they are used extensively to describe the

functionality of software systems.

y Activity diagram: describes the business and operational step-by-step workflows of componentsin a system. An activity diagram shows the overall flow of control.

y UML state machine diagram: describes the states and state transitions of the system.


3/34

y Use case diagram: describes the functionality provided by a system in terms of actors, theirgoals represented as use cases, and any dependencies among those use cases.

Package Diagram

A package diagram provides the means to organize the artifacts of the development process to clearly

present the analysis of the problem space and the associated design. The specific reasons will be varied

but will either focus on physically structuring the visual model itself or on clearly representing the model

elements through multiple views.

The Notation for the package is a rectangle with a tab on the top left.

Visibility of elements

Access to the services by a group of collaborating classes within a package-or more generically to any

elements within a package is determined by the visibility of the individual elements including nested

packages. The visibility of the elements defined by the containing package to be either public or private,

applies both to contained elements and to those that are imported.

Elements with public visibility can be thought of as a part of the packages interface

because these elements are visible to all other elements. Those elements with private visibility are not

visible outside the containing package.

y Public (+) : Visible to elements within its containing package, including nested packages and toexternal elements.

y Private (-): Visible to elements within its containing packages and to nested packages.


4/34

The Dependency Relationship

If an element has the appropriate visibility to afford access, a dependency relationship to it can be

shown representing this access. Dependencies between UML elements are shown an open arrowhead.

The tail of the arrow is located at the element having the dependency (client), and the arrowhead is

located at the element that supports the dependency (supplier).


5/34

Import & Access concepts in package diagram

Import and access are really two sides of the same coin-import is a public package import, whereas

access is a private package import. what this really means is that in an import, other elements that have

visibility into the importing package can see the imported items. But when a package performs an access

no other elements can see those elements that have been added to the importing packagesnamespace.

Component Diagram

A component diagram shows the internal structure of components and their dependencies with other

components. This diagram provides the representation of components, collaborating through well-

defined interfaces, to provide system functionality.

In the Unified Modeling Language, a component diagram depicts how

components are wired together to form larger components and or software systems.Components diagrams are used to illustrate the structure of arbitrarily complex systems.

The Component Notation


6/34

Since a component is a structured classifier, its detailed assembly can be shown with a composite

structure using parts, ports and connectors. Its name EnvironmentalControlSystem in this case is

included within the classifier rectangle in bold lettering. In addition one or both of the component tags

should be included: the keyword label and the component icon shown in the upper

right-hand corner of the classifier.

On the boundary of the classifier rectangle we have seven ports which are denoted by

small squares. Ports have public visibility unless otherwise noted.Components may also have hidden

ports, which are denoted by same small squares, but they are represented totally inside the boundary of

the composite structure, with only one edge touching its internal boundary. Hidden ports may be used

for capabilities such as test points that are not to be publically available. ports are used by the

component for its interaction with its environment and they provide encapsulation to the structured

classifier.

To the ports we have connected interfaces which define the components interface details. The

interface is shown in the ball and socket notation. Provided interfaces use the ball notation to specify

the functionality that the component will provide to its environment; Light Control is an example of

provided interface.


7/34

The Component Diagram

Components are wired together by using an assembly connectorto connect the required

interface of one component with the provided interface of another component. This illustrates

the service consumer - service providerrelationship between the two components.

An assembly connectoris a "connector between two components that defines that one

component provides the services that another component requires. An assembly connector is a

connector that is defined from a required interface or port to a provided interface or port."

When using a component diagram to show the internal structure of a component, the provided

and required interfaces of the encompassing component can delegate to the corresponding

interfaces of the contained components.

Adelegation connectoris a "connector that links the external contract of a component (as

specified by its ports) to the internal realization of that behavior by the components parts."

Components Interface


8/34

EnvironmentalController realizes the cool Control interfaces; this means that it provides the

functionality specified by the interface. This functionality is starting,stopping,setting the

temperature and setting the fan speed for any component using the interface.


9/34

Figure 1. UML 2.x component diagram.


10/34


11/34

Deployment Diagram

A deployment diagram is used to show the allocation of artifacts to nodes in the physical design

of a system. A single deployment diagram represents a view into the artifacts structure of a

system. During development we use deployment diagram to indicate the physical collection of

nodes that serve as the platform for execution of our system.

The three essential elements of a deployment diagram are artifacts, nodes and

their connections.

The Artifact Notation

The Node Notation

A node is a computational resource, typically containing memory and processing on which artifacts are

deployed for execution. Nodes may contain other nodes to represent complex execution capability.

There are two types of nodes: devices and execution environments.

A device is a piece of hardware that provides computational capabilities such as a

computer modem or a sensor. An execution environment is software that provides for the developmentof specific types of executing artifacts; examples include and .


12/34

Figure 2. Concise UML 2 deployment diagram.


13/34

Use Case Diagram

A use case diagram depicts the context of the system to be built and the functionality provided by that

system. Use case diagrams depict who interacts with the system. They show what the outside world

wants the system to do.

Actors

Actors are entities that interface with the system. They can be people or other systems.Actors,which are

external to the system they are using are depicted as:

Use Cases

Use cases represent what the actors want your system to do for them. Use cases are not just any

capability that your system may provide. A use case must be a complete flow of activity, from the actors

point of view that provides value to the actor.


14/34


15/34

In the diagram as the Gardener actor executes the Manage Garden use case, he or she

may want to look at some reports. This could be done by using the View Reports use case. However

View Reports is not required when Manage Garden is run. Manage Garden is completed in and of

itself.So,we modify the use diagram to indicate that the ViewReports use case extends the Manage

garden use case as shown

Activity Diagram

An activity diagram provides the visual depiction of the flow of activities, whether in a system, business,

workflow or other process. These diagrams focus on the activities performed and who is responsible for

the performance of those activities.

The Elements of an activity diagram are action nodes, control nodes and object nodes.

There are three types of control nodes: initial and final (final nodes have two varieties, activity final and

flow final), decision and merge and fork and join.

Actions

Actions are the elemental unit behavior in an activity diagram. Activities can contain many actions which

are what activity diagrams depict.


16/34

Starting & Stopping

Since an activity diagram shows a process flow, that flow must start and stop somewhere. The starting

point (initial node) for an activity flow is shown as a solid dot and the stopping point (activity final node)

is shown as a bulls eye.

Decision & Merge Nodes

Decision and merge nodes control the flow in an activity diagram. Each node is represented by a

diamond shape with incoming and outgoing arrows. A decision node has one incoming flow into one of

the nodes outgoing flows.

Merge nodes take multiple input flows and direct any and all of them to one outgoing flows.

There is no waiting or synchronization at a merge node.


17/34

Forks, Joins and Concurrency

Fork and join nodes are analogous to decision and merge nodes respectively. The critical difference is

concurrency. Fork has one flow in and multiple flows out, as do decision node. The difference is where a

decision node selects a single outbound flow a single flow into a fork results in multiple outbound flows.

All the outbound flows occur concurrently.

A join has multiple incoming flows and a single outbound flow, similar to mergenodes. However, with a join all incoming flows must be completed before the outbound flow

commences.


18/34

Class Diagram

A class diagram shows the existence of classes and their relationship in the logical design of a system.

During analysis, class diagram indicate the common roles and responsibilities of the entities that provide

the systems behavior. During design, class diagrams capture the structure of the classes that form the

systems architecture.

Overview

The class diagram is the main building block in object oriented modeling. They are being 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 diagramrepresent 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:


19/34

A class with three sections.

y The upper part holds the name of the classy The middle part contains the attributes of the classy 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. Withdetailed 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.

Members

UML provides mechanisms to represent class members, such as attributes and methods, and

additional information about them.

Visibility

To specify the visibility of a class member (i.e., any attribute or method) there are the following

notations that must be placed before the member's name.

Scope

The UML specifies two types of scope for members: instance and classifier.In the case of

instance members, the scope is a specific instance. For attributes, it means that its value canvary between instances. For methods, it means that its invocation affects the instance state, in

other words, affects the instance attributes. Otherwise, in the classifier member, the scope is

the class. For attributes, it means that its value is equal for all instances. For methods, it means

that its invocation does not affect the instance state. Classifier members are commonly

recognized as "static" in many programming languages. To indicate that a member has the


20/34

classifier scope, its name must be underlined. Otherwise, as default, the instance scope is

considered.

Relationships

A relationship is a general term covering the specific types of logical connections found on class

and object diagrams. UML shows the following relationships:

Instance Level Relationships

External links

ALinkis the basic relationship among objects. It is represented as a line connecting two or

more object boxes. It can be shown on an object diagram or class diagram. A link is an instance

of an association. In other words, it creates a relationship between two classes.

Association

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.

Aggregation

Class diagram showing Aggregation between two classes


21/34

Aggregation is a variant of the "has a" or association relationship; aggregation is more specific

than association. It is an association that represents a part-whole or part-of relationship. As a

type of association, an aggregation can be named and have the same adornments that an

association can. However, an aggregation may not involve more than two classes.

Aggregation can occur when a class is a collection or container of other classes, but where thecontained classes do not have a strong life cycle dependencyon the containeressentially, if

the container is destroyed, its contents are not.

In UML, it is graphically represented as a hollowdiamond shape on the containing class end of

the tree of lines that connect contained class(es) to the containing class.

Composition

Class diagram showing Composition between two classes at top andAggregation between two classes at

bottom

Composition is a stronger variant of the "owns a" or association relationship; composition is

more specific than aggregation. It is represented with a solid diamond shape.

Composition usually has a strong life cycle dependencybetween instances of the container class

and instances of the contained class(es): If the container is destroyed, normally every instance

that it contains is destroyed as well. Note that a part can (where allowed) be removed from a

composite before the composite is deleted, and thus not be deleted as part of the composite.

The UML graphical representation of a composition relationship is afilleddiamond shape on

the containing class end of the tree of lines that connect contained class(es) to the containing

class.

Differences between Composition and Aggregation

When attempting to represent real-world whole-part relationships, e.g., an engine is part of a

car, the composition relationship is most appropriate. However, when representing a software

or database relationship, e.g., car model engine ENG01 is part of a car model CM01, an

aggregation relationship is best, as the engine, ENG01 may be also part of a different car model.

Thus the aggregation relationship is often called "catalog" containment to distinguish it from

composition's "physical" containment.


22/34

The whole of a composition must have a multiplicity of 0..1 or 1, indicating that a part must

belong to only one whole; the part may have any multiplicity. For example, consider University

and Department classes. A department belongs to only one university, so University has

multiplicity 1 in the relationship. A university can (and will likely) have multiple departments, so

Department has multiplicity 1..*.

Class Level Relationships

Generalization

Class diagram showing generalization between one superclass and two subclasses

The Generalization relationship indicates that one of the two related classes (the subtype) is

considered to be a specialized form of the other (the super type) and supertype is considered as

'Generalization'of subtype. In practice, this means that any instance of the subtype is also an

instance of the supertype. An exemplary tree of generalizations of this form is found in binomial

nomenclature: human beings are a subtype of simian, which are a subtype of mammal, and so

on. The relationship is most easily understood by the phrase 'A is a B' (a human is a mammal, amammal is an animal).

The UML graphical representation of a Generalization is a hollow triangle shape on the

supertype end of the line (or tree of lines) that connects it to one or more subtypes.

The generalization relationship is also known as the inheritance or "is a"relationship.

The supertype in the generalization relationship is also known as the "parent", superclass, base

class, or base type.

The subtype in the specialization relationship is also known as the "child", subclass, derived

class, derived type, inheriting class, or inheriting type.

Note that this relationship bears no resemblance to the biological parent/child relationship: the

use of these terms is extremely common, but can be misleading.

y Generalization-Specialization relationship


23/34

A is a type ofB

E. g. "an oak is a type of tree", "an automobile is a type of vehicle"

Generalization can only be shown on class diagrams and on Use case diagrams.

Realization

In UML modeling, a realization relationship is a relationship between two model elements, in

which one model element (the client) realizes (implements or executes) the behavior that the

other model element (the supplier) specifies. A realization is indicated by a dashed line with 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.

General Relationship

Class diagram showing dependency between "Car" class and "Wheel" class

Dependency

Dependency is a weaker form of relationship which indicates that one class depends on another

because it uses it at some point of time. Dependency exists if a class is a parameter variable or

local variable of a method of another class.

Multiplicity

The association relationship indicates that (at least) one of the two related classes makes

reference to the other. In contrast with the generalization relationship, this is most easily

understood through the phrase 'A has a B' (a mother cat has kittens, kittens have a mother cat).


24/34

The UML representation of an association is a line with an optional arrowhead indicating the

role of the object(s) in the relationship, and an optional notation at each end indicating the

multiplicityof instances of that entity (the number of objects that participate in the

association).

Common multiplicities are:...

0..1 No instances, or one instance (optional, may)

1 Exactly one instance

0..* or * Zero or more instances

1..* One or more instances (at least one)

1..3, 6, 9..*Mixed instances

Analysis Stereotypes

In the early stages of a project's technical analysis, class diagrams can be used to produce early

conceptual models of the system. Classes at this stage often take the form of boundaries,

controls and entities and rarely survive into the design without heavy changes.

Boundaries

Boundary classes handle the communication between actors and the system's internal

components. They might be user interfaces, system interfaces or device interfaces (for

example). They are typically identified by each actoruse-case pair on the system's use-case

diagram.


25/34

They are drawn as circles with a short line to the left attached to a vertical line the same height

as the circle (as though it is attached to the side of the use-case system boundary).

Alternatively, they can be drawn as normal classes with the boundary stereotype notation

above the class name.

Entities

Entity classes model the information handled by the system, and sometimes the behaviour

associated with the information. They should not be identified as database tables or other data-

stores.

They are drawn as circles with a short line attached to the bottom of the circle. Alternatively,

they can be drawn as normal classes with the entity stereotype notation above the class

name

Controls

Control classes handle the flow of control for a use-case and can therefore be seen as co-

ordinating representation classes. These do not do everything in the use case, but co-ordinate

with other classes that can do the work for them.

Composite Structure Diagrams

Composite structure diagram provide a way to depict a structured classifier with the definition of its

internal structure. This internal structure is comprised of parts and their interconnections, all within thenamespace of the composite structure. Structured classifiers can be nested, so each part could be

another structured classifier. This diagram is also useful during design to decompose classes into their

constituent parts and model their runtime collaborations.

The essential elements of a composite structure are its parts, ports, interfaces and

connectors.

Composite structure parts

The composite structure diagram for the Hydroponics Gardening Systems Water Tank is shown. Its

name is placed in the top. Water Tank contains the Heater and tank parts which collaborate to provideits functionality, that of providing appropriately heated water for the gardeners to use. The name of a

composite structure part uses the format of role name:Class name [multiplicity].


26/34

Composite structure ports and interfaces

The composite structure and its parts interface with their external environment through ports, denoted

by a small square on the boundary of the part or composite structure. We see that Heater and Tank

both have ports through which they interact with each other to provide the functionality of water Tank.

Using ports for all interactions provides encapsulation to the structured classifier. These

ports have public visibility unless otherwise noted. Hidden ports are denoted by a small square that

appears totally inside the composite structure, with only one edge touching its boundary. To these

ports, we connect the interfaces that define the details of the composite structures interactions. These

interfaces are commonly shown in the ball-and-socket notation.

Timing Diagrams

A timing diagram is used to design and understand time-critical systems. A state machine diagramexpresses behavior as a progression through a series of states, triggered by events and the related

actions that may occur. These are also known as behavioral state machines. Timing diagram are a type

of interaction diagram. Their purpose is to show how the states of an element or elements change over

time ad how events change those states.

Notations & Layout

Timing diagrams have one or more lifelines for each object in the diagram. The possible states of the

object are listed inside the lifeline.Also,a timeline shows how the object changes from one state to

another. Events that drive the state changes are shown along the timeline. The horizontal axis shows

time and may also show tick marks to help the reader of the diagram better understand specific timing.


27/34

Alternate Representation

In case where timing diagram have many lifelines or objects that have many states, instead of using a

timeline, we can use a more compact representation as shown.

Communication Diagram

A communication diagram is a type of interaction diagram that focuses on how objects are linked and

the messages they pass, as they participate in a specific interaction.

Objects, Links & Messages

A link may exist between two objects if and only if there is an association between their corresponding

classe.The existences of an association between two classes denotes a path of communication between

instances of the classes, whereby object may send messages to another.


28/34

Given object A with a link L to object B, may invoke any operation that it applicable

to Bs class and accessible to A; the reverse is true for operations invoked byB on A. We will refer to the

object that invokes the operation as client and whichever object provides the operation as the supplier.

In general the sender of a message knows the receiver but the receiver does not necessarily know the

sender.

Messages & Synchronization

In the example the message startup () is an example of a simple call and is represented with a directed

line with a solid arrowhead. This indicates a synchronous message. In the case of the startup () and

isready () messages, the client must wait for the supplier to completely process the message before

control can resume.

In the case of the message turnOn (), the semantics are different. This is an example of an

asynchronous message, indicated by the open arrowhead. Here the client sends the event to the

supplier for processing, the supplier queues the message and the client then proceeds without waiting

for the supplier.


29/34

Iteration Clauses & Guards

An iteration clause optionally can be added to indicate a series of messages to be sent. It is shown as an

asterisk followed by the iteration clause in brackets. This example indicates that the turnOn message is

to be sent sequentially, 1 to n times. If the message were to be sent concurrently, the asterisk would be

followed by a double bar (i.e. *||[i=1n]).

Guard conditions can also adorn message. The notation is similar to an iteration clause,

but without the asterisk. The guard condition is placed within brackets, as shown.


30/34

Interaction overview Diagrams

Interaction overview diagrams are a combination of activity diagrams and interaction diagrams that are

intended to provide an overview of the flow of control between interaction diagram elements. Though

any type of interaction diagram may be used, the sequence diagram will likely be the most prevalent.

Frames

The interaction overview diagram is typically surrounded by a frame; however the frame is optional

when the context is clear. We see the surrounding frame with the named sd Maintain Temperature

lifelines: EnvironmentalController,: Heater,:Cooler in the compartment in the upper left-hand corner.

The meaning of this name is as follows:

Sd: a tag that indicates this is an interaction diagram. Maintain Temperature: a name describing the purpose of the diagram Lifelines: EnvironmentalController,: Heater,: Cooler.


31/34

Sequence Diagram

A sequence diagram is used to trace the execution of a scenario in the same context as a

communication diagram. To a large degree a sequence diagram is simply another way to

represent an object diagram.

The advanyage of using sequence diagram is that it is easier to read the

passing of messages in relative order.Sequence diagram are often better than object diagram

for capturing the semantics of scenarios early in the development lifecycle,before the protocols

of individual classes have been identified.

Lifelines & Messages

In sequence diagram,the entities of interest are written horizontally across the top of the

diagram.A dashed vertical line called the lifeline is drawn below each object.These indicate the

existence of the object.

Messages are shown horizontally.The endpoints of the message icons connect

with the vertical lines that connect with the entities at the top of the diagram.Messages are

drawn from the sender to the receiver.Ordering is indicated by the vertical position with the first

message shown at the top of the diagram and the last message shown at the bottom.


32/34

Execution Specification

Simple sequence diagrams may not indicate the focus of control as messages are passed.For example if

object A sends messages X and Y to other objects,it may not be clear whether X and Y are independent

messages from A or whether they have been invoked as part of the same enclosing message Z.

Control Constructs

Just as we saw fragments being used to simplify sequence diagrams, they can similarly be used

to indicate flow control constructs on sequence diagrams.


33/34


34/34

object oriented analysis-unit5

Documents