Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr. 01 - Introdução

1. Universidade Federal do Paraná Setor de Ciências ExatasDepartamento de InformáticaESPECIALIZAÇÃO EM INFORMÁTICA Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr. 01 - Introdução 01 - Introdução

2. Conteúdos 1. Considerações iniciais 2. Conceitos básicos 3. Engenharia de software 3.1. Princípios 3.2. Paradigmas 3.3. Interação da engenharia de software com outras áreas 4. Considerações finais 5. Exercícios Bibliografia 01 - Introdução

3. 1. Considerações iniciais Sistemas (“sistemas de software”) Papel cada vez mais importante Funcionamento correto ou incorreto = vida ou morte Espaçonaves, aeronaves, trens, carros, reatores nucleares, equipamentos hospitalares, contas bancárias (segurança de acesso, movimentação correta), ... Aplicações TÊM DE SER totalmente confiáveis! Cumprir requisitos integralmente Requisitos intransigentes Restrições de integridade Vasto conhecimento sobre a aplicação Interações software x ambiente adequadas 01 - Introdução

4. 1. Considerações iniciais (cont.) Construir (bons) produtos de software envolve: Compreender a complexidade dos produtos (cresc.) Gerenciar equipes multidisciplinares Obter informações precisas sobre os produtos a serem desenvolvidos Comunicação adequada Sincronizar e controlar atividades Paralelas Diversos profissionais Diversas equipes 01 - Introdução

5. 1. Considerações iniciais (cont.) Atividades essenciais (do início do desenvolvimento): Extração de requisitos (características do produto a ser desenvolvido) Complexa Baseada na comunicação entre equipes Representação adequada de requisitos Abstrações representativas das diferentes propriedades do sistema Notações formais / semiformais Planejamento e acompanhamento de atividades do projeto Controle do processo de desenvolvimento 01 - Introdução

6. 2. Conceitos básicos Sistema - do latim systema, reunião, grupo; “Conjunto de princípios reunidos de modo a formar um corpo de doutrina”; “Conjunto de partes coordenadas que concorrem para o atingimento de um resultado (conjunto de objetivos) ou para formar um conjunto”; “Conjunto de elementos, concretos ou abstratos, entre os quais se pode encontrar alguma relação”; “Conjunto, identificável e coerente, de elementos que interagem coesivamente, onde cada elemento pode ser um sistema”; (...) 01 - Introdução

7. 2. Conceitos básicos (cont.) Existe uma relação estrutural entre as partes componentes de um sistema Sistema x universo: fronteira conceitual Elementos internos Entidade relativamente autônoma e identificável Fortes interações entre si Elementos externos Fracas interações com elementos internos: devem ser fracas o suficiente para que possamos desprezá-las 01 - Introdução

8. 2. Conceitos básicos (cont.) Exemplo 1: Ecossistema de certa espécie de inseto que passa toda a sua vida em uma única árvore de determinada espécie. Fronteira conceitual Inseto (fisiologia, anatomia, hábitos reprodutivos, ciclo de vida, etc.) Árvore Fauna que habita a árvore Caracterização do habitat da árvore (clima, solo, vegetação na vizinhança, etc.) 01 - Introdução

9. 2. Conceitos básicos (cont.) Exemplo 2: Ecossistema floresta amazônica. Fronteira conceitual ? 01 - Introdução

10. 2. Conceitos básicos (cont.) Exemplo 2: Ecossistema floresta amazônica. Fronteira conceitual ? Flora Fauna Ocupação humana na floresta e em volta dela Utilização humana da floresta Aspectos climáticos, atmosféricos, etc. Etc. 01 - Introdução

11. 2. Conceitos básicos (cont.) Em sistemas de software, determinar a fronteira conceitual adequada É um passo decisivo no processo de concepção do sistema Permite separar componentes pertencentes Ao sistema Informações devem ser estudadas em detalhes Ao ambiente externo Interesse: interações com o sistema 01 - Introdução

