121
10/06/2010 10/06/2010 03 - Modelos para especif 03 - Modelos para especif icação icação 1 Universidade Federal do Paraná Universidade Federal do Paraná Setor de Ciências Exatas Setor de Ciências Exatas Departamento de Informática Departamento de Informática ESPECIALIZAÇÃO EM INFORMÁTICA ESPECIALIZAÇÃO EM INFORMÁTICA Análise e Projeto de Análise e Projeto de Sistemas Sistemas Setembrino Soares Ferreira Jr. Setembrino Soares Ferreira Jr. 03 - Modelos para especificação de 03 - Modelos para especificação de sistemas de software sistemas de software

Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

  • Upload
    mora

  • View
    38

  • Download
    4

Embed Size (px)

DESCRIPTION

Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr. 03 - Modelos para especificação de sistemas de software. Universidade Federal do Paraná Setor de Ciências Exatas Departamento de Informática ESPECIALIZAÇÃO EM INFORMÁTICA. 1. Considerações iniciais 1.1. Especificação 1.1.1. Tipos - PowerPoint PPT Presentation

Citation preview

Page 1: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 11

Universidade Federal do ParanáUniversidade Federal do Paraná Setor de Ciências Exatas Setor de Ciências Exatas

Departamento de InformáticaDepartamento de Informática

ESPECIALIZAÇÃO EM INFORMÁTICAESPECIALIZAÇÃO EM INFORMÁTICA

Análise e Projeto de Análise e Projeto de SistemasSistemas

Setembrino Soares Ferreira Jr.Setembrino Soares Ferreira Jr.

03 - Modelos para especificação de sistemas 03 - Modelos para especificação de sistemas de softwarede software

Page 2: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 22

Conteúdos1. Considerações iniciais1.1. Especificação1.1.1. Tipos1.1.2. Estágios1.1.3. Verificação e validação1.1.4. Qualidade x grau de formalidade

2. Modelos e princípios da E. S.2.1. Um exemplo

Page 3: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 33

Conteúdos (cont.)3. Modelos do mundo real3.1. O modelo de função3.2. O modelo de dados3.3. O modelo comportamental3.4. O modelo de objetos3.5. O modelo formal3.6. O modelo dinâmico3.7. Dicionário de dados

Page 4: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 44

Conteúdos (cont.)4. Modelos de projeto4.1. Modelos para projeto geral4.2. Modelos para projeto detalhado

5. Modelos para teste de programas

6. Modelos de planejamento do projeto6.1. Modelos de custo6.2. Modelos de programação de projetos

Page 5: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 55

Conteúdos (cont.)7. Metodologias, métodos e ferramentas7.1. Métodos estruturados7.2. Métodos orientados a objetos7.3. Métodos formais

8. Comentários finais

9. Exercícios

Page 6: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 66

1. Considerações iniciais“Um modelo de sistema de software é uma representação em miniatura de uma realidade complexa, que reflete certas características específicas do sistema que está sendo representado.”

(CARVALHO; CHIOSSI, 2001) Modelos

Ferramentas úteis para representar especificações

Especificação - dois estágios / processos Construção de modelos Transmissão de mensagens entre grupos

Page 7: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 77

1. Considerações iniciais (cont.)

Objetivos do uso de modelos na especificação das diferentes fases do desenvolvimento

Representar visão do ambiente antes da automação Indicar diferentes alternativas de solução Apontar necessidades futuras Permitir avaliação / refinamento de características Representar componentes como partes bem definidas e com dependência mínima entre elas Permitir o trabalho gradual com a complexidade Fornecer informações quantitativas sobre escopo / complexidade de um projeto

Page 8: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 88

1.1. Especificação Desenvolver sistemas = obter e organizar dados

Volume (dimensão + complexidade) Princípios auxiliadores

Abstração - filtro dos aspectos relevantes a cada fase Decomposição

Reflexo das propriedades do sistema em suas partes Paradigmas: decomposição em fases / associação de tarefas

Page 9: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 99

1.1. Especificação Especificação

Duas classes gerais de atores: produtor e consumidor

Atores e objetivos da especificação variáveis = f(contexto)

Especificação ... ... de requisitos: desenvolvedor + cliente ... de projeto geral: projetista + implementador ... de projeto detalhado (de módulos): programadores implementadores + programadores usuários => propósito: criar ponte de comunicação entre os diversos tipos de pessoas envolvidas

Page 10: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 1010

1.1.1. Tipos de especificação Considerado o enfoque dado aos atributos do sistema

Especificação operacional Representa o comportamento desejado do sistema utilizando modelos abstratos que, de alguma forma, simulem seu comportamento Auxilia na verificação direta dos requisitos

Especificação descritiva Busca declarar as propriedades desejadas do sistema de forma puramente descritiva Representa as propriedades de maneira formal

Exemplo: trajetória de um satélite Especificação operacional: desenho de uma circunferência Especificação descritiva: x2 + y2 + c = 0

Page 11: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 1111

1.1.2. Estágios da especificação

Após a fase inicial de extração e análise de requisitos

Contrato entre cliente e desenvolvedor Documento: Declaração de objetivos e restrições do projeto (DORP)

Antecede o Plano preliminar de projeto (detalhes adiante)

1o. Estágio: Especificação de requisitos Com base nos objetivos da DORP

Descrição precisa e não ambígua do comportamento desejado para o sistema (o que é esperado?)

Com base nas restrições da DORP Delimitações do sistema especificadas como propriedades

Page 12: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 1212

1.1.2. Estágios da especificação (cont.)

2o. Estágio: Especificação de projeto Características operacionais Estrutura do sistema => Como o sistema deve ser implementado Mais detalhes que a E. R.

Dados, ações, controle e execução Passos

Especificação do projeto geral (÷ sistema em subsistemas, definir relações entre eles, ÷ subsistemas em módulos) Especificação do projeto detalhado (lógica dos módulos) Especificação das interfaces do sistema

Page 13: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 1313

1.1.2. Estágios da especificação (cont.)

3o. Estágio: Especificação de programas Deve garantir a correta tradução das decisões de projeto Decisões inclusas: escolha de algoritmos

Outros estágios Garantem a qualidade Permitem o acompanhamento e controle do projeto Exemplos

Especificação de planos para o projeto Especificação de testes

Page 14: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 1414

1.1.3. Verificação e validação F(natureza das especificações)

Várias possibilidades de haver erros Provável não traduzirem exatamente as necessidades

=> Todas devem ser verificadas Pode ser necessário

Modificar especificações existentes Incluir novas especificações

Podem ser utilizadas técnicas diferentes para a validação em cada estágio

Page 15: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 1515

1.1.4. Qualidade x grau de formalidade

Durante o desenvolvimento Várias especificações Cada uma em uma fase Cada uma com um determinado fim Dirigida a públicos diferentes

Projetista, implementador, usuário final, gerente, etc. => Propósitos diferentes

Especificação de requisitos: auxiliar usuário a entender suas necessidades / validar produto final / tomar decisões de projeto e conferir implementação (desenvolvedor) Especificação de projeto: avaliar impactos de modificações / controlar e redirecionar recursos (gerente)

Page 16: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 1616

1.1.4. Qualidade x grau de formal. (cont.)

Fatores que influenciam a qualidade das especificações

Ambigüidade Consistência Omissão

Fatores dependem do grau de formalidade F(criticidade de propriedades / componentes)

Formalismos muitas vezes são evitados F(consumo de tempo, custo, dificuldade de comunicação, falta de domínio de métodos formais, necessidade de treinamento, etc.)

Page 17: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 1717

2. Modelos e princípios da E. S. Especificações devem seguir os princípios

Abstração: concentração nos aspectos importantes, sem ater-se a detalhes não relevantes

Conceito geral dos modelos: top-down Decomposição: divisão de problemas complexos em menores, independentes, fáceis de entender e solucionar; representação das relações entre partes

Técnicas descendentes / ascendentes; hierarquias de programas / classes de objetos; modelagem em rede

Formalidade: modelos formais / semiformais permitem

Instituir controles para o desenvolvimento / qualidade Comunicação mais eficiente Representação precisa de interfaces entre estágios

Page 18: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 1818

2. Modelos e princípios da E. S. (cont.) => Modelos

Devem permitir alcance dos princípios

Boa prática para sistemas complexos Modelo do mundo real (para E. R.)

Modelo de dados Modelo de função Modelo de comportamento do sistema

Modelo do projeto (para especificação do projeto) Modelo do plano de projeto (planejamento do desenvolvimento)

Page 19: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 1919

2.1. Um exemplo Caso exemplo para especificação com modelos

Subsistema de consulta a bibliotecas de uma universidade

Entrada: título e/ou autor (título, autor) informado: pertencente ao acervo?

Sim: verificar a disponibilidade de exemplares / fornecer localização Não: informar que (título, autor) não pertence ao acervo

título informado Listar ocorrências do título no acervo (títulos iguais com autores diferentes)

autor informado Listar todos os títulos daquele autor pertencentes ao acervo

Page 20: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 2020

3. Modelos do mundo real Utilizados para representar sistemasUtilizados para representar sistemas

Representação da especificação de Representação da especificação de requisitosrequisitos

Descrição da percepção do sistema a ser Descrição da percepção do sistema a ser construídoconstruído

Foco em 3 características diferentesFoco em 3 características diferentes O que o sistema fazO que o sistema faz Que dados o sistema mantémQue dados o sistema mantém Como o sistema se comportaComo o sistema se comporta

Ilustração Ilustração

Page 21: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 2121

3. Modelos do mundo real (cont.)

PERCEPÇÕESFUNCIONAL DE DADOS COMPORTAMENT

ALVerificar acervo

Verificar disponibilidade

Localizar exemplar

BibliotecasExemplares

TítulosAutores

Aguardando consulta do usuário

Preparando resposta a consulta

SISTEMA

Sistema de consulta a bibliotecas: Percepções do mundo real

Page 22: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 2222

3.1. O modelo de função Entende o sistema todo como uma Entende o sistema todo como uma

funçãofunção Transformador de entradas em saídasTransformador de entradas em saídas

Diagrama de contexto (YOURDON, 1990): Diagrama de contexto (YOURDON, 1990): relacionamento do sistema com interfaces relacionamento do sistema com interfaces externasexternas

Interface InterfaceSISTEMA SaídaEntrada

Modelo de contexto do sistema

Page 23: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 2323

3.1. O modelo de função (cont.)

