design paradigms fop and oop n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Design Paradigms, FOP, and OOP PowerPoint Presentation
Download Presentation
Design Paradigms, FOP, and OOP

Loading in 2 Seconds...

play fullscreen
1 / 44

Design Paradigms, FOP, and OOP - PowerPoint PPT Presentation


  • 112 Views
  • Uploaded on

Design Paradigms, FOP, and OOP. To understand component-orientation means we need to understand how components came about. Q: Why did it surface? Q: What was happening before? Q: What wasn’t working?. Design paradigms have, and continue to, evolve. Function- Oriented . Object-Oriented .

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Design Paradigms, FOP, and OOP' - jett


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
to understand component orientation means we need to understand how components came about
To understand component-orientation means we need to understand how components came about.

Q: Why did it surface?

Q: What was happening before?

Q: What wasn’t working?

design paradigms have and continue to evolve
Design paradigms have, and continue to, evolve.

Function- Oriented

Object-Oriented

Component-Oriented

is design a science
Is design a science?

Scientific Process

Design Process

Observations

Requirements

Hypothesis

Design

refine

refine

Experiment

Verify

Accepted Theory

Accepted Design

Analytic, Repeatable, Describing what is, Have truth

Creative, Describing what will be,

No truth – it hasn’t been formed

design is a wicked problem
Design is a wicked problem.
  • Hard to define problems
  • No stopping rules
  • Good vs. Bad, not True vs. False
  • Solution space is not well-ordered
  • Solution is “one-shot”
a design method is a way of capturing and communicating a design
A design method is a way of capturing and communicating a design.

Requirements

Representation

Process

Heuristics

Design

Constraints

Design Methodology

Implementer

Domain Knowledge

Designer

design methodologies come into play when we think about systems
Design methodologies come into play when we think about systems.

Function-Orientation

Object-Orientation

Component-Orientation

Batch

Reactive

Concurrent

function orientation can be characterized as
Function-orientation can be characterized as…
  • Basic building block : function
  • Action driven
  • Static binding
  • Great at modeling data processing
  • Weak at control modeling
  • Heavy use of global data
  • Functions logically, not physically, bound to data they operate
key ideas identified in the late 60s early 70s that function orientation didn t address
Key ideas identified in the late 60s/early 70s that function-orientation didn’t address.

1940s

1970

1980

2000

Coupling & Cohesion

1974 – Stevens, Myers, Constantine“Structured Design”

Reuse

1968 – McIlroy

“Mass Produced Component Software”

Use of term “component”!

Stepwise Refinement

1971 – Wirth

“Program Development by

Stepwise Refinement”

Information Hiding

1972 – Parnas

“On the criteria to be used in decomposing systems into modules”

function oriented techniques evolved but they didn t naturally address all ideas
Function-oriented techniques evolved but they didn’t naturally address all ideas.
  • Stepwise Refinement
    • This was okay
  • Information Hiding
    • Forward declarations of hidden structures difficult to manage and extend
  • Coupling/Cohesion
    • Alone, functions could be loosely coupled / highly cohesive : +
    • Functions + data considered together poorly coupled/not cohesive : -
  • Reuse difficult at best
    • Too fine grain.
object based approaches emerged to tackle the reuse info hiding coupling cohesion in a natural way
Object-based approaches emerged to tackle the reuse, info. hiding, coupling/cohesion in a natural way.
  • Physically coupled functions and data
  • Viewed as a collection of interacting things
  • Things protected their data, enabled behavior via interface
  • Virtually no global data

data

interface

the object model adds a framework to the object concept g booch
The object model adds a framework to the object concept. (G. Booch)
  • Abstraction : describing external view
  • Encapsulation : information hiding
  • Modularity : packaging/interfacing
  • Hierarchy : interdependency : uses : structure : class
we can then describe the difference between object based and object oriented
We can then describe the difference between object-based and object-oriented.

Object Oriented

Object Based

- Abstraction

- Abstraction

- Encapsulation

- Encapsulation

- Modularity

- Modularity

- Uses hierarchy

- Uses hierarchy

- Class hierarchy

inheritance and polymorphism are in some sense dual concepts
Inheritance and polymorphism are (in some sense) dual concepts.
  • Inheritance
    • Design time
    • Establishes a “substitution policy”
  • Polymorphism
    • Run time
    • Performs the substitution
    • Ensures type correctness
polymorphism is powerful juju
Polymorphism is powerful juju.

b

A

B

A

: D

1

!

D

An instance of D can be used wherever an instance of B is expected.

polymorphism enables dynamic binding
Polymorphism enables dynamic binding.
  • Static binding : compiler “glues” references to objects
  • Dynamic binding : runtime “glues” references to objects
  • Flexibility is achieved by delaying binding as long as possible.
taking advantage of polymorphism in the design enables easier evolution of the system
Taking advantage of polymorphism in the design enables easier evolution of the system.

b

b

DiskUser

DiskDrive

DiskUser

DiskDrive

1

1

CDRW

CDRW

USB

so object oriented approaches have improved things but have not solved all the problems
So, object-oriented approaches have improved things but have not solved all the problems.

b

DiskDrive

DiskUser

1

Can’t do!

Type widening

Some languages are starting to provide support.

read (nBytes : int)

DVD

read (nBytes : long)

The problem is that we have a design time constraint with (traditional) OO approaches.

while oo improved reuse it still fell short
While OO improved reuse, it still fell short.
  • The model is class based, not service based.
    • Component orientation tries to solve this problem
    • Constraints on polymorphism are even further relaxed
  • OO languages not always sufficient to implement CO
    • Can do it on some level - like FO can mimic OO
    • CO languages exist but aren’t mainstream
