Metodos de Analise, Desenho e Implementacao de Sistemas

MANUAL DO CURSO DE LICENCIATURA EM
GSI
2º Ano
Disciplina: Métodos de Analise, Desenho e Implementação de

SI
Código:
Total Horas/1o Semestre:
Créditos (SNATCA):
Número de Temas:
INSTITUTO SUPER
INSTITUTO SUPERIOR DE CIÊNCIAS E EDUCAÇÃO A DISTÂNCIA - ISCED

ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI
Direitos de autor (copyright)
Este manual é propriedade do Instituto Superior de Ciências e Educação a Distância (ISCED), e

contém reservados todos os direitos. É proibida a duplicação ou reprodução parcial ou total
deste manual, sob quaisquer formas ou por quaisquer meios (electrónicos, mecânico, gravação,
fotocópia ou outros), sem permissão expressa de entidade editora (Instituto Superior de Ciências
e Educação a Distância (ISCED).
A não observância do acima estipulado o infractor é passível a aplicação de processos judiciais

em vigor no País.
Instituto Superior de Ciências e Educação a Distância (ISCED)

Direcção Académica
Rua Dr. Almeida Lacerda, No 212 Ponta - Gêa
Beira - Moçambique
Telefone: +258 23 323501
Cel: +258 82 3055839
Fax: 23323501
E-mail: isced@isced.ac.mz
Website: www.isced.ac.mz
i
Agradecimentos
O Instituto Superior de Ciências e Educação a Distância (ISCED) agradece a colaboração dos

seguintes indivíduos e instituições na elaboração deste manual:
Autor Msc.Solomone Rumhungwe
Direcção Académica do ISCED

Coordenação
Instituto Superior de Ciências e Educação a Distância (ISCED)
Design
Instituto Africano de Promoção da Educação a Distancia (IAPED)
Financiamento e Logística
Revisão Científica e Português

Linguística
Ano de Publicação 2018
Local de Publicação ISCED – BEIRA
ii
Índice
iii
Visão geral 1
Benvindo à Disciplina/Módulo de Analise, Desenho e Implementação de Sistema de
Informação......................................................................................................................... 1
Objectivos do Módulo ....................................................................................................... 1
Quem deveria estudar este módulo .................................................................................. 2
Como está estruturado este módulo .................................................................................. 2
Ícones de actividade.......................................................................................................... 4
Habilidades de estudo ...................................................................................................... 4
Precisa de apoio? .............................................................................................................. 6
Tarefas (avaliação e auto-avaliação) ............................................................................... 6
Avaliação .......................................................................................................................... 7
TEMA – I: CONCEITOS GERAIS DE PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 9

UNIDADE Temática 1.1. Introdução, Conceitos Gerais e Ciclo da vida e atividade de um
processo. ............................................................................................................................ 9
Introdução .......................................................................................................................... 9
Sumário............................................................................................................................ 15
Exercícios de AUTO-AVALIAÇÃO .................................................................................... 15
Exercícios para AVALIAÇÃO ........................................................................................... 15
Unidade Temático1.2: Análise: Elicitação e especificação de requisitos ......................... 15
TEMA -II: MODELAGEM DE SISTEMA DE INFORMAÇÃO 25

UNIDADE Temática 2.1. Introdução, Diagramas de UML, Historia, Diagrama de Caso de
Uso, Aplicação Pratica e Estudo de Caso ........................................................................ 25
Introdução ........................................................................................................................ 25
UNIDADE temático 2.2: Os Modelos- Diagrama de Classe, Descrição de caso de uso,
Diagramas de Interação, diagrama de Atividade e Aplicação Prática ......................... 33
UNIDADE Temática 2.3. Diagrama de Implementação - Componente e Implantação .... 60
Sumário............................................................................................................................ 65
Exercícios de AUTO-AVALIAÇÃO .................................................................................... 65
Exercícios para AVALIAÇÃO ........................................................................................... 69
Exercícios do TEMA .......................................................................................................... 71
TEMA – III: IMPLEMENTACAO 71

UNIDADE Temática 3.1. Introdução, Atividades relacionadas ao código-fonte do Sistema
........................................................................................................................................ 71
Introdução ........................................................................................................................ 71
UNIDADE Tematico 3.2. Modelagem de Processo Desenvolvimento de Software –
Introdução, Modelo Cascada, em fonte , Espiral , Iterativo/Incremental e Ágeis ........... 73
UNIDADE Temático 3.3. Processo Unificado .................................................................... 87
UNIDADE Temático 3.4. Padrões de Implementação ...................................................... 93
Sumário.......................................................................................................................... 101
Exercícios de AUTO-AVALIAÇÃO .................................................................................. 102
Exercícios para AVALIAÇÃO ......................................................................................... 107
iv
TEMA -IV: TESTE DE SOFTWARE 107

UNIDADE Temática 4.1. Importância do teste de software ........................................... 108
Introdução ...................................................................................................................... 108
UNIDADE Temático 4.2 – Teste no projeto de sistema .................................................. 114
UNIDADE Temático 4.3 – Teste no Programa................................................................ 117
UNIDADE Temático 4.4 – Teste na implantação do sistema .......................................... 124
UNIDADE Temático 4.5 – Teste de software em sistema em produção......................... 126
Unidade Temático 4.6 – Ferramentas de teste de software ......................................... 132
v
Visão geral
Benvindo à Disciplina/Módulo de Analise, Desenho e

Implementação de Sistema de Informação
Objectivos do Módulo
Ao terminar o estudo deste módulo de Analise, Desenho e

Implementação de Sistema de Informação deverá ser capaz de:
apresentar o processo de desenvolvimento de uma aplicação desde
os requerimentos do sistema até o desenho da aplicação usando
conceitos de modelado UML para produzir diagramas detalhados.
Pretende-se que o estudante seja capaz de identificar e definir os
requisitos de um sistema e proceda ao desenho de Software
centrado em objectos que satisfaça estes requisitos. Além disso,
pretende-se que o estudante aplique metodologias padrão durante
o processo de análise, desenho e desenvolvimento de Software com
ênfase nos padrões de desenho
▪ Demonstrar uma compreensão do processo de desenvolvimento de

Literatura Fundamental Analise, Desenho Orientada ao Objecto
(ADOO);
▪ Apreciar UML como um modelo para o sistema de Software
Orientada a objecto (OO) típico;
Objectivos
Específicos ▪ Apresentar conceitos ligados ao processo como a própria definição e o
encadeamento das fases.
▪ Introduzidos conceitos de modelagem de sistemas e da linguagem de
modelagem UML
▪ Familiarizar os leitores com o uso de ferramenta case para capaz de
modelar aplicações utilizando UML.
▪ Novo programa de classes OO e pacotes usando os conceitos de
herança e polimorfismo;
▪ Demonstrar uma compreensão básica do uso de padrões de desenho
na conceção de sistemas de Software OO;
▪ Programa de interfaces gráficas usando alguns dos pacotes OO
padrão.
▪ Desenvolver aplicativos autônomos usando desenho e implementação
de abordagens reutilizáveis
1
▪ Investigar requisitos do usuário

▪ Definir, claramente, as necessidades do sistema
▪ Criar (ou adaptar) uma solução adequada
▪ Definição de tecnologias e arquitetura a serem adotadas
▪ Desenvolver a solução Proposta
▪ Garantir que a solução resolverá o problema em questão
▪ Modificar a solução sempre que novos requisitos forem identificados
Quem deveria estudar este módulo
Este Módulo foi concebido para estudantes do 2º ano do curso de

licenciatura em GSI do ISCED. Poderá ocorrer, contudo, que haja
leitores que queiram se actualizar e consolidar seus conhecimentos
nessa disciplina, esses serão bem-vindos, não sendo necessário para
tal se inscrever. Mas poderá adquirir o manual.
Como está estruturado este módulo
Este módulo de ADISI, para estudantes do 2º ano do curso de

licenciatura em GSI, à semelhança dos restantes do ISCED, está
estruturado como se segue:
Páginas introdutórias
▪ Um índice completo.
▪ Uma visão geral detalhada dos conteúdos do módulo, resumindo
os aspectos-chave que você precisa conhecer para melhor
estudar. Recomendamos vivamente que leia esta secção com
atenção antes de começar o seu estudo, como componente de
habilidades de estudos.
2
Conteúdo desta Disciplina / módulo
Este módulo está estruturado em Temas. Cada tema, por sua vez
comporta certo número de unidades temáticas ou simplesmente
unidades. Cada unidade temática se caracteriza por conter uma
introdução, objectivos, conteúdos.
No final de cada unidade temática ou do próprio tema, são
incorporados antes o sumário, exercícios de auto-avaliação, só
depois é que aparecem os exercícios de avaliação.
Os exercícios de avaliação têm as seguintes características: Puros
exercícios teóricos/Práticos, Problemas não resolvidos e actividades
práticas, incluído estudo de caso.
Outros recursos
A equipa dos académicos e pedagogos do ISCED, pensando em si,

num cantinho, recôndito deste nosso vasto Moçambique e cheio de
dúvidas e limitações no seu processo de aprendizagem, apresenta
uma lista de recursos didácticos adicionais ao seu módulo para você
explorar. Para tal o ISCED disponibiliza na biblioteca do seu centro
de recursos mais material de estudos relacionado com o seu curso
como: Livros e/ou módulos, CD, CD-ROOM, DVD. Para além deste
material físico ou electrónico disponível na biblioteca, pode ter
acesso a Plataforma digital moodle para alargar mais ainda as
possibilidades dos seus estudos.
Auto-avaliação e Tarefas de avaliação
Tarefas de auto-avaliação para este módulo encontram-se no final

de cada unidade temática e de cada tema. As tarefas dos exercícios
de auto-avaliação apresentam duas características: primeiro
apresentam exercícios resolvidos com detalhes. Segundo, exercícios
que mostram apenas respostas.
Tarefas de avaliação devem ser semelhantes às de auto-avaliação
mas sem mostrar os passos e devem obedecer o grau crescente de
dificuldades do processo de aprendizagem, umas a seguir a outras.
Parte das terefas de avaliação será objecto dos trabalhos de campo
a serem entregues aos tutores/docentes para efeitos de correcção e
subsequentemente nota. Também constará do exame do fim do
módulo. Pelo que, caro estudante, fazer todos os exercícios de
avaliação é uma grande vantagem.
3
Comentários e sugestões
Use este espaço para dar sugestões valiosas, sobre determinados

aspectos, quer de natureza científica, quer de natureza didáctico-
Pedagógica, etc, sobre como deveriam ser ou estar apresentadas.
Pode ser que graças as suas observações que, em gozo de confiança,
classificamo-las de úteis, o próximo módulo venha a ser melhorado.
Ícones de actividade
Ao longo deste manual irá encontrar uma série de ícones nas margens
das folhas. Estes ícones servem para identificar diferentes partes do
processo de aprendizagem. Podem indicar uma parcela específica
de texto, uma nova actividade ou tarefa, uma mudança de
actividade, etc.
Habilidades de estudo
O principal objectivo deste campo é o de ensinar aprender a

aprender. Aprender aprende-se.
Durante a formação e desenvolvimento de competências, para

facilitar a aprendizagem e alcançar melhores resultados, implicará
empenho, dedicação e disciplina no estudo. Isto é, os bons resultados
apenas se conseguem com estratégias eficientes e eficazes. Por isso é
importante saber como, onde e quando estudar. Apresentamos
algumas sugestões com as quais esperamos que caro estudante possa
rentabilizar o tempo dedicado aos estudos, procedendo como se
segue:
1º Praticar a leitura. Aprender a Distância exige alto domínio de

leitura.
2º Fazer leitura diagonal aos conteúdos (leitura corrida).
3º Voltar a fazer leitura, desta vez para a compreensão e

assimilação crítica dos conteúdos (ESTUDAR).
4º Fazer seminário (debate em grupos), para comprovar se a sua

aprendizagem confere ou não com a dos colegas e com o padrão.
5º Fazer TC (Trabalho de Campo), algumas actividades práticas ou

as de estudo de caso se existirem.
IMPORTANTE: Em observância ao triângulo modo-espaço-tempo,

respectivamente como, onde e quando...estudar, como foi referido
no início deste item, antes de organizar os seus momentos de estudo
reflicta sobre o ambiente de estudo que seria ideal para si: Estudo
4
melhor em casa/biblioteca/café/outro lugar? Estudo melhor à

noite/de manhã/de tarde/fins-de-semana/ao longo da semana?
Estudo melhor com música/num sítio sossegado/num sítio barulhento!?
Preciso de intervalo em cada 30 minutos, em cada hora, etc.
É impossível estudar numa noite tudo o que devia ter sido estudado
durante um determinado período de tempo; Deve estudar cada ponto
da matéria em profundidade e passar só ao seguinte quando achar
que já domina bem o anterior.
Privilegia-se saber bem (com profundidade) o pouco que puder ler e

estudar, que saber tudo superficialmente! Mas a melhor opção é
juntar o útil ao agradável: Saber com profundidade todos conteúdos
de cada tema, no módulo.
Dica importante: não recomendamos estudar seguidamente por

tempo superior a uma hora. Estudar por tempo de uma hora
intercalado por 10 (dez) a 15 (quinze) minutos de descanso (chama-
se descanso à mudança de actividades). Ou seja que durante o
intervalo não se continuar a tratar dos mesmos assuntos das
actividades obrigatórias.
Uma longa exposição aos estudos ou ao trabalho intelectual

obrigatório pode conduzir ao efeito contrário: baixar o rendimento
da aprendizagem. Por que o estudante acumula um elevado volume
de trabalho, em termos de estudos, em pouco tempo, criando
interferência entre os conhecimentos, perde sequência lógica, por fim
ao perceber que estuda tanto mas não aprende, cai em insegurança,
depressão e desespero, por se achar injustamente incapaz!
Não estude na última da hora; quando se trate de fazer alguma

avaliação. Aprenda a ser estudante de facto (aquele que estuda
sistematicamente), não estudar apenas para responder a questões de
alguma avaliação, mas sim estude para a vida, sobre tudo, estude
pensando na sua utilidade como futuro profissional, na área em que
está a se formar.
Organize na sua agenda um horário onde define a que horas e que

matérias deve estudar durante a semana; Face ao tempo livre que
resta, deve decidir como o utilizar produtivamente, decidindo quanto
tempo será dedicado ao estudo e a outras actividades.
É importante identificar as ideias principais de um texto, pois será

uma necessidade para o estudo das diversas matérias que compõem
o curso: A colocação de notas nas margens pode ajudar a estruturar
a matéria de modo que seja mais fácil identificar as partes que está
a estudar e Pode escrever conclusões, exemplos, vantagens,
definições, datas, nomes, pode também utilizar a margem para
5
colocar comentários seus relacionados com o que está a ler; a melhor

altura para sublinhar é imediatamente a seguir à compreensão do
texto e não depois de uma primeira leitura; Utilizar o dicionário
sempre que surja um conceito cujo significado não conhece ou não lhe
é familiar;
Precisa de apoio?
Caro estudante, temos a certeza que por uma ou por outra razão, o
material de estudos impresso, lhe pode suscitar algumas dúvidas como
falta de clareza, alguns erros de concordância, prováveis erros
ortográficos, falta de clareza, fraca visibilidade, página trocada ou
invertidas, etc). Nestes casos, contacte os serviços de atendimento e
apoio ao estudante do seu Centro de Recursos (CR), via telefone, sms,
E-mail, se tiver tempo, escreva mesmo uma carta participando a
preocupação.
Uma das atribuições dos Gestores dos CR e seus assistentes
(Pedagógico e Administrativo), é a de monitorar e garantir a sua
aprendizagem com qualidade e sucesso. Dai a relevância da
comunicação no Ensino a Distância (EAD), onde o recurso as TIC se
torna incontornável: entre estudantes, estudante – Tutor, estudante –
CR, etc.
As sessões presenciais são um momento em que você caro estudante,
tem a oportunidade de interagir fisicamente com staff do seu CR, com
tutores ou com parte da equipa central do ISCED indigitada para
acompanhar as sua sessões presenciais. Neste período pode
apresentar dúvidas, tratar assuntos de natureza pedagógica e/ou
administrativa.
O estudo em grupo, que está estimado para ocupar cerca de 30%
do tempo de estudos a distância, é muita importância, na medida em
que lhe permite situar, em termos do grau de aprendizagem com
relação aos outros colegas. Desta maneira ficará a saber se precisa
de apoio ou precisa de apoiar aos colegas. Desenvolver hábito de
debater assuntos relacionados com os conteúdos programáticos,
constantes nos diferentes temas e unidade temática, no módulo.
Tarefas (avaliação e auto-avaliação)
O estudante deve realizar todas as tarefas (exercícios, actividades e

auto−avaliação), contudo nem todas deverão ser entregues, mas é
importante que sejam realizadas. As tarefas devem ser entregues
duas semanas antes das sessões presenciais seguintes.
Para cada tarefa serão estabelecidos prazos de entrega, e o não
cumprimento dos prazos de entrega, implica a não classificação do
estudante. Tenha sempre presente que a nota dos trabalhos de campo
conta e é decisiva para ser admitido ao exame final da
disciplina/módulo.
6
Os trabalhos devem ser entregues ao Centro de Recursos (CR) e os

mesmos devem ser dirigidos ao tutor/docente.
Podem ser utilizadas diferentes fontes e materiais de pesquisa,
contudo os mesmos devem ser devidamente referenciados,
respeitando os direitos do autor.
O plágio1 é uma violação do direito intelectual do(s) autor(es). Uma
transcrição à letra de mais de 8 (oito) palavras do testo de um autor,
sem o citar é considerado plágio. A honestidade, humildade científica
e o respeito pelos direitos autorais devem caracterizar a realização
dos trabalhos e seu autor (estudante do ISCED).
Avaliação
Muitos perguntam: Com é possível avaliar estudantes à distância,

estando eles fisicamente separados e muito distantes do
docente/tutor! Nós dissemos: Sim é muito possível, talvez seja uma
avaliação mais fiável e consistente.
Você será avaliado durante os estudos à distância que contam com
um mínimo de 90% do total de tempo que precisa de estudar os
conteúdos do seu módulo. Quando o tempo de contacto presencial
conta com um máximo de 10%) do total de tempo do módulo. A
avaliação do estudante consta detalhada do regulamentado de
avaliação.
Os trabalhos de campo por si realizados, durante estudos e
aprendizagem no campo, pesam 25% e servem para a nota de
frequência para ir aos exames.
Os exames são realizados no final da cadeira disciplina ou modulo e
decorrem durante as sessões presenciais. Os exames pesam no mínimo
75%, o que adicionado aos 25% da média de frequência,
determinam a nota final com a qual o estudante conclui a cadeira.
A nota de 10 (dez) valores é a nota mínima de conclusão da cadeira.
Nesta cadeira o estudante deverá realizar pelo menos 2 (dois)
trabalhos e 1 (um) (exame).
Algumas actividades práticas, relatórios e reflexões serão utilizados
como ferramentas de avaliação formativa.
Durante a realização das avaliações, os estudantes devem ter em
consideração a apresentação, a coerência textual, o grau de
cientificidade, a forma de conclusão dos assuntos, as recomendações,
a identificação das referências bibliográficas utilizadas, o respeito
pelos direitos do autor, entre outros.
Os objectivos e critérios de avaliação constam do Regulamento de
Avaliação.
1
Plágio - copiar ou assinar parcial ou totalmente uma obra literária, propriedade
intelectual de outras pessoas, sem prévia autorização.
7
TEMA – I: CONCEITOS GERAIS DE PROCESSO DE DESENVOLVIMENTO DE SOFTWARE
UNIDADE Temática 1.1. Introdução, Conceitos Gerais: objectivos e

Ciclo da vida e atividades de um processo.
UNIDADE Temática 1.2. Análise: Elicitação e especificação de
requisitos
UNIDADE Temática 1.4. EXERCÍCIOS deste tema
UNIDADE Temática 1.1. Introdução, Conceitos Gerais e Ciclo da vida e atividade

de um processo.
Introdução
O ciclo de vida de um sistema Software incluem análises e

