Prof. M.Sc.

Sílvio Bacalá Jr
www.facom.ufu.br/~bacala/ESOF
sbacala@gmail.com
1
Apresentação
 Sílvio Bacalá Jr.
 Engenharia Elétrica – UFU
 Pós em Tecnologia da Informação – UFPE
 Mestrado em Computação - UFU
 Engenharia de Software

2
3
4
Objetivo (1/1)

Conceituar PROCESSO E CICLO

DE VIDA, identificar e conceituar
suas FASES e MODELOS, e
avaliar seu efeito prático na
melhoria da QUALIDADE na
produção de software.

5
Estrutura (1/1)

 1. Introdução
 Software
 Engenharia de Software
 2. Processo de Desenvolvimento de Software
 3. CICLO DE VIDA de Desenvolvimento de Software
 4. Controle da qualidade do processo
 CMMI e MPS.BR.
 5. Conclusão

6
1. Introdução (1/3)

 Software [1]

+ +

Programas Documentação Dados

 Como Construir?
ENGENHARIA
Simplesmente DE SOFTWARE
“FAZER” OU www.sei.cmu.edu/
www.rspa.com/spi/
www.swebok.org
7
1. Introdução (2/3)

 Engenharia de Software [1]

 É a utilização de sólidos princípios de
ENGENHARIA
 a fim de se obter SOFTWARE
 de maneira ECÔNOMICA
 que seja CONFIÁVEL
 e que trabalhe EFICIENTEMENTE em
máquinas reais.

8
1. Introdução (3/3)

Engenharia de Software
Processo de Desenvolvimento de Software
Análise de Implemen- Implan-
Projeto Teste
Requisitos tação tação

Atividades - Garantia de qualidade; - Estimativas;

- Gerência de Configuração; - Revisões Técnicas Formais.
- Gerência de Riscos;
- Métricas; Outros
Processos
Contidos no
Processo
Principal
9
2. Processo de Software (1/2)

 É uma série de passos (um ROTEIRO).

 Para criar EM TEMPO um SOFTWARE de ALTA

QUALIDADE, sem estourar o ORÇAMENTO [1].

Motivação

10
2. Processo de Software (2/2)

 Como “escolher“ um processo? [6]

 As CARACTERÍSTICAS DA APLICAÇÃO (domínio
do problema, tamanho, complexidade etc);
 A TECNOLOGIA a ser adotada na sua construção
(paradigma de desenvolvimento, linguagem de
programação, mecanismo de persistência etc), a
organização;
 ONDE o produto será desenvolvido;
 O PERFIL DA EQUIPE de desenvolvimento.

11
3. Ciclo de Vida (1/13)

 Quando se “escolhe“ um processo [6] DEFINE-SE

um:
 Modelo de Ciclo de Vida (ou modelo de processo).
 É uma representação abstrata da estrutura
(“ESQUELETO“) de processo. Podem ser
decomposta
 Inclui algumas atividades principais. s em sub-
 A ordem de precedência entre elas. atividades!
 Opcionalmente, artefatos requeridos e produzidos.

12
3. Ciclo de Vida (2/13)

 Em geral, os ciclos de vida envolvem as seguintes

FASES :
 Planejamento
 Modelagem de Negócio
 Análise e Especificação de Requisitos
 Projeto
 Implementação
 Testes
 Entrega e Implantação
 Operação
 Manutenção

13
3. Ciclo de Vida (3/13)

 Planejamento
 Fornece uma estrutura que possibilita ao gerente
fazer estimativas iniciais de recursos, custos e
prazos;
 O escopo do software é estabelecido;
 Um plano de projeto deve ser elaborado
configurando o processo a ser utilizado;
 Esta atividade faz parte da gerência de projeto.

 Modelagem de Negócio
 Descrever o funcionamento da organização

14
3. Ciclo de Vida (4/13)

 Análise e Especificação de Requisitos

 O escopo do software é refinado;
 Descreve “o que“ o software deve fazer;
 Devem ser analisados o domínio do problema e o
domínio da solução.
 Projeto
 Utiliza a fase anterior como insumo;
 Envolve duas grandes etapas: projeto da
arquitetura do software e projeto detalhado.

15
3. Ciclo de Vida (5/13)

 Implementação
 O projeto é traduzido para uma para uma forma
passível de execução pela máquina.
 Testes
 Testes de unidade e documentação dos resultados;
 Integração dos componentes e teste do software
como um todo;
 Alguns modelos de processo prevêem a realização de
