• Nenhum resultado encontrado

Semana 4

N/A
N/A
Protected

Academic year: 2021

Share "Semana 4"

Copied!
12
0
0

Texto

(1)

MDS

MODELAGEM DE

DESENVOLVIMENTO DE SISTEMAS

Semana 4

OSASCO OSASCO Profª Tania Arruda Profª Tania Arruda

VISÃO GERAL DA ENGENHARIA DE SOFTWARE  O processo de desenvolvimento de software contém três fases

genéricas independente do paradigma de software escolhido. São elas:  definição;definição;  o quê? ?  desenvolvimentodesenvolvimento; e,  como?  manutençãomanutenção.

 mudanças (o quê? e como?)

VISÃO GERAL DA ENGENHARIA DE SOFTWARE . . .  DEFINIÇÃODEFINIÇÃO

 A fase de definição focaliza o quê. Ou seja, durante a fase de

definição, o desenvolvedor de software tenta identificar quais

informações têm de ser processadas, qual função e desempenho são desejados, quais interfaces devem ser estabelecidas, quais restrições de projeto existem e quais critérios de validação são exigidos para se definir um sistema bem-sucedido. Esta fase apresenta as seguintes etapas:

 análise de sistema; análise de sistema

 planejamento do projeto de software; e,planejamento do projeto de software  análise de requisitos.análise de requisitos

(2)

VISÃO GERAL DA ENGENHARIA DE SOFTWARE . . .  DEFINIÇÃO . . .DEFINIÇÃO . . .

 Análise de sistemaAnálise de sistema

 define o papel de cada elemento num sistema baseado em computador, atribuindo o papel que o software desempenhará.

 Planejamento do projeto de softwarePlanejamento do projeto de software

 uma vez definido o escopo do software, os riscos são analisados, as atividades e os recursos são definidos, os prazos são estabelecidos e os custos são estimados.

VISÃO GERAL DA ENGENHARIA DE SOFTWARE . . .  DEFINIÇÃO . . .DEFINIÇÃO . . .

 Análise de requisitosAnálise de requisitos

 definição detalhada do domínio da informação e da função do software.

VISÃO GERAL DA ENGENHARIA DE SOFTWARE . . .  DESENVOLVIMENTODESENVOLVIMENTO

 A fase de desenvolvimento focaliza o como. Ou seja, o desenvolvedor de software tenta definir como a estrutura de dados e a arquitetura de software têm de ser projetadas, como os detalhes procedimentais têm de ser implementados,

como projeto será traduzido numa linguagem de

programação e como os testes têm de ser realizados. Esta fase apresenta as seguintes etapas:

 projeto de software; projeto de software  codificação; e,codificação

(3)

VISÃO GERAL DA ENGENHARIA DE SOFTWARE . . .  DESENVOLVIMENTO . . .DESENVOLVIMENTO . . .

Projeto de softwareProjeto de software

 traduz os requisitos do software num conjunto de representações que descrevem a estrutura de dados, a

arquitetura, o procedimento algorítmico e as

características de interface. CodificaçãoCodificação

 as representações do projeto devem ser convertidas numa linguagem de programação convencional ou numa linguagem não-procedimental usada no contexto do paradigma 4GT (técnicas de quarta geração).

VISÃO GERAL DA ENGENHARIA DE SOFTWARE . . .  DESENVOLVIMENTO . . .DESENVOLVIMENTO . . .

Realização de testes do softwareRealização de testes do software

 O software deve ser testado para que se possa descobrir defeitos de função, de lógica e de implementação.

VISÃO GERAL DA ENGENHARIA DE SOFTWARE . . .  MANUTENÇÃOMANUTENÇÃO

 A fase de manutenção concentra-se nas mudanças que estão associadas à correção de erros, adaptações exigidas à medida que o ambiente do software evolui e ampliações produzidas por exigências variáveis do cliente. Esta fase apresenta as seguintes etapas:

 correção; correção  adaptação; e,adaptação  melhoramento funcional.melhoramento funcional

(4)

VISÃO GERAL DA ENGENHARIA DE SOFTWARE . . .  MANUTENÇÃOMANUTENÇÃO

CorreçãoCorreção

 A manutenção corretiva muda o software para corrigir defeitos.

 AdaptaçãoAdaptação

 A manutenção adaptativa resulta em modificações no software a fim de acomodar mudanças em seu ambiente.

