teorico_I

Prévia do material em texto

Modelagem de 
Sistemas para Internet
Responsável pelo Conteúdo:
Prof. Dr. Cleber Silva Ferreira da Luz
Revisão Textual:
Aline Gonçalves
Introdução e Estudo de Caso 
Introdução e Estudo de Caso 
 
 
• Apresentar um estudo de caso sobre o desenvolvimento web.
OBJETIVO DE APRENDIZADO 
• Introdução;
• UML;
• Conclusão e Resumo da Unidade.
UNIDADE Introdução e Estudo de Caso 
Introdução
Sistemas web, também chamados de aplicações web ou, ainda, web apps, são softwares 
com base na arquitetura cliente-servidor, que utilizam a internet como plataforma de traba-
lho e processamento. Aplicações web possuem como características fundamentais interação 
em tempo real com o usuário e flexibilidade, alta disponibilidade, alta performance, perso-
nalidade e a utilização de um browser (navegador) para oferecer serviços.
O processo de desenvolvimento de aplicações web requer características e métodos 
diferentes do processo de desenvolvimento de software tradicional. Todavia, alguns ar-
tefatos são semelhantes entre os dois processos, tais como:
• Análise de requisito;
• Identificação das funcionalidades (casos de uso, histórias de usuários etc.);
• Modelagem conceitual (modelo de classes de negócio);
• Testes (cenários de testes para cada funcionalidade). 
Assim, antes de começarmos, de fato, a estudar os recursos, métodos e todos os arte-
fatos sobre a modelagem de sistemas web, faz-se necessário o estudo de alguns assuntos 
sobre a engenharia de software tradicional. Vamos começar com a UML. O próximo 
tópico a apresenta com detalhes. 
UML 
Na engenharia de software, a UML possui papel fundamental na especificação, cons-
trução e documentação do software, isto é, a UML é uma linguagem de modelagem que 
permite representar sistemas de forma padronizada. A Linguagem Modeladora Unificada é 
uma linguagem padrão utilizada para a estrutura de projetos de software. A UML é com-
posta por diversos artefatos que permitem especificar desde funções básicas do sistema até 
funções mais complexas. É importante ressaltar que a UML não é uma metodologia de 
desenvolvimento. Metodologias de desenvolvimento se caracterizam, principalmente, por 
fornecer uma forma de como desenvolver. Já a UML permite mostrar como os módulos do 
sistema se relacionam entrem si e entre os usuários do sistema. É possível concluir, então, 
que a UML permite esboçar o comportamento e, principalmente, a estrutura do sistema. 
De forma resumida, a utilização da UML permite modelar o sistema para que a sua 
compreensão, seu desenvolvimento e sua implantação sejam realizados da melhor forma 
possível. Assim, a UML é uma linguagem modeladora unificada muito expressiva, isto é, 
abrange todas as visões necessárias ao desenvolvimento, teste e à implantação dos sistemas. 
A UML é repleta de diagramas que possibilitam modelar o sistema da forma mais 
adequada. Nesta unidade, estudaremos os seguintes diagramas: 
• Diagrama de Caso de Uso; 
• Diagrama de Classes; 
• Diagrama de Estados;
• Diagrama de Atividade. 
8
9
Para apresentar tais diagramas, vamos considerar o projeto a seguir. Esse projeto será 
utilizado como estudo de caso, a fim de apresentar os diagramas como forma prática.
A empresa Shut Show é tradicional no ramo de varejo de calçados. Shut Show atua em 
vários estados brasileiros, tais como São Paulo, Rio de Janeiro, Minas Gerais, entre outros. 
A Shut Show contratou a empresa Web Dev para criar um sistema de vendas on-line. Um 
analista de requisitos da Web Dev foi até a Shut Show para levantar os requisitos e, futura-
mente, apresentar um projeto para a Shut Show. A análise realizada pelo analista apresenta 
uma descrição sucinta do sistema, tal descrição é apresentada a seguir:
O cliente pode navegar pelo site e escolher um ou mais calçados à mostra no catálogo. 
Após escolher o calçado, o usuário deve adicionar o item ao seu carrinho de compra. Quan-
do o cliente desejar pagar, o sistema deve solicitar um cadastro ao usuário. No cadastro, de-
vem ser solicitados todos os dados do cliente, incluído o endereço residencial e o endereço de 
entrega padrão. Caso o usuário já seja cadastrado, pode fazer login no site. E o sistema deve 
direcionar o cliente para a tela de pagamento. Na tela de pagamento, o usuário deve escolher 
a forma de pagamento: débito ou crédito. Após inserir os dados do pagamento, o cliente 
deve clicar no botão “finalizar” e o sistema deve verificar se a compra foi aprovada ou não. 
O analisa levantou os seguintes requisitos funcionais:
Quadro 1
1 O sistema deve permitir que o usuário escolha um ou mais calçados entre os diversos que são apresentados no catálogo.
2 O sistema deve permitir acrescer itens no carrinho de compra do usuário.
3 O sistema deve permitir excluir itens do carrinho de compra do usuário.
4 O sistema deve permitir que o usuário faça o login.
5 O sistema deve permitir que o usuário faça o seu cadastro.
6 O sistema deve permitir que o usuário escolha a forma de pagamento (débito ou crédito).
A seguir, são apresentados os requisitos não funcionais levantados pelo analista.
Quadro 2
1 O sistema deve possuir uma interface de fácil entendimento, porém sofisticada.
2 O sistema deve verificar, junto com a administradora do cartão, se o pagamento é aprovado ou não.
3 O sistema deve apresentar todas as informações do faturamento da compra, isto é, o valor total ou parcelado, juros ou descontos.
Com uma visão geral do projeto-exemplo, vamos apresentar os diagramas da UML. 
A próxima seção apresenta os principais diagramas da UML considerando, em cada 
diagrama, o projeto-exemplo.
9
UNIDADE Introdução e Estudo de Caso 
Diagrama de Caso de Uso
Antes de entrarmos diretamente em caso de uso, devemos entender o que é um cenário. 
Cenário é uma forma de descrever uma interação entre o usuário e o sistema. Um cenário 
encontrado em nosso projeto-exemplo pode ser: o cliente entra no site, escolhe um calçado, 
adiciona ao carrinho, coloca os dados de pagamento e finaliza a compra. É importante res-
saltar que, para esse cenário, podem acontecer alternativas, por exemplo, se o pagamento 
não for aprovado pela administradora, deve-se solicitar um novo método de pagamento, 
que, no caso, já seria um novo cenário.
Caso de Uso é um conjunto de cenários amarrados por um objetivo comum de um 
usuário (FOWLER, 2011). Os casos de uso visam modelar o comportamento do sistema. 
Um caso de uso pode apresentar um ou mais atores. Um ator é o papel que um usuário 
desempenha em relação ao sistema. 
Para exemplificar o Diagrama de Caso de Uso, vamos considerar um cenário bem 
simples. Considerando o nosso projeto-exemplo, poderíamos ter um cenário no qual o 
cliente pode realizar o cadastro no site, alterar, excluir e consultar o cadastro. A Figura 1 
apresenta um caso de uso para o que chamamos de CRUD (Consult, Register, Update e 
Delete) do cliente. 
Cadastrar
Alterar Cadastro
Excluir Cadastro
Consultar CadastroCliente
Figura 1 – Diagrama de Caso de Uso para um CRUD Cliente
No Diagrama de Caso de Uso, um ator é representado por um boneco. As ações 
(casos de uso) dos autores, isto é, “o que o ator pode realizar”, são representadas por 
elipses. Um ator é o papel que um usuário pode desempenhar em relação ao sistema. 
Todavia, quando você lida com atores, é importante pensar nos papéis em vez de pensar 
nas pessoas ou em cargos. Os atores executam os casos de uso. Um único caso de uso 
pode ter vários atores executando-o. 
É importante observar que, no Diagrama de Caso de Uso, mesmo sendo represen-
tados por bonecos, os atores não precisam ser humanos, um ator pode ser um sistema 
externo que necessita informações do sistema modelado.
Agora que o básico sobre Diagrama de Caso de Uso foi explicado, vamos para um 
exemplo um pouco mais sofisticado. Considerando novamente o nosso projeto, tería-
mos um caso de uso com dois cenários possíveis, um de compra bem sucessiva e outro 
de falha na autorização do cartão. Habitualmente, um caso de uso possui caso comum,no qual tudo dá certo, e muitas alternativas que podem incluir situações inesperadas, er-
ros ou, ainda, outras situações as quais podem ser consideradas como certas. Segundo 
Fowler (2011), uma forma simples de capturar um caso de uso consiste na descrição de 
seu cenário primário como uma sequência de passos numerados e as alternativas como 
variações naquela sequência. Vamos descrever o cenário do caso de uso de “compra de 
um calçado” do nosso projeto-exemplo.
10
11
Compra de Calçado 
1. O cliente navega pelo site, seleciona um calçado e o calçado é adicionado 
ao carrinho;
2. O cliente realiza o login no site; 
3. O cliente preenche os dados do pagamento;
4. O sistema de cartão autoriza o pagamento;
5. O sistema avisa o usuário sobre o sucesso da compra.
• Alternativa 1: Falha na autorização: no item 5, o sistema não autoriza o pagamento, 
o sistema deve permitir que o cliente submeta outro cartão ou mude a forma 
de pagamento. 
• Alternativa 2: Cliente não cadastrado previamente: no item 2, o cliente pode não 
estar cadastrado ainda no site, assim, o sistema deve permitir que se cadastre para 
continuar a compra. 
A seguir, é apresentado um Diagrama de Caso de Uso considerando um cenário 
positivo para o cenário de compra de calçado. 
Cliente Sistema de cartão
Navegar pelo catálogo
Escolher o calçado
Adicionar item ao carrinho
Login no site
<<include>>
<<include>>
Autorizar o pagamento<<include>>Efetuar o pagamento
Figura 2 – Diagrama de Caso de Uso 
O Diagrama de Caso de Uso apresentado na Figura 2 possui dois autores. o cliente 
e o sistema de cartão, que é um sistema externo. Devemos observar, além das ligações 
entre autores e caso de uso, que é possível demonstrar tipos de associações entre caso 
de uso. Existem três tipos de associações entre caso de uso:
• Inclusão (include);
• Generalização;
• Extensão.
No diagrama apresentado na Figura 2, é usada uma associação do tipo inclusão. Se-
gundo Fowler (2011), uma associação do tipo inclusão ocorre quando há uma parte do 
comportamento que é semelhante em mais de um caso de uso. Já uma generalização 
ocorre quando casos de uso são semelhantes. A extensão é usada quando você estiver 
descrevendo uma variação em comportamento normal e deseja utilizar de forma mais 
controlada, explicando os pontos de extensão no caso de uso-base. 
Além do Diagrama de Caso de Uso, o Diagrama de Classe é muito importante na 
UML. A próxima seção apresenta mais detalhes sobre o Diagrama de Classe. 
11
UNIDADE Introdução e Estudo de Caso 
Diagrama de Classe
Segundo Fowler (2011), um Diagrama de Classe é utilizado para descrever os tipos de 
objetos no sistema e os vários tipos de relacionamento estático que existem entre eles. 
Em outras palavras, um Diagrama de classe descreve o que deve estar no sistema que 
estamos modelando. Ele permite expor quais classes o sistema terá e quais são os seus 
relacionamentos. Há, basicamente, dois tipos de relacionamentos estáticos:
• Associações: Por exemplo, um cliente pode possuir mais de uma conta bancária; 
• Subtipos: Por exemplo, dada uma Classe Pessoa, um professor pode ser uma ins-
tância desta classe. 
Um Diagrama de Classe também mostra os atributos e as operações (métodos) de 
uma classe, e restrições às maneiras como os objetos são conectados. Um Diagrama de 
Classe expressa as classes do sistema modelado. Assim, antes de entramos a fundo em 
tal diagrama, vale a pena relembramos o que é classe, atributos e métodos. A seguir, são 
apresentados de forma sucinta tais assuntos. 
• Classe: uma classe pode ser compreendida como representação de um item do 
mundo real, físico ou abstrato que desejamos modelar no sistema. Uma classe defi-
ne o comportamento de um objeto, que é uma instância de uma classe.
Uma classe é formada por atributos e métodos. Um atributo pode ser considerado 
como informações, características ou propriedades de uma classe. Atributos são usados 
para armazenar informações ou dados da classe. Já métodos diz quais ações ou funções 
uma classe pode realizar. Um simples exemplo: considere a classe Cliente; ela possui 
como atributos: nome, CPF, RG, idade, cor, peso, endereço, entre outros. Já os métodos 
dos clientes podem ser comprar, pagar, escolher etc. 
Para exemplificar esse diagrama, vamos considerar o nosso projeto-exemplo. Nesse 
projeto, podemos ter várias classes. Aqui, como forma de simplificar e didática, vamos 
abordar somente as classes Cliente(), ClientePessoaFisica(), ClientePessoaJuridica(), Pe-
dido() e Produto. A Figura 3 apresenta o Diagrama de Classe considerando essas classes. 
Cliente
1 * 1 *
ClientePessoaFisica ClientePessoaJuridica
Pedido Produto
+ expedir(): void
+ encerrar(): void
+ imprimirDados(): void + buscarProduto(): void
- email: String
- senha: String
- endereco: String
- nome: String
- RG: String
- CPF: String
+ getNome(): String
+ getRG(): String
+ getCPF(): String
+ getRazaoSocial(): String
+ getCNPJ(): String
- razaoSocial: String
- CNPJ: String
- valor: double
- numeroDoCalcado: int
- marca: String
- numero: int
- valorTotal: double
- qtdItem: int
Figura 3 – Diagrama de Classe
É importante ressaltar que, para fins didáticos, o Diagrama de classe, trazido acima, 
contém poucas classes e não contém todos os métodos e atributos que um projeto real 
deve ter. O intuito desse material é apresentar de forma prática e simples os diagramas 
da UML, considerando um projeto-exemplo. Dito isso, podemos apresentar mais deta-
lhes sobre o Diagrama de Classe. 
12
13
No Diagrama de Classe, uma classe é representada por um retângulo dividido em 
três partes. A primeira parte é dedicada ao nome da classe. Já a segunda parte é uti-
lizada para especificar os atributos da classe. A terceira parte é utilizada para descrever 
os métodos da classe. No Diagrama de Classe, os atributos devem ser especificados por 
nome, seguido de “:” e o seu tipo de dado. 
Os métodos, além de serem especificados na terceira parte, devem conter o nome do 
método, parâmetros seguidos de “:” e o tipo de retorno do método. Agora, tanto para 
método quanto para atributos, devemos especificar suas visibilidades também. Seguindo 
a seguinte regra: “+” para métodos ou atributos públicos; “–” para privados; “#” para 
protegido; “~” para pacotes, “/” para derivados. 
No diagrama de Classe, é possível representar uma herança. No Diagrama de Classe 
apresentado anteriormente, a herança é vista a partir das classes Cliente(), ClientePes-
soaFisica(), ClientePessoaJuridica(). A classe Cliente() é a classe-mãe e as classes Clien-
tePessoaFisica() e ClientePessoaJuridica() são as classes filhas que receberão a herança. 
A herança é um tipo de relacionamento de subtipos. 
O Diagrama de Classe possui cardinalidades, que são mecanismos utilizados para 
expressar o relacionamento das classes, isto é, quantas ocorrências de uma classe que 
se relaciona com a outra classe. No Diagrama de Classe apresentado aqui, podemos 
interpretar as cardinalidades como: um cliente pode realizar muitos pedidos, em contra-
partida, um pedido deve pertencer a um cliente. Também podemos realizar a seguinte 
leitura, um pedido pode conter vários produtos, já um produto deve pertencer a um 
pedido. A cardinalidade é um tipo de relacionamento associativo. 
Para finalizar o estudo sobre Diagramas de Classes, devemos ter em mente que o 
diagrama de Classe é um diagrama que permite visualizar o sistema de forma estática. 
O próximo diagrama que estudaremos é um que possui visão dinâmica do sistema. 
Diagrama de Estados
Entre os diversos diagramas da UML encontra-se o Diagrama de Estados. Esse dia-
grama é utilizado para descrever o comportamento de um sistema. Diagrama de Estados 
descreve todos os estados possíveis em que um objeto particular pode estar e como o 
estado do objeto muda como resultado de evento que o atinge. 
Diagramas de Estados são projetados para uma classe única, a fim de mostrar o com-
portamento ao longo do tempo de vidade um único objeto. É importante ressaltar que 
existem várias formas de Diagrama de Estados, cada uma com uma pequena diferença 
semântica. Na UML, o Diagrama de Estado tem base no statechart de David Harel.
Em palavras mais simples, o Diagrama de Estados permite modelar os diversos estados 
de um objeto durante o seu ciclo de vida. Assim, podemos modelar os vários estados que 
o sistema pode assumir durante a sua funcionalidade. 
Para exemplificar um Diagrama de Estados. Vamos considerar mais uma vez o nosso 
projeto-exemplo, o sistema de calçado on-line. Vamos, agora, modelar a situação de 
venda do calçado. 
13
UNIDADE Introdução e Estudo de Caso 
No Diagrama apresentado a seguir, é possível ver todos os estados pelos quais o siste-
ma vai passar caso ocorra uma venda. É importante observar que, com essas transições 
de estados, é possível saber como uma classe irá se comportar, ou até mesmo quais os 
valores que um atributo irá receber. 
Início
Esperando venda
Estados
Eventos
Incluir item
Incluir item
Finalizar venda
Escolhendo forma de pagamento
Escolher forma de pagamento
Débito
Efetuar o pagamento
Esperando o pagamentoFechar compra
Fim
Crédito
Incluindo itens
Figura 4 – Diagrama de Estado
Todo Diagrama de Estado deve ter início e fim. No diagrama, o início e o fim são repre-
sentados por círculos, sendo o fim representado por um círculo diferenciado. Os estados 
são representados por retângulos. Os eventos, também chamados de ações, são repre-
sentados por setas, quando um evento é disparado, o sistema assume um novo estado. 
Vale ressaltar que, quando um Diagrama de Estados é finalizado, devemos verificar 
se ele é consistente e se todos os objetivos foram atingidos. É necessário verificar se 
todos os estados podem ser atingidos, se todos os estados que o sistema pode assumir 
foram definidos e, ainda, se cada estado reage adequadamente a todos os eventos, isso 
é, não pode haver ambiguidade nas transições. 
Para finalizar o estudo sobre o Diagrama de Estados, vamos realizar uma compara-
ção do Diagrama de Estados com o Diagrama de Caso de Uso. O Diagrama de Caso 
de Uso, geralmente, é utilizado durante a etapa de análise do sistema. Já o Diagrama 
de Estado é utilizado na etapa de projeção do sistema. Vale ressaltar que Diagramas de 
Casos de Uso são muito mais gerais que os Diagramas de Estados, em muitos casos, en-
globando diversos objetos para executar uma tarefa. Já o foco do Diagrama de Estados 
é identificar os valores que os atributos de uma classe podem assumir, assim como os 
eventos ou as mensagens enviadas a tal objeto irão afetar tal valor. 
Assim como os Diagramas de Estados e de Caso de Uso, o Diagrama de Atividade 
é presente na UML e muito utilizado no mercado. O próximo tópico apresenta com 
detalhe o Diagrama de Atividades. 
Diagrama de Atividade
Nessa ação, vamos falar de mais um diagrama da UML, o Diagrama de Atividade. 
Na UML, o Diagrama de Atividade é utilizado para descrever a sequência de atividades do 
14
15
projeto (FOWLER, 2011). Um Diagrama de Atividade pode ser considerado uma variação 
do Diagrama de Estados no qual a maioria, se não todos, os estados são atividades. Um 
Diagrama de Atividade é um importante mecanismo na conexão com workflow e na des-
crição de comportamento que tem muito processamento em paralelo. 
Nesse diagrama, é importante esclarecer o que é uma atividade. Uma atividade é um 
estado de estar fazendo algo, tanto um processo de mundo real, tal como escrever um 
e-mail, quanto um método de uma classe. É importante, também, entendemos o que é um 
Comportamento Condicional. Segundo Fowler (2011), um comportamento condicional é 
delineado por desvios (branches) e intercalações (merges). Um desvio (branch) pode ser 
considerado como uma transição de entrada única e várias transições de saída guardadas. 
Em palavras mais simples, pode falar que um Diagrama de Atividade é simplesmente 
um fluxo gráfico que mostra todo o fluxo de controle de uma atividade para outra e 
serão empregados para fazer a modelagem do sistema de forma dinâmica. É possível 
afirmar que o Diagrama de Atividade mostra o fluxo de controle de uma atividade para a 
outra. Diagrama de Atividade é um dos principais diagramas da UML, além de mostrar 
aspectos dinâmicos dos sistemas, Diagramas de Atividade são importantes, também, 
para construção de sistemas por meio de engenharia de produção reversa.
A seguir, apresentaremos elementos básicos de um Diagrama de Atividade. Todo 
Diagrama de Atividade deve ter um começo e um fim que são representados por círculo; 
o fim é representado por um círculo diferenciado. As atividades são representadas por 
retângulos e em cada retângulo é realizada uma ação (atividade). Já os losangos repre-
sentam uma decisão.
Agora, considerando o nosso projeto-exemplo, a Figura 1 apresenta um Diagrama 
de Atividade para um pedido recebido, isso é, como o sistema vai se comportar quando 
receber um pedido, quais são as atividades (tarefas) que ele irá realizar. 
Atividades
Início
Separação
Preencher
o pedido Desvio
NãoSim
Pedido é urgente?
Intercalação
Junção
Fechar o
pedido
Fim
Receber o pedido
Enviar a Fatura
Receber o
pagamentoEntrega
padrão
Entrega
rápida
Figura 5 – Diagrama de Atividade: Recebendo um pedido
Fonte: Adaptada de FOWLER, 2011
15
UNIDADE Introdução e Estudo de Caso 
Como mencionado, todo Diagrama de Atividade permite expressar o comporta-
mento dinamicamente e os diversos fluxos que esse comportamento pode assumir. No 
diagrama anterior, é expresso um pedido de compra de calçado. O fluxo do diagrama 
começa ao receber o pedido. O próximo passo é ir para “Separação”. Uma Separação 
(Fork) tem uma transição de entrada e várias transições de saída. Quando uma transição 
de entrada é acionada, todas as transições de saída são executadas em paralelo. Assim, 
no nosso diagrama, após a “separação” ser acionada, ocorrerão duas atividades em 
paralelo: “preencher o pedido” e “enviar fatura”. 
O diagrama anterior apresenta um comportamento condicional. Depois que um pe-
dido é preenchido, há um desvio, isso é, dependendo da situação, é possível o fluxo 
da atividade tomar caminhos diferentes. A questão a ser respondida é: “o pedido é 
urgente”, se for urgente é realizada uma entrega rápida, caso contrário, é realizada uma 
entrega padrão. É importante ressaltar que o sistema pode realizar qualquer uma das 
duas tarefas, “entrega rápida” ou “entrega padrão”. No diagrama, há uma seta saindo 
da atividade “entrega rápida” e outra saindo de “entrega padrão” e conectando a um 
“intercalador”. Um intercalador (merge) possui múltiplas transições de entrada e única 
saída. Um “intercalador” marca o final de um comportamento condicional. 
Conclusão e Resumo da Unidade
Diagramas da UML expõem visões estáticas e visões dinâmicas do sistema, ou seja, 
há diagramas que permitem modelar o sistema a partir de uma visão estática (estrutura 
do sistema), como também há diagramas que permitem modelar comportamentos do 
sistema, como o sistema irá se comportar com determinado fato ou evento. Nesta uni-
dade, aprendemos sobre os diagramas estáticos e dinâmicos por meio de um projeto-
-exemplo, o qual pudemos modelar utilizando os diagramas das UML. Como conclusão 
de estudo, podemos observar que tais diagramas são importantes para o desenvolvi-
mento de sistemas web; sem eles, o desenvolvimento seria complexo, fraco, inseguro, 
ineficiente, entre outros aspectos negativos. É importante afirmar que não é porque 
modelamos o sistema usando os diagramas da UML que o sistema será totalmente 
confiável, todavia, com o uso desses diagramas, é possível obter um respaldo maior no 
desenvolvimento do sistema. Para finalizar o estudo desta unidade, será apresentado um 
resumo dos principais tópicos vistos. 
O primeiro tópico abordado nesta unidade foi sobre UML. A UML (Unified Modeling 
Language) é uma linguagem para a elaboração de projetos de sistemas. É linguagem 
padrão usada para modelar softwares e reúneum conjunto de diagramas que permite 
modelagem de sistema objetivando a construção de um software com qualidade. 
Diagrama de Caso de Uso foi o primeiro diagrama da UML que estudamos nesta 
unidade. Diagrama de Caso de Uso permite descrever as funcionalidades propostas no 
novo sistema. Tal diagrama documenta o sistema pela visão do usuário. O principal 
objetivo desse diagrama é descrever as principais funcionalidades do sistema e as suas 
interações com o usuário. 
16
17
O Diagrama de Classe, também apresentado nesta unidade, é um dos principais 
diagramas da UML. Tal diagrama permite descrever o que deve estar presente no siste-
ma, isso é, quais são classes, métodos, atributos e como as classes devem se relacionar. 
Nesta unidade, falamos também sobre Diagrama de Estados. Tal diagrama permite 
modelar os diversos estados de um objeto durante o seu ciclo de vida. A principal van-
tagem do Diagrama de Estados é expor uma maneira eficiente e clara de se descrever 
todos os possíveis estados de um sistema, assim como quais eventos levam à transição 
de um estado para outro, o que fere a mudança de um estado para o outro. 
Diagrama de Atividade foi o último diagrama apresentado nesta unidade, todavia, 
é um dos principais diagramas da UML. Diagrama de Atividade é uma variante do Dia-
grama de Estados, no qual praticamente todos os estados são atividades. O Diagrama 
de Atividade permite expressar aspectos dinâmicos do sistema. Em suma, o Diagrama 
de Atividade permite expressar o passo a passo de uma atividade, um método, uma 
funcionalidade do sistema que será representada por fluxos de controle. 
17
UNIDADE Introdução e Estudo de Caso 
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Vídeos
Introdução a UML, Conheça a História e Saiba o que é? E Por que usar UML?
Nesse vídeo, o aluno pode aprofundar o conhecimento nos principais diagramas da 
UML e expandir o conhecimento sobre a UML. 
https://youtu.be/IlpdtMcLZ7A
 Leitura
