VINÍCIUS FERNANDES DE JESUS TÍTULO DO TRABALHO

Transcrição

1 VINÍCIUS FERNANDES DE JESUS TÍTULO DO TRABALHO LONDRINA PR 2013

2

3 VINÍCIUS FERNANDES DE JESUS TÍTULO DO TRABALHO Trabalho de Conclusão de Curso apresentado ao curso de Bacharelado em Ciência da Computação da Universidade Estadual de Londrina para obtenção do título de Bacharel em Ciência da Computação. Orientador: Prof(a). Dr(a). Jandira Guenka Palma Coorientador: Prof(a). Dr(a). Nome do(a) Coorientador(a) LONDRINA PR 2013

4 Vinícius Fernandes de Jesus Título do Trabalho/ Vinícius Fernandes de Jesus. Londrina PR, p. : il. (algumas color.) ; 30 cm. Orientador: Prof(a). Dr(a). Jandira Guenka Palma Universidade Estadual de Londrina, Palavra-chave1. 2. Palavra-chave2. I. Orientador. II. Universidade xxx. III. Faculdade de xxx. IV. Título CDU 02:141:005.7

5 VINÍCIUS FERNANDES DE JESUS TÍTULO DO TRABALHO Trabalho de Conclusão de Curso apresentado ao curso de Bacharelado em Ciência da Computação da Universidade Estadual de Londrina para obtenção do título de Bacharel em Ciência da Computação. BANCA EXAMINADORA Prof(a). Dr(a). Jandira Guenka Palma Universidade Estadual de Londrina Orientador Prof. Dr. Segundo Membro da Banca Universidade/Instituição do Segundo Membro da Banca Prof. Msc. Terceiro Membro da Banca Universidade/Instituição do Terceiro Membro da Banca Londrina PR, 24 de novembrode 2013 LONDRINA PR 2013

6

7 Este trabalho é dedicado às crianças adultas que, quando pequenas, sonharam em se tornar cientistas.

8

9 AGRADECIMENTOS Os agradecimentos principais são direcionados à Gerald Weber, Miguel Frasson, Leslie H. Watter, Bruno Parente Lima, Flávio de Vasconcellos Corrêa, Otavio Real Salvador, Renato Machnievscz 1 e todos aqueles que contribuíram para que a produção de trabalhos acadêmicos conforme as normas ABNT com L A TEX fosse possível. Agradecimentos especiais são direcionados ao Centro de Pesquisa em Arquitetura da Informação 2 da Universidade de Brasília (CPAI), ao grupo de usuários latex-br 3 e aos novos voluntários do grupo abntex2 4 que contribuíram e que ainda contribuirão para a evolução do abntex2. 1 Os nomes dos integrantes do primeiro projeto abntex foram extraídos de org.br/projects/abntex/ e

10

11 Não vos amoldeis às estruturas deste mundo, mas transformai-vos pela renovação da mente, a fim de distinguir qual é a vontade de Deus: o que é bom, o que Lhe é agradável, o que é perfeito. (Bíblia Sagrada, Romanos 12, 2)

12

13 SOBRENOME, N. A.. Título do Trabalho. 44 p. Trabalho de Conclusão de Curso (Graduação). Bacharelado em Ciência da Computação Universidade Estadual de Londrina, RESUMO Palavras-chave: latex. abntex. editoração de texto.

14

15 SOBRENOME, N. A.. Title of the Work. 44 p. Final Project (Undergraduation). Bachelor of Science in Computer Science State University of Londrina, ABSTRACT This is the english abstract. The Abstract in English should be faithful to the Resumo in Portuguese, but not a literal translation. Keywords: latex. abntex. text editoration.

16

17 LISTA DE ILUSTRAÇÕES Figura 1 Processo geral de projeto de software. Figura adaptada de [1]

18

19 LISTA DE TABELAS Tabela 1 Classificação dos padrões

20

21 LISTA DE ABREVIATURAS E SIGLAS GOF SRP OCP LSP ISP DIP MDD UML Gang of Four Single Responsibilty Principle Open Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle Desenvolvimento Dirigido por Modelos Unified Modeling Language

22

23 LISTA DE SÍMBOLOS Γ Λ ζ Letra grega Gama Lambda Letra grega minúscula zeta Pertence

24

