Download Software Engineering

SOFTWARE ENGINEERING
Component Abstraction Levels
• Functional abstraction : implements a single function (e.g.,
square root)
• Casual groupings : loosely related entities such as data
declarations and functions
• Data abstractions : a data abstraction or object class
• Cluster abstractions : related object classes that work together
• System abstraction : an entire, self-contained system (e.g., MS
Excel)
CBSE Processes
• Component-based reuse may be opportunistic, or it may
drive the development process.
• In reuse-driven development, system requirements are
modified to reflect the available components.
• CBSE often involves an evolutionary development process
with components being “glued together” using a scripting
language. (e.g., Unix shell, Visual Basic, TCL/TK)
An Opportunistic Reuse Process
Des ign
s ystem
aachitecture
Sp ecify
compon ents
Incorpo rate
dis covered
compon ent s
Search fo r
reus able
components
the “we might get lucky” approach
Reuse-driven Development
Outline
system
requirements
Search for
reusable
components
Modify requirements
according to
discovered
components
Architectural
design
Search for
reusable
components
Specify system
components
based on reusable
components
CBSE Problems
• Component incompatibilities : may mean that cost and
schedule savings are less than expected.
• Finding and understanding components : repositories and
tool support are lacking.
• Managing evolution as requirements change : source code is
typically not available. (“waiting for the next release”)
Application Families
• An application family or product line is a related set of
applications that has a common, domain-specific architecture.
•
The common core of the application family is reused each
time a new application is required.
•
Each specific application is specialized in some way.
Application Family Specialization
• Platform specialization : different versions of the application
are developed for different platforms.
82
•
Configuration specialization : different versions of the
application are created to handle different peripheral devices.
•
Functional specialization : different versions of the
application are created for customers with different
requirements.
Family Member Development
Re-negotiate
requirements
Elicit
stakeholder
requirements
Choose closestfit family
member
Deliver new
family member
Adapt existing
system
Use existing family member as prototype
Design Patterns (Chris Alexander, Mid-70’s)
• A way of reusing “accumulated knowledge and wisdom”
about a problem and its solution.
• A design pattern is a description of some problem and the
essence of its solution.
• Should be sufficiently abstract to be reusable in different
contexts.
• Often utilize OO characteristics such as inheritance and
polymorphism.
Pattern Elements (Gamma, ‘95)
• Name: a meaningful pattern identifier
• Problem description
• Solution description: a template for a design solution that
can be instantiated in different operational contexts (often
illustrated graphically)
• Consequences: the results and trade-offs of applying the
pattern (analysis and experience)
The Observer Pattern (Details: P. 323)
• Name: Observer
• Description: Separates the display of object state from the
object itself.
• Problem description: Used when multiple displays of state
are needed.
• Solution description: See UML description
• Consequences: Optimisations to enhance display
performance are impractical.
Multiple Displays
50
D
A
C
25
B
0
A
B
C
D
Su bj ect
Ob s erv er 1
A:
B:
C:
D:
40
25
15
20
Ob s erv er 2