testes já nas primeiras etapas.

16
3. Ciclo de Vida (6/13)

 Entrega e Implantação
 O software deve ser instalado em ambiente
produção.
 Envolve
 Treinamento de usuários;
 Configuração do ambiente de produção;
 Conversão bases de dados (se necessário).
 Principal propósito desta fase:
 Realizase os Testes de Aceitação (estabelecer que o
software satisfaz os requisitos dos usuários).

17
3. Ciclo de Vida (7/13)

 Operação
 Após o teste de aceitãção, o software passa a ser
utilizado de fato em ambiente de produção.
 Manutenção
 Adaptativas
 Corretivas
 Evolutivas

18
3. Ciclo de Vida (8/13)

 Modelos de Ciclos de Vida [7]

3
abordagens
principais

19
3. Ciclo de Vida (9/13)

 Modelos Seqüenciais
 Organizam o processo em uma seqüência linear de
fases.
 Exemplo
 Waterfall (Cascata)
 Quando empregar
 Problema cujos requisitos
são muito bem definidos
 Apresenta alguns problemas

20
3. Ciclo de Vida (10/13)

 Modelos Incrementais
 Software produzido por incrementos (módulos);
 Incrementos
 Seu desenvolvimento segue o modelo sequencial;
 Exigem revisão do cliente;

Vantagens Problemas
Menor custo e tempo para Requisitos instáveis ou
entrega da 1ª versão; imcompletos geram muitas
Menor risco e nº de mudanças nos incrementos;
mudanças nos req. (pelo fato Gerência do projeto é mais
dos inc. serem menores que o complexa.
sw todo). 21
3. Ciclo de Vida (11/13)

 Modelos Incrementais
 Exemplo
 RAD (Rapid Application Development)
 Prima por um ciclo de desenvolvimento curto.

22
3. Ciclo de Vida (12/13)

 Modelos Iterativos
 Não se preocupa em entregar de versões
operacionais desde o primeiro ciclo;
 Geralmente produzem protótipos ou modelos.
 Versões operacionais são produzidas à medida em
que os requisitos vão ficando mais claros e
estáveis;
 Quando empregar
 Problemas muito complexos
 Requisitos são muito voláteis ou que não podem ser
totalmente especificados no início do desenvolvimento.

23
3. Ciclo de Vida (13/13)

 Modelos Iterativos (Evolutivos ou

Evolucionários)
 Exemplo: Modelo Espiral, RUP

24
5. Conclusão (1/1)

 Desenvolver software é um processo complexo;

 Sucesso depende de pessoas, de processos e
ferramentas;
 Existem vários modelos de processo:

 Todos têm pontos positivos e fracos;

 Todos têm fases genéricas em comum;

25
Referências (1/1)

 [1] PRESMAN, R. S. Engenharia de Software. 5ª Edição – Rio de Janeiro: Mc

Graw Hill, 2002.
 [2] MPS.BR. Guia Geral MPS.BR, disponível em http://www.softex.br/mpsbr.
 [3] CMMI. CMMI Web Page, disponível em
http://www.sei.cmu.edu/cmmi/cmmi.html.
 [4] NBR ISO/IEC 12207 – Tecnologia da Informação – Processos de Ciclo de
Vida, ABNT 1998, Emenda 1: 2002, Emenda 2: 2004.
 [5] ISO/IEC 15504 – Information Technology - Process Assessment, 2003/2004.
 [6] FALBO, R. A. Engenharia de Software. Notas de Aula, 2005, disponível em
http://www.inf.ufes.br/~falbo/.
 [7] LUCENA, F. N. Processo de Desenvolvimento de Software. Notas de
Aula, 2003, disponível em http://www.inf.ufg.br/~fabio/.

26
27
 Análise
Modelagem
Elicitação
Mundo Real

Soluções
Problemas

Gap Semântico

Mundo Computacional

Elicitação de Análise de Modelagem dos

Requisitos Requisitos Requisitos 28
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

29
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)

30
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

31
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

32
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.

33
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

34
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.

35
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.

36
Preâmbulo

37
Objetivos deste preâmbulo

 Visitar alguns conceitos de projeto de software

 Visão do SWEBOK
(Software Engineering Body of Knowledge)

38
 SWEBOK

Introdução
 O SWEBOK (Guide to the Software Engineering Body
of Knowledge) é um documento criado com a
finalidade de servir de referência em assuntos
considerados como essenciais na área de Engenharia
de Software e foi conduzido pelo IEEE (Institute of
Electrical and Electronics Engineers).

