Escolar Documentos
Profissional Documentos
Cultura Documentos
Apostila Uml2
Apostila Uml2
Resumo
A UML , Linguagem de Modelagem Unificada foi criada por Rambaugh, Booch e Jacobson, profissionais da área de sistemas e processos, que se
uniram com o objetivo de se criar um padrão para desenvolvimento de software que reunisse as melhores práticas de metodologia de sistemas.
Esta linguagem é aberta e pode ser utilizada para criar um modelo para se abstrair as fases de um projeto de criação de software. Neste modelo,
diversos diagramas auxiliam na visualização do problema e a concepção da solução, permitindo uma visão macro dos objetos e seus relacionamentos.
Grandes sistemas necessitam de uma série de especificações e geralmente tais documentos são longos e muito detalhados. A modelagem
proporcionada pela UML permite simplificar o entendimento de um sistema, ao transformar suas complexidades em objetos gráficos simples, onde a
lógica interna de seu funcionamento é abstraída.
Através da modelagem também conseguimos estruturar um sistema. A manutenção que ocorrer nos posteriores ciclos de desenvolvimento fica mais
fácil de ser efetuada já que a mesma ocorre inicialmente num nível lógico, e não no código (programa), de forma que se pode evoluir os diagramas que
serão alterados e verificar suas conseqüências, antes de se preocupar com a fase de desenvolvimento.
Algo que é interessante de se notar é que a UML é uma linguagem e não uma Metodologia. Em função de sua independência, a mesma pode ser
utilizada como ferramenta de apoio por diversas metodologias.
Documentação do Sistema
Este modelo pode ser utilizado para se discutir a visão do projeto de sistema com todos os envolvidos, desde os usuários-chave (e gerência) que irão
se beneficiar do sistema até os elementos da equipe de desenvolvimento (programadores, analistas, testadores, etc). Desta forma, o resultado final
deverá ser um conjunto de diagramas e documentos avaliados por toda a equipe e em conformidade com a necessidade dos stakeholders.
Um Controle de Versões poderá ser implementado, na medida em que se armazena (e identifica-se devidamente) os processos (e suas versões) e
suas funcionalidades. Estes elementos irão mudar na medida em que se verifica a manutenção do sistema, de forma que é necessário identificar a
versão dos mesmos.
* Tais itens (diagramas e documentos), requisitos (funcionais e não funcionais), documento visão e protótipos irão inicialmente compor a
Documentação do Sistema.
É uma descrição textual completa de um determinado processo, identificando seu cenário principal, isto é, o fluxo normal que
normalmente ocorreria. Este documento é estruturado descrevendo-se seus passos / instruções sem se ater a detalhes de tecnologia,
porém identificando o limite/restrição/faixa de dados. Além disto, aqui identificamos o (s) ator (es) que interage (m) com o sistema. As
exceções (fluxos / cenários alternativos) também são explicadas porém a ênfase é dada no fluxo principal.
O Ator pode ser entendido como um elemento externo que interage com o sistema. Geralmente simboliza um usuário de algum
departamento, mas também pode simbolizar outros elementos tais como um temporizador (relógio) que aciona o sistema de tempos em
tempos para realizar alguma ação ou sistemas externos que interagem com um determinado sistema.
Através da documentação do sistema, identificamos os atores, eventos e seus processos, de forma a eleger os possíveis Casos de Uso.
Exemplo:-
O Ator, que representa o elemento externo ao sistema, associa-se ao caso de uso (representado pela figura oval).
Neste exemplo utilizei o conceito de generalização, que permite criar um supertipo, composto de subtipos de mesma função, de forma a criar o Ator
Usuário, e a partir dele associar os atores relacionados, de modo a facilitar o entendimento do diagrama. Verificamos neste exemplo que o Ator Cliente,
além de ter acesso aos casos de uso herdados pelo seu supertipo (Usuário), também tem acesso exclusivo ao Caso de Uso “Solicitar Cadastro de
Cliente”.
Diagrama de Classes
Através deste diagrama podemos verificar os objetos do sistema, seus atributos, métodos e
relações.
Atributo
Um atributo de um objeto é uma característica deste objeto. Se o objeto fosse um Pedido de
Venda, alguns de seus atributos seriam número do pedido, data da venda, código do cliente,
data de previsão de entrega, status, dentre outros.
Método
Um método é uma função que a classe realiza. Considerando o mesmo objeto (pedido de venda) como exemplo, alguns de seus métodos seriam
criar(), alterar(), excluir() , imprimir() e baixar().
Nome da Classe
atributo: tipo
+metodo()
Classe / Objeto
A Classe é a representação genérica de um objeto, contendo os tipos de informações que um objeto pode ter, além dos métodos que o objeto
executar.
Um objeto é uma instância (derivação / criação) de uma classe. Ele contém informações específicas que identificam um item específico no sistema.
Exemplo:-
CLASSE OBJETO
Pedido :Pedido
Numero: integer Numero: 1234
Venda: date Venda: 30/12/2005
Cliente: integer Cliente: 537
Previsão: date Previsão: 15/01/2006
Status: integer Status: 2
+Criar() +Criar()
+Alterar() +Alterar()
+Excluir() +Excluir()
+Imprimir() +Imprimir()
+Baixar() +Baixar()
Relacionamento / Associação
O conceito de associação ocorre quando uma classe relaciona-se com outra classe. Isto ocorre neste exemplo. Cada objeto instanciado da classe
ItensPedido refere-se a um objeto do tipo Produto.
ItensPedido Produto
-mantidos em
-produto : long -codigo : long
-quantidade : int -cadastro : Date
-precoUnitario : float 0..* 1 -estoque : long
+metodo() +metodo()
Composição
Classe
Note que o Diagrama de Classe não está prevendo o acesso aos dados, sendo comum na Fase de Projeto. Posteriormente, muitas informações serão
inseridas na fase de Desenvolvimento, dentre elas serão acrescidas as classes de acesso à dados.
Pedido
-numero : long
-data : Date
-cliente : long
+metodo()
0..*
ItensPedido
-produto : long
-quantidade : int
-precoUnitario : float
+metodo()
Herança
Quando uma determinada classe (sub-classe) herda os atributos e métodos da classe pai (super-classe). No exemplo abaixo, notamos a existência
das classes Poupança e Folha, que derivam da classe pai (Conta_Bancária), herdando seus atributos e métodos, mas que possuem atributos que lhe
são próprios.
Conta Bancária
-numero : long
-banco : string
-agencia : string
-conta : string
-saldo : float
+depositar()
+sacar()
+consultar()
Poupança Folha
-vencimento : Date -funcionario : long
Diagrama de Seqüência
Utilizado para se verificar a seqüência dos passos de um determinado caso de uso, num determinado momento do sistema. Neste diagrama
verificamos a interatividade do ator e as mensagens ocorridas entre os objetos.
Linha Vertical: Representa a temporalidade da existência do objeto no diagrama, que ocorre enquanto houver interações entre os demais objetos.
Seta Horizontal com Flecha: Representa a mensagem trocada entre os objetos, podendo conter parâmetros.
Diagrama de Estados
O objetivo de um diagrama de estados é mostrar os possíveis estados de um objeto e os eventos que altera seu status. O estado de um objeto é o
resultado das operações deste objeto num determinado momento. Em geral, o objeto tem um estado inicial quando de sua criação, e em geral é
alterado pela ocorrência de um determinado evento. Após ser acionado, o objeto realiza uma ou mais operações de forma que seu estado muda para
uma outra condição. Num determinado momento o objeto tem o seu estado alterado para um estado final, que pode ocorrer em diversas
circunstâncias, indicando o fim das alternâncias de estado. Desta forma, através deste diagrama é possível visualizar os possíveis estados que um
objeto pode ter, de forma a se prever seu comportamento.
No exemplo a seguir, mostro os estados possíveis para um pedido, os eventos que modificam seu estado e seu estado final.
Para finalizar, aconselho aos usuários a criação de protótipos de telas e formulários, que serão baseados nas descrições de casos de uso e sua
funcionalidade se dará conforme os diagramas de seqüências criados.
Carlos Majer
cmajer@uol.com.br