SSC - 5764

Engenharia de Software

Prof. Paulo C. Masiero

Processo de Software: Fases ou
Subprocessos
Análise de Sistema Processo pelo
DEFINIÇÃO qual os
Análise de Requisitos
requisitos do
software são
traduzidos
CONSTRUÇÃO Projeto
Projeto
para uma
representação
do software que
permite sua
realização
MANUTENÇÃO física.
2
 Modelo de
Informação Modelo
Comportamental
Modelo
Funcional
Projeto de Interface
Outros
Requisitos Projeto Projeto
Arquitetural

Projeto de
Dados
Codificação
Programas

Projeto Software
Procedimental Teste Integrado e
Validado

3
Ponto de Vista Técnico
DADOS: o modelo de domínio da informação é
transformado nas estruturas de dados que serão exigidas
para implementar o software.

ARQUITETURAL: o relacionamento entre os grandes

componentes estruturais do programa é definido.
INTERFACE: os mecanismos de interação e layout para a
interação homem-máquina são estabelecidos.
PROCEDIMENTAL: os componentes estruturais são
transformados em uma descrição procedimental do
software.
4
Ponto de Vista Gerencial

PROJETO PRELIMINAR: preocupa-se com a

transformação dos requisitos do software em
uma arquitetura de software e de dados.

PROJETO DETALHADO: concentra-se nos

aprimoramentos da representação arquitetural
que levam à estrutura de dados detalhada e às
representações algorítmicas do software.

5
 Projeto preliminar
Projeto detalhado

Projeto procedimental

Projeto de interface

Projeto arquitetural

Projeto de dados

6
 Fomentar a qualidade durante o processo de
desenvolvimento.

 Fornecer representações do software que podem

ser avaliadas quanto à qualidade.

 Traduzir com precisão os requisitos de um cliente

num produto de software finalizado.

7
 Sistema instável.
Manutenção
Falhará quando pequenas mudanças Manutenção
forem feitas. Difícil de testar.
Qualidade não pode ser verificada
Teste
até um ponto tardio do processo
de desenvolvimento. Teste
Implementação
Implemen-
Projeto tação

COM projeto
SEM projeto

8
 Modelo de
Modelo
Informação
Comportamental
Modelo Projeto de Dados
Funcional Objetivo
Outros Projeto de Interface
Requisitos Projeto Projeto Selecionar
Arquitetural
representações lógicas
Projeto dos dados (estruturas de
de Dados Codificação
dados), identificados
Projeto Programas
durante a fase de
Procedimental especificação dos
Software
Teste Integrado e
requisitos.
Validado

9
ESTRUTURA DE DADOS: é uma representação do
relacionamento lógico entre elementos de dados
individuais.

 Determina a organização, métodos de acesso, grau

de associatividade e alternativas de processamento
de informações.

10
Você moraria em uma casa em que
não há um projeto (planta) ?

11
 Modelo de
Modelo
Informação
Comportamental
Modelo Projeto Arquitetural
Funcional Objetivo
Outros Projeto de Interface
Requisitos Projeto Projeto Desenvolver uma
Arquitetural
estrutura modular do
Projeto sistema e representar as
de Dados Codificação relações de controle
Projeto entre os módulos.
Programas
Procedimental Software
Teste Integrado e
Validado

12
 O projeto arquitetural une a estrutura de programa
e a estrutura de dados, definindo interfaces que
possibilitam que os dados fluam pelo programa.

13
 Propriedades que devem ser especificadas
como parte de um projeto arquitetural:

◦ Propriedades estruturais: este aspecto da

representação do projeto arquitetural define os
componentes do sistema (como módulos, objetos)
e a maneira pela qual esses componentes são
empacotados e interagem entre si.

14
 Propriedades que devem ser especificadas
como parte de um projeto arquitetural:

◦ Propriedades extra-funcionais: a descrição do

projeto arquitetural deve cuidar de como a
arquitetura do projeto alcança os requisitos de
desempenho, capacidade, confiabilidade,
segurança, adaptabilidade, e outros requisitos não
funcionais do sistema.

15
 Propriedades que devem ser especificadas
como parte de um projeto arquitetural:

◦ Famílias de sistemas relacionados: o projeto

arquitetural deve ter a capacidade de reusar blocos
de construção arquitetural.

16
 O projeto arquitetural pode ser representado
usando-se um ou mais modelos:
◦ Modelo estrutural: representa a arquitetura como
uma coleção organizada de componentes de
programa.
◦ Modelo de arcabouço (framework): aumenta o nível
de abstração de projeto por meio de tentativas de
identificar padrões de projeto arquitetural
repetidos, encontrados em tipos de aplicações
similares.

17
 O projeto arquitetural pode ser representado
usando-se um ou mais modelos:
◦ Modelo dinâmico: cuida dos aspectos
comportamentais da arquitetura do programa,
indicando como a estrutura ou configuração do
sistema pode mudar em reação a eventos externos.

◦ Modelo de processo: focaliza o projeto de negócios

ou processo técnico que o sistema precisa atender.

18
 O projeto arquitetural pode ser representado
usando-se um ou mais modelos:

