PROJETO DE SOFTWARE

REFERÊNCIA

1. Pressman, Engenharia de Software

SUMÁRIO 1) Software e Engenharia de Software MÓDULO 1 - O PROCESSO DE SOFTWARE 2) Processo - Uma Visão Genérica 3) Modelos Prescritivos de Processo 4) Desenvolvimento Ágil MÓDULO 2 - PRÁTICA DE ENGENHARIA DE SOFTWARE 5) Prática - Uma visão genérica 6) Engenharia de Sistemas 7) Engenharia de Requisitos 8) Modelagem de Análise 9) Engenharia de Projeto 10) Projeto Arquitetural 11) Projeto no nível de Componentes 12) Projeto de Interface com o usuário 13) Estratégias de Testes de Software 14) Técnicas de Teste de Software 15) Métricas de Projeto de Software MÓDULO 3 - APLICAÇÃO DE ENGENHARIA DA WEB 16) Engenharia da Web 17) Formulação e Planejamento para Engenharia da Web 18) Modelagem de Análise para Aplicações Web 19) Modelagem de Projeto para Aplicações Web 20) Teste de Aplicações Web MÓDULO 4 - GESTÃO DE PROJETOS DE SOFTWARE 21) Conceitos de Gestão de Projetos 22) Métricas de Processo e Projeto

23) Estimativa de Projetos de Software 24) Cronogramação de Projeto de Software 25) Gestão de Risco 26) Gestão de Qualidade 27) Gestão de Modificações MÓDULO 5 - TÓPICOS AVANÇADOS DE ENGENHARIA DE SOFTWARE 28) Métodos Formais 29) Engenharia de Software de Sala Limpa 30) Engenharia de Software Baseada em Componentes 31) Reengenharia 32) A Estrada Adiante 1) Software e Engenharia de Software • Década de 50 ninguém previu a importância do software, ele evoluiu de ferramenta especializada para produto; • Software tem duplo papel: produto e veículo de entrega do produto; • Software é o elemento chave na evolução de sistemas e produtos baseados em computador e uma das tecnologias mais importantes do mundo; • A produção de software apresenta uma série de problemas, como obter qualidade e obedecer prazos e orçamento • Os computadores tornaram fáceis uma série de coisas, mas a maior parte das coisas que eles facilitam não precisam ser feitas; • Categorias do software: 1. Software de Sistemas = coleção de programas escritos para servir a outros programas; 2. Software de Aplicação = Programas isolados que resolvem uma necessidade específica do negócio; 3. Software Científico e de Engenharia; 4. Software Embutido; 5. Software para Linhas de Produtos (ex.: controle de estoque); 6. Aplicações da Web; 7. Software para IA = Faz uso de algoritmos não numéricos para resolver problemas complexos que não são passíveis de computação ou Análise direta (ex.: sistemas especialistas, redes nerais, reconhecimento de padrões, jogos,...);

é conhecimento incorporado. • O desenvolvimento de software é um processo iterativo de aprendizagem e o resultado é a incorporação de conhecimentos coletados. • Processo de Desenvolvimento de Software é um arcabouço para as tarefas necessárias para a construção de softwares com qualidade. independentemente de seu tamanho ou complexidade.8.html MÓDULO 1 . Comunicação (cliente e outros interessados) 2. Netsourcing (sistemas distribuídos para usando a WEB). 10. Métodos 4. Ferramentas • Arcabouço de Processo estabelece o alicerce para um processo de software completo.com • http://shareware. estando inicialmente disperso. Computação Ubíqua (computação distribuída). • Processo de Software não é Engenharia de Software. Processo 3.O PROCESSO DE SOFTWARE 2) Processo .softwarehistory.yourdon.com • http://dir. Modelagem . 9. Planejamento 3.org • http://www.Uma Visão Genérica • Software.com/story/tech/feature/2002/04/08/lehman/index. como todo capital. • Engenharia de Software é a criação e utilização de sólidos princípios de engenharia a fim de obter softwares econômicos. Referências: • http://www. Ele identifica um pequeno número de atividades de arcabouço. Foco na Qualidade 2. aplicáveis a todos os projetos de software. tácito. • Arcabouço de Processo Genérico: 1.salon.cnet. • A Engenharia de Software é uma tecnologia em : 1. que sejam confiáveis e que trabalhem eficientemente em máquinas reais. destilados e organizados. à medida que o processo e conduzido. Software Aberto • Software legado. latente e incompleto.

Intenção. 7. como por exemplo: 1. Tipo: Tarefa. 6. à medida que as empresas alcaçam diferentes níveis de capacidade e maturidade de processo. 3. 2. Nome do Padrão. 4. Estágio e Fase. 5. Construção 5. 2. Marcos de Projeto • CMMI: Metamodelo de processo baseado em um conjunto de capacidades de Engenharia de Software. Acompanhamento e Controle de Projeto de Software. 2.4. Gestão de Reusabilidade. 3. 3. Usos Conhecidos/exemplos . Solução. Pela combinação de processos uma equipe de projeto pode construir um processo que melhor satisfaça às necessidades de um projeto. Padrões Relacionados. Problema. Gestão de Risco. Contexto Inicial. Revisões Técnicas Formais. 9. Pontos de Garantia de Qualidade. 8. que devem estar presentes. Implantação • O arcabouço genérico da Engenharia de Software é complementado por várias atividades guarda-chuva. A seguir é descrito um modelo para definir um padrão de processo: 1. 6. 8. 4. Garantia de Qualidade de Software. Para atingir essas capacidades a SEI estabelece que as organizações devem desenvolver modelos de processo que sigam as diretrizes CMMI. Produtos de Trabalho Relacionados. 5. Medição. 7. um método consistente para descrever uma característica importante do processo de software. Contexto Resultante. Tarefas de Trabalho de Engenharia de Software. • Cada ação de Engenharia de Software é representada por um conjunto de tarefas. cada um com: 1. Gestão de Configuração de Software. e 4. • PADRÃO DE PROCESSO: gabarito. Preparação e Produção do Produto de Trabalho.

ações tarefas. CBA IPI. 3.cmu.org/wiki/CMMI • http://pt.edu/ • http://pt. ISO 9001:2000 para Software Referências: • http://standards. • Modelo de Ciclo de Vida • Modelo de Desenvolvimento em Cascata • Modelos Incrementais de Processo: 1. • Um modelo prescritvo define um conjunto distinto de atividades.wikipedia. • É uma adaptação em "alta velocidade" do modelo em cascata. algumas propostas: 1.sei.• Avaliação de Processo. marcos e produtos de trabalho.org/wiki/ISO_9001#ISO_9001:2000 3)Modelos Prescritivos de Processo • Os modelos prescritivos de processo foram originalmente propostos para colocar ordem no caos do desenvolvimento de sofware.wikipedia. Modelo Incremental 2. que são necessários para fazer Engenharia de Software com alta qualidade. • O desenvolvimento rápido é conseguido c/uma abordagem de construção baseada em componentes .org • http://www. SCAMPI. 2. Modelo RAD • Enfatiza um ciclo de desenvolvimento curto.ieee.

