View
221
Download
0
Embed Size (px)
Citation preview
1st Lecture
COP 4991 COP 4991 Component-Based Software DevelopmentComponent-Based Software Development
Instructor: Masoud Sadjadihttp://www.cs.fiu.edu/~sadjadi/Teaching/
Introduction to CBSD:Introduction to CBSD:Background, Motivation, Definitions, Background, Motivation, Definitions,
Concept, and PrinciplesConcept, and Principles
1st Lecture 2COP-4991: Component-Based Software Development
AcknowledgementsAcknowledgements
Dr. George T. Heineman
Dr. William Councill
Dr. Clemens Szyperski
Dr. Betty Cheng
Dr. Peter Clarke
Dr. Bernd Bruegge
Dr. Allen Dutoit
1st Lecture 3COP-4991: Component-Based Software Development
AgendaAgenda Background
– Software Engineering– Software Complexity
Why components?– Reuse Concepts– Inheritance and Delegation– Libraries, Frameworks, and Components
Component Based Software Engineering– Definitions– Component Infrastructure– Component Model
Recap– Terminology– Java Quick Overview
1st Lecture 4COP-4991: Component-Based Software Development
What is Software What is Software Engineering? Engineering? (1)(1)
Systematic approach for developing software.
“Methods and techniques to develop and maintain quality software to solve problems.” [Pfleeger, 1990]
“Study of the principles and methodologies for developing and maintaining software systems.” [Zelkowitz, 1978]
“Software engineering is an engineering discipline which is concerned with all aspects of software production.” [Sommerville]
1st Lecture 5COP-4991: Component-Based Software Development
Our IntentionOur Intention
Requirements
Software
1st Lecture 6COP-4991: Component-Based Software Development
Our plan of attackOur plan of attack
RequirementsAnalysis
Design
Implementation
Testing
Delivery and Installation
1st Lecture 7COP-4991: Component-Based Software Development
How to Deal with Complexity? How to Deal with Complexity? 11
Three ways to deal with complexity:– Abstraction – Decomposition
Technique: Divide and conquer
– Hierarchy Technique: Layering
Two ways to deal with decomposition:– Functional Decomposition– Object Orientation
1st Lecture 8COP-4991: Component-Based Software Development
How to Deal with Complexity? How to Deal with Complexity? 22
What is the right way? – Functional Decomposition
may lead to unmaintainable code.
– Object Orientation depending on the purpose of the system, different objects may be
found.
How to proceed?– Start with a description of the functionality
Use case model
– Then find objects Object model
What activities and models are needed?– This leads us to the software lifecycle we use in this class.
1st Lecture 9COP-4991: Component-Based Software Development
AgendaAgenda Background
– Software Engineering– Software Complexity
Why components?– Reuse Concepts– Inheritance and Delegation– Libraries, Frameworks, and Components
Component Based Software Engineering– Definitions– Component Infrastructure– Component Model
Recap– Terminology– Java Quick Overview
1st Lecture 10COP-4991: Component-Based Software Development
Reuse MotivationReuse Motivation
Observation about Modeling of the Real World in [Gamma et al 94]
– Strict modeling of the real world leads to a system that reflects today’s realities but not necessarily tomorrow’s.
– There is a need for reusable and flexible designs.
– Design knowledge complements application domain knowledge and solution domain knowledge.
1st Lecture 11COP-4991: Component-Based Software Development
Reuse HeuristicsReuse Heuristics
Look for existing classes in class libraries– JSAPI, JTAPI, ....
Select data structures appropriate to the algorithms– Container classes – Arrays, lists, queues, stacks, sets, trees, ...
Define new internal classes and operations only if necessary– Complex operations defined in terms of lower-level operations
might need new classes and operations
1st Lecture 12COP-4991: Component-Based Software Development
ReuseReuse
Main goal: – Reuse knowledge and functionality from previous experience to
current problem.– Approaches: Inheritance and Delegation
Inheritance – Interface inheritance
Used for concept classifications type hierarchies
– Implementation inheritance Used for code reuse.
Delegation– An alternative to implementation inheritance.
Used for code reuse.
1st Lecture 13COP-4991: Component-Based Software Development
AgendaAgenda Background
– Software Engineering– Software Complexity
Why components?– Reuse Concepts– Inheritance and Delegation– Libraries, Frameworks, and Components
Component Based Software Engineering– Definitions– Component Infrastructure– Component Model
Recap– Terminology– Java Quick Overview
1st Lecture 14COP-4991: Component-Based Software Development
Metamodel for InheritanceMetamodel for Inheritance
Inheritance is used to achieve two different goals: Taxonomies and Reuse.
Inheritance
InterfaceInheritance
ImplementationInheritance
Inheritancefor ReuseTaxonomy
Inheritance detectedby generalization
Inheritance detectedby specialization
Analysisactivity
Object Design
1st Lecture 15COP-4991: Component-Based Software Development
Taxonomy ExampleTaxonomy Example
Mammal
Tiger Wolf Wale
1st Lecture 16COP-4991: Component-Based Software Development
Implementation InheritanceImplementation Inheritance
A very similar class is already implemented that does almost the same as the desired class implementation.
Example: – I have a List class, I need a
Stack class.
– How about subclassing the Stack class from the List class and providing three methods, Push() and Pop(), Top()?
Add ()
Remove()
List
Push ()Pop()
Stack
Top()
“Already implemented”
1st Lecture 17COP-4991: Component-Based Software Development
ProblemsProblems
Problem with implementation inheritance:– Some of the inherited operations might exhibit unwanted behavior. – What happens if the Stack user calls Remove() instead of Pop()?– What happens if the superclass implementation is modified?– The subclass developer is exposed to internal information about
the superclass and this may result in tight coupling of subclass to superclass.
1st Lecture 18COP-4991: Component-Based Software Development
Impl. vs Interface InheritanceImpl. vs Interface Inheritance
Implementation inheritance– Also called class inheritance– Goal: Extend an application’s functionality by reusing functionality
in parent class– Inherit from an existing class with some or all operations already
implemented
Interface inheritance– Also called subtyping– Inherit from an abstract class with all operations specified, but not
yet implemented
1st Lecture 19COP-4991: Component-Based Software Development
DelegationDelegation
Delegation – is an alternative to implementation inheritance.– is as powerful as implementation inheritance.
In Delegation two objects are involved in handling a request– A receiving object delegates operations to its delegate. – The developer can make sure that the receiving object does not
allow the client to misuse the delegate object.
Client Receiver DelegateDelegates to calls
1st Lecture 20COP-4991: Component-Based Software Development
Delegation vs. Impl. Delegation vs. Impl. InheritanceInheritance
Inheritance: Extending a base class by a new operation or overwriting an operation.
Delegation: Catching an operation and sending it to another object.
Which of the following models is better for implementing a stack?
+Add()+Remove()
List
Stack
+Push()+Pop()+Top()
+Push()+Pop()+Top()
Stack
Add()Remove()
List
1st Lecture 21COP-4991: Component-Based Software Development
ComparisonComparison
Delegation– Pro:
Flexibility: Any object can be replaced at run time by another one (as long as it has the same type)
– Con: Inefficiency: Objects are encapsulated.
Inheritance– Pro:
Straightforward to use Supported by many programming languages Easy to implement new functionality
– Con: Inheritance exposes a subclass to the details of its parent class Any change in the parent class implementation forces the subclass to
change (which requires recompilation of both)
1st Lecture 22COP-4991: Component-Based Software Development
AgendaAgenda Background
– Software Engineering– Software Complexity
Why components?– Reuse Concepts– Inheritance and Delegation– Libraries, Frameworks, and Components
Component Based Software Engineering– Definitions– Component Infrastructure– Component Model
Recap– Terminology– Java Quick Overview
1st Lecture 23COP-4991: Component-Based Software Development
Reuse CodeReuse Code
Select existing code– class libraries– frameworks– components
Adjust the class libraries, framework or components– Change the API if you have the source code.– Use the adapter or bridge pattern if you don’t have access
What are the differences among class libraries, frameworks, and components?– They are all composed of a set of related classes.
1st Lecture 24COP-4991: Component-Based Software Development
FrameworksFrameworks
A framework is a reusable partial application that can be specialized to produce custom applications.
Frameworks are targeted to particular technologies, such as data processing or cellular communications, or to application domains, such as user interfaces or real-time avionics.
1st Lecture 25COP-4991: Component-Based Software Development
Key BenefitsKey Benefits
Reusability – leverages of the application domain knowledge and prior effort of
experienced developers .
Extensibility – is provided by hook methods, which are overwritten by the
application to extend the framework.– Hook methods systematically decouple the interfaces and
behaviors of an application domain from the variations required by an application in a particular context.
1st Lecture 26COP-4991: Component-Based Software Development
Classification of FrameworksClassification of Frameworks
White-Box Frameworks– Extensibility achieved through inheritance and dynamic binding. – Existing functionality is extended by subclassing framework base
classes and overriding predefined hook methods– Often design patterns such as the template method pattern are
used to override the hook methods.
Black-Box Frameworks – Extensibility achieved by defining interfaces for components that
can be plugged into the framework. – Existing functionality is reused by defining components that
conform to a particular interface – These components are integrated with the framework via
delegation.
1st Lecture 27COP-4991: Component-Based Software Development
Another Classification of Another Classification of FrameworksFrameworks
Infrastructure frameworks – aim to simplify the software development process– System infrastructure frameworks are used internally within a
software project and are usually not delivered to a client.
Middleware frameworks – are used to integrate existing distributed applications and
components. – Examples: MFC, DCOM, Java RMI, WebObjects, WebSphere,
WebLogic Enterprise Application [BEA].
Enterprise application frameworks – are application specific and focus on domains– Example domains: telecommunications, avionics, environmental
modeling, manufacturing, financial engineering, enterprise business activities.
1st Lecture 28COP-4991: Component-Based Software Development
Class libraries and Class libraries and FrameworksFrameworks
Class Libraries: – Less domain specific – Provide a smaller scope of reuse. – Class libraries are passive; no constraint on control flow.
Framework: – Classes cooperate for a family of related applications. – Frameworks are active; affect the flow of control.
In practice, developers often use both:– Frameworks often use class libraries internally to simplify the
development of the framework. – Framework event handlers use class libraries to perform basic
tasks (e.g. string processing, file management, numerical analysis…. )
1st Lecture 29COP-4991: Component-Based Software Development
Components and FrameworksComponents and Frameworks
Components– Self-contained instances of classes.– Plugged together to form complete applications.– Defines a cohesive set of operations– Can be used based on the syntax and semantics of the interface. – Components may even be reused on the binary code level.
The advantage is that applications do not always have to be recompiled when components change.
Frameworks:– Often used to develop components.– Components are often plugged into black-box frameworks.
1st Lecture 30COP-4991: Component-Based Software Development
AgendaAgenda Background
– Software Engineering– Software Complexity
Why components?– Reuse Concepts– Inheritance and Delegation– Libraries, Frameworks, and Components
Component Based Software Engineering– Definitions– Component Infrastructure– Component Model
Recap– Terminology– Java Quick Overview
1st Lecture 31COP-4991: Component-Based Software Development
Other Engineering FieldsOther Engineering Fields
Every other engineering profession– divides problems into sub-problems
Ready-made solutions Sub-contracted to conform to specifications
– conforms to standards– self-imposed industrial regulation– certification regiment for engineers
But not Software Engineering…
1st Lecture 32COP-4991: Component-Based Software Development
Some ExcusesSome Excuses
Software is different from hardware My software needs are unique We don’t trust software written elsewhere Users can live with defective software
We want something better…
1st Lecture 33COP-4991: Component-Based Software Development
CBSE MethodologyCBSE Methodology
At its core, CBSE is a methodology that:– constructs applications from software units– supports vendors in producing reusable
software units– develops core technologies that support the
run-time execution of these units– defines agreed-upon standards– engenders trust among participants
1st Lecture 34COP-4991: Component-Based Software Development
Software ComponentSoftware Component
A Software Component is a software element that conforms to a component model and can be independently deployed and can be composed without modification all above according to a composition
standard
1st Lecture 35COP-4991: Component-Based Software Development
Component ModelComponent Model
A Component Model defines specific interaction and composition standards.
An interaction standard is the mandatory requirements employed and enforced to enable software elements to directly and indirectly interact with other software elements.
Component
interface
SoftwareEntity
supply
manage
consume
1st Lecture 36COP-4991: Component-Based Software Development
comp
Interaction StandardInteraction Standard
Based on the concept of an interface– “An abstraction of the behavior of a component”
Provided interface– component implements the interface
Required interface– component interactions with other
software elements are captured
Context Dependency
in
out
1st Lecture 37COP-4991: Component-Based Software Development
Composition StandardComposition Standard
Composition– the combination of two or more software
components yielding a new component behavior
Defines several important concepts– Packaging Installing Instantiating– Deploying Configuring
1st Lecture 38COP-4991: Component-Based Software Development
CMICMI
A Component Model Implementation is the dedicated set of executable software elements required to support the execution of components that conform to the model
The “Plumbing” that enables components to connect and interact with each other
1st Lecture 39COP-4991: Component-Based Software Development
Big PictureBig Picture
Decompose problem into projects and subprojects
Design logical component infrastructure
Problem to be
Solved
Problem to be
Solved
• Select suitable component model
• Provided by vendor; or, if a proprietary component model, must be implemented.
Legend
Subproject
Project
PerformanceRequirements
Evaluate Success of Software System
Evaluate Success of Software System
Master SoftwareDevelopment Plan
1st Lecture 40COP-4991: Component-Based Software Development
Increasingly detailed refinement of design leads to an implemented component infrastructure
Evaluate Success of Software System
Evaluate Success of Software System
Analyze component infrastructure from multiple viewpoints
Legend
Interaction
Component
Logical ComponentInfrastructure
Component Model Implementation
Component Infrastructure
1st Lecture 41COP-4991: Component-Based Software Development
AgendaAgenda Background
– Software Engineering– Software Complexity
Why components?– Reuse Concepts– Inheritance and Delegation– Libraries, Frameworks, and Components
Component Based Software Engineering– Definitions– Component Infrastructure– Component Model
Recap– Terminology– Java Quick Overview
1st Lecture 42COP-4991: Component-Based Software Development
Component InfrastructureComponent Infrastructure
A software component infrastructure is – a set of interacting software components
The infrastructure is designed to ensure that a software system constructed using those components will satisfy clearly defined performance requirements
1st Lecture 43COP-4991: Component-Based Software Development
Designing a Component InfrastructureDesigning a Component Infrastructure
The Component Infrastructure is layered
Layering is a strategy for decomposing complex structures
1st Lecture 44COP-4991: Component-Based Software Development
Four LayersFour Layers
User
Workflow and Process Control
Business Services
Data and Operating System Services
1st Lecture 45COP-4991: Component-Based Software Development
UserUser
User components provide the external interface– graphical user interfaces (GUI), Web-based, or batch-
oriented
Understand user interactions
Request services from other components in response to commands issued by the user
1st Lecture 46COP-4991: Component-Based Software Development
Workflow and Process ControlWorkflow and Process Control
Workflow and process control components manage complex, automated business processes that interact with (potentially) many business services
1st Lecture 47COP-4991: Component-Based Software Development
Business ServicesBusiness Services
Business service and legacy wrapping components provide the implementation of the business rules and the operational activity
This is accomplished using internal business object implementations, or by wrapping legacy systems behind the component interface
1st Lecture 48COP-4991: Component-Based Software Development
Design Layers and DesignersDesign Layers and Designers
User
Business Services &Legacy Wrapping
Data/Operating System Services
Workflow and ProcessControl
Solution
Component Designers
Business
Component Designers
Data/Infrastructure
Component Designers
Supply
Consume
Supply Consume
1st Lecture 49COP-4991: Component-Based Software Development
Component ModelComponent Model
Interfaces
Naming
Meta data
Composition
Customization
Interoperability
Evolution Support
Packaging & Deployment
Specification of component behavior and properties
Definition of Interface Description Language (IDL)
1st Lecture 50COP-4991: Component-Based Software Development
AgendaAgenda Background
– Software Engineering– Software Complexity
Why components?– Reuse Concepts– Inheritance and Delegation– Libraries, Frameworks, and Components
Component Based Software Engineering– Definitions– Component Infrastructure– Component Model
Recap– Terminology– Java Quick Overview
1st Lecture 51COP-4991: Component-Based Software Development
Component ModelComponent Model
Interfaces Naming
Meta data
Composition
Customization
Interoperability
Evolution Support
Packaging & Deployment
Global unique names for interfaces and components
Interface YComponent X
1st Lecture 52COP-4991: Component-Based Software Development
Component ModelComponent Model
Interfaces
Naming Meta data
Composition
Customization
Interoperability
Evolution Support
Packaging & Deployment
Information about components, interfaces, and their relationships
Interfaces to services providing such information
Interface YComponent X
X Meta dataY Meta data
1st Lecture 53COP-4991: Component-Based Software Development
Component ModelComponent Model
Interfaces
Naming
Meta data Composition
Customization
Interoperability
Evolution Support
Packaging & Deployment
Interfaces and rules for combining components to create larger structures and for substituting and adding components to existing structures
Interface YComponent X
Component Z???
1st Lecture 54COP-4991: Component-Based Software Development
Component ModelComponent Model
Interfaces
Naming
Meta data
Composition Customization
Interoperability
Evolution Support
Packaging & Deployment
Interfaces for customizing components
User-friendly customization tools will use these interfaces
Interface YComponent X
CustomizationAPI
Interface YComponent X’
1st Lecture 55COP-4991: Component-Based Software Development
Component ModelComponent Model
Interfaces
Naming
Meta data
Composition
Customization Interoperability
Evolution Support
Packaging & Deployment
Communication and data exchange among components from different vendors, implemented in different languages
Interface Y
Component XVB Impl.
Component ZJava Impl.
???
1st Lecture 56COP-4991: Component-Based Software Development
Component ModelComponent Model
Interfaces
Naming
Meta data
Composition
Customization
Interoperability Evolution Support
Packaging & Deployment
Rules and services for replacing components or interfaces by newer versions
Interface YComponent X
X Meta dataVersion 1
Version 1.1
Y Meta dataVersion 1.0
Version 2.0
1st Lecture 57COP-4991: Component-Based Software Development
Component ModelComponent Model
Interfaces
Naming
Meta data
Composition
Customization
Interoperability
Evolution Support Packaging &
Deployment
Packaging implementation and resources needed for installing and configuring a component
Interface YComponent X
X Meta dataY Meta data
1st Lecture 58COP-4991: Component-Based Software Development
AgendaAgenda Background
– Software Engineering– Software Complexity
Why components?– Reuse Concepts– Inheritance and Delegation– Libraries, Frameworks, and Components
Component Based Software Engineering– Definitions– Component Infrastructure– Component Model
Recap– Terminology– Java Quick Overview
1st Lecture 59COP-4991: Component-Based Software Development
Terminology Terminology (1)(1)
participants – all persons involved in a project.
e.g., developers, project manager, client, end users.
role – associated with a set of tasks assigned to a participant.
system – underlying reality.
model – abstraction of the reality.
work product – an artifact produced during development.
1st Lecture 60COP-4991: Component-Based Software Development
Terminology Terminology (2)(2)
deliverable – work product for client.
activity – a set of tasks performed toward a specific purpose.
milestone – end-point of a software process activity.
task – an atomic unit of work that can be managed and that consumes resources.
goal – high-level principle used to guide the project.
1st Lecture 61COP-4991: Component-Based Software Development
Terminology Terminology (3)(3)
functional requirement – describe the interaction between the system and its actors (e.g., end users and other external systems) independent of its implementation.
nonfunctional requirement – describe aspects of the system that are not directly related to the functional requirements of the system (e.g., QoS, security, scalability, performance, and fault-tolerance).
notation – is a graphical or textual set of rules representing a model (e.g., UML)
method – a repeatable technique for solving a specific problem e.g. sorting algorithm
methodology – a collection of methods for solving a class of problems (e.g., Unified Software Development Process).
1st Lecture 62COP-4991: Component-Based Software Development
AgendaAgenda Background
– Software Engineering– Software Complexity
Why components?– Reuse Concepts– Inheritance and Delegation– Libraries, Frameworks, and Components
Component Based Software Engineering– Definitions– Component Infrastructure– Component Model
Recap– Terminology– Java Quick Overview
1st Lecture 63COP-4991: Component-Based Software Development
Object-oriented ClassObject-oriented Class
Class– name– set of attributes
information of interest
– set of methods functionality of the class
– public declarations
Object– has all the attributes of a class
(“belongs” to the class)
– exhibits the specified functionality– private implementation
VertexString getName ()setName (String n)Integer getX ()
setX (Integer x)Integer getY ()setY (Integer y)
Integer x, yString name
x: 100y: 80
name: n1
x: 55y: 13
name: n2
1st Lecture 64COP-4991: Component-Based Software Development
Objects are instantiatedObjects are instantiated
Vertex v;
x: 0y: 0
name: vv = new Vertex ();
v.setX(15);
x: 15y: 0
name:
v = null;
v
x: 12y: 0
name:n1v = new Vertex ();
v.setX(12);
v.setName(“n1”);
v
1st Lecture 65COP-4991: Component-Based Software Development
InheritanceInheritance
Mechanism to create new classes– ColoredVertex IS A Vertex
– Vertex is the superclass– ColoredVertex is a subclass
Multiple inheritance– Supported by C++ not Java
Enables polymorphism Supports overriding
ColoredVertexColor getColor ()
setColor (Color c)
Color color
Vertex
1st Lecture 66COP-4991: Component-Based Software Development
PolymorphismPolymorphism
Concept that a number of different (yet related) operations have the same name– improvement over C– increased readability of code
Consider ability of Vertex to draw()
forall vertices v in graph
v.draw()
1st Lecture 67COP-4991: Component-Based Software Development
OverridingOverriding
When subclass provides alternate implementation to an inherited method
Also useful for realizing concrete subclasses for abstract base classes
1st Lecture 68COP-4991: Component-Based Software Development
Access rightsAccess rights
Designer can restrict access to– classes, methods, attributes
Public – all classes can access Private – only defining class can access Protected (java) default package
1st Lecture 69COP-4991: Component-Based Software Development
Java – Interfaces Java – Interfaces
Contractual obligation on a class A class implements an interface
public interface ICalc {
/** return the multiplication of a*b. */
int multiply (int a, int b);
}
public class Calculator implements IBlock, ICalc {
…
public int multiply (int x, int y) { … }
}
1st Lecture 70COP-4991: Component-Based Software Development
Java – PackagesJava – Packages
Grouping of classes
One-to-one mapping to directory structure
edu
edu.wpi edu.umass
edu.wpi.Aedu.wpi.Bedu.wpi.C
1st Lecture 71COP-4991: Component-Based Software Development
Java – Static dataJava – Static data
In Java, all data must be defined in a class
What about data common to all objects within a class?
x: 55y: 13
const: 32
x: 22y: 97
const: 32
Node
Integer x, yInteger const
Node
Integer x, ystatic Integer const
x: 55y: 13
x: 22y: 97
const: 32
1st Lecture 72COP-4991: Component-Based Software Development
Accessing Static Accessing Static Data/MethodsData/Methods
Node n = new Node ();
n.setX (10);
n.setY (20);
// Associated with the class
int x = Node.const;
// Can also work on objects (simply delegated to class)
int y = n.const;
Similar access works for static methods
1st Lecture 73COP-4991: Component-Based Software Development
Java – Coupled CommunicationJava – Coupled Communication
public class Agent { private Manager mgr; public Agent (Manager m) { mgr = m; }
public void requestWork() { mgr.showHow(); }}
public class Manager { public Manager () { }
public void showHow() { }}
Agent can’t be used without Manager
1st Lecture 74COP-4991: Component-Based Software Development
Java – Java – Decoupled CommunicationDecoupled Communication
public class Agent { private Vector helpers = new Vector(); public void addHelper (WorkInterface s) { helpers.addElement (s); } public void removeHelper (WorkInterface s) { helpers.removeElement (s); } public void requestWork () { for (Enumeration en = helpers.elements(); en.hasMoreElements(); ) { WorkInterface wi = (WorkInterface) en.nextElement(); wi.showHow(); } }}
public interface WorkInterface { void showHow();}
public class Manager implements WorkInterface { public void showHow() { // Individual work gets done... }}
1st Lecture 75COP-4991: Component-Based Software Development
Decoupled PrinciplesDecoupled Principles
Avoid “death-embrace” coupling
public class A { void doSomething (B b) { B.helpOut (this); } int getValue () { return 20; }}
public class B { void helpOut (A a) { a.getValue() ... }}
public class A implements IVal { void doSomething (IHelp h) { h.helpOut (this); } int getValue () { return 20; }}
public class B implements IHelp { void helpOut (IVal v) { v.getValue() ... }}
Instead use interfaces