COP 4991 ComponentBased Software Development Introduction to CBSD

COP 4991 Component-Based Software Development Introduction to CBSD: Background, Motivation, Definitions, Concept, and Principles Instructor: Masoud Sadjadi http: //www. cs. fiu. edu/~sadjadi/Teaching/ 1 st Lecture

Acknowledgements Dr. George T. Heineman Dr. William Councill Dr. Clemens Szyperski Dr. Betty Cheng Dr. Peter Clarke Dr. Bernd Bruegge Dr. Allen Dutoit COP-4991: Component-Based Software Development 1 st Lecture 2

Agenda 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 COP-4991: Component-Based Software Development 1 st Lecture 3

What is Software Engineering? (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] COP-4991: Component-Based Software Development 1 st Lecture 4

Our Intention Requirements Software COP-4991: Component-Based Software Development 1 st Lecture 5

Our plan of attack Requirements Analysis Design Implementation Testing Delivery and Installation COP-4991: Component-Based Software Development 1 st Lecture 6

How to Deal with Complexity? 1 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 COP-4991: Component-Based Software Development 1 st Lecture 7

How to Deal with Complexity? 2 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. COP-4991: Component-Based Software Development 1 st Lecture 8

Agenda 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 COP-4991: Component-Based Software Development 1 st Lecture 9

Reuse 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. COP-4991: Component-Based Software Development 1 st Lecture 10

Reuse 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 COP-4991: Component-Based Software Development 1 st Lecture 11

Reuse 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. COP-4991: Component-Based Software Development 1 st Lecture 12

Agenda 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 COP-4991: Component-Based Software Development 1 st Lecture 13

Metamodel for Inheritance is used to achieve two different goals: Taxonomies and Reuse. Inheritance Object Design Analysis activity Taxonomy Inheritance detected by specialization by generalization COP-4991: Component-Based Software Development Inheritance for Reuse Interface Inheritance Implementation Inheritance 1 st Lecture 14

Taxonomy Example Mammal Tiger COP-4991: Component-Based Software Development Wolf Wale 1 st Lecture 15

Implementation Inheritance A very similar class is already implemented that does almost the same as the desired class implementation. “Already implemented” 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()? List Add () Remove() Stack Push () Pop() Top() COP-4991: Component-Based Software Development 1 st Lecture 16

Problems 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. COP-4991: Component-Based Software Development 1 st Lecture 17

Impl. 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 COP-4991: Component-Based Software Development 1 st Lecture 18

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 COP-4991: Component-Based Software Development calls Receiver Delegates to Delegate 1 st Lecture 19

Delegation vs. Impl. Inheritance 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? List +Add() +Remove() Stack +Push() +Pop() +Top() COP-4991: Component-Based Software Development List Remove() Add() 1 st Lecture 20

Comparison 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) COP-4991: Component-Based Software Development 1 st Lecture 21

Agenda 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 COP-4991: Component-Based Software Development 1 st Lecture 22

Reuse 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. COP-4991: Component-Based Software Development 1 st Lecture 23

Frameworks 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. COP-4991: Component-Based Software Development 1 st Lecture 24

Key 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. COP-4991: Component-Based Software Development 1 st Lecture 25

Classification 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. COP-4991: Component-Based Software Development 1 st Lecture 26

Another Classification of Frameworks 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, Web. Objects, Web. Sphere, Web. Logic 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. COP-4991: Component-Based Software Development 1 st Lecture 27

Class libraries and Frameworks 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…. ) COP-4991: Component-Based Software Development 1 st Lecture 28

Components 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. COP-4991: Component-Based Software Development 1 st Lecture 29

Agenda 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 COP-4991: Component-Based Software Development 1 st Lecture 30

Other 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… COP-4991: Component-Based Software Development 1 st Lecture 31

Some 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… COP-4991: Component-Based Software Development 1 st Lecture 32

CBSE 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 COP-4991: Component-Based Software Development 1 st Lecture 33

Software 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 COP-4991: Component-Based Software Development 1 st Lecture 34

Component Model A Component Model defines specific interaction and composition standards. consume supply manage An interaction standard is the mandatory requirements employed and enforced to enable software elements to directly and indirectly interact with other software elements. Software Entity COP-4991: Component-Based Software Development Component interface 1 st Lecture 35