especificação de requisitos, desenho, implementação, testagem,
instalação e manutenção. Engenharia de Software é a disciplina que
se ocupa de todas as fases do ciclo de vida, tentando conseguir a
construção de sistemas, que satisfaçam os requisitos dos usuários e dos
clientes, duma forma eficiente.
Para atingir este objetivo se utilizam metodologias para definir o

processo completo da vida de um sistema. Entre estas metodologias
destaca por sua madureza e uso na indústria do Software a
metodologia UP /RUP, baseada no uso de iterações para construir
Software de forma incremental e que utiliza UML como forma de
expressar numa linguagem comum, o conhecimento relativo ao
problema e a solução do sistema a construir.
▪ As fases de elicitação e especificação de requisitos, análise e

projeto têm uma importância enorme no contexto de um rocesso
de desenvolvimento de software devido ao fato de identificarem
Objectivos
específicos o que deve ser desenvolvido (requisitos e análise) e estabelecer
como desenvolver (projeto). Portanto, os conceitos de eliciação e
especificação de requisitos, análise e projeto de sistemas são, de
modo a fornecer uma visão geral destas atividades no contexto
do desenvolvimento de software
Sistema
9
É um conjunto de procedimentos que estabelecem o funcionamento do

fluxo de trabalho (Workflow) das organizações.
Ex: Secretária que organiza o agendamento dos pacientes de

um consultório médico.
É um conjunto de instruções que, orquestradas entre si, manipulam um

conjunto de dados afim de produzir informação e eventos.
Ex1: Sistema Web de agendamento de consultas médicas

(Informação)
Ex2: Sistema de Monitoramento de alerta de tempestades

(Evento)
Sistema vs Software
O software é a automatização de um sistema.
Nem todo sistema é automatizado.
Ex: Agendamento manual de consultas médicas.
O software é tanto o produto quanto o veículo para entregar o

produto (PRESSMAN, 2002)
Ex: Um relatório gerencial em PDF é o produto, assim como

o sistema usado na sua geração.
Software
O software é o conjunto de vários artefatos e não apenas o código

fonte (SOMMERVILLE, 2003).
Realizando uma comparação entre o software e hardware. Chegamos

a seguinte conclusão. O software apenas pode ser desenvolvido e
realizar a manutenção (mudança) no software é uma tarefa omplicada,
exige grande esforço da equipe de engenheiro de software. Ao passar
do tempo o software fica deteriorado. Já para o hardware apenas
pode ser fabricado e realizar a manutenção no hardware é
implesmente trocar à peça que esta em desgaste. Ao passar do tempo
o hardware desgasta por vários motivos (PRESSMAN, 2006).
O software é caro porque torna se uma atividade difícil e trabalhosa

de ser realizado pelo engenheiro de software (JALOTE, 2005).
De acordo Pressman (2006) o software estão categorizados em

seguintes tipos, tais como:
Software de sistema. São programas que apóiam outros programas,

como o software que realiza a comunicação com o hardware (sistema
10
operacional) e software que ajuda na construção de outro software

(compiladores).
Software de aplicação. São programas que são desenvolvidos para

executar no negócio de uma empresa determinada.
Software científico e de engenharia. São algoritmos que processam

números.
Software embutido. São programas construídos para executarem

dentro de um produto específico como a teclas digitais de um forno
micro ondas.
Software para linhas de produtos. São os softwares conhecidos como

software de prateleiras.
Software de web. São aplicativos que são executados via Internet.
Software de inteligência artificial. São softwares que fazem os usos

de algoritmos não numéricos. Estes tipos software se encaixam na
robótica.
Computação ubíqua. São softwares que realiza a verdadeira

computação distribuída.
Software aberto. São software que disponibiliza a visualização do

código fonte da aplicação para o engenheiro de software modifica da
maneira que deseja.
Software Legado
O nome de software legado é dado quando refere se num programa

de computador que foi desenvolvido por há muito tempo. A reocupação
do engenheiro de software com os softwares legados esta na baixa
qualidade do software. Muitas vezes não existem documentações e se
existem são pobres de detalhes, os casos de teste são pobres quando
tem e sem um controle de mudanças. E muitas vezes não mexem no
software legado quando eles atentem as necessidades do cliente
(PRESSMAN, 2006).
Engenharia de Software
Engenharia de software é uma abordagem sistemática e disciplinada

para o desenvolvimento de software (PRESSMAN, 2006).
Uma das grandes dificuldades da engenharia do software é resolver o

problema e deixar o cliente satisfeito com o software (JALOTE, 2005).
11
Na demonstração da figura 1 representa uma visão do engenheiro de

software em desenvolver o software que traz uma grande satisfação
para o usuário quando ele próprio utiliza o software.
A engenharia de software foca no software como produto. Não entra

neste escopo o softwares construídos apenas para passarem o tempo
dos programadores (PAULA FILHO, 2009).
No desenvolvimento de um projeto de software quanto mais complexo

é o software, maior é o empenho que o engenheiro de software deve
fazer para desenvolver e tem que ter maior gerenciamento (JALOTE,
2005).
Na demonstração da figura 2 representa uma comparação entre

projetos de software grande e pequeno. Verificar que quanto maior é
a complexidade do software mais atenção deve ter para a construção
do software.
A base da engenharia de software são conjuntos de atividades para o

processo de desenvolvimento de software. A existência de vários tipos
de processo de desenvolvimento de software e podemos dizer para
resolver o problema do software usam estas atividades tais como:
analise de requisito, design do software, código e teste (JALOTE,
2005).
Analise de requisito. Através da analise de requisito é o momento onde

efetua o conhecimento do problema para desenvolve o software
(JALOTE, 2005).
Design do software. Pelo design do software é o momento que o

engenheiro de software realiza o planejamento da solução do
problema que foi levantado no documento de requisito (JALOTE, 2005).
Codificação. A codificação é o momento que pega o problema

resolvido no design do software e transformará em uma linguagem de
programação (JALOTE, 2005).
12
Teste. O teste de software é o processo tem a intenção de encontrar

defeitos nos artefatos de software (MYERS, 2004). O teste é uma
maneira de medir o controle da qualidade do software durante o
desenvolvimento de software (JALOTE, 2005).
Engenharia de Software
“É a criação e a utilização de sólidos princípios de engenharia a fim

de obter software de maneira econômica, que seja confiável e que
trabalhe eficientemente em máquinas reais.” (Fritz Bauer)
Evolução do Software
No início, os softwares eram muito pequenos, dadas as limitações

de hardware.
Com o crescimento do poder computacional, cresce também o

tamanho e a complexidade do software .
Várias técnicas surgiram para ajudar na administração dessa

complexidade:
• Técnicas ligadas à linguagens de programação;

• Aprofundamento dos estudos na Engenharia de Software;
• Arquitetura de Software;
• Ferramentas CASE.
Tava tudo bonito até que...
Crise do Software
“A maioria dos especialistas concorda que o modo mais provável de o
mundo ser destruído é por acidente. É onde nós entramos. Somos
profissionais de computação. Nós causamos acidentes” (Nathaniel
Borenstein)
Anos 60, mas se arrasta até hoje segundo pesquisa do Standish Group
(2009)
• 18% dos projetos são cancelados por atrasos e orçamentos
estourados;
• 52% dos projetos estouram o orçamento e/ou prazo;
• 30% de todos os projetos de TI atingem seus objetivos dentro
de prazo e custo estimados.
Outros motivos:
13
• Taxa de rotatividade de pessoal elevada – Entre 20% e 30%

ao ano
• Grandes sistemas levando de 3 a 5 anos para serem
desenvolvidos. Muitos deles se tornando obsoletos antes de
serem entregues – Natimortos
• Manutenção de software responsável pelo maior custo
relacionado a computação para a maioria das empresas da
área
• Segundo Sommerville (2007), os problemas a seguir foram
definidos como desafios-chave a serem superados:
• Heterogeneidade - Técnicas de desenvolvimento para
construção de software que possam lidar com ambientes
heterogêneos.
• Entrega - Técnicas de desenvolvimento para conduzir a entrega
mais rápida de software .
• Confiança - Técnicas de desenvolvimento que mostram que o
software pode ter a confiança dos seus usuários.
• Crise, mas nem tanto...
• Apesar dos problemas relatados persistirem de alguma forma,
até hoje, vivenciamos muito mais casos de sucessos que
insucessos.
• Alguns autores defendem que nunca existiu crise de software .
Apenas uma Aflição Crônica (TEICHROW, 1989)
• Aflição: “Qualquer coisa que causa dor ou desconforto”.
• Crônica: “de longa duração ou que volta frequentemente”
• Processo de Desenvolvimento de Software (PDS)
• É a estrutura comum, composta por um pequeno número de
atividades, que são utilizadas em todos os projetos de software
(PRESSMAN, 2002).
• Há muitos modelos para esses processos, cada um descrevendo
abordagens diferentes para uma variedade de tarefas a serem
executadas durante o processo.
Ciclo de Vida e atividade de um processo
Todo ciclo de desenvolvimento tem início, meio e fim.
14
A variável temporal desse processo é chamada de Ciclo de Vida
Todo processo é composto de atividades executadas,

coordenadamente, num encadeamento de fases.
Compreende todas das atividades relacionadas à definição,

desenvolvimento, teste e manutenção do software.
Existem vários processos. Cada um com a sua aplicabilidade.
Sumário
Nesta Unidade temática 1.1 estudamos e discutimos conceitos gerais de

Processo de desenvolvimento de Software, tipos de software,
engenharia do software e Ciclo de vida e actividade de um preocesso
Exercícios de AUTO-AVALIAÇÃO
Perguntas
Respostas: 1A, 2C, 3V…
Exercícios para AVALIAÇÃO
Perguntas
Unidade Temático1.2: Análise: Elicitação e especificação de requisitos
Análise De Sistemas
Processo de reunir e interpretar factos, diagnosticar problemas, utilizar
estes factos para melhorar o sistema.
Na maior parte dos casos, o desenvolvimento de SI´s corresponde a
projectos de grande dimensão, envolve a participação de vários grupos
de stakeholders (técnicos e não técnicos), agrega várias componentes e
tecnologias na sua estrutura (dados,
15
processo e interfaces) e faz uso de várias técnicas e metodologias para

apoiar o desenvolvimento das etapas que compõem o processo. De
acordo com Whitten [5], hoje em dia grande parte dos SI’s suportam
uma estrutura em torno de três componentes diferentes (Fig. 1):
Processo de análise da situação de negócio, com o propósito de o
melhorar através de procedimentos e métodos mais adequados.
(i) Dados - componente que corresponde à camada mais profunda
de um SI e é nela que se armazena todo o material potencialmente
informativo (em bruto);
(ii) Processo - componente que corresponde à camada intermédia
onde é colocada toda a lógica aplicacional de modo a permitir uma
correcta passagem de dados/informação com a máxima garantia de
segurança;
(iii) Interface - componente que corresponde à camada onde são
estabelecidos os principais pontos de contacto entre o sistema e o
exterior, quer para inputs de dados, quer para outputs de informação.
Ainda que estas componentes se encontrem em todos os tipos de SI’s, a
sua identificação vai sendo cada vez mais fácil à medida que passamos
de uma filosofia de SI’s tradicionais (ex: aplicações locais) para SI’s
distribuídos (ex: aplicações Web), uma vez que nestes, as três
componentes encontram-se logicamente e fisicamente separadas,
necessitando de uma quarta (rede) para integrar as três anteriores. Por
este motivo (dispersão das componentes), o tratamento que cada
componente em particular requer na construção do SI torna-se mais
especial no caso dos SI’s distribuídos.
16
Estrutura de construção de um SI – adaptado de [Whitten et al. 2001].
Hoje em dia a maior parte dos projectos de SI’s desenvolvidos têm

características que os permitem classificar como SI’s distribuídos. A
descrição feita ao longo deste manual irá considerar essa tendência,
fazendo uma abordagem ao PDSI para o caso dos SI’s distribuídos na
Web (aplicações Web) e, confrontando essa abordagem com o caso
dos SI’s tradicionais. O desenvolvimento de SI’s é efectuado ao longo
de várias etapas, contando com a participação de vários stakeholders.
Os stakeholders técnicos que colaboram directamente no
desenvolvimento da solução, tais como:
(i) Analista de sistemas - tem como função principal coordenar os
esforços dos restantes elementos participantes, desempenhando o papel
de facilitador ao longo do processo. Geralmente está presente em
todas as fases de desenvolvimento com importância especial nas fases
inicias. Nestas, estuda o problema conjuntamente com o proprietário do
sistema e determina as necessidades conjuntamente com os potenciais
utilizadores, elaborando um relatório (denominado habitualmente como
‘especificação’) para posteriormente ser trabalhado pelos projectistas;
(ii) Projectistas - geralmente especialistas tecnológicos que
traduzem os requisitos descritos na especificação para soluções técnicas
utilizando, para tal, uma linguagem de modelização adequada. Neste
17
grupo podemos ainda encontrar os especialistas de usabilidade

responsáveis pelo projecto de interfaces.
(iii) Programadores - os especialistas tecnológicos, que trabalham
no último elo da cadeia de desenvolvimento, com a responsabilidade
de converter todo o trabalho resultante da etapa anterior para uma
linguagem interpretável e executável pelo computador, assim como
instalar e acompanhar a fase de arranque do novo sistema. Neste
grupo podemos ainda encontrar os especialistas de usabilidade
responsáveis pelo projecto de interfaces.
Os stakeholders não técnicos, embora não integrando directamente a
equipa de projecto, contribuam (de forma muito importante) param o
sucesso do resultado final, através das suas propostas e sugestões a
nível de requisitos funcionais e não-funcionais; sendo assim:
(iv) Utilizadores – são todas as pessoas que irão interagir com o
sistema, tendo um papel fundamental na identificação dos requisitos
(funcionais e alguns requisitos não-funcionais);
(v) Proprietários do sistema - um dos principais beneficiários com a
integração do novo sistema, são também o principal responsável pelo
financiamento do projecto, podendo tratar-se do proprietário da
organização do qual o sistema irá fazer parte ou, simplesmente, de
sócios ou administradores da mesma. O seu contributo para o
desenvolvimento do sistema é muito importante, uma vez que se trata
do principal detentor do conhecimento do negócio, missão da
organização e consequente alinhamento dos objectivos pretendidos com
o sistema.
Para além destes, é necessário auscultar os consultores e vendedores
das tecnologias de informação, uma vez que também estes são
detentores do conhecimento tecnológico que irá constituir a base de
suporte do sistema a desenvolver.
Análise do problema
Nesta etapa, primeira do ADISI, o analista reúne com o proprietário (ou
outro responsável da organização) para clarificar o problema e discutir
propostas de resolução. As técnicas utilizadas para a recolha de dados
18
são, basicamente, reuniões, técnicas de observação directa e análise da

documentação existente.
Como resultado desta etapa, tem-se um relatório (Especificação 1 – Fig.
2) com a descrição da resolução do problema devidamente
contextualizada no sistema organizacional e alinhada com o modelo de
negócios da organização. Passa-se, então, à etapa seguinte, ou seja, à
validação da proposta junto dos potenciais utilizadores.
Etapas, técnicas e métodos no ADISI.
Elicitação e especificação de requisitos

Para que um projeto de desenvolvimento de software seja considerado
de sucesso, uma das premissas é que o produto gerado atenda o que o
cliente deseja. Na grande maioria dos casos o cliente não sabe ao
certo o que deseja e por este motivo a descrição das funcionalidades
esperadas por parte do cliente pode mudar no decorrer do projeto.
Portanto, há a necessidade de documentação das necessidades do
cliente.
Quando estas descrições não são escritas ou são escritas e não são
validadas com o cliente, é comum que no momento da entrega o cliente
expresse que o produto não é o que ele havia solicitado anteriormente.
19
Este é um dos grandes erros que os desenvolvedores individuais ou

micro empresas de desenvolvimento de software que não se preocupam
com requisitos estão sujeitas. Veja a seguinte imagem (Figura 3) que
explicita de forma lúdica o que a ausência do uso das técnicas de
Engenharia de software causa nas fases iniciais do desenvolvimento de
software
Fases Iniciais do Desenvolvimento sem Técnicas de Engenharia de Software.
Como comprovar que o produto desenvolvido está em conformidade com

o que foi solicitado?
A solução para esta situação é utilizar descrições do sistema, onde as

necessidades são documentadas e validadas pelo cliente. Deste modo o
escopo do software é delimitado, alinhado e acordado entre o cliente e
fornece -dor (equipe de desenvolvimento) do software.
20
Requisito é o nome dado a este conjunto de documentos que descrevem

os serviços a serem oferecidos pelo sistema e restrições operacionais de
modo a satisfazer as necessidades do cliente.
Requisito é o nome dado a este conjunto de documentos que descrevem

os serviços a serem oferecidos pelo sistema e restrições operacionais de
modo a satisfazer as necessidades do cliente.
Outro fator que demonstra a importância de requisitos é a necessidade

de manter rastreabilidade entre os artefatos, tendo em vista que os
demais artefatos são evoluções do documento de requisitos no decorrer
do projeto.
Especificação
• Última fase da tarefa de análise

• É necessário que seja escrito de forma não ambígua qual é o
comportamento requerido
✓ Notações formais
✓ Documentos estruturados
✓ Exemplos
• Artefatos de Entrega (Saída)
Especificação de requisitos que comunique ao projetista as características

requeridas para o sistema, usando Casos de Uso Descritivos
• Diagramas de Casos de Uso
Possíveis Falhas
✓ Documentação insuficiente para o entendimento do

problema
✓ Retrabalho
✓ Ocasiona atraso na execução das fases posteriores
• Desenhar uma solução que seja fiel aos requisitos
✓ Com base na experiência acumulada (e técnicas
padronizadas)
• Geralmente precisam inovar em um certo nível
21
• É possível que surjam várias soluções

• Recomenda-se o uso de alguma métrica para a escolha da melhor
solução para o projeto
• Fase de definição de diversas tecnologias:
✓ Linguagem de Programação
✓ Padrões de Projetos
✓ Materializados na adoção de frameworks
✓ IDE
✓ Banco de Dados
✓ Etc.
• Artefatos de Entrega (Saída)
✓ Um documento de projeto que, de forma não ambígua
e clara, comunica o projeto com a equipe que irá
implementar o software.
✓ Recomenda-se que contenha:
▪ Concepção arquitetural
▪ Ferramentas a serem adotadas
▪ Frameworks
▪ Etc.
• Artefatos de Entrega (Saída) (cont.)
✓ Diagramas Estruturais
▪ Diagrama de Classes
▪ Diagrama de Componentes
▪ Etc.
✓ Diagramas Comportamentais
▪ Diagrama de Atividades
▪ Diagrama de Sequência
▪ Diagrama de Máquina de Estados
▪ Etc.
✓ Modelagem de dados
Possíveis Falhas:
✓ Arquitetura do software difícil de ser replicada para

a equipe
22
✓ Curva de aprendizagem desfavorável
Em linhas gerais, o desenvolvimento dos artefatos ocorre da seguinte

forma no decorrer do projeto.
1. O documento de requisitos é criado a partir do levantamento

realizado;
2. Especificações de casos de uso a partir do documento de
requisitos;
3. Diagramas da UML são criados para cada especificação de caso
de uso;
4. O código é desenvolvido a partir dos diagramas gerados e da
especificação de caso de uso (ou história do usuário);
5. As planilhas de teste são criadas tendo como base a
especificação de caso de uso (ou história do usuário);
6. Quando o cliente vai realizar a validação do software
desenvolvido, os requisitos que foram aceitos por ele são
utilizados como parâmetro para validar o sistema;
7. Finalmente, quando o software será evoluído, o documento de
requisitos é a raiz das mudanças a serem implementadas.
Ferramentas de modelagem
Na atividade de desenvolvimento, as ferramentas auxiliam a
criação de có -digo com mais qualidade e menor esforço,
aumentando a produtividade de programadores. Geralmente
estas ferramentas são desenvolvidas para en -contrar erros à
medida que o desenvolvedor digita os comandos de seu pro -
grama e possuem depuradores que facilitam a descoberta do
trecho que causou a falha. Eclipse e Dev são exemplos de
ferramentas de desenvol -vimento, conhecidas como IDE (
Integrated Development Environment – Ambiente de
Desenvolvimento Integrado).
Paralelamente, as ferramentas de modelagem têm um papel
central nesta atividade. A sua importância advém do fato de que
ferramentas projeta -das tomando como base os princípios
estabelecidos na linguagem propiciam a boa formação dos
23
modelos gerados, reduzindo erros e aumentando a pro -

