Ooad bca

Page 1

ekhaY

,

UNIT-I

1Introduction to 0OAD Oriented Analysis (OOA)

obiect

Oriented Analysis (OOA) is the procedure of identifying software engincering requirements and developing software specifications in terms of a software system's object model, which comprises of interacting objccts. The main difference between object oriented analysis and other forms of analysis is that in object oriented approach, requirements are organized around objects, which integrate both data and functions.

They are modelled after real world objects that the system interacts with .

In

traditional analysis methodologies, the two aspects functions and data are considered separately.

Definition of 00A- Object oriented analysis(OOA) is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabular of the problem domain The primary tasks in object

orientd analysis (OOA) are:

Identifying objects

Organizing the objects by creating object model diagram

Defining

the internals of the objects, or object attributes

Defining

the behavior of the objects, i.e., object actions

Describing how the objects interact The common models used in OOA are use cases and object models

Obiect Oriented Design(00D) Oriented Design (O0D) involves implementation of the conceptual model produced during object oriented analysis.

Object

In

independent, are mapped onto OOD, concepts in the analysis model, which are technology implementing classes,

resulting in a model for the solution constraints are identified and interfaces are designed, the system is to be built on concrete technologies. domain, i.e.,a detailed description of how

he

implementation details generally include: data (if necessary):


"Implementation of methods,

i.e., internal data

structures and algorithims.

associations. "Implementation of control, and Implementation of design encompassing the process of Definition of OOD:-Object oriented design as "a method of as well as static Object oriented decomposition and a notation for depicting both logical and physical and dynamic models of the system under design".

design (O0AD) is a technical approach used in The analysis and design of an application or system through the application of the object-oriented paradigm and concepts including visual modeling. This is applied throughout the development life cycle of the application or system.

Delmition

of 00AD:-Object-oriented analysis and

00 Analysis

00

Design

00

Implementation by using O0 Languages

Advantages of Object Oriented Approach:-

Inproved

software -development productivity:- Object-oriented programming provides improved software-development productivity over traditional procedure because of three factors-modularity, extensibility, and reusability

mproved sofiware maintuinability: -For the reasons mentioned above, object -oriented software is also easier to maintain. Since the design is modular, part of the system can be updated in case of issues without a need to make large-scale changes Fuster development:-Reuse enables faster developmen t. Object-Oriented programming languages come with rich libraries of objects,and code developed during projects is also reusable in future projects.

Lower cost of development: -The reuse of software also

lowers the cost of development. Typically, more effort is put in to the object-oriented analysis and design, which lowers the overall cost of development

Higher-quality software: -Faster development of software and

lower cost of development

allows more time and resources to be used in the verification of the software. Although quality is dependent upon the experience of the teams, object -oriented programming tends to in result higher -quality software.

Disadvantages of Object Oriented Approach:

Steep

learning curve:- Object-oriented programming may not be natural for some people, and it can take time to get used to it. It is complex to create programs based on interaction of objects. Some of the key programming techniques, such as inheritance and polymorphism ,can be challenging to comprehend initially.

Larger program size:-Object-oriented programs typically procedural programs

Unified Modeling Language(UML) The Unified Modeling Language (UML)

involve more lines of code than

is a graphical language for OOAD that gives a standard way to write a software system's blueprint.


It It

helps to Visualize, specily, construct, and document the artifacts(requirements. architccture, design, source

code, project Plans,tests, prototypes, relcasc,ctc) of an oricnted system. object is uscd to depict the structures and the relationships in a comnplex system.

Basic Building Blocks of UML: The following are three basic

building blocks UML: of

1) Things

2) Relationships 3) Diagrams 1) Things:- Things are the most important building blocks of UML anid these are given below: . Structural things 2 Behavioral things 3. Grouping things 4. Annotational things/

1.Structural Things:-Structural things define the static part of the model. They represent the physical and conceptual elements. Following are the bricf descriptions of the structural things.

Class-Class represents a set of objects having similar responsibilities. Cless

Atribtess | Operations

Interface- Interface defines a set of operations, which specify the responsibility of a class.

Interface

Collaboration -Collaboration defines an interaction between elements.

L Use case-Use case represents a set of actions performed by a system for a specific goal. Use casa

system. Component -Component describes the physical part ofa

TComponent

Node

A node can

that exists at run time. be defined as a physical element


Nocde

2.Behavioral Things:-A behavioral thing consists of the dynanic parts of UML models. Following are the behavioral things.

Interaction - Interaction

is defined as a behavior that consists of a group of messages exchanged among elements to accomplish a specific task. Message

State

machine

State machine is useful when the state of an object in its life cycle is important. It defines the sequence of states an object goes through in response to events. Events are external -

factors responsible for state change

state

3.Grouping Things:-Grouping things can be defined as a mechanism to group elements a of UML model together. There is only one grouping thing available. Package- Package

is

things.

the only one grouping thing available for gathering structural and behavioral

Packag

4.Annotational Things:-Annotational things can be defîned as a mechanism to capture remarks, descriptions, and comments of UML model elements. Note It is the only one Annotational thing available. A note etc. of an UML element.

is used to

render comments, constraints,

note

2)Relationships:-Relationship is.another most.important.building.black.af UMLI.shows.how.the elements are associated with each other and this association describes the functionality of an application. There are four kinds of relationships available. 1.Dependency

2.Association 3.Generalization


4.Realization

1.Dependeney:-Dcpendency is a relationship between two things in which change in one clement also affects the other. DependencY

