Práticas de Engenharia de Software

Prévia do material em texto

19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3n… 1/47
PRÁTICAS DE ENGENHARIA DEPRÁTICAS DE ENGENHARIA DE
SOFTWARESOFTWARE
PROJETO DE SOFTWARE COMPROJETO DE SOFTWARE COM
UML – INTRODUÇÃO,UML – INTRODUÇÃO,
CONCEITOS E VISÃOCONCEITOS E VISÃO
COMPORTAMENTALCOMPORTAMENTAL
Autor: Esp. Elaine Barbosa de Figueiredo
IN IC IAR
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3n… 2/47
introdução
Introdução
A engenharia de software é das engenharias a capaz de lidar com padrões de
projetos de software em computação. Um projeto de software caracteriza-se
pela análise e elementos como a UML (Uni�ed Modeling Language) propicia o
levantamento dos requisitos, sua análise e a modelagem dos artefatos que
comporão o Sistema. Ela é um padrão para o paradigma de Orientação a
Objetos (OO). RUP (Rational Uni�ed Process) tem na UML um pilar e,
integrando-se devido aos diagramas, compõem a documentação do projeto.
Na UML temos um conjunto de diagramas que permitem analisar cada
característica do software.
Existem diversos diagramas diferentes que utilizam o padrão UML como
forma de demonstrar seus resultados. O Diagrama de Caso de Uso, por
exemplo, representa cada funcionalidade do Sistema projetado e é
imprescindível para análise de requisitos, um complementa o outro, pois são
descritas como ocorrerão as interações e quem as realiza (os atores). O
diagrama de caso de uso mapeia as funcionalidades, suas interações e quem
participa da mesma.   Outro diagrama como o de atividades foca na
funcionalidade como tarefa e destrincha as funções como um processo,
pensando em cada etapa. O conjunto de ferramentas de análise interagindo
entre si irão descrever o comportamento do sistema.
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3n… 3/47
O Projeto Orientado a Objetos possui uma complementaridade com o RUP,
ambos complementam-se e foram desenvolvidos   de modo que as fases e
disciplinas do RUP demanda artefatos especí�cos da UML.
RUP (Rational Uni�ied Process – Processo
Uni�icado da Rational - IBM
Segundo Kruchten (2003), o RUP é um Framework de Processos com
abordagem disciplinada, o objetivo é garantir a produção de software de alta
qualidade dentro de prazos e orçamentos previsíveis. O RUP contém
elementos de todos os modelos gerais de processo, apoia a iteração e
descreve boas práticas de especi�cação e projeto (Sommerville, 2011).
Resgata seis das melhores práticas no desenvolvimento de software de forma
satisfatória para projetos e organizações (KRUTCHTEN, 2003).
Projeto de SoftwareProjeto de Software
Orientado a Objetos comOrientado a Objetos com
UMLUML
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3n… 4/47
#PraCegoVer: Fases e Disciplinas do RUP (Rational Uni�ed Process) Processo
Racional Uni�cado. As fases do RUP são Iniciação, Elaboração, Construção e
Transição, na imagem aparecem na parte superior do grá�co; Na parte
inferior são as iterações, os ciclos e marcos do projeto entre as fases. Ao lado
esquerdo são as Disciplinas: Modelagem de Negócios, Requisitos, Análise e
Design, Implementação, Teste, Implantação, gerência de con�guração e
mudança, Gerenciamento de Projeto e Ambiente. O Grá�co representa a
concentração de atividades das disciplinas do projeto ao longo das fases: As
disciplinas de Modelagem de Negócio, Requisitos e Análise de Design tem seu
pico de trabalho na fase de iniciação ou concepção – 1ª fase; Na fase de
elaboração – 2ª fase as disciplinas de Modelagem de Negócios e Requisitos
continuam com um bom volume no �uxo de atividades e as disciplinas de
Análise e Design e Implementação tem um grande aumento de volume no
�uxo de trabalho; Na fase de construção – 3ª fase a disciplina de Análise e
Design diminui um pouco o �uxo de trabalho e o pico está na disciplina de
Implementação, responsável pela codi�cação; Na fase de Transição – 4ª fase,
há diminuição da disciplina de implementação e há um pico da disciplina de
implantação; As disciplinas teste há alguns picos nas fases de construção e
que transita entre as quatro fases; As disciplinas de Gerência de Con�guração
e Mudança, Gerenciamento de Projeto e Ambiente transitaram entre as
quatro fases do RUP.
Figura 1.1 - Fases e Disciplinas do RUP 
Fonte: Adaptado de Krutchten (200)
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3n… 5/47
De acordo com Sommerville (2011), as melhores práticas abordadas são:
1. Desenvolver o software iterativamente;
2. Gerenciar Requisitos;
3. Usar arquiteturas baseadas em componentes, aplica
componentização;
4. Modela o software visualmente por meio da UML;
5. Veri�ca e Valida a qualidade do software;
6. Gerência e Controle de mudanças do projeto de software.
Segundo Sommerville (2011, p. 34), o RUP é constituído por quatro (4) fases,
relacionadas aos negócios e não tão técnico, que são:
1. Concepção: o objetivo desta fase é estabelecer um caso de
negócio para o sistema. Identi�cam-se os stakeholders (envolvidos),
avaliação e análise de viabilidade; 
2. Elaboração: o entender o domínio do problema, estabelecer um
framework arquitetural para o sistema, desenvolver o plano de
projeto e identi�car seus principais riscos. O objetivo  desta fase é
obter um modelo de requisitos re�nado para o sistema (os casos
de uso e os principais diagramas da UML são especi�cados),
descreve-se a arquitetura e planeja-se o desenvolvimento do
software. 
3. Construção: relacionado ao projeto, desenvolvimento,
implementação e testes. São desenvolvidos partes do sistema em
paralelo e integradas gradativamente durante esta fase. O objetivo
é o   software em funcionamento e a documentação associada
pronta para ser liberada para os usuários �nais. 
4. Transição: nesta fase, transfere-se o sistema do ambiente de
desenvolvimento para o ambiente do usuário �nal, o sistema
funciona no ambiente real. É uma atividade importante, no
entanto, é ignorada na maioria dos modelos de processo de
software, pois é onerosa e quase sempre problemática. O objetivo é
ter um sistema de software documentado, funcionando
corretamente em seu ambiente �nal.
Cada uma das fases descritas   pode ser realizada de forma iterativa   tendo
seus resultados obtidos de maneira incremental.
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3n… 6/47
Work�ow é como são chamadas as atividades que ocorrem durante o
processo de desenvolvimento. Existem pelo menos nove work�ows principais,
que são: Modelagem de negócios, Requisitos, Análise e Projeto,
Implementação, Teste, Implantação, Gerenciamento de Con�guração e
Mudança, Gerenciamento de Projeto e Ambiente. O Quadro 1.1 a seguir
apresenta a descrição de cada um deles:
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3n… 7/47
Work�ow
(Processo)
Descrição de funcionamento
Modelagem de
Negócios
Os processos de negócio são modelados
usando casos de uso de negócios.
Requisitos
Os agentes que interagem com o sistema são
identi�cados e os casos de uso são
desenvolvidos para modelar os requisitos do
sistema.
Análise e Projeto
Um modelo de projeto é criado e
documentado usando modelos de
arquitetura, modelos de componente,
modelos de objetos e modelos de sequência.
Implementação
Os componentes de sistema são
implementados e estruturados em
subsistemas de implementação. A geração
automática de código com base os modelos
de projeto ajuda a acelerar esse processo.
TesteO teste é um processo iterativo realizado em
conjunto com a implementação. O teste de
sistema segue o término da implementação.
Implantação
Uma versão do produto é criada, distribuída
aos usuários e instalada no local de trabalho.
Gerenciamento de
Con�guração e
Mudança
Este work�ow de apoio gerencia mudanças
no sistema.
Gerenciamento de Este work�ow de apoio gerencia o
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3n… 8/47
Quadro 1.1: Work�ows no Rational Uni�ed Process 
Fonte: Adaptado de Sommerville (2011, p. 35).
Documento de Visão do RUP
Este documento captura restrições de design e requisitos de alto nível para
compreensão do sistema que será desenvolvido. Fornece uma visão ampla do
produto. Facilita a análise, e é de grande relevância durante as primeiras
fases, captura todas as perspectivas do sistema (Krutchten, 2003). A estrutura
varia de acordo com as características do projeto e não há um padrão.
Depende da complexidade e nível de detalhamento. Os principais itens que
compõe a estrutura do documento são: nome do projeto, controle de versões,
breve descrição do produto, matriz de papéis, visão do produto, escopo,
viabilidade, requisitos, casos de uso, arquitetura, manual, guia de instalação e
glossário (Medeiros, 2004).
praticar
Vamos Praticar
Projetos desenvolvimento do sistema.
Ambiente
Este work�ow está relacionado à
disponibilização de ferramentas apropriadas
de software para a equipe de
desenvolvimento.
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3n… 9/47
O processo uni�cado (RUP) reúne boas práticas de especi�cação de projeto, é um
modelo de processo organizado em fases que podem gerar um conjunto de
artefatos a cada fase. Assinale a opção que identi�ca a fase do RUP na qual são
incluídos o re�namento e a expansão dos casos de uso, os requisitos não funcionais
e a descrição da arquitetura.
a) Concepção
b) Construção
c) Elaboração
d) Produção
e) Transição
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 10/47
O Dicionário eletrônico Houaiss (2009, on-line) de�ne a palavra requisito,
como uma condição necessária para a obtenção de certo objetivo, ou para o
preenchimento de certo �m.Segundo o glossário de terminologias de
Engenharia de Software do instituto IEEE - The IEEE Standard Glossary of
Software Engineering Terminology (1990), Requisito é uma condição ou
capacidade necessária para um usuário resolver um problema ou alcançar um
objetivo para satisfazer uma especi�cação em um sistema ou em um
componente com uma representação documentada. Logo, quando falamos
de requisitos, na prática, estamos falando daquilo que é necessário para que
um sistema de informação possa ser utilizado na prática. É uma relação entre
a necessidade do usuário e o artefato que deverá suprir a tal necessidade.
Engenharia de Requisitos
Essa parte da engenharia de software engloba um conjunto de atividades
para a produção do documento de requisitos e sua manutenção ao longo do
tempo. Conforme Pressman e Maxim (2016), a engenharia de requisitos
Requisitos de SoftwareRequisitos de Software
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 11/47
constrói uma ligação entre o projeto e sua construção.  Há diversas atividades
e técnicas para obter os requisitos e documentá-los e estas variam de um
projeto para outro, e há atividades comuns, são elas:
Elicitação de requisitos;
Análise de requisitos;
Documentação de Requisitos;
Validação de requisitos;
Gerenciamento de requisitos.
O que são requisitos?
É possívelPode-se conceituar requisito de software como qualquer função ou
característica que um sistema deve ter, as restrições que deve atender ou
outras propriedades que devem ser fornecidas, de forma que satisfaça os
objetivos das organizações e resolver um conjunto de problemas. De�nem o
que o sistema deve fazer e as circunstâncias sobre as quais deve operar.
De�nem os serviços que o sistema deve fornecer e dispõem sobre as
restrições à operação do sistema.
Requisitos de alta qualidade devem ser: claros, completos, sem ambiguidades,
Implementáveis, consistentes e testáveis.
Elicitação de Requisitos: Elicitação – ato ou efeito de elicitar, portanto a
elicitação de requisitos é a tarefa de descobrir, explicitar e obter o máximo de
informações sobre os requisitos de um produto de software .Elicitar
requisitos é a atividade voltada para descobrir, identi�car, deduzir, extrair,
evocar, obter (Houaiss, 2009);
Classi�icação de Requisitos
A Norma ISO/IEC 9126 de�ne seis características de qualidade de software
que devem ser avaliados nos requisitos:
Funcionalidade (�nalidade do produtos – tarefas executadas);
Usabilidade (esforço para utilizar, aprender o produto);
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 12/47
Con�abilidade (frequência de falhas, capacidade de recuperação do
sistema);
E�ciência (desempenho, velocidade, processamento das transações);
Manutenibilidade (esforço necessário para modi�car, alterar o
sistema);
Portabilidade (capacidade de transferir o produto para outros
ambientes).
As características estabelecidas para qualidade de software na norma ISO,
estabelecem parâmetros para classi�cação dos requisitos.
Os Requisitos são classi�cados, basicamente, em quatro tipos: Requisitos
Funcionais (RF), Requisitos Não-Funcionais (RNF), Requisitos Inversos e
Requisitos de Domínio ou Regra de Negócio.
Requisitos Funcionais: Descreve funcionalidade e serviços do sistema, como
o sistema deve reagir a entradas especí�cas, como deve se comportar e como
o operamos. Refere-se aos objetivos do sistema.
Depende diretamente do tipo do software, usuários esperados e ambiente
em que o software é utilizado;
Exemplos:
RF01 - O sistema deve permitir o cálculo dos gastos diários, semanais,
mensais e anuais com o pessoal. – Exemplo de Requisito Funcional da rotina
(funcionalidade, objetivo) que calcula os gastos de um sistema de folha de
pagamento ou um ERP.
RF02 - O sistema deve permitir consultar informações gerenciais operacionais
da empresa. – Exemplo de Requisito Funcional da rotina de consulta
(funcionalidade, objetivo) de informações gerenciais de um sistema
empresarial.
Requisitos Não-Funcionais: De�nem propriedades e restrições do sistema
(tempo, espaço etc), quali�cam o sistema. Requisitos podem especi�car o uso
de determinadas linguagens de programação e métodos de desenvolvimento.
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 13/47
Requisitos não-funcionais podem ser mais críticos que requisitos funcionais.
Devido à sua própria de�nição, são esperados mensuráveis. Assim, deve-se
associar uma característica/propriedade como forma de medida/referência a
cada requisito não-funcional elicitado, no Quadro 1.2 abaixo, são listadas
algumas características com suas medidas e exemplos: 
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 14/47
Propriedade/Característica Medida/Referência
Velocidade 
EFICIÊNCIA
●   Tempo do Processamento de
transações; 
●   Tempo de Resposta do Usuário a
um evento ou tarefa do sistema; 
Ex.: 
RNF 01– O tempo de resposta do
sistema não deve ultrapassar 30
segundos 
RNF 02 – O Sistema deverá consultar o
estoque em até 10 seg.
Tamanho
●   K bytes ocupados (Capacidade); 
●   Quantidade de memória RAM
ocupada; 
Ex.: 
RNF 03 – A imagem de Upload deverá
ser maior que 500kb;RNF 04 – Para execução ideal do
software, o sistema deve ter 200Mb
livre de memória disponível;
Facilidade de Uso 
USABILIDADE
●   De�nições referentes ao projeto de
interface (tela), como: interface
amigável, cor, logo, botões e campos
especí�cos; 
●   Tempo de treinamento dos
usuários; 
●   Quadros de ajuda; 
Ex.: 
RNF 05 – Todas as interfaces deverão
seguir o padrão de cores e logo da
empresa; 
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 15/47
RNF 06 – Os usuários do sistema
receberão treinamento de 40 horas
para os principais módulos do
sistema. 
RNF 07 – O sistema terá telas de ajuda
para todas as funcionalidades, e em
todas as interfaces;
CONFIABILIDADE
●   Tempo médio de falhas; 
●   Probabilidade de indisponibilidade; 
●   Taxa de ocorrências de falhas; 
RNF 08 – Apresentando falha na
execução, o usuário não perderá os
conteúdo em até 1 minuto antes da
falha apresentada.
ROBUSTEZ
●   Tempo de reinício após falhas; 
●   Percentual de eventos causando
falhas; 
●   Probabilidade de corrupção de
dados após falhas; 
RNF 09 – Após apresentar uma falha,
o sistema deverá restabelecer-se em
até 20min.
PORTABILIDADE
●   Capacidade de transferir o sistema
para vários ambientes; 
RNF 10 – O sistema será desenvolvido
para ambiente Windows.
SEGURANÇA ●     Restrições de Acesso; 
●     Políticas de Senhas; 
●     Políticas de Segurança
(Criptogra�a); 
RNF 11– As senhas dos usuários do
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 16/47
Quadro 1.2 – Propriedades e medidas dos requisitos não funcionais 
Fonte:  Adaptado de Sommerville (2011,p.63).
Requisitos de Domínio ou Regra de Negócios: São declarações que
restringem, derivam e fornecem condições de existência, representando o
conhecimento do negócio; São políticas, condições ou restrições que devem
ser consideradas na execução dos processos existentes em uma organização.
Estabelecem requisitos gerais para o sistema, provenientes do próprio
negócio como normas, políticas, legislações etc. Descrevendo a maneira pela
qual a organização funciona. Exemplos de regras do negócio:
RNF01 – O valor total de um pedido é igual à soma dos totais dos itens do
pedido acrescido de 10% de taxa de entrega.
RNF03 – Um aluno não pode se inscrever em mais de seis disciplinas por
semestre letivo.
A RNF01 trata-se de uma regra que calcula a 10% de taxa de entrega sobre o
total do pedido, esta regra de negócio pode ser diferente para a empresa B,
que calcula apenas 5% de taxa de entrega sobre o total do pedido, por
exemplo.
Já a RNF03, trata-se de uma regra de sistema acadêmico em que o aluno pode
inscrever-se em no máximo seis (6) disciplinas em um semestre, para uma
outra instituição é permitida a inscrição em no máximo oito (8) disciplinas por
semestre.
sistema deverão ter no mínimo oito
caracteres alfanuméricos, alternando
números, letras e caracteres especiais;
DISPONIBILIDADE
Capacidade do sistema estar sempre
em operação. 
RNF 12 – O sistema estará disponível:
24h por dia 7 dia por semana (24x7)
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 17/47
Observe que a regra de negócio, segue as regras e a política do negócio, e
para cada empresa as regras se diferem para um mesmo tipo sistema, como
no exemplo, o sistema que calcula a taxa de entrega é o mesmo, com regras
distintas para a empresa A e B.
Estudo de Caso – identi�cação e escrita de requisitos
Descritivo do sistema: Bibliocultura
Deseja-se construir um sistema para uma rede de bibliotecas, a Bibliocultura.
Para cada biblioteca deseja-se armazenar dados como: seu código, o nome e
região. Dentro de cada biblioteca tem-se as obras, das quais são cadastradas
uma única vez. Para cada uma das obras deseja-se armazenar o seu ISBN,
título, autor, ano de publicação, tipo e nome da editora. As obras podem ser
emprestadas a usuários que possuem cadastro. Dos usuários deseja-se
armazenar o seu código, nome e endereço. Também é possível fazer reserva
de uma determinada obra, sendo que a reserva tem uma data de vencimento.
Para o empréstimo são armazenadas as datas de empréstimo e devolução da
obra. Os usuários poderão consultar informações sobre obras e realizar a
reserva on line ou por meio de dispositivo mobile. Para os empréstimos, não
renovados e em atraso, o sistema calcula uma multa diária. O bibliotecário
será responsável pelos cadastros. O administrador do sistema tem acesso a
todas as funcionalidades e é o responsável pela atribuição de privilégios de
cada per�l de usuário.
Para o sistema descrito podemos classi�car e descrever, a partir do texto,
alguns exemplos de requisitos.
Requisitos Funcionais:
RF01- O Sistema deverá cadastrar as obras com os dados: ISBN, título, autor,
ano de publicação, tipo e nome da editora;
RF02- O Usuário poderá pesquisar obras por: ISBN, título e autor;
RF03- Somente usuários previamente cadastrados poderão emprestar e
reservar obras;
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 18/47
RF04- O Sistema deverá emitir relatórios de obras por editora;
Requisitos Não Funcionais
E�ciência:
RNF01- O sistema deverá realizar qualquer pesquisa em até 5s.
RNF02- O sistema deverá emitir relatórios em até 15s.
Segurança:
RNF03- As consultas e reservas de obras, realizar-se-á, por usuários logados
ao Bibliocultura, por meio de senha previamente cadastrada.
RNF04- Os usuários Bibliocultura deverão cadastrar uma senha alfanumérica
de no mínimo 6 (seis) caracteres;
Portabilidade:
RNF05- O sistema Bibliocultura será on line, funcionando por meio da web.
RNF06- O sistema Bibliocultura fornecerá uma interface mobile aos usuários
para acesso, por meio de tablets e smartphones;
Requisitos Inversos
RI01- Não compõe o Escopo do Bibliocultura a negociação e venda de obras;
Regras de Negócio (Requisitos de Domínio)
RN01- Os empréstimos em atraso terão multa diária de R$2,00 por obra e dia
de atraso;
RN02- Os usuários com empréstimos em atraso, �carão bloqueados para
novos empréstimos, num período de 30 (trinta) dias, mesmo que regular;
Neste estudo de caso pudemos classi�car alguns requisitos mediante a breve
descrição do sistema a ser desenvolvido, porém este descritivo inicial não
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 19/47
documenta e descreve o sistema por completo, há algumas informações do
sistema que necessitam de maiores esclarecimentos, e para isso o
pro�ssional que trabalha e documenta os requisitos deverá contatar o cliente,
conhecer melhor o ambiente em que o sistema atuará e os usuários que
estarão em contato com o sistema. Para detalhar e identi�car as reais
necessidades do sistema a ser desenvolvido o Analista de Requisitos estuda,
seleciona e aplica algumas técnicas para levantamento de requisitos antes da
especi�cação �nal, vejamos algumas técnicas para levantamento de
requisitos.
praticar
Vamos Praticar
Sobre requisitos funcionais de sistema, foram relacionados os seguintes requisitos:
I - o sistema deve ter versões disponíveis para plataformas web. 
II- O sistema deve ter versão na plataforma Móvel(Android e iOS); 
III - o sistema deve restringir o acesso ao painel de gestão estratégica do sistema
apenas a diretores do órgão; 
IV - o sistema deve permitir que o painel de gestão estratégica, acessado pelos
diretores, seja atualizado com os dados das operações negociais do órgão, a cada
três minutos; 
V - o sistema deve permitir que o relatório de fechamento mensal das operações
seja disponibilizado aos diretores no primeiro dia útil do mêssubsequente, via
painel de gestão estratégica. 
VI - a emissão dos relatórios ocorrerá em, no máximo 30s. 
VII - o sistema deverá ter uma rotina de importação de dados.
Sobre requisitos funcionais deste sistema, está correto o que se a�rma em:
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 20/47
a) I e II, apenas
b) I e III, apenas.
c) III e IV, apenas.
d) I, II e IV, apenas.
e) II, III e IV, apenas.
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 21/47
A modelagem de caso de uso complementa e auxilia no re�namento dos
requisitos de software e a modelagem refere-se ao Design do diagrama de
Caso de uso (interações entre atores e casos de uso) e ao detalhamento de
Caso de uso que de�ne a execução passo a passo de cada caso de uso.
Modelagem de Caso de Uso
A  modelagem de caso de uso é amplamente utilizada como técnica e apoio à
elicitação de requisitos, pois um caso de uso representa uma funcionalidade e
pode descrever o que o usuário espera de um sistema.
O Diagrama de Casos de Uso tem o objetivo de auxiliar a comunicação entre
os analistas e o cliente. Descreve um cenário que mostra as funcionalidades
do sistema do ponto de vista do usuário.
O cliente deve ver no diagrama de Casos de Uso as principais funcionalidades
de seu sistema.
Modelagem de Casos deModelagem de Casos de
UsoUso
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 22/47
Notação
O diagrama de Caso de Uso é representado por:
atores;
casos de uso;
relacionamentos entre estes elementos.
Estes relacionamentos podem ser:
associações entre atores e casos de uso;
generalizações entre os atores;
generalizações, extends e includes (dependências) entre os casos de
uso.
Casos de uso podem, opcionalmente, estar envolvidos por um retângulo que
representa os limites do sistema, chamado de fronteira (fronteira do sistema).
Em maiores detalhes:
Atores
Um ator é representado por um boneco palito ( stick man ) e um rótulo com o
nome do ator. Um ator é um usuário do sistema, que pode ser humano ou
outro sistema computacional.
No exemplo, o ator é o cliente, ou seja é o cliente que realizará a interação
com os casos de uso (funcionalidades) das quais ele se relaciona (participa). 
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 23/47
#PraCegoVer: Estereótipo do ator Cliente
Caso de Uso
O caso de uso é representado pela elipse e um rótulo com o nome do caso de
uso. Um caso de uso de�ne uma grande função (tarefa, funcionalidade) do
sistema. A implicação é que uma função pode ser estruturada em outras
funções e, portanto, um caso de uso pode ser estruturado
Relacionamentos
Ajudam a descrever casos de uso e suas interações.Os relacionamentos
podem ser
Entre um ator e um caso de uso
Associação (Comunicação):
De�ne uma funcionalidade do sistema do ponto de vista do usuário e o
sentido de sua interação, quando não é indicado o sentido da interação,
signi�ca que há interação mútua.
Figura 1.2: Cliente 
Fonte: Elaborado pelo autor.
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 24/47
Figura 1.3: Associação bidirecional entre ator e caso de uso 
Fonte: Elaborado pelo autor.
#PraCegoVer: Caso de Uso comprar produtos, interação bidirecional entre o
ator cliente e o caso de uso comprar produtos.
No Exemplo, o relacionamento não indica sentido, ou seja, há interação do
ator “Cliente” com o caso de uso “Comprar Produtos” (dados de entrada), e o
caso de uso “Comprar Produtos” também interage com o ator “Cliente” (dados
de saída).
Associação mais usada entre atores e caso de uso. A interação ocorre entre
ambos, ator e caso de uso.
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 25/47
#PraCegoVer: Figura 1.4 - associação unidirecional da interação do ator
cliente para o caso de uso comprar produtos; sentido da interação ator para
caso de uso.
No Exemplo, o relacionamento indica sentido do ator “Cliente” para o caso de
uso “Comprar Produtos”. O Ator “Cliente” fornece dados de entrada, porém o
caso de uso “Comprar Produtos” não troca informações com o ator “Cliente”.
A interação ocorre do ator para o caso de uso.
Figura 1.4: associação unidirecional da interação do ator com o caso de uso 
Fonte: Elaborado pelo autor.
Figura 1.5: Associação unidirecional da interação do caso de uso com o ator 
Fonte: Elaborado pelo autor.
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 26/47
#PraCegoVer: Figura 1.5- Associação unidirecional da interação do caso de
uso comprar produtos com o ator cliente. Sentido da interação Caso de Uso
Comprar Produtos para o Ator Cliente.
No Exemplo, o relacionamento indica sentido do caso de Uso “Comprar
Produtos” para o ator “Cliente”.
O caso de uso “Comprar Produtos” fornece dados de saída respostas, ao ator
“Cliente”. A interação ocorre do Caso de Uso para o ator somente.
Generalização / Especialização
Entre atores
Os casos de uso do professor são também casos de uso do Coordenador, ou
seja todos os casos de uso que o professor interage o ator coordenador
também interage pelo relacionamento de generalização/especialização entre
atores;
O ator coordenador tem seus próprios casos de uso, são de interação
exclusiva do ator Coordenador.
Figura 1.6: Generalização/Especialização entre atores 
Fonte: Elaborado pelo autor.
#PraCegoVer: Figura 1.6 - Generalização/Especialização entre atores
Professor Ator Genérico e Coordenador Ator Especializado.
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 27/47
Entre casos de uso
a generalização relaciona casos de uso com comportamento mais genérico e
o outro mais especí�co. No exemplo, os casos de uso “vender parcelado” e
“vender a vista” são mais especí�cos que o caso de uso “vender produto”. Em
qualquer momento que “vender produto” for executado, um dos dois (“vender
parcelado” OU “vender a vista”) pode ser executado.
#PraCegoVer: Figura 1.7-Generalização/Especialização entre Casos de Uso.
Vender Produtos é o caso de uso genérico e os casos de uso Vender
parcelado e vender a vista são casos de uso especializados.
Caso de uso vender à vista ou vender parcelado é um caso de uso de vender
produto (vender produto é uma generalização de vender parcelado ou vender
a vista e são especializações de Vender Produto).
Um relacionamento entre um caso de uso genérico para um mais especí�co,
que herda todas as características de seu pai. O caso de uso genérico é um
supertipo e os casos de uso especializados são tipos do Caso de uso genérico,
pois esta razão herda as características principais
Dependências Entre Casos de Uso (<<include>>, <<extend>>)
a- <<Include>>
Figura 1.7: Generalização/Especialização entre Casos de Uso 
Fonte: Elaborado pelo autor.
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 28/47
Um relacionamento <<include>>, <<inclusão>> do caso de uso Processar
Pedido para um caso de uso Emitir Nota Fiscal indica que o caso de uso Emitir
Nota Fiscal é essencial para o comportamento de Processar Pedido. Pode ser
dito também que Emitir Nota Fiscal é parte de ( is_part_of ) Processar Pedido.
Figura 1.8: Dependência obrigatória do tipo inclusão <<include>> 
Fonte: Elaborado pelo autor.
#PraCegoVer:Figura 1.8-Ator Vendedor interage com caso de Uso Processar
pedidos, caso de uso principal. A imagem representa uma associação de
Dependência entre casos de uso obrigatória do tipo inclusão <<include>>
entre os casos de uso Processar Pedidos – caso de uso principal e o caso de
uso incluído Emitir Nota Fiscal de execução obrigatória.
Ao processar pedido é obrigatória a emissão de nota �scal.
ATENÇÃO AO SENTIDO DA SETA!!!
Quando o relacionamento de dependência do caso de uso é do tipo
<<include>> (<<inclusão>>), o sentido da seta aponta sempre para o caso de
uso incluído, de execução essencial, obrigatória. No exemplo acima o Caso de
Uso Principal é PROCESSAR PEDIDO e o Caso de Uso incluído é EMITIR NOTA
FISCAL, a seta aponta para - -> EMITIR NOTA FISCAL
Informando, por meio da notação que para todo pedido processado é
obrigatória a emissão da nota �scal.
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 29/47
b- Extend
Um relacionamento <<extend>>, <<extensão>> do caso de uso Consultar
Serasa e Solicitar Entrega para o caso de uso Processar Pedido indica que os
casos de uso Consultar Serasa e Solicitar Entrega pode ser acrescentado para
descrever o comportamento de Processar Pedido (não é essencial). A
extensão é inserida em um ponto de extensão do Processar Pedido.
#PraCegoVer: Figura 1.9 – Ator Vendedor interage com caso de uso principal
processar pedido com Associação de dependência opcional do tipo
<<extends>>, Consultar SERASA e SOLICITAR Entrega são casos de uso
estendidos do caso de uso principal Processar Pedido.
Ponto de extensão em um caso de uso é uma indicação de que outros casos
de uso poderão ser adicionados a ele. Quando o caso de uso for invocado, ele
veri�cará se suas extensões devem ou não serem invocadas (chamadas,
executadas).
Um caso de uso de extensão, é um caso de uso "opcional", em que o caso de
uso estendido pode ou não ser executado.
Quando se especi�ca B extends A, a semântica é:
Figura 1.9:  Associação de dependência opcional do tipo <<extends>> 
Fonte: O autor
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 30/47
Dois casos de uso são de�nidos: A e A é estendido por ( extended
by ) B; 
o B é uma variação de A. Contém eventos adicionais, para certas
condições; 
o B tem que ser especi�cado onde B é inserido em A.
ATENÇÃO AO SENTIDO DA SETA!!!
Quando o relacionamento de dependência do caso de uso é do tipo
<<extends>> (<<extensão>>), o sentido da seta aponta sempre para o caso de
uso principal, e não para o caso de uso estendido. No exemplo acima o Caso
de Uso Principal é PROCESSAR PEDIDO e os Casos de Uso estendidos são
SOLICITAR ENTREGA e CONSULTAR SERASA, a seta aponta para - ->
PROCESSAR PEDIDO
Informando, por meio da notação que para todo pedido processado há
escolha para solicitar entrega ou consultar o serasa ou realizar ambos.
Sistema ou Fronteira
Limites do sistema: representado por um retângulo envolvendo os
casos de uso que compõem o sistema.
Nome do sistema: Localizado dentro do retângulo.
Exemplo 01:
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 31/47
Figura 1.10: Exemplo de diagrama de caso de uso com delimitação de
fronteira - clínica médica 
Fonte: Elaborado pelo autor.
#PraCegoVer: Figura 1.10 - Exemplo de diagrama de caso de uso com
delimitação de fronteira, a fronteira é um recurso opcional no diagrama de
caso de uso que delimita o contexto e enfoque da aplicação, clínica médica. O
Diagrama de Caso de Uso tem os atores: Paciente (ator principal), Secretária,
Médico e Balconista (atores secundários). E os casos de uso principal Cancelar
Consulta, Marcar Consulta, Pedir Remédio e Pagar Conta. O Caso de Uso
Procurar registro de Paciente é caso de uso incluído dos Casos de Uso Marcar
Consulta e Pedir Remédio. O caso de uso Plano de Saúde é caso de uso
especializado de Pagar Conta.
Detalhamento de Caso de Uso - Caso de Uso
Descritivo
O Caso de uso descritivo que será utilizado como exemplo será o caso de uso
Manter Clientes (CRUD - Create, Read, Update e Delete, as quatro (4)
operações principais do bd, na mesma funcionalidade: inserção, alteração,
consulta e deleção). Inserir um novo cliente comporá o �uxo normal, e a
alteração, consulta e deleção serão opções alternativas, dependendo da regra
de negócio do BD e sistema a deleção poderá não existir sendo uma opção
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 32/47
para inativação do registro, uma alteração de status no qual o cliente não
aparecerá nas buscas ativas, mas permanece aparecendo num histórico de
registros anteriores, hoje há uma tendência a manter os dados para histórico.
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 33/47
Caso de Uso: UC02 – Manter Cliente
Objetivo: 
Este caso de uso trata da manutenção dos dados
dos clientes (inserção, alteração, consulta e
deleção)
Requisitos:
RF01 – Todo Cliente será mantido por um código
único; 
RF02 – O sistema deverá manter os dados do
cliente.
Atores: Funcionário
Prioridade: Média
Pré-condições:
O ator deve estar logado ao sistema - (UC01-
Efetuar Login)
Freqüência de
uso:
Média para alta – toda vez que surgir um cliente
ainda não cadastrado ou que necessite de
alteração este caso de uso será executado.
Criticalidade: Baixa
Condição de
Entrada:
O caso de uso inicia na interface de manutenção
de clientes.
Fluxo Principal:
01-  Funcionário insere dados do cliente (A1, A2,
A3); 
02-  Sistema valida dados do cliente (E1, E2); 
03-  Caso de Uso é encerrado.
Fluxo
Alternativo:
01 A1-   Alterar/Editar dados do cliente; 
A1.   1- Funcionário pesquisa/consulta dados do
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 34/47
cliente; 
A1.   2- Sistema exibe dados do cliente; (E2) 
A1.   3- Funcionário altera dados do cliente; 
A1.   4- Sistema valida dados; (E1) 
A1.   5- Caso de uso é encerrado. 
01   A2-  Consultar/Pesquisa dados do cliente; 
A2.  1- Funcionário pesquisa dados do cliente; 
A2.  2- Sistema busca e exibe dados do cliente; (E2)
A2.   3- Caso de uso retorna ao passo A1. 3 do
�uxo alternativo. 
01   A3-  Deletar dados do cliente; 
A3.  1- Funcionário executa o �uxo alternativo A2.
1. 
A3.  2- Funcionário con�rma exclusão do cliente; 
A3. 3- Sistema exibe msg que cliente foi excluído
com sucesso. (E3)
Fluxo de
Exceção:
02 e A1.4 - E1 Dados Inválidos 
E1.1- Sistema veri�ca dados e exibe msg que os
dados estão inválidos; 
E1.2- Caso de uso retorna ao passo 01 do Fluxo
Principal. 
02, A1.2 e A2.2 - E2 Dados do Cliente não
localizados 
E2.1- Sistema exibe msg: “Cliente não localizado”; 
E2.2- Caso de uso retorna ao passo 01 do Fluxo
Principal. 
A3.3 - E3 Há pendências que impedem a
exclusão 
E3.1 – Sistema não permite a exclusão por
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 35/47
Tabela 1.3 – Exemplo de Caso de uso detalhado : UC02 – Manter Clientes. 
Fonte:  Elaborado pelo autor.
O detalhamento de caso de uso descreve a funcionalidade passo a passo
como a descrição de um algoritmo, ao elaborar o diagrama de caso de uso o
raciocínio e o foco estão nas interações e o pensamento deve ser minimalista
quanto mais simples e objetivo melhor, já na descrição do caso de uso
detalhado, o mesmo faz jus ao nome, pois quanto mais completa, detalhada e
sem quaisquer ambiguidades melhor.
No diagrama de caso são analisadastodas as interações de um ator com
todas as funcionalidades com as quais ele interage, são analisadas as
funcionalidades e analisa-se o sistema ou módulo como um todo, desta
análise teremos cada caso de uso, em particular com seu detalhamento e
descrição passo a passo.
A descrição detalhada do caso de uso é por funcionalidade e todos os casos
de uso de um projeto terão sua descrição detalhada. O diagrama de
Atividades pode representar descrições detalhadas de caso de uso.
praticar
Vamos Praticar
detectar pendência; 
E3.2 – O caso de uso é encerrado
Pós-condições: Não se aplica - N/A
Regras de
negócio:
RN 04 – Clientes “Inativos” há cinco anos serão
excluídos automaticamente da base.
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 36/47
Considere uma clínica médica na qual os pacientes primeiramente agendam
consultas com a secretária, fornecendo suas informações pessoais. Caso o paciente
ainda não esteja cadastrado no sistema ou exista algum dado que necessite de
atualização, a secretária deverá atualizar o cadastro. Durante a consulta, o médico
pode marcar exames a serem trazidos posteriormente. a solicitação de exames e
seus resultados assim como todas as ações do paciente são registrados no histórico
do paciente. Todas as interações realizadas pela secretária também poderão ser
realizadas pelo médico. Somente o médico realiza a consulta. O médico pode
solicitar exame ou prescrever medicamento, se necessário.
Para representar as interações da Secretária e do Médico com o sistema, foi criado
o diagrama de casos de uso abaixo.
#PraCegoVer: Diagrama de Caso de Uso de um Consultório Médico para
agendamento de Consultas. Temos os Atores: Médico e Secretária. Médico é o Ator
especializado que realiza consulta e ocasionalmente pode agendar consulta.
Secretária é o Ator genérico que agenda consultas. I-Generalização/Especialização
entre atores, médico é o ator especializado e a Secretária é o ator genérico. II-
Associação de Inclusão entre os casos de Uso Agendar Consulta (Caso de Uso
Principal) e Atualizar dados dos pacientes é o caso de uso incluído. III- Associação de
Fonte: Elaborado pelo autor.
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 37/47
Inclusão entre os casos de uso Solicitar Exames - Caso de Uso Principal e Atualizar
Dados dos pacientes Caso de uso Incluído; IV- Associação de extensão entre o caso
de uso realizar consulta principal e o caso de uso estendido solicitar exames; V-
Associação de Inclusão entre os casos de uso Realizar Consulta principal e Atualizar
Dados dos Pacientes caso de uso incluído; VI- Associação de extensão entre os casos
de uso realizar consulta principal e prescrever medicamentos caso de uso
estendido; VII- Associação de Inclusão entre os casos de uso prescrever
medicamentos, caso de uso estendido que ocorrendo inclui o caso de uso atualizar
dados de Pacientes, caso de uso incluído.
As lacunas I, II, III, IV, V e VI representam relações (ou associações) entre atores e
entre casos de uso e devem ser preenchidas, respectivamente, por:
a) <<include>>, <<extend>>, generalização, associação, <<extend>>,
<<include>> e <<include>>
b) <<extend>>, <<extend>>, <<include>>, <<include>>,<<include>>,
<<extend>> e <<include>>
c) generalização/especialização, <<include>>>, <<extend>>, <<include>>,
<<include>>, <<extend>> e <<extend>>
d) generalização/especialização, <<include>>, <<include>>, <<extend>>,
<<include>>, <<extend>> e <<include >>
e) <<include>>, generalização/especialização, <<extend>>, <<extend>>,
<<include>>, <<include>> e <<extend>>
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 38/47
Um diagrama de atividade é um grá�co que descreve o �uxo das atividades a
serem desenvolvidas Ele é um diagrama do tipo comportamental importante
na UML para descrever aspectos dinâmicos do sistema. O diagrama de
atividades é essencialmente uma versão avançada do �uxograma que modela
o �uxo de uma atividade para outra.Esse tipo de diagrama serve para
descrever como as atividades são coordenadas para fornecer um serviço que
pode estar em diferentes níveis de abstração.
Diagrama de AtividadesDiagrama de Atividades
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 39/47
Normalmente, um evento a ser realizado em um projeto precisa ser
alcançado por algumas operações, particularmente onde as atividades se
destinam a alcançar várias coisas diferentes que exigem coordenação. Os
eventos em um único caso de uso se relacionam entre si, mas existem casos
particulares de casos de uso em que atividades podem se sobrepor e exigir
uma coordenação entre as atividades.
saiba mais
Saiba mais
Acesse o site da OMG.org, órgão responsável
pela regulamentação da UML e veja as
certi�cações da área:
Fonte: Elaborado pelo autor.
ACESSAR
https://www.omg.org/oceb-2/index.htm
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 40/47
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 41/47
O Diagrama de atividades tem três (3) �nalidades:
Descreve as etapas de um algoritmo como um �uxograma;
Descreve as etapas de um processo;
Descreve o detalhamento de um caso de uso (este é o objetivo).
O diagrama de atividades descreve o �uxo de processamento das ações.
praticar
Vamos Praticar
Diagramas de atividades possuem sua importância no processo de
desenvolvimento de softwares. Usado para descrever as etapas a serem seguidas
por um usuário no uso prático de um sistema, ele possui elementos visuais que
Quadro 1.4 – Símbolos utilizados no diagrama de atividades. 
Fonte: Adaptado de UML - Guia do Usuário (2006).
Figura 1.13: Diagrama de Atividades “ Manter Cliente” 
Fonte: Elaborado pelo autor.
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 42/47
descrevem cada etapa de eventos a serem realizados. Nisto, analise os elementos
do quadro a seguir e sua descrição.
Dado o quadro acima, assinale a alternativa que faz correta relação entre símbolos
e descrição.
a) I, II e III, apenas.
b) I, III e IV, apenas.
c) I, II e V, apenas.
d) II, III e IV, apenas
e) III, IV e V, apenas
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 43/47
indicações
Material
Complementar
LIVRO
Princípios De Análise E Projeto De Sistema
Com Umlx
Eduardo Bezerra
Editora: Elsevier Editora, 2014
ISBN: 8535226265, 9788535226263
Comentário: O Livro detalha o passo a passo a análise
orientada a objetos com UML, passando por cada
diagrama e suas características
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 44/47
conclusão
Conclusão
O projeto de software com UML é imprescindível para análise e
documentação de projetos Orientados a Objetos. A visão comportamental
facilita o entendimento e funcionamento do Software tanto para a equipe de
desenvolvimento quanto para o usuário.
O RUP (Rational Uni�ed Process) fornece o enredo de como deve acontecer o
projeto de modo que a cada parte do documento o projeto vai criando um
re�namento e aprimoramento técnico.
A orientação a objeto com a UML e seu conjunto de diagramas aprimoram a
análise, tendo no diagrama de caso de uso os principais agentes que
interagem entre si na aplicação, no detalhamento de caso de uso afuncionalidade é descrita passo a passo já “programando” em “linguagem
natural” a funcionalidade. O Diagrama de atividades na UML representa o
�uxo dos passos descritos no detalhamento de caso de uso e assim cada
conteúdo se complementa e integra dando sentido ao melhor entendimento.
referências
Referências
Bibliográ�cas
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 45/47
Bezerra, E. Princípio de Análise e Projetos de Sistemas com Uml , 3ª Ed.
Campus 2015
Houaiss, Antonio. Dicionário eletrônico Houaiss da Língua Portuguesa . 4ª.
ed. Rio de Janeiro: Objetiva, 2009.
IEEE. IEEE_SoftwareEngGlossary.pdf . Disponível em: <
www.mit.jyu.�/ope/kurssit/.../IEEE_SoftwareEngGlossary.pdf >. , 1990, acesso
em: 05/01/2020.
KRUCHTEN, Philippe. Introdução ao RUP – Rational Uni�ed Process . 2ª
Edição, Rio de Janeiro: Editora Ciência Moderna, 2003.
MEDEIROS, Ernani Sales de. Desenvolvendo Software com UML 2.0:
de�nitivo . São Paulo: Pearson, 2004.
PRESSMAN, Roger S.; MAXIM, Bruce. Engenharia De Software : UMA
ABORDAGEM PROFISSIONAL. 8ª ed. Porto Alegre: Mcgraw Hill - Artmed, 2016.
SOMMERVILLE, I. Engenharia de Software . 9a edição. Pearson Addison
Wesley. 2011.
http://www.mit.jyu.fi/ope/kurssit/.../IEEE_SoftwareEngGlossary.pdf
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 46/47
19/05/2022 19:48 Ead.br
https://student.ulife.com.br/ContentPlayer/Index?lc=eZAx41ya2KyTclLTbRwXLg%3d%3d&l=pRus9GoSvWp9rtEC8b6OSg%3d%3d&cd=XG7r3… 47/47