CSCI3007 ComponentBased Development

1
CSCI3007Component-Based Development

• Alan OCallaghan W9.14
• aoc_at_dmu.ac.uk

2
Course Title and Focus

• On some documents the title of this module
  appears as Interface Requirements Engineering
• This was an interim name used in early curriculum
  development
• In others as Component-Based Development
• The course is about CBD in terms of two workflows
• Requirements definition
• Component specification
• i.e. it is NOT about programming components

3
Aims

• To understand the nature of Component-Based
  Development
• To understand the difference between Objects and
  Components
• To learn how to define requirements for CBD using
  object modelling
• To learn how to specify components
• To grasp the fundamentals of component standards

4
Perspective

• There are many conflicting definitions of the
  term component
• We will see some of them later in this lecture
• In this module we will take an object-oriented
  perspective
• This does not imply that all components are
  implemented as objects
• It DOES mean that we will apply object modelling
  principles and concepts in identifying
  requirements and specifying component solutions
• We will be using a subset of the UML including
  the Object Constraint Language

5
Resources

• Lectures (two per week)
• Information delivery in support of course texts
• Tutorials (one per week)
• Exploration of CBD techniques
• Course Texts
• Cheesman J. and J. Daniels. 2001. UML Components.
  Addison Wesley (MAIN text)
• DSouza D. and A.C. Wills.1999. Objects,
  Components and Frameworks with UML.Addison Wesley
• Web sites
• http//www.cse.dmu.ac.uk/aoc/
• http//www.umlcomponents.com/
• http//www.trireme.com/

6
Assessment

• 2-hour unseen examination
• A group-based assignment
• Specification of components for a problem
• You will work on this from week 4 until the end
  of term

7
Lecture Topics (1)

• Week 1.1 Course Overview and Background
• Week1.2 Components and Objects
• Week 2.1 Components and System Architectures
• Week 2.2 Workflows in CBD
• Week 3 (w/b October 15th) READING WEEK
  

8
Lecture Topics (2)

• Week 4.1 UML for CBD
• Week 4.2 Requirements Definition
• Week 5.1 Component Interaction
• Week 5.2 Component Specification
• Week 6.1 The Object Constraint Language
• Week 6.2 OCL continued
• Week 7.1 Provisioning and Assembly
• Week 7.2 Component Standards

9
Lecture Topics (3)

• Week 8.1 CORBA components
• Week 8.2 COM, DCOM components
• Week 9.1 Java-based Components
• Week 9.2 Java-based Components
• Week 10.1 An overview of Catalysis
• Week 10.2 Abstraction and Refinement
• Week 11 Revision

10
Background

• John Udell pronounced the death of objects in
  1994
• Three years later objects went mainstream
• Suggested OpenDoc represented the future
• Today, OpenDoc is dead

11
The Promise of Components

• The famous 1968 conference on Software
  Engineering promised that components would end
  the software crisis
• Through an industrial revolution
• In 1989 Brad Cox suggested that Software-ICs
  were enabling that revolution
• Through Object-Orientation
• Thirty years later we are still not a
  component-based industry
• Though 80 of companies are now said to be using
  them

12
Market Predictions for Components (1)

• August 1994 a market report was released
  entitled Components Are Not Top of the Class
• Criticised Microsofts COM components for not
  being full objects
• By the Gartner Group
• January 1995 A Plague on Objects
• Component revolution will not happen
• By the Gartner Group
• February 1995 another report predicted that
  components introduced for desktop apps., would
  spread by networking
• By the Gartner Group
• Object-Orientation for the rest of us
• 3 new markets components, assembly tools, and
  custom apps.

13
Market Predictions for Components (2)

• Cutter Consortium Business Technology Trends and
  Impacts Services research claims that 80 of
  companies are currently deploying applications
  that utilise components
• www.cutter.com/consortium/index_trends.html
• The Gartner Group currently predicts that at
  least 70 of all applications will be built using
  components by 2003
• www.gartner.com

14
What is a Component? (1)

• Grady Booch (1987) A reusable software
  component is a logically cohesive, loosely
  coupled module that denotes a single abstraction
• Gio Wiederhold, Peter Wegner and Stefano Ceri
  (1992) Megaprogramming is a technology for
  programming with large modules called megamodules
  that capture the functionality of services
  provided by large organisations like banks,
  airline reservation systems, and city transport
  systems
• Ivar Jacobson (1993) By components we mean
  already implemented units that we use to enhance
  the programming language constructs. These are
  used furing programming and correspond to the
  components in the building industry

15
What is a Component(2)?

• Meta Group (1994) Software components are
  defined as prefabricated, pretested,
  self-contained reusable modules- bundles of data
  and procedures that perform secific functions
• Oscar Niestrasz and Denis Tsichritzis (1995) A
  software component is a static abstraction with
  plugs
• Jed Harris (1995) A component is a piece of
  software small enough to create and maintain, big
  enough to deploy and support, and with standard
  interfaces for interoperability
• Ovum (1995) Small blocks of code that can
  collaborate at runtime

16
What is a Component? (3)

• Robert Orfali and Dan Harkey (1995) A
  component is a factory-debugged software system
• Clemens Szyperski (1997) A software component
  is a unit of composition with contractually
  specified interfaces and explicit context
  dependencies only. A software component can be
  deployed independently and is subject to
  composition by third parties
• Alan OCallaghan (1998) A software component is
  any piece of software which, at any given moment
  in time, is playing the role of a part in a
  software composition

17
What is a Component? (4)

• John Cheesman and John Daniels (2000) The
  component is the unit of deployment and
  replacement in a component system. Components are
  what we build or buy they are the units of
  realization
• N.Bgt Cheesman and Daniels did not offer this as a
  formal definition but as a working definition
  it will serve us on the course

18
Conclusion

• After 30 years of vapourware software components
  are becoming a reality
• There is a debate about the nature of components
  and their relationship to objects
• More importantly, there is a growth of tools and
  techniques to make effective use of components