Capítulo 7 Conceção e Implementação 1

Transcrição

1 Capítulo 7 Conceção e Implementação Capítulo 7 Conceção e Implementação 1

2 Assuntos abordados Design orientado a objetos com recurso ao UML Padrões de design Questões de implementação Desenvolvimento de código aberto Capítulo 7 Concepção e Implementação 2

3 Design e implementação Design e implementação de software é a fase do processo de engenharia de software em que um sistema de software executável é desenvolvido. Atividades de design e implementação de software são invariavelmente intercaladas. Design de software é uma atividade criativa em que você identifica os componentes de software e suas relações, com base nos requisitos do cliente. A implementação é o processo de realização do projeto como um programa executável. Capítulo 7 Concepção e Implementação 3

4 Construir ou comprar Em vários domínios, é agora possível comprar software que pode ser parameterizado e adaptado às necessidades dos utilizadores. Por exemplo, para se implementar um sistema de registos médicos, pode-se comprar um pacote que já é usado em hospitais. Pode ser mais barato e mais rápido usar essa abordagem em vez de desenvolver um sistema numa linguagem de programação convencional. Quando se desenvolve uma aplicação, o processo de design preocupa-se com a forma de utilizar os recursos de configuração desse sistema para entregar os requisitos do sistema. Capítulo 7 Concepção e Implementação 4

5 Design orientado a objetos com recurso ao UML Capítulo 7 Concepção e Implementação 5

6 Processo de design orientado ao objeto Os processos de design orientado a objetos envolvem o desenvolvimento de vários modelos de sistemas. Exigem um grande esforço para o desenvolvimento e manutenção destes modelos e, para pequenos sistemas, isso pode não ser rentável. No entanto, para grandes sistemas, desenvolvidos por diferentes grupos, modelos de design são um mecanismos importante de comunicação. Capítulo 7 Concepção e Implementação 6

7 Etapas do processo Há uma variedade de diferentes processos de design orientados a objetos. Atividades comuns nestes processos incluem: Definir o contexto e modos de utilização do sistema; Projetar a arquitetura do sistema; Identificar os principais objetos do sistema; Desenvolver modelos de design; Especificar interfaces de objetos. Capítulo 7 Concepção e Implementação 7

8 Contexto do sistema e as interações Compreender as relações entre o software que está a ser projetado e o seu ambiente externo é essencial para decidir como fornecer as funcionalidades necessárias do sistema e como estruturar o sistema para se comunicar com o seu ambiente. Compreensão do contexto permite também estabelecer os limites do sistema. Definir os limites do sistema ajuda a decidir quais os recursos que são implementados no sistema que está a ser desenhado e que recursos estão em outros sistemas associados. Capítulo 7 Concepção e Implementação 8

9 Modelos de contexto e interação Um modelo de contexto do sistema é um modelo estrutural que demonstra os outros sistemas no ambiente do sistema que está a ser desenvolvido. Um modelo de interação é um modelo dinâmico que mostra como o sistema interage com o seu ambiente, como ele é usado. Capítulo 7 Concepção e Implementação 9

10 Sistema contexto para a estação de metereologia Capítulo 7 Concepção e Implementação 10

11 Casos de uso da estação meteorológica Capítulo 7 Concepção e Implementação 11

12 Descrição do caso de uso Weather Report Sistema Caso de uso Atores Descrição Estímulo Resposta Comentários Estação meteorológica Boletim meteorológico Sistema de informação metereológica, Estação meteorológica A estação meteorológica envia um resumo dos dados meteorológicos que foram recolhidos, para o sistema de informações meteorológicas. Os dados enviados são a temperatura, a pressão do ar, a velocidade do vento, a precipitação e a direcção do vento com intervalos de cinco minutos. O sistema de informação metereológica estabelece um link de comunicação via satélite com a estação meteorológica e solicita a transmissão dos dados. Os dados resumidos são enviados para o sistema de informações meteorológicas. Estações meteorológicas são normalmente solicitados a relatar uma vez por hora, mas essa freqüência pode diferir de uma estação para outra e pode ser modificado no futuro. Capítulo 7 Concepção e Implementação 12

13 Projeto arquitetónico Uma vez que as interações entre o sistema e o seu ambiente ter sido compreendido, pode-se usar esta informação para projetar a arquitetura do sistema. Identificar os principais componentes que compõem o sistema e as suas interações, e, em seguida, pode organizar os componentes usando um padrão de arquitetura, tais como um modelo em camadas ou cliente-servidor. A estação meteorológica é composto por subsistemas independentes que se comunicam pela transmissão de mensagens numa infra-estrutura comum. Capítulo 7 Concepção e Implementação 13

