Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Lecture 5 OOAD

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 65

Chapter

Five
OOA and
OOD
Object oriented analysis(OOA)

 OOA : is a method of analyzing a system or problem


domain by visualizing it as a group of interacting objects.

 OOA is a method of analysis that examines requirements from


the perspective of the classes and objects found in the
vocabulary of problem domain.

 Requirements are organized around objects, which integrate


both
data and functions.
Cont’d
 The primary task in object oriented analysis 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.

 Defining how the object interact.

 The common models used in OOA are use cases and object
models.
Object oriented design(OOD)
 OOD: involves implementation of conceptual model produced
during object oriented analysis(OOA).
 Is a method of design encompassing the process of object oriented
decomposition and a notation for depicting both logical and
physical as well as static and dynamic models of the system under
design.
 The implementation generally include:-
 Restructuring the class data.
 Implementations of methods i.e. internal data structures and
algorithms.
 Implementation of control.
 Implementation of associations.
Object oriented
programming
 OOP: is a programming paradigm based upon objects(having both

data and methods) that aim to incorporate the advantage of

modularity and reusability.


OO
Concepts
Objects
 Are instances of classes and represent real world entities
in the problem domain.
For example, person, banks, company, and c ustomers
are treated as objects.
 Every entity has some attributes (properties) associated to
it and has some behaviors ( methods) to perform on the
attributes.
Cont’d
Classes

 Are blueprint for creating objects.

 A class is a generalized description of an object. An object is an


instance of a c lass

 Class defines all the attributes, which an object can have and
methods, which defines the functionality of the object.

 In the solution design, attributes are stored as variables and


functionalities are defined by means of methods or procedues .
Cont’d

Encapsulation

 In OOD, the attributes (data variables) and methods (operation on


the data) are bundled together is called encapsulation.

 Class defines all the attributes, which an object can have and
methods, which defines the functionality of the object.

 In the solution design, attributes are stored as variables and


functionalities are defined by means of methods or
procedures.

 Encapsulation not only bundles important information of an object


together, but also restricts access of the data and methods from
Cont’d
Inheritance
 OOD allows similar classes to stack up in hierarchical manner
where the lower or sub-classes can import, implement and re-
use allowed variables and methods from their immediate super
classes.

 This property of OOD is known as inheritance.

 It makes it easier to define specific class and to create


generalized classes from specific ones.
Cont’d
Polymorphism
 OOD languages provide a mechanism where methods
performing similar tasks but vary in arguments, can be
assigned same name.
 This is called polymorphism, which allows a
single interface performing tasks for different
types.
 Depending upon how the function is invoked, respective
Unified Modelling language
(UML)
 Is a standard language for specifying, visualizing, constructing
and documenting the artifacts of a software systems.

 Is a pictorial language used to make software blueprints.

 Can be described as a general purpose visual modeling


language to visualize, specify, construct and document
software systems.

 UML is not programming language but tools can be used to


generate code in various languages using UML diagrams.
Cont’d

 Structure Diagrams: A structure diagram describes things that wil be in

the system you are designing.

 For example, the class diagram (one type of structure diagram) shows

relationships among the classes that wil represent objects in the system

.
Types of Struc ture
 ClassDiagrams
Diagram:-Describes the classes that make up the system, their
properties and methods, and their relationships.
 Object Diagram:-Focuses on a particular set of objects and their
relationships at a specific time.
 Component Diagram:-Shows how components are combined to form
larger parts of the system.
 Composite Structure Diagram:-Shows a class’s internal structure and