VISÃO GERAL DA ENGENHARIA DE SOFTWARE . . .  MANUTENÇÃOMANUTENÇÃO

Melhoramento funcionalMelhoramento funcional

 O melhoramento funcional estende o software para além de suas exigências funcionais originais.

VISÃO GERAL DA ENGENHARIA DE SOFTWARE . . .  As fases apresentadas são completadas por uma série de

atividades de proteção, conforme a seguir: revisõesrevisões (qualidade);

documentaçãodocumentação; e, controle de mudançascontrole de mudanças.

(5)

PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE

CICLO DE VIDA CLÁSSICO (modelo cascata)CICLO DE VIDA CLÁSSICO (modelo cascata)

 Também conhecido como modelo cascata, o paradigma do ciclo de vida clássico requer uma abordagem sistemática, seqüencial ao desenvolvimento de software, conforme figura a seguir: Engenharia de Sistemas Análise Projeto Teste Manutenção Codificação

Ciclo de vida clássico –

Ciclo de vida clássico –

modelo cascata

modelo cascata

PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . .

PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . CICLO DE VIDA CLÁSSICO (modelo cascata) . . .CICLO DE VIDA CLÁSSICO (modelo cascata) . . .

engenharia de sistemas;engenharia de sistemas; análise de requisitos de software;análise de requisitos de software; projeto;projeto;

codificação;codificação; teste; e,teste; e, manutenção.manutenção.

(6)

PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . CICLO DE VIDA CLÁSSICO (modelo cascata) . . .CICLO DE VIDA CLÁSSICO (modelo cascata) . . .

Engenharia de sistemasEngenharia de sistemas

 Coletar os requisitos em nível de sistema, com uma pequena quantidade de projeto e análise de alto nível. Análise de requisitos de softwareAnálise de requisitos de software

 Compreender o domínio da informação para o software, bem como a função, desempenho e interface exigidos. Os requisitos, tanto para o sistema como para o software, são documentados e revistos com o cliente.

PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . CICLO DE VIDA CLÁSSICO (modelo cascata) . . .CICLO DE VIDA CLÁSSICO (modelo cascata) . . .

ProjetoProjeto

 Gerar os quatro atributos distintos do programa: estrutura de dados, arquitetura de software, detalhes procedimentais e caracterização de interface.

 O projeto é documentado e torna-se parte da configuração do software.

CodificaçãoCodificação

 Traduzir o projeto numa forma legível por máquina.

PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . CICLO DE VIDA CLÁSSICO (modelo cascata) . . .CICLO DE VIDA CLÁSSICO (modelo cascata) . . .

TestesTestes

 Realizar testes para descobrir erros técnicos e funcionais, buscando fazer com que a entrada definida produza resultados reais compatíveis com os resultados exigidos.

ManutençãoManutenção

 Reaplicar cada uma das etapas precedentes do ciclo de vida a um programa existente, sempre que ocorrerem mudanças (correções, adaptações ou melhoramentos).

(7)

PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . CICLO DE VIDA CLÁSSICO (modelo cascata) . . .CICLO DE VIDA CLÁSSICO (modelo cascata) . . .

 O modelo cascata é o paradigma mais antigo e o mais amplamente usado na engenharia de software. No entanto, os seguintes aspectos devem ser considerados:

 raramente seguem o fluxo seqüencial que o modelo propõe;

 necessidade de iterações trazem problemas para aplicação do paradigma;

 dificuldade de acomodar a incerteza natural que existe no começo de muitos projetos;

 erros descobertos tardiamente, podem ser desastrosos ao projeto.

PROTOTIPAÇÃOPROTOTIPAÇÃO

 Processo que capacita o desenvolvedor a criar um modelo do software que será implementado.

 Pode assumir uma das três formas:

protótipo em papel ou modelo baseado em PC;protótipo em papel ou modelo baseado em PC; protótipo de trabalho; e,protótipo de trabalho

programa existente.programa existente

PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . .

Protótipo em papel ou modelo baseado em PCProtótipo em papel ou modelo baseado em PC

 Retrata a interação homem-máquina de uma forma que

capacita o usuário a entender quanta interação ocorrerá.

Protótipo de trabalhoProtótipo de trabalho

 Implementa algum subconjunto da função exigida do software desejado.

Programa existentePrograma existente

 Executa parte ou toda a função desejada, mas tem outras características que serão melhoradas em um novo esforço de desenvolvimento.

PROTOTIPAÇÃO . . .PROTOTIPAÇÃO . . .

