Engenharia de Software

1

• Engenharia de Software
• 2007.1
• Projeto com Reuso
• 31/05/07

2
Reutilização de software

• Na maioria das disciplinas de engenharia,
  sistemas são projetados com base na composição de
  componentes existentes que foram utilizados em
  outros sistemas.
• A engenharia de software, até então, tinha como
  base o desenvolvimento tradicional.
• Para alcançar software com mais qualidade, de
  forma mais rápida e com baixo custo, é necessário
  adotar um processo de desenvolvimento baseado na
  reutilização generalizada e sistemática de
  software.

3
Engenharia de software baseado no reuso de
software

• Reuso de sistemas de aplicações
• Todo o sistema pode ser reutilizado pela sua
  incorporação, sem mudança, em outros sistemas
• Reuso de Componentes
• Componentes de uma aplicação que variam desde
  subsistemas até objetos isolados podem ser
  reutilizados
• Reuso de funções
• Componentes de software que implementam uma única
  função podem ser reutilizados

4
Artefatos reusáveis

• Afinal, o que se pode reusar?
• Código compilado
• Casos de testes
• Modelos e projetos frameworks e padrões
• Interface de usuário
• Planos, estratégias e regras arquiteturais
• Soluções
• Idéias

5
Reuso de Software

• Software reuse is the use of existing software
  knowledge or artifacts to build new software
  artifacts Frakes, 1995
• Vantagens (em POTENCIAL)
• MAIS Qualidade
• MENOS Tempo de desenvolvimento
• MENORES custos TOTAIS no ciclo de vida
• Implementação, testes, integração, documentação,
  manutenção, evolução

6
Benefícios do Reuso

• Maior confiabilidade
• Os componentes já foram experimentados e testados
  em sistemas que já estão funcionando.
• Redução dos riscos de processo
• Menos incertezas sobre as estimativas de custos
  de desenvolvimento.
• Uso efetivo de especialistas
• Reuso de componentes ao invés de pessoas.
• Conformidade com padrões
• Os padrões são embutidos ao se reutilizar
  componentes. Ex padrões de interfaces com o
  usuário
• Desenvolvimento acelerado
• Reduz tempo do desenvolvimento e validação,
  acelerando a produção

7
Benefícios do Reuso

• Resumindo -gt Produtividade
• Trabalhar mais rápido
• Automação, ambientes, ferramentas
• Substituir trabalho humano
• Trabalhar mais inteligentemente
• Melhoria do(s) processo(s)
• Evitar/reduzir tarefas de pouco valor
• Evitar o trabalho propriamente dito
• Reuso de ARTEFATOS do CICLO DE VIDA
• Evitar/reduzir o desenvolvimento de artefatos
  específicos para cada projeto

8
Modelo Incremental para adoção de Reuso
Reuse enabled business
Benefit
Systematic Domain- specific reuse
High reuse levels
Broader coverage
Architecture reuse
Reduced maintenance costs
Managed workproducts
Black box code reuse
Reduced Development time
Code leverage
None
Investment, experience
9
O que são Padrões

• O que é?
• Nova categoria de conhecimento
• Conhecimento não é novo, mas falar sobre ele é
• Objetivo conhecer o que você já conhece
• Como?
• Partindo de problemas e soluções recorrentes em
  diferentes áreas do conhecimento

10
O que é um Padrão (Cont.)

• Aplicação
• Arquitetura
• Ciência da Computação
• Engenharia de software
• Engenharia Mecânica
• Telecomunicações
• ...

11
O que é um Padrão (Cont.)

• Por que padrões de software?
• engenheiros de software não iniciam o seu projeto
  do nada
• ao contrário, nós reutilizamos idéiasque já
  vimos antes
• as mesmas técnicas são utilizadas repetitivamente
• a indústria de software necessita documentar o
  que nós fazemos

12
Diferentes Definições

• Um padrão é uma entidade que descreve um
  problema que ocorre repetidamente em um ambiente
  e então descreve a essência da solução para este
  problema, de tal forma que você use esta solução
  milhões de vezes, sem nunca utilizá-la do mesmo
  modo, Christopher Alexander

13
Diferentes Definições (Cont.)

• Um padrão é um pedaço de literatura que descreve
  um problema de projeto e uma solução geral para o
  problema num contexto particular, James Coplien

14
Diferentes Definições (Cont.)

• Um padrão é uma solução provada para um problema
  em um contexto, Comunidade de Software

15
Um Pouco da História

• Object-Oriented (OO)
• Metade do anos 80
• Padrões de software emergiram de objetos
• Ward Cunningham and Kent Beck
• 1987 linguagem de padrões para interface de
  usuário
• James Coplien
• 1988 idioms
• Erich Gamma, Richard Helm, Ralph Johnson, and
  John Vlissides