the collaborations that the class allows.
 Package Diagram:-Describes relationships among the packages that make up a system.
 Deployment Diagram:-Describes the deployment of artifacts (files, scripts ,executable, and
the like) on nodes (hardware devices or execution environments that can execute
Cont’d
 Behavioral Diagrams. UML defines three kinds of basic behavior diagrams: activity
diagrams, use case diagrams, and state machine diagrams.

 Activity Diagrams. An activity diagram represents work flows for activities. They
include several kinds of symbols connected with arrows to show the direction of
the work flow.
Cont’d
 Activity Diagram for Baking
Example Cookies
Cont’d
 Use Case Diagram. A use case diagram represents a user’s interaction
with the system. Use case diagrams show stick figures representing actors
(someone or something that performs a task) connected to tasks
represented by elipses.
 To provide more detail, you can use arrows to join subtasks to tasks. Use
the annotation <<include>> to mean the task includes the subtask. (It
can’t take place without the subtask.)
 If a subtask might occur only under some circumstances, connect it to
the main task and add the annotation <<extend>>.
 If you like, you can add a note indicating when the extension occurs.
(Usualy both <<include>> and <<extend>> arrows are dashed.)
Cont’d
 A use case diagram shows actors and the tasks they perform
(possibly with subtasks and extensions).
 Sequence Diagram. Is a type of interaction diagram in UML that
illustrate the flow of messages and interactions between objects or
components in a specific scenario.

 It provide dynamic view of the system, showing how


objec ts c ollaborate to ac hieve a particular func tionality over
time.
Cont’d
 A sequence diagram shows the timing of messages between make a
phone call.
 Communication Diagram. Like a sequence diagram, a
communication diagram shows communication among objects
during some sort of collaboration. The difference is the sequence
diagram focuses on the sequence of messages, but the
communication diagram focuses more on the objects involved in
the collaboration. Below is a communication diagram emphasizes
the objects participating in a collaboration.
Use Case Diagrams
 What is a use case?

 A requirements analysis concept

 Is graphical representation in UML that depicts the


interaction between various actors and a system
under consideration.
 Describes the system's actions from the point of view
of auser
 Tells a story

 Is oriented toward satisfying auser's goal.


Cont’d
 How do we describe use case?

 Textual or tabular descriptions


 User stories
 Diagrams

 UseCase key elements


 actors – represent role played by a user or any other system being modeled.
something with abehavior or role, e.g., aperson, another system, organization.

 use case –represents a specific functionality or behavior of the system that


provide value to one or more actors.

 Associations: Lines connecting actors to use cases represent associations,


indicating that an actor is involved in or interacts with a particular use case.

 System Boundary: a system boundary, which is a box that encloses the use cases.
Finding an actor?
 Ask the following questions:
Who are the system’s primary users?
Who requires system support for daily tasks?
Who are the system’s secondary users?
What hardware does the system handle?
Which other(if any)systems interact with the system in question?
Do any entities interacting with the system perform multiple roles
as actors?
Which other entities(human or otherwise) might have an interest in
the system's output?
Finding an
actor?
External objects that produce/consume data:
Must serve as sources and destinations for data
Must be external to the system
Example Use-Case Diagram
Linking Use Cases
Association relationships

Generalization relationships
One element (child) "is based on" another element (parent)

Include relationships
One usecase(base) includes the functionality of another(inclusion
case)
Supports re-use of functionality

Extend relationships
One use case (extension) extends the behavior of another (base).
1.
Generalization
The child use case inherits the behavior and meaning of the
parent use case.

The child mayadd to or override the behavior of its parent.


Generalization Example
Example Exercise
 University Registration System

Professors indicate which courses they will teach online.

 Acourse catalog can be printed.

Allow students to select online four courses for upcoming semester.

No course may have more than 10 students or less than 3

students.
When the registration iscompleted,the system sends information

to the billing system.


Professors can obtain course rosters online.

 Students can add or drop classes online.


University Registration System
Class
is diagrams
a type of static structure diagram that represents the structure of a
system by depicting the classes, their attributes, operations, and the
relationships among them.

Represent the basics of Object-Oriented systems

Identify what classes there are, how they interrelate and ,

Capture the static structure of Object-Oriented systems – how systems

are structured rather than how they behave.

Constrain interactions and collaborations that

support functional requirements.


Link to Requirements
Basic Class Compartments
Name

Attributes
represent the state of an object of the class.
are descriptions of the structural or static features of a class.

Operations
define the way in which objects may interact.
are descriptions of behavioral or dynamic features of a class.
public class Employee {
public string name;
private string address;
public int employeeNumber;
private int socialSecurityNumber;
public string department;
private int salary;
private string taxCode;
public string status;
public void join() {}
public void leave() {}
public void retire() {}
public void changeInformation() {}
Derived
Attributes
Visibility
public(+)visibility means that the feature is
available to any class associated with the class that owns the
class.

protected (#) visibility means that the feature is available within

the class∼)that
package( owns means
visibility that feature andfeature
that the any subtype of that
is available class.
only to
other classes in the same package as the declaring class (and the
declaring class itself).
private (-) visibility means that the feature is available only within
the class that owns that feature.
Multiplicit
y
Multiplicity specifies how many instances of the attributes type are
referenced by this attribute.
[n..m] – n to minstances
0..1 – zero or one instance

0..* or * – no limit on the number of instances (including none)


1 – exactly one instance
1..* – at least one instance
Class Relationships

Dependency: objects of one class work briefly


with objects of another class.
Association: objects of one class work with
objects of another class for some prolonged
amount of time. Bidirectional.
Aggregation: one class owns but share a
reference to objects of other class. whole part
r/ship. E.g car ..wheel
 C omposition: one class contains objects of
another class. Strong composition. Eg university ..
Dept’t
 Generalization (Inheritance): one class is a
type of another class. Is a r/ship. Vehicle and car.
Dependenc
y
Associatio
n
Aggregati
on
Compositio
n
Generalization (Inheritance)
Sequence
Diagrams
Sequence Diagrams are interaction diagrams that detail how operations
are carried out.
Is a UML diagram that illustrates the sequence of messages between
objects in an interaction.

Interactions Diagrams
Sequence diagrams
Interaction overview diagrams
Timing diagrams
Communication diagrams
Sequence Diagrams Dimensions
Time. The vertical axis represents time proceedings (or progressing) down the page.

Note that Time in a sequence diagram is all a about ordering, not duration. The

vertical space in an interaction diagram is not relevant for the duration of the

interaction.

Objects. The horizontal axis shows the elements that are involved in the interaction.

Conventionally, the objects involved in the operation are listed from left to right

according to when they take part in the message sequence. However, the elements

on the horizontal axis may appear in any order.

Lifelines: represent the objects participating in an interaction. Eg in banking

scenario lifeline can be banking system or a customer.


Object Types
 The object types used in this analysis model are entity objects,
interface objects and control objects.
How to Produce Sequence Diagrams
Decide on Context: Identify behavior (or use case) to be specified

Identify structural elements

Model objects (classes)

Model lifelines( vertical doted lines)

Model activations( thin rectangle on lifeline representing period of an

operation)
Model messages(call and return messages)

Model Timingconstraints

Refine and elaborate as required


EXAMPL
E
Steps to Analyze and Design Object Oriented System
 Design of a Library Management System (LMS)
 The steps
Example
LMS
 A software has to be developed for automating the manual library of a
University. The system should be stand alone in nature. It should be
designed to provide functionality’s as explained on the next slides.
Issue of Books
 A student of any course should be able to get books issued.

 Books from General Section are issued to all but Book bank books are issued only
for their respective courses.
 A limitation is imposed on the number of books a student can issue.

 A maximum of 4 books from Book bank and 3 books from General section is issued for
15 days only.
 The software takes the current system date as the date of issue and calculates date of
return.
 A bar code detector is used to save the student as well as book information.

 The due date for return of the book is stamped on the book.
Return of Books
 Any person can return the issued books.

 The student information is displayed using the bar code detector.

 The system displays the student details on whose name the books
were issued as well as the date of issue and return of the book.
 The system operator verifies the duration for the issue.

 The information is saved and the corresponding updating take place in the
database.
Query Processing

The system should be able to provide information like:


 Availability of aparticular book.
 Availability of book of any particular author.
 Number of copies available of the desired book.
Furthermore

 The system should also be able to generate reports regarding the details
of the books available in the library at any given time. The corresponding
printouts for each entry (issue/return)made in the system should be
generated. Security provisions like the ‘login authenticity should be
provided. Each user should have auser id and a password. Record of the
users of the system should be kept in the log file. Provision should be
made for full backup of the system.
Solution 1: Design Use Case
Diagram
 UseCaseDiagramof LMS
Sequence Diagram:
Login
Sequence Diagram: Issue Book
Sequence Diagram: Return
Book
Sequence Diagram: Query
Book
Sequence Diagram: Maintain
Catalog
Sequence Diagram: Generate
Reports
Sequence Diagram: Maintain
Login
Sequence Diagram: Maintain Student
Details
Class Diagrams of Entity Classes
THANK
YOU !!!!

You might also like