25 SUMÁRIO 1 Introdução Fundamentação Teórica Arquitetura de Software Arquiteto de Software Estilos de Arquitetura Arquitetura em camadas Arquitetura de Respositórios Projeto de Arquitetura Decomposição da Arquitetura Princípios do Projeto Orientado a Objetos Single Responsibilty Principle Open-Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle Design Patterns Padrões de Arquitetura Trabalhos relacionados Sommerville Modelo Geral do Processo de Projeto de Software Projeto de Software Orientado a Objetos Proposta Estudo de Caso Conclusão Referências

26

27 25 1 INTRODUÇÃO O processo de construção de um software é uma tarefa difícil, que envolve dedicação e alto custo [2]. Porém, construir um software com uma arquitetura robusta, que agregue manutenibilidade, extensibilidade e escalabilidade para o mesmo, é uma tarefa ainda mais difícil [3], exigindo experiência e um alto conhecimento sobre o assunto [1]. Essa dificuldade tem se elevado, devido ao fato de que os softwares estão cada vez mais complexos e que os clientes necessitam que o sistema esteja pronto o quanto antes. Assim sendo, empresas diminuem o tempo da construção do software, adiantando a entrega do mesmo. [4]. Apesar de diminuir o tempo gasto com a construção do software, um sistema, depois de pronto, ainda possuirá um longo tempo de vida, se tornando um sistema legado [4]. Nesta etapa do ciclo de vida de um software se encontra a manutenção e extensão do mesmo, onde empresas, de um modo geral, concentram um alto investimento [4, 1]. Segundo Sommerville, a etapa de manutenção do software consiste em todas as alterações feitas no mesmo após sua entrega [1]. Essas alterações no sofware sempre serão necessárias, sendo que podemos dizer que essas mudanças podem pertencer a 3 (três) tipos de manutenção: [5, 1] Correção de erros: Correção de erros de escrita de cógido, que são os de menor custo; erros em termos de projeto de software, um pouco mais caro que o tipo anterior; e, com um maior custo em relação aos tipos de erros anteriores, temos os erros de requisitos de sofware. Mudança de ambiente: Manutenção feita para adaptar o sistema para um novo ambiente de software, onde ambiente seria um suporte para execução do sistema, como hardware ou sistema operacional. Mudança de requisito: Mudanças feitas para adaptar novos requisitos devido a alterações na regra de negócio ou de empresas clientes. De um modo geral, empresas concentram a maior parte dos recursos gastos durante o processo de software na etapa de manutenção [6]. Segundo Pressman, é comum a existência de empresas que concentram de 60% até 70% dos rescursos em manutenção de software [5]. Segundo pesquisas recentes, o custo investido na etapa de manutenção é um pouco maior que 60% do custo total do processo de software [7, 8]. Conforme mostrado por Pressman e Sommerville, alguns fatores são apontados como sendo os responsáveis pelo alto custo anteriormente citado [5, 1]:

28 26 Capítulo 1. Introdução Arquitetura de software mal estruturada: Durante o desenvolvimento e a manutenção não há uma devida atenção para a arquitetura do sistema. Código fonte ilegível: Desenvolvedores não se preocupam com a legibilidade do código, tornando difícil a compreensão do mesmo para novos membros da equipe. Falta (ou inexistência) de documentação: Pelo fato de atrasar o desenvolvimento de software, a documentação é deixada de lado. Além disso, há casos em que as documentações são desatualizadas, não condizendo com a implementação. Rotatividade da equipe: De um modo geral, empresas do mercado de TI possuem uma grande rotatividade de desenvolvedores, o que afeta a equipe de desenvolvimento original do sistema.

