Componentes de Software

47
Componentes de Software Resumido e Adaptado dos apontamentos do Prof. José Tavares (Ambientes de Desenvolvimento Avaçados)

description

Resumido e Adaptado dos apontamentos do Prof. José Tavares (Ambientes de Desenvolvimento Avaçados). Componentes de Software. Componentes de software. Software Components mean? The main driver behind software components is reuse. - PowerPoint PPT Presentation

Transcript of Componentes de Software

Page 1: Componentes de Software

Componentes de Software

Resumido e Adaptado dos apontamentos do Prof. José Tavares(Ambientes de Desenvolvimento Avaçados)

Page 2: Componentes de Software

2

Componentes de software 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…).

Easily maintaining and customizing those parts to produce new features

Goals (user´s demands) Build more reliable software Less time between versions

Page 3: Componentes de Software

Componentes de software Why use Software Component?

Components are the way to go because all other engineering disciplines introduced components as they became mature - and still use them.

Use component paradigm to simulate “Software Integrated Circuit” to resolve software crisis.

Component software represents the maturation (industrialization) of software development practices.

3

Page 4: Componentes de Software

Componentes de software Some traditional software problems

large software systems are extremely complex large, monolithic systems are difficult to design

and build and even harder to maintain. Reliability and robustness is a major problem.

It is difficult to reuse assets-- e.g. design knowledge, software--across multiple projects.

Tailoring of software products for different user requirements is difficult.

4

Page 5: Componentes de Software

Componentes de software Two traditional software development extremes.

Custom-Made Software - develop from scratch Advantages:

Flexible, competitive edge Optimally adapted to client’s business model Take advantage of any in-house proprietary knowledge

or practice Disadvantages:

Burden of maintenance, product evolution, and interoperability

Expensive undertaking In a world of rapidly changing business requirements

is often too late to be productive before becoming obsolete

Lead to project fail partially or completely

5

Page 6: Componentes de Software

Bought and parameterized software Advantages:

Limit financial risk Minimize time-to-market risk Burden of maintenance, product evolution, and

interoperability is left to vendor

Disadvantages: May necessitate a greater reorganization of business

processes No competitive edge using a standard software that is

also available to competitor Not nimble enough to adapt to changing needs

6

Page 7: Componentes de Software

Benefits of Using Components Provides a middle path between the 2 extremes

of traditional software development Although each bought component is a

standardized product, the process of component assembly allows significant customization.

Individual component can be custom-made to suit specific requirements or to foster strategic advantages.

Puts an end of massive upgrade cycles since evolution replace revolution. Individual upgrading of components as needed and ‘out of phase’ can allow for smoother operations.

7

Page 8: Componentes de Software

8

Componentes de software 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 maximizing reuse Utility computing

Page 9: Componentes de Software

9

Componentes de software So what’s new?

Modularisation of software is not new. What we want of a component is that

l 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

Page 10: Componentes de Software

10

Componentes de software Are Components New? Subroutines

Turing, 1949, Checking a Large Routine Structured Programming

Dijkstra, 1968 Libraries, Packages

NAG, 1971 Information Hiding, Encapsulation

Parnas, 1972

Page 11: Componentes de Software

11

Componentes de software

Page 12: Componentes de Software

12

Componentes de software Num contexto Service Oriented Architecture

Page 13: Componentes de Software

13

Componentes de software Software Components

Components are for composition 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

Page 14: Componentes de Software

14

Componentes de software 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

Page 15: Componentes de Software

15

Componentes de software Definition