2.Association:-Association is basically a sct of links that connects the elemcents a UML model. of also describes how many objects are taking part in that relationship.

It

Associaion-

3.Generalization:-Generalization can be defined as a relationship which connects a specialized element with a generalized element. It basically describes the inheritance relationship in the world of objects.

Generaization

4.Realization:-Realization can be defined as a relationship in which two elements are connected. One element describes some responsibility, which is not implemented and the other one implements them. This relationship exists in case of interfaces. Realization

3.Diagrams :-A diagram is a graphical representation of a system. It comprises of a group of elements generally in the form of a graph. UML includes nine diagrams in all, namely : 1.

Class Diagram:- set of classes and their relationships. Deseribes interface to the class (set off operations describing services)

2.

Object Diagram:-set

3.

Use Case Diagram:- high-level behaviors of the system, user goals. external entities: actors

4.

Sequence Diagram:- focus on time ordering of messages

5.

Collaboration Diagram:-focus on structural organization of objects and messages

6.

State Chart Diagram:-State Chart Diagram- event driven state changes of system

7.

Activity Diagram:- Activity Diagram

8.

Component Diagram:- logical groupings of elements and their relationships

ofobjects (class instances) and their relationships

9. Deployment Diagram

-

flow of control betveen activities

-set of computational resources (nodes) that host each component.

3. Unified Process (UP) Phases


The Unilied Process is an iterative and incremental development process. The Unified Process divides the project into four phases: 1)

2) 3) 4)

Inception Elaboration (milestone) Construction (releasc) Transition (final production relcasc)

Inception phase

Requirements workflow

Elaboration

phase

Constrüction phase

Transition phase

Analysis

workflow

Design workflow

Implementation workílow Test workflow Time

1)Inception phase:-lnception is the smallest phase in the project, and ideally it should be quite short. The following are typical goals for the Inception phase:

Establish Prepare a preliminary project schedule and cost estimate Feasibility

Buy

or develop it

The Lifecycle Objective Milestone marks the end of the Inception phase. Develop an approximate vision of the system, make the business case, define the scope, and produce rough estimate for cost and schedule.

2)Elaboration phase:-During the Elaboration phase, the project team is expected to capture a healthy majority of the system requirements. However, the primary goals of Elaboration are to address known risk factors and to establish and validate the system architecture. Common processes undertaken in this phase include the creation of use case diagrams, conceptual diagrams (class diagrams with only basic notation) and package diagrams (architectural diagrams).

The architecture is validated primarily through the implementation

an

of Executable Architecture Baseline. This is a partial implementation ot the system which includes the core most architecturally significant components. It is built in a series of small time-boxed iterations. By the Elaboration phase, the system architecture must end of the have stabilized and the executable -baseline-mustdemonstrate that the architecture architecure.will.support.the key-system-functionality the right behavior in terms of performance, scalability, and and exhibitcost. The final Elaboration phase deliverable is a plan (including cost and schedule Construction phase. At this point the plan estimates) for the should be accurate and credible since Elaboration it should be based on the phase experience and since significant risk factors should have been addressed during the Elaboration phase.


of the project. In this phasc, the remainder a f the system is built on the foundation laid in Elaboration. System features are implemented in It eries of short., time-boxed iterations. Each iteration results in an exsccutable release of the soltware. customary to write full-text use cases during the construction phase and each one becomes the start fa new iteration. Common Uniticd Modeling lLanguage (UML) diagranis used during this phase clude activity diagrams, sequence diagrams, collaboration diagrams, State Transition diagrams and nternction overview diagrams. Iterative implementation for the lower risks and easicr elements are one. The final Construction phase deliverable is sothvare ready to be deployed in the Transition

)Constrution phase:-Construction

is the largest phase

hase.

Transition phase:-The final project phase is Transition. In this phase the system is deployed to the arget users. Feedback reccived from an initial relcase may result in further refinements to be neorporared over the course of several Transition phase iterations. The Transition phase also ncludes system conversions and user training.

tUsc case Modeling case modeling is a view of a system that emphasizes the behavior as it appears to outside users.

Usc

A use casc model partitions the system functionality into transactions ('use cases") that are meaningful to users ('actors").

is has three components

It

1)Use case 2)Actor 3)Communication

1)Theuse case task referred to as the use case that represents a feature needed

in a software

system.

2)Theactor(s) who trigger the use case to activate. 3)The communication line to show how the actors communicate with the use case. The picture below is a Make Appointment use case for the medical clinic. The actor is a Patient. The connection between actor and use case is a communication association (or communication for short).

communication

actor-

Make Appointment

Patient Use case

Actors are stick figures. Use cases are ovais. Communications are lines that link actors to use cases.

Use-Case Diagram


Appointment byslen

Hako

Paler

Aanngohmea

Bcthed nfonimaikn

igure: A use case diagram is

5.

a

their communications collection of actors, use cases, and

Relating Use Cases in UML The

1)

following are the three types of Relating Use Cases

in

UML:

Generalization

2) Include 3) Extend 1)

more general use case and a more specific use case.lt is represented by a line and a hollow arrow from child to parent

Generalization:-A Relationship between

a

Parent

Child userace

2) Include Relationship:

Represents Arrow

Write

the inclusion of the functionality of one use case within another

is drawn from the base use case to the used use

case

<< include >> above arrowhead line

3) Extend relationship:

>Represents the extension of the use case to include optional functionality

Arrow

Write

is drawn from the extension use

case to the base use case

< extend >> above arrowhead line

