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.