SAD_CHAPTER4

Download as pdf or txt
Download as pdf or txt
You are on page 1of 50

System Analysis and

design

Chapter 4: Understanding the Basics:


Object oriented concepts
Learning outcomes

After completing this chapter students are expected to:


 Discuss software development methodologies
 Differentiate object oriented development from
Structured SAD
 Understand the concept of Object Orientation
 Define major principle object oriented development
 Identify various relationship used in object
orientation
OO concepts from structured point of view

 Selecting a methodology is not simple, as no one


methodology is always best
 Many organization have also their own standards &
policies to guide the choice of methodology.
 To decide w/c methodology to use may depend on
 E.g, systems nature, constraints, and rules
 Your experience as analyst is important to compare
and decide which methodology to use
 D/f types of system development methodologies
 Structured, Object-Oriented, RAD, Agile
Methodologies
OO concepts from structured point of view

Criteria for Selecting a Methodology


 Clarity of user requirements
 Familiarity with technology
 System complexity
 System reliability
 Short time schedules
Structured Analysis and Design

 Developed late 1970s by DeMarco, Yourdon, and


Constantine, after structured programming
 In 1990s CASE tools enabled analysts to develop
and modify the graphical SSAD models
 Traditional system development technique, time-
tested and easy to understand
 Uses a series of phases, called SDLC, to plan,
analyze, design, implement, and support an IS
 Predictive approach, organized into phases, with
deliverables and milestones to measure progress
Structured Analysis and Design

Major principles
 Functional view of the system
Modularization
 Divide large, complex problems into smaller, more
easily handled ones
Hierarchy
 Top-down approach
 Define all the tasks or processes in a system from
top to bottom in increasing levels of detail
Structured Analysis and Design

 Processes and data are treated as two separate


components
 Can be either process- or data-centered
 Use modeling techniques to describe the basic
business processes and data that support them
 B/c two sets of diagrams are used, analyst must
decide w/c set to develop first and use as the core of
the system—process-or data model diagrams
 There is debate over w/c should come first,
processes or data, b/c both important to system
Object Oriented Analysis and Design

 OO analysis and design become popular b/c


 Represent data and process together, object
 Objects may represent actual people, things, concept
transactions and events…etc.
 Views the system in terms of objects that combine
data and processes that act on the data together
 Decompose the system according to key abstractions
in the problem domain (domain objects)
 Model the structural and behavioral aspects of
objects as they interacts each other
Object Oriented Analysis and Design

Analysis Phase
 Model of the problem domain is developed showing
its important properties
 Develop an object model of the application domain
 Object models represent data and behavior, and
show how objects affect other objects
 Model specifies the functional behavior of the
system independent of implementation details
 Use-case, Class, Sequence, & Activity diagrams
Object Oriented Analysis and Design

Design Phase
 Analysis model is refined and adapted to the
environment
 Class Modeling, State & Collaboration diagrams
Can be separated into two stages
 System design
 Concerned with overall system architecture
 Object design
 Implementation details are added to system design
 Component diagram, Deployment diagram
Object Oriented Analysis and Design

Summary
Object Oriented Analysis and Design

 Why object orientation?


 Software complexity rises exponentially
 Need for tools to deal with complexity
 Object-oriented techniques work well with
 Complex systems undergoing continuous
maintenance, adaptation, and design
 Deal the complexity inherent in a real-world
problem by focusing on essential features of an
application
 Closer to the way problems appear in life (physical
and non-physical), business processes & operation
Object Oriented Analysis and Design

 Object-Oriented SAD blend analysis and design in


iterative and incremental processes
 Functionality of system is developed in a successive
series of releases of increasing completeness
 A release may be external (available to the
customer) or internal (not available to the customer).
 Selection of what functionality is developed in each
iteration is driven by mitigation of project risks,
 The experience and results gained as a result of one
iteration are applied to the next iteration.
Object Oriented Analysis and Design

 OO SAD usually follow a series of analysis & design


phases similar to SDLC, named Unified Process (UP)
Phases
 inception, elaboration, construction, & transition
