Visão Geral Parte 2. Jair C Leite DIMAp/UFRN

Transcrição

1 Visão Geral Parte 2 Jair C Leite DIMAp/UFRN Requisitos Objetivos ou restrições estabelecidas por clientes e usuários do sistema que definem as diversas propriedades do sistema Condição ou capacidade necessária que o software deve possuir para que o usuário possa resolver um problema ou atingir um objetivo para atender as necessidades ou restrições da organização ou de outros componentes do sistema.

2 Problemas comuns Os envolvidos* não sabem o que eles realmente querem. Se expressam num vocabulário diferente dos desenvolvedores. Os envolvidos podem ter requisitos conflitantes. Fatores organizacionais e políticos podem influenciar os requisitos. Novos requisitos podem surgir durante o processo de levantamento/análise/especificação. Novos envolvidos podem vir a participar do processo. Podem haver mudanças externas ambiente ou regras de negócios. *Stakeholders: Envolvidos ou partes interessadas Como descrever os requisitos? A especificação dos requisitos deve ser: Completa deve descrever tudo o que é necessário Consistente não deve haver conflitos e contradições Não-ambígua não deve levar a interpretações diferentes por desenvolvedores e usuários. Difícil de atingir considerando que existem diferentes tipos de envolvidos. Depende da precisão da linguagem utilizada Linguagem natural, informal apropriada para os requisitos do usuário e do sistema. Linguagens gráficas, semi-formais apropriada para os requisitos do sistema e do software. Linguagens formais apropriada para uma especificação formal de software em métodos formais.

3 Requisitos funcionais Descrição das diversas funções que clientes e usuários querem ou precisam que o software ofereça Casos de Uso Exemplos: "o software deve possibilitar o cálculo dos gastos diários, semanais, mensais e anuais com pessoal". "o software deve emitir relatórios de compras a cada quinze dias" "os usuários devem poder obter o número de aprovações, reprovações e trancamentos em todas as disciplinas por um determinado período de tempo. Requisitos não-funcionais Propriedades de um software, como manutenibilidade, usabilidade, desempenho, custos e várias outras São exemplos de requisitos não-funcionais: "a base de dados deve ser protegida para acesso apenas de usuários autorizados". "o tempo de resposta do sistema não deve ultrapassar 30 segundo". "o software deve ser operacionalizado no sistema Linux" "o tempo de desenvolvimento não deve ultrapassar seis meses".

4 Tipos de requisitos não-funcionais Engenharia de Requisitos 1/2 Requisitos mudam sempre! Requisitos precisam ser levantados, analisados, especificados, rastreados, verificados e documentados. Estas atividades ocorrem ao longo de todo o ciclo-de-vida do software. A Engenharia de Requisitos propõe modelos, métodos, técnicas e ferramentas para a realização destas atividades

5 O processo de engenharia de requisitos Fonte: Ian Sommerville O processo de levantamento-análiseespecificação-validação.

6 Arquitetura de Software A arquitetura de um software é uma estrutura de componentes interconectados através de interfaces Componentes são compostos de componentes menores e interfaces A interação entre componentes ocorre através de suas interfaces O que é Arquitetura de Software? O que é arquitetura de software? É uma descrição em alto nível de abstração que permite uma visão completa do sistema. A arquitetura deve dar suporte à funcionalidade do sistema. Desta forma, o comportamento dinâmico do sistema deve ser levado em conta. A arquitetura deve está em conformidade com a qualidade (requisitos não-funcionais). No nível arquitetural, todos os detalhes de implementação devem ser escondidos. O que não é arquitetura de software? Design detalhado (baixo-nível) design de componentes internos, modelos de dados e implementação Arquitetura do sistema físico elementos processadores, topologia de rede, arquitetura de elementos de hardware, etc. Arquitetura de software está relacionada com estes últimos no que se chama de Arquitetura do Sistema. Fonte: Bredemeyer Consulting

7 Histórico Visão tradicional Conceito de Sub-sistema e Módulos Arquitetura nos Métodos Estruturados Arquitetura nos Métodos Orientados-a-Objetos Visão atual Disciplina emergente [Shaw e Garlan] Estilo arquiteturais Padrões de Design e Frameworks Visões Arquiteturais Linguagens de Descrição Arquitetural (ADL) Desenvolvimento Baseado em Componentes Arquitetura nos métodos estruturados A arquitetura básica é hierárquica: um programa principal decomposto em várias subrotinas ou funções Sub-rotinas podem ser agrupadas em módulos Forma de Interação: Chamada-de-função e passagem de parâmetros Conceitos: Sub-rotinas Fan-in e Fan-out: mede o grau de dependência entre as subrotinas. Coesão e Acoplamento: uma boa arquitetura deve ter alta coesão e baixo acoplamento módulos Fan-in Fan-out Baixa coesão Alta coesão Alto acoplamento Baixo acoplamento

