Visão Geral – Parte 2 - dimap.ufrn.brdimap.ufrn.br/~jair/ES/slides/VisaoGeralParte2.pdf · ... apropriada para os requisitos do sistema e do software. ... Requisitos funcionais

Engenharia de Software, © 2006 Jair C Leite

Visão Geral – Parte 2

Jair C LeiteDIMAp/UFRN


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.


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 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.


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.


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".


Tipos de requisitos não-funcionais


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


O processo de engenharia de requisitos

Fonte: Ian Sommerville


O processo de levantamento-análise-especificação-validação.


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


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


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 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


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


Exemplo – Sistema estação meteorológica –subsistemas e módulos

Fonte: Ian Sommerville, 2000


Exemplo – Sistema estação meteorológicaclasses de um módulo



Arquitetura nos métodos OO (UML)

HelloWorld

paint()

Graphics

Applet

Panel

...

Diagrama de Classes

java

applet

awt

lang

Pacotes


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


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


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


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


Visões arquiteturais (Hofmeister, 2000)


Visão conceitual


Visão de módulos


Visão de execução


Visão de execução

Relação com o hardware


Visão de codificação

Organização do fonte


Visão de codificação


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


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


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.


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).


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.


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.


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.


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


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


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.



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


Testes de integração incremental


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.


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 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


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


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?


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


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


Teste de integração Bottom-up

• Integra unidades já testadas em módulos de mais altonível, de acordo com a arquitetura.

Documents

Visão Geral – Parte 2 - dimap.ufrn.brdimap.ufrn.br/~jair/ES/slides/VisaoGeralParte2.pdf · ... apropriada para os requisitos do sistema e do software. ... Requisitos funcionais