processamento ou saída. • É difícil definir com precisão a interação homem/máquina.• Modelos Evolucionários de Processo de Software 1) Prototipagem • O cliente normalmente identifica requisitos gerais. • Um protótipo é um excelente meio de coletar os requisitos de um software. não identificando detalhadamente requisitos de entrada. . 2) Modelo Espiral • Combina a natureza iterativa da prototipagem com aspectos consolidados e sistemáticos do modelo em cascata. • Pode ser um modelo de processo independente ou embutida em outro modelo.

• Incorpora muitas das características do modelo espiral.3) Modelo de Desenvolvimento Concorrente • É aplicável a todos os tipos de desenvolvimento de software e fornece uma imagem precisa do estado atual do projeto. 2) Modelo de Métodos Formais • Conjunto de atividades que levam à especificação matemática formal do programa. • Modelos Especializados de Processo 1) Desenvolvimento Baseado em Componentes • Componentes de software comercial de prateleira (COTS). .

3) Desenvolvimento de Software Orientado a Aspectos 4) Processo Unficado 4) Desenvolvimento Ágil • Combina filosofia e diretrizes de desenvolvimento. • O ambiente moderno que usa sistemas computacionais é apressado e sempre mutável. 2. 5. 6. • É valorizado o cumprimento da entrega do produto e não as atividades de A&P. • Manifesto para Desenvolvimento Ágil de Software • Modelos Ágeis de Processo: Extreme Programming(XP) DAS DSDM SCRUM Crystal FDD (Desenvolvimento guiado por características) Modelagem Ágil • Filosofia para Desenvolvimento Ágil: 1. 7. 4. 3. .

princípios e ferramentas que podem ser usadas à medida que o software vai sendo planejado e desenvolvido. 4. Examine o resultado quanto à precisão (teste e garantia de qualidade) ◦ É possível testar cada componente da solução. 3. • Essência da Prática: Entenda o problema (comunicação e análise) ◦ Quem tem interesse na solução. Comunicação e colaboração entre os membros da equipe e entre profissionais e seus clientes. • O processo de desenvolvimento de software fornece um roteiro e a prática os detalhes para alcançar os objetivos. com controle sobre o trabaho que executam. ◦ O problema pode ser compartimentalizado.1. 5. MÓDULO 2 . ◦ O problema pode ser representado graficamente. Reconhecimento de que modificações representam uma oportunidade. ◦ Quais são as incógnitas. . ◦ Pode ser representada uma solução efetiva para o problema. Ênfase na entrega rápida de softwares que satisfaçam o cliente. Importância de equipes auto-organizadas. ◦ Um problema semelhante foi resolvido. ◦ Podem ser definidos subproblemas. 2. • A prática de ES é exercida por engenheiros de software e gerentes.Uma visão genérica A prática da Engenharia de Software envolve conceitos. 2. 1.PRÁTICA DE ENGENHARIA DE SOFTWARE 5) Prática . 4. Execute o plano (geração de código) ◦ A solução está de acordo com o plano.1) Prática da Engenharia de Software • A prática é um amplo conjunto de conceitos. princípios e ferramentas que projetistas de software aplicam durante todo o processo de software. Planeje uma solução (modelagem e projeto de software): ◦ Existem problemas análogos. 3. ◦ Cada componente da solução está correto.

• Envolva o cliente na atividade de planejamento. Porque tudo existe. raciocine clara e completamente antes da ação.◦ A solução produz resultados de acordo com os dados. KSS. funciona melhor quando ambas as partes ganham. • Conserve-se focado. • Se algo não está claro. • Princípios centrais do Desenvolvimento de software: 1. Mantenha a visão. O que você produz os outros vão consumir. • Ajuste a granularidade à medida que o plano é definido.2) Práticas de Comunicação • Escute. 6. • Defina como garantir a qualidade. 7. 3. • Comunicação face a face e melhor. Planeje com antecedência o reuso. • Estime com base no que é sabido. • Seja realista (as pessoas não trabalham 100% todos os dias). 5. • Acompanhe o plano com freqüência e faça ajustes quando necessário. • Descreva como controlar e implementar modificações. modularize sua discussão. 4. funções. • Prossiga independentemente de não concordar e se algum esclarecimento não foi prestado. características e comportamentos que são necessários. • Reconheça que o planejamento é iterativo. desenhe uma figura. • Prepare-se antes de comunicar. • Considere riscos à medida que um plano é definido.3) Práticas de Planejamento: • Entenda o escopo do projeto. 2. 5. • Faça anotações e documente as decisões. • Negociação não é um concurso ou jogo. • Alguém deve facilitar a atividade. produz melhores resultados. • Busque colaboração. Esteja aberto para o futuro. 5. Pense. W5HH .

• Os componentes devem ser acoplados fracamente uns aos outros e ao ambiente externo. 2. • O projeto em nível de componente deve ser funcionalmente independente.4. Onde estão localizados na organização (Where). lutando sempre por maior simplicidade.1) Princípios da Modelagem de Análise • O domínio da Informação de um problema precisa ser representado e entendido. • Sempre considere a arquitetura do sistema a ser construído.2) Principios da Modelagem de Projeto • O projeto deve estar relacionado ao modelo de análise. Quanto é necessário de cada recurso (How Much) 5. • As interfaces (tanto internas quanto externas) precisam ser projetadas com cuidado. Usando a Análise escolher um padrão(estilo) para o projeto.4) Práticas de Modelagem 5. 3. • A tarefa de análise deve ir da informação essencial até os detalhes de implementação. enfatizando no entanto a facilidade de uso. • O projeto de interface do usuário deve estar sintonizado com as necessidades do usuário final.• • • • • • • Porque o sistema está sendo desenvolvido (Why). O que será feito (What). • O comportamento o software. Projetar a interface do usuário. Quando será concluído (When). • As funções a serem desenvolvidas no software devem ser definidas. Como o trabalho será conduzido técnica e gerencialmente (How). Quem será o responsável por uma função (Who). 5. Particionar o modelo de análise em subsistemas. como conseqüência de eventos externos. • Representações de projeto devem ser facilmente compreensíveis.4. • O projeto deve ser desenvolvido iterativamente. • Os modelos que mostram informação. • O projeto dos dados é tão importante quanto o projeto de funções de processamento. precisa ser representado. função e comportamento devem ser particionados de modo que revelem detalhes em forma de camadas. . • Conjunto genérico de tarefas para projeto: 1.

