Prof. M.Sc. Sílvio Bacalá Jr bacala/ESOF ...bacala/ESOF/01-IntroducaoSWEBOK.pdf · O projeto é...
-
Upload
trinhtuong -
Category
Documents
-
view
225 -
download
0
Transcript of Prof. M.Sc. Sílvio Bacalá Jr bacala/ESOF ...bacala/ESOF/01-IntroducaoSWEBOK.pdf · O projeto é...
Prof. M.Sc. Sílvio Bacalá Jr
www.facom.ufu.br/~bacala/ESOF
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]
Como Construir?
7
Programas
+
Documentação
+
Dados
Simplesmente
“FAZER” OU
ENGENHARIA
DE SOFTWARE
www.sei.cmu.edu/
www.rspa.com/spi/
www.swebok.org
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)
9
Engenharia de Software
Processo de Desenvolvimento de Software
Análise de
Requisitos Projeto
Implemen-
tação Teste
Implan-
tação
Atividades - Garantia de qualidade;
- Gerência de Configuração;
- Gerência de Riscos;
- Métricas;
- Estimativas;
- Revisões Técnicas Formais.
Outros
Processos
Contidos no
Processo
Principal
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].
10
Motivação
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.
Inclui algumas atividades principais.
A ordem de precedência entre elas.
Opcionalmente, artefatos requeridos e produzidos.
12
Podem ser
decomposta
s em sub-
atividades!
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]
19
3
abordagens
principais
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
entrega da 1ª versão;
Menor risco e nº de
mudanças nos req. (pelo fato
dos inc. serem menores que o
sw todo).
Requisitos instáveis ou
imcompletos geram muitas
mudanças nos incrementos;
Gerência do projeto é mais
complexa.
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
28
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
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
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).
SWEBOK
39
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.
SWEBOK
40
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.
SWEBOK
41
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.
SWEBOK
42
SWEBOK 2004 SWEBOK
43
SWEBOK 2004 SWEBOK
44
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.
SWEBOK
45
Áreas de Conhecimento
SWEBOK
46
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.
SWEBOK
47
Software Requirements
SWEBOK
48
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
SWEBOK
49
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.
SWEBOK
50
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
SWEBOK
51
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
SWEBOK
52
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
SWEBOK
53
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
SWEBOK
54
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.
SWEBOK
55
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].
SWEBOK
56
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.
SWEBOK
57
Software Design
SWEBOK
58
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
SWEBOK
59
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
Modularização
Encapsulamento
Separação de Interface e implementação
Suficiência e completeza
Abstração
Coesão e Acoplamento
SWEBOK
60
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.
SWEBOK
61
Como distribuir o SW através do HW, como comunicar os componentes, como o middleware pode ser usado com SW heterogêneos.
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.
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 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.
SWEBOK
62
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)
SWEBOK
63
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.
SWEBOK
64
Software Design Quality Analysis and Evaluation Inclui tópicos sobre qualidade e avaliação que estão
especificamente relacionadas com a concepção do software. A maior parte deles são abrangidos de uma forma geral, na KA de Qualidade de Software.
Vários atributos considerados importante para obter um projeto de software de boa qualidade :
manutenibilidade, portabilidade, testabilidade, rastreabilidade, corretude, robustez
• Interessante é a distinção entre a qualidade de atributos: • perceptíveis em tempo de execução
• desempenho, segurança, disponibilidade, funcionalidade, usabilidade
• não perceptíveis em tempo de execução • capacidade de mudança, 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
SWEBOK
65
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
SWEBOK
66
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
SWEBOK
67
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
SWEBOK
68
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
SWEBOK
69
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.
SWEBOK
70
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
SWEBOK
71
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
SWEBOK
72
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
SWEBOK
73
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
SWEBOK
74
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
SWEBOK
75
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
SWEBOK
76
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
SWEBOK
77
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
SWEBOK
78
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.
SWEBOK
79
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.
SWEBOK
80
Software Design Strategies and Methods
Outras abordagens interessantes menos convencionais como
Métodos rigorosos e formais
Métodos transformacionais
SWEBOK
81
Engenharia de Software
82
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”.
SWEBOK
83
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
SWEBOK
O quê Como
documento de requisitos modelos e artefatos
de projeto
84
Projeto de software Um modelo genérico de processo
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
85
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)
Início
Fim
Análise
Projeto Arquitetural
Projeto Detalhado
Implementação
Testes
Entrega do Produto
86
Projeto arquitetural
Início do Projeto Arquitetural
Fim do Projeto Arquitetural
Definição dos Componentes (Arquitetura)
Início
Fim
Análise
Projeto Arquitetural
Projeto Detalhado
Implementação
Testes
Entrega do Produto
87
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)
Início
Fim
Análise
Projeto Arquitetural
Projeto Detalhado
Implementação
Testes
Entrega do Produto
88
Projeto detalhado 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)
89
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
SWEBOK
90
SWEBOK
Projeto de software Tópicos da Área de Conhecimento (KA)
91
Fundamentos de Projeto de SW
92
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]
Princípios de Projeto de Software
93
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
SWEBOK
94
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
SWEBOK
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