03a - Paradigmas

Prévia do material em texto

28/02/2025
Paradigmas de Software
2
• Introdução aos paradigmas de software.
• Descrição de modelos genéricos e sua aplicabilidade.
• Descrição dos processos de requisitos, desenvolvimento, teste 
e evolução.
• Modelo Rational Unified Process (RUP).
• Introdução à tecnologia CASE (Computer-Aided Software 
Engeneering) no suporte das atividades.
Objetivos
3
Processos de Desenvolvimento
• Conjunto de atividades necessário ao desenvolvimento de 
sistemas de software:
• especificação;
• desenho;
• validação;
• evolução.
• Paradigma: representação abstrata de um processo, descrição 
desde perspectiva única.
1
2
3
28/02/2025
4
Processos Genéricos
• Modelo Cascata (Clássico, Seqüencial):
• fases distintas e isoladas de especificação e desenvolvimento.
• Evolucionário:
• especificação, desenvolvimento e validação em camadas.
• Desenvolvimento modular:
• Sistema baseado em biblioteca de componentes.
• Muitas variações existentes:
• i.e: Desenvolvimento Formal = modelo clássico com especificação 
formal e refinamento.
5
Técnicas Básicas
• PDCA:
• Plan, Do, Check e Act;
• planejar, executar, verificar e corrigir.
• 5W1H:
• What, When, Where, Who, Why e How;
• o quê, quando, onde, quem, porque e como.
• Você só controla aquilo que você mede.
6
Técnicas Básicas
• Princípios de Engenharia de SW:
• Formalidade: controle, custo, confiança;
• Abstração: foco em aspectos fundamentais;
• Segmentação: atividades específicas, especialistas;
• Generalização: reutilização;
• Flexibilização: alterações.
4
5
6
28/02/2025
7
Modelo Clássico
8
1. Análise e definição dos Requisitos.
2. Desenho do sistema (arquitetura e SW).
3. Implementação e teste unitário.
4. Integração e teste do sistema.
5. Operação e manutenção.
• Principais falhas:
• difícil acomodar alterações;
• alocação de recursos;
• uma fase deve terminar para início da próxima.
Modelo Clássico
9
1. Análise e definição dos Requisitos:
• coleta e detalhamento de requisitos / identificação dos elementos e 
qualidade do sistema. Foco no SW;
• essencial se o sistema possui interfaces (HW, BD, people);
• domínio, função, desempenho, interfaces;
• documentação e revisão.
Modelo Clássico
7
8
9
28/02/2025
10
2. Desenho do sistema (arquitetura e SW):
• conjunto de representações para avaliação;
• estrutura de dados;
• arquitetura de SW;
• detalhamento dos procedimentos;
• caracterização das interfaces.
Modelo Clássico
11
3. Implementação e teste unitário:
• aspectos lógicos e funcionais.
4. Integração e teste do sistema:
• aspectos lógicos e funcionais.
5. Operação e manutenção:
• dia a dia;
• corretiva, adaptativa e evolutiva.
Modelo Clássico
12
• Problemas:
• particionamento rígido do modelo torna difícil acomodar alterações 
solicitadas pelo cliente.
• adequado apenas a situação em que os requisitos são bem entendidos 
/ definidos e alterações limitadas.
• poucos negócios possuem requisitos rígidos.
• modelo mais utilizado para grandes projetos com desenvolvimento em 
vários sites.
• falta otimização da utilização dos recursos.
Modelo Clássico
10
11
12
28/02/2025
13
Modelo Evolutivo
• Desenvolvimento exploratório:
• trabalho conjunto com o cliente visando evoluir de um sistema básico;
• iniciar com requisitos conhecidos e analisados e adicionar 
funcionalidades conforme solicitação.
• Prototipação:
• objetiva identificar / entender requisitos;
• início com requisitos pouco conhecidos.
14
Modelo Evolutivo
15
• Problemas:
• perda de visibilidade do processo;
• sistemas (normalmente) fracamente estruturados;
• podem ser necessárias habilidades específicas.
• Aplicabilidade:
• sistemas interativos de pequeno / médio porte;
• partes de grandes sistemas;
• para sistemas de vida curta.
Modelo Evolutivo
13
14
15
28/02/2025
16
Desenvolvimento Modular
• Baseado na reutilização sistemática:
• sistemas integrados com componentes existentes (bibliotecas) ou 
COTS (Commercial Off the Shelf).
• Estágios:
• análise de componentes;
• modificação de requisitos;
• desenho com reutilização;
• desenvolvimento e integração.
• Abordagem de utilização crescente devido à padronização de 
componentes.
17
Desenvolvimento Modular
18
Interação
• Requisitos sempre evoluem / se alteram no curso de um 
projeto.
• Retrabalho faz parte do processo, tanto maior quanto maior o 
projeto.
• Interação aplicável a qualquer modelo genérico.
• Duas possíveis estratégias:
• desenvolvimento incremental;
• desenvolvimento em espiral.
16
17
18
28/02/2025
19
Incremental
• Processo incremental.
• Desenvolvimento e entrega em etapas.
• Funcionalidades entregues em partes.
• Requisitos são priorizados.
• Entrega programada segundo a prioridade definida.
• Durante o processo incremental, os requisitos ficam 
“congelados”.
20
Incremental
21
• Vantagens:
• percepção de valor a cada processo incremental;
• disponibilidade de funcionalidade antecipada;
• primeiros incrementos funcionam como protótipo para posteriores;
• baixo risco de falha do projeto;
• funcionalidades e módulos de maior prioridade são os mais testados.
Incremental
19
20
21
28/02/2025
22
Programação Extrema
• Estratégia baseada no desenvolvimento e entrega de 
pequenos incrementos.
• Melhoria de código contínua.
• Envolvimento de usuários.
23
Desenvolvimento Espiral
• Não utiliza sequência linear.
• Cada fase do processo é representada por um loop da espiral.
• Sem fases fixas: dependente da necessidade.
• Endereçamento explícito de riscos.
24
Desenvolvimento Espiral
22
23
24
28/02/2025
25
• Definição de objetivos:
• identificação dos objetivos específicos da fase.
• Identificação e mitigação de riscos:
• riscos analisados e gerenciados;
• plano de contingência;
• monitoração.
• Desenvolvimento e validação:
• modelo escolhido;
• qualquer dos modelos genéricos.
• Planejamento:
• revisão;
• planejamento próxima fase.
Desenvolvimento Espiral
26
Comparativo
• Interativo x Incremental
27
Atividades
• Especificação
• Desenho
• Implementação
• Validação
• Evolução
25
26
27
28/02/2025
28
Especificação
• Definição dos serviços requeridos e vínculos (constraints -
desenvolvimento e operação).
• Paradigma de engenharia:
• estudo de viabilidade;
• identificação de requisitos;
• análise de requisitos;
• especificação de requisitos;
• validação de requisitos
Engenharia de Requisitos
29
Engenharia de Requisitos
30
Desenho e Implementação
• Conversão das especificações / documentação em um sistema 
operacional.
• Software:
• estruturação / codificação que atue como o especificado.
• Implementação:
• converter a codificação em algo executável.
• Atividades fortemente relacionadas
• Podem ser intercaladas.
28
29
30
28/02/2025
31
• Atividades de Desenho:
• desenho da arquitetura;
• especificação abstrata;
• desenho de interfaces;
• desenho de componentes;
• estrutura de dados;
• algoritmo.
• input: Especificação de Requisitos.
Desenho e Implementação
32
Métodos Estruturados
• Estratégia sistemática de desenvolvimento.
• Documentação usual via modelos gráficos.
• Modelos:
• objetos;
• seqüencial;
• transição de estados / fases;
• estrutural
• fluxo de dados.
33
Processo de Testes
• Debug:
• remoção de erros do código;
• atividade pessoal: não existe processo genérico;
• procedimento de testes (básico) para identificação de falhas.
• Verificação e Validação (V&V):
• adequação às especificações;
• atende requisitos;
• envolve verificações, revisões e testes;
• dados de teste: resultado conhecido.
31
32
33
28/02/2025
34
Processo de Testes
35
• Unitário ou componente:
• teste individual independente
• podem ser funções, objetos ou agrupamentos coerentes dessas 
entidades.
• Sistema:
• teste como um todo;
• foco em novas funcionalidades / propriedades.
• Validação:
• teste com dados reais e resultado conhecido.
Processo de Testes
36
Fases
34
35
36
28/02/2025
37
Evolução de SW
• SW é flexível e pode ser alterado.
• Alterações no negóciolevam a alterações nos sistemas que o 
suportam.
• Embora os conceitos de Manutenção (Evolução) e 
Desenvolvimento sejam distintos, isso é irrelevante já que cada 
vez menos sistemas são completamente novos.
38
Evolução de SW
39
Rational Unified Process (RUP)
• Derivado dos trabalhos com UML.
• Usualmente descrito sob 3 perspectivas:
• dinâmica: evolução temporal das fases;
• estática: atividades;
• prática: sugestão de melhores práticas.
37
38
39
28/02/2025
40
RUP: Fases
• Introdução (Inception):
• elaboração do “Business Case”.
• Elaboração (Elaboration):
• desenvolvimento e entendimento do domínio e arquitetura do sistema.
• Construção (Construction):
• desenho, programação e teste.
• Transição (Transition):
• Implementação no ambiente de produção.
41
RUP: Boas Práticas
• Desenvolvimento interativo.
• Gerência de requisitos.
• Arquitetura modular.
• Modelagem visual.
• Qualidade.
• Change Management.
42
RUP: Fluxo Estático
DescriçãoFluxo
Processos de negócio modelados utilizando-se 
casos de uso.
Modelo de 
negócio
Identificação de stakeholders e casos desenvolvidos 
para modelar requisitos.
Requisitos
Modelo criado e documentado utilizando-se 
modelos de arquitetura, de componentes, de objetos e 
sequenciais.
Análise e 
desenho
Componentes implementados e adequados a 
subsistemas. Geração automática de código / 
documentação a partir de modelos de desenho ajudam 
em acelerar esta etapa.
Implementação
40
41
42
28/02/2025
43
RUP: Fluxo Estático (cont.)
DescriçãoFluxo
Processo interativo paralelo à implementação. Teste de 
sistema segue o final da implementação.
Teste
Versão do sistema criada, distribuída e instalada / configurada.Deployment
Gerência de alterações ao sistema. Disciplina própria.
Gerência de 
configuração e 
alteração
Gerência de desenvolvimento de sistemas. Disciplina própria.
Gerência de 
projeto
Disponibilizar ferramentas apropriadas ao time de 
desenvolvimento.
Ambiente
44
CASE: Tecnologia
• Melhoria e avanços nos processos:
• longe do prometido;
• necessário criatividade, algo não facilmente automatizado.
• Engenharia de Software é uma atividade grupal (interação), algo 
não facilmente integrado.
45
CASE: Classificação
• Diferentes tipos de ferramentas CASE e seu suporte.
• Funcional:
• função específica que suportam.
• Processual:
• atividades de processo que suportam.
• Integração:
• organização em unidades integradas.
43
44
45
28/02/2025
46
CASE: Funcional
ExemplosFerramenta
PERT, estimativas, planilhas.Planejamento
Editores de texto, diagramadores.Edição
Tracking de requisitos, sistemas de controle de alterações.Change Management
Gerenciador de versões, geradores de sistemas.
Gerência de 
Configuração
Linguagens de alto nível, gerador de U.I.Prototipação
Editores de desenho, dicionário de dados, geradores de 
código.
Metodologia
47
CASE: Funcional (cont.)
ExemplosFerramenta
Compiladores, interpretadores.Linguagem
Gerador de referências cruzadas, analisadores estáticos e 
dinâmicos.
Análise de Programa
Geradores de dados de teste, comparador de arquivos.Teste
Sistemas interativos de debug.Debugger
Layout de página, editores de imagem.Documentação
Sistemas de referência cruzada, programas de 
reestruturação.
Reengenharia
48
CASE: Atividades
V & VImplementaçãoDesenhoEspecificação
xReengenharia
xxteste
xxdebug
xxanálise programática
xxprocessamento de 
linguagem
xxsuporte de 
metodologia
xxprototipação
xxgerência de 
configuração
xxxxgerência de alteração
xxxxdocumentação
xxxxedição
xxxxplanificação
46
47
48
28/02/2025
49
CASE: Integração
• Ferramentas:
• suporte a tarefas individuais (ex.: editor texto).
• Plataforma:
• suporte a fases (ex.: desenho). Usualmente inclui ferramentas 
integradas.
• Ambiente:
• suporte a (quase) todo o processo. Usualmente inclui várias 
plataformas integradas.
50
Pontos Chave
• Processos de software: atividades da produção e manutenção 
de sistemas.
• Paradigmas de software são representações abstratas desses 
processos.
• Atividades genéricas comum aos modelos:
• especificação
• desenho
• implementação
• validação
• manutenção.
51
• Modelos genéricos descrevem a organização dos processos 
(ex.: Cascata).
• Processos interativos: ciclo de atividades.
• Engenharia de requisitos: processo de obtenção / validação / 
documentação da especificação de um sistema.
• Processos de Desenho e Implementação transformam uma 
especificação e um sistema executável.
Pontos Chave
49
50
51
28/02/2025
52
• Validação:
• verificação que o sistema atende às especificações e aos requisitos 
dos usuários.
• Manutenção (Evolução):
• modificações após entrada em produção.
• RUP:
• processo genérico que separa as atividades de fases.
• CASE:
• suporte às atividades de desenvolvimento.
Pontos Chave
53
52
53