Realizar testes unitários. Projetar testes de unidade para cada componente de software 2. 8. 2. Conduzir o projeto em nível de componentes. 3.5. Refabricar o código. 5. Escolha uma linguagem de programação que satisfaça às necessidades do software e do ambiente em que ele vai operar. que possam ser aplicados. 6. Crie ciclos aninhados.1) Princípios e conceitos de codificação • Princípios de Preparação (antes de escrever uma linha de código): 1. 7. Entenda a arquitetura do software e crie interfaces que sejam consisentes com ela. 4.5) Práticas de Construção 5. Restringir seus algoritmos. seguindo a prática de programação estruturada. Selecione nomes significativos de variáveis e siga outras normas locais de codificação. Selecione um ambiente de programação que forneça ferramentas para facilitar o trabalho. • O principio de Pareto se aplica ao teste de software (80 . Conduzir uma inspeção de código quando adequado.5.2) Princípios de teste: • Todos os testes devem estar relacionados aos requisitos do cliente. corrigindo erros descobertos. Escreva código que é autodocumentado. Entenda os princípios e conceitos básicos do projeto. 2. Conserve a lógica condicional.4. tão simples quanto possível. 9. • Principios de Codificação (quando começar a codificar): 1. Crie um conjunto de testes unitários. Crie uma disposição visual que facilite o entendimento do código. 3. 5. Desenvolver uma estratégia de integração . 5. 2. de modo que sejam facilmente testáveis. • Conjunto Genérico de Tarefas de Teste: 1. tão logo os componentes que estão sendo codificados. Entenda o problema. • Principios de Validação (após completar o primeiro passo de codificação): 1. 5. 3.20). Selecione estrutura de dados que atendam às necessidades do projeto. estejam prontos. • Os testes devem ser planejados muitos antes de serem iniciados. 4. Desenvolver um modelo de implantação 5.

arquitetura de hardware. Realimentação. visando organizar o desenvolvimento de sistemas baseado em computadores: 1. • Principios chave da Implantação: 1. 5. base de dados.e 3.1) Sistemas Baseados em Computador. • Conjunto Genérico de Tarefas de Implantação: 1. Um pacote completo de entrega deve ser montado e testado. 4. Entrega. 2. 6. Coordenar os testes de aceitação com o cliente 5. Criar mídia de entrega. Coletar feed-back dos usuários. Suporte.6) Práticas de Implantação • A atividade de implantação envolve 3 ações: 1. 2. Um regime de suporte deve ser estabelecido antes do software ser entregue. 4. Estabelecer suporte humano pessoal ou em grupo. O software deve ser corrigido primeiro e depois entregue. Engenharia de Processo de Negócio. 3. . • O processo de Engenharia de Sistemas toma diversas formas. Conduzir funções de suporte permanentes. Estabelecer mecanismos de feed-back dos usuários. Desenvolver uma estratégia de validação 4.3. software. 2. Conduzir os testes de integração e validação 5. 6. 5. 6) Engenharia de Sistemas • Focaliza elementos do sistema: objetivo geral. Materiais institucionais adequados devem ser fornecidos aos usuários finais. Engenharia de Produto. 3. As expectativas do cliente quanto ao software devem ser geridas. procedimentos e outros elementos do sistema. 2. Conduzir os teste de alta prioridade 6. pessoal. Disseminar a mídia de entrega entre todos os usuários.

4) Engenharia de Produto • Traduz o desejo do cliente de um conjunto de capacidades definidas para um produto em funcionamento.3) Engenharia de Processo de Negócio • Define arquiteturas que permitem a um negócio usar informações de maneira efetiva.• Principais elementos: software. a ES abrange Métodos topdown e bottom-up para navegar na hierarquia de ES: Visão de Mundo. hardware. • Modelo de Hatley-Pirbhai . Arquitetura de Dados. Simplificações. 5. Arquitetura de Aplicações. Limitações. 6. • Modelagem de sistemas . 3. 2. 4. 1. Visão do Domínio.2) A Hierarquia da Engenharia de Sistemas • Independentemente do domínio de enfoque. 3. 2. Visão Detalhada. documentação e procedimentos. 6.todo sistema baseado em computador pode ser modelado como uma transformação usando um gabarito entrada-saída. 3.fatores restritivos: Pressupostos. • 3 arquiteturas que devem ser analisadas: 1. 6. 6. . pessoal. Visão do Elemento. 1. Restrições. BD. Infra-Estrutura Tecnológica. 4. Preferências • Simulação de Sistemas. 2.5) Modelagem de Sistemas • Os modelos de sistemas tendem a ser em camadas (hierárquicos).

• Especificação. • Elaboração. 8) Modelagem de Análise 9) Engenharia de Projeto 10) Projeto Arquitetural 11) Projeto no nível de Componentes 12) Projeto de Interface com o usuário 13) Estratégias de Testes de Software 14) Técnicas de Teste de Software 15) Métricas de Projeto de Software MÓDULO 3 .• Modelagem com UML. 7) Engenharia de Requisitos 7.GESTÃO DE PROJETOS DE SOFTWARE 21) Conceitos de Gestão de Projetos 22) Métricas de Processo e Projeto 23) Estimativa de Projetos de Software 24) Cronogramação de Projeto de Software . • Levantamento.2) Tarefas para a Engenharia de requisitos: • Concepção.1) Uma ponte para o Projeto e a Construção.APLICAÇÃO DE ENGENHARIA DA WEB 16) Engenharia da Web 17) Formulação e Planejamento para Engenharia da Web 18) Modelagem de Análise para Aplicações Web 19) Modelagem de Projeto para Aplicações Web 20) Teste de Aplicações Web MÓDULO 4 . • Validação. • Negociação. • Gestão de Requisitos. 7.

Não deve existir aqui a pretensão de especificar de forma detalhada requisitos. são especificados em detalhes. estimar de forma vaga esforço e prazos e determinar se o projeto é viável e merece uma análise mais profunda. • Utiliza UML.TÓPICOS AVANÇADOS DE ENGENHARIA DE SOFTWARE 28) Métodos Formais 29) Engenharia de Software de Sala Limpa 30) Engenharia de Software Baseada em Componentes 31) Reengenharia 32) A Estrada Adiante TÓPICOS GERAIS 1) Processo Unificado • O processo unificado (UP) de desenvolvimento de software é o conjunto de atividades necessárias para transformar requisitos do usuário em um sistema de software. • É dirigido por "use-cases". • O Processo Unificado organiza suas iterações em quatro fases principais: 1. Projeto e Processo. Estes são implementados e servem como base de avaliação junto ao usuário e desenvolvedores para o planejamento da próxima iteração. • É iterativo e incremental. • 4 P: Pessoal. a idéia é ter uma visão inicial do problema. Numa primeira iteração um ou dois requisitos. o escopo do projeto. usando o paradigma OO. Produto.25) Gestão de Risco 26) Gestão de Qualidade 27) Gestão de Modificações MÓDULO 5 . os de maior risco e valor arquitetural. onde requisitos . Em cada nova iteração na fase de elaboração pode haver um seminário de requisitos. 2. Concepção: o objetivo desta fase é levantar. de forma genérica e pouco precisa. • É baseado em componentes que realizam interfaces. Elaboração: na fase de elaboração todos (ou a grande maioria dos requisitos) são levantadosem detalhes.