Interaction Standard Based on the concept of an interface – “An abstraction of the behavior of a component” Provided interface – component implements the interface in Required interface – component interactions with other software elements are captured comp Context Dependency out COP-4991: Component-Based Software Development 1 st Lecture 36

Composition Standard Composition – the combination of two or more software components yielding a new component behavior Defines several important concepts – Packaging – Deploying Installing Configuring COP-4991: Component-Based Software Development Instantiating 1 st Lecture 37

CMI 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 COP-4991: Component-Based Software Development 1 st Lecture 38

Big Picture Master Software Development Plan Problem to be Solved Performance Requirements Decompose problem into projects and subprojects Evaluate Success of Software System Design logical component infrastructure • Select suitable component model Legend Project Subproject COP-4991: Component-Based Software Development • Provided by vendor; or, if a proprietary component model, must be implemented. 1 st Lecture 39

Logical Component Infrastructure Evaluate Success of Software System Increasingly detailed refinement of design leads to an implemented component infrastructure Analyze component infrastructure from multiple viewpoints Legend Component Interaction Component Infrastructure Component Model Implementation COP-4991: Component-Based Software Development 1 st Lecture 40

Agenda 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 COP-4991: Component-Based Software Development 1 st Lecture 41

Component 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 COP-4991: Component-Based Software Development 1 st Lecture 42

Designing a Component Infrastructure The Component Infrastructure is layered Layering is a strategy for decomposing complex structures COP-4991: Component-Based Software Development 1 st Lecture 43

Four Layers User Workflow and Process Control Business Services Data and Operating System Services COP-4991: Component-Based Software Development 1 st Lecture 44

User components provide the external interface – graphical user interfaces (GUI), Web-based, or batchoriented Understand user interactions Request services from other components in response to commands issued by the user COP-4991: Component-Based Software Development 1 st Lecture 45

Workflow and Process Control Workflow and process control components manage complex, automated business processes that interact with (potentially) many business services COP-4991: Component-Based Software Development 1 st Lecture 46

Business 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 COP-4991: Component-Based Software Development 1 st Lecture 47

Design Layers and Designers User Workflow and Process Control Business Services & Legacy Wrapping Solution Component Designers Consume Business Supply Component Designers Consume Data/Operating System Services COP-4991: Component-Based Software Development Supply Data/Infrastructure Component Designers 1 st Lecture 48

Component Model Interfaces Naming Meta data Composition Customization Interoperability Evolution Support Packaging & Deployment COP-4991: Component-Based Software Development Specification of component behavior and properties Definition of Interface Description Language (IDL) 1 st Lecture 49

Agenda 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 COP-4991: Component-Based Software Development 1 st Lecture 50

Component Model Interfaces Naming Meta data Composition Customization Interoperability Evolution Support Packaging & Deployment Global unique names for interfaces and components Interface Y COP-4991: Component-Based Software Development Component X 1 st Lecture 51

Component 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 Y COP-4991: Component-Based Software Development Component X X Meta data Y Meta data 1 st Lecture 52

Component 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 Y COP-4991: Component-Based Software Development Component Z Component X 1 st Lecture 53

Component Model Interfaces Naming Meta data Composition Customization Interoperability Evolution Support Packaging & Deployment Interfaces for customizing components User-friendly customization tools will use these interfaces Customization. API Interface Y Component X Interface Y COP-4991: Component-Based Software Development Component X’ 1 st Lecture 54

Component 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 COP-4991: Component-Based Software Development Component Z Java Impl. Component X VB Impl. 1 st Lecture 55

Component Model Interfaces Naming Meta data Composition Customization Interoperability Evolution Support Packaging & Deployment Rules and services for replacing components or interfaces by newer versions Y Meta data Version 1. 0 Version 2. 0 X Meta data Interface Y COP-4991: Component-Based Software Development Component X Version 1. 1 1 st Lecture 56

Component Model Interfaces Naming Meta data Composition Customization Interoperability Evolution Support Packaging & Deployment Packaging implementation and resources needed for installing and configuring a component Interface Y COP-4991: Component-Based Software Development Component X X Meta data Y Meta data 1 st Lecture 57