Example of Relationships


Appointment System

Udsle

xtend

psber

»

ohtmerd

nlomaNo

Mlako ckd SPebert

aberd bppl

Mata peyart

Paher

orarngenen«« etend>

A

Mangene

d

A pabent

Docir

Usc-case Diagram for Bank-ATM ATY

Baning System

WIDYdiTW Money

Actor

System

name

lsecase

Depost Noney Cuskme

Association

Check Balante

System

boundary

pater


System Use-cuse Diagram for Library

Ltay Syiem

sra aa

Use-case Diagram for IHotel Information Hotel Intermaton Systern

Make

Book9

Cuslomer

A Booking Process Clerk

Cancel Bockng Tour

Group

Customer Check-in a Rocm

Reception

indAdual Customer

Check-out a Room

Sta


UNIT-II 1)

Elaboration

This phase is used to develop an understanding of the problem domain and the system architecture. risk signiticant portions may be coded and tested. 80% major requirements identified. The goal of the elaboration phase

is

to baseline the most significant requirements.

Elaboration Objectives:.To refine the initial requirements and business case To ensure architecture, requirements, and plans are stable To monitor and address all architecturally significant

risks of the project To refine or establish a base lined architecture To produce an evolutionary, throwaway, or exploratory prototypes To demonstrate that the base lined architecture will support the requirements of the system at a reasonable cost and in a reasonable time. To establish a supporting environment. To produce the project management plan

Elaboration Essential Activities: Analyze the problem domain. Define, validate and baseline the architecture

Refine the Vision to understand the most criticalIse Cascs

Create and baseline iteration plans for construction phase.

Refine the development business case Put in place the development environment, Refine component architecture and decide build/buy/reuse

Develop a project plan and schedule. Mitigate high-risk elements identified in the previous phase.

Elaboration Outcomes

Use Case model (at least 80% complete). o All Use Cases identified o All Actors identified. o Most Use-Case descriptions developed.

Supplementary requirements.


o (non-functional or not associated with

a

Use Casc)

Software architecture description. Exccutable architectural prototype.

Revised risk

list and revised business case.

Development plan for overall project.

Updated development case that specifies process to be used. Preliminary user manual (optional).

2.Domain Model Domain Model in problem solving and software engineering can be thought of as a conceptualmodel of a domain of interest. A

Which describes the various entities, attributes, relationships and constraints.

The domain model is a representation of real-situation conceptual classes

Demain-Modelcan-be created as Finding

conceptual classes

Draw them as classes in a UML class diagram Add associations and attributes

Conceptual Class: The conceptual class is defined informally as an idea, thing, a conceptual class may be considered in terms of its

or object. More formally,

*Symbols - words or images *Intensions

*Extensions

-

its definitions

the set

ofexamples to which it applies

Finding Conceptual Classes:1)

Reuse or modify the existing models

2) Use a category list 3) Identify noun phrases in the use-cases 1)

Reuse or modify the existing models :- This is the first best and usually easiest approach. There are published, well-crafted domain models and data models for many common such as inventory, fînance, domains health and so on.

2) Use a category list:-


For cxample consider the tollowing Category List (Partial):

Business transaction Salc. PayIment. Reservation

Product or service related to transaction Hem. Flight, Seat

Where is the transaction recorded

Lcdger. FlightManifest

Register. Place of servicc

Storc, Airport. Plane, Scat

3)identify Basic

noun phrases in the use-cascs:

Flow for a POS System

.

Customer arrives at a POS checkout with goods and/or services to purchase

2.

Cashier start a new sale

3.

Cashier enters itcm identificr

4.

System records sale line item and presents item description, price, and running total

Ex:- Part of POS System Sales Linetemn

1em

Reçords-sale-of D.

quantty

Stocked-in Cortained-jn

Store

Sale

adross

dale unpe

narne

0.1

ousu Paid-by Rugiste

Captured-on

Payment amount

Deseription Classes


that describes something else. For example.a description class is defined as information picture. and text descripticon of an Item. Product Description that records the price.

A

E.g. Item and

Produet Deseription

ProductDescription

Item

DescribesS

description

*

1

price

serial number

itemID

).

Domain model refinements Generalization and Specialization Generalization and specialization represent a hierarchy of relationships between classes, where subclasses inherit from super-classes.

Generalization In the generalization process, the common characteristics of classes are combined to form a class in a higher level of hierarchy, i.e., subclasses are combined to form a generalized super-class. It represents an "is -a - kind of relationship. For example. "car is a kind of land vehicle", or "ship is a kind of water vehicle". -

Specialization Specialization is the reverse process of generalization. Here, the distinguishing features of groups of objects are used to form specialized classes from existing classes. It can be said that the subclasses are the specialized versions of the super-class.

The following figure shows an example of generalization and specialization.

Vehicle

L

Land

Car Links

Bus

Ship

and Association

Water

Air

Boat

Aeroplane

Helicopter


link represents a connection through which an object collaborates with other objects. Through ink, one object may invoke the mcthods or navigate through another object. A link depicts the elationship betiwecn tiwo or more objects.

A

a

ssociation of links having common structure and common behavior. Association depicts an he relationship between objects of one or more classes. A link can be defined as an instance of ssociation.

ssociation

is a group

egree of an Association

egree of an association denotes the number

of classes involved in a connection. Degree may be

anary, binary, or ternary.

unary relationship connects objects of the same class. rclationship connects objccts of two classes. A-binary A ternary relationship connects objects of three or more classes. A

