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

Apresentação em tema: "1 Engenharia de Software 2007.1 Projeto com Reuso 31/05/07."— Transcrição da apresentação:

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

2 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 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 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 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 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 7 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 Benefícios do Reuso

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

9 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 10 O que é um Padrão (Cont.) Aplicação Arquitetura Ciência da Computação Engenharia de software Engenharia Mecânica Telecomunicações...

11 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 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 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 14 Diferentes Definições (Cont.) “Um padrão é uma solução provada para um problema em um contexto, ” Comunidade de Software

15 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 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 17 Classificação dos Padrões de Software (Cont.) Requisitos AnáliseProjeto Implementação Padrões de Requisitos Padrões de Análise Padrões de Projeto Meta-Padrões Padrões Arquiteturais Idiomas

18 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 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 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 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 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 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 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 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 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 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 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 29 GoF Design Patterns Creational patterns Abstract factory Builder Factory method Prototype Singleton Behavioral Patterns Chain of Responsibility Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor Structural patterns Adapter Bridge Composite Decorator Facade Flyweight Proxy

30 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 31 Architectural Patterns From Mud to Structure Layers Pipes and Filters Blackboard Adaptable Systems Reflection Microkernel Interactive Systems Model-View- Controller Presentation- Abstraction- Control Distributed Systems Broker Pipes and Filters Microkernel

32 32 Template GoFJ2EECoplienPOSA Nome Classificação Intenção Também Conhecido Como Motivação Aplicabilidade Estrutura Participantes Colaborações Implementação Código Exemplo Consequências Usos Conhecidos Padrões Relacionados Nome Problema Forças Solução - Estrutura - Estratégias Consequências Código Exemplo Padrões Relacionados Nome Contexto Problema Forças Solução Sketch Contexto Resultante Argumentação (Rationale) Nome Também Conhecido Como Exemplo Contexto Problema Solução Estrutura Dinâmica Implementação Exemplo Resolvido Variantes Usos Conhecidos Consequências Veja Também

33 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 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 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 36 Component Dictionary definition A unit of, part of a model Hardware components Software components Differences?

37 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 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 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 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 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 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 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 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 45 Commonality and Difference SP (Structured Programming) OOP (Object-Oriented Programming) COP (Component-Oriented Programming) What are common? What are different?

46 46 SPOOPCOP Divide and conquer for managing complexity break a large problem down into smaller pieces Yes Unification of data and function a software entity combines data and the functions processing those data. improve cohesion Yes Encapsulation The client of a software entity is insulated from how that software entity’s data is stored or how its functions are implemented. Reduce coupling Yes Identity Each software entity has a unique identity Yes Interface represent specification dependency divide a component specification into interfaces restrict inter-component dependency Yes

47 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 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 49 Component Goals If you are asked to name three goals for using component technology, what are they? 1. Conquering complexity 2. Managing change 3. Reuse

50 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 10 18 bytes.” http://www.sims.berkeley.edu/research/projec ts/how-much-info/summary.html http://www.sims.berkeley.edu/research/projec ts/how-much-info/summary.html

51 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 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 53 CBSE Component-Based Software Engineering CBSE = COA + COD + COP + COM Two key activities: Development for reuse Development with reuse

54 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 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 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 3’s C (Containers, Conectors and Components) Exemplos

57 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 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 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 ComponentsJ. J.Cheesman and J.Daniels Catalysis http://www.iconcomp.com/catalysis D. D'Souza andA. A. Willshttp://www.iconcomp.com/catalysis KobrA C.Atkinson et al.