Agenda 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 COP-4991: Component-Based Software Development 1 st Lecture 58

Terminology (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. COP-4991: Component-Based Software Development 1 st Lecture 59

Terminology (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. COP-4991: Component-Based Software Development 1 st Lecture 60

Terminology (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. , Qo. S, 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). COP-4991: Component-Based Software Development 1 st Lecture 61

Agenda 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 COP-4991: Component-Based Software Development 1 st Lecture 62

Object-oriented Class – name – set of attributes information of interest – set of methods functionality of the class – public declarations Vertex String get. Name () set. Name (String n) Integer get. X () set. X (Integer x) Integer get. Y () set. Y (Integer y) Object – has all the attributes of a class (“belongs” to the class) Integer x, y String name – exhibits the specified functionality – private implementation x: 100 y: 80 name: n 1 COP-4991: Component-Based Software Development x: 55 y: 13 name: n 2 1 st Lecture 63

Objects are instantiated Vertex v; v = new Vertex (); v. set. X(15); v = null; v = new Vertex (); v. set. X(12); v. set. Name(“n 1”); COP-4991: Component-Based Software Development v x: x: 15 0 y: 0 name: x: 12 y: 0 name: n 1 1 st Lecture 64

Inheritance Mechanism to create new classes – Colored. Vertex IS A Vertex – Vertex is the superclass – Colored. Vertex is a subclass Multiple inheritance – Supported by C++ not Java Enables polymorphism Supports overriding Vertex Colored. Vertex Color get. Color () set. Color (Color c) Color color COP-4991: Component-Based Software Development 1 st Lecture 65

Polymorphism 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() COP-4991: Component-Based Software Development 1 st Lecture 66

Overriding When subclass provides alternate implementation to an inherited method Also useful for realizing concrete subclasses for abstract base classes COP-4991: Component-Based Software Development 1 st Lecture 67

Access rights Designer can restrict access to – classes, methods, attributes Public – all classes can access Private – only defining class can access Protected (java) default package COP-4991: Component-Based Software Development 1 st Lecture 68

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) { … } } COP-4991: Component-Based Software Development 1 st Lecture 69

Java – Packages Grouping of classes One-to-one mapping to directory structure edu. wpi edu. umass edu. wpi. A edu. wpi. B edu. wpi. C COP-4991: Component-Based Software Development 1 st Lecture 70

Java – Static data In Java, all data must be defined in a class What about data common to all objects within a class? x: 55 y: 13 x: 22 y: 97 Node Integer x, y static Integer const COP-4991: Component-Based Software Development x: 55 y: 13 const: 32 x: 22 y: 97 const: 32 Node const: 32 Integer x, y Integer const 1 st Lecture 71

Accessing Static Data/Methods Node n = new Node (); n. set. X (10); n. set. Y (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 COP-4991: Component-Based Software Development 1 st Lecture 72

Java – Coupled Communication public class Agent { private Manager mgr; public Agent (Manager m) { mgr = m; } public void request. Work() { mgr. show. How(); } } Agent public class Manager { public Manager () { } public void show. How() { } } can’t be used without Manager COP-4991: Component-Based Software Development 1 st Lecture 73

Java – Decoupled Communication public class Agent { private Vector helpers = new Vector(); public void add. Helper (Work. Interface s) { helpers. add. Element (s); } public void remove. Helper (Work. Interface s) { helpers. remove. Element (s); } public void request. Work () { for (Enumeration en = helpers. elements(); en. has. More. Elements(); ) { Work. Interface wi = (Work. Interface) en. next. Element(); wi. show. How(); } public interface Work. Interface { void show. How(); } } } public class Manager implements Work. Interface { public void show. How() { // Individual work gets done. . . } } COP-4991: Component-Based Software Development 1 st Lecture 74

Decoupled Principles Avoid “death-embrace” coupling public class A { void do. Something (B b) { B. help. Out (this); } int get. Value () { return 20; } } public class B { void help. Out (A a) { a. get. Value() . . . } } Instead use interfaces public class A implements IVal { void do. Something (IHelp h) { h. help. Out (this); } int get. Value () { return 20; } } COP-4991: Component-Based Software Development public class B implements IHelp { void help. Out (IVal v) { v. get. Value() . . . } } 1 st Lecture 75