12. 2. Conceitos básicos (cont.) Exemplo 3: Sistema de reservas de passagens aéreas de uma determinada companhia. Fronteira conceitual ? 01 - Introdução

13. 2. Conceitos básicos (cont.) Exemplo 3: Sistema de reservas de passagens aéreas de uma determinada companhia. Fronteira conceitual ? Companhia Dados sobre vôos: disponibilidades, reservas, cancelamentos, etc.) Se o sistema de software incluir reservas de hotéis, locação de carros, ofertas de pacotes turísticos, etc., a fronteira conceitual terá de ser ampliada para contemplar informações sobre ? Hotéis, locadoras de carros, agências de turismo, etc. 01 - Introdução

14. 2. Conceitos básicos (cont.) Produtos de software Sistemas de software entregues ao usuário com a documentação que descreve como instalá-lo e usá-lo Categorias de produtos de software Sistemas genéricos: produzidos e vendidos no mercado Sistemas específicos: produzidos sob encomenda especialmente para um determinado cliente Composição dos produtos de software Instruções (programas de computador) Estruturas de dados (manipuladas pelas instruções) Documentos (descrevem operações e uso do produto) 01 - Introdução

15. 2. Conceitos básicos (cont.) Processo de desenvolvimento de software Conjunto de atividades e resultados associados, com o objetivo de construir um produto de software Desenvolvimento Especificação de funcionalidades e restrições relativas à operacionalidade do software Produção do software conforme as especificações Validação Avaliação da aderência do software às necessidades do usuário Manutenção Correções, adaptações e ampliações para corrigir erros pós-entrega Atender novos requisitos / mudanças na tecnologia 01 - Introdução

16. 2. Conceitos básicos (cont.) No processo de desenvolvimento de software, modelos de processos (paradigmas) especificam: Quais atividades devem ser executadas Qual a ordem de execução das atividades Produtos de software podem ser construídos utilizando-se diferentes modelos de processos Alguns modelos são mais adequados que outros = f(tipo da aplicação) A escolha de um determinado modelo deve ser feita = f(produto a desenvolver) 01 - Introdução

17. 3. Engenharia de software Décadas de 60 e 70, desafio era desenvolver hardware que reduzisse custos de: Processamento Armazenagem de dados Década de 80, f(avanços na microeletrônica): Aumento do poder computacional Custo cada vez menor Processo de desenvolvimento e software: Cronogramas não eram cumpridos Custos excediam previsões Requisitos não eram cumpridos Etc. 01 - Introdução

18. 3. Engenharia de software (cont.) Desafio atual (há ± 3 décadas): Melhorar a qualidade Reduzir o custo do software Introduzir disciplina no desenvolvimento Engenharia de software Uma disciplina que reúne metodologias, métodos e ferramentas a serem utilizadas, desde a percepção do problema até o momento em que o sistema desenvolvido deixa de ser operacional, visando resolver problemas inerentes ao processo de desenvolvimento e ao produto de software. 01 - Introdução

19. 3. Engenharia de software (cont.) Objetivos da engenharia de software Auxiliar no processo de produção de software Processo para gerar produtos de alta qualidade Mais rapidamente Custo cada vez menor Problemas a tratar, f(atributos do processo e do produto de software) Complexidade, visibilidade, aceitabilidade, confiabilidade, alterabilidade, segurança, etc. Controle de tráfego aéreo / ferroviário: confiabilidade Controladores embutidos em eletrodomésticos (lavadoras de roupas / videocassetes): desempenho 01 - Introdução

20. 3. Engenharia de software (cont.) Engenharia de software Herda da engenharia o conceito de disciplina na produção de software Adota metodologias, com métodos que utilizam ferramentas automatizadas Métodos focalizam: Funções do sistema Objetos do sistema Eventos do funcionamento do sistema 01 - Introdução

21. 3.1. E. S. - Princípios Referem-se: Ao processo Ao produto final Descrevem propriedades gerais dos processos e produtos Processo correto => produto correto Produto almejado => escolha do processo (~ estratégia <=> estrutura organizacional) Princípios são insuficientes. Há a necessidade de: Metodologias Métodos Ferramentas 01 - Introdução