5. 4. Testes. Requisitos (funcionais e não funcionais). 3.antigos são melhor esclarecidos e novos são detalhados. LISTA 01 1) O que é e quais os motivos de criação da UML? 2) Para que serve o diagrama de caso de uso da UML? 3) Quais foram as metodologias de A&P usadas usadas ao longo do tempo? 4) O que é Análise Essencial? . O processo de engenharia de requisitos é composto por quatro atividades de alto nível: 1. Identificação. determinam se este é ou não viável e se deve prosseguir para a identificação dos requisitos. Ao fim da fase. 4. Especificação e documentação. 2) Engenharia de Requisitos • É um processo que engloba todas as atividades que contribuem para a produção de um documento de requisitos e sua manutenção ao longo do tempo. Distribuição (nós físicos e os componentes em cada nó). 2. Validação. Análises (classes e responsabilidade). • Este processo deve ser precedido de estudos de viabilidade que. 90% dos requisitos foram levantados em detalhes. Projeto (classes de projeto. Implementação . a partir das restrições do projeto. subsistemas. Construção: implementação iterativa dos elementos restantes de menor risco e mais fáceis e preparação para a implantação. 3. São os seguintes os modelos: 1. 6. os principais riscos foram tratados e pode-se então fazer estimativas mais realistas. 3. 4. • O PU utiliza modelos que descrevem o sistema a ser desenvolvido sob um certo ponto de vista e seu ambiente. o núcleo do sistema foi implementado com alta qualidade. 2. interfaces). Transição: testes finais e implantação. Análise e negociação.

6) Descreva o Modelo Comportamental da Análise Essencial. 8) Cite 3 características do ciclo de vida em cascata. 11) O que é um processo de desenvolvimento de software? 12) Apresente as principais atividades de um processo de des. 23) Quais as etapas principais de um levantamento de requisitos? LISTA 02 1) Que importância era dada ao software na década de 50? 2) Qual o duplo papel atriuído ao software? 3) Quais são as 10 categorias de software? 4) Para que servem: a) Software de Sistemas. b) Software de Aplicação. 13) Onde é aplicada a TIC na cadeia de trabalho? 14) Porque o paradigma OO auxilia no projeto de sistemas complexos? 15) Cite duas ferramentas utilizadas para gerenciamento de projetos. 9) Por que um bom levantamento de requisitos é importante? 10) Cite e descreva os tipos de manutenção de software. 19) O que é um processo de produção de software? 20) O que é ciclo de vida? 21) O que é levantamento de requisitos? 22) Para que serve um Modelo de Caso de Uso. 5) O que é desenvolvimento de sofware? 6) O que é processo de desenvolvimento de software? 7) O que é Engenharia de Software? 8) Quais as camadas de Engenharia de Software? 9) O que é um arcabouço de processo de desenvolvimento de software? 10) Enumere os elementos integrantes de um arcabouço de processo de desenvolvimento de software genérico. 16) O que é e para que serve o Diagrama de Contexto? 17) Quais são as etapas de um processo genérico? 18) Defina requisitos funcionais e não funcionais. 11) O que são atividades guarda-chuva? 12) Cite 3 atividades guarda-chuva? 13) Como se representa uma ação em Engenharia de Software? .5) Descreva o Modelo Ambiental da Análise Essencial. 7) Cite 3 características do ciclo de vida espiral. de sw genérico.

responsável pelo mapeamento dos requisitos. 29) Qual a diferença do desenvolvimento em cascata para os modelos incrementais? 30) Porque é importante o uso de técnicas e ferramentas de Engenharia de Software? LISTA 03 01) No processo unificado. o empacotamento em componentes de software dos elementos do modelo de projeto — tais como arquivo de código-fonte. a equipe de projeto. Inicialmente. desenvolveu seus trabalhos seguindo os quatro subprocessos da engenharia de requisitos. 26) Quais os 4 principios da filosofia de Desenvolvimento Ágil? 27) Descreva os passos envolvidos na prototipagem. 20) Cite 2 modelos evolucionários de processo de software. biblioteca de ligação dinâmica e componentes executáveis — é descrito pelo workflow de _______________________ (ENADE 2005) 02) No processo de desenvolvimento de um sistema de controle de materiais (matérias-primas) para uma metalúrgica. 28) Descreva o modelo de desenvolvimento em cascata. foram feitas a análise e a avaliação para se verificar se o sistema seria útil ao negócio. Finalmente. logo em seguida. 17) Para que servem os modelos prescritivos de processo. cinco workflows acompanham o conjunto das fases de desenvolvimento de software. foi verificado se os requisitos identificados atendiam às . os requisitos foram identificados e analisados e. Considerando o desenvolvimento de um sistema integrado de gestão (ERP). Cada workflow é um conjunto de atividades executadas por vários membros do projeto. 19) Descreva o modelo RAD.14) Para que serve o modelo CMMI? 15) O que é um padrão de processo? 16) Cite 3 elementos integrantes de um padrão de processo. 18) Cite 3 exemolos de modelos incrementais de processo. 21) O que são componentes COTS? 22) Em que consiste o modelo que emprega métodos formais? 23) Quais as fases do processo unificado? 24) O que é valorizado no desenvolvimento ágil? 25) Cite dois modelos ágeis de processo de desenvolvimento de software. foram documentados. Em um segundo momento.

Nessa perspectiva. D) teste de integração do sistema e análise de requisitos do sistema.demandas dos usuários. C) conversão das bases de dados do sistema e teste de integração do sistema. conceitos computacionais. B) os sistemas sejam encapsulados por outros sistemas. no contexto de um processo de desenvolvimento de software. Considere ainda que nenhuma dessas unidades possua qualquer tipo de certificação e que o principal problema da organização esteja relacionado ao desenvolvimento de sistemas que atendam às necessidades da organização e que reflitam as expectativas dos clientes globais. identificou dois problemas no processo: a documentação dos requisitos (formulários e padrões utilizados) estava inadequada e não possibilitava o entendimento correto dos requisitos. são desenvolvidas as atividades de: A) definição da arquitetura do sistema e conversão das bases de dados do sistema. a adoção do paradigma orientado a objetos implica necessariamente que: A) os usuários utilizem as aplicações de forma mais simples. Tendo sido executado esse procedimento. Considerando o relatório da auditoria independente. quais foram as duas fases do processo de engenharia de requisitos que apresentaram problemas? 03) A orientação a objetos é uma forma abstrata de pensar um problema utilizando-se conceitos do mundo real e não. 04) Na etapa de projeto orientado a objetos. uma na Índia e outra na China. C) os programadores de aplicações sejam mais especializados. uma empresa independente de auditoria. D) os objetos sejam implementados de maneira eficiente e simples. 05)O desenvolvimento global de software GSD — global software development — tem-se firmado como uma das grandes tendências na área de sistemas de informação nas organizações. B) identificação dos objetos do sistema e definição da arquitetura do sistema. apenas. Considere que uma organização da área de varejo e distribuição sediada na Europa tenha implantado três unidades de desenvolvimento de software espalhadas no mundo: uma no Brasil. E) análise de requisitos do sistema e definição da arquitetura do sistema. após análise. o processo de checagem entre as demandas dos usuários e as especificações relatadas não foi bem conduzido e seus resultados eram insatisfatórios. . E) a computação seja acionada por troca de mensagens entre objetos.