A self-contained piece of software that can be independently deployed and plugged into an environment that provides a compatible socket. It has well-defined run-time interfaces, and it can cooperate out of the box with other components (Peter Herzum, Olivier Sims, "Business Component

Factory")

Page 16: Componentes de Software

Definition An independently deliverable unit of software

that encapsulates its design and implementation and offers interfaces to the outside, by which it may be composed with other components to form a larger whole.

(From: Objects, Components, and Frameworks with UML--The Catalysis

Approach, by D. D’Souza and A. Wills, Addison Wesley, 1998.)

16

Page 17: Componentes de Software

17

Componentes de software Characteristic properties (1)

Independent Deployment Separated from its environment and other

components Encapsulate its constituent features Cannot be partially deployed Hide the construction details

Page 18: Componentes de Software

Characteristic properties (2) Third-party composition

Self-contained Must have clear specifications of what it

requires, as well as what it provides Needs to encapsulate its implementation Interact with its environment by means of

well-defined interfaces

18

Page 19: Componentes de Software

19

Componentes de software Interfaces

Define component’s access points - allow the clients of a component to access the services provided by a component

Interfaces specifies signature and behavior Interface nominally consists of a set of named

operations (methods). The semantics (behavior) of each operation must

be precisely specified. Different interfaces will normally provide access

to different services Each interface specification could be viewed as a

contract between the component and a client

Page 20: Componentes de Software

20

Componentes de software 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

• OMG CORBA Microsoft COM, CLR Sun’s Java

Interoperability

Page 21: Componentes de Software

21

Componentes de software Interfaces as contracts

Provider (supplier): The entity (component) that implements the operations of an interface.

Client (user): An entity that uses (invokes) the services provided by an interface.

Can view an interface specification as a “contract” between the client and a provider

So the interface specification must state: What the client needs to do What a provider can rely on What a provider must promise in return What the client can rely on

Page 22: Componentes de Software

22

Componentes de software Interfaces:

A contract is an apropriate aproach, with pre- and pos- conditions atached to every operation

decouple clients and providers The same interface may be used by large numbers of different clients also be supported by large numbers of providers

Page 23: Componentes de Software

23

Componentes de software Pre- and Post-Conditions

Pre-conditions: What the client must establish before calling

the operation The provider can rely on this condition being

true whenever the operation is called Post-conditions:

What the provider must establish before returning to the client

The client can rely on this condition being true whenever the call to the operation returns

Page 24: Componentes de Software

24

Componentes de software

• Pre- and Post-Conditions

Page 25: Componentes de Software

25

Documentation - JAVA Use “@pre” and “@post” as special tags for pre-

conditions and post-conditions:

/*** @pre precondition* @post postcondition**/public void method1(...){

// …}

Page 26: Componentes de Software

26

Documentation – CLR (.NET) Use “<pre>” and “<post>” as special tags for pre-

conditions and post-conditions if XML comments are used:

/// <pre> pre-condition </pre>/// <post> post-condition </post>///public void method1(...){

// …}

Page 27: Componentes de Software

27

Example - JAVA

/*** Returns the i-th element in the list** @pre i >= 0 && i < size( )* @post @nochange*/

public Object element(int i);

Page 28: Componentes de Software

28

Example – C#

/// <summary>/// Returns the i-th element in the list

/// </summary>/// <pre> i >= 0 && i < size( ) </pre>/// <post> @nochange </post>///

public Object element(int i);

Page 29: Componentes de Software

29

Other logical expressions

==> logical implication

<==> logical equivalence

@forall x : Range @ Expression

Universally quantified expression

@exists x : Range @ Expression

[m … n] Integer range from m to n

Page 30: Componentes de Software

30

A example

/*** Inserts a new element into a list * at the i-th position* * @pre item != null && i >= 0 && i <= size( )* @post size( ) == size( )@pre + 1* @post @forall k : [0 .. size( ) - 1] @* (k < i ==> element(k)@pre == element(k)) &&* (k == i ==> item@pre == element(k)) &&* (k > i ==> element(k-1)@pre == element(k)*/

public void insert(Object item, int i);

Page 31: Componentes de Software

31

An exerciseUse this method to specify the interface to a method that inserts a new element to the head of a list

Page 32: Componentes de Software

32

Solution

/*** Inserts a new element at the head of a list* * @pre item != null* @post size( ) == size( )@pre + 1* @post item@pre == element(0)* @post @forall k : [1 .. size( ) - 1] @ element(k-1)@pre == element(k)*/

public void insertHead(Object item);

Page 33: Componentes de Software

33

How does this help? This separation between what a function

does and how the function works is extremely important

As this stands, the comments provide guidance only

They prescribe what should be done, but are agnostic about whether a specific implementation satisfies them

We can, however, provide run-time checks through the use of Assertions

Page 34: Componentes de Software

34

Componentes de software OO Interface

Sometimes we may find two or more different subclasses share some common behaviour

In this case, they are not strictly “kinds of” some common parent

Rather, they “behave like” some common pattern (under certain circumstances)

We say that they both implement a common interface

Page 35: Componentes de Software

35

Componentes de software Interfaces

public interface Cashier {

public void deposit( int id, double amount);

public boolean withdraw( int id, double amount);

}

An interface is pure specification - it contains no implementation

Identical in C#

Page 36: Componentes de Software

36

Componentes de software

Page 37: Componentes de Software

37

Componentes de software

• Abstract class

• An abstract class is one whose main purpose is to define a common interface for its subclasses

Page 38: Componentes de Software

38

Componentes de softwarepublic abstract class EllipticalShape {public abstract double area( );public abstract double circumference( );

}

public interface Cashier {

public void deposit(int id, double amount);

public boolean withdraw(int id, double amount);

}

Page 39: Componentes de Software

39

Componentes de software

Abstract Class Can include class and

instance fields

May include concrete implementations of methods

A concrete class can only extend a single abstract class

Interface

• Can only include static final fields

• All methods must be abstract declarations - no implementation

• A class can implement multiple interfaces

Page 40: Componentes de Software

40

Componentes de software Interface / Abstract class

public abstract class EllipticalShape {public abstract double area( );public abstract double circumference( );

}

public interface Cashier {public void deposit(int id, double amount);

public boolean withdraw(int id, double amount);

}

Page 41: Componentes de Software

41

Componentes de software Design Guideline:

“When the functionality supported by a class can be implemented in different ways, it is advisable to separate the interface from the implementation”

Xiaoping Jia

Object-Oriented Software Development Using Java

Page 42: Componentes de Software

42

Class V Interface Uma classe define o estado interno do objecto e a

implementação das suas operações. Um tipo de objectos apenas se refere à sua interface –

conjunto de pedidos a que pode responder Um objecto pode ter vários tipos e objectos de várias

classes podem ser do mesmo tipo. Herança de classes define uma implementação do

objecto baseada na implementação de outro objecto – super

Herança de interface ( subtyping) descreve quando um objecto pode ser usado no lugar de outro

Page 43: Componentes de Software

43

Componentes de softwareList as an example

public interface List {public int size( );public boolean isEmpty( );public Object element(int i);public Object head( );public Object last( );public void insert(Object item, int i);public void insertHead(Object item);public void insertLast(Object item); // more…

}

Page 44: Componentes de Software

44

Componentes de software Implementations of List

We can have several different implementations of the List interface:

public class LinkedList implements List

{

<body of Linked List here>

}

or:

public class DynamicArray implements List {

<body of DynamicArray here>

}

Page 45: Componentes de Software

45

Componentes de software Interfaces (cont)

Separar a interface da implementação permite múltiplas implementações da mesma ideia.

Para manter o código genérico, deve-se trabalhar com a interface e não com o tipo de uma implementação particular

Separar a interface da implementação permite alterar a implementação sem afectar a interface Permite alterar a implementação sem afectar os clientes dessa

interface Clientes não estão ligados às classes de implementação

As interfaces devem ser imutáveis de modo a não quebrar o contracto estabelecido com os clientes

Herança de interfaces permite o “upgrade” de uma interface. Uma variável do tipo interface pode fazer referência a qualquer

objecto que implemente essa interface

Programming to an Interface, not an Implementation

[ GOF Design Patterns: Elements of Reusable Object-Oriented Software.]

Page 46: Componentes de Software

46

Componentes de software Meyer: "Seven Criteria for Components“

May be used by other software elements (clients). May be used by clients without the intervention of the

component's developers. Includes a specification of all dependencies (hardware

and software platform, versions, other components). Includes a precise specification of the functionalities it

offers. Is usable on the sole basis of that specification. Is composable with other components. Can be integrated into a system quickly and smoothly.

Page 47: Componentes de Software

47

Design by Contract DBC was first introduced by Bertrand Meyer as part of

the Eiffel Project. Under the DBC theory, a software system is viewed as

a set of communicating components whose interaction is based on precisely defined specifications of the mutual obligations – contracts.

DBC provides a formal way to incorporate specification information, which is obtained from comments, into the code. By doing this, the code’s implicit contracts are transformed into explicit requirements that must be satisfied.