Presentation is loading. Please wait.

Presentation is loading. Please wait.

Component-Based Software Engineering CSM-15 Paul Krause.

Similar presentations


Presentation on theme: "Component-Based Software Engineering CSM-15 Paul Krause."— Presentation transcript:

1 Component-Based Software Engineering CSM-15 Paul Krause

2 Health Warning!  To work well, a Seminar-Based module needs your input!  I have plenty of material I can provide, but you must also tell me what you want within reason within reason  Let’s now quickly look at the recommended books …

3 Focus on components for the Internet Service-Oriented Computing: Semantics, Processes, Agents Authors: Singh and Huhns Publisher: Wiley

4 For the Practical Stuff

5 Lecture 1 - Overview Contents  Software Engineering  Components as architecture  What is a software component?  Interfaces  Software as a “metaproduct”

6 Why Software Engineering?  The difference between writing a program and engineering a software system is like the difference between building a patio table and building a bridge  You can patch up one until it works  You need careful analysis and design to succeed with the other  Good Software Engineering practice is essential for Software Components

7 Engineering The profession in which a knowledge of the mathematical and natural sciences gained by study, experience and practice is applied with judgement to develop ways to utilise, economically, the materials and forces of nature for the benefit of mankind Accreditation board for Engineering and Technology, 1996

8 Lecture 1 - Overview Contents  Software Engineering  Components as architecture  What is a software component?  Interfaces  Software as a “metaproduct”

9 Software Components mean?  The main driver behind software components is reuse.  That means we must modularise applications if they are to have potentially reusable parts.  The expectation is that if the parts (often collections of classes) can be reused then costs will be reduced (in the long run…).

10 So what’s new?  Modularisation of software is not new.  What we want of a component is that It may be used by other program elements (clients) It may be used by other program elements (clients) (encapsulation and low coupling – good strategies for any modular design)(encapsulation and low coupling – good strategies for any modular design) The clients and their authors do not need to be known to the component’s authors The clients and their authors do not need to be known to the component’s authors This is a little bit new, and only works if all the respective authors work to a common standardThis is a little bit new, and only works if all the respective authors work to a common standard

11 An Example Component  A Windows executable  Can be dynamically linked to any Windows application  Can be composed with other COM objects

12 Do we get anything for free?  Of course not!  Components may be classes (or collections of classes), but they must satisfy additional guidelines: So we really do understand what is provided and what is required at their interfaces So we really do understand what is provided and what is required at their interfaces So that we know the framework or architecture in which they are to be used So that we know the framework or architecture in which they are to be used

13 Components as architecture  Could view “independent components” as a category of software architectures Pipes and filters Pipes and filters UnixUnix Parallel communicating processes Parallel communicating processes Java threadsJava threads Client-server Client-server World-wide web;World-wide web; CORBA – a middle layer that provides a common data busCORBA – a middle layer that provides a common data bus Event systems Event systems Java event model and Java BeansJava event model and Java Beans

14 Lecture 1 - Overview Contents  Software Engineering  Components as architecture  What is a software component?  Interfaces  Software as a “metaproduct”

15 What is a Software Component?  “Components are units of deployment” - Clemens Szyperski

16 Drivers for CBD  The development of the WWW and Internet Systems of loosely coordinated services Systems of loosely coordinated services  Object-oriented design techniques and languages  Move from Mainframe to client-server based computing  Rapid pace of technological change  Economic necessity of maximising reuse

17 Are Components New?  Subroutines Turing, 1949, Checking a Large Routine Turing, 1949, Checking a Large Routine  Structured Programming Dijkstra, 1968 Dijkstra, 1968  Libraries NAG, 1971 NAG, 1971  Information Hiding Parnas, 1972 Parnas, 1972

18 Software Components  Components are for composition  (In principle) already existing “things” can be reused by rearranging them to make a new composite  So components are about reuse This drives many of the engineering requirements for software components This drives many of the engineering requirements for software components

19 What is a component (2)?  A component makes its services available through interfaces  And interfaces are of certain types or categories

20 Revised Definition  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. 1996 European Conference on Object-Oriented Programming

21 Lecture 1 - Overview Contents  Software Engineering  Components as architecture  What is a software component?  Interfaces  Software as a “metaproduct”

22 Connector Design :Button :Motor :Meter pressed start stop speed value

23 Connector Design :Button :Motor :Meter pressed start stop speed value :OR :Threshold a b a  b a > b a < b :Multiplier :Selector {1, 10, 100} :Selector {1, 10, 100} ab a x b 5:int a b

24 Lessons from electronics kit Families of products from kits of components  Design of a component infrastructure Basic technology - e.g. do components interact via procedure calls or remote method invocations? Basic technology - e.g. do components interact via procedure calls or remote method invocations?  Component design Components must conform to the component infrastructure Components must conform to the component infrastructure  Product building

25 Infrastructure:  Do pluggable connectors mean common data types across all components?  No! Local usage may not fit a common type Local usage may not fit a common type  Answer: Encapsulation No direct access to the data of any component from outside No direct access to the data of any component from outside All communication should be a request defined in an interface All communication should be a request defined in an interface

26 Revised Definition  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. 1996 European Conference on Object-Oriented Programming

27 Independent Deployment  Encapsulation  Cannot be partially deployed  Must have clear specifications of what it requires, as well as what it provides  Must have well-defined interfaces

28 Interfaces  Interfaces allow the clients of a component to access the services provided by a component  Different interfaces will normally provide access to different services  Each interface specification could be viewed as a contract between the component and a client

29 Explicit context dependencies  Components must also specify their needs i.e. the context of composition and deployment i.e. the context of composition and deployment  This means both The component’s requires interfaces, and The component’s requires interfaces, and The component world it is prepared for The component world it is prepared for (CORBA, COM, Java…)(CORBA, COM, Java…)

30 Component Specification  Provides Interfaces The services a component can offer to a client The services a component can offer to a client  Requires Interfaces The services required by a component to help it deliver its promises The services required by a component to help it deliver its promises  Context of Use The “world” the component lives in The “world” the component lives in

31 Lecture 1 - Overview Contents  Software Engineering  Components as architecture  What is a software component?  Interfaces  Software as a “metaproduct”

32 Software ICs? Page Acquisition Page Store

33 The nature of software  “Delivery of software means delivering the blueprints for products” Clemens Szyperski Clemens Szyperski  When software is installed on a computer, an instance of the product is instantiated  The computer can instantiate the product one or more times  Better to view software as a “metaproduct”

34 Plans vs. Instances  Plans can be parameterised  Plans can be applied recursively  Plans can be scaled  Plans can be instantiated any number of times

35 Summary We have:  Seen some of the drivers behind the introduction of component-based software engineering  Explored some definitions of software components  Identified the importance of specifying requires and provides interfaces


Download ppt "Component-Based Software Engineering CSM-15 Paul Krause."

Similar presentations


Ads by Google