Cardinality Ratios of Associations Cardinality of a binary association denotes the number of instances participating in an association. here are three types of cardinality ratios, namely-

single object of class A is associated with a single object of class B. One-to-Many A single object of class is associated with many objects of class B. B and Many-to-Many An object of class A may be associated with many objects of class of Conversely an object of class B may be associated with many objects classA.

One-to-One- A -

-

)Association, Aggregation and Composition Association between classes and simple structural connection or channel Association and there is no owner. where all objects have their own lifecycle

is a relationship

is a

Lets

Student. take an exampe of Department and

Multiple

can associate Department and single student single a with have their students can associate betiween the objects and both ownership no is Departments, but there

with multiple own lifecycle.

Both

can create and delete independently.

Here

for the above example. is respective Model and Code


Course class Associales Student and Department classes

Depar tent

Student

nae_p:

n

char

conatruetor> #9use ti destruct or>>Hou3e \1

0..

0..

p:

char

Corstrurtor'

de3truct or>

'

Degartrens DepattAnt

{

--

Course

std p

Student

lept_p: Departbe nt courseNane_p: char

etatic>> static>>

index

unsigned

int

courselist_p: Course

Aggregation is a specialized form of Association where all objects have their own lifecycle Aggregation but there is a ownership like parent and child.

Child object cannot belong to another parent object at the same time..

We

can think of it as "has-a" relationship.

Implementation details: Typically we use pointer variables that point to an object that lives outside the scope of the aggregate class 1.

2. Can use reference values that point to an object that lives outside the scope of the aggregate class 3. Not

responsible for creating/destroying subclasses

Lets take an example of Employee and Company. A single Employee can not belong to multiple Companies (legally!! ),

but if we delete the Company, Employee object will not destroy.

Here

is respective Model and Code

for the above example.


Employee class has Agregation Relatioshlp with Company class

COMpany

Employee hanylane

p

char

nam

*

aryp

pchar

p:

înmployee

Kconstructor>> Lmployee (|

Kdestrvctor) imployee|)

KConstructor>> Company

Pdispl)

9<destructor>> -conpang()

(l|

*

Composition Composition

Itis.a

is again specialized form of Aggregation.

strong type of Aggregation

the Parent and Child objects have coincident lifetimes. Child object does not have its own lifecycle and if parent object gets deleted, then all of its child objects will also be deleted.

Here

Implentation details: 1.

Typically we use normal member variables

2. Can use pointer values if the composition class automatically handles allocation/deallocation 3. Responsible for

creation/destruction of subclasses

Rooms. take an example of a relationship between House and it's

Lets

House can contain multiple rooms there is no independent

.

Ilife

cannot belong to two different house.

If

we delete the house room will also be automatically deleted.

Here

is

example. respective Model and Code for the above

for room and

any room


Room class has Composition Relationship with House class

ROOM

p:

nane

House

House

olyise_p

char

roomsist_p : Roo

*

Wnare_p

<Kconstructor>>

char t

Room{0)

destructor>> -Room() static>> initlist vi)

static>>

:

createRoom_v{)|

disp

Kconstructor>> House () edestructor> House

disp)

5)Activity diagrams Activity

diagram is another important diagram in UML to describe the dynamic aspects of the

system. ACtivity diagram is basicatty a- ftowehartto-represent the -few-frem-ene-aetivity-te-anetheractivity. The activity can be described as an operation of the system. The control fNow is drawn from one operation to another. This flow can be sequential. branched. or concurrent. t does not show any message flow from one activity to another. Before drawing an activity diagram, we must have a clear understanding about the elements used in activity diagram. The main element of an activity diagram is the activity itself. An activity is a function performed by the system. After identifying the activities, we need to understand how they are associated with constraints and conditions.

Before

drawing an-activity diagram, we should identify the following elements:

Activities Association

Conditions Constraints Following is an example of an activity diagram for order management system. In the diagram, four activities are identified which are associated with conditions. Following diagram is drawn with the four main activities. Send order by the customer Receipt of the order Confirm the order Dispalch the order After receiving the order request, condition checks are performed to check if it is normal or special order. After the type of order is identified, dispatch activity is performed and that is marked as the termination of the process.


Activity dilagrom of an order management system

Activites (Customer sends

an

ordor

request

Ordor

Condition

reuost systom

conhrms the

rocolpt of the ordor

check ICheck if tho ordor ls nomal

fdor Start

proce

[No)

Yos

Check if tho order is speclal ordor)

Yes] INo]

Confirm the ordor

TOmination Dispatch the order


UNIT-III 1)Sequence Diagrams

order i.e. the order inn between objccts in a sequential interaction depicts simply A Sequence diagram diagrams or event scenarios to refer to event terms the use also We can in a system vhich interactions take place. and in what order the objects how describe diagrams Sequence a sequcnce diagram. to document and and software developers businessmen by used widely are diagrams function. These understand requirements for new and existing systems.

Sequence Diagram Notations With it UML diagram represents a type of role where interacts person notation. a and its objects. We represent an actor in a UML diagram using stick

1Actors- An

actor

in a

the

system

ACIOr

Figure-NotatroTT Symbotfor

aeter-

2) Lifclines: - A lifeline is a named element which depicts an individual participant in a sequence diagram. So basically each instance in a sequence diagram is represented by a lifeline. Lifeline elements are located at the top in a sequence diagram. The standard in UML for naming a lifeline

follows the following format- Instance Name: Class Name

.

Figure

lifeline