dutividade na execução das atividades de análise e projeto.
Várias ferramentas de modelagem têm sido propostas tomando
por base a UML, podemos citar:
• astah - http://astah.net/
•Rational Rose- http://www-01.ibm.com/software/awdtools/developer/rose
•Jude- http://jude.change-vision.com/jude-web/product/index.html
(Ver -são anterior do astah)
• ArgoUML - http://argouml.tigris.org/
• DIA - http://projects.gnome.org/dia/
• Fujaba - http://www.fujaba.de/
• StarUML - http://staruml.sourceforge.net/en/
• Umbrello - http://uml.sourceforge.net/
•VisualParadigm- http://www.visual-paradigm.com/download/
Muitas vezes o software de modelagem disponibiliza duas
versões: uma gratuita e outra paga. Este é o caso do astah, que
disponibiliza uma versão gratuita: o astah community e outras
versões astah Professional e astah UML que são do tipo Trial
(gratuitas apenas para teste). A diferença entre elas encontra-se
nas funcionalidades disponíveis, com o a versão Professional é
pos -sível gerar código a partir dos diagramas e realizar
engenharia reversa (Gerar diagramas a partir do código Java,
C++ ou C#), o que não é possível com a versão Community. A
ferramenta é de fácil uso e o instalador está disponível para
down load em http://members.change-vision.com/files/astah_community
Sumário
Nesta Unidade temática 1.2 estudamos e discutimos Análise de sistema

que inclui Elicitação e especificação de requisitos
Perguntas
24
Perguntas
TEMA -II: MODELAGEM DE SISTEMA DE INFORMAÇÃO
UNIDADE Temática 2.1. Introdução, Diagrama de UML: Diagrama de

Caso de Uso, Aplicação pratica e estudo de caso.
UNIDADE Temática 2.2. Os Modelos: Diagrama de Classe, Descrição
de caso de uso, Diagramas de Interação, diagrama de Atividade e
Aplicação Prática
UNIDADE Temática 2.3. Diagrama de Implementação: Componente e
Implantação
UNIDADE Temática 2.1. Introdução, Diagramas de UML, Historia, Diagrama de

Caso de Uso, Aplicação Pratica e Estudo de Caso
Introdução
A modelação do sistema representa a etapa onde toda a informação

textual descrita na especificação é convertida para uma linguagem
gráfica, de maneira a facilitar a comunicação entre os diferentes
membros da equipa de projecto, nomeadamente os programadores
que irão trabalhar sobre os modelos. Ainda que o analista esteja
envolvido nesta etapa, a sua participação é menos activa, uma vez que
esta tarefa é da responsabilidade directa do projectista. É nesta fase
que se faz a ‘ponte’ entre a solução descrita na especificação e a
implementação dessa solução, fazendo uso de uma determinada
linguagem gráfica (metodologia). O trabalho efectuado nesta fase não
acrescenta informação, apenas converte para modelos, existindo
alguma propensão para se perder informação, quando não se utilizam
os métodos adequados. Por esta razão, é precisamente neste ponto que
se deve ter cuidado, para que nenhum trabalho efectuado
anteriormente tenha aqui o seu fim. Desta forma, é muito importante
utilizar um método adequado ao tipo de SI, de forma a garantir uma
correcta passagem de informação entre a fase anterior e a fase da
implementação.
25
Análise específica o que é que o sistema deve fazer. Desenho

apresenta como é que o sistema deve ser desenvolvido.
Objetivo
Solucionar problemas do mundo real, fazendo uso da linguagem UML
na representação de modelos.
Diagramas de UML
• Por que surgiu?

– Para instituir padronização na forma de desenvolvimento de
softwares, pois era desenvolvido de forma imediatista, baseado no
conhecimento dos técnicos, sem garantia de continuidade.
• O que é?
26
– É a definição de métodos, técnicas e ferramentas que devem ser

aplicados para ordenar o desenvolvimento e se obter maior qualidade.
A Importância da Modelagem
É comum ouvir dizer que “Uma imagem vale mais que mil palavras”.
Em desenvolvimento de sistemas não podia ser diferente.
Um modelo representa melhor o negócio do que vários escritos de
especificação.
Um modelo oferece facilidade de comunicação entre as partes (usuário
e técnico), documentação para garantir a continuidade e apoio na
implementação.
Princípios de Modelagem
Todo modelo possui um propósito e simbologia própria para
representação do negócio.
Deve-se conhecer a forma de expressão do modelo para que a
comunicação seja estabelecida corretamente e a leitura seja fiel ao
contexto apresentado.
Unified Modelling Language:
Linguagem de modelagem que irá se associar ao processo para formar
método.
Representação desenvolvida a partir da aplicação de técnicas com
características próprias para atender a natureza da aplicação em
estudo.
Técnicas possuem uma comunicação direta e se completam.
Para utilizar a UML deve-se quebrar paradigmas e ter uma visão
sistêmica e funcional abrangente.
Histórico
A UML tem origem na compilação das "melhores práticas de
engenharia" que provaram ter sucesso na modelagem de sistemas
grandes e complexos.
Sucedeu aos conceitos de Booch, OMT (Rumbaugh) e OOSE (Jacobson)
fundindo-os numa única linguagem de modelagem comum e largamente
utilizada.
A UML pretende ser a linguagem de modelagem padrão para modelar
sistemas concorrentes e distribuídos.
27
Os esforços para a criação da UML tiveram início em outubro de 1994,

quando Rumbaugh se juntou a Booch na Rational.
Com o objetivo de unificar os métodos Booch e OMT, decorrido um ano
de trabalho, foi lançado, em outubro de 1995, o esboço da versão 0.8
do Unified Process - Processo Unificado (como era conhecido).
Nesta mesma época, Jacobson se associou à Rational e o escopo do
projeto da UML foi expandido para incorporar o método OOSE.
Nasceu então, em junho de 1996, a versão 0.9 da UML.
Finalmente em 1997, a UML foi aprovada como padrão pelo OMG
(Object Management Group), um consórcio internacional de empresas
que define e ratifica padrões na área de Orientação a Objetos.
Atualmente encontra-se na versão 2.2
Aplicação
– A UML foi definida para ser utilizada na Metodologia Orientada a

Objetos, o que significa que ela possui recursos para representação dos
conceitos propostos pela metodologia.
• É possível utilizar em outras metodologias!!!!
Objetivo
– Ser independente da linguagem de programação e processo de
desenvolvimento.
28
Não se utiliza obrigatoriamente todos os modelos em todos os projetos.

Deve-se utilizar o que melhor representar o contexto do negócio.
Diagrama de Casos de Uso
• Modelo aplicado para representar os requisitos de sistema.
• O que são requisitos?
– São as necessidades dos usuários, as funcionalidades necessárias
para realizar o negócio.
• Quais são os tipos?
– Funcionais: Ligados a produção da aplicação.
– Não-funcionais: Necessidades de ambiente e estrutura operacional
(operacionalidade, ambiente operacional, etc.);
Caso de Uso: Simbologia
29
• Simbologia – Interação de Casos de Uso

<<include>> Estabelece a ligação obrigatória entre os casos de
uso. SEMPRE o caso de uso será executado
<<extend>> estabelece a ligação opcional entre os casos de uso. O

caso de uso será executado em atendimento a uma regra de negócio.
30
Simbologia – Generalização de Ator
Representa a classificação de um determinado ator
Deve ser usada quando:

Temos mais de um ator realizando a mesma tarefa e, algumas tarefas
diferenciadas.
Concentra em um caso de uso um conjunto de procedimentos que serão
utilizados por vários outros casos de uso que possuem outras
particularidades.
31
• Passos para construção:
1.Leia atentamente o estudo de caso e identifique os requisitos e os
responsáveis por realizar os requisitos;
2.Crie uma lista de atores e requisitos;
3.Inicie a construção do modelo verificando quem é o responsável por
.realizá-lo: ator ou outro caso de uso.
4.Sendo o ator: represente o modelo.
5.Sendo outro caso de uso verifique se essa interação é de
<<include>> ou <<extend>>.
6.Verifique se existe generalização.
Estudo de Caso
• Estacionamento “Parque de Estacionamento”
• Diariamente o estacionamento “Parque da Estácio” recebe vários
clientes para aluguel de suas vagas e possui uma rotina destinada ao
bom atendimento.
• O gerente do estacionamento cadastra todas as vagas com sua
devida localização e situação. No caso de algum impedimento, goteira
e obra, por exemplo, as vagas são interditadas para uso.
• O veículo é identificado (Placa, Cor e modelo) na entrada e
registrado pelo atendente/recepcionista, que emite um comprovante e
cadastra o cliente que for recebido pela 1ª vez. A locação da vaga
registra data e hora de entrada, identifica o motorista e atendente/
recepcionista e, bloqueia a vaga.
32
• A liberação é efetivada a partir da solicitação do cliente, que

entrega ao atendente/recepcionista o seu comprovante de locação,
realiza o pagamento e recebe uma autorização de saída.
São registradas data e hora de saída e a vaga é liberada para um
próximo cliente.
• O motorista retira o carro da vaga e entrega-o ao cliente.
Sumário
Nesta Unidade temática 2.1 estudamos e discutimos fundamentalmente

……
Perguntas
Perguntas
UNIDADE temático 2.2: Os Modelos- Diagrama de Classe, Descrição de caso de

uso, Diagramas de Interação, diagrama de Atividade e Aplicação Prática
Diagrama de Classe
Modelo aplicado para representar as informações necessárias para
realização das funcionalidades do sistema em estudo a partir do
conceito de CLASSE.
Exemplo:
33
• O que é CLASSE?
• Antes é preciso saber o que OBJETO.
• Exemplo: Em um negócio de vendas, quais os elementos movimentam a
execução do negócio?
SIM!!! SÃO OBJETOS DO NEGÓCIO

• OBJETO: Todo elemento que representa ou compõe algum conceito
dentro de nosso projeto.
• CLASSE: Conjunto de objetos com atributos e comportamentos
representados por métodos.
Ex.: Classe CLIENTES representa todos os clientes da empresa.
• ATRIBUTO: Característica ou identificação do objeto.
Ex.: nome, cpf, email,
• MÉTODOS: Operações realizadas param um objeto.
Ex.: lerNome ()
Diagrama de Classe – Simbologia
34
Para identificar uma classe devemos analisar se o objeto:

• Possui vida própria;
• Possui mais de um atributo;
• Deseja-se acompanhar existência;
• ASSOCIAÇÃO ligação estabelecida entre as classes, por necessidade

de comportamentos do negócio analisado.
35
• PAPEL nome da associação, tornando claro no diagrama o ligação

estabelecida.
• MULTIPLICIDADE define o número de vezes em que o objeto
participa da associação.
MULTIPLICIDADE
– Deve ser representada utilizando os dois sentidos de leitura, sempre
associado a um objeto com o resultado na outra classe e levando em
consideração os comportamentos desejados do negócio que está sendo
analisado.
– A representação de multiplicidade possui o seguinte esquema:
– Li ... Ls, onde: Li define o Limite inferior
– Ls define o Limite superior
– Li e Ls poderão ter valores numéricos de 0 a n e
– Ls poderá também ter a representação * que tem como significado
infinito/muitos.
CLASSE ASSOCIATIVA
– Classe que representa os objetos resultados de uma associação, com
atributos, características e operações próprias.
36
RESTRIÇÕES
– Complementam o modelo com informações não representadas.
• AGREGAÇÃO POR REFERÊNCIA

– Define o conceito <compõe> e associa os objetos indicando que
existe referência para várias participações.
37
AGREGAÇÃO POR VALOR

– Define o conceito <estar inserido> associando os objetos indicando
que existe referência para apenas uma participação e estabelece uma
dependência entre as classes associadas.
Passos para desenvolvimento

1. Identificar no diagrama de caso de uso os objetos que possuem
identificação própria e precisam ter essas informações guardadas
para atendimento dos requisitos de sistema: Essas são as classes.
2. Identificar a ligação que existe entre os objetos.
3. Estabelecer as associações na melhor forma de representação da
natureza do negócio.
Diagrama de Classe
• Estacionamento “Parque de Estacionamento”
▪ Diariamente o estacionamento “Parque de Estacionamento” recebe
vários clientes para aluguel de suas vagas e possui uma rotina
destinada ao bom atendimento.
38
▪ O gerente do estacionamento cadastra todas as vagas com sua

devida localização e situação. No caso de algum impedimento,
goteira e obra, por exemplo, as vagas são interditadas para uso.
▪ O veículo é identificado (Placa, Cor e modelo) na entrada e
registrado pelo atendente/recepcionista, que emite um
comprovante e cadastra o cliente que for recebido pela 1ª vez. A
locação da vaga registra data e hora de entrada, identifica o
motorista e atendente/recepcionista e, bloqueia a vaga.
▪ A liberação é efetivada a partir da solicitação do cliente, que
entrega ao atendente/recepcionista o seu comprovante de locação,
realiza o pagamento e recebe uma autorização de saída. São
registradas data e hora de saída e a vaga é liberada para um
próximo cliente.
▪ O motorista retira o carro da vaga e entrega-o ao cliente.
Estudo de Caso – Caso de Uso
• AUTO ASSOCIAÇÃO
– Define quando um objeto de uma classe está relacionado com outro

objeto da mesma classe para atender a algum comportamento. A
multiplicidade é estabelecida normalmente.
39
• GENERALIZAÇÃO / ESPECIALIZAÇÃO
– Generalização: Representa os vários tipos de um objeto em uma única

classe.
– Especialização: Representa os vários tipos de um objeto em uma

classe distinta relacionando seus próprios atributos e comportamentos.
– Atributos e comportamentos comuns são relacionados na classe mãe.
40
Passos para desenvolvimento
• 1º Passo - Buscar no escopo do projeto os conjuntos de objetos que

tenham identificação própria. (Analisaros casos de uso de cadastro,
por exemplo);
• 2º Passo - Analisar os atributos das classes para identificar
aqueles que indicam outras classes. Esta identificação gera a
associação entre as classes;
• 3º Passo - Buscar conjuntos de objetos inseridos no contexto do
estudo que servem para controlar e acompanhar as atividades do
projeto;
• 4º Passo - Relacionar atributos destas classes;
• 5º Passo – Criar novas classes e associações considerando as
formas normais:
Primeira Forma Normal: Uma relação está na primeira forma
normal se todos os seus atributos são monovalorados.
Segunda Forma Normal: a relação estiver na primeira forma
normal; e todos os atributos primos dependerem funcionalmente de
toda a chave primária.
Terceira Forma Normal: a relação estiver na segunda forma
normal; e todos os atributos primos dependerem não transitivamente
de toda a chave primária.
• 6º Passo – Criar novas classes e associações identificando atributos
que definem vários objetos da classe.
• 7º Passo - Definir as multiplicidades;
• 8º Passo - É sabido que o diagrama de classe deve dar suporte à
realização dos casos de uso. Verificar se o diagrama de classe
possui atributos para atender a todos os procedimentos. Se não
estiver, complementar o diagrama de classe.
• 9º Passo - O caso de uso também deverá criar e manter as
informações do diagrama de classe. Verificar se todas as classes e
atributos estão sendo contemplados na realização dos casos de uso.
Se não estiver, complementar o diagrama de caso de uso.
• Sistema de Gestão de Hotel Estacio
• O cadastro do hóspede (nome, procedência, endereço, contato,

previsão de permanência) é realizado pelo setor de recepção
que também controla a alocação de quarto/apartamento
(número do quarto ou apartamento) e abertura de uma conta
corrente para o hóspede (senha, número da conta, nome do
hospede).
41
• Ao setor de serviço de copa cabe a responsabilidade pelos

lançamentos, na conta do hospede, das despesas que o mesmo
efetuar com bebidas e comidas (data, tipo da despesa e valor).
• A atendente/recepcionista de telefonia é responsável pelo
lançamento, na conta do cliente, das chamadas interurbanas que
o mesmo venha a fazer (data, local chamado, duração e tarifa).
• As chamadas locais não são computadas.
• O setor de lavanderia é responsável pelos lançamentos, na
conta do hóspede, dos serviços que o mesmo venha a solicitar
àquele setor (data, tipo de serviço, valor).
• A gerência pode, a qualquer instante, ter acesso às informações
de cadastro e gastos realizados pelo hóspede.
• A gerência é responsável pelo cadastro e atualização das
tabelas de serviços, menus e diárias.
• O hóspede pode a qualquer instante consultar o saldo de sua
conta.
• O setor de recepção é responsável pela extração do extrato
final da conta e fechamento da mesma quando o hóspede
finaliza sua estadia.
42
Descrição de Casos de Uso

• A Descrição de caso de uso é a representação textual dos casos de
uso. Deve ser utilizada para complementar o modelo, pois muitas regras
de negócio estão implícitas ao caso de uso. Este recurso ajuda a validar
se a compreensão dos requisitos foi plena.
• A descrição registra a funcionalidade lógica e é o documento
comprobatório de nosso levantamento, onde o usuário poderá validar o
nosso entendimento.
A descrição de caso de uso é desenvolvida para cada caso de uso. As
interações devem ser citadas na abrangência da descrição, mas não
deve definir dois casos de uso em uma só descrição. Quanto mais clara
a definição melhor o entendimento.
• A descrição poderá ser desenvolvida de duas formas:

Descrição não Expandida e Descrição Expandida.
Formação: Cabeçalho + descrição
43
• Descrição não Expandida prevê a apresentação sucinta dos

procedimentos, como um pequeno relato apresentando os objetivos a
serem atingidos. Deve ser utilizada quando o Caso de Uso for de
conhecimento completo de todos, não possuir exceções ou, utilizar
mecanismos de outro caso de uso.
• Exemplo “Parque de Estácionamento”: Utilizando o Caso de Uso
“Emitir autorização de saída”:
– Nome: Emitir Autorização de saída
– Objetivo: Gerar comprovante de quitação do aluguel da vaga.
– Pré-condição: estar com a locação fechada.
– Pós-condição: não há
• Exemplo “Estacionamento Praça da Estácio”:

• Utilizando o Caso de Uso “Emitir autorização de saída”:
• Descrição
• Emitir autorização de saída, Formulário 005, a partir das informações
de fechamento de locação.
• Descrição Expandida prevê a apresentação detalhados
procedimentos, apresentando os objetivos a serem atingidos passo-a-
passo e com referência a responsabilidade se ator ou sistema.
• Devemos considerar a descrição em duas partes: Fluxo Normal e
Fluxo Alternativo.
• Fluxo Normal é o passo-a-passo dos procedimentos sem desvio. Uma
lista de procedimentos considerando os passos frequentes e sem
exceção.
• Fluxo Alternativo é o passo-a-passo dos procedimentos de exceção
e condições alternativas para
44
determinado passo do Fluxo Normal. Não são todos os passos citados

no Fluxo Normal que terá citação no Fluxo Alternativo.
• Exemplo “Parque de Estacionamento”:
– Utilizando o Caso de Uso “Registrar Locação”:
Na Descrição Expandida, para consumar uma descrição consistente é

necessário um projeto de interface, mesmo que não possua todas as
configurações visuais. O importante é representarmos a funcionalidade
básica e não os detalhes de programação.
• 1º Passo: IDEALIZAR A INTERFACE
• 2º passo: CABEÇALHO
– NOME........... : Registrar Locação
– DESCRIÇÃO.: O atendente identifica o veiculo em sua entrada no
estacionamento e cadastra sua ocupação da vaga.
– Pré-Condição: Ter acesso a interface.
45
– Pós-Condição: VAGA estará bloqueada

• 3º Passo: Descrever FLUXO NORMAL
• FLUXO NORMAL
1.Sistema Apresenta Tela de Locação.
2.Vendedor Informa Placa de VEÍCULO.
3.Sistema obtém dados de VEÍCULO.
4.Sistema obtém dados de CLIENTE.
5.Sistema apresenta dados de CLIENTE.
6.Sistema obtém dados de VAGA.
7.Sistema apresenta lista de VAGA.
8.Vendedor escolhe VAGA.
9.Vendedor clica CONFIRMA.
10.Sistema altera VAGA.
11.Sistema Inclui “Emitir

Comprovante de Locação”
12.Sistema Encerra Caso De Uso.
• 4º Passo: Descrever FLUXO ALTERNATIVO
• FLUXO ALTERNATIVO
• 3. Sistema obtém dados de VEÍCULO.
– 3.1 Não há registro de VEÍCULO
• 3.1.1 Sistema estende “Cadastrar Veículo”.
• 3.1.2 Sistema retorna para item 4.
• 4º Passo: Descrever fluxo normal
– 4. Sistema obtém dados de CLIENTE.
• 4.1 Não há registro de CLIENTE
– 4.1.1 Sistema estende “Cadastrar Cliente”.
– 4.1.2 Sistema retorna para item 5.
– 5. Vendedor clica Cancela.
• 5.1 Sistema retorna para item 1.

46
• OBSERVAÇÕES:
– Não possuímos no nosso Diagrama o Caso de Uso “Cadastrar

Cliente”, item 4.1.1 da descrição. A necessidade surgiu durante a
especificação. Quando isto ocorre é necessário voltarmos ao diagrama
e incluir este novo caso de uso;
– Mais uma vez deve ser comentado que a cada modelo/técnica

utilizada deve-se estar pronto a recomeçar, pois é possível sempre
estar descobrindo falhas ou complementos
Descrição de Casos de Uso
• A especificação de caso de uso também disponibiliza um recurso para

informações adicionais do tipo, vagas bloqueadas terão código “B”.
Para isto, retornamos a especificação e incluímos um COMENTÁRIO
entre asteriscos imediatamente após o passo desejado;
• Outra informação relevante para ser incluída em comentário é a
tecla utilizada para fim, quando for o caso;
• Fluxo Normal
1.Sistema Apresenta Tela de Locação.
2.Vendedor Informa Placa de VEÍCULO.
3.Sistema obtém dados de VEÍCULO.
4.Sistema obtém dados de CLIENTE.
5.Sistema apresenta dados de CLIENTE.
6.Sistema obtém dados de VAGA.
7.Sistema apresenta lista de VAGA.
47
8.Vendedor escolhe VAGA.

9.Vendedor clica CONFIRMA.
11.Sistema Inclui “Emitir Comprovante de Locação”
• Portanto, deve-se preocupar em apresentar os detalhes necessários
para:
– Usuário aferir o atendimento do requisito;
– Avaliar as restrições;
– Dar segurança ao projeto no sentido do programador ter
entendimento completo;
– Documentação;
•REGRAS:
– Para descrever um caso de uso é preciso a aplicação de regras, pois
assim é definido um padrão de entendimento entre o usuário e o
técnico. Dentre as regras podemos destacar:
• Estabelecer o diálogo entre o usuário e o sistema.
• Adotar sentenças curtas,
• Os passos devem ser numerados, sequenciados logicamente;
• A primeira e a última sentença são comandadas pelo sistema;
• Deve-se utilizar um padrão de linguagem;
• Descrição não representa condição e repetição;
• Descrição não representa controles técnicos (críticas, fim de leitura);
• Não é preciso fluxo alternativo para todas as sentenças relacionadas
no fluxo normal. Apresentar somente quando necessário.
• Podem-se utilizar comentários para complementar a informação “***
comentários”;
• Para representar os INCLUDES utilizar <INCLUIR>;
• Para representar os EXTENDS utilizar <ESTENDER>.
• EXERCÍCIO:
48
• Dado o seguinte diagrama de caso de uso e diagrama de classe de

um sistema de locação de carros.
• EXERCÍCIO:
– Interface
• EXERCÍCIO:
• Segue a DESCRIÇÃO EXPANDIDA
– Nome: Alugar Veículos
– Descrição: Registra o aluguel do veículo do cliente.
– Pré-condição: Veículo deve estar cadastrado e disponível
– Pós-Condição: Locação definida
• Fluxo Normal:
– 1. Sistema apresenta tela;
– 2. Sistema apresenta lista de modelos disponíveis;
– 3. Sistema apresenta lista de cor;
49
– 4. Ator escolhe modelo;

– 5. Sistema apresenta dados do veículo;
– 6. Sistema apresenta lista de Clientes;
– 7. Ator escolhe Nome do Cliente
– 8. Ator informa data de aluguel e número de dias;
• EXERCÍCIO (cont..):
– 9. Sistema calcula data devolução;
– 10. Ator confirma operação clicando em “Ok”;
– 11. Sistema <inclui> “Emitir Contrato”;
• EXERCÍCIO:
– 12. Sistema cria locação;
– 13. Sistema Atualiza veículo
– ***Situação = indisponível
– 14. Sistema encerra caso de uso
• EXERCÍCIO
– Revendo os modelos já produzidos...
– 2. Sistema apresenta lista de modelos disponíveis;
• Diagrama de Interação
– Conceitos Básicos
– Diagrama de Sequencia
– Diagrama de Sequencia de Sistema - DSS
– Diagrama de Colaboração
– Aplicação
Relembrar...
50
• Conceitos:
– O Diagrama de Interação apresenta a relação entre os objetos e a
troca de mensagens que são necessárias para efetivar a realização do
comportamento.
– O Diagrama de Interação representa um único caso de uso e deve ser
usado quando se deseja visualizar os comportamentos utilizados pelos
vários objetos dentro do caso de uso.
– Diagramas de interação são apresentados sob duas formas na UML
através do Diagrama de Sequência e Diagrama de Comunicação.
• DIAGRAMA DE SEQUÊNCIA:
– Representa a sequência lógica dos comportamentos dentro do caso
de uso. Portanto a leitura é realizada de cima para baixo e, da
esquerda para direita.
– Os elementos utilizados para compor o diagrama são os seguintes:
• DIAGRAMA DE SEQUÊNCIA – SIMBOLOGIA
51
52
DIAGRAMA DE SEQUÊNCIA – EXEMPLO – FLUXO NORMAL

1. Sistema Apresenta Tela de Locação.
53
2. Vendedor Informa Placa de VEÍCULO.
3. Sistema obtém dados de VEÍCULO.
4. Sistema obtém dados de CLIENTE.
5. Sistema apresenta dados de CLIENTE.
6. Sistema obtém dados de VAGA.
7. Sistema apresenta lista de

VAGA.
8. Vendedor escolhe VAGA.
9. Vendedor clica CONFIRMA.
11.Sistema Inclui “Emitir Comprovante de Locação”
• DIAGRAMA DE COMUNICAÇÃO
– Era conhecido como Diagrama de Colaboração (UML 1.5)
– Apresenta objetos e classes envolvidas no cenário e a ligação entre

eles apresentando a forma de navegação e visibilidade.
– Os elementos utilizados para compor o diagrama são os seguintes:
• DIAGRAMA DE COMUNICAÇÃO – SIMBOLOGIA
Ligação
1. A primeira mensagem não é numerada;
54
2. A ordem e o alinhamento são mostrados com um esquema de

numeração cardinal.
Sequencia:
Auto Delegação:
Criação de instância
55
Diagramas de Interação
• A diferença básica é que no Diagrama de Sequência conseguimos
visualizar claramente a sequência da troca de mensagens entre os
objetos, sendo válido para avaliação da consistência das operações.
• No Diagrama de Comunicação esta sequência não fica totalmente
clara, mas é possível interpretar todas as mensagens recebidas pelos
objetos, sendo muito válido para definição de parâmetros,
planeamento de desenvolvimento e outros aspectos para o projeto em
si.
Diagrama de Atividade - Conceito

• O diagrama de atividade permite escolher a ordem pela qual as
coisas devem ser feitas, isto é, indica meramente as regras essenciais de
sequência que necessitam ser seguidas - esse é um aspecto fundamental
para diferenciar um diagrama de atividade de um fluxograma.
• Fluxogramas são limitados a processos sequenciais enquanto
Diagramas de Atividade podem manipular processos paralelos.
• O ponto forte do diagrama de atividade reside no fato de suportar e
encorajar comportamento paralelo, tornando-se uma boa técnica para
a modelagem de fluxo de trabalho e programação para
multiprocessamento.
Diagrama de Atividade – Simbologia
56
• Agrupam atividades relacionadas às responsabilidades que cumprem;

• Mostrar em qual parte da organização um trabalho é executado;
• Mostrar explicitamente onde são executadas ações (em qual objeto).
57
Inicio: Representa o início do diagrama.

Atividade: Tarefa que precisa ser feita. Representa um método sobre
uma classe.
Decisão: Representa comportamento condicional que a partir de uma
única entrada poderá gerar algumas saídas.
Intercalação: Representa comportamento condicional que a partir de
várias entradas poderá gerar apenas uma saída.
Separação: Conhecida também como “Barra de Sincronização”,
transições seguintes são efetuadas em paralelo independente da
sequência.
Junção: Transição seguinte efetuada somente quando todos os estados
nas transições de entrada tenham completado suas atividades.
Fim: Representa o fim do diagrama.
Representação de cada Caso de Uso complexa;
58
Desafio 1:
Desafio 2:
59
Sumário

……
Perguntas
Perguntas
UNIDADE Temática 2.3. Diagrama de Implementação - Componente e

Implantação
• Diagrama de Implementação
– Conceitos Básicos
Diagrama de Componentes
60
– Apresentação
– Simbologia
– Aplicação
Diagrama de Implantação
– Apresentação
– Simbologia
– Aplicação
Diagrama de Implementação
• A arquitetura física descreve a decomposição do hardware e
software que cercam a implementação de um sistema.
• Na UML, aspectos de implementação física são modelados através
de diagramas de implementação:
– Diagrama de componentes
– Diagrama de Implantação
Diagramas de Implementação permitem:

A descrição física do software: Os diagramas de componentes são
usados para modelar a arquitetura de um sistema na perspectiva dos
seus componentes de software (Ex: arquivos de código fonte, de
executáveis, de configuração, tabelas de dados, documentos de gestão
do projeto), explicitar principalmente as suas múltiplas dependências.
A descrição física do hardware: Os diagramas de instalação, por
outro lado, são usados para modelar a arquitetura de um sistema na
perspectiva dos seus componentes de hardware (Ex: computadores,
adaptadores de rede, impressoras, roteadores), explicitar as suas
dependências de comunicação.
A integração do software com o hardware: Os diagramas de
instalação com componentes são usados para modelar um determinado
ambiente de execução com componentes, através da identificação de
instâncias de componentes que são instaladas em determinada instância
de nó computacional.
Diagrama de Componentes
• Componentes modelam coisas físicas que podem residir em um nó,
como: executáveis, bibliotecas, tabelam, arquivos e documentos.
61
• Assim como na análise, para a implementação de um software é

necessário estabelecer qual a modelagem física do sistema executável.
• Um diagrama de componentes mostra as dependências entre
componentes de software, incluindo componentes de código fonte,
componentes de código binário e componentes executáveis.
• Um diagrama de componente é um grafo de componentes
conectados por relacionamentos de dependência.
Notação:
Exemplo
Diagrama de Implantação
• São utilizados para:
– Modelagem da visão estática de funcionamento de um sistema. Essa
visão é direcionada para a distribuição, entrega e instalação das
partes que formam o sistema físico.
– Visualizar, especificar e documentar sistemas embutidos,
cliente/servidor e distribuídos.
• Envolvem a topologia do sistema, descrevendo a estrutura de
hardware.
• Esses diagramas mostram:
62
– A configuração de nós de processamento em tempo de execução e os

componentes que neles existem.
– Componentes que não existem em tempo de execução não aparecem
nestes diagramas.
• São diagramas úteis também para a engenharia reversa
• NÓ:
• Um diagrama de implantação é um grafo de nós conectados por
associações de comunicação.
• Um nó é um objeto físico que representa um recurso computacional.
• Nós geralmente são computadores como processadores, e
dispositivos, como impressoras, leitoras de cartão, dispositivos de
comunicação, etc.
Composição UML
63
Conclusão
• Para obter sucesso no desenvolvimento de sistemas é necessário
utilizarmos modelos adequados a critérios de qualidade:
• Baixa manutenibilidade
• Grande iteratividade
• Boa performance
• Economia / segurança
• Disponibilidade / estabilidade
Exercício
• Construir um diagrama de componentes e de implantação,
representando a arquitetura de um sistema acadêmico, sendo a
aplicação um sistema web que grava as informações num SGBD
PROFISSIONAIS DE SISTEMAS DE INFORMAÇÃO

Analista de Sistemas ou Analistas de Informação
Determinar as necessidades de informação e requisitos de
processamento. Conduzir estudos relacionados com a actividade de
negócio.
Analista e Desenhador de Sistemas ou Desenhadores de sistemas ou
aplicações
Responsáveis pelo estudo exaustivo do negócio e pelo desenho do novo
sistema.
64
Analistas, Desenhadores e Programadores de Sistemas ou

programadores
Conduzem o projecto desde a análise do sistema, desenvolvem as
especificações e desenho, e programam o software que implementa o
desenho especificado.
Sumário
1. UML (Unified Modeling Language) tem como finalidade:

A) Executar atividades de controle de qualidade
B) Definir o processo de desenvolvimento de software
C) Modelar o sistema a ser desenvolvido.
D) Auxiliar na definição do escopo do software
E) Codificar o software
2. Assinale a alternativa que faz referência ao modelo iterativo
incremental de desenvolvimento de software:
A) Possui quatro atividades: planeamento, análise de riscos, engenharia
e avaliação do usuário.
B) Vulnerável a mudança de requisito.