Decompõe o sistema identificando como Decompõe o sistema identificando como componentes suas principais funçõescomponentes suas principais funções A função do sistema todo fica constituída A função do sistema todo fica constituída

por um conjunto de subfunções conectadaspor um conjunto de subfunções conectadas Cada subfunção é possivelmente formada Cada subfunção é possivelmente formada

por outras subfunções conectadaspor outras subfunções conectadas ... Modelo funcional do sistema... Modelo funcional do sistema

Série de desenhos (rede)Série de desenhos (rede) Sucessivas divisões das partes que Sucessivas divisões das partes que

constituem o sistemaconstituem o sistema

Page 24: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 2424

3.1. O modelo de função (cont.)

Interface Interface

Conexão

Função 1 SaídaEntrada

Sistema

Função 2

Função 3

Função 4

Conexão

Conexão Conexão

Modelo funcional: Decomposição

Page 25: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 2525

3.1. O modelo de função (cont.)

O modelo de função pode ser considerado O modelo de função pode ser considerado completo quandocompleto quando Descreve todo o sistemaDescreve todo o sistema

Mostra as transformações de todas as entradas em Mostra as transformações de todas as entradas em saídassaídas

Decompõe convenientemente o sistemaDecompõe convenientemente o sistema Todos os componentes não particionados são Todos os componentes não particionados são

elementareselementares Cada componente do sistema está ligado Cada componente do sistema está ligado

corretamente ao resto da redecorretamente ao resto da rede Nenhuma conexão necessária foi omitidaNenhuma conexão necessária foi omitida As conexões estão minimizadasAs conexões estão minimizadas Cada conexão da rede está definida no dicionário Cada conexão da rede está definida no dicionário

de dadosde dados Todos os elementos que compõem cada conexão Todos os elementos que compõem cada conexão

estão definidosestão definidos

Page 26: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 2626

3.1. O modelo de função (cont.)

Diagramas de fluxo de dados – DFD Diagramas de fluxo de dados – DFD (DEMARCO, 1979)(DEMARCO, 1979) Especificação semiformal de funcionalidadesEspecificação semiformal de funcionalidades

Notação gráfica atrativa e fácil de usarNotação gráfica atrativa e fácil de usar Descrevem um sistema como uma coleção Descrevem um sistema como uma coleção

de dados manipulados por funçõesde dados manipulados por funções Dados podem estarDados podem estar

Armazenados em Armazenados em depósitos de dadosdepósitos de dados (estáticos) (estáticos) Contidos em Contidos em fluxos de dadosfluxos de dados (conexões) (conexões)

(dinâmicos)(dinâmicos) Fluindo de uma função para outraFluindo de uma função para outra Sendo transferidos para / do ambiente externoSendo transferidos para / do ambiente externo

Page 27: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 2727

3.1. O modelo de função (cont.)

DFD – Elementos básicosDFD – Elementos básicos Bolhas / cilindros: processos (funções)Bolhas / cilindros: processos (funções)

Transformadores(as) dos fluxos de dadosTransformadores(as) dos fluxos de dados Setas: fluxos de dados (conexões)Setas: fluxos de dados (conexões)

Meios por onde trafegam pacotes de dadosMeios por onde trafegam pacotes de dados Caixas abertas: depósitos de dadosCaixas abertas: depósitos de dados

Armazenam dados entre processosArmazenam dados entre processos Caixas retangulares: entidades externasCaixas retangulares: entidades externas

Origem ou destino de transações (/ dados Origem ou destino de transações (/ dados associados) do sistemaassociados) do sistema

Page 28: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 2828

3.1. O modelo de função (cont.)

DFD – ExemploDFD – Exemplo

Bibliotecas

Localiza(r)

exemplar

Verifica(r) disponibi-

lidade

Verifica(r)acervo

Exemplares

Títulos e Autores

Usuário

Disponibilidade

!

Exemplar disponíve

lInformações do acervo

Nome da biblioteca

Mensagem 2

Título, Autor

Mensagem 1

Lista Título-Autor

! = dados de ...

!

MR

MR

MR

Mensagem 2: Exemplar pertencente ao acervo mas não

disponível

Mensagem 1: Título e/ou autor não pertence(m) ao acervo

Page 29: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 2929

3.1. O modelo de função (cont.)

DFD – LimitaçõesDFD – Limitações É necessária alguma experiência com o É necessária alguma experiência com o

sistema para poder deduzir certas sistema para poder deduzir certas informações a partir da figurainformações a partir da figura

O diagrama não especifica claramente O diagrama não especifica claramente como as entradas são usadas para como as entradas são usadas para produzir as saídasproduzir as saídas

Sincronização de componentes não Sincronização de componentes não representadarepresentada

É necessário o uso de um dicionário de É necessário o uso de um dicionário de dados para a inclusão dos detalhes não dados para a inclusão dos detalhes não representadosrepresentados

Page 30: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 3030

3.1. O modelo de função (cont.)

DFD – Considerações finaisDFD – Considerações finais O desenho pode ser feito com o auxílio O desenho pode ser feito com o auxílio

de ferramenta automatizadade ferramenta automatizada Entradas de dicionário de dados são geradas Entradas de dicionário de dados são geradas

automaticamenteautomaticamente Cabe ao desenvolvedor completar as Cabe ao desenvolvedor completar as

entradas com os detalhes não especificadosentradas com os detalhes não especificados

Page 31: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 3131

3.2. O modelo de dados Deve representarDeve representar

Os dados que precisam ser armazenadosOs dados que precisam ser armazenados A melhor organização dos dadosA melhor organização dos dados O relacionamento entre grupos de dadosO relacionamento entre grupos de dados Como os dados serão utilizadosComo os dados serão utilizados

““É uma representação concisa dos É uma representação concisa dos requisitos do sistema sob o ponto de requisitos do sistema sob o ponto de vista de dados”.vista de dados”.

(ELMASRI; NAVATHE, 1994)(ELMASRI; NAVATHE, 1994)

Page 32: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 3232

3.2. O modelo de dados (cont.) Dados armazenadosDados armazenados

Descrevem “coisas” do mundo realDescrevem “coisas” do mundo real Possibilitam o atendimento dos requisitosPossibilitam o atendimento dos requisitos

Relação entre dados dentro do sistema Relação entre dados dentro do sistema e pessoas ou coisas fora do sistemae pessoas ou coisas fora do sistema Gera uma espécie de mapa... Pista de Gera uma espécie de mapa... Pista de

como se deve organizar os dadoscomo se deve organizar os dados Perseguir esta pista significa agrupar itens Perseguir esta pista significa agrupar itens

associados à mesma entidade do mundo associados à mesma entidade do mundo realreal

Page 33: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 3333

3.2. O modelo de dados (cont.) IlustraçãoIlustração

MUNDO REAL

DENTRO DO SISTEMA

Carro

Cliente

Entidade Propriedade Relacionamento

Cliente:

Carro:

Alugar

marcacornº chassis

nomeendereçocic

Abstração de dados

Page 34: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 3434

3.2. O modelo de dados (cont.) Abstração da entidade ClienteAbstração da entidade Cliente

Propriedades nome, endereço e cic Propriedades nome, endereço e cic dentro do sistemadentro do sistema

Boa desde que as informações sejam Boa desde que as informações sejam necessárias e suficientes para necessárias e suficientes para representar um clienterepresentar um cliente

Relacionamento entre entidadesRelacionamento entre entidades Representa uma associação essencial ao Representa uma associação essencial ao

sistemasistema Relacionamento “Alugar”Relacionamento “Alugar”

Associação entre as entidades “Cliente” e Associação entre as entidades “Cliente” e “Carro” “Carro”

Page 35: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 3535

3.2. O modelo de dados (cont.) Modelo entidade-relacionamento – Modelo entidade-relacionamento –

MER (ELMASRI; NAVATHE, 1994)MER (ELMASRI; NAVATHE, 1994) Modelo para a especificação dos dados Modelo para a especificação dos dados

armazenados pelo sistemaarmazenados pelo sistema ConceitosConceitos

EntidadesEntidades AtributosAtributos RelacionamentosRelacionamentos

Ferramenta gráficaFerramenta gráfica Diagrama entidade-relacionamento – DERDiagrama entidade-relacionamento – DER

Page 36: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 3636

3.2. O modelo de dados (cont.) Diagrama entidade-relacionamento – Diagrama entidade-relacionamento –

DER: notaçõesDER: notações Retângulos: entidades sobre as quais o Retângulos: entidades sobre as quais o

sistema mantém dadossistema mantém dados Elipses: atributos (propriedades) das Elipses: atributos (propriedades) das

entidadesentidades Losangos: relacionamentos entre Losangos: relacionamentos entre

entidadesentidades Linhas: conexões das entidades com Linhas: conexões das entidades com

atributos e/ou relacionamentosatributos e/ou relacionamentos

Page 37: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 3737

3.2. O modelo de dados (cont.) DER: exemploDER: exemplo

Cliente CarroAlugar

nome endereço cic marca cor nº chassis

m1

Page 38: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 3838

3.2. O modelo de dados (cont.) DER exemplo representaDER exemplo representa

Duas entidades: Cliente e CarroDuas entidades: Cliente e Carro Cliente aluga carroCliente aluga carro Carro é alugado por clienteCarro é alugado por cliente

Modelo entidade-relacionamentoModelo entidade-relacionamento Faz especificação descritiva! ApresentaFaz especificação descritiva! Apresenta

Propriedades (atributos) das entidadesPropriedades (atributos) das entidades Relacionamentos com outras entidadesRelacionamentos com outras entidades Ainda outras características do mundo realAinda outras características do mundo real

ParticipaçãoParticipação CardinalidadeCardinalidade

Page 39: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 3939

3.2. O modelo de dados (cont.) Participação (de entidades) em Participação (de entidades) em

relacionamentosrelacionamentos ParcialParcial

Nem todos os elementos da entidade Nem todos os elementos da entidade participamparticipam

Notação: linha simples ligando a entidade ao Notação: linha simples ligando a entidade ao relacionamentorelacionamento

Ex.: participação de Ex.: participação de carrocarro no relacionamento no relacionamento alugaralugar (alguns carros podem não estar (alguns carros podem não estar associados a clientes)associados a clientes)

TotalTotal Ex.: Ex.: ClienteCliente no relacionamento no relacionamento alugaralugar (não (não

interessa ao sistema interessa ao sistema clientesclientes que não aluguem que não aluguem carrocarro))

Page 40: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 4040