22. 3.1. E. S. - Princípios (cont.) Formalidade Abstração Decomposição Generalização Flexibilização 01 - Introdução

23. 3.1. E. S. - Princípios (cont.) Formalidade Desenvolvimento de software = atividade criativa Tende a ser imprecisa (não estruturada) Enfoque formal: produtos mais confiáveis, com custo controlado e melhor desempenho Não deve restringir a criatividade Projeto como seqüência de passos precisos Passos segundo metodologia e algum método formal, informal ou semiformal Adequar formalidade à necessidade (ex.: barco p/ rio x oceano) Efeitos: manutenção, reutilização, portabilidade e entendimento do software 01 - Introdução

24. 3.1. E. S. - Princípios (cont.) Abstração Processo de identificação de aspectos importantes de um determinado fenômeno, ignorando-se os detalhes Podem existir diferentes abstrações, f(visões e objetivos diferentes) Ex.: telefone sem fio P/ o usuário: manual c/ efeitos do acionamento dos diversos botões P/ o técnico de manutenção: manual c/ informações de componentes Ex.: programas Abstrações das funcionalidades do sistema Ex.: linguagens de programação Foco do programador no problema, não na máquina 01 - Introdução

25. 3.1. E. S. - Princípios (cont.) Decomposição Para lidar com a complexidade: Subdividir atividades do processo Atribuí-las a especialistas de diferentes áreas Várias formas (ex.: tempo) Ex.: controle de qualidade do processo, controle de qualidade do produto, especificação do projeto, implementação e manutenção Decomposição = separação de preocupações Pode-se decompor o produto Permite o trabalho em paralelo Permite a reutilização de componentes por outros componentes ou sistemas 01 - Introdução

26. 3.1. E. S. - Princípios (cont.) Generalização Solução de um problema potencialmente pode ser reutilizada Determinado componente pode ser utilizado em diversos pontos do mesmo sistema, ao invés de várias soluções especializadas Solução pode demorar mais (mais custosa) Avaliar custo e eficiência para decidir Conseqüência principal: portabilidade 01 - Introdução

27. 3.1. E. S. - Princípios (cont.) Flexibilização Envolve processo e produto Produto se altera = f(entendimento de requisitos) Processo ocorre passo a passo, de forma incremental Princípio necessário ao processo para que o produto possa ser modificado com facilidade Processo deve ter flexibilidade para permitir A reutilização de componentes A portabilidade do produto para diferentes plataformas computacionais 01 - Introdução

28. 3.2. E. S. - Paradigmas Modelos de processo de desenvolvimento que proporcionam: Ao gerente: Controle do processo de desenvolvimento de sistemas de software. Ao desenvolvedor: Obtenção de base para produzir, de maneira eficiente e eficaz, software que satisfaça os requisitos preestabelecidos. Objetivo: Diminuir os problemas inerentes ao processo de desenvolvimento de software 01 - Introdução

29. 3.2. E. S. - Paradigmas (cont.) Existem vários. Escolha de acordo com: Natureza do projeto e do produto Métodos e ferramentas Controles e produtos intermediários desejados Três mais utilizados: Ciclo de vida clássico Evolutivo Espiral 01 - Introdução

30. 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico Método sistemático e seqüencial O resultado de uma fase é entrada de outra Fases se sucedem linearmente (=> “cascata”) Fases estruturadas como um conjunto de atividades que podem ser executadas por pessoas diferentes simultaneamente 01 - Introdução

31. Análise e Especificação de Requisitos 3.2. E. S. - Paradigmas (cont.) Projeto Implementação e teste unitário 3.2.1. Ciclo de vida clássico (cont.) Integração e teste do sistema Operação e manutenção Os cinco passos 01 - Introdução

