Uma Introdução à UML 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. Estrutura Básica da UML Neste artigo irei relacionar alguns dos itens que considero o básico na estrutura da UML. Será algo superficial para o leitor que queira ter uma primeira noção do que é a UML, de forma que não irei me aprofundar muito nos detalhes. Colocarei também alguns exemplos de diagramas, de maneira que o leitor possa fazer um comparativo analógico com explicação dada. Os diagramas que descreverei são:-

� Descrição de Casos de Uso � Diagrama de Casos de Uso � Diagrama de Classes � Diagrama de Seqüência � Diagrama de Estados

Descrição de Casos de Uso

É 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:-

Nome do Caso de Uso Efetuar Login

Descrição Este caso de uso descreve a maneira pelo qual um usuário tem acesso ao sistema.

Ator Envolvido Usuário

Ativação Ocorre no momento em que o Usuário acessa o site.

Pré-Requisito Usuário deve estar cadastrado no sistema.

Ator Sistema

O usuário informa sua identificação (login) e senha. Caso o usuário deseje que num próximo

acesso o sistema apresente seu nome automaticamente, ele terá a opção de armazenar a sua

identificação. (EX01)

O sistema consiste se o usuário foi informado, se o mesmo está cadastrado, se a senha é válida

(é igual à cadastrada no sistema) e se o usuário não está com seu acesso ao sistema bloqueado

(ver observações na próxima página). (EX02, EX03, EX04)

O sistema registra a data e hora do último acesso do usuário.

O Sistema exibe número de acessos efetuados pelo usuário, a data de seu último acesso e a

mensagem:= “Seja bem vindo(a) à Área Reservada”

Interação entre Ator e Sistema

O sistema memoriza a identificação (login) e tipo de usuário que pode ser Cliente, Operador do

Sistema, Departamento Financeiro ou Departamento Comercial.

EX01 O sistema apresenta automaticamente a identificação do usuário, caso tenha sido

configurado para isto.

EX02 O sistema verifica se a identificação está em branco e neste caso mostra a mensagem:-

“Campo Identificação em branco - Favor Informar”

Exceções

EX03 Caso o sistema não consiga encontrar o usuário ou se a senha do mesmo estiver

incorreta, ele exibe a mensagem:-

“Identificação de Usuário ou Senha: Incorreto”

e em seguida o sistema registra a falha da tentativa de login.

EX04 Caso o usuário esteja bloqueado, o sistema exibe a mensagem

“Você está atualmente bloqueado – Favor entrar em contato com a

Administração.”

e em seguida ele registra a tentativa de acesso ao sistema.

Observações Bloqueado: Status do Usuário que faz com que ele não possa acessar o sistema. Este status

pode ser definido pelo Operador do Sistema, Depto Financeiro ou Depto Comercial, em função

das seguintes possibilidades:-

� Dívida/Inadimplência do Cliente

� Usuário demitido

� Usuário temporariamente afastado (férias, licença, etc)

� Outras eventualidades.

Diagrama de Casos de Uso Modelo gráfico que agrupa determinados casos de usos e atores de um determinado sistema, de forma a visualizar-se de maneira rápida e fácil o relacionamento entre eles, servindo de documento para comunicação entre os participantes do projeto. 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 Venda: date Cliente: integer Previsão: date Status: integer

Numero: 1234 Venda: 30/12/2005 Cliente: 537 Previsão: 15/01/2006 Status: 2

+Criar() +Alterar() +Excluir() +Imprimir() +Baixar()

+Criar() +Alterar() +Excluir() +Imprimir() +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.

+metodo()

-codigo : long-cadastro : Date-estoque : long

Produto

+metodo()

-produto : long-quantidade : int-precoUnitario : float

ItensPedido-mantidos em

0..* 1

Composição

Classe

Classe Classe Classe

Um tipo de associação de agregação é a Composição, e podemos perceber isto através do exemplo abaixo. A classe Pedido tem suas informações gerais (número do pedido, data do pedido, código do cliente, etc), bem como seus métodos. A classe ItensPedido contém os itens de um determinado Pedido, com seus atributos (código do produto, quantidade pedida, precoUnitario), além de seus métodos específicos. Entretanto a existência de um objeto do tipo ItensPedido está totalmente relacionada à existência de um objeto do tipo Pedido, ou a 1a. classe é composta dos itens da 2a. classe, de forma que não tem sentido a existência de ItensPedido sem a existência de Pedido. 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.

+metodo()

-numero : long-data : Date-cliente : long

Pedido

+metodo()

-produto : long-quantidade : int-precoUnitario : float

ItensPedido

1

0..*

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.

+depositar()+sacar()+consultar()

-numero : long-banco : string-agencia : string-conta : string-saldo : float

Conta Bancária

-vencimento : Date

Poupança

-funcionario : long

Folha

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. Ator: Usuário, interage com o sistema Objeto TelaLogon: boundary, representa a fronteira entre o sistema e o usuário. Também chamado de interface. Objeto CtrlLogin: control, representa a classe que gerencia a seqüência e controla as mensagens do sistema. Objeto Usuário: entity: Entidade, representa a classe que retrata o objeto real, onde se recupera e armazena as informações necessárias ao sistema. 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.

Figura 1 – Protótipo de Tela de Login

Figura 2 – Protótipo de Tela de Entrada de Pedidos

Carlos Majer

Desenvolvedor (desde 1986)

Analista de Sistemas (desde 1988)

Pioneiro no uso da Internet participando do projeto experimental da Internet Brasileira de Abril a Dezembro de

1994.

Pioneiro na criação de software Shareware no Brasil (1994)

Tecnólogo e Professor da Universidade Cidade de São Paulo.

cmajer@uol.com.br