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

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 -> 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 High reuse levels Systematic Domain- specific reuse Broader coverage Architecture reuse Reduced maintenance costs Managed workproducts Blackbox 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éias”que 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. Padrões Arquiteturais Padrões de Requisitos Padrões de Análise Meta-Padrões Idiomas Padrões de Projeto 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 • Decorator • 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 Adaptable Systems Reflection Microkernel • From Mud to Structure • Layers • Pipes and Filters • Blackboard • 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@cs.uiuc.edu • Patterns-request@cs.uiuc.edu • Patterns-discussion-request@cs.uiuc.edu • Padroes-l@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 Szyperski’s 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?

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