◦ Modelo funcional: pode ser usado para representar

a hierarquia funcional do sistema.

19
 CONCEITOS
 Abstração
 Refinamento
 Modularidade
 Ocultação da Informação
 Independência Funcional
 Arquitetura
 Particionamento Estrutural

20
ABSTRAÇÃO: possibilita que o projetista
represente os procedimentos, os dados e o
controle em vários níveis de detalhes.

Uma solução:
 é declarada em termos amplos usando-se a alto
linguagem do ambiente do problema
Nível
 é estabelecida usando-se uma terminologia de
orientada à implementação Abstração
 é estabelecida de uma forma que possa ser
diretamente implementada baixo

21
Abstração Procedimental: uma sequência de
instruções designadas que têm uma função
específica e limitada.

Ex: a palavra ´entrar´ numa porta

Sequência de passos procedimentais:
caminhe até a porta, aproxime-se e
segure a maçaneta, gire a maçaneta
e empurre a porta, etc...

22
Abstração de Dados: uma coleção designada
de dados que descrevem um objeto de
dados.

Ex: cheque de pagamento

Trata-se de uma coleção de muitas infor-
mações diferentes: nome da pessoa a
quem se paga, quantia bruta paga,
imposto retido, contribuição para a
previdência, etc.

23
Abstração de Controle: implica um mecanismo
de controle do programa sem especificar
detalhes internos.

Ex: semáforo de sincronização

Utilizado para coordenar atividades de um
sistema operacional.

24
REFINAMENTO passo a passo: é uma antiga
estratégia de projeto top-down (1971)

 A arquitetura de um programa é desenvolvida

refinando-se, sucessivamente, os níveis de
detalhes procedimentais.

25
 MODULARIDADE: o software é dividido em
componentes (módulos), que são integrados
para atender aos requisitos do problema.
◦ Dividir para conquistar.

 Um projeto modular reduz a complexidade,

facilita a mudança e resulta numa
implementação mais fácil ao estimular o
desenvolvimento paralelo de diversas partes de
um sistema.

26
MODULARIDADE
A submodularidade ou a
supermodularidade devem
É mais fácil resolver um
ser evitadas.
problema complexo
quando ele é dividido em COMO DEFINIR UM TAMANHO
partes. DE MÓDULO APROPRIADO?
Dividir indefinidamente torna
o problema infinitamente
pequeno?
NÃO

27
28
OCULTAÇÃO DE INFORMAÇÕES: o conceito de
modularidade leva o projetista de software a
uma questão fundamental:
“Como decompor uma solução de software para
obter o melhor conjunto de módulos? ”

O princípio da "ocultação de informações"

sugere que os módulos sejam "caracterizados
pelas decisões de projeto que (cada módulo)
esconde de todos os outros".

29
 Os módulos devem ser especificados e
projetados de tal forma que as informações
(procedimentos e dados) contidas num módulo
sejam inacessíveis a outros módulos que não
tenham necessidade de tais informações.

 A ocultação implica em uma modularidade tal

que um conjunto de módulos independentes
comunicam entre si somente aquelas
informações que são necessárias para se obter
a função do software.

30
INDEPENDÊNCIA FUNCIONAL: produto direto da
modularidade e do conceito de ocultação da
informação.
 Alcançada desenvolvendo-se módulos com
função "com um só propósito" e "aversão" a
interações excessivas com outros módulos;
 Um software com módulos independentes é
mais fácil de ser desenvolvido e mais fácil de
ser mantido => fundamental para um bom
projeto.

31
A INDEPENDÊNCIA FUNCIONAL é medida
usando-se dois critérios qualitativos:

COESÃO

ACOPLAMENTO

32
A INDEPENDÊNCIA FUNCIONAL é medida
usando-se dois critérios qualitativos:

COESÃO COESÃO
Medida da força
funcional relativa
ACOPLAMENTO de um módulo.
Pode ser vista como
a força que mantém unidos
os elementos de um módulo.

33
A INDEPENDÊNCIA FUNCIONAL é medida
usando-se dois critérios qualitativos:

COESÃO
ACOPLAMENTO
É o grau de ACOPLAMENTO
interdependência
entre os módulos.

34
 PARTICIONAMENTO ESTRUTURAL: a estrutura do
programa deve ser particionada
horizontalmente e verticalmente
 particionamento horizontal: Função 3
Função 1
define três partições:
entrada, transformação de
dados (processamento) e
saída.

Função 2 35
 PARTICIONAMENTO ESTRUTURAL: a estrutura do
programa deve ser particionada
horizontalmente e verticalmente
 particionamento vertical: Função 3
