Análise e Projeto de Software

Transcrição

1 Análise e Projeto de Software 1

2 Mundo Real Modelagem Elicitação Análise Problemas Soluções Gap Semântico Mundo Computacional Elicitação de Requisitos Análise de Requisitos Modelagem dos Requisitos 2

3 Projeto de software Perspectiva de processo Atividade do ciclo de vida na qual os requisitos de software são analisados para produzir uma descrição da estrutura interna do software que servirá de base para a sua construção 3

4 Projeto de software Perspectiva de resultado Descreve como um sistema é decomposto organizado em componentes e descreve as interfaces entre esses componentes Refina a descrição dos componentes até um nível de detalhamento que permita a sua construção. arquitetura do software (componentes e interfaces entre componentes) 4

5 Importância de Projeto de Software Detecção de problemas podem comprometer seu uso e até mesmo a conclusão do mesmo. Se forem detectados apenas na construção do software, correções podem ser custosas e parte do trabalho pode ser perdida 5

6 Fundamentos Conceitos, noções e terminologia que formam a base para compreensão o papel e o escopo do projeto de software. Conceitos Contexto do projeto de software Processo do projeto de software Princípios do projeto de software 6

7 Conceitos Projeto como um problema wicked Software não é apenas um campo no qual projeto está inserido De maneira geral, projeto é visto como uma forma de resolver problemas. Conceito de wicked problem Um problema sem solução definitiva Importante para estabelecer os limites do projeto. 7

8 O contexto do projeto de software Projeto de software agrega atividades que se encaixam entre: análise de requisitos de software e construção de software 8

9 O processo do projeto de software Feito em dois passos: Projeto arquitetural ( top-level design ) : descrição da estrutura e organização do software e identificação de componentes e suas interfaces Projeto detalhado ( detailed design ): descrição detalhada de cada componente. Entrada: documento(s) de especificação de requisitos Saída: um conjunto de modelos e artefatos que documentam as principais decisões tomadas. 9

10 Resumindo... É a transformação de requisitos (de software), estabelecidos em termos relevantes ao domínio do problema, em uma descrição que explica como solucionar os aspectos do problema relacionados com software. 10

11 Análise e Projeto de Software Engenharia de Software 11

12 Projeto de software SWEBOK [IEEE ] o processo de definir a arquitetura, os componentes, as interfaces e outras características de um sistema ou componente, e o resultado de tal processo. 12

13 Projeto de software Perspectiva de processo SWEBOK Atividade que transforma uma descrição sobre o que se quer resolver (usando termos relevantes ao domínio do problema) em uma descrição que explica como resolver o problema O quê Como documento de requisitos modelos e artefatos de projeto 13

14 Somerville Projeto de software Um modelo genérico de processo Especificação de requisitos Atividades de projeto Projeto arquitetural Especificação abstrata Projeto de interface Projeto de componente Projeto de dados Projeto de algoritmos Arquitetura do sistema Especificação de software Especificação de interface Especificação de componentes Especificação de estruturas de dados Especificação de algoritmos Artefatos de projeto [Sommerville 2001] 14

15 Análise Início Projeto arquitetural Projeto Arquitetural Projeto Detalhado Implementação Testes Entrada: Documentos Gerados na Análise Documento de Especificação de Requisitos Objetivo: Determinar os principais componentes do sistema e o relacionamento entre eles Saída: Diagrama Arquitetural (Alto Nível) Entrega do Produto Fim 15

16 Análise Início Projeto arquitetural Projeto Arquitetural Projeto Detalhado Início do Projeto Arquitetural Implementação Definição dos Componentes (Arquitetura) Testes Fim do Projeto Arquitetural Entrega do Produto Fim 16

17 Análise Início Projeto detalhado Projeto Arquitetural Projeto Detalhado Implementação Testes Entrega do Produto Entrada: Documentos Gerados na Análise Documento de Especificação de Requisitos Objetivo: Determinar uma solução para o sistema baseando-se nos documentos gerados na análise Saída: 1) Diagrama de Classes (Nível de Projeto) 2) Diagramas de Seqüência (ator e objetos) Fim 17

18 Análise Início Projeto detalhado Projeto Arquitetural Início do Projeto Detalhado Projeto Detalhado Construção dos Diagramas de Classes (Nível de Projeto) Implementação Construção dos Diagramas de Seqüência (Ator e Objetos) Testes Entrega do Produto Fim do Projeto Detalhado Fim 18