C) Cada etapa só inicia com o término da anterior.
D) Trabalha com entregas parciais, até a conclusão do
desenvolvimento do escopo.
E) Usuário recebe produto antecipadamente, mas muitas vezes
incompletos.
3. Qual a relação das disciplinas de engenharia de software com o
ciclo de vida de software?
As disciplinas são as atividades necessárias para realizar o
desenvolvimento do software, e o ciclo de vida é quem define a
transições de fases no processo de desenvolvimento. É quem
coordena o trabalho a ser desenvolvido pelas disciplinas.
4. O diagrama de Casos de Uso é composto por 3 elementos básicos.
São eles:
A) Casos de Uso, Objetos e Diagramas
B) Atores, Casos de Uso e Interações
65
C) Classes, Casos de Uso e Diagramas

D) Atores, Classes e Interações
E) Classes, Casos de Uso e Interações
5. Sobre o diagrama de Casos de Uso, podemos afirmar que:
A) A interação <<include>> ocorre de forma obrigatória enquanto a
<<extend>> de forma opcional.
B) A interação <<include>> só ocorre se a <<extend>> for acionada.
C) A interação <<extend>> ocorre de forma obrigatória enquanto a
<<include>> de forma opcional.
D) Tanto a interação <<extend>> quanto a <<include>> são
opcionais.
E) Tanto a interação <<extend>> quanto a <<include>> são
obrigatórias.
6. Sobre o diagrama de Casos de Uso, podemos afirmar que:
A) A generalização de atores define uma cadeia de herança nas
permissões de acesso aos casos de uso
B) A generalização de casos de uso determina que um caso de uso será
executado por qualquer ator do modelo.
C) Sem uma definição prévia, todos o atores tem total permissão aos
casos de uso
D) O caso de uso representa uma classe do sistema
E) O Ator representa apenas requisitos funcionais do sistema
7. A estrutura condicional é um elemento que pode ser encontrado em
qual diagrama?
A) De Classes
B) De Casos de Uso
C) De Atividade
D) De Sequência
E) De Estados
8. Analise as assertivas a seguir e classifique cada uma como
verdadeiro (V) e falso (F):
1 - ( ) A Descrição de caso de uso não registra a lógica do sistema.
2 - ( ) A descrição de caso de uso, é representação textual dos casos de
uso e auxilia a validação do entendimento dos requisitos do sistema.
3 - ( ) Nem todos os casos de uso devem ser descritos.
4 - ( ) Quanto mais técnico forem os termos da descrição de casos de
uso, melhor será para apresentar ao usuário.
Com base em sua avaliação, assinale a alternativa que apresente a

correta sequência de V e F:
66
A) F, V, F, F
B) V, F, V, V
C) F, F, V, F
D) V, V, F, F
E) F, F, V, V
9. Qual diagrama tem a função de representar um objeto do mundo
real em termos conceituais de POO?
A) Diagrama de casos de usos.
B) Diagrama de classes.
C) Diagrama de atividades.
D) Diagrama de estados.
E) Diagrama de componentes.
10. Os diagramas UML da categoria comportamental são os de:
A) Classes, objetos e componentes.
B) Casos de uso e atividades
C) Objetos, estrutura composta e máquinas de estado.
D) Casos de uso, sequência e classes.
E) Classes, atividades e sequência
11. Considerando um sistema de supermercado onde o cliente pode
comprar vários produtos e cada produto pode ser comprado por vários
clientes, analise o modelo abaixo e indique o nome que se dá à
representação apresentada dentro do círculo?
A) Agregação por valor.

B) Classe associativa.
C) Agregação por
referência.
D) Auto-associação.
E) Generalização e
especialização.
12. Dentre as assertivas colocadas, escolha aquela que completa,
corretamente, as lacunas da seguinte proposição: Os diagramas de
_____ e _____ chamados diagramas de interação - são dois dos
diferentes diagramas utilizados na UML, para a modelagem dos
aspectos _______de sistema.
A) Sequência - atividade - dinâmicos
B) Sequência - colaboração - dinâmicos
C) Sequência - colaboração - estáticos
D) Sequência - atividade - estáticos
67
E) Gráfico de estado - colaboração – dinâmicos

13. Na UML (Unified Modeling Language), o _______________________
é utilizado para indicar as comunicações dinâmicas entre objetos
durante a execução de uma tarefa. Ele mostra a ordem temporal na
qual as mensagens são enviadas entre os objetos para executar aquela
tarefa.
A) Diagrama de Casos de Uso
B) Diagrama de Classes
C) Diagrama de Estados
D) Diagrama de Sequência
E) Diagrama de Comunicação
14. De acordo com o diagrama, podemos afirmar que:
A) A execução do caso de uso 'Consultar estoque' incorpora

opcionalmente o caso de uso 'Liberar desconto'.
B) A execução do caso de uso 'Liberar desconto' incorpora
opcionalmente o caso de uso 'Realizar venda'.
C) A execução do caso de uso 'Realizar venda' incorpora
obrigatoriamente o caso de uso 'Consultar estoque'.
D) A execução do caso de uso 'Realizar venda de produto nacional'
incorpora obrigatoriamente o caso de uso 'Liberar desconto'.
E) Um gerente pode interagir com o caso de uso 'Realizar venda', pois
ele é um Usuário.
15. Observe o diagrama e marque a alternativa correta:
68
A) SITUAÇÃO é uma classe dependente de carro, ou seja, não poderá

existir quando não participar da associação.
B) CARRO pode ser criado sem participar da associação, mas
CLIENTE somente poderá ser criado se participar pelo menos de uma
associação.
C) CLIENTE pode ser criado sem participar da associação, mas CARRO
somente poderá ser criado se participar pelo menos de uma
associação.
D) ALUGUEL é uma classe do tipo independente, onde serão
registradas as ocorrências de aluguel de carro.
E) CARRO e CLIENTE podem ser criados sem participar pelo menos de
uma associação.
1. Quais os elementos básicos de um Diagrama de Casos de Uso?

Descreva-os
Ator – Responsável por realizar o caso de uso. Pode se pessoas,

hardware ou software
Caso de Uso – Representa um requisito do sistema ou uma operação
Interações – Representa a realização do caso de uso
2. Quais os elementos básicos de um Diagrama de Classes? Descreva-
os.
Classe – Conjunto de objetos com atributos e comportamentos
representados por métodos
Atributos – Característica ou identificação do objeto
Métodos – Operações realizadas para um objeto
69
Associações – Ligação estabelecida entre as classes, por necessidade

