0% found this document useful (0 votes)
2 views38 pages

Chapter 20

Uploaded by

unstable da
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
2 views38 pages

Chapter 20

Uploaded by

unstable da
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 38

Reusable Components

Based on Chapter 20 of Bennett, McRobb


and Farmer:
Object Oriented Systems Analysis and
Design Using UML, (2nd Edition), McGraw
Hill, 2002.
03/12/2001 © Bennett, McRobb and Farmer 2002 1
In This Lecture You Will
Learn:
 Why reuse is regarded as important
 Some of the problems with reuse
 How to plan system development to
achieve reuse of components
 The different techniques for
obtaining and managing reuse
 How to design a reusable
component
© Bennett, McRobb and Farmer 2002 2
Why Reuse?
 Reuse allows programmers to save time and
effort by reusing other developers’ code
 Reuse applies to procedural and functional
languages as well (e.g. Fortran and C
Libraries)
 The growth of Visual Basic can be attributed
to the easy availability of reusable controls
offering all kinds of functionality
 Object-oriented languages have been
promoted as enabling reuse

© Bennett, McRobb and Farmer 2002 3


Why Reuse?
 Economic argument
 Hewlett Packard achieved
– improved productivity
– faster time to market
– fewer defects
– return on investment of 215% on one
project, 410% on another
(Lim, 1994)

© Bennett, McRobb and Farmer 2002 4


Why Reuse?
 Quality argument
 Reusing a component that has
been developed and tested
elsewhere saves time and money
in testing and wuality assurance
– IBM maintains a library of zero-defect
components in Ada, PL/CX and C++
(Jacobson et al., 1997)
© Bennett, McRobb and Farmer 2002 5
Why Hasn’t O-O Delivered?
 Innapropriate choice of projects for
reuse
 Planning for reuse too late
 Level of coupling between classes
in an O-O design
 Lack of standards for reusable
components
© Bennett, McRobb and Farmer 2002 6
Choice of Projects
 Jacobson et al. (1997) identify four kinds of
software businesses suitable to develop
reusable components
– large organizations with a portfolio of projects
and IS infrastructure
– hardware developers using embedded software
– consultancy companies, particularly those that
work in vertical markets
– large software product developers where
components can be reused across a product
range

© Bennett, McRobb and Farmer 2002 7


Organizational Structure
 Stages of reuse development
(maturity)
– no code reuse
– informal code reuse
– black-box code reuse
– managed workproduct reuse
– architected reuse
– domain-specific reuse-driven organization
(Jacobson et al., 1997)

© Bennett, McRobb and Farmer 2002 8


Organizational Structure
 Allen and Frost (1998) argue that
organizations do not have the right
approach to or mindset for reuse
 This requires
– organizational change
– software tools to manage repositories
of reusable components

© Bennett, McRobb and Farmer 2002 9


Organizational Structure
SOLUTION PROCESS

HARV EST
COMPONENT
User
Services

REPOSITORY

Business Data
Services Services

MANAGEMENT

SOW
COMPONENT PROCESS

Allen and Frost, 1998 (Figure reproduced by permission of Cambridge University Press)
© Bennett, McRobb and Farmer 2002 10
Appropriate Unit of Reuse
 Components rather than classes
are the unit of reuse
 Classes are often too closely linked
to other classes
 Components are groups of classes
that deliver some higher-level
functionality

© Bennett, McRobb and Farmer 2002 11


Definitions of Components
 Executable unit of code … black-
box encapsulation of services
(Allen and Frost, 1998)
 Type, class or workproduct …
engineered to be reusable
(Jacobson et al., 1997)

© Bennett, McRobb and Farmer 2002 12


Components as Sub-
systems
 Sub-systems that provide more
functionality than a single class
 It should also be possible to reuse
intermediate products from the life
cycle
– use cases
– analysis models
– design models
– test models
© Bennett, McRobb and Farmer 2002 13
Component Standards
 Recent factors that promote reuse
– CORBA (Common Object Request
Broker Architecture) standard for
interoperability of components
– Java as a language with mechanisms
to package reusable components
(and standards like Enterprise Java
Beans)
– the growth of the WWW as a means
of distributing reusable components
© Bennett, McRobb and Farmer 2002 14
Component Standards
 New standards
– SOAP (Simple Object Access Protocol)
based on XML (eXtensible Markup
Language)
– Web Services mechanism to find
services on the Internet using UDDI
– UDDI (Universal Description, Discovery
and Integration) directory service
– .NET and C# (C Sharp not C Hash)

