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

Transcription

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

2 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 1

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

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

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

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

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

8 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 7

9 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 8

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

11 10

12 Num contexto Service Oriented Architecture 11

13 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 12

14 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 European Conference on Object-Oriented Programming 13

15 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") 14

16 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.) 15

17 Characteristic properties (1) Independent Deployment Separated from its environment and other components Encapsulate its constituent features Cannot be partially deployed Hide the construction details 16

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

19 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. 18

20 Interfaces Each interface specification could be viewed as a contract between the component and a client Since the component and its clients are developed in mutual ignorance, the standardized contract must form a common ground for successful interaction Different interfaces will normally provide access to different services 19

21 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 20

22 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 21

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

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

25 Pre- and Post-Conditions 24

26 Documentation - JAVA as special tags for preconditions and post-conditions: /** precondition postcondition **/ public void method1(...) { // } 25

27 Documentation CLR (.NET) Use <pre> and <post> as special tags for preconditions and post-conditions if XML comments are used: /// <pre> pre-condition </pre> /// <post> post-condition </post> /// public void method1(...) { // } 26

28 Example - JAVA /** * Returns the i-th element in the list * i >= 0 && i < size( */ public Object element(int i); 27

29 Example C# /// <summary> /// Returns the i-th element in the list /// </summary> /// <pre> i >= 0 && i < size( ) </pre> /// </post> /// public Object element(int i); 28

30 Other logical expressions Example - Object Constraint Language (OCL) ==> logical implication <==> logical x : Expression Universally quantified x : Expression [m n] Integer range from m to n 29

31 An example /** * Inserts a new element into a list * at the i-th position * item!= null && i >= 0 && i <= size( ) size( ) == size( )@pre + k : [0.. size( ) - * (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); 30

32 An exercise Use this method to specify the interface to a method that inserts a new element to the head of a list 31

33 Solution /** * Inserts a new element at the head of a list * item!= null size( ) == size( )@pre + 1 item@pre == k : [1.. size( ) - element(k-1)@pre == element(k) */ public void inserthead(object item); 32

34 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 33

35 Example for a Use Case: Purchase Goods Goal of Use Case: A Consumer goes to the Retailer website with the intent of purchasing Consumer electronic products. Preconditions: 1. Product Catalog Exists 2. All state (warehouse levels etc) set back to predefined values 3. Payment and address details for Consumer are known 34

36 Success Post Conditions: 1. At least one product is shipped 2. The Consumer is returned a Confirmation page outlining which products will be shipped 3. The Retailer has requested the warehouses to ship the available goods. 4. Payment from the Consumer s credit card is triggered. Failed Post Conditions: The Consumer is returned an error stating that none of the items in the order can be fulfilled. 35

37 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 36

38 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# 37

39 38

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

41 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); 40

42 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 41

43 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); } 42

44 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 43

45 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 44

46 List 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 } 45

47 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> } 46

48 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 47

49 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. Novas funcionalidades devem ser colocadas noutra interface derivada 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.] 48

50 More on Components (Bertrand Meyer) Components are client oriented software The two basic conditions for a software element to be considered a component are that it be: Usable by other software elements. This excludes a program in the traditional sense that is meant to be used by humans or non-software triggers unless it has been componentized, meaning precisely adapted for use by other software. Usable by software elements whose authors are unknown to the component's authors. This excludes the case of routines, classes and other software elements used by other parts of the same software. A component must be of interest to a broad range of "clients" not directly connected to the original authors. 49

51 "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. [What to Compose Bertrand Meyer] 50

52 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. 51