C) custo. E) nível 3. custo e tempo. que são as áreas de gerenciamento de: A) escopo. KPA SPTO – acompanhamento de projeto.respectivamente. no desenvolvimento de um sistema de vendas de uma empresa que atua no segmento industrial. B) o comprometimento da alta administração. ampliando-se. E) risco. contratação e custo. D) nível 3. o nível do modelo SW-CMM e a KPA (área chave de processo) mais adequados para a situação apresentada são. Nas reuniões com os usuários para a entrega do sistema. o orçamento inicial tenha sido extrapolado em 120% e que a equipe da área de sistemas tenha concluído o sistema com mais de quatro meses de atraso. KPA SPE – engenharia de produtos de software. contratação e risco. . D) a antecipação de tendências. tempo e escopo. descrito no PMBOK. foi constatado que este não atendia às especificações esperadas pelos usuários. tempo e escopo. 07) O planejamento estratégico de sistemas de informação pode ser entendido como o processo de identificação de um porta-fólio computadorizado de aplicações que dá suporte ao plano de negócios das organizações e auxilia na concretização dos objetivos organizacionais. B) tempo. envolvendo inovação tecnológica contínua. seja pela alocação mais eficaz de recursos. Considere que. Os principais objetivos do processo de planejamento estratégico de sistemas de informação não incluem: A) o alinhamento das estratégias da área de SI com as estratégias do negócio. KPA OPD – definição do processo da organização. C) a melhoria do desempenho da área de SI.Nessa situação. Nessa situação. B) nível 2. conseqüentemente. suas chances de sucesso. KPA RM – gestão de requisitos. D) contratação. envolve um conjunto de nove áreas de conhecimento a serem consideradas com vistas a melhorar o processo de gestão de um projeto. seja pelo aumento de produtividade dos profissionais. 06) O modelo de gerenciamento de projetos do PMI (Project Management Institute). C) nível 2. pela alocação dos recursos e resultados intermediários e incrementais. A) nível 2. evidenciam-se áreas de conhecimento que compõem a chamada tripla restrição. KPA SPP – planejamento.

08)Julgue os seguintes itens referentes a teste de software. C) Apenas os itens I e III estão certos. permite verificar se são atendidos os detalhes do código e solicita a execução de partes ou de componentes elementares do programa. julgue os itens que se seguem. o objetivo é descobrir erros associados às interfaces entre os módulos quando esses são integrados. a avaliação e a validação dos controles relacionados aos sistemas de informação existentes. A) Apenas um item está certo.A técnica de teste funcional. na fase de teste de integração. com base em determinada implementação. I .E) a identificação. na célula inferior direita. II. D) Apenas os itens II e III estão certos. I. a técnica de teste estrutural aborda o software de um ponto de vista macroscópico e estabelece os requisitos de teste. E) Todos os itens estão certos. que estabelece os requisitos de teste com base em determinada implementação.O número 65. informação e conhecimento. projeto | P1 P2 percentual 50 80 completado (em %) | percentual do orçamento já despendido (em %) 70 65 Com base nessa planilha e com relação aos conceitos de dado. do ponto de vista de sua eficiência e eficácia. em fluxo de controle e em fluxo de dados. Assinale a opção correta. 09) O gerente de desenvolvimento de uma empresa de TI examinou a seguinte planilha sobre andamento de projetos. . é um dado. estabelecida na fase de projeto. III. procurando-se identificar erros de lógica e de implementação de cada módulo. B )Apenas os itens I e II estão certos. o objetivo é explorar-se a menor unidade de projeto.Na fase de teste de unidade. são utilizados pela técnica estrutural de teste. para se construir a estrutura do software.Critérios com base na complexidade.

IV . a especificação de requisitos apresenta vários desafios desse tipo.I e II. na área de desenvolvimento de software. Estão certos apenas os itens: A) I e II. resolução de conflitos. IV . Os propósitos da TGS que podem contribuir para a resolução desses problemas incluem I. diversos problemas requerem abordagem multidisciplinar para serem resolvidos. C) II e III.III e IV.a integração de contribuições de várias ciências na busca de solução dos problemas. III .Dizer que P1 está adiantado ou atrasado é uma informação. qualquer que seja a natureza dos elementos que os compõem e as relações ou forças existentes entre eles. D . Por exemplo.o desenvolvimento de princípios únicos para cada área do conhecimento. D) III e IV. III. 10) O objetivo da Teoria Geral dos Sistemas (TGS) é a formulação dos princípios válidos para os sistemas em geral.Associar o número 80 (célula inferior central) ao percentual completado (em %) e a P2. Estão certos apenas os itens: A . E . Na área de sistemas de informação. C . e concluir que o projeto P2 está 80% completado é um conhecimento.I e IV. V .II e III.o incentivo à especialização total das áreas do conhecimento. B) I e V. conhecimento do negócio. diferenças culturais etc. E) IV e V 11) Qual a importância do gerenciamento de versões em um processo de desenvolvimento de software e como gerenciamento de configuração pode ajudar .II . II.o desenvolvimento dos princípios unificadores quetranscendem o universo das ciências individuais. B .II e IV.o desenvolvimento de estudos que visem à ampliação da separação entre as ciências naturais e sociais.Dizer o quanto P1 vai precisar a mais do que foi inicialmente previsto no orçamento é um conhecimento. tais como aspectos de relacionamento interpessoal.