Workflows
 business modeling, requirements, analysis and design,
implementation, test, deployment
 Each phase organized into a no. of separate iterations
 Each phase has objectives, a focus of activity over the
workflows, and incremental deliverables.
The Unified Process (UP)…
The Shifting Focus of Iterations
Our Approach to Systems Development

 The SDLC is an organizing and guiding principle


that will be used in this course.
 We will construct artificial boundaries or artificially
separate activities & processes for learning
purposes.
 E.g. Analysis & design phased discussed separately
 The intent is to help you understand all the pieces
and how to assemble them.
Our Approach to Systems Development
Our Approach to Systems Development

Inception
 Defining the scope, determining the feasibility,
understanding user requirements, preparing a
software development plan
 Relatively short, low resource requirements
 Focus on planning and analysis
Elaboration
 Detailed user requirements and baseline
architecture is established
 Fairly long, but not high in resource demand
 Focus on analysis and design
Our Approach to Systems Development

Construction
 Coding, testing, and documenting code
 Longest and most resource-intensive
 Focus is on implementation tasks
Transition
 System is deployed and users are trained and
supported
 Short-term, but resource-intensive
 Focus is on installation, training, and support
Our Approach to Systems Development
OO Principales

1: Abstraction
 A process allowing to focus on most important aspects
while ignoring less important details.
 Abstraction allows us to manage complexity by
concentrating on essential aspects making an entity
different from others
2: Encapsulation
 Encapsulation separates implementation from
users/clients.
 A client depends on the interface
3: Modularity
 Modularity breaks up complex systems into small, self-
contained pieces that can be managed independently.
OO Principles

 4.Hierarchy
Inheritance

 Inheritance can be defined as the process where one


object acquires the properties of another.
 With the use of inheritance the information is made
manageable in a hierarchical order.
 Objects that are derived from other object "resemble"
their parents by inheriting both state (fields) and
behavior (methods).
 Defining a new class based on existing class.
 The new class or derived class is referred to as a sub
class of the class from which it is derived.
 The original class is called base class
Polymorphism

 Ability to dynamically choose the method for an operation at


run-time or service-time
 facilitated by encapsulation and generalization:
 Encapsulation –separation of interface from implementation
 Generalization –organizing information such that the shared
features reside in one class and unique features in another
 Operations could be defined and implemented in the super-class,
but re-implemented methods are in unique sub-classes
Basic concepts of an object

What is an object?
1) Any abstraction that models a single thing
2)A representation of a specific entity in the real
world
3) May be tangible (physical entity) or intangible
Examples: specific citizen, agency, Job, location, order,
etc.
Basic concepts of an object
Object Definition

Two aspects:
Information:
1) has a unique identity
2) has a description of its structure
3) has a state representing its current condition
Behaviors:
1) what can an object do?
2) what can be done to it?
Object Definition
Class

What is a class?
1) Any uniquely identified abstraction of a set of
logically related instances that share similar
characteristics
3) A definition or template that describes how to build
an accurate representation of a specific type of objects
Examples: agency, citizen, car, etc.
 Objects are created using class definitions as
templates
Class
Attribute

 Attribute is a named property of a class describing a range of


values that instances of the class may hold for that property.
 An attribute has a type and defines the type of its instances.
 Only the object is able to change the values of its own
attributes.
 The set of attribute values defines the state of the object
Operation
 Operation is the implementation of a service that can be
requested from any object of a given class.
 An operation could be:
1. A question - does not change the values of the attributes
2. A command – may change the values of the attributes
Attribute
Interface

 The mechanism by which users of a component


invoke its behaviors and manipulate its properties
 The behavior of a class or component that is
noticeable from outside the class or component
 The minimum information required to use an object
 Allows users to access the object’s knowledge
 Must be exposed or visible
 Provides no direct access to object internal
 The interface is implemented by method signatures
Component

 A replaceable part of a system providing a clearly


defined function through a set of interfaces
 Group of classes working together toward a
common end, a subsystem
Package

 A logical grouping of related analysis or design


elements
 Group of classes sharing similar characteristics or