19 Projeto de software Perspectiva de resultado Projeto arquitetural descrição da estrutura e organização de nível mais alto do software, e identificação de componentes e relacionamentos Projeto detalhado descrição de cada componente em nível de detalhe suficiente para permitir a sua construção estrutura e comportamento SWEBOK 19

20 Enabling techniques PRINCÍPIOS DE PROJETO DE SOFTWARE 20

21 Princípios de projeto de software SWEBOK Principle a basic truth or a general law that is used as a basis of reasoning or a guide to action. Oxford English Dictionary Princípios de projeto Noções consideradas fundamentais para diversas abordagens de projeto de software 21

22 Princípios gerais de projeto SWEBOK Abstração Encapsulamento e Information Hiding Acoplamento e coesão Modularidade e decomposição Separação de interesses Separação entre interface e implementação Suficiência, completeza e primitiveness 22

23 Conceitos de Projetos Abstração Ocultamento da informação Refinamento Modularidade Hierarquia de Controle Particionamento estrutural Estrutura de dados Procedimento de Software Independência Funcional Coesão e Acoplamento 23

24 Abstração Quando consideramos uma solução modular para qualquer problema, muitos níveis de abstração pode ser levantados. No nível mais alto de abstração, uma solução é enunciada em termos amplos usando a linguagem de ambiente do problema. Nos níveis mais baixos de abstração, uma orientação procedimental é adotada. 24

25 Abstração Princípio básico para lidar com a complexidade. [Booch 2591]

26 Refinamento Um programa é desenvolvimento pelo refinamento sucessivo de níveis de detalhes procedimentais. Refinamento é na verdade um processo de elaboração. Começamos com um enunciado da função(ou descrição da informação) que é definida em alto nível de abstração. Isto é, o enunciado descreve a função ou informação conceitualmente, mas não fornece qualquer informação sobre o funcionamento interno da função ou a estrutura interna da informação. O refinamento leva o projetista a elaborar o enunciado original, fornecendo mais e mais detalhes à medida que cada refinamento(elaboração) ocorre. 26

27 Abstração e Refinamento Abstração e refinamento são conceitos complementares. A abstração permite ao projetista especificar procedimentos e dados e ainda suprimir detalhes de baixo nível. O refinamento ajuda o projetista a revelar detalhes de baixo nível à proporção que o projeto progride. Ambos os conceitos ajudam o projetista a criar um modelo completo de projeto à medida que o projeto evolui. 27

28 Modularidade O software é dividido em partes chamadas de módulos nomeados separadamente e endereçaveis, integrados para satisfazer os requisitos do problema. 28

29 Ocultamento da Informação Ocultação dos detalhes internos da implementação de um módulo (ou componente) dos seus clientes. Implica que a efetiva modularidade pode ser conseguida pela definição de um conjunto de módulos independentes que informam uns aos outros apenas o necessário para realizar uma função do software. Para evitar acoplamento entre componentes, o cliente deve conhecer somente a Interface de seus fornecedores, ou seja, a assinatura de suas operações. 29

30 Encapsulamento / Information Hiding [Booch 3091]

31 Abstração X Ocultamento Abstração ajuda a definir as entidades procedimentais(ou informacionais) que constituem o software. Ocultamento define e impõe restrições de acesso, tanto a detalhes de processamento dentro de um módulo quanto a qualquer estrutura de dados local usada pelo módulo. 31

32 Hierarquia de Controle Hierarquia de controle, também chamada estrutura de programa, representa a organização dos componentes de programa(módulos) e implica uma hierarquia de controle. 32

33 Particionamento estrutural Se o estilo arquitetural de um sistema hierárquico, as estruturas do programas podem ser particionadas tanto horizontalmente quanto verticalmente. Particionamento horizontal, define ramos separados da hierarquia modular para cada função principal do programa Particionamento vertical, sugere que o controle(tomada de decisão) e o trabalho sejam distribuídos de maneira descendente na estrutura do programa. Os módulos de nível alto devem desempenhar funções de controle e fazer pouco trabalho de processamento real. Módulos que se situam abaixo na estrutura devem ser os trabalhadores, realizando todas as tarefas de entrada, de computação e de saída. 33

34 Estrutura de Dados Estrutura de Dados é uma representação do relacionamento lógico entre elementos de dados individuais. Como a estrutura da informação vai invariavelmente afetar o projeto procedimental final, a estrutura de dados é tão importante quanto a estrutura do programa para a representação da arquitetura de software. A estrutura de dados determina a organização, os métodos de acesso, o grau de associatividade e as alternativas de processamento da informação. 34