• 1990 ? 1995 Padrões de projeto (Design Patterns)

16
Diferentes tipos de padrões

• Etapas de Desenvolvimento de Sistemas
• Requisitos, Análise, Projeto, Implementação e
  Teste
• Domínio de Aplicação
• Segurança, BD, GUI, XML, Web, Sistemas
  Distribuídos
• Camada de Aplicação do Padrão
• Negócios, Apresentação, Integração (Sun)
• Classificação de Autores
• GoF Estrutural, Comportamental, Criação
• POSA Sistemas Interativos, Organização do
  Trabalho, Comunicação

17
Classificação dos Padrões de Software (Cont.)
Análise
Projeto
Requisitos
Implementação
18
Padrões de Requisitos

• Documentam as necessidades do usuário e o
  comportamento genérico do sistema em um alto
  nível de abstração
• Ações que os desenvolvedores de software podem
  tomar para melhorar os requisitos não-funcionais
• Mostram os relacionamentos entre o usuário ou o
  operador e o sistema

19
Padrões de Requisitos (Cont.)

• Fault-tolerant telecommunication patterns
• Visa a manutenção dos sistemas de comutação
• Medidas apropriadas para serem tomadas no estágio
  de desenvolvimento de requisitos
• Padrões relacionados a confiabilidade (mensagens
  do sistema e falhas do sistema)
• Five minutes of no escalation messages
• Padrões relacionados aos fatores humanos

20
Padrões de Análise

• Inicialmente apresentados como complementos aos
  padrões de projeto
• Um passo antes do projeto
• Modelo de análise que focaliza nas estruturas
  conceituais
• Padrões de análise do Martin Fowler
• Domínio de conhecimento de software de negócios
• Party, quantity, subtype state machines, entre
  outros

21
Padrões de Análise (Cont.)

• Party
• Problema pessoas e organizações têm
  responsabilidades semelhantes
• Solução Crie um tipo party como um supertype de
  uma pessoa ou organização

22
Padrões de Projeto

• Estrutura repetida de elementos de projeto
• Um esquema para o refinamento de subsistemas ou
  de componentes de sistemas ou as relações entre
  eles.
• ...resolvem um problema geral de projeto num
  contexto particular., GoF
• Padrões de projeto que incluem detalhes de código
  de baixo nível
• Aplicados a diferentes tipos de problemas
• Padrões Arquiteturais e Meta-Padrões podem ser
  considerados Padrões de Projeto.

23
Idiomas

• Relacionados com a implementação de
  características de projeto específicas
• Padrão de baixo nível específico para uma
  linguagem de programação
• Idiomas em C
• C Programming Styles and Idioms, James Coplien,
  1991

24
Idiomas (Cont.)

• Nome Counted Body
• Contexto A interface de uma classe é separada de
  sua implementação (respectivamente, classes
  handle e body)
• Problema atribuição em C é definida
  recursivamente como membro-por-membro com cópia
  quando a recursão termina
• Solução Um contador de referência é adicionado à
  classe body para facilitar o gerenciamento de
  memória
• Autor e data James Coplien, 1994

25
A Comunidade de Padrões

• Uma hierarquia de workshops de escritores
• Grupos de leitura local
• Grupo Hillside
• Livros com os artigos da conferência
• Conferências PLoP ao redor do mundo

26
Ética de Padrões

• Regra de Buschmann nunca capture suas próprias
  idéias em um padrão
• Não pense que padrões resolvem tudo
• Tente sempre encorajar as pessoas a repassar os
  conhecimentos
• Sempre reconheça aqueles que criaram as técnicas
  ou que primeiro se empenharam a escrever sobre
  elas
• Padrões são apenas mais uma técnica para
  ajudá-lo no desenvolvimento de software

27
Reuso

• Conheça os padrões que estão disponíveis
• Catálogo de padrões de 2000
• Escolha aquele que satisfaz as suas necessidades
• Um padrão é difícil de entender se você não
  necessita dele
• Apenas tenha uma visão geral
• Utilize o vocabulário dos padrões em revisões e
  sessões de projeto

28
Reuso (Cont.)

• GoF
• Bastante utilizado entre a comunidade de software
• Core J2EE Pattern Catalog
• http//java.sun.com/blueprints/corej2eepatterns/
• Padrões Arquiteturais
• Frank Bushmann, Regine Meunier, Hans Rohnert,
  Peter Sommerlad, Michael Stal (Gang of Five)

29
GoF Design Patterns

• Behavioral Patterns
• Chain of Responsibility
• Command
• Interpreter
• Iterator
• Mediator
• Memento
• Observer
• State
• Strategy
• Template Method
• Visitor

Creational patterns Abstract factory
Builder Factory method Prototype
Singleton
Structural patterns Adapter Bridge Composite D
ecorator Facade Flyweight Proxy
30
Core J2EE Pattern Catalog
Presentation Tier Intercepting Filter Front
Controller View Helper Composite View
Service to Worker Dispatcher View

