component based software engineering n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Component-Based Software Engineering PowerPoint Presentation
Download Presentation
Component-Based Software Engineering

Loading in 2 Seconds...

play fullscreen
1 / 71
caradoc

Component-Based Software Engineering - PowerPoint PPT Presentation

198 Views
Download Presentation
Component-Based Software Engineering
An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Component-Based Software Engineering Introduction and Overview Paul Krause

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

  3. 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

  4. 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

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

  6. 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…).

  7. 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) • (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 • This is a little bit new, and only works if all the respective authors work to a common standard

  8. An Example Component • A Windows executable • Can be dynamically linked to any Windows application • Can be composed with other COM objects

  9. 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 that we know the framework or architecture in which they are to be used

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

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

  12. What is a Software Component? • “Components are units of deployment” • Clemens Szyperski

  13. Drivers for CBD • The development of the WWW and Internet • 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

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

  15. Software Components • Components are for composition • (In principle) already exisiting “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

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

  17. 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

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

  19. :Button :Button pressed start :Motor :Meter speed value stop pressed Connector Design

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

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

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

  23. 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

  24. 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

  25. 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

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

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

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

  29. Page Acquisition Page Store Software ICs?

  30. The nature of software • “Delivery of software means delivering the blueprints for products” • 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”

  31. Plans vs. Instances • Plans can be parameterised • Plans can be applied recursively • Plans can be scaled • Plans can be instantiated any number of times

  32. 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

  33. Lecture 1 (Part 2) - Software Architecture Contents • Why is this interesting? • What is Software Architecture? • Why is Software Architecture Important? • Architectural Views and Frameworks • Architecture-Based Development • Summing Up

  34. Why Study Architecture? • The choice of Architecture determines many of the qualities of a software system • Architecture is the blueprint for component integration • Defines the context in which a class of components may be used

  35. Software Architecture is? Software architecture is about structural properties: • Components • Interrelationships • Principles • Guidelines It is one of the earliest stages in software system design

  36. AQUA CLASSIC CARBON COCOA JAVA QUARTZ OPENGL QUICKTIME DARWIN Mac OS X Component Architecture

  37. AQUA CLASSIC CARBON COCOA JAVA QUARTZ OPENGL QUICKTIME BSD SUBSYSTEM MACH KERNEL Mac OS X Component Architecture IMAGING LAYER

  38. AQUA CLASSIC CARBON COCOA JAVA QUARTZ OPENGL QUICKTIME BSD SUBSYSTEM MACH KERNEL Mac OS X Component Architecture API LAYER

  39. AQUA CLASSIC CARBON COCOA JAVA QUARTZ OPENGL QUICKTIME BSD SUBSYSTEM MACH KERNEL USER INTERFACE LAYER Mac OS X Component Architecture

  40. Structural Issues? • Gross organisation and global control structure • Protocols for communication, synchronisation and data access • Assignment of functionality to design elements • Physical distribution • Composition of design elements • Scaling and performance

  41. Why is it important? • “If a project has not achieved a system architecture, including its rationale, the project should not proceed to full-scale system development. Specifying the architecture as a deliverable enables its use throughout the development and maintenance process.” • Barry Boehm, Invited talk, First International Workshop on Architecture for Software Systems

  42. Three Basic Reasons: • Mutual communication • A common high-level abstraction that can be used by all the system’s stakeholders • Early design decisions • Ones that will be important throughout the lifecycle (development, service and maintenance) • Transferable abstraction of the system • Relatively small, intellectually graspable model of the system

  43. Transferable Model • Reuse at the architectural level for systems with similar requirements • Entire product lines can share a common architecture • Facilitates use of externally-developed components • Architecture constrains how components interact with their environment • How they receive and relinquish control • The data they work with and produce • The protocols they use for communication and resource sharing

  44. The Need for Multiple Views • As well as functionality, we need to reason about physical distribution, process communication and synchronisation … • May need different views to reflect the concerns of different stakeholders • The structure represented in a view • May or may not exist at runtime • May describe the product, the process of building the product, or the process of using the product

  45. Some Representative Views • Conceptual (Logical) View • Abstract representation of the functional requirements: block diagrams, class diagrams • Module (Development) View • Organisation of modules, components, subsystems (e.g. layered architecture) • Process (Coordination) View • Runtime behaviour: concurrency, synchronisation • The Physical View • Mapping of software onto hardware

  46. End Users - functionality Programmers - software management Conceptual Module Process Physical • System Integrators • performance • scalability • throughput • System engineers • system topology • delivery • installation • telecommunication Summary of Views

  47. Summing Up • Component-based software engineering is a highly structured way of working • Software architecture concerns the structural properties of a system ___________________________________ • Getting the software architecture right is a critical success factor in component-based software engineering

  48. Lecture 1 Part 3 - Object-Orientation & UML Contents • Overview • Classifiers • Static Modelling • Dynamic Behaviour • Summing Up

  49. Unified Modelling Language • Visual modelling language • Specify • Visualise • Construct • Document • UML can be used to capture information about: • Static structure • Dynamic behaviour • Environmental aspects • Organisational aspects

  50. Dynamic behaviour: communication patterns Deployment View Static View Behavioural View: Single Object customer vendor credit service height: Real age: Real timed out Person request item CreditCardCharges CustomerInterface ManagerInterface ServiceInterface ItemSeller ItemDB buy lock Available Locked Sold show availability select item unlock SalesServer 1 1 demand payment * * insert card SalesTerminal Client Male_Person Female_Person charge card Overview