39
 SWEBOK

Introdução
 O porquê do guia?
 Necessidade da comissão de especialistas da área
de Engenharia de Software, visando uma
definição das fronteiras que a delimitam.
[SWEBOK, 2004].
 Subsídios para o reconhecimento da profissão de
Engenheiro de Software.

40
 SWEBOK

Introdução
 Onde surgiu o guia?
 O projeto SWEBOK foi iniciado em 1998 pela
SWECC (Software Engineering Coordinating
Committee).
 SWECC surgiu com a colaboração do IEEE
Computer Society e a Association for
Computing Machinery (ACM) com o intuito de
promover a profissionalização da engenharia de
software.

41
 SWEBOK

Objetivos do SWEBOK
 Caracterizar o conteúdo da disciplina de engenharia de
software;
• Estabelecer um conjunto apropriado de critérios e
normas para a prática profissional da Engenharia de
Software;
 Marcar as fronteiras entre a Engenharia de Software e
as demais disciplinas relacionadas;
 Prover uma fundação para certificação individual e
para licenciamento de profissionais.

42
 SWEBOK

SWEBOK 2004

43
 SWEBOK

SWEBOK 2004

44
 SWEBOK

SWEBOK 2010
 Adicionado material sobre Interfaces Humano-
Computador no design de software e Teste de
Software;
 Remoção da seção Ferramentas e métodos de
Engenharia de Software (distribuídos para outras áreas
de conhecimento);
 Redistribuição de matérias entre as áreas de
conhecimento.

45
 SWEBOK

Áreas de Conhecimento

46
 SWEBOK

Requisitos de Software
 Elicitação,
 Análise,
 Especificação e
 Validação de Requisitos;
 Sub-áreas:

Fundamentos dos Requisitos;

Processo de Requisitos;

Elicitação de Requisitos;

Análise de Requisitos;
 Especificação de Requisitos;

Validação de Requisitos;

Considerações Práticas.

47
 SWEBOK

Software Requirements

48
 SWEBOK

Software Requirements
 Fundamentos de requisitos de
software

 Definições Básicas
 Requisitos de Software
 Requisitos de Produto e Software
 Requisitos Funcionais e não Funcionais
 Propriedades Emergentes
 Requesitos quantificáveis
 Requisitos de Sistema e de Software

49
 SWEBOK

Software Requirements
 Requirements Process
 Apresenta os processos de requisitos de
software
 Orientando as outras cinco subáreas
 Mostra como o planejamento de requisitos se
encaixa com o processo completo de
planejamento de software
 Se preocupa com modelos de processo, atores,
suporte, gerenciamento de requisitos, melhoria
e qualidade do processo.

50
 SWEBOK

Software Requirements
 Requirements Elicitation
 Se preocupa com a origem dos requisitos
e como os engenheiros de software
podem coletar eles
 Primeiro estágio para o entendimento de
como o problema poderá ser resolvido.
 Identificar Fontes e definir as técnicas
para extrair requisitos dos stakeholders

51
 SWEBOK

Software Requirements
 Requirements Analysis
 Detectar e resolver conflitos entre
requisitos
 Descobrir os limites do sistema e como ele
deve interagir com o ambiente de
operação
 Aprimorar requisitos do sistema para
requisitos de software.
 Classificação dos requisitos

52
 SWEBOK

Software Requirements
 Requirements Specification
 Produção do documento de definição do
sistema
 Especificação dos requisitos do sistema e
derivação dos requisitos de software a partir
dos do sistema
 Especificação dos componentes de software

53
 SWEBOK

Software Requirements
 Requirements Validation
 Garantir o entendimento dos requisitos pelos
engenheiros de software
 Verificar se o documento de requisitos está
conforme com os padrões da organização,
estão consistentes e completos:
 Revisões
 Prototipação
 Testes de aceitação

54
 SWEBOK

Software Requirements
 Pratical Considerations
 Gerenciamento de mudança e manutenção
dos requisitos
 Atributos dos requisitos
 Acompanhamento dos Requisitos
 Avaliar o tamanho das mudanças em
requisitos,e estimar o custo do
desenvolvimento e manutenção da tarefa.

55
 SWEBOK

Projeto de Software
 Atividade do ciclo de vida da Engenharia de
Software em que os requisitos são analisados
a fim de produzir uma descrição da
estrutura interna do software. [Swebok,
2004].