14 Arquitetura alto-nível da estação meteorológica Capítulo 7 Concepção e Implementação 14

15 Arquitetura do sistema de recolha de dados Capítulo 7 Concepção e Implementação 15

16 Identificação da classe de objeto Identificar classes de objetos é muitas vezes uma tarefa difícil, parte do projeto orientado a objetos. Não há 'fórmula mágica' para a identificação de objetos. Baseia-se na habilidade, experiência e conhecimento de domínio dos projetistas de sistemas. Identificação de objetos é um processo iterativo. É improvável que se obtenha correto na primeira vez. Capítulo 7 Concepção e Implementação 16

17 Abordagens para a identificação Usar uma abordagem gramatical baseada numa descrição do sistema em linguagem natural. Basear a identificação em coisas tangíveis no domínio do aplicativo. Usar uma abordagem comportamental e identificar objetos com base no que participa o comportamento. Usar uma análise baseada em cenários. Os objetos, atributos e métodos em cada cenário são identificados. Capítulo 7 Concepção e Implementação 17

18 Classes de objeto da estação meteorológica Identificação das classe de objeto no sistema da estação meteorológica, pode ser baseada no hardware tangível e nos dados do sistema: Termómetro, anemómetro, entre outros Objetos de domínio da aplicação que são objetos 'hardware' relacionados com os instrumentos do sistema. Estação meteorológica A interface básica da estação meteorológica com seu ambiente. Reflete as interações identificadas no modelo de caso de uso. Dados meteorológicos Encapsula os dados recolhidos pelos instrumentos. Capítulo 7 Concepção e Implementação 18

19 Modelos de design Modelos de design mostram os objetos, classes de objetos e relações entre estas entidades. Existem dois tipos de modelo de design: Os modelos estruturais descrever a estrutura estática do sistema em termos de classes de objetos e as suas relações. Modelos dinâmicos descrevem as interações dinâmicas entre objetos. Capítulo 7 Concepção e Implementação 20

20 Exemplos de modelos de design Modelos de subsistemas que mostram os agrupamentos lógicos de objetos em subsistemas coerentes. Modelos de sequência que mostram a sequência de interações dos objetos. Modelos de máquina de estado que mostram como objetos individuais mudam o seu estado em resposta a eventos. Outros modelos incluem modelos de caso de uso, modelos de agregação, modelos de generalização, etc. Capítulo 7 Concepção e Implementação 21

21 Modelos de subsistema Mostra como o projeto está organizado em grupos de objetos logicamente relacionados. Em UML, estes são mostrados usando pacotes. Este é um modelo lógico. A organização real dos objetos no sistema podem ser diferentes. Capítulo 7 Concepção e Implementação 22

22 Modelos de sequência Modelos de sequência mostram a sequência de interações dos objetos Os objetos são dispostas horizontalmente na parte superior; O tempo é representado verticalmente para e são lidos de cima para baixo; Interações estão representadas por setas, diferentes estilos de seta representam diferentes tipos de interação; Um retângulo representa o momento em que o objeto é o objeto de controlo no sistema. Capítulo 7 Concepção e Implementação 23

23 Diagram de sequência que descreve a recolha de dados Capítulo 7 Concepção e Implementação 24

24 Diagramas de estado Diagramas de estado são usados para saber como os objetos respondem a diferentes solicitações de serviço e às transições de estado desencadeadas por estas solicitações. Diagramas de estado são modelos de alto nível de um sistema ou o comportamento de tempo de execução de um objeto. Normalmente não precisa de um diagrama de estado para todos os objetos no sistema. Muitos dos objetos num sistema são relativamente simples e um modelo de estado acrescenta detalhes desnecessários ao design. Capítulo 7 Concepção e Implementação 25

25 Diagrama de estados da estação metereológica Capítulo 7 Concepção e Implementação 26

26 Especificação de interface Interfaces de objetos precisam ser especificados para que os objetos e outros componentes possam ser projetados em paralelo. Designers devem evitar projetar a representação da interface, deve-se esconder isso no próprio objeto. Os objetos podem ter diversas interfaces que são pontos de vista sobre os métodos fornecidos. Em UML usa-se o diagrama de classes para a especificação da interface. Capítulo 7 Concepção e Implementação 27