3.2. O modelo de dados (cont.) Cardinalidade de um relacionamentoCardinalidade de um relacionamento

Quantidade de instâncias de uma entidade que Quantidade de instâncias de uma entidade que se relacionam com instâncias de outra se relacionam com instâncias de outra entidadeentidade

RelacionamentosRelacionamentos Um para um (1:1)Um para um (1:1) Um para muitos (1:m)Um para muitos (1:m) Muitos para muitos (m:n)Muitos para muitos (m:n)

Ex.: Relacionamento Ex.: Relacionamento alugaralugar Um para muitosUm para muitos SignificadoSignificado

Um Um clientecliente pode pode alugaralugar vários vários carros carros (ex.: empresas) (ex.: empresas) Cada Cada carro carro pode estar pode estar alugadoalugado a apenas um a apenas um clientecliente

Page 41: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 4141

3.2. O modelo de dados (cont.) LimitaçõesLimitações

Algumas características do mundo real Algumas características do mundo real (propriedades de entidades) não podem (propriedades de entidades) não podem ser representadasser representadas

Ex.: formação do Ex.: formação do ciccic => notação semiformal=> notação semiformal

Sintaxe / semântica não precisasSintaxe / semântica não precisas NecessidadeNecessidade

Comentários informais para completar o modeloComentários informais para completar o modelo

e/oue/ou Utilização de um dicionário de dados para detalhar o Utilização de um dicionário de dados para detalhar o

modelomodelo

Page 42: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 4242

3.2. O modelo de dados (cont.) DER subsistema de consulta a DER subsistema de consulta a

bibliotecasbibliotecas

título

código

local

nome

editora

data de publicação

área

estado

nº item

autor

edição

Acervo

Possuir

ExemplarConterBiblioteca

n

m1

1

Observações:1) Entidade usuário não modelada: sem interesse2) Estado (exemplar): disponível, emprestado, reservado para disciplina3) Relacionamentos permitem verificar existência, disponibilidade e localização de um título

Page 43: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 4343

3.3. O modelo comportamental SistemasSistemas

Tendem a assumir vários estadosTendem a assumir vários estados Cada estado se caracteriza por Cada estado se caracteriza por

responder de forma única a um responder de forma única a um determinado conjunto de estímulosdeterminado conjunto de estímulos

Análise de estados de um sistema Análise de estados de um sistema exige enumerarexige enumerar Possíveis estadosPossíveis estados Eventos: condições e/ou ações que Eventos: condições e/ou ações que

causam mudança de estadocausam mudança de estado

Page 44: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 4444

3.3. O modelo comportamental (cont.)

Modelo de comportamento do Modelo de comportamento do sistema representasistema representa EstadosEstados Eventos que alteram os estadosEventos que alteram os estados

Condições e ações para mudanças de Condições e ações para mudanças de estadosestados

Se a condição para a ocorrência de um evento for Se a condição para a ocorrência de um evento for verdadeira, a ação correspondente será ativadaverdadeira, a ação correspondente será ativada

Ao longo da realização de determinada ação, o Ao longo da realização de determinada ação, o estado do componente do sistema sendo alterado estado do componente do sistema sendo alterado não é observávelnão é observável

Completada a ação, o componente passa ao Completada a ação, o componente passa ao estado determinado pelo evento correspondenteestado determinado pelo evento correspondente

Page 45: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 4545

3.3. O modelo comportamental (cont.)

Máquina de estados finitos – MEF (ALAGAR; Máquina de estados finitos – MEF (ALAGAR; PERIYASAMI, 1998)PERIYASAMI, 1998) Inclui conceitosInclui conceitos

EstadosEstados Cadeias de dados de entrada (eventos)Cadeias de dados de entrada (eventos)

Ferramenta gráfica para especificações Ferramenta gráfica para especificações semiformaissemiformais

Utiliza um grafo para representar o Utiliza um grafo para representar o comportamento do sistemacomportamento do sistema

Sistema descrito comoSistema descrito como Conjunto de estados que se alternamConjunto de estados que se alternam Em conseqüência de algum evento modelado por Em conseqüência de algum evento modelado por

dados de entradadados de entrada

Page 46: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 4646

3.3. O modelo comportamental (cont.)

Máquina de estados finitos – MEF: Máquina de estados finitos – MEF: notaçõesnotações Elipses: estadosElipses: estados Setas: eventos que causam mudanças Setas: eventos que causam mudanças

de estadosde estados Podem ser rotuladas para representarPodem ser rotuladas para representar

Condições sobre eventos que ocasionam Condições sobre eventos que ocasionam mudanças de estadosmudanças de estados

e/oue/ou Ações realizadas nas mudanças de estadosAções realizadas nas mudanças de estados

Page 47: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 4747

3.3. O modelo comportamental (cont.)

MEF: exemploMEF: exemplo

Estado 5

Estado 4

Estado 3

Estado 2

Estado 1

Ação 1(condição 1)

Ação 4(condição 4)

Ação 3(condição 3)

Ação 2(condição 2)

Estado inicial: disparado por um evento que não tem origem em outro estado

Estado final: nenhum evento parte dele

Evento 1

Evento 2

Evento 3

Evento 4

Page 48: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 4848

3.3. O modelo comportamental (cont.)

MEF: títulos de uma bibliotecaMEF: títulos de uma biblioteca

reservado para disciplina

emprestadodisponível

cancelar reserva(final do

semestre)Observação:Eventos são representados através de ações e/ou condições (quando existirem)

registrar reserva(área disciplina

= área exemplar)

registrar devolução

registrar retirada

Page 49: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 4949

3.3. O modelo comportamental (cont.)

Traço de eventosTraço de eventos Outra ferramenta para modelar Outra ferramenta para modelar

comportamentocomportamento Utilizado para representar cenários em Utilizado para representar cenários em

sistemas orientados a objetossistemas orientados a objetos Cenários descrevem como o sistema trabalhará Cenários descrevem como o sistema trabalhará

quando estiver em operaçãoquando estiver em operação Notação simplesNotação simples

Representa os objetos das classes envolvidas em um Representa os objetos das classes envolvidas em um serviço do sistema e as interfacesserviço do sistema e as interfaces

Traço vertical: classes envolvidas no serviçoTraço vertical: classes envolvidas no serviço Traço horizontal: mensagens trocadas entre as Traço horizontal: mensagens trocadas entre as

classesclasses

Page 50: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 5050

3.3. O modelo comportamental (cont.)

Traço de eventos: exemplo bibliotecaTraço de eventos: exemplo biblioteca Localização de um exemplarLocalização de um exemplar

Entrada: (título, autor)Entrada: (título, autor) Resposta: nome da biblioteca onde disponívelResposta: nome da biblioteca onde disponível

Acervo

título, autor

Exemplar Biblioteca

verifica estado

procura nome

nome da biblioteca

nome da biblioteca

nome da biblioteca

Page 51: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 5151

3.4. O modelo de objetos Utilizado para representar dados e Utilizado para representar dados e

processamento; combina aspectos dos processamento; combina aspectos dos modelos de função e de dadosmodelos de função e de dados

(RUMBAUGH, 1991)(RUMBAUGH, 1991) Permite ainda representar a composição Permite ainda representar a composição

e a classificação de componentes e a classificação de componentes (objetos)(objetos)

Na fase de análiseNa fase de análise Modelo não inclui detalhes de objetos Modelo não inclui detalhes de objetos

individuaisindividuais Trata de classes de objetos do mundo realTrata de classes de objetos do mundo real

Page 52: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 5252

3.4. O modelo de objetos (cont.) Classe de objetosClasse de objetos

Abstração sobre um conjunto de objetos Abstração sobre um conjunto de objetos que possuem atributos e serviços que possuem atributos e serviços (operações) comuns(operações) comuns

Modelo representaModelo representa Atributos e serviços das classes de Atributos e serviços das classes de

objetosobjetos Relacionamentos entre as classesRelacionamentos entre as classes Utilização de serviços de um objeto por Utilização de serviços de um objeto por

outrooutro

Page 53: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 5353

3.4. O modelo de objetos (cont.) O modelo é usado para análise e projetoO modelo é usado para análise e projeto

AnáliseAnálise Identificação de classes que representam o Identificação de classes que representam o

domínio (coisas ou conceitos) do problemadomínio (coisas ou conceitos) do problema ProjetoProjeto

Adiciona informações sobre o domínio da soluçãoAdiciona informações sobre o domínio da solução PodePode

Redefinir e estender objetos da análiseRedefinir e estender objetos da análise Acrescentar objetos para representarAcrescentar objetos para representar

InterfacesInterfaces ControlesControles Serviços de suporteServiços de suporte

Page 54: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 5454

3.4. O modelo de objetos (cont.) Utiliza diagrama de classes de Utiliza diagrama de classes de

objetos para especificar o sistemaobjetos para especificar o sistema Notações para construçãoNotações para construção

Retângulo de cantos arredondados: Retângulo de cantos arredondados: classes de objetosclasses de objetos

Nome

Lista de atributos

Serviços (operações)

Page 55: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 5555

3.4. O modelo de objetos (cont.) Diagrama de classes de objetos: Diagrama de classes de objetos:

Notações para construção (cont.)Notações para construção (cont.) Linha (ligando classes)Linha (ligando classes)

Associações entre classes de objetosAssociações entre classes de objetos Indica haver troca de mensagens (objeto Indica haver troca de mensagens (objeto

usa serviços de outro)usa serviços de outro) Losango: composição de objetos de uma Losango: composição de objetos de uma

classe (agregação)classe (agregação) Triângulo: classificação de objetos de Triângulo: classificação de objetos de

uma classe (generalização / uma classe (generalização / especialização)especialização)

Page 56: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 5656

3.4. O modelo de objetos (cont.) Relações entre classes de objetosRelações entre classes de objetos

Generalização / especializaçãoGeneralização / especialização Serve para representar que uma classe de Serve para representar que uma classe de

objetos herda todos ou alguns atributos e objetos herda todos ou alguns atributos e serviços de uma classe mais geral, além de serviços de uma classe mais geral, além de poder conter seus próprios atributos e serviçospoder conter seus próprios atributos e serviços

Classe mais geral: superclasseClasse mais geral: superclasse Especializações: subclassesEspecializações: subclasses

AgregaçãoAgregação Representa a composição de objetosRepresenta a composição de objetos Permite representar situações do mundo real Permite representar situações do mundo real

em que um objeto é composto de várias partesem que um objeto é composto de várias partes