29 27 2 FUNDAMENTAÇÃO TEÓRICA 2.1 ARQUITETURA DE SOFTWARE Arquitetura de sofware é um termo que não possui um consenso geral em sua definição, tornando difícil sua definição [9]. Apesar dessa falta de consenso, pelas definições de Sommerville [1], Ralph Johnson [9] e Grady Booch [10], podemos interpretar que a arquitetura de um software consiste na estrutura dos componentes do sistema e nas regras de comunicação entre esses componentes [11]. Dessa forma, uma arquitetura de software, quando adequadamente documentada, facilita a compreensão da estrutura de um sistema, evitando a compreensão a partir do código fonte e ajudando nas comunicação com a equipe de desenvolvimento e com clientes [1]. Além disso, a arquitetura de um software nos permite perceber, de forma rápida, decisões na construção do software que influenciam no sucesso de sofware [5]. Assim, o desenvolvimento da arquitetura de um sistema afeta fatores como reuso, manutenibilidade, extensibilidade e escalabilidade [1] Arquiteto de Software Um arquiteto de software é o responsável por criar a arquitetura de um sistema a partir de seus requisitos, possuindo a tarefa de tomar decisões para organizar a estrutura e a interoperação entre os componentes do sistema [5]. O arquiteto de software sempre está preocupado com o andamento do projeto [9], realizando intensas colaborações, seja no auxílio à equipe de desenvolvimento em lógicas de programação, seja no auxílio à coleta de requisitos com especilistas sobre o domínio do problema [12]. Além dessas atividades, o arquiteto de software também possui a responsabilidade de ser o mentor da equipe de desenvolvimento, tornando-a capaz de tomar decisões importantes relacionadas com a arquitetura do sistema [9] Estilos de Arquitetura Estilos de arquitura de software são maneiras de se estruturar um software [1]. De um modo geral, todo software possui algum tipo de estilo de arquitura. Esses estilos de arquitetura de software são como estilos de arquitetura na construção civil. Com um estilo de arquitetura definido, um arquiteto civil consegue facilmente

30 28 Capítulo 2. Fundamentação Teórica identificar a estrutura geral de uma construção, mas não pode prever nada detalhado sobre ela [5]. Desta forma, o estilo de arquitetura de um software fornece informações superficiais sobre como o software é organizado. Os estilos de arquitetura servem como um template para projetar um software. Desta forma, esses estilos funcionam como uma estrutura guia para detalhar os componentes e módulos do software [5]. Há vários tipos de estilos de arquitetura de software, como arquitetura em camadas, piper and filter, modelo de repositórios, arquitetura cliente-servidor, arquitetura orientada a objetos, entre outros [1, 5]. Cada estilo de arquitetura possui uma maneira de organizar o sistema e uma característica que representa quando devemos utilizá-lo. Essas características, de uma maneira geral, são extraídas dos requisitos não funcionais do software [5]. Vale ressaltar que esses estilos de arquitetura não são mutuamente exclusivos. A seguir descrevemos dois estilos de arquitetura Arquitetura em camadas Nesse estilo de arquitetura o sistema é separado em camadas, onde cada camada possui uma funcionalidade bem definida e independente das outras camadas [5]. As camadas se comunicam entre sí através de uma interface de comunicação bem definida. De um modo geral, uma camada fornece serviços para sua camada superior e utiliza serviços de sua camada inferior. Porém, há casos em que camadas não adjacentes comunicam diretamente entre sí, para que não haja muita demora na comunicação entre elas [13]. Uma vantagem desse estilo de arquitetura é que podemos facilmente construir um software multiplataforma. Isso se dá pelo fato de que conseguimos substituir a implementação de uma camada sem afetar nenhuma outra camada. Além disso, também há a facilidade em adicionar novas camadas ao sistema [5]. Uma dificuldade enfrentada ao se utilizar o estilo em questão é que a separação lógica das camadas não é muito evidente e isso pode ser um problema para a qualidade do software [1]. Como exemplo desse estilo de arquitetura considere o padrão de arquitetura MVC (Model View Controller) [2, 1] e também o modelo de redes OSI (Open Systems Interconnection) [13, 14].

