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

[email protected]

1

http://www.facom.ufu.br/~bacala

http://www.facom.ufu.br/~bacala

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

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


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


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


9


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!


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


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


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


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


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


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


Modelos de Ciclos de Vida [7]

19

3

abordagens

principais


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


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


Modelos Incrementais

Exemplo

RAD (Rapid Application Development)

Prima por um ciclo de desenvolvimento curto.

22


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


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

http://www.softex.br/mpsbr

http://www.sei.cmu.edu/cmmi/cmmi.html

http://www.inf.ufes.br/~falbo/

http://www.inf.ufg.br/~fabio/

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


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


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


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 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 estruturar e organizar a interação com usuários e a apresentação das informações. Por exemplo, usar o MVC.



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


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


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


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


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


Outras abordagens interessantes menos convencionais como

Métodos rigorosos e formais

Métodos transformacionais

SWEBOK

81


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 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 Detalhado

Implementação

Testes

Entrega do Produto

88

Projeto detalhado Início

Fim

Análise


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

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

Prof. M.Sc. Sílvio Bacalá Jr bacala/ESOF ...bacala/ESOF/01-IntroducaoSWEBOK.pdf · O projeto é...

Documents

Transcript of Prof. M.Sc. Sílvio Bacalá Jr bacala/ESOF ...bacala/ESOF/01-IntroducaoSWEBOK.pdf · O projeto é...