32. 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) • Decomposição = f(complexidade da aplicação) • aplicações simples e bem entendidas • menos formalidade • aplicações maiores e mais complexas • maior decomposição do processo • melhor controle • garantia dos resultados • Exemplos - aplicações p/usuários • não especialistas: fase p/projetar material especial de treinamento + treinamento p/entrada em operação • especialistas: manuais técnicos / telefonemas / S.A.U. 01 - Introdução

33. 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) • Análise e especificação de requisitos • Via consultas aos usuários • Identificar serviços, metas, restrições <=> qualidade = f(funcionalidade, desempenho, facilidade de uso, portabilidade, ...) • Especificar quais os requisitos, não como alcançá-los • Os requisitos especificados não devem restringir o desenvolvedor no projeto e implementação • Resultado da fase: documento de especificação de requisitos, que deve ser • analisado e confirmado pelos usuários • usado pelos desenvolvedores p/obtenção do produto 01 - Introdução

34. 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) • Análise e especificação de requisitos (cont.) • Documento de especificação de requisitos • instrumento de comunicação entre muitos indivíduos • inteligível, preciso, completo, consistente e s/ambigüidades • facilmente modificável = f(natureza evolutiva do software) • conciliar interesses dos usuários e do desenvolvedor • texto em linguagem natural • versão preliminar do manual do usuário 01 - Introdução

35. 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) • Análise e especificação de requisitos (cont.) • Outro resultado da fase: plano de projeto • usar princípios: abstração, decomposição e generalização • Documento de especificação de requisitos • funcionais: o que o produto deve fazer • não funcionais: • confiabilidade - disponibilidade, integridade, segurança • acurácia dos resultados • desempenho • problemas de ihc • restrições físicas e operacionais • questões de portabilidade • ... 01 - Introdução

36. 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) • Análise e especificação de requisitos (cont.) • Documento de especificação de requisitos • de desenvolvimento e manutenção • procedimentos de controle de qualidade • procedimentos de teste • prioridades de funções • mudanças prováveis • etc. 01 - Introdução

37. 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) • Projeto • Representação das funções do sistema em forma que possa ser transformada em um ou mais programas executáveis • Produto é decomposto em partes tratáveis: documento de especificação de projeto • descrição da arquitetura do software • o que cada parte deve fazer • relação entre as partes 01 - Introdução

38. 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) • Projeto (cont.) • Projeto preliminar x detalhado • Preliminar: estrutura de relações: usa, é_composto_de, herda_de, ... Detalhado: especificação das interfaces • Preliminar: decomposição lógica (alto nível) Detalhado: decomposição física do programa em unidades de programação • Preliminar: principais estruturas de dados Detalhado: algoritmos para cada módulo 01 - Introdução

39. 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) • Implementação e teste unitário • Transformação do projeto em programas (ou unidades de programas) • Resultado: • Coleção de programas implementados e testados, conforme os padrões da organização, se houverem • comentários • nomenclatura • número máximo de linhas por componente, ... • Teste unitário: verifica se cada unidade satisfaz suas especificações, normalmente conforme padrões • planos e critérios de testes, critério de completude, gerenciamento de casos de teste, respeito a padrões, ... 01 - Introdução

40. 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) • Integração e teste do sistema • Programas são integrados e testados como sistema • Freqüentemente não é feito de uma só vez, mas progressivamente, em conjuntos cada vez maiores, a partir de pequenos subsistemas, até que o sistema inteiro seja construído 01 - Introdução

41. 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) • Operação e manutenção • Fase mais longa do ciclo de vida • Entrega em dois estágios • grupo selecionado de usuários (feedback / alterações, caso necessário) • oficial • Manutenção • Atividade posterior à entrega do sistema aos usuários • Corretiva: correção de erros remanescentes • Adaptativa: adaptação a mudanças do ambiente • Evolutiva: mudanças nos requisitos, adição de características e qualidades ao software 01 - Introdução