© Bennett, McRobb and Farmer 2002 15


Component Standards
 Borland Delphi—object Pascal as DLLs
 Visual Basic—.VBX and .OCX
 Windows—OLE, DDE, DLLs, COM and
DCOM
 CORBA—IDL and IOP
 Java—JAR files (and WAR and EAR),
EJBs
 .NET—MSIL, CLR and WSDL
© Bennett, McRobb and Farmer 2002 16
Strategy for Reuse
 The SELECT Perspective (Allen &
Frost)
 Solution process—delivering services
to meet business requirements while
drawing on the component process in
the search for reusable components
 Component process—developing
reusable components in packages to
deliver generic business services
© Bennett, McRobb and Farmer 2002 17
Strategy for Reuse
 SELECT Perspective
 The analogy of sowing and harvesting
 Sowing reusable components and
harvesting them in business solutions
 A repository for component
management is central to this
approach, with facilities to store and
index components and to browse and
search for them
© Bennett, McRobb and Farmer 2002 18
Strategy for Reuse
 Reuse-driven Software Engineering
Business (RSEB) (Jacobson et al.)
 Intermediate artefacts are reusable
as well as finished code
 Requires an architectural process to
design reusable models and code
 This requires a change to the way
in which the software business
operates
© Bennett, McRobb and Farmer 2002 19
Strategy for Reuse
 RSEB
 Developing a reuse business
requires reengineering the
organization
– Requirements Capture Unit
– Testing Unit
– Component Engineering Unit
– Architecture Unit
– Component Support Unit
© Bennett, McRobb and Farmer 2002 20
Strategy for Reuse
 RSEB
 Three engineering processes
– Application Family Engineering (AFE)—
produces layered architecture of application
and components
– Component System Engineering (CSE)—
develops reusable components to support
application development
– Application System Engineering (ASE)—
develops application systems designed to
make use of components produced by CSE
© Bennett, McRobb and Farmer 2002 21
Commercially Available
Componentware
 VBX, OCX and COM Components
 Wide range of components using
Microsoft architecture
 Controls for
– serial communication
– computer-aided design
– project management
– spreadsheets
– scientific charts
– barcode reading and printing
© Bennett, McRobb and Farmer 2002 22
IBM San Francisco Project
 Java distributed server-based
components
 Layered architecture
– Foundation Layer
– Common Business Objects
– Core Business Processes
 general ledger
 accounts receivable and payable
 warehouse management
 order management
© Bennett, McRobb and Farmer 2002 23
Case Study Example
Each program in the system will be represented by
a use case in the use case diagram. One or more
actors will be associated with each use case, and
each actor may be associated with more than one
use case. A member of staff will fill the role of one
or more actors, and each actor will be represented
by one or more members of staff. Each actor will
be given access rights to use specific use cases
(programs). A member of staff may only use
those use cases (programs) for which one of the
actor roles they fill has been given an access right.

© Bennett, McRobb and Farmer 2002 24


Case Study Example
 Requirement for a security system
 Could be reused in many
application systems

© Bennett, McRobb and Farmer 2002 25


Add a use Add a staff
case member

Add an Add an
actor actor role

Add an Remove a
access staff member System
right Manager

Remove a Remove an
Application use case actor role
Developer

Remove an Check user


actor authorization
Live System

Remove an
access
right

© Bennett, McRobb and Farmer 2002 26


Actor UseCase
* *
name title
*
AccessRight

ActorRole

*
StaffMember
login
name
password

© Bennett, McRobb and Farmer 2002 27


Actor UseCase
name : String title : String
* *
«responsibilities» «responsibilities»
add a new actor add a new use case
remove an actor remove a use case
add a staff member in actor role add an access right for an actor
remove a staff member from actor role remove an access right from an actor
*

*
StaffMember
login : String
name : String
password : String
«responsibilities»
add a new staff member
remove a staff member
change password

© Bennett, McRobb and Farmer 2002 28


Design Decisions
 Do we design sub-system with boundary
and control classes?
 Can we reuse the StaffMember class?
 How will application classes be aware of
interface to sub-system?
 What data storage mechanism will the
sub-system use?
 What parts of the sub-system will be
visible to other applications?
© Bennett, McRobb and Farmer 2002 29
Business Application
Java AWT

Security
Security Server Security Client

Security Core Security Boundary


Classes Classes

Security Server Security Client


Control Classes Control Classes

© Bennett, McRobb and Farmer 2002 30


Use of the Façade Pattern
 Provide a high-level interface to a sub-system
 Used to decouple clients of a sub-system from