(8)

Coleta e refinamento dos requisitos P ro je to ráp ido Co nstr ução do pro tótip o Avaliação do protótipo pelo cliente En genh aria d o pro du to R e fina m e nto do prot ótipo Início Fim Seqüência de eventos do paradigma de prototipação

PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . PROTOTIPAÇÃO . . .PROTOTIPAÇÃO . . .

 Ainda que possam ocorrer problemas, a prototipação é um paradigma eficiente da engenharia de software. A chave é definir-se as regras do jogo logo no começo; ou seja, o cliente e o desenvolvedor devem concordar que o protótipo seja construído para servir como um mecanismo de definição dos requisitos. Ele depois será descartado (pelo menos em parte) e o software real será projetado, levando-se em conta a qualidade e a manutenção.

PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . PROTOTIPAÇÃO . . .PROTOTIPAÇÃO . . .

 Desenvolvido para abranger as melhores características tanto do ciclo clássico como da prototipação, acrescentando, ao mesmo tempo, um novo elemento – a análise de riscos – que falta a esses paradigmas.

Análise dos riscos baseada nos requisitos iniciais Análise dos riscos baseada na reação do cliente

Decisão de prosseguir / não prosseguir

Protótipo do software inicial Protótipo no nível seguinte Sistema construído pela engenharia Avaliação

do cliente

Planejamento Análise dos riscos

Avaliação do cliente Engenharia Planejamento baseado nos comentários do cliente Coleta inicial dos requisitos e planejamento do projeto

PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . .

MODELO ESPIRALMODELO ESPIRAL

(9)

 O modelo representado pela espiral define quatro

importantes atividades representadas pelos quatro

quadrantes da figura:  planejamento;planejamento  análise dos riscos;análise dos riscos  engenharia; e,engenharia  avaliação do cliente.avaliação do cliente

PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . MODELO ESPIRAL . . .MODELO ESPIRAL . . .

PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . MODELO ESPIRAL . . .MODELO ESPIRAL . . .

PlanejamentoPlanejamento

 Mistura análise com projeto. Nesta fase determina-se os objetivos, restrições e verifica-se alternativas de projeto.

Análise de riscoAnálise de risco

 Nesta fase analisa-se as alternativas e verifica-se os riscos. Decide-se seguir o projeto na mesma linha ou começar de novo.

EngenhariaEngenharia

 Nesta fase desenvolve-se o protótipo. A cada nova fase de engenharia o produto aproxima-se mais do produto final. Esta fase pode incluir todo o ciclo de vida clássico.

Avaliação do clienteAvaliação do cliente

 O cliente avalia o produto. Os desenvolvedores verificam a necessidade de novas fases.

 O cliente avalia o trabalho de engenharia (o quadrante de avaliação do cliente) e apresenta sugestões para modificações.

 Na maioria dos casos, o fluxo ocorre ao redor de uma

trajetória espiral contínua, com cada trajetória

movimentando os desenvolvedores para fora na direção de um modelo mais completo do sistema.

 O paradigma de modelo espiral para a engenharia de software é atualmente a abordagem mais apropriada para o desenvolvimento de sistemas e de software em grande escala.

PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . MODELO ESPIRAL . . .MODELO ESPIRAL . . .

(10)

 O termo Técnicas de Quarta Geração abrange um amplo conjunto de ferramentas de software que têm uma coisa em comum: cada uma delas possibilita que o desenvolvedor especifique alguma característica do software em alto nível. A ferramenta gera então, automaticamente, o código-fonte, tendo como base a especificação do desenvolvedor. O paradigma da técnica de quarta geração concentra-se na capacidade de se especificar software a uma máquina em um nível que esteja próximo à linguagem natural ou de se usar uma notação que comunique uma função significativa. PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . .

TÉCNICAS DE QUARTA GERAÇÃOTÉCNICAS DE QUARTA GERAÇÃO

 O usuário realiza a especificação em uma linguagem de 4G, em alto nível.

 A codificação propriamente dita é realizada por uma linguagem de 4G.

 Uma ferramenta de 4G é responsável por transformar automaticamente a especificação em código executável.  Quanto mais alto o nível da especificação (ou seja, mais

próxima da linguagem natural), mais rapidamente é gerado o produto final.

PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . TÉCNICAS DE QUARTA GERAÇÃOTÉCNICAS DE QUARTA GERAÇÃO

 O ambiente de desenvolvimento de software que sustenta o ciclo de vida de quarta geração inclui:

