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

Component-based software engineering How do you define a “Component”? How do you define “Component-based software engineering”? 5

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! 6

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 7

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

Motivation for CBSE – Develop software systems as assemblies of components – Reuse-driven & market-driven software development – Easing maintenance and evolution: design for change! 11

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 12

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 ClassName, superclass, super- interfaces, inner classes, fileds, constructors, Methods FieldName, type ConstructorParameters, exceptions MethodName, parameter, return type, exceptions

N tier Architecture

Software Architecture Point of View The software architecture of a program or computing system is the structure or structures of the system, which comprise software components [and connectors], the externally visible properties of those components [and connectors] and the relationships among them... [and the environment]

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

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 38

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