8 Arquitetura de Software nos Métodos Orientados-a-Objetos Objetivos Agrupamento de dados e funções num único componente Visão abstrata em termos de classes/objetos e troca de mensagens Princípios: Independência Conceitual Encapsulamento Técnicas Identificação de objetos Especialização de objetos (Herança) Padrões de Projetos (Design Patterns) Representação UML: diagramas de classes, de seqüência, de colaboração e de estados Exemplo Sistema estação meteorológica subsistemas e módulos Fonte: Ian Sommerville, 2000

9 Exemplo Sistema estação meteorológica classes de um módulo Fonte: Ian Sommerville, 2000 Arquitetura nos métodos OO (UML)... Panel Applet java applet HelloWorld paint() Graphics awt lang Diagrama de Classes Pacotes

10 Arquitetura de Software visão emergente Objetivos Visão abstrata do software através de componentes e interfaces Independência de plataforma Independência de paradigma de programação Técnicas Estilos Arquiteturais Padrões de projetos (Design Patterns) Frameworks Representação Linguagens de Descrição Arquitetural Estilos Arquiteturais Identificados em diversas aplicações de sucesso Modelo em camadas OSI/ISO para redes Notificador em Sistemas de Janelas Pipes em Sistemas Unix Não são modelos, são conjunto de características comuns Mais de um estilo pode ser utilizado em uma mesma aplicação Semelhanças com a idéia de Patterns

11 Tubos e filtros (pipe-and-filter) Um Filtro é um componente que processa o fluxo de dados de sua entrada e gera um fluxo de saída para um outro filtro Fluxo de dados vai de um Filtro para o outro através de Tubos Facilmente implementado no Unix Scan Parse GenCode Outro exemplo abrindo uma imagem compactada e criptografada req req req Application Decompression OS P P Decryption P File- System Camadas Elementos da camada superior utiliza serviços oferecidos na interface (API) da camada inferior Um elemento da camada inferior não utiliza serviços da camada superior Uma camada pode ser modificada desde que mantenha a sua interface Aplicações: Sistemas de Janelas; Redes de Computadores

12 Visões arquiteturais (Hofmeister, 2000) Visão conceitual

13 Visão de módulos Visão de execução

14 Visão de execução Relação com o hardware Visão de codificação Organização do fonte

15 Visão de codificação As 3 Visões Componentee-conector (C&C) Decomposição Módulo Classes Processo Concorrência Clienteservidor Dados compartilhados Alocação Utilização Camadas Atribuição de trabalho Implantação Implementação

16 As 4+1 visões P. Krutchen Visão lógica Stakeholders Funcionalidade Diagramas: Classes, Seqüência, Colaboração Integradores Desempenho Escalabilidade Diagramas: Atividades, Objetos Seqüência, Colaboração Visão de processos Visão de Casos de Uso Visão de implementação Programadores Gerenciamento de configuração Diagramas: Pacotes, componentes Engenheiros de Sistema Topologia do Sistema Comunicação Diagramas: Implantação Visão de implantação Preenchimento iterativos das visões 1/2 No RUP, o design arquitetural está espalhado nas várias iterações na fase de elaboração. As 4 visões vão sendo elaboradas de forma iterativa, dirigidas a partir dos casos de usos e requisitos nãofuncionais. Fonte:C. Hofmeister et al. / The Journal of Systems and Software 80 (2007)

17 Preenchimento iterativos das visões 2/2 O processo sugere a elaboração de cenários a partir de requisitos (casos de uso) de negócio e de sistema. Com base nos cenários são elaborados diagramas de seqüência e colaboração. Em seguida os diagramas de classes (ainda visão lógica) a partir das quais pode-se código fonte organizados em módulos e sub-sistemas. A visão de processo permite ver a execução de processos concorrentes e como eles estão alocados nos nós processadores do sistema (visão de implantação). Padrões Padrões são soluções para problemas específicos que ocorrem de forma recorrente em um determinado contexto que foram identificados a partir da experiência coletiva de desenvolvedores de software. A proposta original de padrões veio do trabalho de Christopher Alexander na área de arquitetura. Sua definição para padrões: Cada padrão é uma regra (esquema) de três partes que expressa uma relação entre um certo contexto, um problema, e uma solução.

18 Contexto, Problema, Solução e Forças O contexto descreve uma situação no desenvolvimento na qual existe um problema. O problema que ocorre repetidamente no contexto deve também ser descrito bem como as forças (requisitos, restrições e propriedades) associadas a ele. A solução descreve uma configuração ou estrutura de componentes e suas interconexões, obedecendo às forças do problema. As forças, denominação dada por Alexander, descrevem os requisitos que caracterizam o problema e que a solução deve satisfazer, as restrições que devem ser aplicadas às soluções e propriedades desejáveis que a solução deve ter. Padrão Proxy - idéia O Padrão Proxy permite que clientes de um serviço utilizem um representante do componente que oferece o serviço. Aumenta a eficiência, a segurança e facilita o acesso. O Proxy pode substituir o servidor quando ocorrem problemas com o servidor. O Proxy permite criar uma independência de endereçamento e implementação do servidor.

