Componentes de Software

1
Componentes de Software

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

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 (users 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 clients 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 whats 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 components 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. DSouza 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 components 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 components requires interfaces, and
• The component world it is prepared for
• OMG CORBA
• Microsoft COM, CLR
• Suns 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 _at_pre and _at_post as special tags for
  pre-conditions and post-conditions
• /
• _at_pre precondition
• _at_post postcondition
• /
• public void method1(...)
• //

26
Documentation CLR (.NET)

• Use ltpregt and ltpostgt as special tags for
  pre-conditions and post-conditions if XML
  comments are used
• /// ltpregt pre-condition lt/pregt
• /// ltpostgt post-condition lt/postgt
• ///
• public void method1(...)
• //

27
Example - JAVA

• /
• Returns the i-th element in the list
• _at_pre i gt 0 i lt size( )
• _at_post _at_nochange
• /
• public Object element(int i)

28
Example C

• /// ltsummarygt
• /// Returns the i-th element in the list
• /// lt/summarygt
• /// ltpregt i gt 0 i lt size( ) lt/pregt
• /// ltpostgt _at_nochange lt/postgt
• ///
• public Object element(int i)

29
Other logical expressions

• gt logical implication
• ltgt logical equivalence
• _at_forall x Range _at_ Expression
• Universally quantified expression
• _at_exists x Range _at_ Expression
• m n Integer range from m to n

30
A example

• /
• Inserts a new element into a list
• at the i-th position
• _at_pre item ! null i gt 0 i lt size( )
• _at_post size( ) size( )_at_pre 1
• _at_post _at_forall k 0 .. size( ) - 1 _at_
• (k lt i gt element(k)_at_pre element(k))
• (k i gt item_at_pre element(k))
• (k gt i gt element(k-1)_at_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
• _at_pre item ! null
• _at_post size( ) size( )_at_pre 1
• _at_post item_at_pre element(0)
• _at_post _at_forall k 1 .. size( ) - 1
• _at_ element(k-1)_at_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
• ltbody of Linked List heregt
• or
• public class DynamicArray implements List
• ltbody of DynamicArray heregt

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
  codes implicit contracts are transformed into
  explicit requirements that must be satisfied.