de comportamentos do negócio analisado
3. Quais os elementos básicos de um Caso de Uso Descritivo?
Nome, Descrição, Pré-Condições, Fluxo Principal, Fluxo
Alternativo, Pós-Condições, etc.
4. Quais os elementos básicos de um Diagrama de Atividades?
Início, Raia, Atividade, Decisão, Separação ou “Barra de
Sincronização”, Junção, fim
5. Qual a finalidade dos Diagramas de Casos de Uso ?
A)Mostrar os relacionamentos entre os atores externos (pessoa,
software ou hardware) e os requisitos do sistema.
B) Treinar o usuário final na utilização da nova ferramenta.
C) Usar o plano de teste na fase final do projeto
D) Mostrar a sequência em que ações ocorrem no sistema.
E) Mostrar todas as classes utilizadas no sistema
6. Qual a diferença entre Requisitos Funcionais e Não Funcionais?
Requisitos funcionais – Descrevem as funções que o software deve
executar
Requisitos Não Funcionais – Descrevem a infraestrutura necessária
para a operação do software
7. Explique o que significa multiplicidade em um Diagrama de Classes?
Representa a informação dos limites inferior e superior da quantidade
de objetos aos quais um outro objeto pode estar associado.
8. Quais os elementos básicos de um Diagrama de Implantação?
Descreva-os
Componente – Modelam coisas físicas que podem residir em um nó,
como: executáveis, bibliotecas, tabelas, arquivos e documentos.
Interface – Elemento que possibilita acessarmos os recursos do
componente
Nó – É um objeto físico que representa um recurso computacional
(Servidores, impressoras, roteadores, etc.). Servem de container para os
componentes.
Dependência – Relacionamento do uso de uma interface de nó ou
componente
9. O que motivou a criação do Modelo de Desenvolvimento de
Software Iterativo Incremental?
Foi criado para suprir os problemas apresentados pelo modelo
cascada, onde uma fase só poderia ser iniciada quando todas as
atividades da fase anterior fossem concluídas. Esse modelo cria mini
ciclos, envolvendo todas as fases do projeto, para um determinado
70
conjunto de requisitos, até que todo o escopo do projeto seja

desenvolvido.
Exercícios do TEMA
Perguntas
TEMA – III: IMPLEMENTACAO
UNIDADE Temática 3.1. Introdução, Atividades relacionadas ao

código-fonte do Sistema
UNIDADE Temática 3.2. Modelagem de Processo Desenvolvimento de
Software – Introdução, Modelo Cascada, em fonte , Espiral ,
Iterativo/Incremental e Ágeis
UNIDADE Temática Processo Unificado
UNIDADE Temática 3.1. Introdução, Atividades relacionadas ao código-fonte do

Sistema
Introdução
A fase da implementação é da responsabilidade dos construtores ou

programadores, tendo estes que interpretar a informação contida nos
modelos e convertê-la para uma linguagem executável pelo
computador. É nesta fase que se faz a escolha da tecnologia mais
apropriada, podendo-se recorrer à ajuda dos vendedores ou
consultores tecnológicos. Qualquer SI, independentemente do tipo,
necessita de futuras intervenções a nível de manutenção de conteúdos;
por esta razão, no momento da implementação esse facto deve ser
compreendido em toda a sua extensão e para que o problema possa
ser devidamente enfrentado. Infelizmente, no caso dos SI distribuídos na
Web, o problema aumenta de complexidade, e muitas vezes
alterações simples a nível de interfaces podem envolver muito trabalho.
Se imaginarmos aplicações de grande dimensão, na ordem das
centenas de instâncias por classe, rapidamente se conclui que a
manutenção a nível das instâncias seria impensável. O ideal seria a
escolha de tecnologias, tais como, ASP, ASP.NET, PHP, JSP, que
71
permitam actualizações ou outro tipo de manutenção a nível das

classes, o que, por sua, permitirá simplificar bastantes intervenções
futuras no SI.
Atividades relacionadas ao código-fonte do sistema:
✓ Escrever
✓ Documentar
✓ Debugar
✓ Preparar a aplicação para testes
▪ Unitário
▪ Usuário
Artefatos de Entrega (Saída)
Código-fonte, de preferência, versionado
Documentação do código-fonte
Produto para teste
Possíveis Falhas:
Implementação em desacordo com o requisito.
Descumprimento de prazo
Dimensionamento equivocado do esforço a ser colocado nas tarefas de
implementação
Déficit técnico
Sumário

……
Perguntas
Perguntas
72
UNIDADE Tematico 3.2. Modelagem de Processo Desenvolvimento de Software

– Introdução, Modelo Cascada, em fonte , Espiral , Iterativo/Incremental e Ágeis
Processo Cascata (Water Fall) ou TOP DOWN.

Processo Iterativo.
Processo Ágil.
Introdução
• Há um bom tempo busca-se um processo ou metodologia que
seja previsível e repetível, e que melhore a produtividade e a
qualidade do desenvolvimento de software
• Vários modelos foram idealizados com o intuito de organizar o
processo, podendo assim alcançar a máxima eficiência
pretendida, com o menor custo relacionado
Modelo Cascata (Waterfall)

O ciclo de vida em Cascata (Clássico ou Linear) possui uma
tendência maior para a progressão sequencial apesar de pode haver
retroalimentação.
Problemas:
Projetos reais raramente seguem o fluxo;
Presume possibilidade de declarar previamente todos os
requisitos;
A implantação fica distante da fase inicial;
Aplicabilidade:
Modelo apropriado quando se tem requisitos bem definidos
Extraido de BEZZERA, E .Principio de Analise e Projecto de Software
73
Modelo em Fonte
• Baseado no modelo de cascata
• Porém, observe que a sequência sempre contém ciclos
• Reflete o fato de que algumas fases não podem iniciar antes de
outras
• E que algumas fases são intercaladas
Modelo em Espiral
• Sugerido por Boehmen em 1988
• Representação em espiral, não como sequência de tarefas
• Não tem número fixo de fases
• Os riscos são tratados explicitamente
74
“O modelo espiral pode ser adaptado para ser aplicado ao longo de

todo o ciclo de vida de uma aplicação, desde o desenvolvimento de
conceitos até a sua manutenção” [PRESSMAN, 2011]
Modelo Iterativo / Incremental

• A cada iteração:
• O software é incrementado em termos de artefatos de software
• A definição desses artefatos e suas iterações seguem a
necessidade do Cliente/Usuário
• As primeiras devem abordar os artefatos de maior relevância
para o produto.
Metodologias Ágeis
O desenvolvimento ágil de software defende alguns pontos de vista em

detrimentos de outros:
Manifesto Ágil:
75
• Indivíduos e interações entre eles mais que processos e

ferramentas;
• Software em funcionamento mais que documentação abrangente;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.
Metodologias Ágeis - Feedback
• Processos ágeis usam feedback, ao invés do planeamento como

seu mecanismo de controle rimário
• O feedback é orientado por testes e releases periódicos do
software envolvido
Metodologias Ágeis - Exemplos
• Scrum
• eXtreme Programming (XP)
• Etc.
SCRUM
• Scrum é uma metodologia ágil para gestão e planeamento de

projetos de software.
• Os projetos são divididos em ciclos (mensais, semanais, etc.)
chamados de Sprints. O Sprint representa um Time Box (intervalo
de tempo) dentro do qual um conjunto de atividades deve ser
executado.
• Metodologias ágeis de desenvolvimento de software são
iterativas, ou seja, o trabalho é dividido em iterações, que no caso
do Scrum, são as Sprints.
• As funcionalidades a serem implementadas em um projeto são
mantidas em uma lista que é conhecida como Product Backlog.
• No início de cada Sprint, faz-se um Sprint Planning Meeting, ou
seja, uma reunião de planeamento na qual o Product Owner
prioriza os itens do Product Backlog e a equipe seleciona as
atividades que ela será capaz de implementar durante o Sprint
que se inicia.
• As tarefas alocadas em um Sprint são transferidas do Product
Backlog para o Sprint Backlog.
• Alguns termos serão comumente vistos ao utilizar essa
metodologia:
✓ Produt Backlog
✓ Sprint Planning Meeting
✓ Sprint Backlog
✓ Daily Scrum
✓ Release Burndown
76
✓ Sprint Review
✓ Sprint Retrospective
SCRUM – Product Backlog
• É uma lista contendo todas as funcionalidades desejadas para um

produto.
• O conteúdo desta lista é definido pelo Product Owner.
• O Product Backlog não precisa estar completo no início de um
projeto. Pode-se começar com tudo aquilo que é mais óbvio em
um primeiro momento.
• Com o tempo, a lista cresce e muda à medida que se aprende
mais sobre o produto e seus usuários.
SCRUM – Sprint Planning Meeting
• É uma reunião na qual estão presentes o Product Owner, o Scrum

Master e todo a equipe, bem como qualquer pessoa interessada
que esteja representando a gerência ou o cliente.
• Durante o Sprint Planning Meeting, o Product Owner descreve
as funcionalidades de maior prioridade para a equipe.
• A equipe faz perguntas durante a reunião de modo que seja
capaz de quebrar as funcionalidades em tarefas técnicas, após
a reunião.
• Essas tarefas irão dar origem ao Sprint Backlog.
SCRUM – Sprint Backlog
• É uma lista de tarefas que a equipe se compromete a fazer em

um Sprint.
• Os itens do Sprint Backlog são extraídos do Product Backlog,
pela equipe, com base nas prioridades definidas pelo Product
Owner e a percepção da equipe sobre o tempo que será
necessário para completar as várias funcionalidades.
SCRUM – Daily Scrum
• A cada dia do Sprint a equipe faz uma reunião diária, chamada

Daily Scrum.
• Ela tem como objetivo disseminar conhecimento sobre o que foi
feito no dia anterior, identificar impedimentos e priorizar o
trabalho a ser realizado no dia que se inicia.
• É composta pelo Scrum Master e a equipe de desenvolvimento.
SCRUM – Release Burndown
77
• Em um projeto Scrum, a equipe monitora seu progresso em

relação ao projeto, atualizando um gráfico chamado Release
Burndown ao final de cada Sprint (iteração).
• O eixo horizontal de um Release Burndown Chart mostra os
Sprints;
• O eixo vertical mostra a quantidade de trabalho que ainda
precisa ser feita no início de cada Sprint.
• O trabalho que ainda resta pode ser mostrado na unidade
preferencial da equipe: Pontos de função, dias de trabalho e
assim por diante.
SCRUM – Sprint Review Meeting
• É feito ao final de cada Sprint.

• Durante esta reunião, a equipe mostra o que foi alcançado
durante o Sprint.
• Tipicamente, isso tem o formato de um demo das novas
funcionalidades.
• Os participantes do Sprint Review tipicamente incluem o
Product Owner, a equipe, o Scrum Master, gerência, clientes
e engenheiros de outros projetos.
SCRUM – Sprint Retrospective
• Ocorre ao final de um Sprint e serve para identificar o que

funcionou bem, o que pode ser melhorado e que ações serão
tomadas para melhorar.
• Pode servir também para iniciar o planeamento da nova
Sprint.
78
• Conta com a participação do Scrum Master e com a equipe

de desenvolvimento.
eXtreme Programming (XP)
• É uma metodologia de desenvolvimento de software,

nascida nos Estados Unidos ao final da década de 90.
• Vem fazendo sucesso em diversos países, por ajudar a criar
sistemas de melhor qualidade, que são produzidos em menos
tempo e de forma mais econômica que o habitual.
• Tais objetivos são alcançados através de um pequeno
conjunto de princípios e práticas, que diferem
substancialmente da forma tradicional de se desenvolver
software.
Princípios:
Comunicação
Coragem
Feedback
Respeito
Simplicidade
Comunicação:
79
Coragem:
• Única constância nos projetos de software é a mudança

• A confiança nas ferramentas e nas metodologias
adotadas ajudam em tomadas de decisões corajosas, para o
bem do projeto
Feedback
• Projetos de software requerem alto investimento por parte
do cliente
80
• É preciso que o cliente tenha conhecimento do status do seu

investimento, a cada instante
• Para isso, a comunicação e o respeito devem esta presente
na relação Equipe x Cliente
Respeito
• Membros de uma equipe só irão se preocupar em
comunicar-se melhor, por exemplo, se houver respeito uns com
os outros
Simplicidade:
• Pesquisa sobre as funcionalidades desenvolvidas para um

software
Muito esforço é, geralmente, empregado na produção do software, sem

que haja agregação de valor no produto final
eXP
81
eXtreme Programming (XP) – Práticas
Organizacionais:
• Jogo de Planeamento
• Pequenas Versões (Releases)
• Teste de Aceitação
• Time Coeso
Equipe:
• Propriedade Coletiva
• Padronização de Código
• Ritmo Sustentável
• Integração Contínua
• Metáforas
Pares:
• Programação em Par
• Refatoração
• Projeto Simples
• Desenvolvimento Orientado a Teste (TDD)
Jogo de Planeamento:
• É a reunião feita no início da iteração, entre

desenvolvedores e cliente, cuja finalidade é identificar as
82
prioridades do projeto para que os desenvolvedores

estimem o esforço das tarefas.
• O cliente é essencial neste processo e assim ele fica sabendo
o que está acontecendo e o que vai acontecer no projeto.
• Como o escopo é reavaliado a cada ciclo, o projeto é
regido por um contrato de escopo negociável, que difere
significativamente das formas tradicionais de contratação de
projetos de software.
• Ao final de cada ciclo, o cliente recebe novas
funcionalidades, completamente testadas e prontas para
serem postas em produção.
Pequenas Versões (Releases):
• A liberação de pequenas versões funcionais do projeto

auxilia muito no processo de aceitação por parte do cliente,
que já pode testar uma parte do sistema que está
comprando.
• As versões chegam a ser ainda menores que as produzidas
por outras metodologias incrementais, como o RUP.
Teste de Aceitação:
• São testes construídos pelo cliente e conjunto de analistas e

testadores, para aceitar um determinado requisito do
sistema.
• Descreve um cenário (de sucesso ou não) com uma
expectativa do cliente em relação à história ou
funcionalidade.
• Como o nome sugere, ele ajuda a equipe a entender
quando uma história está completa (aceita).
Time Coeso:
• Deve ser formado pelo cliente, desenvolvedores e por

profissionais que contribuam para o desenvolvimento do
projeto, como consultores, por exemplo.
• A equipe de desenvolvimento é formada por pessoas
engajadas e de perfis multidisciplinares, com o objetivo de
termos um vasto conjunto de habilidades necessárias para o
projeto.
• Um projeto bem-sucedido precisa levar em conta a opinião
de diversas partes, bem como incorporar diferentes pontos
de vista.
83
Propriedade Coletiva :
• O código fonte não tem dono e ninguém precisa solicitar

permissão para poder modificar o mesmo.
• O objetivo com isto é fazer a equipe conhecer todas as
partes do sistema.
Padronização de Código :
• A equipe de desenvolvimento precisa estabelecer regras

para programar e todos devem seguir estas regras.
• Desta forma parecerá que todo o código fonte foi editado
pela mesma pessoa, mesmo quando a equipe possui 10 ou
100 membros.
• IDEs e Frameworks contribuem de forma significativa para
implantar essa prática.
Ritmo Sustentável :
• Trabalhar com qualidade, buscando ter ritmo de trabalho

saudável (40 horas/semana, 8 horas/dia), sem horas extras.
• Horas extras são permitidas quando trouxerem
produtividade para a execução do projeto.
• Outra prática que se verifica neste processo é a prática de
trabalho energizado, onde se busca trabalho motivado
sempre.
• Para isto o ambiente de trabalho e a motivação da equipe
devem estar sempre em harmonia.
Integração Contínua:
• Sempre que produzir uma nova funcionalidade, nunca

esperar uma semana para integrar à versão atual do
sistema.
• Isto só aumenta a possibilidade de conflitos e a
possibilidade de erros no código fonte.
• Integrar de forma contínua permite saber o status real da
programação.
Metáforas :
• Procura facilitar a comunicação com o cliente, entendendo a

realidade dele.
• O conceito de rápido para um cliente de um sistema jurídico
é diferente para um programador experiente em controlar
comunicação em sistemas em tempo real, como controle de
tráfego aéreo.
84
• É preciso traduzir as palavras do cliente para o significado

que ele espera dentro do projeto.
Programação em Par :
• É a programação em par/dupla num único computador.

• Geralmente a dupla é formada por um iniciante na
linguagem e outra pessoa funcionando como um instrutor.
• Como é apenas um computador, o novato é que fica à
frente fazendo a codificação, e o instrutor acompanha
ajudando a desenvolver suas habilidades.
• Desta forma o programa sempre é revisto por duas pessoas,
evitando e diminuindo assim a possibilidade de defeitos.
• Com isto busca-se sempre a evolução da equipe,
melhorando a qualidade do código fonte erado.
Refactoração:
• É um processo que permite a melhoria contínua da

programação, com o mínimo de introdução de erros e
mantendo a compatibilidade com o código já existente.
• Refatorar (ou refabricar) melhora a clareza (leitura) do
código, divide-o em módulos mais coesos e de maior
reaproveitamento, evitando a duplicação de código-fonte
Projeto Simples :
• Simplicidade é um princípio da XP. Projeto simples significa

dizer que caso o cliente tenha pedido que na primeira
versão apenas o usuário "teste" possa entrar no sistema com
a senha "123" e assim ter acesso a todo o sistema, você vai
fazer o código exato para que esta funcionalidade seja
implementada, sem se preocupar com sistemas de
autenticação e restrições de acesso.
• Um erro comum ao adotar essa prática é a confusão por
parte dos programadores de código simples e código fácil.
• Nem sempre o código mais fácil de ser desenvolvido levará
a solução mais simples por parte de projeto.
• Esse entendimento é fundamental para o bom andamento do
XP.
• Desenvolvimento Orientado a Teste (TDD)
Testing Driven Development
• Primeiro crie os testes unitários (Unit Tests) e depois crie o
código para que os testes funcionem.
• Esta abordagem é complexa no início, pois vai contra o
processo de desenvolvimento de muitos anos.
85
• Só que os testes unitários são essenciais para que a

qualidade do projeto seja mantida.
Variação entre os modelos
Como o processo de desenvolvimento de software se

distribui/concentra no tempo dentro de um projeto?
Cada modelo tem suas vantagens e desvantagens
Cabe aos gerentes e analistas escolherem a melhor abordagem

para o projeto a ser desenvolvido
Sumário

……
Perguntas
Perguntas
86
UNIDADE Temático 3.3. Processo Unificado
Fases do Processo.
Ciclo de vida do processo.
• Orientado por Casos de Uso, surgiu para realizar o

desenvolvimento de software visando a construção de sistemas
orientados a objetos.
• Este modelo de desenvolvimento de software é iterativo e

adaptativo, desta forma consegue produzir um sistema de
grande porte como se fossem vários pequenos sistemas, o que
diminui o risco do projeto.
• O PU utiliza um paradigma evolucionário paro o

desenvolvimento de softwares. O ciclo de vida iterativo é
baseado em refinamentos e incrementos sucessivos a fim de
convergir para um sistema adequado.
• Em cada iteração incrementa-se um pouco mais o produto,

baseando-se na experiência obtida nas iterações anteriores e
no feedback do usuário. Cada iteração pode ser considerada
um miniprojeto de duração fixa, sendo que cada um destes inclui
suas próprias atividades de análise de requisitos, projeto,
implementação e testes.
Segundo Ivar Jacobson, Grady Booch e James Rumbaugh

(1999):
– Hoje em dia, a tendência do software é no sentido de sistemas

maiores e mais complexos. Isso deve, em parte, ao fato de que
os computadores tornam-se mais potentes a cada ano, levando
aos usuários a ter uma expectativa maior em relação a eles (...)
87
Queremos software que seja mais e mais adaptado as nossas

necessidades, mas isso, por sua vez, simplesmente torna o
software mais complexo.
Características
• Baseado em componentes que realizam interfaces
• Usa UML
• Aspectos:
– Dirigido por Casos de Uso
– Centrado em arquitetura
– Iterativo e incremental
– Focado no Risco
• Composto pelos 4 P’s: Pessoal, Projeto, Produto e Processo
P4 = Pessoa, Projeto, Produto, Processo
• PESSOAS: Financiam, escolhem, desenvolvem, gerenciam,