31 2.2. Decomposição da Arquitetura Arquitetura de Respositórios O estilo de arquitetura de repositórios é um estilo em que o software é dividido em vários componentes e esses componentes se comunicam através de dados compartilhados em um repositório central (por exemplo banco de dados) [13]. Desta forma, cada componente do sistema realiza uma leitura e/ou escrita nesse repositório central, respeitando a estrutura em que os dados são compartilhados [5]. Uma vantagem desses estilo é que podemos adicionar, remover ou modificar um componente sem realizar nenhuma alteração nos outros componentes [1]. Porém, uma desvantagem desse estilo é que todos os componentes dependem do repositório central. Sendo assim, qualquer erro que ocorra no repositório afetará os outros componentes [1]. O modelo de arquitetura blackboard é um exemplo de uma aplicação do estilo em questão, conforme ilustrado por Shaw e Garlan [13] Projeto de Arquitetura Neste trabalho, o projeto de arquitetura é considerado a atividade de definir a estrutura geral sistema, como estilo que será utilizado, quais componentes terão no sistema, entre outras. 2.2 DECOMPOSIÇÃO DA ARQUITETURA A decomposição da arquitetura de software consiste em projetar os componentes do sistema, elaborando sua estrutura e interface de comunicação. De forma contrária ao projeto de arquitetura de software, essa decomposição também aborda mais detalhes do projeto do software. Neste trabalho, a forma de decomposição abordada se limita ao paradigma orientado a objetos. A mesma é feita através do uso de princípios e técnicas do projeto orientado a objetos. Desta forma, entende-se como pré-requisito deste trabalho o conhecimento de conceitos basicos do paradigma em questão, como classes, objetos, herança, polimorfismo, interfaces e composição Princípios do Projeto Orientado a Objetos A seguir, alguns princípios de projeto orientado a objetos serão passados. Esses princípios são utilizados no momento em que se inicia a criação de classes e objetos. Tais princípios são aplicações de importantes fundamentos da orientação a objetos e por isso seguí-los agrega qualidade ao projeto do componente.

32 30 Capítulo 2. Fundamentação Teórica Primeiramente, definimos os princípios SOLID, que foram compilados e apresentados por Robert Cecil Martin [15] Single Responsibilty Principle Este princípio, que foi primeiramente descrito por Tom DeMacro [16] e Meilir Page-Jones [17] com o nome de coesão, afirma que uma classe deve possuir uma única responsabilidade, onde uma responsabilidade seria uma possibilidade de mudança [15]. Quando uma classe possui mais de uma responsabilidade, ela automaticamente possui mais de uma razão para sofrer alteração. Assim, mudanças em uma responsabilidade poderá afetar outra responsabilidade distinta. Com isso, uma alteração poderá afetar o sistema sem persepção alguma [15] Open-Closed Principle Introduzido por Bertrand Meyer, este princípio diz que o módulo de um software deve estar aberto para extensão e fechado para modificação [18]. O termo aberto para extensão significa que o comportamento do módulo pode ser expandido. Por exemplo, em um módulo de tradução de texto entre línguas naturais, uma extensão seria adicionar a tradução para uma nova língua (Português, Inglês, etc) [15]. Já o termo fechado para modificação refere-se à não modificação a base do módulo, matendo intacto o que já foi construído até o momento [18]. Em outras palavras, esse princípio denota que para realizar a expanção de um módulo não devemos modificar o seu estado atual, basta adicionar um novo comportamento que respeite as características desse módulo. A importância desse princípio se dá pela constante mudança sofrida pelo software durante o seu ciclo de vida [15]. Respeitar o princípio em questão permite que essas mudanças sejam feitas facilmente Liskov Substitution Principle Diretamente relacionado às propriedades de orientação a objetos herança e polimorfismo, o princípio em questão herda o nome de sua criadora, Barbara Liskov [19]. Para entender este princípio, considere as classes A e B, onde a classe B herda da classe A. Agora considere o programa P que possui uma referência para o objeto o1 do tipo A e que faz uma chamada ao método m de o1. Segundo o princípio de Liskov, substituir o tipo do objeto o1 para o tipo B não irá modificar o comportamento do programa [19].