• Integration Tier
• Data Access Object
• Service Activator

Business Tier Business Delegate Service
Locator Session facade Transfer Object
Transfer Object Assembler Value List
Handler Composite Entity
31
Architectural Patterns
From Mud to Structure Layers Pipes and
Filters Blackboard

• Adaptable Systems
• Reflection
• Microkernel

Distributed Systems Broker Pipes and
Filters Microkernel
Interactive Systems Model-View-Controller
Presentation-Abstraction-Control
32
Template
33
Maiores Informações

• Página de Padrões do Grupo Hillside
• http//hillside.net
• Apontadores para listas, livros, arquivos ftp,
  padrões on-line, conferências, entre outros
• Listas
• Gang-of-4-patterns-request_at_cs.uiuc.edu
• Patterns-request_at_cs.uiuc.edu
• Patterns-discussion-request_at_cs.uiuc.edu
• Padroes-l_at_great.ufc.br
• Repositório de Padrões Portland
• http//c2.com/ppr/index.html

34
Em resumo ...

• Arquitetos experientes não têm consciência que
  utilizam padrões
• Bons para compartilhar informação e capturar
  conhecimento
• Padrões funcionam como uma porta para troca de
  experiências
• Pode ajudar novos desenvolvedores a aprenderem
  com os mais experientes
• Vocabulário Comum
• Padrões dão uma competência arquitetural de
  organização

35
Em resumo ... (Cont.)

• Você deve escrever padrões para
• Aprender mais sobre padrões
• Compartilhar conhecimento
• Provavelmente você usa alguma coisa que não foi
  documentada ainda
• Tarefa difícil e nem todos tem tempo ou vontade
• Você deve reutilizar padrões
• Em busca de uma melhoria no desenvolvimento de
  software

36
Component

• Dictionary definition
• A unit of, part of a model
• Hardware components
• Software components

• Differences?

37
What is a component? (1)

• 1. A component is a nontrivial, nearly
  independent, and replaceable part of a system
  that fulfills a clear function in the context of
  a well-defined architecture. A component conforms
  to and provides the physical realization of a set
  of interfaces. (Philippe Krutchen, Rational
  Software)
• 2. A runtime software component is a
  dynamically bindable package of one or more
  programs managed as a unit and accessed through
  documented interfaces that can be discovered at
  runtime. (Gartner Group)

38
What is a component? (2)

• 3. 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 third-party
  composition. (Clemens Szyperski)
• 4. A business component represents the software
  implementation of an autonomous business
  concept or business process. It consists of the
  software artifacts necessary to express,
  implement, and deploy the concept as a reusable
  element of a larger business system. (Wojtek
  Kozaczynski, SSA)

39
What is a component? (3)

• 5. A reusable part of software, which is
  independently developed, and can be brought
  together with other components to build larger
  units. It may be adapted but may not be modified.
  
• A component can be, for example, a compiled
  code without a program source, or a part of a
  model and/or design.
• --- D'Souza and Wills

40
What is a component? (4)

• 6. A software component is a software element
  that conforms to a component model and can be
  independently deployed and composed without
  modification according to a composition standard.
  
• --- Councill and Heineman

41
What are in common?

• A piece of software
• Independently deployable
• Composable
• Self-contained
• Reusable
• A set of interfaces provided to, or required from
  the environment.
• An executable code, which can be coupled to the
  code of other components via interfaces.

42
Implications

• The following implications arise as a result of
  Szyperskis definition
• For a component to be deployed independently, a
  clear distinction from its environment and other
  components is required.
• A component must have clearly specified
  interfaces.
• The implementation must be encapsulated in the
  component and is not directly reachable from the
  environment.

43
Implications

• A software component simply cannot be
  differentiated from other software elements by
  the programming language used to implement the
  component.
• The difference is in how software components are
  used.

44
DBC

• Abordagem de desenvolvimento de software na qual
  todos os aspectos e fases do ciclo de vida do
  desenvolvimento, incluindo análise de
  requerimentos, arquitetura, projeto, construção,
  testes, distribuição, suporte técnico, e também a
  gerência de projeto, são baseados em componentes.

45
Commonality and Difference

• SP (Structured Programming)
• OOP (Object-Oriented Programming)
• COP (Component-Oriented Programming)
• What are common?
• What are different?

46
(No Transcript)
47
Composability

• Software entity and its ability of being
  integrated with other entities
• SP functions, procedures low
• OOP classes, objects high
• COP components very high

48
The Interchangeability

• Interchangeable parts are components of any
  device designed to specifications which insure
  that they will fit within any device of the same
  type.
• SP Two different implementations can never be
  interchangeable.