56
 SWEBOK

Projeto de software
Subáreas
 fundamentos de projeto de software
 pontos chaves no projeto de software
 estrutura e arquitetura do projeto de
software
 análise e avaliação do projeto de software
 notações do projeto de software e
 estratégias e métodos para projeto de
software.
57
 SWEBOK

Software Design

58
 SWEBOK

Software Design Fundamentals

 Consiste em conceitos notações e
terminologias que norteiam e fazem
compreender os papéis e o escopo do
projeto de software.
 Compreender o contexto em que o
software se ajusta, para melhor
entender seu ciclo de vida

59
 SWEBOK

Software Design Fundamentals

 O processo de projeto de software consiste
em:
 Projeto arquitetural: como o SW é decomposto e
organizado em componentes
 Projeto Detalhado: descreve o comportamento
especifico dos componentes
 Técnicas para possibilitar o design, tais
como:
 Decomposição e  Abstração

Modularização  Coesão e

 Encapsulamento Acoplamento
 Separação de Interface e implementação
 Suficiência e completeza

60
 SWEBOK

Key Issues in Software Design

 Questões fundamentais devem ser tratadas
no projeto de software, algumas com relação
à qualidade que todos os softwares devem
possuir, como, por exemplo, o desempenho
 Como decompor o SW em processos, tasks e
threads e relacioná-los com eficiência,
atomicidade, sincronização e regras de
escalonamento.
 Como controlar o fluxo de controle, manusear
eventos temporais e reativos por meio de
mecanismos tais como invocação implícita e call-
backs.

61
 SWEBOK

Key Issues in Software Design

 Como distribuir o SW através do HW, como
comunicar os componentes, como o middleware
pode ser usado com SW heterogêneos.
 Como prevenir e tolerar falhas e manipular
condições excepcionais.
 Como estruturar e organizar a interação com
usuários e a apresentação das informações. Por
exemplo, usar o MVC.
 Como manipular dados persistentes.

62
 SWEBOK

Software Structure and Architecture

 Arquitetura de software é a descrição dos
subsistemas e componentes e as relações
entre eles. É a definição da estrutura interna
do SW.
 Diferentes visões de alto nível podem sem
descritas e documentadas: Visão lógica
(requisitos funcionais), de processos
(concorrência), física (distribuição) e de
desenvolvimento (como o projeto está
particionado em unidades de
implementação)
63
 SWEBOK

Software Structure and Architecture

 Estilos arquiteturais :pipes e filtros,
blackboard, cliente-servidor, three-tier, broker,
sistemas interativos (MVC, Presentation-
Abstraction-Control), sistemas adaptativos
(micro-kernel), batch, etc.
 Padrões de Projetos (creacionais, estruturais e
comportamentais)
 Reuso de software e componentes para
construir uma família de SW.

64
 SWEBOK

Software Design Quality

Analysis and Evaluation
 Inclui tópicos sobre qualidade e avaliação que estão
• Interessante é a distinção entre a qualidade de atributos:
especificamente relacionadas com a concepção do
•software.
perceptíveis
A maior em
partetempo deabrangidos
deles são execuçãode uma
forma• geral,
desempenho,
na KA de Qualidadesegurança,
de Software. disponibilidade,
funcionalidade,
 Vários usabilidade
atributos considerados importante para obter um
• nãoprojeto de software deem
perceptíveis boa tempo
qualidadede: execução
 manutenibilidade, portabilidade, testabilidade,
• rastreabilidade,
capacidadecorretude,
de mudança,robustez
portabilidade, reusabilidade,
integrabilidade, e testabilidade
• e os relacionados com as qualidades intrínsecas da
arquitetura
• integridade conceitual, exatidão, completude e
capacidade de construção

65
 SWEBOK

Software Design Quality

Analysis and Evaluation
 Técnicas para auxiliar a alcançar a qualidade de
software desejada
 Revisões de projeto de software, informais ou
formais, frequentemente realizadas em grupo,
técnicas para verificar a qualidade dos artefatos do
projeto
 Revisões arquiteturais, revisões de projeto e
inspeções, técnicas baseadas em cenários, trace de
requisitos
 Análise estática, formal ou semiformal, usada para
avaliar o projeto
 Análise de falhas e verificação cruzada
 Técnicas dinâmicas para avaliar o projeto
 simulação de desempenho e protótipo de
factibilidade 66
 SWEBOK

Software Design Quality

Analysis and Evaluation
 Medidas usadas para assegurar e