purposes
Relationship

 The relationships can be b/n classes or objects


 Most commonly, relationships b/n classes
 Associations: No ownership, only semantic
dependency
 Aggregations: Parts exist independent of the whole
 Compositions: Parts & the whole dependent each
other
 Generalization: Abstraction of common features
among multiple classes, as well as their
relationships, into a more general class
Association

 Models only a semantic connection among classes


 Degree may be unary, binary, ternary or higher
 Showed as a solid line between participating classes
Role
 The role each class plays in relationship with the other
Multiplicity
 Indicates how many objects participate in a given r/n
Association Class
 An association that has attributes or operations of its
own, or that participates in relationships with other
classes
Association
Aggregation

 Sometimes an object is made of another object


 E.g, computer: input, output, & storage devices
 It’s a restrictive form of ―is part of‖ association
 Part objects can be physically or logically assembled
 The aggregate object coordinates its part
 Defines a single point of control for participating objects
Composition

 Stricter form of aggregation


 Lifespan of individual objects depend on the lifespan of the
aggregate object
 Parts can not exist on their own
 There is a create-delete dependency of the parts to the whole
 Example
Generalization
 Inheritance exists to express generalization r/n
 Equivalent to ―kind-of‖ or ―type-of‖ relationship
 A relationship between a more general (or parent) class and a more
specific (or child) class
 A sub-class inherits all the attributes & operations from its super-class
by default
 may add new attributes or operations of its own
 A process of organizing the features of different kinds of objects that
share the same purpose
Dependency
 Non-structural, ―is using‖ relationship
 It indicates that an element on one end of the r/n, in some manner,
depends on element on the other end
 A relationship between two model elements where a change in one
may cause a change in the other
 Often used in architectural models (b/n components or packages) or
implementation level (b/n modules)
 There are many different kinds of dependency relationships
Realization

1. Allows a class to inherit from an interface class without being a sub-


class of the interface class
2. Only inherits operations
3. Cannot inherit attributes or associations
Super-Class/Sub-Class
 Super-Class is a class that contains the features common to two
or more classes.
 A super-class is similar to a superset, e.g. agency-staff
 Sub-Class is a class that contains at least the features of its super-
class(es).
 A class may be a sub-class and a super-class at the same time, e.g.
management-staff
Abstract Class
1. a class that lacks a complete implementation - provides operations
without some implementing methods
2. cannot be used to create objects; cannot be instantiated
3. a concrete sub-class must provide methods for unimplemented
operations
Super-Class/Sub-Class
 Super-Class is a class that contains the features common to two
or more classes.
 A super-class is similar to a superset, e.g. agency-staff
 Sub-Class is a class that contains at least the features of its super-
class(es).
 A class may be a sub-class and a super-class at the same time, e.g.
management-staff
Abstract Class
1. a class that lacks a complete implementation - provides operations
without some implementing methods
2. cannot be used to create objects; cannot be instantiated
3. a concrete sub-class must provide methods for unimplemented
operations
Coupling

 Coupling is the degree of interdependence between


software modules
 A measure of how closely connected two routines or
modules are; the strength of the relationships between
modules.
 Coupling is usually contrasted with cohesion.
 Low coupling often correlates with high cohesion, and
vice versa.
 Low coupling is often a sign of a well structured
computer system and a good design, and when
combined with high cohesion, supports the general goals
of high readability and maintainability
Cohesion

 Cohesion refers to the degree to which the elements


of a module belong together.
 Thus, cohesion measures the strength of relationship
between pieces of functionality within a given
module.
 For example, in highly cohesive systems
functionality is strongly related.
 Cohesion is an ordinal type of measurement and is
usually described as ―high cohesion‖ or ―low
cohesion‖
Patterns

 It is an instructive information that captures the


essential structure and insight of a successful family
of proven solutions to a recurring problem that
arises within a certain context and system of forces.
Good Pattern will do the following:
 It solves a problem.
 It is a proven concept.
 The Solution is not obvious.
 It describes a relationship.
 The pattern has a significant human component
Thank you!
Questions?

You might also like