43
ENGENHARIA DE ENGENHARIA DE SOFTWARE SOFTWARE RESUMO DA AULA ANTERIOR RESUMO DA AULA ANTERIOR

Aula2 paradigmas

Embed Size (px)

Citation preview

Page 1: Aula2 paradigmas

ENGENHARIA DE ENGENHARIA DE SOFTWARESOFTWARE

RESUMO DA AULA ANTERIORRESUMO DA AULA ANTERIOR

Page 2: Aula2 paradigmas

DefinicaoDefinicao de de Engenharia de Engenharia de softwaresoftware

estabelecimento e uso de sestabelecimento e uso de sóólidos lidos princprincíípios de engenharia para:pios de engenharia para:

Minimizar custos de desenvolvimento Minimizar custos de desenvolvimento de software;de software;Software Software conficonfiáávelvel;;Software eficientemente;Software eficientemente;OrganizacaoOrganizacao;;Produtividade; eProdutividade; eSoftware de qualidadeSoftware de qualidade

Page 3: Aula2 paradigmas

Etapas da Eng. SoftwareEtapas da Eng. Software

Métodos

Como fazer

Ferramentas

Apoio automatizado –CASE Tools

Procedimentos

Definem a sequência em que os métodos são aplicados.

Page 4: Aula2 paradigmas

Ciclo de Vida clCiclo de Vida cláássico da ESssico da ES

Definição deRequisitos

Análise

Desenho

Implementação

Teste

Manutenção

Page 5: Aula2 paradigmas

Processo de Desenvolvimento

Definição (O quê?)- Analise e Planeamento:

o que será desenvolvido

Desenvolvimento (Como?)- Desenho, Codificacao e Teste:

como será desenvolvido

Manutenção (Mudanças?)- Correcao, adaptacao e perfeicao:

que mudanças ocorrerão depois

Page 6: Aula2 paradigmas

PARADIGMAS DA PARADIGMAS DA ENG. DE SOFTWAREENG. DE SOFTWARE

DefiniDefiniçção, Caracterizaão, Caracterizaçção, ão, Vantagens e Desvantagens.Vantagens e Desvantagens.

Page 7: Aula2 paradigmas

Paradigmas de Eng. de SoftwareParadigmas de Eng. de Software

IncrementalIncrementalRADRADIterativoIterativoFormalFormalEstruturadoEstruturadoLLóógicogicoEspiralEspiralEvolutivoEvolutivoOOOOCombinaCombinaççãoão de de ParadigmasParadigmasTTéécnicascnicas de de QuartaQuarta GeraGeraççãoão

Modelos de Ciclo deVida de Software

Page 8: Aula2 paradigmas

Paradigmas de Eng. de Software: Paradigmas de Eng. de Software: Escolha da Estrategia de deve Escolha da Estrategia de deve considerar:considerar:

Natureza do projecto;Tipo da aplicação;Métodos e ferramentas que serão usados;Métodos de controle;Prazo de entrega;Produtos que serão entregues.

Page 9: Aula2 paradigmas

IncrementalIncremental

Desenvolv.incremento

Validaçãoincremento

Integraçãoincremento

Requisitossuperficiais

Requisitosem

incrementos

Projecto da

arquitetura

Sistema incompleto

Sistemacompleto

Validação do

sistema

Page 10: Aula2 paradigmas

IncrementalIncremental

Desenvolvimento atravDesenvolvimento atravéés de incrementos s de incrementos sucessivas do âmbito do sistema;sucessivas do âmbito do sistema;O sistema O sistema éé alargado progressivamente;alargado progressivamente;Ao invés de entregar o sistema completo, divide-se o sistema em partes de tal forma a cada entrega corresponder a alguma funcionalidade do sistema;Requisitos do usuário são priorizados e quanto maior a prioridade, mais cedo tal funcionalidade deve ser entregue;Uma vez que o desenvolvimento de um incremento seja iniciado, esses requisitos são fixados enquanto que os posteriores são deixados serem modificados;

Page 11: Aula2 paradigmas

IncrementalIncremental -- VantagensVantagens

Esta abordagem Esta abordagem éé úútil paratil paraProblemas complexos;Problemas complexos;Recursos humanos insuficientes;Recursos humanos insuficientes;Datas de entrega inflexDatas de entrega inflexííveis.veis.

Page 12: Aula2 paradigmas

