Análise e Projeto de Software

1

2

Problemas Soluções

Gap Semântico

Mundo Real

Mundo Computacional

Elicitação de

Requisitos

Elicitação

Modelagem dos

Requisitos Análise de

Requisitos

Modelagem Análise

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

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

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

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

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

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

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

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

Análise e Projeto de Software

Engenharia de Software

11

Projeto de software

[IEEE 610.12-90]

– “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

SWEBOK

Projeto de software Perspectiva de processo

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

13

SWEBOK

O quê Como

documento de requisitos modelos e artefatos

de projeto

Projeto de software

Um modelo genérico de processo

14

Projeto

arquitetural Especificação

abstrata

Projeto de

interface

Projeto de

componente Projeto

de dados

Projeto de

algoritmos

Arquitetura

do sistema

Especificação

de requisitos Atividades de

projeto

Artefatos de

projeto

Especificação

de software

Especificação

de interface

Especificação

de componentes

Especificação

de estruturas

de dados

Especificação

de algoritmos

[Sommerville 2001]

Somerville

Projeto arquitetural

15

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)

Início

Fim

Análise

Projeto Arquitetural

Projeto Detalhado

Implementação

Testes

Entrega do Produto

Projeto arquitetural

Início do Projeto Arquitetural

Fim do Projeto Arquitetural

Definição dos Componentes (Arquitetura)

16

Início

Fim

Análise

Projeto Arquitetural

Projeto Detalhado

Implementação

Testes

Entrega do Produto

Projeto detalhado

17

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)

Início

Fim

Análise

Projeto Arquitetural

Projeto Detalhado

Implementação

Testes

Entrega do Produto

Projeto detalhado

18

Início

Fim

Análise

Projeto Arquitetural

Projeto Detalhado

Implementação

Testes

Entrega do Produto

Fim do Projeto Detalhado

Início do Projeto Detalhado

Construção dos Diagramas de Classes (Nível de Projeto)

Construção dos Diagramas de Seqüência (Ator e Objetos)

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

19

SWEBOK

PRINCÍPIOS DE PROJETO DE SOFTWARE

Enabling techniques

20

Princípios de projeto de software

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

SWEBOK

Princípios gerais de projeto

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

SWEBOK

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

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

Abstração

Princípio básico para lidar com a complexidade.

25 [Booch 91]

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

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

Modularidade

O software é dividido em partes chamadas de módulos

– nomeados separadamente e

– endereçaveis,

integrados para satisfazer os requisitos do problema.

28

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

Encapsulamento / Information Hiding

30 [Booch 91]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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