Componentes de Software

1. Resumido e Adaptado dos apontamentos do Prof. José Tavares (Ambientes de Desenvolvimento Avaçados) 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

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.

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.

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

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

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.

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

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

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

11. Componentes de software

12. Componentes de software • Num contexto Service Oriented Architecture

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

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

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

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

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

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

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

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

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

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

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

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

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

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(...) { // … }

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

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

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

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

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

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

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

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

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#

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

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

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

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.

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.