IncrementalIncremental -- VantagensVantagens

Solicitações dos clientes são entregues a cada incremento. Assim, as funcionalidades são entregues o mais cedo possívelIncrementos iniciais servem de protótipo para obter requisitos para incrementos posterioresDiminuição do risco de falha de todo o projetoServiços de maior prioridade tendem a receber maior ênfase em testes

Page 13: Aula2 paradigmas

RapidRapid ApplicationApplicationDevelopmentDevelopment (RAD)(RAD)

ÉÉ um modelo de processo de um modelo de processo de desenvolvimento de software desenvolvimento de software iterativo e iterativo e incrementalincremental;;O ciclo de desenvolvimento O ciclo de desenvolvimento éécurto (entre 60 e 90 dias).curto (entre 60 e 90 dias).

Page 14: Aula2 paradigmas

RapidRapid ApplicationApplicationDevelopmentDevelopment (RAD)(RAD)

ModeladoDa gestãoModeladoDa gestão

Modelado Dos dadosModelado Dos dados

Modelado Dos

processos

Modelado Dos

processos

Geração deAplicaçõesGeração deAplicações

Testes eentrega

Testes eentrega

ModeladoDa gestãoModeladoDa gestão

Modelado Dos dadosModelado Dos dados

Modelado Dos

processos

Modelado Dos

processos

Geração deAplicaçõesGeração deAplicações

Testes eentrega

Testes eentrega

ModeladoDa gestãoModeladoDa gestão

Modelado Dos dadosModelado Dos dados

Modelado Dos

processos

Modelado Dos

processos

Geração deAplicações

Geração deAplicações

Testes eentrega

Testes eentrega

Equipa 1 Equipa 2 Equipa 3

Page 15: Aula2 paradigmas

RAD RAD -- VantagensVantagensPermite o desenvolvimento rPermite o desenvolvimento ráápido e/ou a pido e/ou a prototipagemprototipagem de aplicade aplicaçções;ões;Enfatiza um ciclo de desenvolvimento Enfatiza um ciclo de desenvolvimento extremamente curto (entre 60 e 90 dias);extremamente curto (entre 60 e 90 dias);Cada funCada funçção principal pode ser ão principal pode ser direcionadadirecionadapara uma equipe RAD separada e então para uma equipe RAD separada e então integrada a formar um todo;integrada a formar um todo;CriaCriaçção e reutilizaão e reutilizaçção de componentes;ão de componentes;Visibilidade mais cedo (protVisibilidade mais cedo (protóótipos)tipos)Maior flexibilidade (desenvolvedores podem Maior flexibilidade (desenvolvedores podem experimentar praticamente a vontade)experimentar praticamente a vontade)Grande reduGrande reduçção de codificaão de codificaçção manual ão manual ((wizardswizards...);...);Envolvimento maior do usuEnvolvimento maior do usuáário;rio;ProvProváável custo reduzido (tempo vel custo reduzido (tempo éé dinheiro e dinheiro e tambtambéém devido ao m devido ao reusoreuso););

Page 16: Aula2 paradigmas

RAD RAD -- DesvantagensDesvantagens

Se uma aplicaSe uma aplicaçção não puder ser ão não puder ser modularizada de modo que cada funmodularizada de modo que cada funçção ão principal seja completada em menos de 3 principal seja completada em menos de 3 meses, não meses, não éé aconselhaconselháável o uso do RAD;vel o uso do RAD;Para projectos grandes (mas escalPara projectos grandes (mas escalááveis) o veis) o RAD exige recursos humanos suficientes RAD exige recursos humanos suficientes para criar o npara criar o núúmero correcto de equipes, mero correcto de equipes, isso implica em um alto custo com a isso implica em um alto custo com a equipe;equipe;O envolvimento com o usuO envolvimento com o usuáário tem que ser rio tem que ser activo;activo;Comprometimento da equipe do projecto;Comprometimento da equipe do projecto;

Page 17: Aula2 paradigmas

RAD RAD -- DesvantagensDesvantagens