testam, usam e são beneficiadas por produtos
• PROJETOS: Sofrem alterações. Determinam os tipos de

pessoas que irão trabalhar no projeto e os artefatos que serão
usados
• PRODUTO código fonte, código de máquina, subsistemas,

classes, diagramas: interação, de estados e outros artefatos
– ARTEFATO é qualquer tipo de informação criada por uma

pessoa (diagramas UML, textos, modelos de interfaces)
• PROCESSO define quem faz o que, quando e como
• PU é um processo. Considera fatores organizacionais, do

domínio, ciclo de vida e técnicos
Dirigido a Use-Cases
88
• Capturar os requisitos: o Diagrama Use-Case mostra quais

atores usam quais use-cases
• Dirigir o processo: para realizar os use-cases são definidos

classificadores (classes, subsistemas, interfaces) e
relacionamentos (colaborações) entre estes
• Elaborar a arquitetura, determinar iterações, determinação

dos manuais de usuário
Centrado na arquitetura
• A organização do sistema como um todo
• Os elementos estruturais, interfaces e seu comportamento
• Composição de elementos estruturais e comportamentais em

subsistemas
• A ARQUITETURA descreve as partes essenciais do sistema,

importantes para todos desenvolvedores
– Menos de 10% das classes são relevantes para a arquitetura
• Descrição de REQUISITOS ADICIONAIS: segurança,

distribuição, concorrência, plataformas, etc.
89
• Sequência para o arquiteto:
• Criar uma visão preliminar da arquitetura
• Analisar os use-cases chave (5-10%) e especificar um

subsistema para cada um
• Pela especificação dos subsistemas aparecem mais detalhes

da arquitetura e novos use-cases
• Repetir o passo acima, até terminar o sistema
Benefícios
• Mitigação precoce, ao invés de tardia, minimizando os riscos

do projeto;
• Progresso visível desde o início
• Realimentação, envolvimento do usuário e adaptação

imediatos, levando a um sistema refinado que atenda, de forma
mais adequada, às reais necessidades dos interessados;
• A complexidade é administrada
– A equipe não é sobrecarregada pela “paralisia da análise”

ou por passos muito longos e complexos;
90
• O aprendizado obtido em uma iteração pode ser usado para

melhorar o próprio processo de desenvolvimento.
Fases do Processo Unificado
Fases do Processo Unificado
• Concepção
• Elaboração
• Construção
• Transição
• Produção
Concepção:
• Estabelece o business case (prioridade de negócio)
• Envolve tanto a atividade de comunicação com o cliente como

a de planeamento
• Delimita o escopo do sistema
• Determina arquitetura candidata (elementos novos, arriscados)
• Identifica riscos críticos
• Identifica potenciais usuários ou clientes do sistema
Elaboração:
• Determina uma arquitetura estável
91
• Identificar e reduzir riscos de construção
• Especificar maioria dos Casos de Uso
• Fixar a arquitetura em proporções executáveis
• Preparar o plano de projeto (para a próxima fase)
• Estimar e justificar o orçamento
• Finalizar o business case
Construção:
• Determina capacidades operacionais iniciais
• Estender o modelo de Casos de Uso para toda a aplicação
• Finalizar a análise, projeto, implementação e testes
• Verificar integridade da arquitetura (com possíveis alterações)
• Monitorar riscos críticos
Transição:
• Transforma versão beta em um sistema em produção
• Preparar atividades de transição
• Avisar clientes sobre mudanças no ambiente (hardware,

software, distribuição, ..)
• Preparar documentação final
• Carregar o novo sistema
• Corrigir possíveis defeitos detectados no beta-teste
Produção (Segundo Pressman [2010])
• Durante essa fase, monitora-se o uso contínuo do software
• Disponibiliza-se suporte para o ambiente operacional

(infraestrutura)
• Realiza-se e avalia-se relatórios de defeitos e solicitações de

mudanças
Sumário

……
92
Perguntas
Perguntas
UNIDADE Temático 3.4. Padrões de Implementação
Projetar um sistema orientado a objeto não é simples, mas realizar este

projeto levando em consideração o reuso é ainda mais complexo. Você
deve estabelecer as classes pertinentes, com a granularidade
necessária e relacioná-las da melhor maneira possível.
Uma das maneiras de facilitar esta tarefa é realizar o reuso de boas

soluções propostas para problemas recorrentes do desenvolvimento de
software. Este cenário de reuso é descrito através de padrões de
projeto. Vale frisar que padrões promovem o reuso das ideias de como
solucionar o problema, não de código Padrões de projeto apresentam
as seguintes vantagens e desvantagens:
Vantagens
• Facilidade de repassar conhecimento entre os desenvolvedores

experientes;
• Capturar experiências, tornando-as acessíveis aos novatos;
• Tornar mais rápido o entendimento de sistemas (documentados por

meio de padrões);
• Facilitar a evolução do código – quando padrões são usados no

desenvolvimento, fica mais fácil entender o código para evoluí-lo;
• Modularidade – código que usa padrões possui maior coesão e,

portanto, módulos mais bem definidos, com consequente diminuição da
complexidade por quebrar o problema em problemas menores;
Desvantagens
• Menor Eficiência: Em alguns casos, o uso de um padrão de software

pode exigir que seja adicionada novas classes ou novas camadas de
aplicação ao modelo original do
93
sistema, o que pode causar uma sobrecarga na sua execução,

tornando-o mais lento;
• Menor Legibilidade: Apesar de serem concebidos para melhorar o

entendimento de programas, em certos casos padrões podem diminuir a
compreensão de um projeto ou de uma implementação;
• Falta de Motivação da Equipe: Assim como em outras formas de

reuso, pode haver resistência ao uso de padrões por parte da equipe.
Para que uma solução seja considerada um padrão, ela deve

preencher os seguintes requisitos:
• Deve ser uma solução para um problema em um contexto;
• Deve ser capaz de dizer ao solucionador do problema o que fazer

e como resolver o problema;
• Deve ser maduro, uma solução provada;
• A solução deve ser construída dentro da ótica do solucionador do

problema e pode ser implementada milhões de vezes sem se repetir;
• Deve ser capaz de se reproduzir
Existe uma infinidade de padrões de projeto propostos na literatura,

dentre eles podemos citar: Padrões GoF, Padrões POSA e Padrões
J2EE. Dentre eles destacamos os padrões GoF. Quanto ao propósito,
eles podem classificar-se em:
• Padrões de Criação: Diz respeito ao processo ou ciclo de criação de

um objeto.
• Estruturais: Diz respeito à composição de objetos e classes.
• Comportamentais: Caracteriza o modo como classes e objetos

interagem e compartilham responsabilidades.
A organização dos padrões GoF é dada de acordo com a tabela a

seguir:
94
A seguir um padrão de cada propósito será detalhado.
Singleton
Singleton é um exemplo de padrão GoF criacional que permite que

uma classe possibilite apenas uma instância e provê um ponto global de
acesso a esta instância.
• Motivação: É importante para algumas classes ter exatamente uma

instância. Como nós gostaríamos que a classe fosse? E o acesso a esta
instância?
• Descrição do Problema: Um atributo de instância criado com tipo

base da própria classe possibilita a acessibilidade de uma instância a
partir da classe base, mas não elimina a possibilidade de instanciar
vários objetos a partir dela.
• Descrição: Permite que a própria classe base (que possui uma

instância de si mesma) controle sua única instância. A classe pode
garantir que nenhuma outra instância pode ser criada e pode fornecer
uma maneira de acessar a instância.
• Consequências: A classe base deve ser responsável por interceptar

solicitações para criar novos objetos.
• Estrutura da Solução: A estrutura deste padrão é bastante simples.

Uma única classe é utilizada, esta classe possui uma instância de si
mesma e um método que devolve esta instância. Tanto o atributo
(Instância da classe) quanto o método de retorno são estáticos, isto
permite que outra classe possa acessar o método sem instanciar a
classe diretamente. Observe que o atributo que armazena a instância
da classe é privado, deste modo o método de retorno é capaz de
garantir que apenas uma instância seja criada. Em linguagens que
disponibilizam o conceito de construtor, deve ser criado um construtor
privado sem parâmetros para garantir que outras classes tenham
acesso à instância da classe base somente através do método
getInstancia.
95
Exemplo: O exemplo a seguir utiliza o contexto de um sistema

universitário, onde é permitido que somente um reitor exista na
instituição em de -terminado momento. Além disto, a classe UAB, recebe
a instância da classe ReitorSingleton.
Em Java, o código destas classes ficaria da seguinte forma:
Composite
96
Composite é um exemplo de padrão GoF estrutural que compõe

objetos em árvores de agregação (relacionamento parte-todo) e
permite que objetos agregados sejam tratados como um único objeto.
• Motivação: Permitir que as aplicações gráficas como editores de

desenho possibilitem que usuários possam construir diagramas
complexos a partir de componentes simples.
• Descrição: O padrão Composite descreve como usar a composição

recursiva para que os clientes não precisem fazer essa distinção.
• Descrição do Problema : O utilizador do padrão pode agrupar

componentes para formar componentes maiores, que por sua vez
podem ser agrupados para formar componentes ainda maiores. Uma
implementação simples pode definir classes para componentes gráficos
primitivos, tais como texto e linhas mais outras classes que atuam como
recipientes para essas primitivas.
• Consequências: código que usa essas classes deve tratar objetos

primitivos e recipiente de forma diferente, mesmo que na maioria das
vezes o usuário os trata de forma idêntica. Ter que distinguir estes
objetos torna a aplicação mais complexa.
• Estrutura da Solução: A solução é simples. Várias classes

implementam as partes da solução (Folha) e uma classe representa o
todo (Composite), adicionalmente uma superclasse ou interface pode ser
criada para relacionar as folhas e composite de modo a possibilitar o
uso de qualquer folha pelo todo
Exemplo: Um desenho pode ser composto de vários círculos e linhas.

Cada um deles é uma figura que pode ser adicionada, removida,
desenhada e pode ter seu desenho retornado.
97
// Interface Figura
public interface Figura {
public abstract void desenhar();
public void adicionar(Figura fig);
public void remover(Figura fig);
public Figura getFigura(int indice);
}
__________________________________________________
// Classe Circulo
public class Circulo implements Figura{
public void adicionar(Figura fig) {
System.out.println(“Círculo não tem Filhos.”);
}
public void desenhar() {
System.out.println(“()”);
}
public Figura getFigura(int indice) {
return null;
}
public void remover(Figura fig) {
}
}
__________________________________________________
//Classe Linha
public class Linha implements Figura{
System.out.println(“Linha não tem Filhos.”);
}
System.out.println(“____________________ ”);
}
System.out.println(“Linha não tem Filhos, será retornado
nulo.”);
98
return null;
}
System.out.println(“Linha não tem Filhos.”);
}
}
__________________________________________________
//Classe Desenho
public class Desenho implements Figura {
ArrayList<Figura> filhos = new ArrayList<Figura>();
this.filhos.add(fig);
}
Figura f;
for(int i = 0; i < this.filhos.size(); i++){
f = this.filhos.get(i);
f.desenhar();
}
return (Figura) this.filhos.get(indice);
}
this.filhos.remove(fig);
}
}
Template Method
Template Method é um exemplo de padrão GoF comportamental que

permite que subclasses componham o algoritmo e tenham a
possibilidade de redefinir certos passos a serem tomados no processo,
sem contudo alterar sua interface.
• Motivação: Deseja que subclasses implementem versões diferentes,

mas com a mesma estrutura de um método da superclasse. O que faria?
• Descrição: Define o esqueleto de um algoritmo em uma operação. O

Template Method permite que subclasses componham o algoritmo e
tenham a possibilidade de redefinir certos passos a serem tomados no
processo, sem contudo, mudá-lo.
• Descrição do Problema: Implementar as partes invariantes de um

algoritmo uma só vez e as subclasses implementam comportamentos
variantes. Quando comportamento comum entre subclasses deve ser
fatorado e localizado em uma classe comum para evitar duplicação de
código.
• Consequências: É importante dizer o que os métodos: devem, podem

e não podem ser sobrescritos.
99
• Estrutura da Solução: Uma classe abstrata que possui o método

template é definida e utilizada como base para as classes que
utilizarão o conjunto de passos do método template e definirão as
operações abstratas (cada passo) definidas na classe pai.
Exemplo: O exemplo a seguir utiliza a feitura de café e de chá para

exemplificar o uso do padrão de Projeto Template Method. Para
fazermos um café, é necessário ferver água, infundir os grãos de café,
despejar na panela e condimentar com açúcar. Para o preparo do chá,
é necessário ferver água, infundir as folhas do chá, despejar na panela
e condimentar com limão. Observe que a sequência das operações é
semelhante, o que muda são os ingredientes.
100
// Classe BebidaQuente
public abstract class BebidaQuente {
public void preparar(){
ferverAgua();
despejarNaChaleira();
infundir();
condimentar();
}
public void ferverAgua(){

System.out.println(“Água fervida.”);
}
public void despejarNaChaleira(){
System.out.println(“Água na chaleira.”);
}
public abstract void infundir();

public abstract void condimentar();
}
___________________________________________________
// Classe Cafe
public class Cafe extends BebidaQuente{
public void condimentar() {
System.out.println(“Açúcar adicionado.”);
}
public void infundir() {
System.out.println(“Pó de café adicionado.”);
}
}
___________________________________________________
//Classe Chá
public class Cha extends BebidaQuente{
public void condimentar() {
System.out.println(“Limão adicionado.”);
}
public void infundir() {
System.out.println(“Folhas adicionadas.”);
}
}
Sumário

……
Perguntas
101
1. Qual o objetivo dos padrões Comportamentais, segundo o catálogo

GOF?
Definir formas de gerenciar e combinar diferentes
comportamentos e responsabilidades de classes e objetos de
uma aplicação.
2. Qual o objetivo dos padrões Estruturais, segundo o catálogo

GOF?
Facilitar o design do sistema identificando maneiras de realizar
o relacionamento entre as entidades, deixando o desenvolvedor
livre desta preocupação.
3. Qual o seu entendimento sobre Processo de Desenvolvimento de
Software e quais são os seus objetivos básicos?
É um conjunto de atividades que, coordenadas entre si, visam
a construção de software. Seus objetivos são aumentar a
produtividade e melhorar a qualidade dos projetos de software
desenvolvidos na organização.
4. Descreva o que significa desenvolver um software de qualidade?
Objetivar desenvolver um software que esteja em conformidade
com os requisitos coletados junto ao cliente, visando a sua
satisfação, assim como seguir os processo de desenvolvimento
de software com o intuito de se gerenciar o projeto de maneira
eficiente, buscando assim o resultado esperado.
5. NÃO é considerada uma metodologia para processos de
desenvolvimento de software.
a) RUP
b) ISO/IEC 12207
c) LINUX
d) XP
e) SCRUM
6. Relacione o artefato de entrega com a atividade de PDS
correspondente.
Artefatos:
I - Questionário de entrevista
II - Plano de teste
III - Código fonte do software
IV - Diagrama de Casos de Uso
102
V - Diagrama de Classes
Atividade de PDS:
A) Análise
B) Especificação
C) Projeto
D) Implementação
E) Teste
A relação correta é:
A) A-I, B-II, C-III, D-IV, E-V
B) A-IV, B-I, C-III, D-II, E-V
C) A-I, B-IV, C-V, D-III, E-II
D) A-II, B-III, C-VI, D-I, E-V
E) A-III, B-II, C-I, D-V, E-IV
7. São fases do Processo Unificado:

a) Negócios, Elaboração, Construção e Transição.
b)Iniciação, Elaboração, Construção e Transição.
c) Iniciação, Elaboração, Codificação, Testes e Transição.
d) Iniciação, Requisitos, Modelagem, Construção e
Transição.
e) Negócios, Elaboração, Construção e Implantação.
8. XP – eXtreme Programming. - Baseado em 5 valores, qual da

opções abaixo NÃO é um desses valores ?
a) Complexidade
b) Comunicação
c) Simplicidade (fazer o necessário)
d) Feedback
e) Coragem (para lidar c/ mudança requisito)
9. O Processo Unificado divide a realização de um projeto para

desenvolvimento de um sistema de software em fases. Em cada uma
dessas fases, são executadas atividades de diversas disciplinas em
diferentes proporções. No desenvolvimento de um sistema de
software complexo, quais a principal recomendação desse
processo?
103
Usar a abordagem de desenvolvimento iterativa e incremental,

para dividir as atividades em iterações em que cada iteração
gera um incremento do software, facilitando o seu
gerenciamento.
10. Os métodos ágeis trazem uma nova abordagem para o
desenvolvimento de software diferente das abordagens até então
utilizadas. Explique quais as principais diferenças existentes entre a
abordagem tradicional e a abordagem de métodos ágeis.
Está na especificação do software. Enquanto a abordagem

tradicional valoriza as fases especificação, análise e projeto do
sistema considerando-as fundamental para a produção de
artefatos bem definidos que possam nortear a programação, a
abordagem ágil faz uma especificação simples e sucinta do
sistema e tem como principal foco a codificação do software.
11. Considere um sistema cujos requisitos de interface são definidos
apenas quando o cliente realiza um test-drive na aplicação e
aprova essa interface. Assinale a alternativa que apresenta o
modelo mais adequado para o desenvolvimento da interface desse
sistema.
a) Ágil.
b) Cascata.
c) Iterativo incremental.
d)Prototipação.
e) RAD - Rapid Application Development.
12. Sobre o modelo iterativo e incremental, classifique cada sentença
como sendo V (verdade) ou F (falsa).
Em seguida, assinale a alternativa correta.
I. O modelo iterativo baseia-se na idéia do aumento da

abrangencia do sistema.
II. O modelo incremental baseia-se na ideia de refinamentos
sucessivos.
III. O modelo iterativo e incremental vale-se do modelo em cascata
para sua realização.
IV. A cada iteração, ocorre a especificação, implementação, teste e
implantação
Com base em sua analise assinale a opção que descreve a correta
sequência de V e F é:
a) I-F; II-F; III-V; IV-V

b) I-V; II-V; III-V; IV-V
c) I-V; II-V; III-V; IV-F
104
d) I-F; II-F; III-V; IV-F

e) I-V; II-V; III-F; IV-V
13. Em uma metodologia ágil para desenvolvimento de software como
XP, a técnica SCRUM para gestão de projeto é largamente
adotadas. Justifique essa afirmação explicando melhor como
funciona em SCRUM conceitos como Product Owner, Relase
Planning e SCRUM Master
Product Owner é o dono do produto, o gerente do projeto

responsável pelo que vai ser desenvolvido.
Release Planning é o planeamento de quantas e quais
funcionalidades serão feitas em cada entrega do produto e
SCRUM Master é o líder da equipe, responsável por liderar a
equipe e aplicar as técnicas de SCRUM
14. Qual o objetivo dos padrões de Criação, segundo o catálogo
GOF?
Abstrair o processo de criação de objetos, ou seja, a sua
instanciação. Desta maneira o sistema não precisa se preocupar
com questões sobre, como o objeto é criado, como é composto,
qual a sua representação real.
15. Assinale a opção cujos padrões de projeto estão todos classificados
como Comportamentais, segundo o catálogo GoF
A) Command, Bridge, Iterator, Mediator, Observer, State,
Strategy
B) Command, Bridge, Iterator, Mediator, Bridge, State,
Strategy
C) Command, Bridge, Iterator, Mediator, Composite, State,
Strategy
D) Command, Interpreter, Iterator, Mediator, Observer, State,
Strategy
E) Command, Interpreter, Iterator, Mediator, composite, State,
Strategy
como criação, segundo o catálogo GoF:
A) Command, Builder, Factory Method, Protype , Singleton
B) Abstract Factory, Builder, Factory Method, Decorator, Singleton
C) Abstract Factory, Builder, Factory Method, Protype, Singleton
D) Abstract Factory, Builder, Composite, Protype, Singleton
E) Abstract Factory, Bridge, Factory Method, Protype, Singleton
como Estruturais, segundo o catálogo GoF:
105
A) Adapter, Bridge, Composite, Decorator, Façade, Flyweight,