19 O Padrão Proxy Contexto: Um cliente precisa acessar um serviço de um outro componente em um sistema distribuído. O acesso direto é tecnicamente possível, mas pode não ser a melhor opção. Problemas: O acesso direto pode não ser eficiente em tempo de execução, ter alto custo e não ser seguro. O cliente não precisa ficar dependente de endereço de rede do componente. Solução: Utilize um representante do cliente que ofereça o serviço de forma idêntica e realize pré- e pós-processamento adicionais para garantir a Qualidade do Serviço. : Client service : Proxy : Service pre-processing Client AbstractService service service post-processing Proxy 1 1 service Service service Verificação e Validação (V & V) Objetivo: assegurar que o software que o software cumpra as suas especificações e atenda às necessidades dos usuários e clientes. Verificação: Estamos construindo certo o produto? O software deve está de acordo com a sua especificação. Validação: Estamos construindo o produto certo? O software deve atender às necessidades dos usuários. Ocorrem em todo o ciclo de vida completo Revisões de requisitos, revisões de design, testes de código

20 Técnicas de V & V (Sommerville) Inspeções de software (V & V estática) Análise da documentação e código fonte do software Pode ser auxiliado por ferramentas de depuração Testes de software (V & V dinâmica) O programa ou um protótipo devem ser executados Casos de testes deve ser elaborados: dados de entrada e comportamento esperado. Fonte: Ian Sommerville, 2000 Inspeções de Software Características Técnica preventiva permite a V & V antes do software ser codificado Mais barata Baseada na experiência do inspetor Mais aplicada a fatores de revisão e transição Pouco eficaz para fatores operacionais Aplicações mais comuns Inspeção de programa fonte (estática e dinâmica) Inspeção de documentos e modelos Desenvolvimento Cleanroom

21 Testes de integração incremental Teste de integração Top-down Começa pelos componentes de alto nível e vai descendo na hieraquia de componentes, de acordo com a arquitetura do software. Os sub-componentes são representados por stubs. Stubs tem a mesma interface, mas não precisa ter funcionalidade. Basta retornar valores esperados.

22 Prova Formal de Programas Utilizada em métodos formais Linguagens de programação são definidas formalmente (sintaxe e semântica formal) Linguagens de especificação formais também Pode-se provar matematicamente que um programa está correto em relação à especificação formal {x=5} x := x + 1; {x=6} Especificação: condição inicial Especificação: condição final Testes de software Elaboração de casos de testes baseados na especificação funcional Dados de entradas Comportamento esperado Podem ser classificados Quanto ao escopo Quanto ao método Aplicações em fatores operacionais Correção Usabilidade Desempenho Robustez

23 Testes de correção Revelam a presença de erros, mas NÃO a ausência Um teste bem sucedido é aquele que descobre o maior número de erros existentes. Deve ser utilizado em conjunto com técnicas de inspeção O teste deve identificar o erro A inspeção analítica (rastreamento ou depuração) deve localizar e corrigir o erro O problema da geração de casos de testes Testes exaustivos são impraticáveis. Escolher bons casos de testes (dados de entrada e comportamento esperado) é fundamental para que um teste seja bem sucedido, isto é, detecte os erros existentes. Exemplo: Considere um programa (ou trecho de programa) que deve determinar o maior entre dois números inteiros: MAX(x,y) O conjunto de casos testes exaustivos é infinito. Um possível conjunto de casos de testes poderia ser: { (1,0)->1; (-2,-5)->-2; (9,3)->9; (34,25)->34; (0,-1)->0; (1,1)->1; (100,99)->100; (-45,-11)->-45; } Inspecione o código deste programa ao lado: Aplicando-se os casos de testes acima, conclui-se que o programa não tem erros. No entanto, bastariam apenas três casos de testes para concluir-se que o programa tem erros. Como determinar estes casos? read(x,y); If (x>y) then max:=x; else max:=x; print(max);

24 Testes caixa-preta São chamados testes funcionais. O programa é uma caixa preta cujo comportamento é determinado estudando-se as suas entradas e saídas. Os casos de testes são derivados da especificação funcional. A escolha dos dados de entrada podem ser feitas com várias técnicas: Partição de domínio Grafos de causa-efeito Teste caixa-branca Analisa a estrutura do programa para determinar os casos de teste Exemplo: teste do caminho básico Visa determinar um conjunto de casos de teste que garanta que todos os caminhos (fluxos) através do programa sejam percorridos. Utiliza-se um grafo de fluxo de programa onde cada nó representa uma decisão e cada arco um caminho possível. O grafo é usado como base para determinar a complexidade ciclomática do programa Complexidade ciclomática = número_de_arcos número_de_nós + 2

25 Teste de integração Bottom-up Integra unidades já testadas em módulos de mais alto nível, de acordo com a arquitetura.