O RAD O RAD não não éé aconselhaconselháávelvel quando os quando os riscos triscos téécnicos são altos e não cnicos são altos e não éé indicada indicada quando se estquando se estáá testando testando novas novas tecnologias;tecnologias;Menos eficientes;Menos eficientes;Perda de precisão cientPerda de precisão cientíífica (falta de fica (falta de mméétodos formais);todos formais);FunFunçções reduzidas (ões reduzidas (reusoreuso, ", "timeboxingtimeboxing");");Problemas legais;Problemas legais;Requisitos podem não se encaixar Requisitos podem não se encaixar (conflitos entre desenvolvedores e clientes)(conflitos entre desenvolvedores e clientes)Sucessos anteriores são difSucessos anteriores são difííceis de se ceis de se reproduzirreproduzir..

Page 18: Aula2 paradigmas

O RAD O RAD éé apropriado quandoapropriado quando

A aplicaA aplicaçção ão éé do tipo "do tipo "standalonestandalone";";A performance não A performance não éé o mais o mais importante;importante;A distribuiA distribuiçção do produto ão do produto éé pequena;pequena;O escopo do projecto O escopo do projecto éé restrito;restrito;O sistema pode ser dividido em O sistema pode ser dividido em vváários mrios móódulos independentes;dulos independentes;A tecnologia necessA tecnologia necessáária tem mais de ria tem mais de um ano de existência.um ano de existência.

Page 19: Aula2 paradigmas

O RAD deve ser evitado O RAD deve ser evitado quandoquando

A aplicaA aplicaçção precisa interagir com outros programas;ão precisa interagir com outros programas;Performance Performance éé essencial;essencial;O desenvolvimento não pode tirar vantagem de O desenvolvimento não pode tirar vantagem de ferramentas de alto nferramentas de alto níível;vel;A distribuiA distribuiçção do produto serão do produto seráá em grande escala;em grande escala;Para se construir sistemas operacionais Para se construir sistemas operacionais ((confiabilidadeconfiabilidade exigida alta demais)exigida alta demais)Jogos de computador (performance exigida muito Jogos de computador (performance exigida muito alta)alta)Riscos tecnolRiscos tecnolóógicos muito altos devido a tecnologia gicos muito altos devido a tecnologia ter sido recter sido recéém lanm lanççada;ada;O sistema não pode ser modularizado.O sistema não pode ser modularizado.

Page 20: Aula2 paradigmas

IterativoAplicação do modelo cascata

iterativamente;As iterações iniciais atacam os

maiores riscos;

Page 21: Aula2 paradigmas

IterativoIterativoOs requisitos do sistema SEMPRE mudam durante o desenvolvimentoIteração pode ser aplicado a qualquer um dos processos de desenvolvimentoDuas abordagens são destacadas:

Desenvolvimento incrementalDesenvolvimento em espiral.

Page 22: Aula2 paradigmas

IterativoDesenvolvimento iterativo antecipa a redução de riscos;Testes e integração são realizados desde o início, de forma contínua;Riscos críticos são resolvidos antes que grandes investimentos sejam realizados;Permite feedback dos usuários desde cedo;Pequenos objectivos, foco em curto-prazo;Progresso é medido de forma mais concreta;Implementações parciais podem ser implantadas;

Page 23: Aula2 paradigmas

FormalFormal

Definição derequisitos

Especificaçãoformal

Transformaçãoformal

Integração etestes

Page 24: Aula2 paradigmas

FormalFormal

MMéétodos formaistodos formaisEspecificaEspecificaçção matemão matemááticaticaExacta e rigorosaExacta e rigorosaDetecta e corrige requisitos Detecta e corrige requisitos incompletos, ambincompletos, ambííguos e guos e inconsistentesinconsistentes

Page 25: Aula2 paradigmas

FormalFormal

DesvantagensDesvantagensNecessita de profissionais altamente Necessita de profissionais altamente qualificados para aplicar a tqualificados para aplicar a téécnicacnicaAlguns aspectos ainda são difAlguns aspectos ainda são difííceis de ceis de especificar (GUI)especificar (GUI)

VantagensVantagensGarantia de seguranGarantia de segurançça e a e confiabilidadeconfiabilidade

AplicaAplicaççõesõesSistemas crSistemas crííticos e complexosticos e complexos

Page 26: Aula2 paradigmas

CascataCascataVVáárias actividades executadas de forma rias actividades executadas de forma sistemsistemáática e sequencialtica e sequencial

Page 27: Aula2 paradigmas

CascataCascataUm dos mais antigos, e ainda um dos mais Um dos mais antigos, e ainda um dos mais usados!usados!VVáárias actividades executadas deforma rias actividades executadas deforma sistemsistemáática e sequencial;tica e sequencial;Fixa pontos especFixa pontos especííficos para a entrega de ficos para a entrega de artefactos;artefactos;ÉÉ simples e fsimples e fáácil de aplicar, facilitando o cil de aplicar, facilitando o planeamento;planeamento;Na prNa práática, existe uma interactica, existe uma interacçção entre as ão entre as atividades e cada atividade pode levar a atividades e cada atividade pode levar a modificamodificaçções nas anteriores;ões nas anteriores;Pressupõe que os requisitos ficarão Pressupõe que os requisitos ficarão estestááveis;veis;Atrasa a reduAtrasa a reduçção de riscos.ão de riscos.

Page 28: Aula2 paradigmas

Cascata Cascata -- VantagensVantagens

Padroniza os métodos para análise, projecto, codificação, testes e manutenção.Etapas semelhantes às etapas genéricas aplicáveis a todos os paradigmas;OrientadoOrientado a a documentadocumentaççãoão;;ManutenManutenççãoão éé maismais simples.simples.

Page 29: Aula2 paradigmas

Cascata Cascata -- DesvantagensProjectos reais raramente seguem o fluxo sequencial que esse modelo propõe. Sempre ocorre alguma interacção e/ou superposição;Dificilmente os clientes são capazes de relacionar todos os requisitos de uma sóvez no início do projecto;Maioria dos programas só estarádisponível quando o cronograma já estábastante adiantado;Dificuldades para se introduzir alterações quando o processo está avançado;Dificuldade para lidar com as mudanDificuldade para lidar com as mudançças as nos requisitos do sistemanos requisitos do sistemaNão gere riscosNão gere riscos

Page 30: Aula2 paradigmas

EspiralEspiral

Page 31: Aula2 paradigmas

EspiralEspiral

AnAnáálise de riscos como ferramenta;lise de riscos como ferramenta;Essencial para o planeamento e Essencial para o planeamento e gestão do projecto;gestão do projecto;Dificuldades para fechar o contrato;Dificuldades para fechar o contrato;Complexo e requer experiência na Complexo e requer experiência na avaliaavaliaçção de riscos!ão de riscos!

Page 32: Aula2 paradigmas

Espiral Espiral -- VantagensVantagens

Modelo evolutivo possibilita uma maior integração entre as fases e facilita a depuração e a manutenção do sistema.Permite que o projectista e cliente possa entender e reagir aos riscos em cada etapa evolutiva.FFáácilcil de de decidirdecidir o o quandoquando testartestar

Page 33: Aula2 paradigmas

Espiral Espiral -- DesvantagensDesvantagens

Avaliação dos riscos exige muita experiência;O modelo é relativamente novo e não tem sido amplamente utilizado;BemBem aplicadoaplicado somentesomente a a sistemassistemasde de largalarga escalaescala;;SistemasSistemas devemdevem ser ser produtosprodutosinternosinternos dada empresaempresa..

Page 34: Aula2 paradigmas

44ªª GeraGeraççãoão

Ferramentas de 4Ferramentas de 4ªª GeraGeraççãoãoSuporte automatizado Suporte automatizado ààespecificaespecificaçção de requisitosão de requisitos..

A ferramenta gera A ferramenta gera codigocodigo--fontefonte, , na base da especna base da especificaificaççãoão do do desenvolvedor;desenvolvedor;

Page 35: Aula2 paradigmas

CombinaCombinaçção de Paradigmasão de Paradigmas

Os paradigmas para a Os paradigmas para a Engenharia de Software Engenharia de Software alcancamalcancam melhores resultados melhores resultados quando combinadas. quando combinadas. ExemExemploplo::

Espiral resulta da Espiral resulta da combinacaocombinacaoentre a Prototipacao e cascata entre a Prototipacao e cascata numa abordagem revolucionaria.numa abordagem revolucionaria.

Page 36: Aula2 paradigmas

EvolutivoEvolutivo

Atividadesconcorrentes

Especificação

Desenvolvimento

Validação

Versãoinicial

Versãofinal

Versõesintermediárias

Descriçãosuperficial

Page 37: Aula2 paradigmas

EvolutivoEvolutivo

Desenvolvimento exploratDesenvolvimento exploratóório rio (Prot(Protóótipo evoluciontipo evolucionáário)rio)

Construa, avalie e evolua para produtoConstrua, avalie e evolua para produtoTrabalhar com os clientes atTrabalhar com os clientes atéé se obter o se obter o produto final a partir de uma especificaproduto final a partir de uma especificaçção ão bembem--definidadefinida e completa do sistema.e completa do sistema.

ProtProtóótipo descarttipo descartáávelvelConstrua, use e descarteConstrua, use e descarte

Obter requisitos do cliente. IniciaObter requisitos do cliente. Inicia--se com se com uma especificauma especificaçção incompleta e simples do ão incompleta e simples do sistemasistema

Page 38: Aula2 paradigmas

EstruturadoEstruturado

Page 39: Aula2 paradigmas

Orientado a ObjectosOrientado a Objectos

Métodos OO são voltados principalmente para sistemas complexos, que devem ser divididos para a distribuição dos trabalhos pela equipe;A abordagem OO se baseia em um desenvolvimento onde fases teoricamente já completadas são revistas continuamente, e alteradas se preciso;Iterativo e Iterativo e incrementalincremental..

Page 40: Aula2 paradigmas

Orientado a ObjectosOrientado a Objectos

recursivo(modelo evolutivo)

paralelo(reutilização de componentes)

desenvolver novas classes,se não existem

adicionar novas classes à biblioteca

construir n-ésimaiteração do sistema

Análise de Riscos

Engenhariae Construção

Baseado em componentes Baseado em componentes UnifiedUnified DevelopmentDevelopment ProcessProcessUtiliza UML Utiliza UML

Identificar classes candidatas

buscar classes na biblioteca

extrair classes, se existem

Page 41: Aula2 paradigmas

SelecSelecçção do Modeloão do Modelo

Projectos pequenos: ciclo Projectos pequenos: ciclo clcláássicossicoLimites severos de tempo: RADLimites severos de tempo: RADData entrega muito prData entrega muito próóxima: xima: modelo modelo incrementalincremental..Sistemas Complexos com Sistemas Complexos com muitas mudanmuitas mudançças de Requisitos: as de Requisitos: Orientadas a Objectos;Orientadas a Objectos;

Page 42: Aula2 paradigmas

BIBLIOGRAFIABIBLIOGRAFIA

Gerry Coleman and Gerry Coleman and RenaatRenaat VerbruggenVerbruggen. A. A quality quality software process for rapid application developmentsoftware process for rapid application development, , Software Quality Journal 7, pp. 107Software Quality Journal 7, pp. 107--122, 1998.122, 1998.

Software Software EngineeringEngineering. I.Somme. I.Sommervillerville;;

Engenharia de Software, Engenharia de Software, RogerRoger S. S. PressmanPressman, 3., 3.ªªEdiEdiççãoão..

A Discipline for Software A Discipline for Software EngineeringEngineering. . W.S.HumphreyW.S.Humphrey;;

httphttp://://pt.wikipedia.orgpt.wikipedia.org/wi/wikiki/En/Engenharia_de_softwaregenharia_de_software, , de 9/de 9/FevFev/2007/2007

Page 43: Aula2 paradigmas

TPCTPC1.1. FacaFaca um um estudoestudo comparativocomparativo dos dos seguintesseguintes

paradigmasparadigmas::a.a. Evolutivo e Espiral;Evolutivo e Espiral;b.b. IncrementalIncremental e Iterativo;e Iterativo;c.c. Estruturada e OO;Estruturada e OO;

2.2. Para cada uma das Para cada uma das situacoessituacoes que modelo usaria que modelo usaria para desenvolvimento de Software:para desenvolvimento de Software:

a.a. Tempo reduzido (60 dias);Tempo reduzido (60 dias);b.b. Sistema complexo, com muitos riscos;Sistema complexo, com muitos riscos;c.c. Sistema com uma dimensão muito reduzida;Sistema com uma dimensão muito reduzida;d.d. Sistema critico com alta precisão de Sistema critico com alta precisão de

processamento (logico ou matemprocessamento (logico ou matemáático);tico);e.e. ImplementaImplementaçção de um jogo de entretenimento;ão de um jogo de entretenimento;

3.3. Para o desenvolvimento de um software para Para o desenvolvimento de um software para gestaogestao de registos academicos da UST, que com de registos academicos da UST, que com binbinacaoacao de modelos usaria? Justifique a sua de modelos usaria? Justifique a sua escolha.escolha.