We display a lifeline in a rectangle called head with its name and type. The head is located on top of dashed line (referred to as the stem) as shown above.

a vertical

3)Messages-Communication between objects is represented using messages. The messages appear in a sequential order on the lifeline. we represent messages using arrows. Lifelines and messages form the core of a sequence diagram. Messages can be broadly classified into the following categories: 1.Synchronous me5sages:-Ä synchronous message waits for-a reply-before-the-interaction-canmove forward. The sender waits until the receiver has completed the processing of the message. The caller continues only when it knows that the receiver has processed the previous receives a reply message. We use a message i.e. it solid arrow head to represent a synchronous message.


lent

Figurc- a sequence diagram

synchronous message

using a

2Aspnchronous Messages: -An asynchronous message docs not wait for a reply from receiver. The interaction moves forward irrespective the

of the receiver processing the message or not. We use a lined arow hcad to previous represcnt asynchronous message.

Devre

USer

Welcome kessage

U 3.Create message: We use a Create message to instantiate a new object in the sequence diagram. There are situations-when-a particuar message calTrequires the creation of an object. is It represented with a dotted arrow and create word labelled on it to specify that it is the create Message symbol. For example- The creation of a new order on a e-commerce website would require a new object of Order class to be created. -

******************-

Figure -a situation where create message

is used

delete an object. When an object

is

deallocated

to 4.Delete Message: - We use a Delete Message the Delete Message symbol. It destroys the memory or is destroyed within the system we use terminating with a x. an is

represented by

arrOw


the order In the scenario below when CXanpie O class can be destroycd.

is

user, the object of order received by the

L

message Figure-a scenario where delete

is used

needs to send a message to itself Certain scenarios might arise where the object arrow, represented with aU shaped Such messages are called Self Messages and are

5.Self Messuge:

-

Litelne

Figure

self message

6.Reply Message Reply messages are used to show the message being sent from the receiver open arrowhead with doted line. to the sender. We represent a return/reply message using an The interaction moves forward only when a reply message is sent by the receiver.

a

Figure- reply message A Found message is used to represent a scenario where an unknown source is It an arrow message. sends the represented using directed towards a lifeline from an end point

7.Found Message:

-

.feyliasa"1

Figure-found message


8.LostMessage A

LOst message

used to represcnt a scenario where the recipient is not known to towards an end point from a liteline. For generated.

is

the system. It is represented using an arOw directed example: Consider a scenario where a warning is

Figurclost message

4)Guards- To model conditions we

use guards in UML. They are uscd when we need to restrict flow of messages on the pretext of a condition the being met. Guards play an important software developers know the constraints in letting role attached to a system or a particular

process. example: For In order to be able to withdraw cash, having a balance greater than zero is a condition zhat must be met as shown below.

A

Cust3 Cistcrte

Ea2Ba

Figure- sequence diagram using a guard

sequence diagram for an emotion based music player Cenc

Figure-a

-

Darabase

sequence diagram for an emotion based music player


he bovVC

2. 3.

4 S.

6. 7, S.

9,

lor an emotion based music player: scqucnce diagranm depiets the sequcnce diagram

Firstly the application is opened by the user. cam. The device then gets aceess to the web user. The vebeam captures the iage ol the predict the mood. The deviee uses algorithns to detect the face and It then requests database for dictionary of possible moods. The nood is retrieved lronm the database. The mood is displayed to the user. The music is requested lrom the database. The playlist is generated and linally shown to the user.

2)Relationship between sequence diagrams and use case diagrams Sequencediagram:Sequenee diagrams are used to model the flow of logic within a system by showing the information (also known as stimuli. or message) that is passed between the objects during the execution of a scenario. Iu is a type of interaction diagram as it describes how and in what order a group of objects (interface components or sofiware components) interact with one another. Sequence diagrams are also known as event diagrams.

Howere,-it-deestetshew-hetheobjects-are related to each other Notation: Objects are represented as boxes from left to right. Message sent are represented as horizontal arrows with name on top. Particular instances of each object are shown with a lifeline below to indicate when the object is created and destroyed.

Earlier events are-depicted at the top of the lifeline, with the later events shown further down. Arrival of a stimulus at an object is called an event. Sequence diagrams only specify the ordering of events and not the exact timings of events. An activation box represents the period during which an operation is executed.

Strengths Shows interactions betwecen objects in visual and chronological (time) order. Refines use cases with more details.

Limitations Creating sequence dingram for every use case Fairly technical.

carn

be a waste of time and effort.

Use case diagrams Use case diagram depicts how actors (a person or a system) interacts with a solution to accomplish one or more of the person's or systems goals. It visually depicts the scope of the solution, the actors involved, and the use cases.

Notations:


A ssociations:

ShoivS relationships betWcen actors and use cases:

are: commonly used relationships ol additional behavior into a use casc. Herc. base usc casc gcts Extend: A llows for insertion its execution ALWAYS extended by the extendcd use case. Extending use case is optional and denends on a condition. he pOint at which extension occurs is called extension point, 1

as the base use case (extended use casc) i5 complete vithout the cxtending use casc where extending use case 1S incomplcte without the base use casc. The

Include: Allows basc use case to inake use of the functionalityy prescnt in another use case. Jnciuded ce case is ALWAYS exccuted. The base usc case is incomplete without the included usc case.

represented by include relationship and is mandatory. Additional function is Common function is represented by extend relationship and is non-mandatory. Strengths