Singleton
B) Adapter, Bridge, Protype, Decorator, Façade, Flyweight,
Singleton
C) Singleton, Bridge, Composite, Decorator, Façade, Flyweight,
Proxy
D) Singleton, Bridge, Protype, Decorator, Façade, Flyweight,
Proxy
E) Adapter, Bridge, Composite, Decorator, Façade, Flyweight,
Proxy
18. O que é o MVC e como ele é estruturado?

É um padrão arquitetura que tem como objetivo separar a
apresentação dos dados da sua manipulação. O MVC é composto,
basicamente, de 3 camadas:
View(Visão) – Apresentação do sistema para o usuário
Controller(Controle) – Efetuará o processamento das informações
fornecidas pela visão
Model(Modelo) – Responsável pela persistência (armazenamento)
dos dados na estrutura escolhida (Banco de Dados, XML, Etc.)
19. Em uma janela pode-se adicionar objetos como barras de rolagem,
caixas de texto, labels, etc. Pode-se criar uma classe Auxiliar que
será estendida pelos decoradores que irão inserir propriedades na
janela. O padrão de projetos que possibilita essa implementação
chama-se:
A) Memento
B) Template Method
C) Decorator
D) Prototype
E) Builde
20. Dois dos principais patterns utilizados atualmente são descritos a
seguir:
I. Visa garantir que uma classe só tenha uma única instância e
prover um ponto de acesso global a ela.
II. Visa definir uma dependência um-para-muitos entre objetos para
que quando um objeto mudar de estado os seus dependentes sejam
notificados e atualizados automaticamente.
Os Design Patterns descritos em I e II são, respectivamente:
A) Singleton e Observer.
B) Composite e Adapter
C) Singleton e Command.
D) Facade e Observer.
106
E) Facade e Adapter.
21. A família de padrões GoF é dividida em três grupos principais de
padrões, a saber:
a) Padrões de Criação; Padrões Metodológicos; Padrões de Ponte.
b) Padrões de Processo; Padrões de Singularidade; Padrões de
Prototipação.
c) Padrões de Proxy; Padrões de Criação; Padrões de
Encadeamento.
d) Padrões Estruturais; Padrões de Processo; Padrões de
Responsabilidade.
e) Padrões Comportamentais; Padrões de Criação; Padrões
Estruturais.
1. Qual a importância de padrões de projeto?
2. Consulte outros três padrões de projeto GOF e liste as principais

características deles.
3. Consulte mais cenários de aplicação para os padrões apresentados

nesta seção.
4. Que padrão utilizaria para implementar um sistema de uma fábrica

de ventiladores que possuem vários tipos de ventiladores, montados a
partir de um conjunto específico de peças? Ilustre este cenário.
TEMA -IV: TESTE DE SOFTWARE
UNIDADE Temática 4.1. Introdução, Importância do Teste de Software:

natureza, objectivos e definições do Teste.
UNIDADE Temática 4.2. Teste no projecto do Sistema
UNIDADE Temática 4.3. Teste no Programa
UNIDADE Temática 4.4. Teste na plantação do sistema
UNIDADE Temática 4.5. Teste do Software em Sistema em Produção
UNIDADE Temática 4.6. Ferramentas de Teste de Software
107
UNIDADE Temática 4.1. Importância do teste de software
Introdução
A atividade de teste de software é complemento indispensável à

atividade de construir e manter sistema.
A aplicação de teste de software deve ser planeada, supervisionada,

executada e avaliada.
Objetivos Gerais
Conhecer as técnicas de teste de software para aplicação no ambiente

de desenvolvimento e produção de sistemas.
Objetivos Específicos
• Identificar necessidade de uso de teste de software nas diversas fases

de vida e de construção do software;
• Selecionar os testes adequados para cada situação;
• Criar e escolher estratégias de teste de software;
• Aplicar e analisar teste de software.
4.1.1 - O teste nas fases de vida e de desenvolvimento de um

software.
A Importância do Teste
• O desenvolvimento de sistemas envolve uma série de atividades em

que as oportunidades de injeção de falhas são muito grandes.
• Estes erros podem começar a aparecer logo no início do processo,

onde os objetivos podem estar erroneamente especificados, além de
erros que venham a ocorrer em fases de projeto e desenvolvimento
posteriores.
• Por causa da inabilidade humana de realizar e de se comunicar com

perfeição, o desenvolvimento é acompanhado de garantia de
qualidade.
• A atividade de teste de software é um elemento crítico da garantia

de qualidade de software e representa a última revisão de
especificação, projeto e codificação.
Custo do Reparo
108
• Não é raro gastarmos entre 30 e 40% do esforço total do projeto no

Teste de Software.
• O Teste de Software para ambientes críticos (ex.: controle de voo,

monitoramento de reatores nucleares e etc.) pode custar de três a cinco
vezes mais do que todos os outros passos de engenharia de software
combinados.
Gráfico de Índice de Falhas x Tempo
Definindo o Teste de Software
• Avaliar se o software está fazendo o que deveria fazer, de acordo

com os seu requisitos, e não está fazendo o que não deveria fazer;
• Qualquer atividade que, a partir da avaliação de um atributo ou

capacidade de um programa ou sistema, seja possível determinar se
ele alcança os resultados desejados. (Bill Hetzel – 1988).
109
• Processo de executar um programa ou sistema com a intenção de

encontrar defeitos (Glen Myers – 1979);
• Segundo Pressman, o teste de software é um conjunto de atividades

que podem ser planejadas com antecedência e executadas
sistematicamente.
• Uma estratégia de teste de software deve acomodar testes de baixo

nível, necessários para verificar se um pequeno segmento de código
fonte foi implementado corretamente, bem como testes de alto nível,
que validam as funções principais do sistema de acordo com os
requisitos do cliente.
• A atividade de teste é um passo do processo de Engenharia de

Software que visa encontrar/corrigir erros ao longo do software que
foi construído.
• Testes podem ser usados para descobrir a presença de erros, mas

não para mostrar a sua ausência.
• Testes de software é o processo de executar o software de uma

maneira controlada com o objetivo de descobrir diferenças entre o
comportamento previsto e o comportamento observado
Estratégias de Teste
• Todas estratégias fornecem um modelo para o teste e têm

basicamente as seguintes características:
–Para executar um teste eficaz, proceder a revisões técnicas eficazes.

Fazendo isso, muitos erros serão eliminados antes do começo do teste.
–O teste começa no nível do componente e progride em direção à

integração do sistema computacional como um todo.
–Diferentes técnicas de teste são apropriadas para diferentes

abordagens de engenharia de software e em diferentes momentos
–O teste é feito pelo desenvolvedor do software e (para grandes

projetos) por um grupo independente de teste.
–O teste e a depuração são atividades diferentes, mas a depuração

ocorre em consequência de um teste.
• A atividade de teste é o processo de executar um programa com a

intenção de descobrir um erro.
• Um bom caso de teste é aquele que possui uma elevada

probabilidade de revelar um erro ainda não descoberto.
110
• Um teste bem-sucedido é aquele que revela um erro ainda não

descoberto.
Diretrizes para o Teste
• Determinar quando o teste deve ser interrompido.
• Atribuir a responsabilidade do teste a um testador.
• Descrever os resultados esperados para cada caso de teste.
• Escrever casos de teste para condições de entrada válidas e inválidas.
• Inspecionar o resultado de cada teste por completo.
• Alocar os programadores mais criativos para teste.
O Processo de Teste
• O processo de teste de software deve basear-se em uma

metodologia aderente ao processo de desenvolvimento, com pessoal
técnico qualificado, ambiente e ferramentas adequadas.
• Esta metodologia de teste deve ser o documento básico para

organizar a atividade de testar aplicações no contexto da empresa.
Assim como o processo de desenvolvimento de software, teste de
software também possui um ciclo de vida:
• Planeamento: Elaboração e revisão da Estratégia de teste e do

plano de teste;
• Preparação: Preparação do ambiente de teste, incluindo

equipamentos, rede, pessoal, software e ferramentas.
• Procedimentos iniciais: Consiste na elaboração de documento com o

estabelecimento de um acordo entre as partes envolvidas no projeto de
teste (usuários e técnicos):
– Objetivo do projeto de teste,
– Pessoal a ser envolvido,

111
– As responsabilidades de cada um;
– O plano preliminar de trabalho;
– Avaliação dos riscos;
– Os níveis de serviços acordados e etc.
• Especificação: Elaboração e revisão dos casos de teste , "scripts" (no

caso de ferramentas de automação de testes) e dos roteiros de Teste e
execução dos testes de verificação da documentação do sistema (testes
estáticos).
• Execução: Execução dos testes planejados conforme os Casos de

Teste, "scripts" e dos roteiros de Teste com os correspondentes registros
dos resultados obtidos.
• Entrega: Conclusão do processo de testes com a entrega do sistema

para o ambiente de produção.
Interação entre os Ciclos de Vida
• Há muitas estratégias que podem ser utilizadas para testar um

software. Uma das estratégias de teste que é preferida pela maioria
das equipes é a visão incremental do teste, começando com o teste das
unidades individuais de programa, passando para os testes destinados
a facilitar a integração de unidades e culminando com testes que usam
o sistema concluído.
• Verificação: Nesta etapa são realizadas inspeções/revisões sobre os

produtos gerados.
• Testes Unitários: São realizados no estágio mais baixo da escala de

testes e são aplicados nas menores componentes de códigos criados,
visando garantir que estes atendem as
112
especificações, em termos de garantia e de funcionalidade. Verificam o

funcionamento de um pedaço do sistema ou software isoladamente ou
que possam ser testado separadamente.
• Normalmente é feito pelos desenvolvedores.
• Testes de Integração: São executados em uma combinação de

componentes para verificar se eles funcionam corretamente juntos,
conforme as especificações.
• Componentes podem ser pedaços de código, módulos, aplicações

distintas, clientes servidores.
• Normalmente é feito pelos desenvolvedores
• Teste de Sistema: São realizados pela equipe de testes, visando a

execução do sistema como um todo ou um subsistema (parte de um
sistema), dentro de um ambiente operacional controlado, para validar
a exatidão e perfeição na execução de suas funções.
• Neste estágio de teste deve ser simulada a operação normal do

sistema, sendo testadas todas as suas funções de forma mais próxima
possível do que irá ocorrer no ambiente de produção.
• Esses testes são feitos pela equipe de teste de software.
• Teste de Aceitação: São os testes finais de execução do sistema,

realizados pelos usuários, visando verificar se a solução atende aos
objetivos do negócio e aos seus requisitos, no que diz respeito À
funcionalidade e usabilidade, antes da sua utilização no ambiente de
produção.
• Ao tratar os testes como um processo organizado e muitas vezes

paralelo e integrado ao processo de desenvolvimento, os custos de
manutenção serão reduzidos.
• Segundo Myers, o custo de correção de defeitos tende a aumentar

quanto mais tarde o defeito é detectado. Defeitos encontrados durante
a produção tendem a custar muito mais que defeitos encontrados em
modelos de dados e em outros documentos do projeto do software.
Os testes unitários podem remover entre 30% e 50 % dos defeitos dos

programas;
• Os testes de sistemas podem remover entre 30% e 50% dos defeitos

remanescentes.
• Desse modo, os sistemas podem ir para produção ainda com

aproximadamente 49% de defeitos.
113
• Por últimos, as revisões de códigos podem reduzir entre 20% e 30%

desses defeitos.
4. 1.2 - O teste na engenharia de sistemas e na engenharia de

programas
Sumário

……
Perguntas
Perguntas
UNIDADE Temático 4.2 – Teste no projeto de sistema
4.2.1 – Revisões Técnicas Formais
FTR (Formal Technical Review)
• É uma atividade de Garantia de Qualidade (SQA) de um
software.
• Diferentemente dos testes, que só podem ser feitos após o término da

codificação do software, a FTR pode ser feita em qualquer fase do
projeto.
Objetivos:
Descobrir erros na função, na lógica ou na implementação, para

qualquer representação do software;
• Verificar se o software sob revisão satisfaz seus requisitos;
114
• Garantir que o software tenha sido representado de acordo com

padrões predefinidos;
• Conseguir software que seja desenvolvido de modo uniforme;
• Tornar os projetos mais administráveis.
• Além disso, a FTR serve como uma oportunidade de treinamento,

permitindo a jovens engenheiros observar abordagens diferentes para
a análise, projeto e implementação de software.
• A FTR é na realidade uma classe de revisões que inclui walkthoughs,

inspeções, revisões circulares e outras avaliações técnicas de software.
A Reunião de Revisão
• Independentemente do formato de FTR escolhido, cada reunião de

revisão deve atender às seguintes restrições:
– Entre três e cinco pessoas (em geral) devem ser envolvidas na

revisão. Preparativos devem ser feitos, os quais não devem exigir mais
de duas horas de trabalho de cada pessoa;
– A duração da reunião de revisão deve ser inferior a duas horas;
– À vista dessas restrições, fica óbvio que uma FTR focaliza uma parte
específica (e pequena) de todo o software.
• O foco de uma FTR é um Produto de Trabalho.
– Ex: Uma parte da especificação de requisitos, o projeto detalhado de

um componente, uma listagem do código-fonte de um componente,
• O indivíduo que desenvolveu o produto de trabalho (produtor)

informa ao líder do projeto que o produto do trabalho foi completado
e que é necessária uma revisão.
• O líder do projeto contata um líder de revisão, que avalia se o

produto está efetivamente pronto, gera cópias dos materiais do
produto e as distribui a dois ou três revisores para preparativos
antecipados.
• Concomitantemente, o líder de revisão também revisa o produto e

estabelece uma agenda para a reunião de revisão, que é usualmente
marcada para o dia seguinte.
115
• A reunião de revisão tem a participação do Líder de Revisão, de

todos os Revisores e do Produtor.
• Um dos revisores assume o papel de Registrador, isto é, o indivíduo

que registra (por escrito) todas as questões importantes levantadas
durante a revisão.
• A FTR começa com a introdução da agenda e uma breve introdução

pelo produtor.
• O produtor então prossegue, percorrendo o produto de trabalho e

explicando o material, enquanto os revisores levantam questões
baseadas na sua preparação antecipada.
• Quando problemas ou erros válidos são descobertos, o registrador os

anota.
• No fim da revisão, todos os participantes da FTR devem decidir se:
– Aceitam o produto sem maiores modificações;
– Rejeitam o produto devido a erros graves;
– Aceitam o produto condicionalmente.
• Tomada a decisão, todos os participantes da FTR assinam uma lista

na qual indicam sua participação na revisão e sua concordância com os
resultados da equipe de revisão.
4.2.2 – Validação pelo usuário
• Os testes na fase de projeto que podem ser validados em conjunto

com o usuário, notadamente revisões guiadas por amostras.
116
• Documentos revisados e Iterações estáveis são os artefatos de

software candidatos nessa atividade.
Sumário

……
Perguntas
Perguntas
UNIDADE Temático 4.3 – Teste no Programa
Introdução
• "Há um mito segundo o qual, se fôssemos realmente bons para
programar, não haveria 'bugs' a ser procurados. Se pudéssemos realmente
nos concentrar, se todos usassem programação estruturada, projeto 'top-
down' , tabelas de decisão, se tivéssemos as balas de prata certas, então
não haveria 'bugs'." Beizer, 1990
• A tarefa de efetuar testes em software foi considerada secundária

por muito tempo.
• Geralmente era vista com um castigo para o programador, ou como

uma tarefa onde não se deveria gastar muito com tempo e
investimentos.
• O tema esteve relegado a segundo plano, e, até alguns anos atrás

não se encontrava muita literatura sobre o assunto.
• O objetivo primordial de qualquer técnica para testes é: MAXIMIZAR

(% defeitos encontrados/número de testes feitos)
• As técnicas que vamos estudar auxiliam principalmente na

minimização do número testes.
117
• Deve-se deixar claro que testar não é a única maneira de se

detectarem erros.
• As técnicas do tipo "walkthroughs" (revisões estruturadas) quando bem

aplicadas chegam a detectar até 60% dos defeitos existentes.
• 4.3.1 – Depuração
• Antes de continuar deve ficar bem claro que teste e depuração são
conceitos diferentes.
• Objetivos do Teste: Mostrar que o software tem erros.
• Objetivos da Depuração (Debug): Encontrar a causa do erro

detectado no teste, projetar e implementar as modificações no
programa para correção do erro
Ferramentas de Depuração
• De forma geral, linguagens de alto nível tornam a depuração mais

fácil, pois fornecem mais ferramentas para identificar erros, como o
tratamento de exceções.
– Ex: Java, PHP, .Net, etc. Em ambos os casos as IDEs fornecem a

interface para a depuração
• Em linguagens de baixo nível, erros de código podem causar

problemas difíceis de serem identificados, como corrupção de memória.
Nesse caso, depuradores de memória podem ser necessários.
Exercício
Depurar código java para identificarmos onde está ocorrendo a falha

na exibição das respostas esperadas.
• 4. 3.2 – Teste de caixa branca
• Também conhecidos como Testes Estruturais
• Nesta metodologia os casos de teste são gerados tendo-se

conhecimento da estrutura interna (lógica) do programa, bem como os
seus requisitos.
• É executado na fase de implementação do software
• Estudaremos 2 métodos:
– Cobertura Lógica (Critérios Myers)
– Método dos Caminhos Básicos.
Cobertura Lógica (Critérios Myers)
118
• Este método é constituído de critérios que, quando obedecidos,

determinam os casos de teste a serem gerados.
• Os critérios vão se tornando cada vez mais abrangentes e rigorosos,

partindo-se:
– Do mais simples, ineficiente e menos rigoroso (Cobertura de

Comandos)
– Até o mais complexo, eficiente e rigoroso (Cobertura de Múltiplas
Condições).
• A escolha do critério adequado será norteada pelos seguintes fatores:
– Complexidade do programa a testar;
– Estrutura do programa a ser testado;
– Criticidade do programa a testar;
– Nível de confiança que se deseja atingir.
Complexidade do programa a testar
• Programas mais simples podem ser satisfeitos pela utilização de

critérios menos rigorosos.
• Muitas vezes a utilização de critérios mais rigorosos em programas

muito simples acaba por onerar excessivamente o processo de testes.
Estrutura do programa a ser testado
• Certas estruturas são mais adequadas a determinados critérios.
• Ex: Programas ricos em comandos, podem ser testados utilizando-se o

critério de cobertura de comandos, programas com decisões complexas
devem ser testados por cobertura de decisões /condições.
Criticidade do programa a testar
• Programas cujo funcionamento não é crítico podem exigir testes menos

rigorosos. Portanto, critérios menos rigorosos podem ser suficientes para
se testar o programa.
Nível de confiança que se deseja atingir
• Se o nível de confiança de bom funcionamento é alto, critérios mais

rigorosos são necessários.
Coberturas
• Comandos
119
• Decisões
• Condições
• Decisões-Condições
• Múltiplas Condições
Cobertura de Comandos
• Neste critério os casos de teste devem ser gerados de forma que ao

serem executados, o fluxo do programa passe por todos os
COMANDOS existentes no mesmo.
• 4. 3.3 – Teste de caixa preta
• Conhecido também como Teste Comportamental
• O seu foco principal é testar os requisitos funcionais (Software

entregue, Documentos de especificação, regras de negócio, etc.)
• As técnicas desse tipo de teste permitem derivar série de condições de

entrada que utilizarão completamente todos os requisitos funcionais
para um programa
• O teste Caixa-Preta não é uma alternativa ao Caixa-Branca, porém,

são abordagens complementares.
Possíveis Erros a serem encontrados
• Funções incorretas ou incompletas
• Erros de Interface
• Erro em Estruturas de Dados ou de acesso a bases de dados externas
• Erros de Comportamento ou de Desempenho
• Erros de Inicialização e Termino
Diferentemente do teste Caixa-Branca, que é executado na da fase de

implementação, o teste Caixa-Preta é executado na fase de teste do
projeto.
Métodos
• Partição em Classes de Equivalência
• Método do Grafo de Causa e Efeito
Partição em Classes de Equivalência
120
• Esta metodologia é adequada ao teste de valores típicos de entrada

