Buscar

Metodos de Analise , desenho e Implementacao de Sistemas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes
Você viu 3, do total de 141 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes
Você viu 6, do total de 141 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes
Você viu 9, do total de 141 páginas

Faça como milhares de estudantes: teste grátis o Passei Direto

Esse e outros conteúdos desbloqueados

16 milhões de materiais de várias disciplinas

Impressão de materiais

Agora você pode testar o

Passei Direto grátis

Você também pode ser Premium ajudando estudantes

Prévia do material em texto

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 
 i 
 
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 
 
 
 
http://www.isced.ac.mz/
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 ii 
 
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 
Coordenação 
Design 
Financiamento e Logística 
Revisão Científica e 
Linguística 
Ano de Publicação 
Local de Publicação 
Direcção Académica do ISCED 
Instituto Superior de Ciências e Educação a Distância (ISCED) 
Instituto Africano de Promoção da Educação a Distancia (IAPED) 
Português 
 
2018 
ISCED – BEIRA 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 iii 
 
Índice 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 iv 
 
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 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 v 
 
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 
 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo:ADISI 
 1 
 
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 
 
 
Objectivos 
Específicos 
▪ 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; 
▪ 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 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 2 
 
▪ 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. 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 3 
 
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. 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 4 
 
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 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 5 
 
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 numanoite 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 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 6 
 
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. 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 7 
 
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. 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 9 
 
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 eCiclo 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. 
 
Objectivos 
específicos 
 
▪ 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 
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 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 10 
 
 É 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 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 11 
 
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). 
 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 12 
 
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). 
 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 13 
 
 
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 complexidadedo 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: 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 14 
 
• 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. 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 15 
 
 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 
Respostas: 1A, 2C, 3V… 
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, 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 16 
 
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. 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 17 
 
 
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 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 18 
 
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 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 19 
 
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. 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 20 
 
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. 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 21 
 
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 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 22 
 
• É 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 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 23 
 
✓ 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 DevelopmentEnvironment – 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 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 24 
 
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 
Exercícios de AUTO-AVALIAÇÃO 
Perguntas 
Respostas: 1A, 2C, 3V… 
 
http://astah.net/
http://www-01.ibm.com/software/awdtools/developer/rose
http://jude.change-vision.com/jude-web/product/index.html
http://argouml.tigris.org/
http://projects.gnome.org/dia/
http://www.fujaba.de/
http://staruml.sourceforge.net/en/
http://uml.sourceforge.net/
http://www.visual-paradigm.com/download/
http://members.change-vision.com/files/astah_community
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 25 
 
Exercícios para AVALIAÇÃO 
 
Perguntas 
Respostas: 1A, 2C, 3V… 
 
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.4. EXERCÍCIOS deste tema 
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. 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 26 
 
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 é? 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 27 
 
– É 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. 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 28 
 
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. 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 29 
 
 
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 
 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 30 
 
 
 
• 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. 
 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 31 
 
 
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. 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 32 
 
 
Aplicação Prática 
• 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. 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 33 
 
• 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 
…… 
 
Exercícios de AUTO-AVALIAÇÃO 
Perguntas 
Respostas: 1A, 2C, 3V… 
Exercícios para AVALIAÇÃO 
 
Perguntas 
Respostas: 1A, 2C, 3V… 
 
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: 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 34 
 
 
• 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 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 35 
 
 
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. 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 36 
 
 
• 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. 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 37 
 
 
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. 
 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 38 
 
 
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. 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI39 
 
▪ 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. 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 40 
 
 
• 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. 
 
 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 41 
 
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. 
 
Aplicação Prática 
• 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). 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 42 
 
• 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. 
Aplicação Prática 
 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 43 
 
 
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 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 44 
 
 
• 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 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 45 
 
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 projetode 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. 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 46 
 
– 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. 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 47 
 
• 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. 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 48 
 
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. 
• 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: 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 49 
 
• 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; 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 50 
 
– 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... 
 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 51 
 
 
 
 
 
• 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 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 52 
 
 
 
 
 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 53 
 
 
 
 
 
 
DIAGRAMA DE SEQUÊNCIA – EXEMPLO – FLUXO NORMAL 
1. Sistema Apresenta Tela de Locação. 
 
ISCED Curso de Gestão de Sistema de Informação; 20 Ano Disciplina/Módulo: ADISI 
 54 
 
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. 
• DIAGRAMA DE COMUNICAÇÃO

Outros materiais