Good at clarifying scope, and providing a high-levelunderstanding of requirements Use case specifications make it easy to understand functional behavior ofa system.

.

Limitatiens Written at higher-level of abstraction (low level of detail). Lack of standardized formats. Need analysis to identify include use cases.

3Logical architecture and UML Package diagrams The

logical archtectureis the large scale organizatíon of the software classes into packages (or

decision is amespaces), subsystems, and layers. It is called the logical architecture because there no physical about how these elements are deployed across different operating system processes or acros computers in a network.

subsystems that has cohesive layer is a very coarse grained grouping of classes, packages, or that "higher" layers esponsibility for a major aspect of the system. A lso, layers are organized such vice versa. Typically such as the UI layer) call upon services of "lower" layers, but not normally ayers in an 0bject Oriented system include: A

User Interface. domain concepts Application Logic and Domain Objecis- software objects representing requirements, such as calculating a (for example, a software class Sale) that fulfill application sale total.

that provide supporting Technical Servicesgeneral purpose objects and subsystems These services are

or error logging. a technical services, such as interfacing with database several systems. usually application - independent and reusable across

the services of the layer directly below it. This strict layered architecture, a layer only calls upon in information systems, which usually have a design is common in network protocol stacks, but not upon several lower layers. For example. elaxed layered architecture, in which a higher layer calls application logic layer, and also upon elements of he UI layer may call upon its directly subordinate so forth. lower technical service layer, for logging and n

a


UML Package Diagrams contents of componcnts, which are often Package Diagrams are often used to show the packages in the Java sense. Each package represents a namespace. packages. P'ackages, as components, can be nested inside other

UML

Domain

UI

Sales

Web

Swing

Ui::Web

U:Swin9

Swing

Web

Domain::Sales

Domain Sales

Fig: An Example of Package Diagram

ALogical Architecture refinement

-

UML Class Diagram

Class diagram is a static diagram. It represents the static view of an application. Class diagram is not only used for visualizing, describing, and documenting different aspects of a system but also for constructing executable code of the software application. Class diagram describes the attributes and operations of a class and also the constraints imposed on the system. The class diagrams are widely used in the modeling of objectoriented systems because they are the only UML diagrams, which can be mapped directly with object-oriented languages. Class diagram shows a collection of classes, interfaces, associations, collaborations, and constraints. It is also known as a structural diagram.

Purpose of Class Dingrams and design of the static view Describe responsibilities of a system.

Analysis

of an application.

Base.for.component and deployment diagrams. Forward and reverse engineering The following points should be remembered while drawing a class diagram: The name of the class diagram should be meaningful to describe the aspect of the system. Each element and their relationships should be identified in advance. Responsibility (attributes and methods) of cach class should be clearly identified


For each class, Iminimum number of properties should be specified, as unnecessary properties will make the diagram complicated. Use notes whenever required to describe some aspect of the diagram. At the end ot the drawing it should be understandable to the developer/coder. Finally, before making the final version, the diagram should be drawn on plain paper and reworked as many times as possible to make it

correct.

lowing diagram

is

an example ot an Order System

of thc entire.application.

of an application.

It

describes: particular

First of all, Order and Customer are identified as the two elements of the system. They have a one-to-many relationship because a customer can have multiple orders. Order class is an abstract class and it has two concrete classes

(inheritance relationship) SpecialOrder and NormalOrder. The two inherited classes have all the properties as the Order class. In addition, additional functions like dispatch they have () and receive ().

owing class diagram has been drawn considering all the points mentioned above. Sample Class Diagram

Sustomer name:String

6rder

ocation:Sting

date:Date number:String

sendOrdert) eceiveOrder()

confirm()

Super

class

dose()

Generaliza tion

Nomalorder

SpeclalOrder date:Date

date:Date

numberString

number:String confim()

confim() closef) dispatch()

close() dispatch()

recelve)

Sub

class


UNIT-IY 1).

responsibilities. GRASP : Designing objects with

Assignment Software Patterns. Responsibility General for GRASP stands responsibilities to collaborating objects. Responsibility can be:-

accomplished

It

assi in assigning guides in

by a single object.

a responsibility. group of object collaboratively accomplish object/elae. lass. Or responsibility should be assigned to which in deciding which us helps ídentify how also GRASP and domain, problem the ldentity the objects and responsibilities from objects interact with cach other. with methods implementing those Define blue print for those objects i.c. class responsibilities. The following are the different GRASP Patterns: 1.Creator 2.Information Expert 3.Low Coupling

a

-

4.Controller 5.High Cohesion

2Creator

Who creates an Object? Or who should create a new instance of some class? Container" object creates "contained" objects. who can be creator based on theobjects association and their interaction. Decide Example for Creator: Consider VideoStore and Video in that store. VideoStore has an aggregation association with Video. I.e, VideoStore is the container and the Video is the contained object.

So, we caninstantiate video object-in-VideoStore-elass Example diagram Creator

ideoStore

Video

title

Example for creator


VideoStore

Video

Create

Create

3)Infomation Expert

Given

an object o, which responsibilities can be assigned to o? >Expert principle says assign those responsibilities to o for which o has the in formation to fulfill that responsibility. They have all the information needed to perform -

operations, or in some cases they collaborate with others to fulfill their responsibilities. Example for Expert Assume we need to get all the videos ofa VideoStore. Since VideoStore knows about all the videos, we can assign this responsibility of giving all the videos can be assigned to VideoStore class. VideoStore is theinformationexpert Example for Information Expert

VideoStore getAllVideos0

Video

title