linguagens não procedimentais para consulta de banco de dados;

ferramentas para geração de relatórios; ferramentas para manipulação de dados; ferramentas para definir interação e telas; ferramentas para geração de códigos; capacidade gráfica de alto nível; e, capacidade de planilhas eletrônicas.

PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . TÉCNICAS DE QUARTA GERAÇÃO . . .TÉCNICAS DE QUARTA GERAÇÃO . . .

(11)

Coleta de Requisitos Estratégia de “Projeto” Implementação Usando 4G Teste

PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . .

Ciclo de vida a partir das

Ciclo de vida a partir das

Técnicas de Quarta Geração

Técnicas de Quarta Geração

 Coleta de requisitos

O cliente descreve os requisitos os quais são traduzidos para um protótipo operacional.

Problemas:

o cliente pode estar inseguro quanto aos requisitos; o cliente pode ser incapaz de especificar as informações de modo que uma ferramenta de 4G possa entender; e,

as linguagens de 4G atuais não são sofisticadas

suficientemente para acomodar a verdadeira

linguagem natural.

PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . TÉCNICAS DE QUARTA GERAÇÃO . . .TÉCNICAS DE QUARTA GERAÇÃO . . .

 Estratégia de projeto

Nesta fase normalmente é projetado como o software será feito, organizado, estruturado, etc.;

No entanto, para pequenas aplicações é possível mover-se da fase um direto para a fase três, pulando a fase de projeto. Utilizando linguagens de quarta geração, às vezes esta fase não é necessária; e, Já para grandes projetos é sempre necessário desenvolver uma estratégia de projeto. Caso contrário ocorrerão os mesmos problemas encontrados quando se

usa abordagem convencional (baixa qualidade,

manutenção ruim, má aceitação do cliente, etc). PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . TÉCNICAS DE QUARTA GERAÇÃO . . .TÉCNICAS DE QUARTA GERAÇÃO . . .

(12)

Implementação usando linguagem de 4G

Os resultados desejados são representados de modo que haja geração automática de código. Deve existir uma estrutura de dados com informações relevantes e que seja acessível pela 4G.

Teste

O desenvolvedor deve efetuar testes e desenvolver

uma documentação significativa. O software

desenvolvido deve ser construído de maneira que a manutenção possa ser efetuada prontamente. PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . TÉCNICAS DE QUARTA GERAÇÃO . . .TÉCNICAS DE QUARTA GERAÇÃO . . .

Considerações Favoráveis

Os defensores das linguagens de 4G argumentam que por meio delas se obtém uma redução dramática no tempo de desenvolvimento do software (aumento de produtividade).

Desfavoráveis

As linguagens de 4G atuais não são mais fáceis de usar do que as linguagens de programação. O código fonte produzido é ineficiente.

A manutenção de sistemas usando técnicas de 4G ainda é questionável.

PARADIGMAS DO DESENVOLVIMENTO DE SOFTWARE . . . TÉCNICAS DE QUARTA GERAÇÃO . . .TÉCNICAS DE QUARTA GERAÇÃO . . .

Referências

Documentos relacionados

Os testes de desequilíbrio de resistência DC dentro de um par e de desequilíbrio de resistência DC entre pares se tornarão uma preocupação ainda maior à medida que mais

Para tal, foram testadas as seguintes hipóteses; i- em locais mais íngremes ocorre maior substituição de espécies de macrófitas, visto que essas áreas são mais instáveis devido a

Faial, que parecia mesmo um lobo, abriu e fechou a boca várias vezes, mas não uivou (19).. No entanto, era evidente (20) que os cães também se

A análise mostrou a oportunidade de (i) adoção de uma estratégia de planejamento que reflita um modelo sustentável de desenvolvimento que inclua decisões sobre o futuro da Amazônia

The analysis found that there is an opportunity to (i) enact a planning strategy that reflects a sustainable development model and includes decisions about the future of the Amazon

Ainda segundo Gil (2002), como a revisão bibliográfica esclarece os pressupostos teóricos que dão fundamentação à pesquisa e às contribuições oferecidas por

A tabela 25 apresenta os resultados brutos desta avaliação em relação à característica busca e a tabela 26 exibe o resultado ponderado para esta característica.. A tabela 27

Uma matriz computacional é inspirada na matriz matemática, que também é capaz de armazenar um conjunto de valores em duas dimensões.. LF2 são os limites de cada dimensão da