the internal workings of the sub-system
 Simple interface to sub-system
Façade

Gamma et al, 1995 (Figure reproduced by permission of Addison Wesley Longman)

© Bennett, McRobb and Farmer 2002 31


«façade»
SecurityAuthorizer

+ checkAuthorization(login:String, password:String, title:String)

«façade»
SecurityManager

+ addAccessRight(ac:Actor, uc:UseCase)
+ addActor(name:String)
+ addActorRole(ac:Actor, sm:StaffMember)
+ addStaffMember(name:String, login:String, password:String)
+ addUseCase(title:String)
+ listActors( )
+ listActorsByUseCase(uc:UseCase)
+ listStaffMembers( )
+ listStaffMembersByActor(ac:Actor)
+ listUseCases( )
+ listUseCasesByActor(ac:Actor)
+ removeAccessRight(ac:Actor, uc:UseCase)
+ removeActor(ac:Actor)
+ removeActorRole(ac:Actor, sm:StaffMember)
+ removeStaffMember(sm:StaffMember)
+ removeUseCase(uc:UseCase)

© Bennett, McRobb and Farmer 2002 32


AddUseCase AddActor AddStaffMember

+ addUseCase(title:String) + addActor(name:String) + addStaffMember(name:String, login:String, password:String)

RemoveUseCase RemoveActor RemoveStaffMember

+ removeUseCase(uc:UseCase) + removeActor(ac:Actor) + removeStaffMember(sm:StaffMember)

ListUseCases ListActors
ListStaffMembers
+ listUseCases( ) + listActors( )
+ listStaffMembers( )
+ listUseCasesByActor(ac:Actor) + listActorsByUseCase(uc:UseCase)
+ listStaffMembersByActor(ac:Actor)
+ listActorsbyStaffMember(sm:StaffMember)

AddAccessRight AddActorRole RemoveAccessRight

+ addAccessRight(ac:Actor, uc:UseCase) + addActorRole(ac:Actor, sm:StaffMember) + removeAccessRight(ac:Actor, uc:UseCase)

CheckAuthorization RemoveActorRole

+ checkAuthorization(login:String, password:String, title:String) + removeActorRole(ac:Actor, sm:StaffMember)

© Bennett, McRobb and Farmer 2002 33


UseCase
UseCaseCollection
- actors: OSHashTable
- useCases: OSHashtable - title : String
1 *
+ addUseCase( ) + addActor( )
+ removeUseCase( ) + removeActor( )
+ listUseCases( ) + getTitle( )
+ findUseCaseByTitle( ) + listActors( )
1
*
1
*
Actor
- name : String
ActorCollection
- staffMembers: OSHashTable
- actors: OSHashTable - useCases: OSHashtable
1 *
+ addActor( ) + addStaffMember( )
+ removeActor( ) + removeStaffMember( )
+ listActors( ) + addUseCase( )
+ findActorByName( ) + removeUseCase( )
+ getName( )
+ listStaffMembers( )
+ listUseCases( )
1
*
1 *
StaffMember
- actors: OSHashTable
- login : String
StaffMemberCollection
- name: String
- staffMembers: OSHashTable - password: String
1 *
+ addStaffMember( ) + addActor(
addActor )
+ removeStaffMember( ) + removeActor(
removeActor )
+ listStaffMembers( ) + getName(
getName )
+ findStaffMemberByLogin( ) + getPassword(
setPassword )
+ setPassword(
listActors )
+ listActors( )

© Bennett, McRobb and Farmer 2002 34


Java RMI Business Application Java AWT

Security
Security Server Security Facade Security Client

Security Core «façade» Security Boundary


Classes CheckAuthorization Classes

Security Server «façade» Security Client


Control Classes SecurityManager Control Classes

ObjectStore PSE Pro

com.ODI com.ODI.util

com.ODI.imp

© Bennett, McRobb and Farmer 2002 35


CheckAuthorization
SecurityFaçade.jar

Agate.jar

© Bennett, McRobb and Farmer 2002 36


Summary
In this lecture you have learned about:
 Why reuse is regarded as important
 Some of the problems with reuse
 How to plan system development to
achieve reuse of components
 The different techniques for
obtaining and managing reuse
 How to design a reusable component

© Bennett, McRobb and Farmer 2002 37


References
 Allen and Frost (1998)
 Jacobson et al. (1997)
 Orfali and Harkey (1998)
(For full bibliographic details, see
Bennett, McRobb and Farmer)

© Bennett, McRobb and Farmer 2002 38

You might also like