Example for Information Expert Infomation Expert

VideoStore

about all the videos

getAlVideos)

4)Low Coupling

to each other? strongly the objects are connected Coupling-object depending on other object. changes, it affects the dependant also. upon elements n When depended upon element in depended ofchange impact reduce the Ceuping--How-can-we

How

Low

low. dependant elements. responsibilities so that coupling remain assign and code reusable. Prefer low coupling making system maintainable, efficient hence dependency Minimizes the Two elements are coupled, if aggregation/composition One element has association with another element. implements/extends other element. One element -


Example for poor coupling

YIdeop0

Rentviieo -get'deoj

gotaxdeo s0

tte)

getqt:te) VIJeg

here class Rent knows about both Video Store and Video objects. Rent is depending on both the classes. Example for low coupling VideoStore and Video class are coupled, and Rent is coupled with Video Store. Thus providing low coupling.

RentvidEO getVideoftite)

VideoStore

getAiideos)-

getvideo(titte)

Video

5)Controller Deals with how to delegate the request from the Ul layer objects to domain layer objects. when a request comes from UI layer object, Controller pattern helps us in determining what is that first object that receive the message from the Ul layer objects. This object is called controller object which receives request from UI layer object and then controls/coordinates with other object of the domain layer to fulfill the request. delegates the work to other class and coordinates the overall It activity. We can make an object as Controller, if


t reNENNIS the overali systenm (tacade controller) -Oniat ,NOSNI a ue cA niing a squrnde ot opertions (session controiler). -an S

n an

this cntnoller elass use to amam the state of the us Case. entrN zhe sqEne ofthe activitiss

Example for Controller

5}High Cohesion How are the operations of any element are functionally related? Related responsibilities in to one manageable unit. Prefer high cohesion Cearly deines the purpose of the element Benefits Easily understandable and maintainable. -Code reuse Low coupling Example for low cohesion

Student gerstunDetatsO

acressDE0. DEcars0

nse:tDSO


D

udo Student

Example Cohesion

for High getStudentDetail S0

**

insert(student)****

KaccessDe0, DBcalls0

insertDB(data)

7) Designing for Visibilty In common usage, visibilityis the ability

of an object to "see" or have a reference to another object. More generally, it is related to the issue of scope: Is one resource (such as an instance) within the scope of another? There are four common ways that visibility can be achieved from object A to object

B:

.

Atribute visibility- B is an attribute of A. 2. Paruneter visibility- B is a parameter of a method of A. 3. Local

visibility-B is a (non parameter) local object in a method 4. Global visibility-B is io some way globally visible. -

of

A

Attribute Visibility:-

Auribute visibility from A to B exists when B is an attribute ofA. It is a relatively permanent visibility because it persists as long as A and B exist. This is a very common form of visibility in object oriented systems.

Parameter Visibility;Parameter visibility from A to B exists when B is passed as a parameterto a method relatively temporary visibility because it ofA. It isa persists only within the scope of the method. After attribute visibility, it is the second most common form of visibility in object oriented systems.

Local Visibility


hility from A to B exists when B is declared as a local object Local within a method of A. It is a vis because it persists only within the scope clatively temporary visibility of the method. After paramete visibility, it is the third most common form of visibility in

ter

object oriented systems. -

Two Common

means

by \which

local

visibility is aclhieved arc

Create a new local instance and assign it to a local variable. Assign the returning object from a method invocation to a local A

vith parameter visibility, it

visibility. Global

IS

variable.

common to transtorm locally declared visibility into attribute

Visibility:-

Clobal visibility from A to B exists when B is global to A. It isa relatively permanent visibility hecause it persists as long as A and B exist. It is the least common form of visibility in

object

systems.

oriented One way

-

to achieve global visibility is to assign an instance to a global variable, which is possible in

some languages.

such as C++, but not others, such as Java.

UNIT-V 1) State Diagrams (or) State chart diagrams state diagram is used to represent the condition of the system or part of the system at finite instances of time. State diagrams are also referred to as State machines and State-chart Diagrams. These terms are often used interchangeably. So simply, a state diagram is used to model the dynamic behavior of a class in response to time and changing external stimuli. A

Uses

of state chart diagrams:-

use it to state the events responsible for change in state (we do not show what processes cause those events). We use it to model the dynamic behavior of the system. understand the reaction of objects/classes to internal or external stimuli.

We

To

User Identifiec

Start

PIN

Card Swiped

authentication

PIN Entered

waiting for PIN

PIN Veritication

PIN Rejected

Figure

-

a

state diagram for user verification


C 0agram above shows the diflerent states for a particular system.

in

sub-systcn which the verification

or ciss

exist

Basic components of a statechart diagram:

state - We

nital

initial state of a System or a Class. use a black filled circle represent the

Figure 2.

initial state notation

We use a solid arrow to represent the transition or change of control from one state to another. The arrow is labelled with the event which causes the change in state.

Transition

-

Event

State2

State1

Figure transition 3.

use a rounded rectangle to represent a state. A state represents the conditions circumstances of an object of' a class at an instant of time.

State-We

or

State

Figure- state notation 4.

Fork- We use a rounded solid rectangular bar to represent

arrow

a Fork

notation with incoming

from the parent state and outgoing arrows towards the newly created states. We use the fork notation to represent a state splitting into two or more concurrent states.

StaleA

StaleB

Statec


Figure-a diagram

inal

using

the fork notation

state - We use a

tilled circle within a circle notation to represent the final state in a state machine diagram.