Função 1
módulos de nível mais Módulos de
alto devem realizar tomada
funções de controle; os de decisão
módulos de nível mais
baixo devem realizar as
tarefas de entrada,
processamento e saída. Módulos
`trabalhadores´
Função 2 36
ARQUITETURA DE SOFTWARE é a estrutura
hierárquica de componentes de programa
(módulos), o modo pelo qual estes
componentes interagem e as estruturas de
dados que são usadas pelos componentes.

37
Projeto Arquitetural: ARQUITETURA DO
SOFTWARE

Princípios básicos de projeto para arquiteturas

modulares:
(1) unidades modulares;
(2) poucas interfaces;
(3) interfaces pequenas (fraco acoplamento);
(4) interfaces explícitas;
(5) ocultação de informações.

38
Projeto Arquitetural: ARQUITETURA DO
SOFTWARE

de projetoaos
Correspondem
Princípios básicos módulos
para do sistema.
arquiteturas
modulares:
(1) unidades modulares;
(2) poucas interfaces;
(3) interfaces pequenas (fraco acoplamento);
(4) interfaces explícitas;
(5) ocultação de informações.

39
Projeto Arquitetural: ARQUITETURA DO
SOFTWARE
Para conseguir baixo acoplamento:
o número de interfaces entre os
módulos e a quantidade de informações
Princípios básicos de projeto para arquiteturas
que se movimentam por uma interface
modulares: devem ser minimizados.

(1) unidades modulares;

(2) poucas interfaces;
(3) interfaces pequenas (fraco acoplamento);
(4) interfaces explícitas;
(5) ocultação de informações.

40
Projeto Arquitetural: ARQUITETURA DO
SOFTWARE

Princípios básicos de projeto para arquiteturas

modulares: Quando os módulos precisam se
comunicar, eles devem fazê-lo de
(1) unidades modulares;
uma maneira óbvia e direta.
(2) poucas interfaces;
(3) interfaces pequenas (fraco acoplamento);
(4) interfaces explícitas;
(5) ocultação de informações.

41
Projeto Arquitetural: ARQUITETURA DO
SOFTWARE

Princípios básicos de projeto para arquiteturas

modulares:
(1) unidades modulares;
(2) poucas interfaces;
Todas as informações sobre um módulo
(3) interfaces pequenas (fraco
são escondidas acoplamento);
do acesso externo.
(4) interfaces explícitas;
(5) ocultação de informações.

42
 Modelo de
Modelo
Informação
Comportamental
Modelo
Funcional
Outros Projeto de Interface Projeto Procedimental
Requisitos Projeto Projeto Objetivo
Arquitetural

Projeto
Especificar os detalhes
de Dados Codificação dos algoritmos de forma

Projeto Programas não ambígua.

Procedimental Software
Teste Integrado e
Validado

43
PROCEDIMENTO DE SOFTWARE: focaliza os
detalhes de processamento de cada módulo
individualmente.

O Procedimento deve oferecer uma

especificação precisa do processamento
(sequência de eventos, pontos de decisão,
operações repetitivas e até mesmo estrutura e
organização de dados).

44
 Linguagem de projeto de programa
(inglês estruturado ou pseudocódigo)

 É uma linguagem híbrida no sentido

de que ela usa o vocabulário de uma
linguagem (isto é, inglês) e a sintaxe
global de outra (isto é, uma
linguagem de programação
estruturada).

45
 Características:
1- uma sintaxe fixa de palavras-chave que forneçam todas as
construções estruturadas, declarações de dados e
características de modularidade.
2- uma sintaxe livre de linguagem natural que descreva as
características de processamento.
3- facilidades de declaração de dados que incluam tanto as
estruturas de dados simples como as complexas.
4- a definição de subprogramas ou técnicas de chamada que
apóiem vários modos de descrição de interfaces.

46
 Nas fases iniciais, costuma-se usar
declarações que informam
◦ Pré-condições
◦ Pós-condições
 É uma linguagem baseada em lógica
matemática
 Usado por exemplo em casos de uso e
contratos.

47
 Modelo de Projeto de Interface
Modelo
Informação
Comportamental Objetivo
Modelo
Funcional
Outros Projeto de Interface Estabelecer os
Requisitos Projeto Projeto mecanismos de
Arquitetural interação e layout para a
Projeto interação homem-
de Dados Codificação máquina
Projeto Programas
Procedimental Software
Teste Integrado e
Validado

48
 Processoiterativo, abrangendo as
atividades:
◦ Análise e modelagem do usuário, tarefa, ambiente.

◦ Projeto da interface.
 Tempo de resposta do sistema.
 Facilidades de ajuda ao usuário.
 Manipulação de informações de erro.
 Rotulação de comandos.

49
◦ Construção da interface.
 Ferramentas de projeto de interface e prototipagem.
 Fornecem componentes de software “pré-
empacotados” para criar uma interface com o usuário.

◦ Validação da interface.
 Determinar se o protótipo operacional da interface
satisfaz as necessidades do usuário.
 Dados qualitativos.
 Dados quantitativos.
 Experimentos de usabilidade
 Acessibilidade

50
 Regras de Ouro.
◦ Coloque o usuário no controle.
◦ Reduza a sobrecarga cognitiva do usuário.
◦ Faça a interface consistente.
◦ ...

51
 Modelo de
Informação Modelo
Comportamental
Modelo
Funcional
Projeto de Interface
Outros
Requisitos Projeto Projeto
Arquitetural

Projeto de
Dados
Codificação
Programas

Projeto Software
Procedimental Teste Integrado e
Validado

52
 SSC - 5764
Engenharia de Software

Profa. Ellen Francine