27 Interfaces da estação metereológica Capítulo 7 Concepção e Implementação 28

28 Padrões de design Capítulo 7 Concepção e Implementação 29

29 Padrões de design Um padrão de design é uma maneira de reutilizar o conhecimento abstrato sobre um problema e a sua solução. Um padrão é uma descrição do problema e a essência da sua solução. Deve ser suficientemente abstrato para ser reutilizado em diferentes contextos. Descrições padrão costumam fazer uso de características orientadas a objetos, tais como herança e polimorfismo. Capítulo 7 Concepção e Implementação 30

30 Patterns Padrões e linguagens de padrões são formas de descrever as melhores práticas, bons projetos e experiência de captura de uma forma que é possível para os outros reutilizar essa experiência. Capítulo 7 Concepção e Implementação 31

31 Elementos do padrão teste Nome Um identificador padrão significativo. Descrição do Problema. Descrição da solução. Não é um projeto concreto, mas um modelo para uma solução de design que pode ser instanciado em maneiras diferentes. Consequências Os resultados e as compensações de aplicação do padrão. Capítulo 7 Concepção e Implementação 32

32 O padrão observador Nome Observador. Descrição Separa a exibição de estado do objeto a partir do próprio objeto. Descrição do Problema Usado quando são necessários vários monitores de estado. Descrição da solução Veja slide com descrição UML. Consequências Otimizações para melhorar o desempenho de exibição são impraticáveis. Capítulo 7 Concepção e Implementação 33

33 Vários monitores usando o padrão Observer Capítulo 7 Concepção e Implementação 36

34 Problemas de design Para usar padrões num projeto, precisa-se reconhecer que qualquer problema de design pode ter um padrão associado que pode ser aplicado. Vários objetos que o estado de algum outro objeto foi alterado. Arrumar as interfaces para uma série de objetos relacionados que foram muitas vezes desenvolvidas de forma incrementa. Fornecer uma maneira padrão de acessar os elementos em uma coleção, independentemente de como essa coleção é implementada. Permitir a possibilidade de estender a funcionalidade de uma classe existente no tempo de execução. Capítulo 7 Concepção e Implementação 38

35 Problemas de implementação Capítulo 7 Concepção e Implementação 39

36 Problemas de implementação Foco aqui não é sobre a programação, embora este é, obviamente, importante, mas em outras questões de implementação que muitas vezes não são abordados em programação: Reuso A maioria do software moderno é construído através da reutilização de componentes ou sistemas existentes. Quando se está a desenvolver um software, deve-se fazer o máximo uso possível de código existente. Gestão de configurações Durante o processo de desenvolvimento, tem que se manter a par das muitas versões diferentes de cada componente de software num sistema de gestão de configuração. Desenvolvimento O software de produção não costuma executar no mesmo computador como o ambiente de desenvolvimento de software. Em vez disso, desenvolve-se num computador (o sistema host) e executa-se num computador separado (sistema de destino). Capítulo 7 Concepção e Implementação 40

37 Reuso A partir dos anos 1960 aos anos 1990, a maioria dos novos software foi desenvolvido a partir do zero, escrito todo o código em uma linguagem de programação de alto nível. A única reutilização significativa foi a reutilização de funções e objetos em bibliotecas de linguagem de programação. Custos e pressão de cronograma, significa que esta abordagem tornou-se cada vez mais inviável, especialmente para sistemas comerciais e baseados na Internet. Uma abordagem ao desenvolvimento baseada em torno da reutilização de software existente é geralmente usado para software de negócios e software científico. Capítulo 7 Concepção e Implementação 41

38 Níveis de reutilização O nível de abstração Neste nível, não se reutiliza software diretamente, mas usar o conhecimento de abstrações na concepção do software. O nível do objecto Neste nível, reutiliza-se diretamente objetos de uma biblioteca, em vez de escrever o código. O nível de componente Os componentes são coleções de objetos e classes de objetos que se reutiliza em sistemas de aplicação. O nível de sistema Neste nível, reutiliza-se sistemas de aplicação inteiros. Capítulo 7 Concepção e Implementação 42

39 Reuso de software Capítulo 7 Concepção e Implementação 43