Page 57: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 5757

3.4. O modelo de objetos (cont.) Generalização / especialização e Generalização / especialização e

agregaçãoagregação

professor

alunoempregado

pessoa

funcionário

membrotroncocabeça

pessoa

Page 58: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 5858

3.4. O modelo de objetos (cont.) ServiçosServiços

Operações associadas aos objetos da classeOperações associadas aos objetos da classe Permitem que o estado de um objeto de uma Permitem que o estado de um objeto de uma

classe possa ser modificado ou observadoclasse possa ser modificado ou observado São definidos para uma classeSão definidos para uma classe Ficam disponíveis para cada objeto da classeFicam disponíveis para cada objeto da classe

Associação entre classesAssociação entre classes Permite um objeto obter um serviço de outra Permite um objeto obter um serviço de outra

classeclasse Um objeto de uma classe pode enviar Um objeto de uma classe pode enviar

mensagens a objetos de outra classe que mensagens a objetos de outra classe que possuam o serviço desejadopossuam o serviço desejado

Page 59: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 5959

3.4. O modelo de objetos (cont.) Associação entre classesAssociação entre classes

pessoa

faculdade

Objetos da classe pessoa podem utilizar serviços definidos para a classe faculdade:

- para um objeto da classe pessoa é possível saber, por exemplo, o nome da faculdade;

- associação simples: um objeto da classe pessoa requer um serviço da classe faculdade e recebe como resultado no máximo um objeto.

Cada objeto da classe faculdade pode utilizar serviços que envolvam vários objetos da pessoa (ponto negro).

Page 60: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 6060

3.4. O modelo de objetos (cont.)

Diagrama de classes de objetos para o sistema de bibliotecasDiagrama de classes de objetos para o sistema de bibliotecas

BibliotecaExemplarAcervoTítuloData public.EditoraAssuntoAutor

Nº itemEstado

NomeLocalUnidade

Verifica títuloVerifica autorVerifica disp.

Verifica estadoLocaliza item

Obtém nomeObtém local

Page 61: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 6161

3.5. O modelo formal

Modelos formais utilizam notações Modelos formais utilizam notações matemáticas para especificar sistemasmatemáticas para especificar sistemas

Podem ser usados em qualquer Podem ser usados em qualquer estágio da especificaçãoestágio da especificação

Rejeição!????!!!!!?!Rejeição!????!!!!!?! Falta de destreza matemática para Falta de destreza matemática para

notações formaisnotações formais UtilizaçãoUtilização CompreensãoCompreensão

Page 62: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 6262

3.5. O modelo formal (cont.)

Maioria dos modelos formais: lógica Maioria dos modelos formais: lógica de predicadosde predicados Predicado: expressão booleanaPredicado: expressão booleana

Resultado: Resultado: verdadeiro verdadeiro ouou falso falso Operadores convencionais (relacionais e Operadores convencionais (relacionais e

lógicos)lógicos) Qualificadores: permitem que um predicado Qualificadores: permitem que um predicado

seja aplicado a um ou a todos os elementos seja aplicado a um ou a todos os elementos de uma coleção particular de valoresde uma coleção particular de valores

Page 63: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 6363

3.5. O modelo formal (cont.)Descrição Símbol

oSignificado

Operadores relacionais

Operadores lógicosQuantificadoresOutros símbolos

<, >, =≤, ≥, ≠۸, ۷, ~

Є, /,

Menor, maior, igual...E, ou, nãoExiste, para todoPertence, tal que, então

Alguns símbolos utilizados em cálculo de predicados

Page 64: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 6464

3.5. O modelo formal (cont.) Exemplo de usoExemplo de uso

Especificar uma função em termos de Especificar uma função em termos de pré e pós-condiçõespré e pós-condições

Pré-condiçãoPré-condição O que deve ser verdadeiro para que uma função O que deve ser verdadeiro para que uma função

seja executadaseja executada Uma condição sobre os dados de entrada da Uma condição sobre os dados de entrada da

funçãofunção Pós-condiçãoPós-condição

O que deve ser verdadeiro quando uma função O que deve ser verdadeiro quando uma função termina sua execuçãotermina sua execução

Condição sobre os dados resultantes da execução Condição sobre os dados resultantes da execução da funçãoda função

Page 65: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 6565

3.5. O modelo formal (cont.) Exemplo de uso (cont.)Exemplo de uso (cont.)

Em resumoEm resumo Pré e pós-condiçõesPré e pós-condições

Predicados sobre entradas e saídas das funçõesPredicados sobre entradas e saídas das funções Operandos da expressão: parâmetros da funçãoOperandos da expressão: parâmetros da função

Passos para a especificação formal de uma Passos para a especificação formal de uma função com o modelo de pré e pós-condiçõesfunção com o modelo de pré e pós-condições

Estabelecer restrições aos valores de entradaEstabelecer restrições aos valores de entrada Domínio de valores; existência de elementos num Domínio de valores; existência de elementos num

conjunto que possuam uma propriedade; uma conjunto que possuam uma propriedade; uma propriedade desejada para todos os elementos de um propriedade desejada para todos os elementos de um conjuntoconjunto

Estabelecer restrições aos valores de saída (Estabelecer restrições aos valores de saída (entrada)entrada) Combinar os predicados em pré e pós-condiçõesCombinar os predicados em pré e pós-condições

Page 66: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 6666

3.6. O modelo dinâmico Sistemas de software de tempo realSistemas de software de tempo real

Altamente acoplados ao mundo externoAltamente acoplados ao mundo externo Executam ações em resposta a eventos externosExecutam ações em resposta a eventos externos Escala de tempo ditada pelo mundo realEscala de tempo ditada pelo mundo real

Necessário representar modificações do Necessário representar modificações do sistema = f(t)sistema = f(t) Percepções vistas não servem!Percepções vistas não servem!

Modelos estáticos do mundo realModelos estáticos do mundo real Aspectos de tempo relevantes => modelos Aspectos de tempo relevantes => modelos

dinâmicosdinâmicos Especificação de sistemas de tempo realEspecificação de sistemas de tempo real

Modelos estático e dinâmicoModelos estático e dinâmico

Page 67: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 6767

3.6. O modelo dinâmico (cont.) Modelo dinâmicoModelo dinâmico

Especifica aspectos de mudança (movimentos) = Especifica aspectos de mudança (movimentos) = f(t)f(t)

Deve considerar atributos dinâmicosDeve considerar atributos dinâmicos Tratamento de interrupçõesTratamento de interrupções Mudança de contextoMudança de contexto Tempo de respostaTempo de resposta Taxa de transferênciaTaxa de transferência Taxa de processamento de dadosTaxa de processamento de dados Alocação de recursosAlocação de recursos Manipulação de prioridadesManipulação de prioridades Sincronização de tarefasSincronização de tarefas Comunicação entre tarefasComunicação entre tarefas Etc.Etc.

Page 68: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 6868

3.6. O modelo dinâmico (cont.) Modelo dinâmico (cont.)Modelo dinâmico (cont.)

Cada um dos atributos de desempenho Cada um dos atributos de desempenho deve ser especificadodeve ser especificado

Para Pressman (1992), a análise de Para Pressman (1992), a análise de sistemas de tempo real exige sistemas de tempo real exige modelagem e simulação que permitam modelagem e simulação que permitam avaliar seavaliar se

Os elementos do sistema obterão a resposta Os elementos do sistema obterão a resposta desejadadesejada

Os recursos do sistema serão suficientes Os recursos do sistema serão suficientes para satisfazer os requisitos computacionaispara satisfazer os requisitos computacionais

Os algoritmos de processamento serão Os algoritmos de processamento serão executados com velocidade suficienteexecutados com velocidade suficiente

Page 69: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 6969

3.6. O modelo dinâmico (cont.) Modelos como DFD, MER e Modelos como DFD, MER e

diagramas de classes de objetos diagramas de classes de objetos devem ser complementados comdevem ser complementados com Modelos que consigam representar a Modelos que consigam representar a

alteração dos estados de uma função, alteração dos estados de uma função, dado ou objeto = f(t)dado ou objeto = f(t)

Modelos de comportamentoModelos de comportamento Máquinas de estadoMáquinas de estado Traço de eventosTraço de eventos

Page 70: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 7070

3.7. Dicionário de dados Utilizado para possibilitar o entendimento Utilizado para possibilitar o entendimento

de modelos formais e semiformaisde modelos formais e semiformais ConstituiçãoConstituição

Conjunto de entradas (componentes dos Conjunto de entradas (componentes dos modelos) em ordem alfabéticamodelos) em ordem alfabética

Decomposição de componentes, caso possívelDecomposição de componentes, caso possível Descrições formais ou informaisDescrições formais ou informais

RecomendaçãoRecomendação Utilizar ferramenta automatizada para a Utilizar ferramenta automatizada para a

confecção do DDconfecção do DD Grande número de entradasGrande número de entradas Produtos geradosProdutos gerados

Page 71: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 7171

3.7. Dicionário de dados (cont.)

