Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
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