33 2.2. Decomposição da Arquitetura 31 Ao violar este princípio, um programa, ao ser extendido, passará por modificações. Essas modificações deixam o mesmo instável e dificultam sua manutenção. Além disso, o princípio Open Closed também será violado [15]. Em sua essência, este princípio quer dizer que uma subclasse deve respeitar as definições estabelecidas por sua classe pai. Sempre vale lembrar que uma classe herda propriedades e comportamento de outra classe. Embora isso pareça trivial, sua violação é muito comum [15] Interface Segregation Principle Associado com o projeto de interfaces de um sistema, esse princípio diz que o cliente de uma interface não pode depender de métodos que ele não faz uso [15]. Em termos de projeto, isso quer dizer que uma interface não deve ser poluída, ou seja, ela deve possuir um pequeno conjunto de funcionalidades [15]. Violar esse princípio pode aumentar o acoplamento de um software, já que funcionalidades destintas se encontram no mesmo lugar e logo existe uma dependência entre elas [15] Dependency Inversion Principle Este princípio, muito utilizado na construção de frameworks [20], diz que um módulo não pode depender de um outro módulo, ambos devem depender de abstrações. Além disso, detalhes devem depender de abstrações, nunca o contrário [15]. O fato de depender de uma abstração torna o módulo mais fácil de se extender, já que basta trocarmos o detalhe (implementação) que respeita essa abstração. Além do mais, depender de abstrações diminui o acoplamento do software [15]. Esse princípio pode ser aplicado sempre que há alguma comunicação entre classes. Para aplicá-lo, Robert C. Martin utiliza algumas heurísticas [15]: Nenhuma variável de uma classe deve ter referência para uma classe concreta. Nenhuma classe deve ser subclasse de uma classe concreta. Nenhum método deve sobrescrever um método implementado pela classe pai. O princípio em questão se assemelha ao princípio utilizado pelo GOF na construção de design patterns (veja 2.2.2), que diz o seguinte Programe para uma interface, não para uma implementação [3].

34 32 Capítulo 2. Fundamentação Teórica Design Patterns Design patterns (padrões de projeto no português) são soluções tradicionais para problemas recorrentes no projeto de software [1]. Essas soluções são genéricas e buscam fazer o melhor uso de princípios e conceitos de orientação a objetos e geralmente fornecem reuso, flexibilidade e baixo acoplamento [3]. Sua origem vem da arquitetura civil, quando o arquiteto civil Christopher Alexander escreveu o livro A Pattern Language que fala sobre os padrões de projeto da construção civil [21, 5]. Foi neste livro que Ralph Johnson, John Vlissides, Richard Helm e Erich Gamma, conhecidos como Gang of Four (GOF), se basearam para popularizar os padrões de projeto de software, em meados da década de 90 [3]. Um benefício do uso de design patterns é que equipes de desenvolvimento de software, ao encararem algum problema no projeto de um sistema, podem reutilizar soluções existentes e então poupar tempo na construção do sistema [2]. Padrões de projeto podem ser aplicados para qualquer linguagem de programação orientada a objetos. Além disso, o uso de padrões de projeto permite que o desenvolvedor explique uma determinada solução apenas citando o nome do padrão utilizado [3]. Apesar de não ser regra, em geral um padrão possui quatro elementos [3]: Nome: Uma palavra ou duas que descreve o problema, a solução e a consequência de um padrão. O uso de nome em padrões de projeto aumenta o vocabulário de projeto de software e possibilita uma fácil referência aos padrões, podendo ser utilizado em conversas de equipe e documentações. Problema: Informa quando o padrão deve ser aplicado. Em geral, descreve o problema de projeto e seu contexto. Solução: Representa os elementos do projeto (classes, interfaces e objetos), as responsabilidades de cada um e o relacionamento entre eles. Consequências: São os resultados da aplicação do padrão de projeto. Esses resultados geralmente são dados em relação a espaço utilizado, tempo de resposta, flexibilidade, extensibilidade e portabilidade. A análise desses resultados ajuda a ponderar na escolha entre alternativas de padrões de projeto. Os padrões de projeto apresentados pelo GOF são classificados através de dois critérios [3]. O primeiro critério diz a respeito do propósito do padrão. Cada padrão pode ter um dos três propósitos: Criacional: Quando o padrão está relacionado com a criação de objetos.

35 2.3. Trabalhos relacionados 33 Propósito Escopo Criacional Estrutural Comportametal Classe Factory Method Adapter Interpreter Template Method Abstract Factory Adapter Chain of Responsibility Builder Bridge Command Prototype Composite Iterator Objeto Singleton Decorator Mediator Facade Memento Flyweight Observer Proxy State Strategy Visitor Tabela 1 Classificação dos padrões Estrutural: Padrão que se refere a composição de classe e objetos. Comportamental: Aborda os padrões que se referem a comunição entre objetos e classes. O segundo critério de classificação é o escopo do padrão, que pode ser dois valores: Classe: Quando o padrão se refere a relação entre classes e subclasses, conhecido como herença. Objeto: Tipo de padrão que se refere a relação entre objetos, ou seja, se diz respeito a composição dos mesmos. A lista dos padrões do GOF e sua classificação é exibida na tabela Padrões de Arquitetura Assim como no projeto de software, a ideia de padrões pode ser aplicada para o projeto de arquitetura 2.1.3, com uso de padrões de arquitetura. Padrões de arquitetura são soluções para problemas no projeto de arquitetura, tendo uma característica mais geral do que padrões de projeto [2]. Em geral, esse padrões ajudam a estruturar a arquitetura do sistema, auxiliam a construir o estilo de arquitetura do sistema [1, 5]. 2.3 TRABALHOS RELACIONADOS Nesta seção, uma lista de trabalhos relacionados ao processo de contrução da arquitetura de software serão apresentados.

