designer grafiico

1. Análise e Projeto de
Software
1

2. Elicitação de Modelagem dos
Requisitos Requisitos
Mundo Real
Mo
E
dlA
e
ic
ln
a
itá
a
glç
e
is
ã
m
e
o
Problemas
Soluções
Gap Semântico
Mundo Computacional
Análise de 2
Requisitos

3. Projetodesoftware
Perspectivadeprocesso
• 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. Projetodesoftware
Perspectivaderesultado
• 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ânciadeProjetode
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 processodo projetode 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. 11
Análise e Projeto de
Software
Engenharia de Software

12. SWEBOK
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

13. Projetodesoftware
Perspectivadeprocesso
• 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
SWEBOK
documento de requisitos modelos e artefatos 13
de projeto
Como
O quê

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

15. Projeto arquitetural
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)
15
Início
Análise
Projeto
Arquitetural
Projeto
Detalhado
Implementação
Testes
Entrega do
Produto
Fim

16. Início
Análise
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
16
Fim

17. Projeto detalhado
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)
17
Início
Análise
Projeto
Arquitetural
Projeto
Detalhado
Implementação
Testes
Entrega do
Produto
Fim

18. Início
Análise
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
Fim do Projeto Detalhado
18

19. Projetodesoftware
Perspectivaderesultado
• 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ÍPIOSDEPROJETODESOFTWARE 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. 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

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. 25
[Booch 91]
Abstração
• Princípio básico para lidar com a complexidade.

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
30
[Booch 91]

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ãoe
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. TiposdeCoesão(emordem
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. TiposdeCoesão(emordem
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. TiposdeCoesão(emordem
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. TiposdeAcoplamento(emordem
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. TiposdeAcoplamento(emordem
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