Upload
vuongcong
View
214
Download
0
Embed Size (px)
Citation preview
Engenharia de Software, © 2006 Jair C Leite
Visão Geral – Parte 2
Jair C LeiteDIMAp/UFRN
Engenharia de Software, © 2006 Jair C Leite
Requisitos
• Objetivos ou restrições estabelecidas por clientese usuários do sistema que definem as diversaspropriedades do sistema
• Condição ou capacidade necessária que osoftware 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.
Engenharia de Software, © 2006 Jair C Leite
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
Engenharia de Software, © 2006 Jair C Leite
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 dousuário e do sistema.
– Linguagens gráficas, semi-formais – apropriada para osrequisitos do sistema e do software.
– Linguagens formais – apropriada para uma especificação formalde software em métodos formais.
Engenharia de Software, © 2006 Jair C Leite
Requisitos funcionais
• Descrição das diversas funções que clientes e usuáriosquerem 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 umdeterminado período de tempo.
Engenharia de Software, © 2006 Jair C Leite
Requisitos não-funcionais
• Propriedades de um software, comomanutenibilidade, 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".
Engenharia de Software, © 2006 Jair C Leite
Tipos de requisitos não-funcionais
Engenharia de Software, © 2006 Jair C Leite
Engenharia de Requisitos – 1/2
• Requisitos mudam sempre!• Requisitos precisam ser levantados, analisados,
especificados, rastreados, verificados edocumentados.
• Estas atividades ocorrem ao longo de todo ociclo-de-vida do software.
• A Engenharia de Requisitos propõe modelos,métodos, técnicas e ferramentas para arealização destas atividades
Engenharia de Software, © 2006 Jair C Leite
O processo de engenharia de requisitos
Fonte: Ian Sommerville
Engenharia de Software, © 2006 Jair C Leite
O processo de levantamento-análise-especificação-validação.
Engenharia de Software, © 2006 Jair C Leite
Arquitetura de Software
• A arquitetura de um software é uma estrutura decomponentes interconectados através deinterfaces
• Componentes são compostos de componentesmenores e interfaces
• A interação entre componentes ocorre através desuas interfaces
Engenharia de Software, © 2006 Jair C Leite
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 derede, arquitetura de elementos de hardware, etc.
– Arquitetura de software está relacionada com estes últimos no que sechama de Arquitetura do Sistema.
Fonte: Bredemeyer Consulting
Engenharia de Software, © 2006 Jair C Leite
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
Engenharia de Software, © 2006 Jair C Leite
Arquitetura nos métodos estruturados
• A arquitetura básica éhierárquica:– um programa principal
decomposto em várias sub-rotinas ou funções
– Sub-rotinas podem seragrupadas em módulos
• Forma de Interação:– Chamada-de-função e
passagem de parâmetros• Conceitos:
– Fan-in e Fan-out: mede o graude dependência entre as sub-rotinas.
– Coesão e Acoplamento: umaboa arquitetura deve ter altacoesão e baixo acoplamento
Fan-in
Fan-out
Baixa coesãoAlto acoplamento
Alta coesãoBaixo acoplamento
módulos
Sub-rotinas
Engenharia de Software, © 2006 Jair C Leite
Arquitetura de Software nos MétodosOrientados-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
Engenharia de Software, © 2006 Jair C Leite
Exemplo – Sistema estação meteorológica –subsistemas e módulos
Fonte: Ian Sommerville, 2000
Engenharia de Software, © 2006 Jair C Leite
Exemplo – Sistema estação meteorológicaclasses de um módulo
Fonte: Ian Sommerville, 2000
Engenharia de Software, © 2006 Jair C Leite
Arquitetura nos métodos OO (UML)
HelloWorld
paint()
Graphics
Applet
Panel
...
Diagrama de Classes
java
applet
awt
lang
Pacotes
Engenharia de Software, © 2006 Jair C Leite
Arquitetura de Software – visãoemergente• Objetivos
– Visão abstrata do software através de componentes einterfaces
– 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
Engenharia de Software, © 2006 Jair C Leite
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ísticascomuns
• Mais de um estilo pode ser utilizado em umamesma aplicação
• Semelhanças com a idéia de Patterns
Engenharia de Software, © 2006 Jair C Leite
Tubos e filtros (pipe-and-filter)
• Um Filtro é um componente que processa o fluxo de dados de suaentrada 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
Application Decompression OSFile-
SystemP P Decryption P
req req req
Engenharia de Software, © 2006 Jair C Leite
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 camadasuperior
• Uma camada pode ser modificada desde que mantenha a suainterface
• Aplicações: Sistemas de Janelas; Redes de Computadores
Engenharia de Software, © 2006 Jair C Leite
Visões arquiteturais (Hofmeister, 2000)
Engenharia de Software, © 2006 Jair C Leite
Visão conceitual
Engenharia de Software, © 2006 Jair C Leite
Visão de módulos
Engenharia de Software, © 2006 Jair C Leite
Visão de execução
Engenharia de Software, © 2006 Jair C Leite
Visão de execução
Relação com o hardware
Engenharia de Software, © 2006 Jair C Leite
Visão de codificação
Organização do fonte
Engenharia de Software, © 2006 Jair C Leite
Visão de codificação
Engenharia de Software, © 2006 Jair C Leite
As 3 Visões
Módulo
Componente-e-conector (C&C)
AlocaçãoDecomposição
Utilização
Camadas
Classes
Cliente-servidor
Concorrência
ProcessoDados compartilhados
Atribuiçãode trabalho
Implantação
Implementação
Engenharia de Software, © 2006 Jair C Leite
As 4+1 visões – P. Krutchen
Visão lógicaStakeholders
Funcionalidade
Visão de implementaçãoProgramadores
Gerenciamento de configuração
Visão de processos
DesempenhoEscalabilidade
Integradores
Visão de implantação
Topologia do SistemaComunicação
Engenheiros de Sistema
Visão deCasos de Uso
Diagramas: Classes,Seqüência, Colaboração
Diagramas: Pacotes,componentes
Diagramas: Atividades, ObjetosSeqüência, Colaboração
Diagramas: Implantação
Engenharia de Software, © 2006 Jair C Leite
Preenchimento iterativos das visões – 1/2
Fonte:C. Hofmeister et al. / The Journal of Systems and Software 80 (2007) 106–126
No RUP, o designarquitetural está espalhadonas várias iterações na fasede elaboração.
As 4 visões vão sendoelaboradas de forma iterativa,dirigidas a partir dos casosde usos e requisitos não-funcionais.
Engenharia de Software, © 2006 Jair C Leite
Preenchimento iterativos das visões – 2/2
O processo sugere aelaboração de cenários apartir de requisitos (casos deuso) de negócio e de sistema.
Com base nos cenários sãoelaborados diagramas deseqüência e colaboração.
Em seguida os diagramas declasses (ainda visão lógica) apartir das quais pode-secódigo fonte organizados emmódulos e sub-sistemas.
A visão de processo permite ver a execuçãode processos concorrentes e como elesestão alocados nos nós processadores dosistema (visão de implantação).
Engenharia de Software, © 2006 Jair C Leite
Padrões
• Padrões são soluções para problemas específicos queocorrem de forma recorrente em um determinadocontexto que foram identificados a partir da experiênciacoletiva de desenvolvedores de software.
• A proposta original de padrões veio do trabalho deChristopher 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 entreum certo contexto, um problema, e uma solução.
Engenharia de Software, © 2006 Jair C Leite
Contexto, Problema, Solução e Forças
• O contexto descreve uma situação no desenvolvimentona qual existe um problema.
• O problema que ocorre repetidamente no contexto devetambé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 decomponentes e suas interconexões, obedecendo àsforças do problema.
• As forças, denominação dada por Alexander, descrevemos requisitos que caracterizam o problema e que asolução deve satisfazer, as restrições que devem seraplicadas às soluções e propriedades desejáveis que asolução deve ter.
Engenharia de Software, © 2006 Jair C Leite
Padrão Proxy - idéia
• O Padrão Proxy permite que clientes de um serviçoutilizem um representante do componente que oferece oserviço. Aumenta a eficiência, a segurança e facilita oacesso.
• O Proxy pode substituir o servidor quando ocorremproblemas com o servidor.
• O Proxy permite criar uma independência deendereçamento e implementação do servidor.
Engenharia de Software, © 2006 Jair C Leite
O Padrão Proxy
• Contexto: Um cliente precisa acessar um serviço de um outrocomponente 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 deexecução, ter alto custo e não ser seguro. O cliente não precisa ficardependente de endereço de rede do componente.
• Solução: Utilize um representante do cliente que ofereça o serviço deforma idêntica e realize pré- e pós-processamento adicionais paragarantir a Qualidade do Serviço.
Proxyservice
Client
Serviceservice
1 1
AbstractServiceservice
: Service: Proxy: Clientservice
service
pre-processing
post-processing
Engenharia de Software, © 2006 Jair C Leite
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
Engenharia de Software, © 2006 Jair C Leite
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
Engenharia de Software, © 2006 Jair C Leite
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
Engenharia de Software, © 2006 Jair C Leite
Testes de integração incremental
Engenharia de Software, © 2006 Jair C Leite
Teste de integração Top-down
• Começa pelos componentes de alto nível e vai descendo nahieraquia 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.
Engenharia de Software, © 2006 Jair C Leite
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
Engenharia de Software, © 2006 Jair C Leite
Testes de software
• Elaboração de casos de testesbaseados na especificaçãofuncional– Dados de entradas– Comportamento esperado
• Podem ser classificados– Quanto ao escopo– Quanto ao método
• Aplicações em fatoresoperacionais– Correção– Usabilidade– Desempenho– Robustez
Engenharia de Software, © 2006 Jair C Leite
Testes de correção
• Revelam a presença de erros, mas NÃO aausência
• Um teste bem sucedido é aquele que descobre omaior número de erros existentes.
• Deve ser utilizado em conjunto com técnicas deinspeção– O teste deve identificar o erro– A inspeção analítica (rastreamento ou depuração)
deve localizar e corrigir o erro
Engenharia de Software, © 2006 Jair C Leite
O problema da geração de casos detestes• 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; }
read(x,y);If (x>y) then
max:=x;else
max:=x;print(max);
–Inspecione o código deste programa ao lado:–Aplicando-se os casos de testes acima, conclui-seque o programa não tem erros.–No entanto, bastariam apenas três casos detestes para concluir-se que o programa tem erros.–Como determinar estes casos?
Engenharia de Software, © 2006 Jair C Leite
Testes caixa-preta
• São chamados testesfuncionais.
• O programa é uma caixa pretacujo comportamento édeterminado estudando-se assuas entradas e saídas.
• Os casos de testes sãoderivados da especificaçãofuncional.
• A escolha dos dados deentrada podem ser feitas comvárias técnicas:– Partição de domínio– Grafos de causa-efeito
Engenharia de Software, © 2006 Jair C Leite
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
Engenharia de Software, © 2006 Jair C Leite
Teste de integração Bottom-up
• Integra unidades já testadas em módulos de mais altonível, de acordo com a arquitetura.