Aula 10 Modelagem de Sistemas

Prévia do material em texto

- -1
MODELAGEM DE SISTEMAS
PRÁTICA DOS MODELOS (UML) E 
ABORDAGEM EM CAMADAS
- -2
Olá!
Essa é a nossa última aula desta disciplina, e nela daremos continuidade ao pequeno projeto iniciado na aula 6,
com base no estudo de casos proposto.
Vamos elaborar um diagrama de estados para as classes pertinentes, diagrama de atividades para determinados
casos de uso ou até mesmo métodos de classes que exijam complexidade algorítmica (iremos analisar), diagrama
de classes de projeto, diagrama de componentes e finalmente, diagrama de implantação.
Bons estudos!
Objetivos
1. Definir a forma de aplicar a linguagem UML, com base em um estudo de caso;
2. Aplicar, com um estudo de caso, a construção dos diagramas de estados, de atividades, de componentes e de
implantação;
3. Reconhecer na prática a relação entre os diagramas e a necessidade de mantê-los atualizados durante o
desenvolvimento do software.
Minimundo do Estudo de Caso
Vamos iniciar esta aula realizando um estudo de caso. Observe:
- -3
Esta é a gráfica . que confecciona faixas de anúncios ou outras finalidades por encomenda. Faixa Amarela Ltda
Este é o proprietário da gráfica de faixas, seu Pereira.
Como os pedidos vêm crescendo, ele encomendou um sistema que controle suas atividades.
Solução ao projeto
Para desenvolver o sistema solicitado pelo seu Pereira, proprietário da gráfica Faixa Amarela, seguiremos o
seguinte procedimento para modelagem da continuidade dos diagramas da UML:
1 Diagrama de estados, identificando as classes que têm necessidade desse diagrama;
2 Derivação do diagrama conceitual de classes, com base no diagrama conceitual de classes;
3 Construção do diagrama de atividades para casos de uso complexos e/ou identificar a necessidade de diagrama
de atividades para métodos de classes com algoritmos complexos;
4 Construção do diagrama de componentes;
5 Construção do diagrama de implantação.
Diagrama de Estados
- -4
O primeiro passo é analisar o diagrama conceitual de classes e identificar as que terão mais de um estado
durante o ciclo de vida do sistema:
Conclusão do diagrama de Estados
Com base no diagrama que vimos anteriormente, podemos concluir que apenas teremos diagramas de estados
para a classe PEDIDOS, que através do atributo STATUS armazenará os diferentes estados que poderão assumir
os objetos da classe PEDIDO, durante o ciclo de vida do sistema. Observe que o próprio enunciado já nos informa
os estados de PEDIDO, neste trecho extraído do enunciado:
O pedido, ao longo do seu ciclo de vida, pode ter vários estados, e o sistema deve controlar os eventos que geram
mudança de estado.
• Ao ser inserido, o status é EM ESPERA;
• Assim que o sinal for pago, o status passa a ser PRONTO PARA PRODUÇÃO;
• Quando o responsável técnico da fábrica inicia a produção da faixa, o status passa a ser EM PRODUÇÃO;
• Ao ser finalizado, o status passa a ser PRONTO;
• Ao ser entregue, o status passa a ser ENTREGUE. Para ser considerado ENTREGUE, o pedido tem que ter 
•
•
•
•
•
- -5
• Ao ser entregue, o status passa a ser ENTREGUE. Para ser considerado ENTREGUE, o pedido tem que ter 
o saldo de pagamento confirmado.
Os possíveis estados da classe Pedido podem ser vistos na tabela a seguir:
Diagrama de Atividades
Para compreender como usar o diagrama de atividade, vamos modelar três casos de uso. Mas antes, saiba que
esse diagrama , na medida em que permite que modelemos amplia a visão das especificações de casos de uso
também (em conjunto) os cenários alternativos.
Os casos de uso que terão as suas especificações complementadas pelos respectivos diagramas de atividades são: 
Registrar Pedido, Incluir Cliente, Cadastrar Cliente e Confirmar Recebimento de Sinal.
Caso de Uso Registrar Pedido
•
Fique ligado
O uso oportuno do diagrama de atividades é para casos de uso cuja especificação é complexa e
/ou extensa. Tais propriedades não se aplicam em nossos casos de uso, devido à simplicidade
do estudo de caso. Nossa intenção não é explorar as propriedades superlativas da UML e seus
diagramas, e sim mostrar como aplicá-los.
- -6
Subatividade INCLUIR CLIENTE
O mais interessante desta modelagem de subatividade para INCLUIR CLIENTE é que ela será aproveitada
também no diagrama
Subatividade CADASTAR CLIENTE
Comentários do diagrama de atividade x especificações de casos de uso:
• Observe, novamente, que as atividades correspondem ao passo a passo da especificação do respectivo 
caso de uso, que apresentaremos na sequência.
• Há uma decisão, cuja pergunta é “LOCALIZOU O CLIENTE?”.
• Em caso negativo, acionaremos a subatividade INCLUIR CLIENTE, já desenvolvida no diagrama de 
atividade do caso de uso REGISTRAR PEDIDO. Usaremos novamente aqui. Veja o que ela contém no 
diagrama apresentado;
• Em caso positivo, ou seja, o cliente foi localizado, é emitida uma mensagem de erro e retornamos à 
atividade INFORMAR ID CLIENTE.
•
•
•
•
- -7
Caso de Uso Confirmar Recebimento de Sinal
Comentários do diagrama de atividade x especificações de casos de uso:
• Nesse diagrama, podemos ver com mais propriedade a grande vantagem do diagrama de atividade sobre 
a especificação de casos de uso, além, claro, de ser gráfico, enquanto a descrição é textual: podemos ver 
todos os cenários alternativos conjugados com a diagramação do cenário principal.
• Temos dois cenários alternativos, representados por caminhos do SENÃO nas duas decisões do 
diagrama. A primeira decisão após a atividade LOCALIZAR PEDIDO e a segunda após a atividade 
INFORMAR DADOS SINAL, com as respectivas atividades de emissão de mensagens (cenários 
alternativos).
•
•
- -8
Diagramas de componentes e de implantação
Esses dois diagramas estão intimamente relacionados e caracterizam a solução arquitetônica definida para o
software. O diagrama de atividade é o limiar entre o projeto lógico (solução sistêmica) e o projeto físico (solução
tecnológica). Assim sendo, antes de modelarmos esses diagramas, vamos conhecer as definições tecnológicas da
solução, veja:
• O sistema vai rodar na intranet, já deixando toda a plataforma pronta para operar pela internet a 
qualquer momento. Espera-se que, com o crescimento da empresa, em um ano esse sistema 
comece a ser usado pela internet.
• O banco de dados usado será o SQL Server, que a empresa já possui.
• Será usado o sistema de autenticação e firewall já existentes na empresa, bem como a estrutura 
de servidores existentes (aplicações web, servidor BD e servidor impressão).
• O sistema deve ter um design responsivo (operar em qualquer plataforma de equipamentos), de 
forma que funcione em computadores, notebooks, tablets e smartphones.
• O sistema será desenvolvido para a plataforma Windows, usando o gerenciador de internet IIS do 
Windows.
• A linguagem será JAVA.
•
•
•
•
•
•
- -9
Veja, agora, a modelagem dos diagramas de componentes e de implantação:
Diagrama de Componentes
Diagrama de Implantação
Fique ligado
As definições tecnológicas da solução não têm compromisso com as melhores soluções. Nossa
finalidade é acadêmica, e assim estimulá-los a pensar e refletir sobre a existência de soluções
mais adequadas.
- -10
CONCLUSÃO
Nesta aula, você:
• Aplicou estudos de caso, nos quais exercitou a modelagem de diagramas de estados, de classes de 
projeto, de atividades, de componentes e de implantação.
Referências
BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. — Guia do Usuário. 2. ed. Rio de Janeiro: Elsevier, 2005. cap. 1 e 2.UML 
FOWLER, Martin. — um breve guia para a linguagem padrão. 3. ed. Porto Alegre: Artmed, 2005.UML essencial 
cap. 1
Saiba mais
Para saber mais sobre os tópicos estudados nesta aula, pesquise na internet sites, vídeos e
artigos relacionados ao conteúdo visto. Se ainda tiver alguma dúvida, fale com seu professor
online, utilizando os recursos disponíveis no ambiente de aprendizagem.
•
- -11
LARMAN, Craig. uma introdução à análise e ao projeto orientados a objetos e aoUtilizando UML e padrões: 
processo unificado. 3. ed. Porto Alegre:Artmed, 2007. cap. 2.