Modelagem incremental de aplicações web com abordagem UWE: um sistema para 
registro de publicações acadêmicas 
Neste artigo, é possível aprendermos um pouco mais sobre a engenharia web com 
base na UML. O objetivo central desse artigo é apresentar uma abordagem incre-
mental para aplicações web, assim, podemos aprender um pouco mais sobre a 
filosofia de desenvolvimento web utilizando uma abordagem incremental.
https://bit.ly/3g1Js9p
Modelagem de uma aplicação web a partir de um framework de Agenda de Tarefas 
Esse artigo retrata uma modelagem para aplicações web utilizando um framework 
de agenda de tarefas. Com o estudo desse artigo, você consegue ver na prática 
como a modelagem web é aplicada. 
https://bit.ly/3247GI6
Engenharia de software para web 
Nesse manual técnico, o aluno pode expandir os conhecimentos sobre a engenha-
ria de software para a web. 
https://bit.ly/3sd4Uef
18
19
Referências
COSTANTIN, C.; RODRIGUES, C. A.; MALANOVICZ, A. V. Modelagem incremen-
tal de aplicações web com abordagem UWE: um sistema para registro de publica-
ções acadêmicas. Simpósio de engenharia de produção, 2014, Brasil. Disponível em: 
<https://rl.art.br/arquivos/5054906.pdf?1417440407>. Data de acesso: 31/05/2020.
FOWLER, M. UML essencial: um breve guia para linguagem padrão. 3. ed. Porto Alegre: 
Bookman, 2011. (E-book).
MACHADO, R. P. Desenvolvimento de software: programação de sistemas web 
orientada a objetos em Java. Porto Alegre: Bookman, 2016. v. 3. (e-book)
MEDEIROS, E. Desenvolvendo software com UML 2.0 - definitivo. São Paulo: 
Pearson, 2006. (E-book).
19