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

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

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

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

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

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

10. 9 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

11. 10 Componentes de software

12. 11 Componentes de software Num contexto Service Oriented Architecture

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

14. 13 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

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

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

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

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

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

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

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

24. 23 Componentes de software Pre- and Post-Conditions

25. 24 Documentation - JAVA Use “@pre” and “@post” as special tags for pre- conditions and post-conditions: /** *@pre precondition *@post postcondition **/ public void method1(...) { // … }

26. 25 Documentation – CLR (.NET) Use “ ” and “ ” as special tags for pre- conditions and post-conditions if XML comments are used: /// pre-condition /// post-condition /// public void method1(...) { // … }

27. 26 Example - JAVA /** * Returns the i-th element in the list * * @pre i >= 0 && i < size( ) * @post @nochange */ public Object element(int i);

28. 27 Example – C# /// /// Returns the i-th element in the list /// /// i >= 0 && i /// @nochange /// public Object element(int i);

29. 28 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

30. 29 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 element(k)@pre == element(k)) && *(k == i ==> item@pre == element(k)) &&item@pre *(k > i ==> element(k-1)@pre == element(k) */ public void insert(Object item, int i);

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

32. 31 Solution /** * Inserts a new element at the head of a list * * @pre item != null * @post size( ) == size( )@pre + 1 * @post item@pre == element(0)item@pre * @post @forall k : [1.. size( ) - 1] @ element(k-1)@pre == element(k) */ public void insertHead(Object item);

33. 32 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

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

35. 34 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#

36. 35 Componentes de software

37. 36 Componentes de software Abstract class An abstract class is one whose main purpose is to define a common interface for its subclassesabstract class

38. 37 Componentes de software 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); }

39. 38 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

40. 39 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); }

41. 40 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

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

43. 42 Componentes de software 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… }

44. 43 Componentes de software Implementations of List We can have several different implementations of the List interface: public class LinkedList implements List { } or: public class DynamicArray implements List { }

45. 44 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. ]Design Patterns: Elements of Reusable Object-Oriented Software

46. 45 Componentes de software Meyer: "Seven Criteria for Components“"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.

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