• OOP Two different objects implementing the same
  specification are interchangeable.
• COP Two different components with different
  specifications are interchangeable as long as
  they satisfy those interface requirements for all
  client components.

49
Component Goals

• If you are asked to name three goals for using
• component technology, what are they?
• Conquering complexity
• Managing change
• Reuse

50
Conquering Complexity

• We are living in a complex world!
• The world produces between 1 and 2 exabytes of
  unique information per year, which is roughly 250
  megabytes for every man, woman, and child on
  earth. An exabyte is a billion gigabytes, or 1018
  bytes.
• http//www.sims.berkeley.edu/research/projects/how
  -much-info/summary.html

51
Managing Change

• Change is inherent in software engineering.
• The user requirements change, specifications
  change, personnel change, budgets change,
  technology change, etc. etc.
• This means building for change, design for
  change, is necessary.
• It is important to place primary emphasis during
  architecture and design on the dependencies
  between the components, and the management of
  those dependencies.

52
Reuse

• Design and implement something once and use it
  over and over again in different contexts.
• This will realize large productivity gains,
  taking advantage of best-in-class solutions, the
  consequent improved quality, and so forth.
• Develop for reuse, and develop with reuse

53
CBSE

• Component-Based Software Engineering
• CBSE COA COD COP COM
• Two key activities
• Development for reuse
• Development with reuse

54

• Para se criar um componente, devemos primeiro
  garantir
• Que os serviços que o componente oferece,
  independam do contexto
• Que os dados que o componente trabalha, sejam
  acessíveis em qualquer projeto
• Que o componente defina e implemente sua
  interface padrão
• Que o componente esteja dentro de um container
  padrão

55
Conclusão

• Objeto vs. Componente
• Componentes são independentes do contexto onde
  são usados.
• Criado de tal forma que funciona em qualquer
  projeto de software, módulo ou container.
• Objetos são projetados para um fim específico, e
  não podem (ou não devem) ser utilizados em outros
  contextos.
• Ex se você criar um objeto Pedido para um
  sistema de atacado, dificilmente este objeto
  poderá ser utilizado em outro aplicativo como um
  aplicativo de gestão de recursos humanos.

56
Conclusão

• Objeto vs. Componente
• Quando modelamos objetos, pensamos primeiramente
  no problema que tentamos resolver
• Componentes são projetados para serem elementos
  chave de qualquer aplicativo de software
• Todo componente deve ter suas interfaces bem
  definidas
• 3s C (Containers, Conectors and Components)
• Exemplos

57
Problemas com Reuso

• Aumento nos custos de manutenção
• Código fonte de componentes não disponíveis
• Falta de ferramentas de apoio
• Falta integração de CASEs com bibliotecas de
  componentes
• Síndrome do não foi inventado aqui
• Manutenção de uma biblioteca de componentes
• Encontrar e adaptar componentes reutilizáveis
• É preciso ser planejado e incorporado por meio de
  um programa de reuso da organização.

58
Referências

• Andrade, R.M.C, Capture, Reuse, and Validation
  of Requirements and Analysis Patterns for Mobile
  Systems, Ph.D. Thesis, University of Ottawa,
  Ottawa, 2001.
• Alexander, C., Ishikawa, S., Silverstein, M.,
  Jacobson, M., Fiksdahl-King, I., and Angel, S., A
  Pattern Language Towns, Buildings, Construction,
  Oxford University Press, New York, NY, 1977.
• Buschmann, F., Meunier, R., Rohnert, H.,
  Sommerlad, P., Stal, M., Pattern-Oriented
  Software Architecture, John Wiley and Sons, New
  York, NY, 1996.
• Coplien, J. O., Software Patterns, SIGS books and
  Multimedia, June 1996.
• Fowler, M., Analysis Patterns Reusable Object
  Models, Addison-Wesley, Reading, MA, 1997.

59
Referências (Cont.)

• Gamma E., Helm R., Johnson R., Vlissides J.,
  Design Patterns Element of Reusable
  Object-Oriented Software, 1995.
• Pattern Languages of Program Design I, II, III
  IV Patterns from the PLoP Conference at Allerton
  Park in Illinois, US and EuroPLoP in Europe
  Addison-Wesley, 1994-95-96-98.
• Rising, Linda, Patterns A Way to Reuse
  Expertise, IEEE Communications Magazine, Vol.
  37, No. 4, April 1999.
• Rising, Linda, The Pattern Almanac 2000, Software
  Pattern Series, Addison-Wesley, 2000. ISBN
  0-201-61567-3.
• Metodologias para o DBC
• Wang A.J.A, Qian K, Component Oriented
  Programming
• UML Components??J. J.Cheesman and J.Daniels
• Catalysis http//www.iconcomp.com/catalysis D.
  D'Souza andA. A. Wills
• KobrA C.Atkinson et al.