SOFTWARE DESIGN AND ARCHITECTURE

LECTURE 32

Review

• Behavioral Patterns– Observer Pattern– Chain of command

Outline

• Component Based Software Engineering– Components– Component Based Design– Component Model– CBSE

COMPONENT BASED SOFTWARE ENGINEERING

5

Component-based software engineering

• How do you define a “Component”?• How do you define “Component-based

software engineering”?

6

What is a Component?

• Several definitions of a component in literature, however everyone agrees that a component is a piece of software… But this requires clarification!

7

What is a Component?

• Components provide a service without regard to where the component is executing or its programming language

– A component is an independent executable entity that can be made up of one or more executable objects

– The component interface is published and all interactions are through the published interface

Component

• The Object Management Group’s “Modeling Language Specification” defines a component as – “a physical, replaceable part of a system that

packages implementation and provides the realization of a set of interfaces.

– A component represents a physical piece of system’s implementation, including software code (source, binary or executable) or equivalents, such as scripts or command files.

Component• Provides a service: implementation-independent• Need not to be compiled• Executable • More abstract than classes

Components can be made of

• Source code– Classes – one or more, possibly related

• Executable code– Object code– Virtual object code

• Other files– Images, text, indices

11

Motivation for CBSE

– Develop software systems as assemblies of components

– Reuse-driven & market-driven software development

– Easing maintenance and evolution: design for change!

12

Component view points

• There are many definitions of components: – Consideration of CBSE from different viewpoints and

focus on different aspects of software engineering

• Design viewpoint: components as reusable design parts

• Architecture viewpoint: – High-level representation(structural and behavioral)

of a service/computation

• Implementation viewpoint:– Components confirmed to a specific component

model– At run time could be binary packages, distributed

components

• Business viewpoint: – buy vs. build (Commercial-off-the-shelf COTS

components)

Manifests

• Since components can consist of several parts, they are typically packaged with a list of their contents.

• Manifests contain information such as:– Identification of the component– Authorship of the component– List of the files or classes making up this component– Other components on which this one relies– Encryption information– Means of verifying that all parts of the component are present– Version number

introspection

• The information about the component is called metadata and the process of obtaining it is introspection

Class Name, superclass, super-interfaces, inner classes, fileds, constructors, Methods

Field Name, type

Constructor Parameters, exceptions

Method Name, parameter, return type, exceptions

N tier Architecture

Component Characteristics

• Standardised– A component has to conform to some standardised

component model• This model may define component interfaces, component meta-

data, documentation, composition and deployment

• Independent– A component should be independent

• It should be possible to compose and deploy it without having to use other specific components

– In situations where the component needs externally provided services, these should be explicitly set out in a ‘requires’ interface specification

Component Characteristics

• Composable– For a component to be composable,

• All external interactions must take place through publicly defined interfaces

• In addition, it must provide external access to information about itself such as its methods and attributes

• Deployable– To be deployable,

• A component has to be self-contained and must be able to operate as a stand-alone entity on some component platform that implements the component model

• This usually means that the component is a binary component that does not have to be compiled before it is deployed

• Explicit context dependencies– Specification of the deployment and run-time

environments• Which tools, platforms, resources, other components are

required?

• Documented– Components have to be fully documented so that

potential users of the component can decide whether or not they meet their needs• The syntax and, ideally, the semantics of all component

interfaces have to be specified

• Marketable entity– A component is a self-contained binary piece of software

that one can typically purchase in the open market• Not a complete application

– A component can be combined with other components to form a complete application (or an even bigger component)

• It can be used in unpredictable combinations– A component can be used in ways that were totally

unanticipated by the original developer– Components can be combined with other components

using plug-and-play

UML

Interfaces

• Act as a “contract”• Requires• Provide

• Interfaces– Can include operations, method calls, etc that pass

messages to component to ask for services

– Can declare exceptions to indicate that the operation did not perform successfully

Component Diagram

• In UML 2 a component is merely a specialized version of the class concept.

• The notation rules that apply to the class classifier also apply to the component classifier.

• A component is drawn as a rectangle with optional compartments stacked vertically.

• Can be modeled as just a rectangle with the component's name and the component stereotype text and/or icon.

• The component stereotype's text is «component»" and the component stereotype icon is a rectangle with two smaller rectangles protruding on its left side (the UML 1.4 notation element for a component).

Figure: The different ways to draw a component's name compartment

Component Diagram

• The interfaces provided represent the formal contract of services the component provides to its consumers/clients.

• Figure shows the Order component having a second compartment that denotes what interfaces the Order component provides and requires– Even though components are – autonomous units they still may– depend on the services provided – by other components.

Component Diagram• Another approach to modeling a component's interfaces: Builds

off the single rectangle, with the component's name in it, and places interface symbols connected to the outside of the rectangle.

• In this second approach the interface symbols with a complete circle (lollipop) at their end represent an interface that the component provides.

• Interface symbols with only a half circle at their end (sockets) represent an interface that the component requires (in both cases, the interface's name is placed near the interface symbol itself).

Component Diagram• Modeling a component's relationships• When showing a component's relationship with other components, the

lollipop and socket notation must also include a dependency arrow.• On a component diagram with lollipops and sockets, note that the

dependency arrow comes out of the consuming (requiring) socket and its arrow head connects with the provider's lollipop, as shown in Figure.

• Assembly connectors are drawn as lollipop and socket symbols next to each other. Drawing these assembly connectors in this manner makes the lollipop and socket symbols very easy to read.

Figure 5: A component diagram that shows how the Order System component depends on other components

Component Diagram

Figure: This component's inner structure is composed of other components

An example of UML 2.5 component diagram for online shopping.

Contractual interfaces• A specification attached to an interface that mutually binds the

clients and providers of the components• Functional Aspects (API)• Pre- and post-conditions for the operations specified by API

– Preconditions denoting the constraints which need to be met by the client

– Postconditions denoting the constraints which the component promises to fulfill in return

– A component may also additionally satisfy global constraints called invariants

• Non-functional aspects (different constrains, environment requirements, etc.)

Component Model• A component model is a definition of standards for component

implementation, documentation and deployment– Examples of component models

• EJB model (Enterprise Java Beans)• .NET model• Corba Component Model

• The component model specifies how interfaces should be defined and the elements that should be included in an interface definition

• Different application domains have different needs for component-based systems– Different non-functional properties: performance, security, reliability,

scalability, etc.

Elements of a component model

38

CBSE• Describes the principles and practices of systematically engineering

software systems from components– CBSE process models vs. classical models

• CBS lifecycle, reuse approach, Unified Process – Requirements & design

• Requirements engineering approaches to CBSE• Describes Unified Modeling Language (UML) notations to the

specification, design, and modeling of components-based software– Component-based software architectures

• Styles, specification, refinements, and paradigms (e.g. Service-oriented architectures, middleware-induced software architectures, Model-Driven Architectures)

• Dependability issues in CBSE

Summary

• Component Based Software Engineering– Components– Component Based Design– Component Model– CBSE