Paradigmas de Software

Transcrição

1 Paradigmas de Software Objetivos 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. Mar/11 2 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. Mar/11 3 1

2 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. Mar/11 4 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. Mar/11 5 Técnicas Básicas Principios 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. Mar/11 6 2

3 Modelo Clássico Mar/11 7 Modelo Clássico 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. Mar/11 8 Modelo Clássico 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. Mar/11 9 3

4 Modelo Clássico 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. Mar/11 10 Modelo Clássico 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. Mar/11 11 Modelo Clássico 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. Mar/

5 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. Mar/11 13 Modelo Evolutivo Mar/11 14 Modelo Evolutivo 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. Mar/

6 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. Mar/11 16 Desenvolvimento Modular Mar/11 17 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. Mar/

7 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. Mar/11 19 Incremental Mar/11 20 Incremental 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. Mar/

8 Programação Extrema Estratégia baseada no desenvolvimento e entrega de pequenos incrementos. Melhoria de código contínua. Envolvimento de usuários. Mar/11 22 Desenvolvimento Espiral Não utiliza seqüência linear. Cada fase do processo é representada por um loop da espiral. Sem fases fixas: dependente da necessidade. Endereçamento explícito de riscos. Mar/11 23 Desenvolvimento Espiral Mar/

9 Desenvolvimento Espiral 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. Mar/11 25 Especificação Desenho Implementação Validação Evolução Atividades Mar/11 26 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 Mar/

10 Engenharia de Requisitos Mar/11 28 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. Mar/11 29 Desenho e Implementação Atividades de Desenho: desenho da arquitetura; especificação abstrata; desenho de interfaces; desenho de componentes; estrutura de dados; algoritmo. input: Especificação de Requisitos. Mar/

11 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. Mar/11 31 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. Mar/11 32 Processo de Testes Mar/

12 Processo de Testes 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. Mar/11 34 Fases Mar/11 35 Evolução de SW SW é flexível e pode ser alterado. Alterações no negócio levam 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. Mar/

13 Evolução de SW Mar/11 37 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. Mar/11 38 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. Mar/

14 RUP: Boas Práticas Desenvolvimento interativo. Gerência de requisitos. Arquitetura modular. Modelagem visual. Qualidade. Change Management. Mar/11 40 RUP: Fluxo Estático Fluxo Descrição Modelo de Processos de negócio modelados utilizando-se negócio casos de uso. Identificação de stakeholders e casos Requisitos desenvolvidos para modelar requisitos. Modelo criado e documentado utilizando-se Análise e modelos de arquitetura, de componentes, de objetos desenho e seqüenciais. Componentes implementados e adequados a subsistemas. Geração automática de código / Implementação documentação a partir de modelos de desenho ajudam em acelerar esta etapa. Mar/11 41 RUP: Fluxo Estático (cont.) Fluxo Descrição Teste Processo interativo paralelo à implementação. Teste de sistema segue o final da implementação. Deployment Versão do sistema criada, distribuída e instalada / configurada. Gerência de Gerência de alterações ao sistema. Disciplina configuração e própria. alteração Gerência de projeto Gerência de desenvolvimento de sistemas. Disciplina própria. Ambiente Disponibilizar ferramentas apropriadas ao time de desenvolvimento. Mar/

15 CASE Computer Aided Software Engineering. Software que suporta o desenvolvimento e manutenção. Automação: editores gráficos: modelagem de sistemas; dicionário de dados: gerência de entidades; gerador gráfico de U.I.; debuggers; compilação / tradução automática. Mar/11 43 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. Mar/11 44 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. Mar/

16 CASE: Funcional Ferramenta Planejamento Edição Change Management Gerência de Configuração Prototipação Metodologia Exemplos PERT, estimativas, planilhas. Editores de texto, diagramadores. Tracking de requisitos, sistemas de controle de alterações. Gerenciador de versões, geradores de sistemas. Linguagens de alto nível, gerador de U.I. Editores de desenho, dicionário de dados, geradores de código. Mar/11 46 CASE: Funcional (cont.) Ferramenta Linguagem Análise de Programa Teste Debugger Documentação Reengenharia Exemplos Compiladores, interpretadores. Gerador de referências cruzadas, analisadores estáticos e dinâmicos. Geradores de dados de teste, comparador de arquivos. Sistemas interativos de debug. Layout de página, editores de imagem. Sistemas de referência cruzada, programas de reestruturação. Mar/11 47 CASE: Atividades reengenharia teste debug análise programática processamento de linguagem suporte de metodologia prototipação gerência de configuração gerência de alteração documentação edição planificação Especificação Desenho Implementação V & V Mar/

17 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. Mar/11 49 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. Mar/11 50 Pontos Chave 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. Mar/

18 Pontos Chave 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. Mar/11 52 Mar/