36 34 Capítulo 2. Fundamentação Teórica Sommerville Nesta subseção serão apresentadas ideias sobre o processo do projeto de um software, que consiste desde a construção do estilo de arquitetura do software até a decomposição de seus módulos, segundo o autor Sommerville [1]. Primeiramente será explicado um modelo geral do processo de projeto de software, exibido pelo autor. Em seguida, será mostrado um conjunto das atividades mais importantes no processo de projeto de software utilizando orientação a objetos Modelo Geral do Processo de Projeto de Software O autor exibe um processo geral para se projetar um software, ilustrado pela figura 1. Note que esse processo é independente do tipo de processo de software utilizado. Figura 1 Processo geral de projeto de software. Figura adaptada de [1] Primeiramente, temos as entradas das atividades do projeto de software, fomentadas pela coleta dos requisitos. Essas entradas são descritas da seguinte forma: Informações sobre a plataforma: Informações sobre o ambiente em que o software vai ser executado. Esse ambiente é composto por softwares que interagem com o sistema, como banco de dados e sistemas operacionais.

37 2.3. Trabalhos relacionados 35 Especificação dos requisitos: São especificações sobre o que o software deve fazer. Descrição dos dados: Descrições sobre os dados utilizados no sistema, como por exemplo dados cadastrais. O autor descreve quatro atividades dentro do projeto de software, sendo projeto de arquitetura, projeto da interface, projeto dos componentes e projeto do banco de dados. O projeto de arquitetura é o momento de definição da estrutura geral do sistema (estilos de arquitetura 2.1.2), dos principais componentes e de seus relacionamentos. A segunda atividade, projeto de interface, consiste em definir a interface de comunicação utilizada pelos componentes. Respeitar essa interface de comunicação permite que o projeto de cada componente seja feito de maneira independente. A terceira atividade consiste em elaborar cada componente do sistema, de forma a projetar como o componente irá operar. Esse projeto pode ser a construção de um novo componente ou a adaptação de um componente existente. A última atividade, projeto do banco de dados, consiste em projetar a estrutura de dados do sistema e como essas estruturas serão representadas no banco de dados. Conforme ilustrado, essas quatro atividades produzem algumas saídas da etapa de projeto. A estrutura de cada saída varia de forma considerável. Segundo Sommerville, essas saídas podem ser representadas com um conjunto de diagramas, caso a abordagem do MDD (Desenvolvimento Dirigido por Modelos) for utilizada. No caso do uso de métodos ágeis, essas saídas podem ser representadas dentro do código Projeto de Software Orientado a Objetos De uma forma geral, um processo de projeto de software orientado a objetos possui algumas importantes atividades, sendo elas: Contexto do sistema e interações: Essa atividade consiste em compreender a relação do software que está sendo projetado com o seu ambiente externo. Isso ajuda a estruturar a maneira como o software vai interagir com outros sistema e quais funcionalidades ele ficará responsável. Projeto da arquitetura: É nesta atividade que a arquitetura do sistema será definida, identificando os principais componentes do sistema e o relacionamento entre eles. Para defini-la, são utilizados conceitos sobre o domínio do problema (coletados na etapa anterior) e conceitos sobre arquitetura de software, como estilos de arquitetura (2.1.2) e padrões de arquitetura ( ). Identificar objetos do sistema: Consiste em reconher as principais classes de objetos do sistema, através das informações sobre o sistema. Ao analisar informações como