neste processo? 12) Para que serve um sistema de controle de versão? 13)Como funciona o controle de versão? 14) Quais as semelhanças e diferenças entre o controle de versão centralizado e o distribuído? 15) Cite duas ferramentas de controle de versão e exemplifique seu uso. O desenvolvedor não trabalha diretamente nos arquivos do repositório. • Colaboração. Orepositório armazena todo o histórico de evolução do projeto. O controle de versão possibilita que vários desenvolvedores trabalhem em paralelo sobre os mesmo arquivos sem que um sobrescreva o código de outro. . • Variações no Projeto. Por exemplo. Além disso. o que traria reaparecimento de defeitos e perda de funcionalidades.0 enquanto a equipe prepara uma versão 2.0. Registra toda a evolução do projeto. permite reconstruir uma revisão específica do arquivo sempre que desejado. mantendo uma versão 1. Com essas informações sabe-se quem fez o que. Ao invés disso. Mantém linhas diferentes de evolução do mesmo projeto. registrando toda e qualquer alteração feita em cada item versionado. Essa área é individual e isolada das demais áreas de trabalho. 17) Como funciona o controle de versão? R. cada alteração sobre cada arquivo. quando e onde. 16) Como o Controle de versão apóia o desenvolvimento de software? R.: O controle de versão é composto de duas partes: o repositório e a área de trabalho. usa uma área/cópia de trabalho que contém a cópia dos arquivos do projeto e que é monitorada para identificar as mudanças realizadas.: • Histórico.

A sincronização entre a área de trabalho e o repositório é feita através dos comandos decommit e update. 18) O que é qualidade de software? R. O update faz o inverso. data e autor. 19)O que é qualidade de software segundo a norma ISO 9000 . o principal objetivo é garantir um produto final que satisfaça às expectativas do cliente. As "fotos" antigas são mantidas e podem ser recuperadas e analisadas sempre que desejado. envia as modificações contidas no repositório (origem) para a área de trabalho (destino). dentro daquilo que foi acordado inicialmente. O commit envia um pacote contendo uma ou mais modificações feitas na área de trabalho (origem) ao repositório (destino).:A qualidade de software é uma área de conhecimento da engenharia de software que objetiva garantir a qualidade do software através da definição e normatização de processos de desenvolvimento. Cada commit gera uma nova revisão no repositório. isto é. Apesar dos modelos aplicados na garantia da qualidade de software atuarem principalmente no processo. A diferença está em como cada uma dessas partes está arranjada. Uma revisão funciona como uma "foto" de todos os arquivos e diretórios em um determinado momento da evolução do projeto. Tanto o controle de versão centralizado quanto o distribuído possuem repositórios e áreas de trabalho. O conjunto dessas revisões é justamente o histórico do projeto. contendo as modificações feitas.

Desenvolvido pelo SEI (Software Engineering Institute) da Universidade Carnegie Mellon. dos processos de desenvolvimento e dos produtos gerados.Capability Maturity Model for Software /SEI" é uma estrutura-"framework". Este caminho de melhoria é definido por cinco níveis de maturidade: inicial. processo ou sistema cumpre os requisitos inicialmente estipulados para estes. 22) O que é CMMI? R. A GQS atua como "guardiã".: Segundo a norma ISO 9000 (versão 2000). Dirige-se ao processo de desenvolvimento de produtos e serviços.2) apresenta três modelos: ▪ CMMI for Development (CMMI-DEV) publicada em agosto de 2006.: O "CMM . o CMMI é uma evolução do CMM e procura estabelecer um modelo único para o processo de melhoria corporativo.: O CMMI (Capability Maturity Model Integration) é um modelo de referência que contém práticas (Genéricas ou Específicas) necessárias à maturidade em disciplinas específicas (Systems Engineering (SE). gerenciado e otimizado. A versão atual do CMMI (versão 1. integrando diferentes modelos e disciplinas. 21) O que é o modelo CMM R.: Garantia da Qualidade de Software (GQS) é a área-chave de processo do CMM cujo objetivo é fornecer aos vários níveis de gerência a adequada visibilidade dos projetos. O CMM descreve os estágios de maturidade através dos quais Organizações de software evoluem o seu ciclo de desenvolvimento de software através de sua avaliação contínua. que descreve os principais elementos de um processo de desenvolvimento de software efetivo. repetitivo. fornecendo um retrato do uso do Processo e não é responsável por executar testes de software ou inspeção em artefatos. Supplier Sourcing (SS)).R. Software Engineering (SW). definido. . 20) O que é GQS (Garantia da Qualidade de Software)? R. identificação e ações corretivas dentro de uma estratégia de melhoria dos processos. Integrated Product and Process Development (IPPD). a qualidade é o grau em que um conjunto de características inerentes a um produto.

: Possibilita à organização utilizar a ordem de melhoria que melhor atende os objetivos de negócio da empresa. É caracterizado por Níveis de Maturidade (Maturity Levels): ▪ Nível 1: Inicial (Ad-hoc) ▪ Nível 2: Gerenciado / Gerido ▪ Nível 3: Definido ▪ Nível 4: Quantitativamente gerenciado / Gerido quantitativamente ▪ Nível 5: Em otimização 26) Em que consiste a Engenharia de Requisitos? R.: Contínua e por estágios. 23) Quais os tipos de representação do CMMI? R. .▪ CMMI for Acquisition (CMMI-ACQ) publicada em novembro de 2007. Dirige-se aos processos de empresas prestadoras de serviços.: Disponibiliza uma seqüência pré-determinada para melhoria baseada em estágios que não deve ser desconsiderada.: é um processo que engloba todas as atividades que contribuem para a produção de um documento de requisitos e sua manutenção ao longo do tempo. 24) Para que serve a representação contínua? R. pois cada estágio serve de base para o próximo. Dirige-se aos processos de aquisição e terceirização de bens e serviços. ▪ CMMI for Services (CMMI-SVC) publicada em fevereiro de 2009. É caracterizado por Níveis de Capacidade (Capability Levels): ▪ Nível 0: Incompleto (Ad-hoc) ▪ Nível 1: Executado (Definido) ▪ Nível 2: Gerenciado / Gerido ▪ Nível 3: Definido ▪ Nível 4: Quantitativamente gerenciado / Gerido quantitativamente ▪ Nível 5: Em otimização (ou Optimizado) 25) Para que serve a representação por estágios? R.

através da interação com "as partes interessadas" (ou stakeholder em inglês) do projeto (em reuniões ou entrevistas. Uma outra atividade que se pode considerar que faz também parte deste processo. por exemplo). 2. Análise e negociação. Uma forma de avaliar a viabilidade de um projeto é obter. determinam se este é ou não viável e se deve prosseguir para a identificação dos requisitos. a partir das restrições do projeto. Especificação e documentação. de um ponto de vista tecnológico e organizacional. sendo que as alterações podem ser causadas pelos mais diversos fatores desde inovações tecnológicas a mudanças na natureza do negócio (e consequentemente nos requisitos). é a gestão dos requisitos (change management. 3. 27) Quais as 4 atividades de alto nível da engenharia de Requisitos? R. 2005): 1. 28) Em que consiste um estudo de viabilidade? R. a sua "manutenção"). será que o sistema pode ser implementado? ▪ Caso haja necessidade de integração entre diferentes sistemas.: O processo de engenharia de requisitos é composto por quatro atividades de alto nível (Soares. Identificação. Tal como o nome sugere. se incluirmos a fase posterior à produção do documento (isto é. entre outras). políticas. organizacionais (econômicas. recursos disponíveis) e temporais associadas ao projeto. Validação. pretende-se com este estudo avaliar se. será que esta é possível? 29) Em que consiste um estudo etnográfico? . ambientais.Este processo deve ser precedido de estudos de viabilidade que. deve ser feito um estudo de viabilidade. a resposta às seguintes questões: ▪ Será que o sistema contribui para os objetivos da organização? ▪ Dadas as restrições tecnológicas. 4. o projeto é viável.: Antes de se avançar com uma análise mais detalhada dos requisitos de um projeto.