de um programa.
• Os casos de teste são gerados a partir do conhecimento das entradas,

de maneira sistemática e direta.
• A entrada de dados no programa é dividida em classes que serão

testadas a partir de um caso de uso específico. O objetivo dessa
técnica é eliminar os casos de testes redundante.
• Projeto de casos de teste para particionamento de equivalência é

baseado numa avaliação das classes de equivalência para uma
condição de entrada
Etapas da Técnica
1. Identificar as classes de equivalência de Entrada
2. Refinar as classes de Entrada
3. Identificar as classes de Saída
4. Refinar as Classes de Saída
5. Relacionar as Classes de Entrada e de Saída
6. Definir os casos de teste
•4. 3.4 – Teste de ambiente Web
Introdução
• Com o crescimento da Internet e a evolução das tecnologias

envolvidas, as aplicações na WEB também evoluíram.
• Hoje grande parte dos negócios das organizações também estão na

WEB e consequentemente ocorreu um aumento nos números de
aplicações desenvolvidas para este fim.
• O teste de uma aplicação WebApp (aplicações para Web) é um

conjunto de atividades relacionadas com um único objetivo:
• Descobrir erros
• Mas como?
• Para atingir este objetivo deve ser utilizada uma estratégia de teste
que abrange as revisões e o teste executável
• O processo de teste começa focando os aspectos visíveis da aplicação

ao usuário e abrange os aspectos de tecnologia e infraestrutura, neste
caso em sete etapas de teste:
121
1. No conteúdo,
2. Na função,
3. Na usabilidade,
4. Na navegabilidade,
5. No desempenho,
6. Na capacidade,
7. Na segurança das aplicações e etc.
• A qualidade, segundo Pressman (2011) é incorporada a uma

aplicação Web como consequência de um bom projeto.
• “Não se pode testar a qualidade. Se ela não estiver lá antes de você

começar a testar, não estará lá quando você tiver terminado de testar.”
(Pressman).
• A qualidade é incorporada ao software em todo o processo de

engenharia de software.
Conceito de Teste na Web
• A aplicação adequada de métodos e ferramentas, RTFs e um

gerenciamento e medição sólidos, todos levam à qualidade que é
confirmada durante o teste.
• A qualidade é avaliada aplicando-se uma série de revisões técnicas e

de um processo de teste com o objetivo de examinar uma ou mais das
seguintes dimensões de qualidade:
Dimensões de Qualidade
122
• Conteúdo: É avaliado no nível semântico e sintático. No nível sintático

examina-se a ortografia, pontuação e gramática. No nível semântico
são verificadas a exatidão, consistência e ausência de ambiguidade
das informações.
• Função: É testada para descobrir erros que indicam falta de

conformidade com os requisitos do cliente.
• Estrutura: É avaliada para assegurar o fornecimento apropriado do

conteúdo e função da aplicação. Que seja extensível e possa ser
mantida à medida que novo conteúdo ou funcionalidade é adicionado
• Usabilidade: é testada para garantir que cada categoria de usuário

seja suportada pela interface.
• Navegabilidade: É testada para assegurar que toda a sintaxe e

semântica de navegação sejam experimentadas para descobrir
quaisquer erros de navegação.
• Desempenho: É testado sob uma variedade de condições de

operação, configuração e carga para assegurar que o sistema
responda à interação com o usuário e suporte cargas extremas sem
degradação inaceitável de operação.
• Compatibilidade: É testada executando-se a aplicação em uma

variedade de diferentes configurações hospedeiras tanto no lado
cliente quanto no lado servidor.
• Interoperabilidade: É testada para garantir que a aplicação tenha

uma interface adequada com outras aplicações e/ou bases de dados.
Segurança: É testada para investigar vulnerabilidades potenciais e

tentar explorar cada uma delas.
123
Qualquer tentativa bem-sucedida de invasão é considerada falha de

segurança.
Sumário

……
Perguntas
Perguntas
UNIDADE Temático 4.4 – Teste na implantação do sistema
Introdução
O processo de desenvolvimento de sistemas pode ser visto como uma espiral
com suas etapas movimentando-se para dentro enquanto a estratégia de
teste pode ser vista movimentando-se para fora.
124
Considerando de um ponto de vista procedimental, o teste no contexto

da Engenharia de Software é uma série de quatro passos, que são
implementados sequencialmente.
Estratégia de Teste
• Os testes iniciais também conhecidos como teste de unidade focalizam

um único componente e aplicam-se para descobrir erros nos dados e na
lógica de processamento destes componentes.
• Posteriormente cada componente testado deve ser integrado.
• Neste momento ocorre o teste de integração, cuja preocupação é

verificar problemas associados à construção do programa.
• Após esta fase ocorrem testes de ordem superior, como por exemplo,
o teste de validação com o objetivo de garantir que o software
satisfaz a todos os requisitos informativos, funcionais, comportamentais e
de desempenho.
• A última etapa de teste de ordem superior é o teste de sistema que

verifica se todos os elementos se combinam corretamente e se a
função/desempenho global do sistema é conseguida.
• 4.4.1 – Teste de Unidade
• 4.4.2 – Teste de Integração
• 4.4.3 – Teste de Validação
• 4.4.4 – Teste de Sistema
• 4.4.5 – Teste na Migração
125
Sumário

……
Perguntas
Perguntas
UNIDADE Temático 4.5 – Teste de software em sistema em produção
Introdução
• Estudaremos os testes de manutenção (corretiva, perfectiva, adaptativa e
preventiva) que um sistema em produção poderá sofrer.
• É importante ressaltar que estes tipos de testes de software aplicados na

manutenção de sistemas em produção demandam cuidados adicionais,
notadamente quanto à corretitude e ao tempo reduzido para realizar os
testes, depurar os erros e validar os resultados, uma vez que os sistemas são
ativos da empresa e suas interrupções podem causar danos e prejuízos à
empresa.
• Estudaremos também sobre a importância da medida de confiabilidade e

da disponibilidade de um software.
• Veremos que o conceito de confiabilidade se baseia na execução do

sistema em determinada unidade de tempo sem falhas. Enquanto o conceito
de disponibilidade se baseia na oferta do software em determinada unidade
de tempo, considerando-se, proporcionalmente, o tempo útil de uso e o
tempo de reparo de falhas.
126
Fonte: Pressman, 2006
• A manutenção de software existente pode ser responsável por mais de

70% de todo o esforço despendido por um setor de desenvolvimento de
sistemas.
• A percentagem pode aumentar a medida que mais software é produzido

ou de acordo com o contexto organizacional.
• A mudança é inevitável quando se constroem sistemas baseados em

computador, já que os processos empresariais mudam e se renovam cada
vez mais rápido levando à um ciclo de vida dos produtos cada vez menor.
• Outro fator importante: algumas estatísticas apontam que para cada três
vezes que fazemos uma manutenção, em uma delas adicionamos um erro
por falha nossa.
• Uma das metas principais da Engenharia de Software é a de facilitar a

acomodação das mudanças, reduzir a quantidade de esforço despendido em
manutenção e aumentar a qualidade das tarefas associadas à Manutenção
de Software.
Tipos de Manutenção
• Independentemente do domínio da aplicação, tamanho ou complexidade,

o software continuará a evoluir com o tempo.
• Após seu desenvolvimento um sistema pode ficar operacional, ou seja, em

produção por anos ou até mesmo décadas.
127
Porém durante este período o próprio sistema ou seu ambiente operacional

podem ser corrigidos, modificados ou completados.
Diferentes causas geram manutenções em um software em produção, e

podem ser classificadas em:
➢ Manutenção Corretiva;
➢ Manutenção Adaptativa;
➢ Manutenção Perfectiva;
➢ Manutenção Preventiva.
• 4.5.1 – Teste de software nos diversos tipos de manutenção
• 4.5.2 – Confiabilidade
Confiabilidade e Disponibilidade
• Com o constante desenvolvimento da TI, os sistemas computacionais

têm sido requisitados em quase todas as áreas da atividade humana.
• Essa crescente dependência em relação ao software tem

conscientizado os usuários, que cada vez mais exigem softwares
confiáveis .
• Por isso o software constitui a parte mais cara para a solução de um

problema que envolve a TI.
• Consequentemente desenvolver um software com qualidade tem

exigido um enorme esforço na atividade de teste.
• Os problemas de confiabilidade e disponibilidade podem quase

sempre ser associados a defeitos de projeto ou de implementação.
• Antes de estudarmos sobre a confiabilidade e disponibilidade de um

software, precisamos compreender o conceito de falha. Segundo
Pressman(2011):
• É a falta de conformidade com os requisitos de software.
• Existem diferentes tipos de falhas que podem ser problemáticas ou

catastróficas.
• Enquanto uma determinada falha pode ser corrigida em segundos,

outras necessitarão de horas ou até mesmo meses para serem
corrigidas.
128
• É importante considerar também que às vezes a correção de uma

falha pode resultar na introdução de outros erros que resultarão em
outras falhas
• Componentes dos sistemas que estão sujeitos a falhas:
• Hardware: Erros de fabricação;
• Final de sua vida útil.
• Software: Especificação, projeto ou implementação;
• Operadores humanos;
• Falha ao operar o sistema.
• Dimensões da confiança de um software:
• Segundo Sommerville (2003), confiança de um sistema :
• É uma propriedade do sistema que equivale a sua integridade .
• Ou seja, é o grau de confiança dos usuários de que o sistema

operará como eles esperam e não “falhará” em uso normal.
• Existem quatro dimensões principais de confiança:
Fonte: Sommerville, 2003
• 4.5.3 – Disponibilidade
Disponibilidade
• Se baseia na oferta do software em determinada unidade de tempo,

considerando-se, proporcionalmente, o tempo útil de uso e o tempo de
reparo de falhas.
129
• É a probabilidade de que um programa esteja operando de acordo

com os requisitos em determinado ponto do tempo.
• Se um programa deixar de funcionar repetidamente, pouco importa

se outros fatores de qualidade de software são aceitáveis.
• Confiabilidade é definida como a probabilidade de operação livre

de falhas de um programa de computador num ambiente específico
durante determinado tempo.
• O conceito de confiabilidade de software se baseia na execução do

sistema em determinada unidade de tempo sem falhas.
• A confiabilidade do produto de software é influenciada pelo processo

de software utilizado para desenvolver o produto.
• Um processo orientado no sentido de evitar defeitos poderá

desenvolver um sistema confiável.
Segurança de Software
• Quando o software é usado como parte do controle de Ambientes

Críticos, as falhas tornam-se muito mais difíceis de serem detectadas,
podendo resultar em significativos danos e até perda de vidas.
• É uma atividade que se concentra na identificação e avaliação de

casualidades em potencial que possam exercer um impacto negativo
sobre o software e fazer com que todo o sistema falhe.
• Se as casualidades puderem ser identificadas, é possível especificar

características de projeto que as eliminem ou controlem. Um processo
de modelagem e análise é levado a efeito. Inicialmente, as
casualidades são identificadas e dispostas por categorias, criticidade e
risco.
• Logo que as casualidades são identificadas e analisadas, os requisitos

relacionados à segurança podem ser especificados.
• A especificação pode conter uma lista de eventos indesejáveis e as

respostas desejadas a esses eventos.
Proteção
• A proteção de um sistema é uma avaliação do ponto em que o

sistema protege a si mesmo de ataques externos.
• Erros no desenvolvimento de um sistema podem levar a falhas de

proteção.
• Sem um nível razoável de proteção, a disponibilidade, a

confiabilidade e a segurança do
130
sistema poderão ser comprometidas se ataques externos provocarem

algum dano ao sistema.
Medida de Confiabilidade
• Um meio simples de se medir a confiabilidade de um software é

observar o tempo para a ocorrência da próxima falha.
• Métricas que podem ser utilizadas para medir a confiabilidade:
• O tempo médio entre falhas, MTBF (mean time between failure),

representa o tempo esperado para a ocorrência da próxima falha, ou
seja, é o tempo durante o qual o software funciona sem falhas
(Delamare & Maldonado & Jino, 2007).
• É calculado considerando-se a soma de duas medidas:
• MTTF (mean time to failure) – Tempo médio de uso até a falha do

software e
• MTTR (mean time to repair) – Tempo médio de reparo da falha no

software.
MTBF = MTTF + MTTR
• MTBF – tempo médio de ocorrência de falhas ( mean time between

failure )
• MTTF – tempo médio até a ocorrência de falha (mean time to failure )
• MTTR – tempo médio de reparo ( mean time to repair)
• Portanto, quanto maior for o MTBF e o MTTF em relação ao MTTR

mais tempo o sistema ficou operativo.
• Tempo gasto para reparar ou reiniciar o sistema
• A medida de disponibilidade de software considera as medidas MTTF

e MTTR, sendo mais sensível ao MTTR ou seja, tempo de correção da
falha, pois a disponibilidade é obtida através de:
131
Disponibilidade = MTTF x 100%
(MTTF + MTTR)
• Quanto mais próximo de 1 for a disponibilidade, mais disponível o

software esteve no período, logo, mais será produtivo.
Sumário

……
Perguntas
Perguntas
Unidade Temático 4.6 – Ferramentas de teste de software
Introdução
• 4.6.1 – Ferramentas de teste no desenvolvimento de sistema
• 4.6.2 – Ferramentas de teste para o programa
• 4.6.3 – Ferramentas de teste para o ambiente Web
• 4.6.4 – Ferramentas de teste para sistemas em produção
132
Sumário

……
Perguntas
1. Qual é a importância dos testes de software?
Descobrir o maior número possível de defeitos do software,

assegurar que o teste atende a todos os requisitos de sistema
estabelecido entre o desenvolvedor e o cliente.
2. Segundo Pressman, o teste de software é um conjunto de atividades

que podem ser planejadas com antecedência e executadas
sistematicamente. Por esta razão deverá ser definido:
a) Uma metodologia de desenvolvimento e um modelo ( template )

para o teste.
b) Um padrão de desenvolvimento e um processo de teste de software.
c) Um cronograma de teste e um padrão de desenvolvimento.
d) Um processo de teste de software e um modelo ( template) para o

teste.
e) Uma metodologia de desenvolvimento e um padrão de

desenvolvimento.
3. Sobre os objetivos de teste de software, considere as afirmativas

abaixo e assinale a alternativa correta:
1. A atividade de teste é o processo de executar um programa

com a intenção de descobrir um erro.
2. A atividade de teste pode comprovar a ausência de erros.
3. Um bom caso de teste é aquele que tem uma elevada

probabilidade de revelar um erro ainda não descoberto
4. Um teste bem- sucedido é aquele que revela um erro não

descoberto.
133
a) Somente as afirmativas 3 e 4 são verdadeiras.
b) Somente a afirmativa 3 é verdadeira.
c) As afirmativas 1, 2, 3 e 4 são verdadeiras.
d) Somente as afirmativas 1, 3 e 4 são verdadeiras.
e) Somente as afirmativas 2 e 4 são verdadeiras.
3. Analise o gráfico abaixo e responda a importância das revisões

constantes na produção do software, visando um uso consciente dos
recursos.
Quanto mais tarde os defeitos

são identificados, mais caro se
torna a sua manutenção
4. No processo de teste de software, temos as fases de
Planeamento e Preparação. Explique suas finalidades e
responda por que elas são atividades transversais as demais
fases do processo?
Planeamento: Elaboração e revisão da Estratégia de teste e do

plano de teste;
Preparação: Preparação do ambiente de teste, incluindo
equipamentos, rede, pessoal, software e ferramentas.
Porque todas as fases precisam de planeamento e preparação
para serem executados, tendo a preocupação com a aderência
das atividades ao processo
5. Qual o Objetivo das Revisões Técnicas Formais?
• Descobrir erros na função, na lógica ou na implementação,

para qualquer representação do software;
• Verificar se o software sob revisão satisfaz seus requisitos;
• Garantir que o software tenha sido representado de acordo com
padrões predefinidos;
134
• Conseguir software que seja desenvolvido de modo uniforme;

• Tornar os projetos mais administráveis.
135

Metodos de Analise, Desenho e Implementacao de Sistemas

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Metodos de Analise, Desenho e Implementacao de Sistemas

Enviado por

Direitos autorais:

Formatos disponíveis

MANUAL DO CURSO DE LICENCIATURA EM

Disciplina: Métodos de Analise, Desenho e Implementação de

INSTITUTO SUPERIOR DE CIÊNCIAS E EDUCAÇÃO A DISTÂNCIA - ISCED

Direitos de autor (copyright)

Este manual é propriedade do Instituto Superior de Ciências e Educação a Distância (ISCED), e

A não observância do acima estipulado o infractor é passível a aplicação de processos judiciais

Instituto Superior de Ciências e Educação a Distância (ISCED)

O Instituto Superior de Ciências e Educação a Distância (ISCED) agradece a colaboração dos

Autor Msc.Solomone Rumhungwe

Direcção Académica do ISCED

Revisão Científica e Português

Ano de Publicação 2018

Local de Publicação ISCED – BEIRA

TEMA – I: CONCEITOS GERAIS DE PROCESSO DE DESENVOLVIMENTO DE SOFTWARE 9

TEMA -II: MODELAGEM DE SISTEMA DE INFORMAÇÃO 25

TEMA – III: IMPLEMENTACAO 71

TEMA -IV: TESTE DE SOFTWARE 107

Benvindo à Disciplina/Módulo de Analise, Desenho e

Ao terminar o estudo deste módulo de Analise, Desenho e

▪ Demonstrar uma compreensão do processo de desenvolvimento de

▪ Investigar requisitos do usuário

Quem deveria estudar este módulo

Este Módulo foi concebido para estudantes do 2º ano do curso de

Como está estruturado este módulo

Este módulo de ADISI, para estudantes do 2º ano do curso de

Conteúdo desta Disciplina / módulo

A equipa dos académicos e pedagogos do ISCED, pensando em si,

Auto-avaliação e Tarefas de avaliação

Tarefas de auto-avaliação para este módulo encontram-se no final

Use este espaço para dar sugestões valiosas, sobre determinados

O principal objectivo deste campo é o de ensinar aprender a

Durante a formação e desenvolvimento de competências, para

1º Praticar a leitura. Aprender a Distância exige alto domínio de

2º Fazer leitura diagonal aos conteúdos (leitura corrida).

3º Voltar a fazer leitura, desta vez para a compreensão e

4º Fazer seminário (debate em grupos), para comprovar se a sua

5º Fazer TC (Trabalho de Campo), algumas actividades práticas ou

IMPORTANTE: Em observância ao triângulo modo-espaço-tempo,

melhor em casa/biblioteca/café/outro lugar? Estudo melhor à

Privilegia-se saber bem (com profundidade) o pouco que puder ler e

Dica importante: não recomendamos estudar seguidamente por

Uma longa exposição aos estudos ou ao trabalho intelectual

Não estude na última da hora; quando se trate de fazer alguma

Organize na sua agenda um horário onde define a que horas e que

É importante identificar as ideias principais de um texto, pois será

colocar comentários seus relacionados com o que está a ler; a melhor

Tarefas (avaliação e auto-avaliação)

O estudante deve realizar todas as tarefas (exercícios, actividades e

Os trabalhos devem ser entregues ao Centro de Recursos (CR) e os

Muitos perguntam: Com é possível avaliar estudantes à distância,

TEMA – I: CONCEITOS GERAIS DE PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

UNIDADE Temática 1.1. Introdução, Conceitos Gerais: objectivos e

UNIDADE Temática 1.1. Introdução, Conceitos Gerais e Ciclo da vida e atividade

O ciclo de vida de um sistema Software incluem análises e

Para atingir este objetivo se utilizam metodologias para definir o

▪ As fases de elicitação e especificação de requisitos, análise e

É um conjunto de procedimentos que estabelecem o funcionamento do

Ex: Secretária que organiza o agendamento dos pacientes de

É um conjunto de instruções que, orquestradas entre si, manipulam um

Ex1: Sistema Web de agendamento de consultas médicas

Ex2: Sistema de Monitoramento de alerta de tempestades

O software é a automatização de um sistema.

Nem todo sistema é automatizado.