38 36 Capítulo 2. Fundamentação Teórica funcionalidade e propriedade de um módulo ideias são formadas sobre possíveis objetos do sistema. Projetar modelos: Consiste em criar modelos, como diagramas UML, que representam partes do projeto de sistema, como a estrutura dos componentes, o fluxo de interação entre os objetos e os estados dos objetos. Especificar interfaces: Consiste em especificar a interface de comunicação entre os componentes. Essa interface tem que ser bem projetada, pois futuras mudanças podem causar um grande retrabalho. Essas atividades são dependentes uma das outras e variam a forma de execução de acordo com o sistema que será projetado.

39 37 3 PROPOSTA Escrita não iniciada.

40

41 39 4 ESTUDO DE CASO Escrita não iniciada.

42

43 41 CONCLUSÃO Sed consequat tellus et tortor. Ut tempor laoreet quam. Nullam id wisi a libero tristique semper. Nullam nisl massa, rutrum ut, egestas semper, mollis id, leo. Nulla ac massa eu risus blandit mattis. Mauris ut nunc. In hac habitasse platea dictumst. Aliquam eget tortor. Quisque dapibus pede in erat. Nunc enim. In dui nulla, commodo at, consectetuer nec, malesuada nec, elit. Aliquam ornare tellus eu urna. Sed nec metus. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Phasellus id magna. Duis malesuada interdum arcu. Integer metus. Morbi pulvinar pellentesque mi. Suspendisse sed est eu magna molestie egestas. Quisque mi lorem, pulvinar eget, egestas quis, luctus at, ante. Proin auctor vehicula purus. Fusce ac nisl aliquam ante hendrerit pellentesque. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos hymenaeos. Morbi wisi. Etiam arcu mauris, facilisis sed, eleifend non, nonummy ut, pede. Cras ut lacus tempor metus mollis placerat. Vivamus eu tortor vel metus interdum malesuada. Sed eleifend, eros sit amet faucibus elementum, urna sapien consectetuer mauris, quis egestas leo justo non risus. Morbi non felis ac libero vulputate fringilla. Mauris libero eros, lacinia non, sodales quis, dapibus porttitor, pede. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos hymenaeos. Morbi dapibus mauris condimentum nulla. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Etiam sit amet erat. Nulla varius. Etiam tincidunt dui vitae turpis. Donec leo. Morbi vulputate convallis est. Integer aliquet. Pellentesque aliquet sodales urna.

44

45 43 REFERÊNCIAS 1 SOMMERVILLE, I. Software engineering. Boston: Pearson, ISBN FOWLER, M. Patterns of Enterprise Application Architecture. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., ISBN GAMMA, E. et al. Design patterns: elements of reusable object-oriented software. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., ISBN CHANG, C.-H.; LU, C.-W.; HSIUNG, P.-A. Pattern-based framework for modularized software development and evolution robustness. Information and Software Technology, v. 53, n. 4, p , ISSN PRESSMAN, R. Software engineering : a practitioner s approach. New York: McGraw-Hill Higher Education, ISBN TIAKO, P. Maintenance in joint software development. In: Computer Software and Applications Conference, COMPSAC Proceedings. 26th Annual International. [S.l.: s.n.], p ISSN REN, Y. et al. Research on software maintenance cost of influence factor analysis and estimation method. In: Intelligent Systems and Applications (ISA), rd International Workshop on. [S.l.: s.n.], p SU, C.-T.; YEH, D. Software architecture recovery and re-documentation tool of a hospital information system. In: Computer and Communication Engineering (ICCCE), 2012 International Conference on. [S.l.: s.n.], p FOWLER, M. Design - who needs an architect? Software, IEEE, v. 20, n. 5, p , ISSN BOOCH, G. Object-oriented analysis and design with applications. Upper Saddle River, NJ: Addison-Wesley, ISBN VALIPOUR, M. et al. A brief survey of software architecture concepts and service oriented architecture. In: Computer Science and Information Technology, ICCSIT nd IEEE International Conference on. [S.l.: s.n.], p BOOCH, G. The professional architect. Software, IEEE, v. 29, n. 1, p , ISSN GARLAN, D.; SHAW, M. An Introduction to Software Architecture. Pittsburgh, PA, USA, TANENBAUM, A. S.; WETHERALL, D. J. Computer Networks (5th Edition). [S.l.]: Prentice Hall, ISBN MARTIN, R. C. Agile Software Development, Principles, Patterns, and Practices. [S.l.]: Prentice Hall, ISBN