Esta observação pode ser acompanhada de registros áudio/vídeo. pelo que convém ter algum cuidado na escolha do mesmo. 30) Em que consiste a gestão da configuração de software? R. são criadas muitas versões diferentes de software. Quando um dado conjunto de tarefas se torna rotineiro para uma pessoa. porém não convém usá-los em demasia visto que o tempo necessário para os processar pode ser demasiado. O objetivo é maximizar a produtividade pela minimização dos erros.” Segundo Sommerville [SOMMERVILLE03] o gerenciamento de configuração (configuration management – CM) é o desenvolvimento e aplicação de padrões e procedimentos para gerenciar um produto de sistema em desenvolvimento. Essas versões incorporam propostas de mudanças. É necessário gerenciar os sistemas em desenvolvimento porque. é de esperar que esta sinta dificuldade em articular todos os passos que segue ou todas as pessoas com as quais interage para as levar a cabo.: Os Estudos Etnográficos são uma análise da componente social das tarefas desempenhadas numa dada organização. É possível que haja várias versões em desenvolvimento e em uso . correções de defeitos e adaptações para diferentes hardwares e sistemas operacionais.: Segundo Babich [BABICH86] gestão de configuração de software é: “A arte de coordenar o desenvolvimento de software para minimizar a confusão é chamada de gestão de configuração.R. à medida que eles se desenvolvem. organizar e controlar modificações de software que está sendo construído por uma equipe de programação. Através de uma observação direta das atividades realizadas durante um período de trabalho de um funcionário é possível encontrar requisitos que não seriam observáveis usando técnicas convencionais. A gestão de configuração é a arte de identificar. Nesta técnica assume-se que o representante do cliente observado desempenha as suas funções "corretamente".

Ao invés disso. ele é significativo. Já para Szyperski [4]. pois tem uma função clara no contexto em que foi definido. No caso dos componentes "comerciais de prateleira" ( ou commercial off-the-shelf . mas sim um dispositivo de software que possua uma interface bem definida. o componente é um elemento independente. O nível de serviço é portanto crucial e precisa ser acurado se quiser que a integração do componente ao sistema de software seja bem sucedida. e substituível parte de um sistema que cumpre uma função clara no contexto de uma arquitetura bem definida". Ao contrário de objetos em POO. Mas a definição é levada ainda além. em componentes funcionais e lógicos com interfaces bem definidas. usadas para comunicação entre os próprios componentes. Mas para Krutchen [5]. Componentes são definidos para oferecer um certo nível de serviço. Componentes são considerados como estando num nível de abstração mais alto que do que Objetos e.ao mesmo tempo. ao engenheiro de software é dada apenas uma interface externa bem-definida a partir da qual ele deve trabalhar. quase independente. esta descrição é similar a de um objeto em POO. o engenheiro de software sabe pouco ou nada sobre o funcionamento interno de um componente. É necessário manter o controle das mudanças que foram implementadas e de como essas mudanças foram incluídas no software. contudo. Eles empregam regras de herança. como tal. com ênfase na decomposição dos sistemas. Brown e Wallnau descrevem um componente de software como “uma unidade de composição contratualmente especificada e somente com dependências contextuais explícitas”. 31) Em que consiste a ES baseada em componentes (ESBC)? R. os componentes são usualmente construídos a partir de muitos “objetos” de software (embora a construção não seja . 32) O que é um componente de software? R. Componentes possuem uma interface. Em muitos sentidos. não compartilham estado e comunicam-se por troca de mensagens contendo dados.: Engenharia de Software Baseada em componentes é um ramo de Engenharia de Software. que pode ser substituído. o componente não é necessariamente uma tecnologia implementada especificamente e nem a aplicação.: Brown e Wallnau[3] descrevem um componente como "uma não-trivial.COTS).

Os assim chamados “objetos” trabalham em conjunto para realizar uma tarefa específica em um dado nível de serviço. permite a integração de novos componentes e/ou a atualização dos já existentes. São componentes que podem ser comprados. a ESBC almeja: ▪ Componentes qualificados [6] ▪ Componentes adaptados ▪ Componentes aglutinados ▪ Componentes atualizados 33) Quais os 2 processos que correm em paralelo na ESBC? R. e os serviços que este oferece. Isso auxilia na manutenção dos sistemas uma vez que. como podem ou não ser acuradas. b) Desenvolvimento Baseado em Componentes O Desenvolvimento Baseado em Componentes (DBC) aborda a criação de sistemas de software que envolva a composição de componentes permitindo a adição. no geral. adaptação. Adicionalmente aos COTS. Componentes podem ser caracterizados com base em seu uso no processo de ESBC: Como mencionado acima temos os COTS. 34) Quais os principais modelos de componentes existentes? . não há código fonte disponível. dentro de um domínio de aplicação específico.confinada a POO) e fornecem uma unidade de funcionalidade coerente. Essa idéia vem ao encontro da reutilização que busca flexibilizar o desenvolvimento. catalogar e disseminar um conjunto de componentes de software que tenham aplicabilidade para software existentes e futuros. pois foram usados e testados( e reusados e retestados) e muitas diferentes aplicações. é que estes tipos de componentes deveriam(em teoria) ser mais robustos e adaptáveis. e sendo assim. pré-fabricados.: a) Engenharia de Domínio Objetiva identificar. precisam ser confiavelmente testadas. remoção e substituição de partes do sistema sem a necessidade de sua completa substituição.aplicações com funcionalidade(ou intenção de funcionalidade) similar. a definição do uso do componente dada pelo fabricante(desenvolvedor). entretanto. O objetivo é estabelecer um mecanismo em que engenheiros de software possam partilhar estes componentes usando-os em sistemas futuros. Um domínio de aplicação é como uma família de produtos . A desvantagem. A abordagem é criar ou adaptar os componentes para que sejam utilizados em diversos sistemas. com a desvantagem de que. construir.