35 Procedimento de Software O procedimento de software focaliza os detalhes de processamento de cada módulo individualmente. O procedimento deve fornecer uma especificação precisa do processamento, incluindo sequencia de eventos, pontos exatos de decisão, operações repetitivas e até organização e estrutura de dados. 35

36 Independência funcional Decorrência direta da modularidade dos conceitos de abstração e ocultamento funcional Conseguida pelo desenvolvimento de módulos com função de finalidade única e uma aversão a interação excessiva com outros módulos. De outro modo: projetar software de maneira que cada módulo cuide de uma subfunção específica dos requisitos e tenha uma interface simples quando visto de outras partes da estrutura do programa. 36

37 Independência funcional Módulos independentes são mais fáceis de manter (e testar) : efeitos secundários causados por modificação de projeto ou código são limitados, a propagação de erros é reduzida e os módulos reusáveis são possíveis. Para resumir, independência funcional é a chave para um bom projeto, e o projeto é a chave da qualidade de software. Independência é medida usando dois critérios qualitativos: coesão e acoplamento 37

38 Modularização Coesão e Acoplamento Princípios introduzidos como parte do projeto estruturado. Acoplamento foca em aspectos de relacionamentos entre módulos, Coesão enfatiza a consistência interna de um módulo. 38

39 Coesão Um modulo coeso realiza uma única tarefa dentro de um procedimento de software, requerendo pouca interação com procedimentos que estão sendo realizados em outras partes de um programa. Um módulo coeso deveria (idealmente) fazer apenas uma coisa. Altamente coeso: Excelente. Baixa coesão: Problemas 39

40 Tipos de Coesão (em ordem decrescente) 1/3 Coesão Funcional: um módulo com coesão funcional contém elementos que contribuem para a execução de uma e apenas uma tarefa relacionada ao problema. Coesão Sequencial: um módulo sequencialmente coeso é aquele cujos elementos estão envolvidos em atividades tais que os dados de saída de uma atividade servem como dados de entrada para a próxima. Coesão Comunicacional: um módulo com coesão comunicacional é aquele cujos elementos contribuem para atividades que usem a mesma entrada ou a mesma saída. 40

41 Tipos de Coesão (em ordem decrescente) 2/3 Coesão Procedural: módulo cujos elementos estão envolvidos em atividades diferentes e possivelmente não relacionadas, mas nas quais o controle flui de uma atividade para a outra. Coesão Temporal: módulo cujos elementos estão envolvidos em atividades que estão relacionadas no tempo. Coesão Lógica: módulo cujos elementos contribuem para atividades da mesma categoria geral, onde a atividade ou as atividades a serem executadas são selecionadas fora do módulo. 41

42 Tipos de Coesão (em ordem decrescente) 3/3 Coesão Coincidental: um módulo coincidentemente coeso é aquele cujos elementos contribuem para atividade sem relação significativa entre si. Observação: o grau de similaridade de métodos pode ser visto como o maior aspecto de coesividade dos módulos. Se um módulo possui diferentes rotinas que operam sobre um mesmo conjunto de variáveis locais, o módulo é coeso. 42

43 Acoplamento Medida da interconexão entre módulos numa estrutura de software. Depende da complexidade da interface entre módulos, do ponto em que é feita entrada ou referência a um módulo e que dados passam através da interface. Lutamos por acoplamento mais baixo possível. Conectividade simples entre módulos resulta em software bem mais fácil de entender e menos propenso a efeito de propagação erros que ocorrem em um lugar se propagam por todo o sistema. 43

44 Tipos de Acoplamento (em ordem crescente) 1/2 Acoplamento de Dados: módulos que se comunicam por parâmetros. Acoplamento de Imagem: dois módulos são ligados por imagem se eles se referem à mesma estrutura de dados. Acoplamento de Controle: um módulo passa para o outro um grupo de dados (flags) destinado a controlar a lógica interna do outro. 44

45 Tipos de Acoplamento (em ordem crescente) 2/2 Acoplamento Comum: dois módulos possuem acoplamento comum se eles se referem à mesma área de dados. Acoplamento de Conteúdo: dois módulos apresentam acoplamento de conteúdo se um faz referência ao interior do outro: por exemplo, se um módulo desvia a seqüência de instruções para dentro do outro. 45