estimar quantitativamente vários
aspectos do projeto de software:
tamanho, estrutura ou qualidade.
Dependem da abordagem usada.
 Medições de projetos orientados a funções
(estruturadas)
 Medições de projetos Orientados a Objetos

67
 SWEBOK

Software Design Notations

 Notações e linguagens usadas para
descrever a organização estrutural do
projeto ou representar o comportamento do
software.
 Representação gráfica (maioria) de aspectos
estruturais do SW, seus componentes e como
estão interconectados
 Linguagens de descrição arquitetural (ADL) –
textual e quase sempre formal
 Diagramas de classes e objetos
 Diagramas de componentes: componentes de
um sistema e a realização das interfaces
68
 SWEBOK

Software Design Notations

 CRCs (Class responsability collaborator cards):
os nomes das classes, suas responsabilidades e os
nomes de seus componentes colaborativos.
 Diagramas de Implantação (Deployment): um
grupo de nós e seus inter-relacionamentos
visando modelar aspectos físicos do sistema.
 DER – diagrama de entidade-relacionamento:
modelo conceitual de dados
 Linguagem de descrição de interface (IDL):
linguagem usada para definir nomes e tipos de
operações exportadas dos componentes de
software

69
 SWEBOK

Software Design Notations

 Diagrama de estrutura de Jackson: descreve a
estrutura dos dados em termos de sequência,
seleção e iteração
 Gráficos estruturados: descreve a estrutura de
chamada dos programas - que módulo chama,
qual é chamado, por qual outro módulo.

70
 SWEBOK

Software Design Notations

 Notações e linguagens, gráfica ou textuais,
usadas para descrever a organização o
comportamento do software e
componentes. Usadas durante o projeto
detalhado.
 Diagramas de atividades: fluxo de controle
de atividade para atividade
 Diagramas de colaboração: interações que
ocorrem entre objetos, suas ligações e as
mensagens enviadas nelas

71
 SWEBOK

Software Design Notations

 Diagrama de fluxo de dados: fluxo de dados
entre processos
 Diagramas e tabelas de decisão: representam
combinações complexas de condições e
ações
 Fluxogramas estruturados: fluxo de controle
e ações associadas para serem realizadas
 Diagramas de sequência: interações entre
objetos com ênfase no ordenamento
temporal das mensagens

72
 SWEBOK

Software Design Notations

 Diagrama de transição de estados: fluxo de
controle de estado a estado em uma máquina
de estado
 Linguagem de especificação formal:
linguagem textual que usa notações
matemáticas básicas (lógica, sequência,
conjuntos, ...) para definir interfaces de
componentes de software e seu
comportamento, em termos de pré e pós
condições

73
 SWEBOK

Software Design Notations

 Linguagem de projeto de programas (PDLs)
e pseudocódigo: linguagem, tipo linguagem
de programação, usada para descrever, no
projeto detalhado, o comportamento de um
procedimento ou método

74
 SWEBOK

Software Design Strategies and

Methods
 Conjunto de estratégias que ajudam a guiar o
processo de design.
 Diferentemente das estratégias gerais, os
métodos são mais específicos, sugerindo e
provendo um grupo de notações a serem
usadas com o método, descrevendo o
processo e as linhas gerais para se utilizar o
método

75
 SWEBOK

Software Design Strategies and

Methods
 Alguns exemplo de estratégias gerais usadas
em projeto:
 Dividir para conquistar
 Stepwise refinement
 Top-down x bottom-up
 Abstração de dados e information hiding
 Uso de heurísticas
 Uso de patterns e pattern language
 Uso de abordagem iterativa e incremental

76
 SWEBOK

Software Design Strategies and

Methods
 Um dos métodos clássicos de projeto , no qual
se identificam as funções maiores do software,
depois elaborando-as e refinando -as de modo
top-down.
 O Projeto Estruturado segue a Análise
Estruturada, produzindo DFDs e especificação
de processos. Aplicam-se várias estratégias
(análise de transformação, análise de
transação) e heurísticas (fan-in, fan-out, efeito
de escopo, controle de escopo) para
transformar DFD em um diagrama de
estruturas
77
 SWEBOK

Software Design Strategies and

Methods
 Existem diversos métodos orientados a objetos
 Evoluções do projeto baseado em objetos,
meados de 1980 (nome = objetos, verbo =
método, adjetivo = atributo)
 Utilizam herança e polimorfismo como