oo evolved from fo to help support key practices
OO evolved from FO to help support key practices.
  • Information hiding
  • Coupling/Cohesion
  • Natural modeling of systems of interacting things
  • Changeability
  • Reusability
reuse at the object level was too fine grained
Reuse at the object level was too fine grained.
  • Dependencies were intricate and difficult to identify
  • Has to do with a tendency to depend on states and identity rather than services.
changeability limited by environment and often code in hand
Changeability limited by environment and often code in hand.
  • Extending systems requires some amount of code to extend
  • Have to work in a similar environment when doing the extensions
  • Changing elements of the system may require balancing delicate interactions – elements assume specifics of other elements.
the component definitions are varied but all generally agree on some level
The component definitions are varied but all generally agree on some level.

Wikipedia

Brown/Short

software package, or a module, that encapsulates a set of related functions (or data).

an independently deliverable set of reusable services

Szyperski

a unit of composition with contractually specified interfaces and explicit context dependencies that is independently deployable and subject to third party compositions

Heinemann/Councill

a software element that conforms to a component model and can be independently deployed and composed without modification according to a composition standard

Wallnau/Hissam/Seacord

a unit of software implementation that is produced by a vendor who sells/license its use to profit from that transaction; is released by its vendor in binary form; provides an interface that supports third-party integration with other components.

do components
Do components …

… need to be binary/executable?

… need to be part of a component model/composition standard?

… need explicit context dependencies?

a component is a unit of construction that
A component is a unit of construction that…

Has a well-defined interface

Encapsulates well-defined behavior

Is independently deployable

Is third party composable

we are trying to understand improve the reusability of components and changeability of our systems
We are trying to understand/improve the reusability of components and changeability of our systems.

New System

Existing System

A

D

B

?

C

E

we are going to see some changes happening
We are going to see some changes happening.
  • Less focus on development of full systems
  • Planning is crucial – and at different levels of abstraction
  • Documenting/describing the environment is now important.
with the shift away from development components must be coming from somewhere
With the shift away from development, components must be coming from somewhere.
  • Economy
    • A system of production, distribution and consumption
  • Market
    • A social arrangement to enable buyers and sellers to discover and exchange goods and services
component software is about the component market
Component Software is about the “component market”
  • Components exist in a market
  • Leads to necessary market factors
  • Describes change system life cycle
  • Discusses the technical factors that motivate/enable/prohibit market factors
while we need to understand the market to an extent we care more about
While we need to understand the market to an extent, we care more about…
  • Component philosophy
  • Technical considerations
  • Management of this complex space
let s talk a bit about the component market
Let’s talk a bit about the “component market”.

What enables business to be successful?

Competitive advantage

Reduced time to market

Focusing on what they do well

How do components help?

Component philosophy: reuse!

Businesses want to buy when it’s cheaper

Want customization

Reducing time invested in obtaining/installing apps is crucial

organizations gain a competitive edge when they have something useful others do not
Organizations gain a competitive edge when they have something useful others do not.

Cost Efficiency

Flexibility

Custom

COTS

Leveraging components is a balancing act

deciding what direction to go comes down to cost
Deciding what direction to go comes down to cost.

Need to reuse in-house development 3 times on average to recoup costs.

http://www.sei.cmu.edu/library/abstracts/news-at-sei/productlines4q03.cfm

component(s)

?

+

development

>

+

installation/

configuration

maintenance

+

maintenance

we can abstract the idea of component and consider a component spectrum
We can abstract the idea of component and consider a “component spectrum”.
  • Components are complex and often captured in views:
    • Requirements
    • Interfaces
    • Behaviors
    • Packaging
    • Code
    • Libraries

Concept

Executable

slide38
The process of creating a COTS component-based system involves different activities than development.
  • Define Requirements
  • Shop
  • Configure/Extend
  • Establish Deployment Infrastructure
  • Deploy in Test Environment
  • Put into production
  • Monitor vendor activities and roadmaps and continuously perform trade-offs
to get the component benefit we need a market
To get the component benefit, we need a market.
  • Buyers = demand
  • Sellers = supply
  • Obstacles:
    • Components need to be general but useful
    • Independence from context
    • Requires a common problem
    • Advertising / Discovery (componentsource.com)
    • Documentation
what kind of components are there how do we classify them
What kind of components are there? How do we classify them?

Framework-based

Application

Custom

COTS

Infrastructure

OS-based

Wallnau, Hissam, Seacord

“Building Systems from

Commercial Components”

to get the component benefit we need customization
To get the component benefit, we need customization.
  • Tools
    • Spotty. Some companies do a good job with their components (e.g., VxWorks)
  • Languages
    • No standard. XML-based ones have good potential.
to get the component benefit we need the infrastructure
To get the component benefit, we need the infrastructure.
  • Technologies for dynamic development and management
    • Some vendors are good in their space (.Net, J2EE)
    • Not universal which means homogenous solutions
    • Includes Quality of Service, testing, security
  • Late binding
to get the component benefit we need the infrastructure1
To get the component benefit, we need the infrastructure.

Standards : Vertical vs. Horizontal markets

Domains = Market Niches

Cross domain = broad appeal

standardization is hard in vertical and horizontal markets
Standardization is hard in vertical and horizontal markets.

Horizontal

  • A lot of players
  • Long wish lists
  • Difficult to find compromise

Vertical

  • Highly specialized
  • Differences are the business advantages
  • Volatile