Os benefícios são melhores decisões. melhora no relacionamento com as partes interessadas. processo e estrutura relativos a perceber oportunidades enquanto gerencia-se efeitos adversos. na performance e na efetividade e ainda.R. menos surpresas. O principal ponto de gerenciar riscos é avaliar a incerteza do futuro de modo a tomar a melhor decisão possível. segundo a SEI? R. ▪ DCOM (Distributed Component Obejct) e COM/COM+ (Component Object Model) da Microsoft.: Gestão de risco pode ser definido como cultura. e ▪ JavaBeans e Entreprise JavaBeans (EJB) da Sun. Em geral. melhora no planejamento. Acreditamos que gestão de risco deveria ser parte integral de boas práticas de negócios.: • De acordo com a Natureza ◦ Riscos de Projeto ◦ Riscos de Negócio ◦ Riscos Técnicos • De acordo com a probabilidade do evento ◦ Conhecidos ◦ Previsíveis ◦ Imprevisíveis 37) Quais as atividades contínuas da Gestão de Riscos. 36) Quais os tipos de riscos em software? R. Um explicação para o crescente interesse em gestão de risco é a oportunidade de aplicar nosvas idéias e ferramentas à "nova realidade de risco". toda gestão de risco e toda tomada de decisão lida com essa questão.: ▪ CMM (CORBA Component Model) do OMG (Object Management Group).: . 35) Qual o objetivo da gestão de riscos? R. tanto nos níveis estratégicos quanto operacionais.

b). c).Comunicar Identificar Buscar e localizar os riscos antes que eles se tornem problemas reais Analisar Transformar os dados dos riscos em informações para tomada de decisão Planejar Traduzir e implementar as informações dos riscos em ações de decisão e resolução de riscos Monitorar Monitorar indicadores dos riscos e seus planos de resolução Controlar Corrigir os desvios para os planos de resolução dos riscos 38) O que é uma ferramenta de controle de versão? 39) Qual a importância do uso de uma ferramenta de controle de versão num projeto? 40) Em que consiste a filosofia de desenvolvimento por componentes? 41) Dê exemplo de arquiteturas de desenvolvimento por componentes. b. (d. (c. onde: V = {a. e. c. f} E = {(a. e). em programas de computador. A seguir á apresentado um exemplo de grafo G (V. E) é composto por um conjunto V não vazio de vértices(nós) e um conjunto (E) de arestas (arcos). b) é uma aresta entre vértice a e b. d. (b. d). quais suas vantagens no desenvolvimento de sistemas? Consideraçõe sobre a Teora dos Grafos Um grafo G = (V. onde cada aresta conecta dois vértices. . Um grafo pode ser representado de duas formas: uma baseada numa representação visual.usando círculos fechados para vértices e retas ou curvas para arestas e outra mais formal que usa matrizes e vetores. e). (c. f)} (a. (b. 42) Por que o estabelecimento exato dos requisitos do sistema com o cliente e sua exata compreensão pela equipe de desenvolvimento é tão importante? 43) O que é um "milestone" na gestão de um projeto? 44) Para que serve a gestão de modificações? 45) O que é gestão de reusabilidade? 46) Descreva resumidamente para que servem as práticas da Engenharia de Software.E). A segunda forma será usada nas estruturas de dados que trabalham com grafos.

E) é usualmente representado por uma matriz de adjacências. v3). Um sumidouro é um vértice com grau de saída 0 e grau de entrada > 1. O grau de um vértice é o número de arestas adjacentes a ele. Um circuito será simples se nenhum vértice aparecer mais de uma vez. Programa make do Unix O programa make do Unix toma como entrada um arquivo texto contendo comandos da forma . Num grafo dirigido o grau de entrada é dado pelo número de arestas que chegam ao vértice e o grau de saída pelo número de arestas que sai. Um caminho é uma seqüência de vértices v1. Um grafo dirigido é também chamado de dígrafo e consiste de uma tripla ordenada (N. Um grafo é conectado (conexo) se existe um caminho entre dois vértices quaisquer do grafo.y) de nós Na função g. vn). v2. x é o ponto (extremidade) inicial e y o ponto final de a. vn conectados por arestas (v1. …. Um laço é um arco com extremidades n-n. O comprimento de um caminho é dado pelo número de arcos que ele contém. para algum nó n. Um grafo sem ciclos é chamado de acíclico. Dois arcos com as mesmas extremidades são ditos paralelos.A. (v2. exceto o primeiro e o último. Além da orientação podem ser impostos pesos. Um circuito é um caminho onde o vértice final é igual ao inicial. num não dirigido esta ordem é indiferente. um par ordenado (x.Um grafo pode ser dirigido ou não dirigido. … (vn . onde cada arco tem um valor numérico associado. Um circuito simples é chamado de ciclo. Dado um grafo. onde: N = Um conjunto não vazio de nós A = Um conjunto de arcos g = Função que associa a cada arco. Um grafo G = (V. dizemos que um vértice é adjacente a outro vértice.1.g). se existe no grafo uma aresta que une os dois. Uma fonte é um vértice com grau de entrada 0 e grau de saída > 1. No dirigido a ordem dos vértices importa. As arestas são também consideradas como parte do caminho. v2).

obj ln é o linker e cc o compilador.obj b.obj : a. b.obj b.obj b.c cc -c c .obj" será mais novo que prog que será linkado por "ln -o prog a.obj c. Eliminação de Código Morto Podemos representar um procedimento como um grafo onde as instruções são vértices e existe aresta dirigida de v para w se w é executado após v (ou pode ser executado.c prog.h b.obj c. goto L1.c cc -c b.c"). no caso de if’s e while’s). se algum di for mais novo que Nome.obj : b. porque ele será mais novo que "b.c for modificado.obj a. por exemplo.obj ". Make lê este texto e executa Comandos se a data de última atualização de algum arquivo di for mais nova que de Nome. Então "b.Nome : d1 d2 … dn Comandos Nome é o nome de um arquivo que depende dos arquivos d1 d2 … dn. As relações de dependências do make podem ser colocada em forma de um grafo.obj".c prog prog.c a. Ou seja. .: prog : ln -o a. ele executa Comandos.obj c. A função void f( { if (i > 0) { j = 1.h a.obj : c. que são comandos para o Unix que possivelmente deverão atualizar arquivo Nome. Ex. make irá compilá-lo novamente (Comando "cc -c b.c cc -c c. Se.

Exercícios Será cobrado na prova transformação de códigos em grafos e verficação de sua utilidade. } else j = 10. A resposta para o grafo acima é : não. return 1. } seria transformada no grafo Para descobrir o código morto. fazemos uma busca a partir da primeira instrução do procedimento marcando todos os vértices visitados. . As instruções correspondentes aos vértices não visitados nunca serão executados e podem ser removidos pelo compilador.a = 10. L1. Note que com este mesmo grafo pode-se descobrir se a instrução return será executada por todos os caminhos que ligam o vértice inicial ao vértice "fim da função".

Sign up to vote on this title
UsefulNot useful