Notações utilizadas para a descrição Notações utilizadas para a descrição de entradasde entradas = é composto de= é composto de + e+ e () opcional() opcional {} iteração{} iteração [//] seleção (uma das opções acontece)[//] seleção (uma das opções acontece) * comentário* comentário

Page 72: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 7272

3.7. Dicionário de dados (cont.)

Exemplo: sistema de bibliotecas – Exemplo: sistema de bibliotecas – descrição do depósito de dados descrição do depósito de dados ExemplaresExemplaresexemplares = {exemplar}exemplares = {exemplar}exemplar = n_item + estado + nome_títuloexemplar = n_item + estado + nome_títuloestado = [emprestado / disponível / estado = [emprestado / disponível / reservado_p_disc]reservado_p_disc]cod_biblioteca = String[2]cod_biblioteca = String[2]n_exemplar = Integern_exemplar = Integernome_título = String[60]nome_título = String[60]

Page 73: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 7373

4. Modelos de projeto Modelo de projetoModelo de projeto

Representa a especificação do projetoRepresenta a especificação do projeto Deve traduzirDeve traduzir

Especificação do sistema (representada com Especificação do sistema (representada com modelos do mundo real)modelos do mundo real)

Arquiteturas de dados e módulosArquiteturas de dados e módulos Atividade também chamada de projeto Atividade também chamada de projeto

geral do sistemageral do sistema

Page 74: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 7474

4.1. Modelos para projeto geral

Durante o projeto geral, especificarDurante o projeto geral, especificar Decomposição do sistema em Decomposição do sistema em

subsistemassubsistemas Relações entre subsistemasRelações entre subsistemas Decomposição de subsistemas em Decomposição de subsistemas em

módulosmódulos Diferentes modelosDiferentes modelos

Da arquitetura do sistemaDa arquitetura do sistema De controle do sistemaDe controle do sistema Da arquitetura de módulosDa arquitetura de módulos

Page 75: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 7575

4.1. Modelos para projeto geral (cont.)

Modelo da arquitetura de sistemaModelo da arquitetura de sistema Deve descreverDeve descrever

O sistema como um conjunto de componentes O sistema como um conjunto de componentes (subsistemas) que fornecem um conjunto de serviços (subsistemas) que fornecem um conjunto de serviços específicosespecíficos

A comunicação entre componentesA comunicação entre componentes Modelos mais específicos podem ser utilizadosModelos mais específicos podem ser utilizados

Compartilhamento de dadosCompartilhamento de dados Distribuição dos dadosDistribuição dos dados

Modelo de dados centralizado / distribuídoModelo de dados centralizado / distribuído Interfaces entre subsistemasInterfaces entre subsistemas

Exemplo de modelo: cliente-servidorExemplo de modelo: cliente-servidor Distribuição de dados e processamento entre Distribuição de dados e processamento entre

processadoresprocessadores

Page 76: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 7676

4.1. Modelos para projeto geral (cont.)

Exemplo:Exemplo:Arquitetura com base de dados Arquitetura com base de dados centralizadacentralizada

Base de dados da universidade

Subsistema catalogação

Subsistema aquisição

Subsistema consulta

Subsistema empréstimo

Page 77: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 7777

4.1. Modelos para projeto geral (cont.) Modelo de controle do sistemaModelo de controle do sistema

Especifica as relações de controle entre as Especifica as relações de controle entre as partes do sistemapartes do sistema

Duas abordagens utilizadas pelos modelosDuas abordagens utilizadas pelos modelos CentralizadoCentralizado

Um subsistema é responsável pelo controleUm subsistema é responsável pelo controle Pode iniciar e parar outros subsistemasPode iniciar e parar outros subsistemas Pode passar o controle a outro subsistema, mas Pode passar o controle a outro subsistema, mas

aguarda o retornoaguarda o retorno Baseado em eventosBaseado em eventos

Cada subsistema pode responder a eventos Cada subsistema pode responder a eventos externos, oriundosexternos, oriundos

De outros subsistemasDe outros subsistemas Do ambiente externoDo ambiente externo

Page 78: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 7878

4.1. Modelos para projeto geral (cont.)

Exemplo:Exemplo:MModelo de controle centralizadoodelo de controle centralizado

Sistema de bibliotecas da universidade

Subsistema catalogação

Subsistema aquisição

Subsistema consulta

Subsistema empréstimo

Também pode ser usado para representar: - arquitetura de módulos; - controle de funções; - controle de objetos. (Operações em objetos = = procedimentos ou funções)

Page 79: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 7979

4.1. Modelos para projeto geral (cont.) Modelo de arquitetura de módulosModelo de arquitetura de módulos

Deve especificar a decomposição de cada subsistema Deve especificar a decomposição de cada subsistema em módulosem módulos

Dois modelos de decomposiçãoDois modelos de decomposição Orientado a objetosOrientado a objetos

Subsistemas decompostos em um conjunto de objetos que se Subsistemas decompostos em um conjunto de objetos que se comunicamcomunicam

FuncionalFuncional Subsistemas decompostos em módulos funcionais queSubsistemas decompostos em módulos funcionais que

Recebem dados de entradaRecebem dados de entrada Transformam em dados de saídaTransformam em dados de saída

Convenções utilizadasConvenções utilizadas Retângulos: módulosRetângulos: módulos Setas com caudaSetas com cauda

Vazia: troca de dados entre módulosVazia: troca de dados entre módulos Preenchida: passagem de (dados de) controle entre módulosPreenchida: passagem de (dados de) controle entre módulos

Losango negro: decisãoLosango negro: decisão Arco com seta: chamada iterativaArco com seta: chamada iterativa

Page 80: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 8080

4.2. Modelos para projeto detalhado Aprimoramento da representação Aprimoramento da representação

estruturalestrutural Especificação de estruturas de dados Especificação de estruturas de dados

detalhadasdetalhadas Representações algorítmicas dos Representações algorítmicas dos

módulosmódulos Modelos consagradosModelos consagrados

Àrvores / tabelas de decisãoÀrvores / tabelas de decisão Português estruturado / logicamente Português estruturado / logicamente

compactocompacto

Page 81: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 8181

4.2. Modelos para projeto detalhado (cont.)

Exemplo 1: português estruturadoExemplo 1: português estruturado

Módulo: localiza-exemplar;Módulo: localiza-exemplar;Recebe: exemplar-disponível;Recebe: exemplar-disponível;Usa: BD-biblioteca;Usa: BD-biblioteca;Produz: nome-bibliotecaProduz: nome-bibliotecaProcedimentoProcedimento

Início;Início; código = exemplar-disponível[1]código = exemplar-disponível[1]

+ exemplar-disponível[2];+ exemplar-disponível[2]; nome-biblioteca = obtém-nome-biblioteca(código);nome-biblioteca = obtém-nome-biblioteca(código);

exibe-biblioteca(nome-biblioteca);exibe-biblioteca(nome-biblioteca);FimFim

Page 82: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 8282

4.2. Modelos para projeto detalhado (cont.)

Exemplo 2: tabela de decisão – Exemplo 2: tabela de decisão – especificação do módulo especificação do módulo verifica-acervoverifica-acervo

Entradas Regras

C1 – recebe autorC2 – recebe título

1 2 3 4 V V F F V F V F

AçõesA1 – chama verifica-título-e-autorA2 – chama verifica-autorA3 – chama verifica-títuloA4 – exibe tela inicial

X X X X

Page 83: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 8383

5. Modelos para teste de programas Visam representar os programas abstraindo Visam representar os programas abstraindo

apenas o que for de interesse para a fase de apenas o que for de interesse para a fase de testestestes UnitárioUnitário De integraçãoDe integração

Visualização dos módulos de forma aVisualização dos módulos de forma a Facilitar a detecção de errosFacilitar a detecção de erros Permitir o projeto de casos de teste que cubram Permitir o projeto de casos de teste que cubram

diferentes tipos de erros com tempo e esforço diferentes tipos de erros com tempo e esforço mínimosmínimos

Modelos úteis para a fase de testes – construídosModelos úteis para a fase de testes – construídos Especificação de requisitosEspecificação de requisitos ProjetoProjeto

Page 84: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 8484

5. Modelos para teste de programas (cont.)

Outro modelo bastante utilizadoOutro modelo bastante utilizado Modelo de programaModelo de programa

Projeto detalhado do móduloProjeto detalhado do módulo Grafo de programaGrafo de programa

Programa (módulo) representado por seu Programa (módulo) representado por seu grafografo

NotaçãoNotação Nó: um ou + comandos seqüenciais (exceto Nó: um ou + comandos seqüenciais (exceto

decisão / iteração)decisão / iteração) Arco: transferência de controle (ramo ou ponto de Arco: transferência de controle (ramo ou ponto de

decisão)decisão)

Page 85: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 8585

5. Modelos para teste de programas (cont.)

Exemplo: Exemplo: verifica-disponibilidadeverifica-disponibilidade (proj. det.) (proj. det.)Módulo: verifica-disponibilidade;Recebe: informações-do-acervo;Procedimento:(1) início(1) consulta-exemplares(informações-do-acervo, lista-de- exemplares, n-exemplares, flag);(2) se flag = “não-disponível”(3) então Exibe-mensagem-2 (informações-do-acervo)(4) senão(5) enquanto n-exemplares <> 0(6) início(6) localiza-exemplar(lista-de-exemplares(n- exemplares));(6) n-exemplares = n-exemplares – 1;(7)(7) fim fim(7) fim(7) fim

Page 86: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 8686

5. Modelos para teste de programas (cont.)

Exemplo: Exemplo: verifica-disponibilidadeverifica-disponibilidade – grafo de – grafo de programaprograma

1

2

3 4

5

6

7

A especificação de casos de teste através dos grafos de programa permite garantir que todos os caminhos de um módulo sejam exercitados pelo menos uma vez.Caminho: coleção de arcos que vai do primeiro ao último nó do grafo.O número de caminhos (Np) é o número máximo de casos de teste que deve ser criado para se exercitar todos os caminhos ao menos uma vez.Caminhos do grafo:

(1, 2, 3, 7), (1, 2, 4, 7), (1, 2, 4, 5, 7) e (1, 2, 4, 5, 6, 5, 7)Np = 4

Page 87: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 8787

6. Modelos de planejamento do 6. Modelos de planejamento do projetoprojeto

Modelos de planos estratégicos da Modelos de planos estratégicos da empresaempresa Guias para escolha de quais projetos têm Guias para escolha de quais projetos têm

maior prioridade na verificação da real maior prioridade na verificação da real necessidade de software a ser desenvolvidonecessidade de software a ser desenvolvido

Modelos de planejamento estabelecemModelos de planejamento estabelecem Tática para o desenvolvimentoTática para o desenvolvimento Esquema contábil para o controle do esforço Esquema contábil para o controle do esforço

do desenvolvimentodo desenvolvimento Plano de desenvolvimentoPlano de desenvolvimento

Deve serDeve ser Elaborado antes do início do projetoElaborado antes do início do projeto Usado para controlar seu andamentoUsado para controlar seu andamento

Não é estáticoNão é estático Deve ser modificado ante novas informaçõesDeve ser modificado ante novas informações

Page 88: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 8888

6.1. Modelos de custo6.1. Modelos de custo Oferecem previsão (LONDEIX, 1987)Oferecem previsão (LONDEIX, 1987)

Do esforço (custo de mão-de-obra) necessário Do esforço (custo de mão-de-obra) necessário para o ciclo de vida de um sistemapara o ciclo de vida de um sistema

Do tempo de desenvolvimentoDo tempo de desenvolvimento Custo monetárioCusto monetário

Estimado = f(m.o. total determinada pelo Estimado = f(m.o. total determinada pelo modelo)modelo)

Em geral, utilizam modelos matemáticos Em geral, utilizam modelos matemáticos para estimarpara estimar Esforço = f(tamanho do software)Esforço = f(tamanho do software) Tempo = f(esforço, dada uma produtividade Tempo = f(esforço, dada uma produtividade

média)média) TípicosTípicos

Putnam (PUTNAM, 1978)Putnam (PUTNAM, 1978) Boehm (BOEHM, 1981)Boehm (BOEHM, 1981)

Page 89: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 8989

6.1. Modelos de custo (cont.)6.1. Modelos de custo (cont.) O modelo de PutnamO modelo de Putnam

Utiliza a curva de Rayleigh para estudar a Utiliza a curva de Rayleigh para estudar a distribuição de m.o. = f(t)distribuição de m.o. = f(t)

M(t) = 2 K a t e M(t) = 2 K a t e -at-at22

K: esforço total em pessoas-ano (pa)K: esforço total em pessoas-ano (pa) a: aceleraçãoa: aceleração t: tempo em anost: tempo em anos

11a = -------a = ------- 2 T2 Tdd

22

TTdd: tempo de desenvolvimento: tempo de desenvolvimento

Page 90: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 9090

6.1. Modelos de custo (cont.)6.1. Modelos de custo (cont.) O modelo de Putnam (cont.)O modelo de Putnam (cont.)

N º d e p e ss o a s

MoaMobMoc

Tdc Tdb Tda

c ba

tempo

Mo -> Pico de mão-de-obraTd -> Tempo de desenvolvimento

Page 91: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 9191

6.1. Modelos de custo (cont.)6.1. Modelos de custo (cont.) O modelo de Putnam (cont.)O modelo de Putnam (cont.)

A equipe de projetoA equipe de projeto Deve iniciar com um número de pessoas que deve Deve iniciar com um número de pessoas que deve

crescer até o final do desenvolvimentocrescer até o final do desenvolvimento Pico de mão-de-obra MoPico de mão-de-obra Mo Tempo Td (~ 40% da mão-de-obra total)Tempo Td (~ 40% da mão-de-obra total)

Ser reduzido até o final do ciclo de vida do projetoSer reduzido até o final do ciclo de vida do projeto OperaçãoOperação ManutençãoManutenção

ObservaçõesObservações Maior a equipe, maior a aceleração, menor o tempo Maior a equipe, maior a aceleração, menor o tempo

de desenvolvimentode desenvolvimento Há um limiteHá um limite

Oferece outras equaçõesOferece outras equações Cálculo do esforço = f[tamanho do sistema (LOC)]Cálculo do esforço = f[tamanho do sistema (LOC)] Cálculo do pico de mão-de-obra (Mo)Cálculo do pico de mão-de-obra (Mo)

Page 92: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 9292

6.1. Modelos de custo (cont.)6.1. Modelos de custo (cont.) O modelo de BoehmO modelo de Boehm

Três níveis de detalhesTrês níveis de detalhes Modelo básicoModelo básico

Equações para estimativas grosseiras de esforço Equações para estimativas grosseiras de esforço e tempo no início do projetoe tempo no início do projeto

Modelo intermediárioModelo intermediário Estima esforço e tempo com base em vários Estima esforço e tempo com base em vários

fatores do produto, equipamento, pessoas e fatores do produto, equipamento, pessoas e projetoprojeto

Modelo detalhadoModelo detalhado Possibilita maior grau de precisão nas estimativasPossibilita maior grau de precisão nas estimativas A partir da decomposição do produto e do A partir da decomposição do produto e do

processoprocesso

Page 93: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 9393

6.1. Modelos de custo (cont.)6.1. Modelos de custo (cont.)

O modelo de Boehm (cont.)O modelo de Boehm (cont.) Equações variam com a complexidade Equações variam com a complexidade

do produto a desenvolverdo produto a desenvolver Dos mais simplesDos mais simples Aos mais sofisticados (softwares embutidos Aos mais sofisticados (softwares embutidos

em aparelhos eletrodomésticos)em aparelhos eletrodomésticos)

Page 94: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 9494

6.1. Modelos de custo (cont.)6.1. Modelos de custo (cont.) O modelo de Boehm (cont.)O modelo de Boehm (cont.)

Equações do modelo básicoEquações do modelo básicoProduto simplesProduto simples E = 2.4SE = 2.4S1.051.05 T Tdd = 2.5E = 2.5E0.380.38

Produto moderadoProduto moderado E = 3.0SE = 3.0S1.121.12 T Tdd = 2.5E = 2.5E0.350.35

Produto complexoProduto complexo E = 3.6SE = 3.6S1.201.20 T Tdd = 2.5E = 2.5E0.320.32

S: tamanho estimado [KLOC]S: tamanho estimado [KLOC] E: esforço estimado [pessoas-mês (pm)]E: esforço estimado [pessoas-mês (pm)] TTdd: tempo de desenvolvimento estimado [meses]: tempo de desenvolvimento estimado [meses]

Ex.: sistema simples, com S = 15 KLOCEx.: sistema simples, com S = 15 KLOC => E = 41 pm=> E = 41 pm => T=> Td d = 10 meses= 10 meses

Page 95: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 9595

6.1. Modelos de custo (cont.)6.1. Modelos de custo (cont.) Em geralEm geral

Os modelos de custo são compostos por Os modelos de custo são compostos por um conjunto de equações matemáticas um conjunto de equações matemáticas para a determinaçãopara a determinação

Do esforço total EDo esforço total E Do tempo necessário para o desenvolvimento Do tempo necessário para o desenvolvimento

do sistema (Tdo sistema (Tdd)) De outras informações úteis para o De outras informações úteis para o

planejamento e controle do projetoplanejamento e controle do projeto Os valores calculados pelas equações dos Os valores calculados pelas equações dos

modelos devem ser corrigidos com fatores modelos devem ser corrigidos com fatores que, de alguma forma, tenham influência que, de alguma forma, tenham influência no esforço estimado para o sistemano esforço estimado para o sistema

Page 96: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 9696

6.2. Modelos de programação de 6.2. Modelos de programação de projetosprojetos

Estimados o esforço e a duração de um projeto, Estimados o esforço e a duração de um projeto, com os recursos humanos disponíveis é possível com os recursos humanos disponíveis é possível estabelecer a organização das atividades do estabelecer a organização das atividades do projetoprojeto Decompor o produto e o processoDecompor o produto e o processo Estimar o tempo de cada atividade do processo para Estimar o tempo de cada atividade do processo para

cada componente do produtocada componente do produto Indicar atividadesIndicar atividades

ParalelasParalelas SeqüenciaisSeqüenciais

RecorrerRecorrer Ao banco de dados de projetos concluídosAo banco de dados de projetos concluídos À experiência da pessoa que está planejando o sistemaÀ experiência da pessoa que está planejando o sistema

Modelos mais utilizadosModelos mais utilizados Rede de processos (PERT / CPM)Rede de processos (PERT / CPM) Diagrama de barras (gráfico de Gantt)Diagrama de barras (gráfico de Gantt)

Page 97: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 9797

6.2. Modelos de programação de projetos 6.2. Modelos de programação de projetos (cont.)(cont.)

PERT / CPM (WIEST; LEVY, 1997)PERT / CPM (WIEST; LEVY, 1997) BaseBase

AtividadesAtividades DuraçãoDuração DependênciasDependências

Diagrama representaDiagrama representa Rede de tarefas do início ao fim do projetoRede de tarefas do início ao fim do projeto Sincronização de atividadesSincronização de atividades Dependências entre atividadesDependências entre atividades Caminho críticoCaminho crítico

Seqüência de atividades que determinam a duração do Seqüência de atividades que determinam a duração do projetoprojeto

Estimativa de duração das atividadesEstimativa de duração das atividades Limites de tempo para as atividadesLimites de tempo para as atividades

Page 98: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 9898

6.2. Modelos de programação de projetos 6.2. Modelos de programação de projetos (cont.)(cont.)

PERT / CPM (cont.)PERT / CPM (cont.) Questões típicas tratadasQuestões típicas tratadas

Qual o tempo mais cedo para terminar o Qual o tempo mais cedo para terminar o projeto?projeto?

Quais as atividades que influenciam para Quais as atividades que influenciam para que o projeto termine na data marcada?que o projeto termine na data marcada?

Qual a interdependência entre as Qual a interdependência entre as atividades?atividades?

Quais as atividades críticas?Quais as atividades críticas?

Page 99: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 9999

6.2. Modelos de programação de projetos 6.2. Modelos de programação de projetos (cont.)(cont.)

PERT / CPM (cont.)PERT / CPM (cont.) Diagrama – elementos básicosDiagrama – elementos básicos

1 2 TMTTMC TMCTMT

2

1TMCTMT

TMTTMC

duração(folga)

evento final

atividade

evento inicial

Page 100: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 100100

6.2. Modelos de programação de projetos 6.2. Modelos de programação de projetos (cont.)(cont.)

PERT / CPM (cont.)PERT / CPM (cont.) Diagrama – elementos básicos (cont.)Diagrama – elementos básicos (cont.)

Evento: algo que ocorre e dispara uma atividadeEvento: algo que ocorre e dispara uma atividade TMC / TMT: tempos mais cedo / mais tarde de início da TMC / TMT: tempos mais cedo / mais tarde de início da

atividade sem afetar o projetoatividade sem afetar o projeto TMC = máx. (TMC inicial + duração) para atividades TMC = máx. (TMC inicial + duração) para atividades

entrantesentrantes TMT = mín. (TMT final – duração) para atividades terminaisTMT = mín. (TMT final – duração) para atividades terminais TMC = 0 para evento inicialTMC = 0 para evento inicial TMC = TMT para evento terminalTMC = TMT para evento terminal

Para cada atividade, estimar duração e calcular folgaPara cada atividade, estimar duração e calcular folga Quantidade de tempo que uma atividade não crítica pode Quantidade de tempo que uma atividade não crítica pode

superar a duração estimada sem afetar o tempo previsto superar a duração estimada sem afetar o tempo previsto para o projetopara o projeto

Folga = TMT final – TMC inicial – duraçãoFolga = TMT final – TMC inicial – duração Atividades simuladas podem ser usadas para indicar / Atividades simuladas podem ser usadas para indicar /

coibir atividades paralelas (não consomem tempo nem coibir atividades paralelas (não consomem tempo nem recursos)recursos)

Representação: setas pontilhadasRepresentação: setas pontilhadas

Page 101: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 101101

6.2. Modelos de programação de projetos 6.2. Modelos de programação de projetos (cont.)(cont.)

PERT / CPM (cont.)PERT / CPM (cont.) Conceito bastante utilizadoConceito bastante utilizado

Caminho críticoCaminho crítico Caminho de maior duração entre os eventos inicial e final do Caminho de maior duração entre os eventos inicial e final do

projetoprojeto FolgasFolgas

Do caminho crítico: sempre iguaisDo caminho crítico: sempre iguais De outros caminhos >= folgas das atividades críticasDe outros caminhos >= folgas das atividades críticas

Enfoque principal do controle administrativoEnfoque principal do controle administrativo Define atividades onde colocar recursos adicionaisDefine atividades onde colocar recursos adicionais

Encurtando o caminho críticoEncurtando o caminho crítico Permitindo o término antecipado do projetoPermitindo o término antecipado do projeto

Folgas do caminho críticoFolgas do caminho crítico >0: excesso de recursos ou prazo acima do necessário>0: excesso de recursos ou prazo acima do necessário =0: prazos e recursos adequados=0: prazos e recursos adequados <0: falta de recursos ou prazo para a conclusão do projeto<0: falta de recursos ou prazo para a conclusão do projeto

Pode haver mais de um caminho crítico em um projetoPode haver mais de um caminho crítico em um projeto Caminho crítico alternativoCaminho crítico alternativo

RepresentaçãoRepresentação Setas mais espessas (“negrito”)Setas mais espessas (“negrito”)

Page 102: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 102102

6.2. Modelos de programação de projetos 6.2. Modelos de programação de projetos (cont.)(cont.)

Diagrama de barras (ou gráfico de Gantt)Diagrama de barras (ou gráfico de Gantt) Também bastante utilizado para expor o Também bastante utilizado para expor o

relacionamento entre recursos e tarefasrelacionamento entre recursos e tarefas Para cada atividade, o diagrama indicaPara cada atividade, o diagrama indica

ResponsávelResponsável Data prevista de inícioData prevista de início Data prevista de términoData prevista de término

Pode ser usado para controlar / acompanhar Pode ser usado para controlar / acompanhar um projetoum projeto

Registrando os tempos estimados e gastos em cada Registrando os tempos estimados e gastos em cada tarefatarefa

Acrescentando outro tipo de barra para representar Acrescentando outro tipo de barra para representar as datas de início e término das atividadesas datas de início e término das atividades

Page 103: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 103103

7. Metodologias, métodos e ferramentas7. Metodologias, métodos e ferramentas Organização do processo de softwareOrganização do processo de software

Atividade críticaAtividade crítica Vai do gerenciamento de pessoasVai do gerenciamento de pessoas Ao gerenciamento de todos os produtos gerados durante Ao gerenciamento de todos os produtos gerados durante

o ciclo de vida do sistemao ciclo de vida do sistema Envolve a definição de métodos, ferramentas e suas Envolve a definição de métodos, ferramentas e suas

combinações dentro de metodologiascombinações dentro de metodologias MetodologiasMetodologias

Disciplinas utilizadas para produzir diferentes modelos de Disciplinas utilizadas para produzir diferentes modelos de um sistemaum sistema

MétodosMétodos Linhas gerais que governam a execução de alguma Linhas gerais que governam a execução de alguma

atividade, utilizando abordagens rigorosas, sistemáticas e atividade, utilizando abordagens rigorosas, sistemáticas e disciplinadasdisciplinadas

FerramentasFerramentas Dão suporte à aplicaçãoDão suporte à aplicação

MétodosMétodos MetodologiasMetodologias

Page 104: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 104104

7. Metodologias, métodos e ferramentas 7. Metodologias, métodos e ferramentas (cont.)(cont.)

Metodologia de desenvolvimento de Metodologia de desenvolvimento de softwaresoftware Detalha as atividades do ciclo de vidaDetalha as atividades do ciclo de vida Especifica um conjunto único e coerenteEspecifica um conjunto único e coerente

PrincípiosPrincípios MétodosMétodos Linguagem de representaçãoLinguagem de representação ProcedimentosProcedimentos DocumentaçãoDocumentação

Permite ao desenvolvedor implementar, sem Permite ao desenvolvedor implementar, sem ambigüidadesambigüidades

Especificações advindas das fases do ciclo de vida do Especificações advindas das fases do ciclo de vida do softwaresoftware

Page 105: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 105105

7. Metodologias, métodos e ferramentas 7. Metodologias, métodos e ferramentas (cont.)(cont.)

Modelagem de um sistemaModelagem de um sistema Forma barata de estudar aspectos essenciais de um sistema antes Forma barata de estudar aspectos essenciais de um sistema antes

de sua construçãode sua construção Para cobrir diferentes fases do desenvolvimento, uma Para cobrir diferentes fases do desenvolvimento, uma

metodologia deve utilizar métodos e ferramentas que permitam metodologia deve utilizar métodos e ferramentas que permitam conduzirconduzir A fase de análise de requisitosA fase de análise de requisitos

Especificação resultante = modelo significativo dos requisitos (modelo Especificação resultante = modelo significativo dos requisitos (modelo do mundo real)do mundo real)

A fase de projetoA fase de projeto Para produzir o modelo interno do sistemaPara produzir o modelo interno do sistema NecessidadesNecessidades

Mecanismos para traduzir a representação do domínio da informação numa Mecanismos para traduzir a representação do domínio da informação numa representação do projetorepresentação do projeto

Notação para representar componentes funcionais e interfacesNotação para representar componentes funcionais e interfaces Heurísticas para refinamento e divisão em partiçõesHeurísticas para refinamento e divisão em partições Diretrizes para a avaliação da qualidade do projetoDiretrizes para a avaliação da qualidade do projeto

O planejamento do projetoO planejamento do projeto Para produzir o plano de projeto (alternativas para a solução do Para produzir o plano de projeto (alternativas para a solução do

problema, riscos, decisões tomadas e estimativas de tempo, custo e problema, riscos, decisões tomadas e estimativas de tempo, custo e recursos)recursos)

NecessidadesNecessidades Registrar as atividades envolvidas no desenvolvimento e sua seqüênciaRegistrar as atividades envolvidas no desenvolvimento e sua seqüência Registrar resultados a produzirRegistrar resultados a produzir Metodologias a usar em cada fase do ciclo de vida do sistemaMetodologias a usar em cada fase do ciclo de vida do sistema

Page 106: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 106106

7. Metodologias, métodos e ferramentas 7. Metodologias, métodos e ferramentas (cont.)(cont.)

Escolha da metodologia mais adequadaEscolha da metodologia mais adequada À construção de um produto de boa qualidadeÀ construção de um produto de boa qualidade Aos interesses da organizaçãoAos interesses da organização Ao ambiente de desenvolvimentoAo ambiente de desenvolvimento Ao tipo de software a ser desenvolvidoAo tipo de software a ser desenvolvido Responsabilidade: Gerente ou administrador do Responsabilidade: Gerente ou administrador do

desenvolvimentodesenvolvimento Domínio de métodos e ferramentasDomínio de métodos e ferramentas

Permitam construir um produto de boa qualidadePermitam construir um produto de boa qualidade Responsabilidade: desenvolvedorResponsabilidade: desenvolvedor

Métodos principais (análise de requisitos + Métodos principais (análise de requisitos + projeto)projeto) Métodos estruturadosMétodos estruturados Métodos orientados a objetosMétodos orientados a objetos Métodos formaisMétodos formais

Page 107: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 107107

7.1. Métodos estruturados7.1. Métodos estruturados Metodologias podem variar quanto ao Metodologias podem variar quanto ao

enfoque dado às características do mundo enfoque dado às características do mundo realreal Enfoque funcionalEnfoque funcional

Mais antigo e popularMais antigo e popular Diversas metodologiasDiversas metodologias

Primeiras: puramente intuitivasPrimeiras: puramente intuitivas Generalização do conceito de implementação para Generalização do conceito de implementação para

funções de nível mais altofunções de nível mais alto ExemplosExemplos

Análise estruturada (GANE; SARSON, 1982) (DEMARCO, Análise estruturada (GANE; SARSON, 1982) (DEMARCO, 1979)1979)

Metodologias mais atuaisMetodologias mais atuais + (modelagem de dados, extensões para sistemas + (modelagem de dados, extensões para sistemas

de tempo real, comportamento do sistema)de tempo real, comportamento do sistema) Análise estruturada moderna (YOURDON, 1990)Análise estruturada moderna (YOURDON, 1990) Análise essencial (MCMENAMIN; PALMER, 1984)Análise essencial (MCMENAMIN; PALMER, 1984) Metodologia de Ward e Mellor (1985)Metodologia de Ward e Mellor (1985)

Page 108: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 108108

7.1. Métodos estruturados (cont.)7.1. Métodos estruturados (cont.) Metodologias podem variar quanto ao Metodologias podem variar quanto ao

enfoque dado às características do enfoque dado às características do mundo real (cont.)mundo real (cont.) Enfoque na assistência ao analistaEnfoque na assistência ao analista

Na identificação dos principais objetos de Na identificação dos principais objetos de informação e operaçõesinformação e operações

Na representação da estrutura de informação Na representação da estrutura de informação de forma hierárquicade forma hierárquica

Apresentam um conjunto de passos que levam de Apresentam um conjunto de passos que levam de uma estrutura hierárquica de dados a uma estrutura uma estrutura hierárquica de dados a uma estrutura de programade programa

Jackson System Development (JSD) (JACKSON, 1983)Jackson System Development (JSD) (JACKSON, 1983) Data Structured System Development (DSSD) Data Structured System Development (DSSD)

(WARNIER, 1981)(WARNIER, 1981)

Page 109: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 109109

7.1. Métodos estruturados (cont.)7.1. Métodos estruturados (cont.) Principal ferramenta de análise e Principal ferramenta de análise e

projeto estruturados (com enfoque projeto estruturados (com enfoque funcional)funcional) Diagrama de fluxo de dados (DFD)Diagrama de fluxo de dados (DFD) Construído na fase de análiseConstruído na fase de análise Pode ter o projeto derivado a partir delePode ter o projeto derivado a partir dele

Diagrama da hierarquia de módulos Diagrama da hierarquia de módulos [diagrama da estrutura de software (DES)][diagrama da estrutura de software (DES)]

(PAGE-JONES, 1980)(PAGE-JONES, 1980)

Page 110: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 110110

7.2. Métodos orientados a objetos7.2. Métodos orientados a objetos Abordagem mais atualAbordagem mais atual Principal característicaPrincipal característica

Utilização de um mesmo modelo em diferentes Utilização de um mesmo modelo em diferentes fases do desenvolvimentofases do desenvolvimento

Análise: identificação e definição de classes de objetosAnálise: identificação e definição de classes de objetos Domínio do problemaDomínio do problema Responsabilidades do sistemaResponsabilidades do sistema

Projeto: identificação e definição de classes de objetos Projeto: identificação e definição de classes de objetos adicionaisadicionais

Domínio da solução – classes de objetos que representamDomínio da solução – classes de objetos que representam InterfacesInterfaces Controle de tarefasControle de tarefas Suporte do sistemaSuporte do sistema

Page 111: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 111111

7.2. Métodos orientados a objetos (cont.)7.2. Métodos orientados a objetos (cont.) Ao contrário dos métodos estruturadosAo contrário dos métodos estruturados

Resulta em projetos que interligamResulta em projetos que interligam Objetos de dadosObjetos de dados Operações de processamento (serviços ou Operações de processamento (serviços ou

métodos)métodos) Modulariza não só o processamentoModulariza não só o processamento

InformaçãoInformação ProcessamentoProcessamento

Objeto encapsula sob o mesmo nomeObjeto encapsula sob o mesmo nome DadosDados OperaçõesOperações Outros objetosOutros objetos

Page 112: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 112112

7.2. Métodos orientados a objetos (cont.)7.2. Métodos orientados a objetos (cont.)

Metodologias mais conhecidasMetodologias mais conhecidas Rumbaugh (1991)Rumbaugh (1991) Coad e Yourdon (1990)Coad e Yourdon (1990) Booch (1986)Booch (1986) Fusion (1984)Fusion (1984)

Page 113: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 113113

7.2. Métodos orientados a objetos 7.2. Métodos orientados a objetos (cont.)(cont.)

Ferramenta mais conhecida para Ferramenta mais conhecida para análise e projeto orientados a objetosanálise e projeto orientados a objetos Diagrama de classes de objetosDiagrama de classes de objetos

Retrata objetos relevantes do sistema, a partir Retrata objetos relevantes do sistema, a partir dede

AtributosAtributos Operações feitas sobre os objetos de uma classeOperações feitas sobre os objetos de uma classe Relacionamentos entre objetosRelacionamentos entre objetos

Comportamento do sistemaComportamento do sistema CenáriosCenários Máquinas de estadosMáquinas de estados

Aspectos funcionaisAspectos funcionais Diagrama de fluxo de dadosDiagrama de fluxo de dados

Page 114: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 114114

7.2. Métodos orientados a objetos 7.2. Métodos orientados a objetos (cont.)(cont.)

Na fase de projetoNa fase de projeto Classes são atribuídas a componentes físicos Classes são atribuídas a componentes físicos

de programas (módulos)de programas (módulos) Concepção de implementação da arquitetura de Concepção de implementação da arquitetura de

programaprograma Projeto detalhadoProjeto detalhado

Alcançado detalhando-seAlcançado detalhando-se InterfacesInterfaces Estruturas de dadosEstruturas de dados AlgoritmosAlgoritmos

Fase de testeFase de teste Pode ser auxiliada pela construção de cenáriosPode ser auxiliada pela construção de cenários

Descrevem diferentes situações de comportamento Descrevem diferentes situações de comportamento esperadas para o sistemaesperadas para o sistema

Tornam possível verificar quanto o software está de Tornam possível verificar quanto o software está de acordo com os requisitosacordo com os requisitos

Page 115: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 115115

7.3. Métodos formais7.3. Métodos formais Compreendem um conjunto de atividades Compreendem um conjunto de atividades

que permitemque permitem Desenvolvimento e verificação de sistemas de Desenvolvimento e verificação de sistemas de

softwaresoftware A partir de notações matemáticas rigorosasA partir de notações matemáticas rigorosas

Proporcionam a possibilidade de avaliarProporcionam a possibilidade de avaliar ConsistênciaConsistência InteirezaInteireza Exatidão do modeloExatidão do modelo

Ambigüidades, inconsistências e omissões Ambigüidades, inconsistências e omissões descobertas mais facilmentedescobertas mais facilmente Não por revisãoNão por revisão Mediante a aplicação de análise matemáticaMediante a aplicação de análise matemática

Page 116: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 116116

7.3. Métodos formais (cont.)7.3. Métodos formais (cont.) Na verificação de programas, Na verificação de programas,

facilitamfacilitam DescobertaDescoberta Correção de errosCorreção de erros

Metodologias mais conhecidasMetodologias mais conhecidas Vienna (VDM) (JONES, 1990)Vienna (VDM) (JONES, 1990) Larch (GUTTAG; HORNING; WING, 1985)Larch (GUTTAG; HORNING; WING, 1985) Processos seqüenciais comunicantes Processos seqüenciais comunicantes

(CSP) (MOORE, 1990)(CSP) (MOORE, 1990)

Page 117: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 117117

7.3. Métodos formais (cont.)7.3. Métodos formais (cont.) Baseados nos conceitos (isolados ou Baseados nos conceitos (isolados ou

combinados)combinados) ÁlgebraÁlgebra LógicaLógica Teoria dos conjuntos e relaçõesTeoria dos conjuntos e relações

AdoçãoAdoção Maior possibilidade de uso se Maior possibilidade de uso se

desenvolvedores tiverem ferramentas desenvolvedores tiverem ferramentas automatizadas paraautomatizadas para

EspecificaçãoEspecificação VerificaçãoVerificação

Page 118: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 118118

7.3. Métodos formais (cont.)7.3. Métodos formais (cont.) EspecificaçãoEspecificação

Via linguagem formalVia linguagem formal Elementos primáriosElementos primários

SemânticaSemântica Auxilia na definição de um universo de objetos que será Auxilia na definição de um universo de objetos que será

usado para descrever o sistemausado para descrever o sistema SintaxeSintaxe

Define a notação para a representação da especificaçãoDefine a notação para a representação da especificação Conjunto de relaçõesConjunto de relações

Definem as regras que determinam quais objetos Definem as regras que determinam quais objetos satisfazem adequadamente a especificaçãosatisfazem adequadamente a especificação

Exemplos de linguagens formais (GEHANI; Exemplos de linguagens formais (GEHANI; MCGETTRICK, 1986)MCGETTRICK, 1986)

VDLVDL ZZ

Page 119: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 119119

7.3. Métodos formais (cont.)7.3. Métodos formais (cont.) VerificaçãoVerificação

FerramentasFerramentas Permitem que o desenvolvedor construa um Permitem que o desenvolvedor construa um

modelo de estado finito do sistemamodelo de estado finito do sistema Verificam se as propriedades definidas via Verificam se as propriedades definidas via

linguagem formal de especificação se linguagem formal de especificação se mantêm para cada estado ou mudança de mantêm para cada estado ou mudança de estadoestado

De manipulação algébrica trabalham De manipulação algébrica trabalham diretamente com a sintaxe e a semântica da diretamente com a sintaxe e a semântica da linguagem de especificação. Duas categoriaslinguagem de especificação. Duas categorias

Ferramentas de verificação de prova (Larch)Ferramentas de verificação de prova (Larch) Manipuladores lógicos: LCF (GEHANI; Manipuladores lógicos: LCF (GEHANI;

MCGETTRICK, 1986)MCGETTRICK, 1986)

Page 120: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 120120

8. Comentários finais8. Comentários finais Modelos para especificaçãoModelos para especificação

Utilidade incontestável para todas as fasesUtilidade incontestável para todas as fases Facilitam a comunicação entre os diferentes Facilitam a comunicação entre os diferentes

atores que participam da construção do atores que participam da construção do produtoproduto

ClientesClientes UsuáriosUsuários DesenvolvedoresDesenvolvedores EspecialistasEspecialistas Etc.Etc.

Possibilitam o registro de informações de Possibilitam o registro de informações de maneira formal ou semiformalmaneira formal ou semiformal

Apoiados por ferramentas automatizadas têm Apoiados por ferramentas automatizadas têm suas qualidades potencializadassuas qualidades potencializadas

Page 121: Análise e Projeto de Sistemas Setembrino Soares Ferreira Jr

10/06/201010/06/2010 03 - Modelos para especificação03 - Modelos para especificação 121121

9. Exercícios9. Exercícios1) Escreva as especificações operacional e descritiva da trajetória em 1) Escreva as especificações operacional e descritiva da trajetória em