elementos chaves.
 Projeto dirigido a responsabilidades surge
como abordagem alternativa

78
 SWEBOK

Software Design Strategies and

Methods
 Projeto centrado nos dados (Warnier-Orr ,
Jackson) tem foco nas estruturas de dados
manipuladas pelos programa ao invés das
funções que realizam.
 Primeiro se descreve a estrutura de dados de
entrada e de saída (usando Diagrama de
estrutura de Jackson, por exemplo) e em
seguida desenvolve-se uma estrutura de
controle de programa baseada naquela
estrutura de dadas.

79
 SWEBOK

Software Design Strategies and

Methods
 Componente de software é uma unidade
independente que possui interface bem
definida e dependências que podem ser
compostas e distribuídas independentemente.
 CBD utiliza questões relacionadas a prover,
desenvolver e integrar componentes
objetivando o reuso.

80
 SWEBOK

Software Design Strategies and

Methods
 Outras abordagens interessantes menos
convencionais como
 Métodos rigorosos e formais
 Métodos transformacionais

81
Engenharia de Software

82
 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”.

83
 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

O quê Como

documento de requisitos modelos e artefatos

de projeto
84
 Somerville

Projeto de software
Um modelo genérico de processo
Especificação Atividades de
de requisitos
projeto

Projeto Especificação Projeto de Projeto de Projeto Projeto de

arquitetural abstrata interface componente de dados algoritmos

Especificação Especificação
Arquitetura Especificação Especificação Especificação
de componentes de estruturas
do sistema de software de interface de algoritmos
de dados

Artefatos de
projeto

[Sommerville 2001]
85
 Início

Análise Projeto arquitetural

Projeto
Arquitetural

Entrada: Documentos Gerados na Análise

Projeto Documento de Especificação de
Detalhado
Requisitos

Implementação Objetivo: Determinar os principais

componentes do sistema e o
relacionamento entre eles
Testes

Saída: Diagrama Arquitetural (Alto Nível)

Entrega do
Produto

Fim

86
 Início

Análise Projeto arquitetural

Projeto
Arquitetural

Início do Projeto
Projeto
Detalhado
Arquitetural

Definição dos Componentes

Implementação (Arquitetura)

Fim do Projeto Arquitetural

Testes

Entrega do
Produto

Fim

87
 Início

Análise Projeto detalhado

Projeto
Arquitetural Entrada: Documentos Gerados na Análise
Documento de Especificação de
Projeto Requisitos
Detalhado
Objetivo: Determinar uma solução para o
sistema baseando-se nos
Implementação
documentos gerados na análise

Saída: 1) Diagrama de Classes (Nível de

Testes Projeto)
2) Diagramas de Seqüência (ator
e objetos)
Entrega do
Produto

Fim

88
 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

Fim do Projeto Detalhado

Entrega do
Produto

Fim

89
 SWEBOK
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
90
 SWEBOK

Projeto de software
Tópicos da Área de Conhecimento (KA)

91
Fundamentos de Projeto de SW
 Conceitos, noções e terminologia
que formam a base para
compreensão do papel e do escopo
do projeto de software.
 Conceitos
 Contexto do projeto de software
 Processo do projeto de software
 Princípios de projeto de software
Enabling techniques [Buschman96]

92
Princípios de Projeto de Software

93
 SWEBOK

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

94
 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

95
Fundamentos de Projeto de SW

96
97
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
98
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.

99
Abstração
 Princípio básico para lidar com a complexidade.

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

101
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.

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

103
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.

104
Encapsulamento / Information
Hiding

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

106
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.

107
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.
108
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.

109
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.

110
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.

111
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
112
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.

113
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

114
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.
115
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.
116
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.

117
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.

118
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.
119
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.

120
Separação de Objetivos
(Separation of Concerns)
 Permite a análise de diferentes aspectos de um
problema,
 analistas se concentram em um aspecto de cada vez.
 Fundamental para o entendimento de sistemas de
software complexos.
 Responsabilidades diferentes ou não-relacionadas
devem ser separadas em um sistema de software
 Ex: atribuir a diferentes componentes.
 Componentes que colaboram para a solução de uma
tarefa específica devem ser separados daqueles
envolvidos em outras tarefas. 121
Sugestões para Leitura
 Ian Sommerville, Software Engineering, Cap. 10, 2001
 Shari Pfleeger, Engenharia de Software, Cap. 5, 2003
 Grady Booch, Análise e Projeto OO,1991
 UML User Guide, 1999

122