Component-Based Software Engineering

Component-Based Software Engineering Introduction and Overview Paul Krause

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

: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

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

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

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

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

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

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

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

Page Acquisition Page Store Software ICs?

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”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Component-Based Software Engineering