PRÁTICAS DE ENGENHARIA DE SOFTWARE

Prévia do material em texto

07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&PA… 1/44
PRÁTICAS DE ENGENHARIA DE SOFTWAREPRÁTICAS DE ENGENHARIA DE SOFTWARE
PROJETO DE SOFTWARE COM UMLPROJETO DE SOFTWARE COM UML
– INTRODUÇÃO, CONCEITOS E– INTRODUÇÃO, CONCEITOS E
VISÃO COMPORTAMENTALVISÃO COMPORTAMENTAL
Autor: Esp. E laine Barbosa de Figueiredo
IN IC IAR
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&PA… 2/44
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.
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&PA… 3/44
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 Software Orientado aProjeto de Software Orientado a
Objetos com UMLObjetos com UML
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&PA… 4/44
#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.
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;
Figura 1.1 - Fases e Disciplinas do RUP
Fonte: Adaptado de Krutchten (200)
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&PA… 5/44
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.
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:
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&PA… 6/44
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.
Teste
O 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
Projetos
Este work�ow de apoio gerencia o
desenvolvimento do sistema.
Ambiente
Este work�ow está relacionado à disponibilização
de ferramentas apropriadas de software para a
equipe de desenvolvimento.
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&PA… 7/44
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
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
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&PA… 8/44
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 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;
Requisitos de SoftwareRequisitos de Software
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&PA… 9/44
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);
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.
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 10/44
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.
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:
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 11/44
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;
RNF 06 – Os usuários do sistema
receberão treinamento de 40 horas para
os principais módulosdo sistema.
RNF 07 – O sistema terá telas de ajuda
para todas as funcionalidades, e em todas
as interfaces;
CONFIABILIDADE ●   Tempo médio de falhas;
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 12/44
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
●   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
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)
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 13/44
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.
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.
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 14/44
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;
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)
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 15/44
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 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ês subsequente, 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.
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 16/44
Sobre requisitos funcionais deste sistema, está correto o que se a�rma em:
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.
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 17/44
A modelagem de caso de usocomplementa 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.
Notação
O diagrama de Caso de Uso é representado por:
atores;
Modelagem de Casos de UsoModelagem de Casos de Uso
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 18/44
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).
#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
Figura 1.2: Cliente
Fonte: Elaborado pelo autor.
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 19/44
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.
#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.
Figura 1.3: Associação bidirecional entre ator e caso de uso
Fonte: Elaborado pelo autor.
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 20/44
#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.
#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”.
Figura 1.5: Associação unidirecional da interação do caso de uso com o ator
Fonte: Elaborado pelo autor.
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 21/44
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.
#PraCegoVer: Figura 1.6 - Generalização/Especialização entre atores Professor Ator
Genérico e Coordenador Ator Especializado.
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.
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 22/44
#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>>
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.7: Generalização/Especialização entre Casos de Uso
Fonte: Elaborado pelo autor.
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 23/44
#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.
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 acrescentadopara descrever o
comportamento de Processar Pedido (não é essencial). A extensão é inserida em um
ponto de extensão do Processar Pedido.
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 24/44
#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 é:
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.
Figura 1.9:  Associação de dependência opcional do tipo <<extends>>
Fonte: O autor
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 25/44
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:
#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
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 26/44
existir sendo uma opção 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.
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 27/44
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 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)
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 28/44
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.
   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 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.
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 29/44
No diagrama de caso são analisadas todas 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
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 solicitarexame 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.
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 30/44
#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 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>>
Fonte: Elaborado pelo autor.
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 31/44
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>>
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 32/44
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
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
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 33/44
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.
O Diagrama de atividades tem três (3) �nalidades:
Descreve as etapas de um algoritmo como um �uxograma;
Descreve as etapas de um processo;
Quadro 1.4 – Símbolos utilizados no diagrama de atividades.
Fonte: Adaptado de UML - Guia do Usuário (2006).
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 34/44
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 descrevem cada etapa de eventos a serem
realizados. Nisto, analise os elementos do quadro a seguir e sua descrição.
Figura 1.13: Diagrama de Atividades “ Manter Cliente”
Fonte: Elaborado pelo autor.
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 35/44
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
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 36/44
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
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 37/44
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 a funcionalidade é 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
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.
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 38/44
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
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 39/44
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P…40/44
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 41/44
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 42/44
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 43/44
07/10/2021 13:59 Ead.br
https://fmu.blackboard.com/webapps/late-course_content_soap-BBLEARN/Controller?ACTION=OPEN_PLAYER&COURSE_ID=_738352_1&P… 44/44