final state notation

Figure Steps to draw

a state diagram:

Identify the initial state and the final terminating states. 2, Identify the posible states in which the object can exist (boundary values corresponding to different attributes guide us in identifying different states). 3. Label the events which trigger these transitions. 1.

xample-state diagram for an online order-

Grcer Recer

Unprocessed

Oids

ejec

acce

Crecked

ocked

Rejected Orce

Accepted Orde

Some tems

some ems noi avaliablt

2vailable]

Processed

rcessed delver Fu1illed Orde

Pending Oide

all tens available

Figure - state diagram

for an online order

JOperation Contracts Use Cases often fully describe Operation

l. be enough. the behaviour of a system But they may not concepts in the Domain Model may of Contracts describe how the internal state the

change. Operation Contracts are described

in

conditions. terms of preconditions and post


Writing Operation Contracts Operation-name of operation (parameters) operation contract occlu Cross Reference--the Use Cases in which the objects in domain modelling or system of 3. Pre conditions-noteworthy assumptions about state

.

before execution 4. OST Conditions-state of objects 'or example

in

execution of operation domain modelling after

consider the following operation contract:

Contract C02: enterltem Operation: Cross References: Preconditions:

Postconditions:

enterltem(itemlD: ItemlD, quantity: integer) Use Cases: Process Sale There is a sale underway. -

A

-

sli

-

SalesLineltem instance

sli

was created (instance cre-

alion). was associated with the current Sale (association formed). sli.quantity became quantity (atribute modification). sli was associated with a ProductDescription, based on

iternID malch fassociation formed)

PsoessSale Scsnatn System

GIshier makeNew Salef)

loopniore tems]_

_

enterllemtemilD, quinttA

hese input yslem

ovenls

YOLe sysem opotaticns

--

----65Enpbon total.

the 2ystem.rrent enterllem ivokes a Ylcm openon

cald enterllem and so torth

endSale) totalwith Lxes.

makePayment(amoun

-.nge du, recept

Tus s the same as in objoct onenled programmirg wthen we sy he mesiag2 Ioo urvokes the method.(handling operabon) oo


aNUML Deployment

Diagrams

onloyment diagrams are used to visualize the topology of the physical components Depl of a svstem, wlhere the soitware components are deployed. lovment diagrams are used to describe the static deployment view of a system. D Denloyment diagrams consist of nodes and their relationships. diagrams are usetul tor system engineers. nent diagrams Deployment

parameters inmportantas-it-contrOis-tne-following

An efficient deployment diagram is very

Performance Scalability Maintainability Portability

Before drawing a deployment diagram, the following artifacts should be identified Nodes

Relationships among nodes

a

Following is sample deployment diagram to provide an idea of the deployment view of order management system. Here, we have shown nodes as:

Monitor Modem Caching server Server in assumed to be a web-based application, which is deployed a clustered connects to the application using the environment using server 1, server 2, and server 3. The user clustered environment. Internet. The controlHlows from the caching server to the

Theapplication

The following

is

all the points mentioned above. deployment diagram has been drawn considering Deployment

dngram

of

an

order

ma*gemont

system

Internet

Connection Modemn -

<<Processo> server Cachlng

User

Server

Serveri

Server2

Nodes


Uses

of Deplovment DiagranI1S

a system.

To model the hardware topology of To model the embedded systcm. system. for a client/scrver To model the hardware details application. distributed To model the hardware details ofa For Forward and Reverse engincering.

AUML Component Diagrams is also different from all other purpose The components used to Omponent diagram is a special kind of diagram but it describes the system the functionality tlhe of dlagrams. It does not describe make those functionalities. in UML.

used to visualize the physical irom that point of view, component diagrams are system. These components are libraries, packages, files, etc.

components

in a

hus

view of a system. Static Component diagrams can also be described as a static implementation moment. implementation represents the organization of the components at a particular

ASingle tomponent

diagram-cannot-represent-the-entire-system-but-a-collection-of-diagrams-is-used-

to represent the whole.

The purpose of the component diagram can be summarized as Visualize the components of a system. Construct executables by using forward and reverse engineering. Describe the organization and relationships of the components.

This diagram is very important as without it the application cannot be implemented efficiently. A

well-prepared component diagram is also important for other aspects such as application performance, maintenance, etc. Before drawing a component diagram, the following artifacts are to be identified clearly Files used in the system. Libraries and other artifacts relevant to the application. Relationships among the artifacts.

After identifying the artifacts, the following points need to be considered:

. Use a meaningful name to identify the component for which the diagram is to be drawn. Prepare a mental layout before producing the using tools. Use notes for clarifying important points.

Following-is a-component.diagram fororder management system. Here, the artifacts are files. The diagram shows the files in the application and their relationships. In actual, the component diagram also contains dlls, libraries, folders, etc. In the following diagram, four files are identified and their relationships are

produced. Component diagram cannot be matched directly with other UML diagrams discussed so far it as is drawn for completely different purpose.


component diagram been dea.. nas been diagram has drawn considering all the points mentiohed e following above. Component diagram

Ava

of pn order

management system

files

Order.java

Custemer.Java

SpecialOrder.java

ComponentsK

Normal0rder.java

ses

of Componentdiagrams

Model Model Model Model

the components of a system. the database schema. the executables of an application. the system's source code.


Turn static files into dynamic content formats.

Create a flipbook
Issuu converts static files into: digital portfolios, online yearbooks, online catalogs, digital photo albums and more. Sign up and create your flipbook.