40 Custos de reutilização Os custos do tempo gasto na procura de software para reutilizar e avaliar se é viável ou não às necessidades. Quando aplicável, os custos de aquisição do software reutilizáveis. Para grandes sistemas off-the-shelf, estes custos podem ser muito elevados. Os custos de adaptação e configuração dos componentes ou sistemas de software reutilizáveis para refletir os requisitos do sistema que se está a desenvolver. Os custos de integração de elementos de software reutilizáveis uns com os outros (se estiver s usar software de diferentes fontes) e com o novo código que se desenvolveu. Capítulo 7 Concepção e Implementação 44

41 Gestão de configurações Gestão de configuração é o nome dado ao processo geral de gestão das mudanças de um sistema de software. O objetivo da gestão de configuração é apoiar o processo de integração do sistema de modo a que todos os programadores possam acessar ao código e documentos do projeto de uma forma controlada, descobrir que mudanças foram feitas, e compilar componentes de ligação para criar um sistema. Capítulo 7 Concepção e Implementação 45

42 Atividades de gestão de configuração Gestão de versões, onde se acompanha as diferentes versões de componentes de software. Sistemas de gestão de versões incluem instalações para coordenar o desenvolvimento de vários programadores. Integração de sistemas, onde os programadores a definem as versões de componentes que vão usar para criar cada versão do sistema. Acompanhamento de problemas, onde permite aos utilizadores reportar bugs e outros problemas, para permitir que os programadores os resolvam. Capítulo 7 Concepção e Implementação 46

43 Interação ferramenta de gestão de configuração Capítulo 7 Concepção e Implementação 47

44 Desenvolvimento Host-Target A maioria dos softwares é desenvolvido num computador (host), mas é executado numa máquina separada (o alvo). De modo mais geral, podemos falar de uma plataforma de desenvolvimento e uma plataforma de execução. A plataforma é mais do que apenas hardware. Inclui o sistema operacional instalado além de outros softwares de suporte, como um sistema de gestão de base de dados ou, para plataformas de desenvolvimento, um ambiente de desenvolvimento interativo. Plataforma de desenvolvimento tem geralmente software instalado diferente da plataforma de execução; essas plataformas podem ter diferentes arquiteturas. Capítulo 7 Concepção e Implementação 48

45 Desenvolvimento Host-Target Capítulo 7 Concepção e Implementação 49

46 Ferramentas para a plataforma de desenvolvimento Um compilador integrado e sistema de edição dirigida pela sintaxe que permite criar, editar e compilar o código. Um sistema de linguagem de depuração. Ferramentas de edição de gráficos, como ferramentas para editar modelos UML. Ferramentas de teste, tais como junit que pode executar automaticamente uma série de testes numa nova versão de um programa. Ferramentas de apoio ao projeto que ajudam a organizar o código para diferentes projectos de desenvolvimento. Capítulo 7 Concepção e Implementação 50

47 Ambientes de desenvolvimento integrado (IDEs) Ferramentas de desenvolvimento de software muitas vezes são agrupados para criar um ambiente de desenvolvimento integrado (IDE). Um IDE é um conjunto de ferramentas de software que suporta diferentes aspectos do desenvolvimento de software, dentro de algum quadro comum e interface de utilizador. IDEs são criados para apoiar o desenvolvimento de uma linguagem de programação específica, como Java. Capítulo 7 Concepção e Implementação 51

48 Componentes de implantação do sistema Se um componente é projetado para uma arquitetura de hardware específico, ou se baseia em algum outro sistema de software, deve, obviamente, ser implantado numa plataforma que fornece o suporte de hardware e software necessários. Sistemas de alta disponibilidade podem exigir componentes para ser implantado em mais do que uma plataforma. Isto significa que, em caso de falha da plataforma, uma implementação alternativa do componente está disponível. Se houver um alto nível de tráfego de comunicações entre os componentes, normalmente faz sentido implantá-los na mesma plataforma ou em plataformas que estão fisicamente próximos uma das outras. Isso reduz o atraso entre o tempo que uma mensagem é enviada por um componente e recebida por outra. Capítulo 7 Concepção e Implementação 52

49 Desenvolvimento de código aberto Capítulo 7 Concepção e Implementação 53