pista elíptica de um veículo de Fórmula Indy.pista elíptica de um veículo de Fórmula Indy.2) Considere um sistema de materiais de uma pequena indústria e os 2) Considere um sistema de materiais de uma pequena indústria e os

subsistemas “cadastro de materiais” e “retirada de materiais”. subsistemas “cadastro de materiais” e “retirada de materiais”. Faça o modelo de dados e o modelo de objetos dos subsistemas.Faça o modelo de dados e o modelo de objetos dos subsistemas.

3) Desenhe um diagrama entidade-relacionamento que represente a 3) Desenhe um diagrama entidade-relacionamento que represente a matrícula de um aluno em matrícula de um aluno em nn disciplinas de um curso. disciplinas de um curso.

4) Usando uma máquina de estados, descreva um sistema de 4) Usando uma máquina de estados, descreva um sistema de iluminação que consiste de uma lâmpada e dois interruptores iluminação que consiste de uma lâmpada e dois interruptores ligados em paralelo. Se a lâmpada estiver apagada, apertando-se ligados em paralelo. Se a lâmpada estiver apagada, apertando-se qualquer um dos interruptores, o estado da lâmpada passará para qualquer um dos interruptores, o estado da lâmpada passará para acesa e vice-versa.acesa e vice-versa.

5) Descreva os módulos de trabalho envolvidos na construção de 5) Descreva os módulos de trabalho envolvidos na construção de uma residência e mostre como eles estão organizados seqüencial uma residência e mostre como eles estão organizados seqüencial e paralelamente.e paralelamente.

6) Diferentes pessoas que interagem com aplicações de software 6) Diferentes pessoas que interagem com aplicações de software podem requerer diferentes abstrações. Comente brevemente que podem requerer diferentes abstrações. Comente brevemente que tipos de abstrações são úteis para o usuário final, o projetista e o tipos de abstrações são úteis para o usuário final, o projetista e o pessoal de manutenção.pessoal de manutenção.

7) Desenvolva uma pesquisa sobre a linguagem Z.7) Desenvolva uma pesquisa sobre a linguagem Z.