42. 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) • Outras atividades • Paradigma clássico dividido em fases • Algumas atividades devem ser feitas • antes do início do ciclo de vida • durante todo o ciclo de vida • Estudo de viabilidade • Estágio crítico para o sucesso do projeto • Envolve custos e benefícios • Limitado por tempo (sob pressão) • Poucos recursos investidos • Identificar soluções alternativas, c/custos e datas de entrega • Conteúdo: problema, soluções (c/benef. esp., recursos nec. e datas de entrega 01 - Introdução

43. 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) • Outras atividades (cont.) • Documentação • Produtos ou resultados da maioria das fases são documentos • Mudança de fases depende destes documentos • Seguir padrões da organização p/sua elaboração • Verificação • Ocorre no teste unitário e do sistema • Também em outras fases • Processo de controle de qualidade via revisões e inspeções • Descoberta e remoção de erros deve ocorrer o quanto antes (antes da entrega do produto) 01 - Introdução

44. 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) • Outras atividades (cont.) • Gerenciamento • Meta: controlar o processo de desenvolvimento • Adaptação do ciclo de vida ao processo: rigidez / profundidade variáveis • Políticas: armazenagem, acesso e modificação de produtos / resultados intermediários; critérios de construção de versões diferentes e autorizações para acesso aos componentes de entrada e saída do banco de dados 01 - Introdução

45. 3.2. E. S. - Paradigmas (cont.) 3.2.1. Ciclo de vida clássico (cont.) • Contribuições geradas • Processo sujeito a disciplina, planejamento e gerenciamento • Implementações postergadas até o entendimento completo dos objetivos • Problemas • Rigidez (o desenvolvimento não é linear, é iterativo!) • Objetivo continua sendo a linearidade => • Previsibilidade • Facilidade de monitoramento • Planejamento orientado para data de entrega única, que pode ser bastante longa (“congelamento?”) 01 - Introdução

46. 3.2. E. S. - Paradigmas (cont.) 3.2.2. O paradigma evolutivo • Base • Desenvolvimento e implementação de produto inicial • Comentários e críticas dos usuários • Refinamento através de múltiplas versões • Desenvolvimento e validação paralelas (rápido feedback) • Dois tipos • Desenvolvimento exploratório • Protótipo descartável 01 - Introdução

47. 3.2. E. S. - Paradigmas (cont.) 3.2.2. O paradigma evolutivo (cont.) • Desenvolvimento exploratório • Objetivo: trabalhar junto do usuário para descobrir os requisitos • Incremental, até o produto final ser obtido • Adoção: dificuldade (ou impossibilidade) de obter especificação detalhada de requisitos a priori • Início • Partes mais bem entendidas • Evolução • Novas características adicionadas (sugeridas pelo usuário) 01 - Introdução

48. 3.2. E. S. - Paradigmas (cont.) Atividades Paralelas 3.2.2. O paradigma evolutivo (cont.) Versão inicial Desenvolvimento Versão intermediária Descrição Validação Versão final Desenvolvimento exploratório 01 - Introdução

49. 3.2. E. S. - Paradigmas (cont.) 3.2.2. O paradigma evolutivo (cont.) • Protótipo descartável • Objetivo: melhor definir requisitos do usuário/sistema • Fazer experimentos c/requisitos não bem entendidos • Envolve projeto, implementação e teste (não formais / completos) • Adoção • Usuário define objetivos / não define E-P-S • Desenvolvedor incerto sobre • Eficiência de algoritmo • Adaptação da aplicação a sistema operacional • Forma de IHC 01 - Introdução

50. 3.2. E. S. - Paradigmas (cont.) 3.2.2. O paradigma evolutivo (cont.) • Protótipo descartável (cont.) • Possibilita criar modelo do software a construir • Desenvolvedor pode perceber reações do usuário e obter sugestões para mudança / inovação • Usuário pode relacionar protótipo com requisitos • Operacionalização • Versão preliminar da especificação de requisitos • Construção do protótipo descartável • Uso pelos usuários => ok’s, alterações, sobras, faltas, etc. • Modificação do protótipo / uso pelos usuários • Repetir ciclo enquanto novas informações valerem $ e tempo • Especificação de requisitos definitiva = f(modificações) • Desenvolvimento 01 - Introdução