50 Desenvolvimento de código aberto Desenvolvimento de código aberto é uma abordagem para o desenvolvimento de software no qual o código fonte de um sistema de software é publicado e os voluntários são convidados a participar no processo de desenvolvimento Suas raízes estão na Free Software Foundation ( Que defende que o código fonte não deve ser proprietário, mas sim deve estar sempre disponível para os utilizadores o examinarem e modificarem como desejarem. Software de código aberto estendeu essa ideia usando a Internet para recrutar uma população muito maior de programadores voluntários. Muitos deles também são utilizadores do código. Capítulo 7 Concepção e Implementação 54

51 Sistemas de código aberto O produto de código aberto mais conhecido é, claro, o sistema operacional Linux, que é amplamente usado como um sistema de servidor e, cada vez mais, como um ambiente desktop. Outros produtos open source importantes são o Java, o servidor web Apache e o mysql Sistema de Gestão de Base de Dados. Capítulo 7 Concepção e Implementação 55

52 Negócios de fonte aberta Mais e mais empresas de produtos estão a usar uma abordagem de código aberto para o desenvolvimento. O seu modelo de negócio não é dependente da venda de um produto de software, mas na venda de suporte para esse produto. Elas acreditam que o envolvimento da comunidade de código aberto irá permitir que o software seja desenvolvido de forma mais barata, mais rápida e vai criar uma comunidade de utilizadores para o software. Capítulo 7 Concepção e Implementação 57

53 Licenciamento de fonte aberta Um princípio fundamental do desenvolvimento de código aberto é que o código fonte deve ser livremente disponíveis, isso não significa que qualquer um pode fazer o que quiserem com esse código. Legalmente, o programador do código (seja uma empresa ou um indivíduo) ainda possui o código. Eles podem colocar restrições em como ele é usado, incluindo condições juridicamente vinculativos em uma licença de software de código aberto. Alguns programadores de código aberto acreditam que, se um componente de código aberto é usado para desenvolver um novo Sistema em seguida, que o sistema também deve ser de código aberto. Outros estão dispostos a permitir que o seu código seja usado sem essa restrição. Os sistemas desenvolvidos podem ser proprietários e vendidos como sistemas de código fechado. Capítulo 7 Concepção e Implementação 58

54 Modelos de licença O GNU General Public License (GPL). Esta é uma chamada de licença 'recíproco' que significa que se usar o software de código aberto que está licenciado sob a licença GPL, então deve fazer esse software fonte aberta. O GNU Lesser General Public License (LGPL) é uma variante da licença GPL, onde se pode escrever componentes que apontam para abrir o código-fonte sem ter que publicar a origem desses componentes. Distribuição Berkley Padrão (BSD) License. Esta é uma licença não recíproca, o que significa que não são obrigados a voltar a publicar quaisquer alterações ou modificações feitas para abrir o código-fonte. Você pode incluir o código em sistemas proprietários que são vendidos. Capítulo 7 Concepção e Implementação 59

55 Gestão de licenças Estabelecer um sistema para manter as informações sobre os componentes de código aberto que são baixados e usados. Estar ciente dos diferentes tipos de licenças e compreender como um componente é licenciado antes de ser usado. Estar ciente dos caminhos de evolução para os componentes. Educar as pessoas sobre código aberto. Têm sistemas de auditoria no local. Participar da comunidade open source. Capítulo 7 Concepção e Implementação 60

56 Pontos chave O processo de concepção orientada para o objecto inclui actividades como conceber a arquitectura do sistema, identificar objectos no sistema, descrever a concepção utilizando diferentes modelos de objecto e documentar as interfaces de componentes. Uma gama de diferentes modelos podem ser produzidos durante um processo de concepção orientada por objectos. Estes incluem modelos estáticos (modelos de classe, modelos de generalização, modelos de associação) e modelos dinâmicos (modelos de sequência, modelos de máquinas de estado). Interfaces de componentes deve ser definido com precisão para que outros objetos possam usá-los. Capítulo 7 Concepção e Implementação 61

57 Pontos chave Ao desenvolver software, deve-se sempre considerar a possibilidade de reutilizar software existente, quer como componentes, serviços ou sistemas completos. Gestão de configuração é o processo de gerir mudanças para um sistema de software em evolução. É essencial quando uma equipa de pessoas estão a cooperar para desenvolver software. A maioria de desenvolvimento de software é o desenvolvimento host-target. Usa-se um IDE em uma máquina host para desenvolver o software, que é transferida para uma máquina de destino para execução. Desenvolvimento de código aberto envolve fazer o código fonte de um sistema acessível ao público. Isso significa que muitas pessoas podem propor alterações e melhorias no software. Capítulo 7 Concepção e Implementação 62