O Diagrama de Caso de Uso descreve a funcionalidade proposta para um novo sistema, que ser projetado.

Segundo Ivar Jacobson, podemos dizer que um Caso de Uso um documento narrativo que descreve a sequncia de eventos de um ator que usa um sistema para completar um processo. Caso de uso representado por uma elipse, com o nome do caso de uso dentro ou abaixo. Se h limites do sistema no diagrama, o caso de uso deve ficar dentro. Os casos de Uso so tipicamente relacionados a atores. (Iremos ver a definio de ator abaixo.) Imaginem o caso de uso como um palco de teatro, onde vocs tm o cenrio e seus atores, cada um executando uma ao com o cenrio a sua volta. O palco (limite) seria a parte do sistema em que o cenrio se encaixa. Use os casos de uso para descrever o sistema e como ele executa a ao, utilize uma linguagem simples e objetiva. Algumas regras para fazer um bom caso de uso: Um caso de uso sempre se inicia por um Ator. Um caso de uso deve oferecer possveis situaes do mundo real para testes do sistema. Um caso de uso deve ser completo. Um caso de uso deve ser uma descrio completa do sistema, o mesmo no estar completo at que o valor final seja produzido. Para identificar os casos de uso devemos fazer algumas perguntas: O ator precisa ler, modificar, alterar alguma informao no sistema? O trabalho do ator pode ser facilitado, simplificado com o uso de mais funes no sistema? O ator tem que receber ou enviar notificaes ao sistema? Quais as funes que o ator precisa do sistema? O que o ator precisa fazer? Quais os problemas com a implantao atual?

Ator
Especifica um papel executado que interage com o cenrio (caso de uso). Um ator deve ter associaes exclusivamente para casos de uso. A exceo um ator que possa herdar o papel de outro. Um ator representado por um boneco (stick man).

Um ator pode ser um usurio, um humano, uma mquina,hardware, uma aplicao. Um ator deve representar uma interao com o sistema. Para identificar um ator de um sistema podemos fazer as seguintes perguntas: Quem est interessado na exigncia? O sistema usa um recurso externo? Quem fornecer a informao ir usar e modificar, ou s remover? Uma pessoa representa um papel? O sistema interage com um sistema legado?

Interao em caso de uso

O ator comunica-se com o sistema atravs do envio e recebimento de mensagens. Um ator comunica-se com o caso de uso, esta comunicao e mostrada conectando-se o smbolo do ator ao smbolo do caso de uso por um caminho slido.

Tipos de relacionamento

Uso <<use>>
Quando os casos de uso tm um comportamento comum eles podem ser modelados em um simples caso de uso que utilizado por outro caso de uso. Ocorre quando h uma parcela de comportamento similar sugerindo um reutilizao.

Incluso <<include>>
No relacionamento de incluso, o cenrio mais comum quando existem dois casos de uso que sero utilizados em um caso de uso base, para que outros casos de uso utilizem estes servios. Desta forma evita-se descrever a mesma seqncia em casos de uso que usam outros casos de uso.

Extenso <<extend>>
Extenses so usadas para mostrar um comportamento semelhante, mas com alguma particularidade. (Especializao e Generalizao).

Como fazer um bom caso de uso

Eu tenho uma receita que costumo seguir para montar os meus casos de uso. Vou pass-la a vocs, mas com o tempo vocs iro melhorar a receita ou adequar s suas necessidades. Passo 1: Identificao dos atores

o o o o o o o o o o o

Listar os atores; Nomear os atores, d nomes reais Sr. Joo , Impressora HH900, CGQ; Descrever o papel de cada ator; Passo 2: Identificao dos Cenrios (Casos de Uso) Listar os casos de uso; Nomear os casos de uso (verbos); Descrever os casos de uso; Passo 3: Definir as interaes (Atores x Casos de Uso) Descrever as interaes; Analisar os esteretipos dos relacionamentos <<include>>, <<use>>, <<extend>>) Passo 4: Montar o diagrama Desenhe o diagrama; Descreva o diagrama; Passo 5: Estabelecer as ligaes Agrupe pelo tipo de cenrio;

Concluso
Eu considero os casos de uso o principal diagrama para um bom desenvolvimento e documentao de um sistema. Devemos detalhar todos os casos de uso, sem economizar nas descries, estas devem ser em uma linguagem simples e objetiva para que o cliente e o desenvolvedor possam falar o mesmo idioma, pois o seu cliente pode no entender os termos tcnicos que voc usa, assim como voc pode no entender os termos que ele usa.

UML - Diagrama de Classes e objetos

Resolvi falar um pouco sobre diagrama de classes e de objetos.. No uma tarefa trivial para ser desenvolvida em um pequeno artigo onde deve-se ter a preocupao de ser claro , objetivo sem ser superficial.

Eu poderia comear dando de cara a definio do que um diagrama de classes , mas creio que preciso falar sobre o conceito de classes , mas para isto preciso falar sobre o que so objetos... Estou falando para programadores e analistas , certo !!! Ento nosso foco e rea de atuao ser a Programao Orientada a Objetos. (POO) Em POO , os problemas de programao so pensados em termos de objetos , nada de funes , rotinas , nada disto , o assunto so os objetos , propriedades e mtodos. Nota: A preocupao da programao estruturada estava em procurar os processos que envolviam o problema e no os objetos que o compunham. Desta forma quando colocado o problema de desenvolver um sistema para locadoras , por exemplo , devemos pensar como dividir o problema em objetos. Para este caso podemos ter os seguintes objetos : Clientes , CDs e Fitas , etc.. A melhor maneira de conceituar estes termos considerar um objeto do mundo real e mostrar como podemos represent-lo em termos conceitos para POO. Comeando com as definies : "Um objeto um termo que usamos para representar uma entidade do mundo real" (Fazemos isto atravs de um exerccio de abstrao.) Vou usar como exemplo o meu cachorro Bilu. Posso descrever o Bilu em termos de seus atributos fsicos: pequeno , sua cor principal castanha , olhos pretos , orelhas pequenas e cadas, rabo pequeno , patas brancas. Posso tambm descrever algumas aes que ele faz (temos aqui os mtodos) : balana o rabo quando chego em casa , foge e se deita se o mando sair debaixo da mesa, late quando ouve um barulho ou v um co ou gato, atende e corre quando o chamo pelo seu nome. Temos abaixo a representao do Bilu.

Temos aqui a representao de um objeto , no caso o meu cachorro Bilu , que possui as seguintes propriedades e mtodos: Propriedades : Cor do corpo : castanha cor dos olhos : preto altura: 18 cm comprimento: 38 cm largura : 24 cm Mtodos : balanar o rabo , latir , deitar , sentar Meu cachorro Bilu

Em termos de POO para poder tratar os objetos comeamos criando classes , neste caso irei criar a classe chamada Cachorro. "Uma classe representa um conjunto de objetos que possuem comportamentos e caractersticas comuns". "Na UML o nome de uma classe um texto contendo letras e dgitos e algumas marcas de pontuao. Na realidade, melhor guardar os nomes curtos com apenas letras e dgitos. UML sugere capitalizar todas as primeiras letras de cada palavra no nome (ex.: ``Lugar'', ``DataReserva''). melhor tambm manter nomes de classe no singular, classes por default contm'' mais de um objeto, o plural implcito.". [Nicolas Anquetil] Uma classe descreve como certos tipos de objetos se parecem do ponto de vista da programao , pois quando definimos uma classe precisamos definir duas coisas: 1. Propriedades - Informaes especficas relacionadas a uma classe de objeto. So as caractersticas dos objetos que as classes representam. Ex Cor , altura , tamanho , largura , etc... 2. Mtodos: So aes que os objetos de uma classe podem realizar. Ex: Latir , correr , sentar , comer, etc. Voc pode pensar em uma classe com um modelo para criar quantos objetos voc desejar de um tipo particular. Pense em um carimbo com a imagem de um cachorro , quando voc carimba e obtm um desenho de cachorro voc acabou de criar uma instncia da classe e obteve um objeto daquela classe. O novo objeto possuir todas as caractersticas e comportamentos definidos pela classe. (As classes especificam a estrutura e o comportamento (operaes) dos objetos, que so instncias das classes)

Aqui temos que Bilu um objeto da classe Cachorro. Em termos de POO acabamos de criar uma instncia da classe Cachorro e a chamamos Bilu. Quando criamos uma nova instncia de uma classe dizemos que estamos instanciando a classe.

Geralmente em um sistema de mdio porte sero identificados diversas classes que compem o sistema. Neste contexto a UML surgiu como uma proposta de ser uma linguagem para modelagem de dados que usava diversos artefatos para representar o modelo de negcio ; um destes artefatos o diagrama de classes. A representao de uma classe usa um retngulo dividido em trs partes:

nome atributos mtodos

Podemos dizer que os diagramas de classes so los principais diagramas estruturais da UML pois ilustram as classes , interfaces e relacionamentos entre elas. Os diagrama se classes ilustram atributos e operaes de uma classe e as restries como que os objetos podem ser conectados ; descrevem tambm os tipos de objetos no sistema e os relacionamentos entre estes objetos que podem ser : associaes e abstraes.

Para poder representar a visibilidade dos atributos e operaes em uma classe utiliza-se as seguintes marcas e significados: + pblico - visvel em qualquer classe # protegido - qualquer descendente pode usar - privado - visvel somente dentro da classe

Relacionamento entre classes

Os objetos tem relaes entre eles: um professor ministra uma disciplina para alunos numa sala, um cliente faz uma reserva de alguns lugares para uma data, etc. Essas relaes so representadas tambm no diagrama de classe. [Nicolas Anquetil] A UML reconhece trs tipos mais importantes de relaes: dependncia, associao e generalizao (ou herana). Geralmente as classes no esto ss e se relacionam entre si. O relacionamento e a comunicao entre as classes definem responsabilidades , temos 3 tipos : 1. Associaes : Agregao e composio 2. Generalizao (herana) 3. Dependncias As representaes usam a seguinte notao :

Associao : So relacionamentos estruturais entre instncias e especificam que objetos de uma classe esto ligados a objetos de outras classes. Podemos ter associao uniria , binria , etc. A associao pode existir entre classes ou entre objetos. Uma associao entre a classe Professor e a classe disciplina (um professor ministra uma disciplina) significa que uma instncia de Professor (um professor especfico) vai ter uma associao

com uma instncia de Disciplina. Esta relao significa que as instncias das classes so conectadas, seja fisicamente ou conceitualmente.[Nicol as Anquetil]

Dependncia - So relacionamentos de utilizao no qual uma mudana na especificao de um elemento pode alterar a especificao do elemento dependente. A dependncia entre classes indica que os objetos de uma classe usam servios dos objetos de outra classe.

l l l

Generalizao (herana : simples ou composta) - Relacionamento entre um elemento mais geral e um mais especfico. Onde o elemento mais especfico herda as propriedades e mtodos do elemento mais geral. A relao de generalizao tambm conhecida como herana no modelo a objetos. Como a relao de dependncia, ela existe s entre as classes. Um objeto particular no um caso geral de um outro objeto, s conceitos (classes no modelo a objetos) so generalizao de outros conceitos. Agregao Regular - tipo de associao ( parte de , todo/parte) onde o objeto parte um atributo do todo ; onde os objetos partes somente so criados se o todo ao qual esto agregados seja criado. Pedidos composto por itens de pedidos.

l l Composio - Relacionamento entre um elemento ( o todo) e outros elementos (as partes) onde as parte s podem pertencer ao todo e so criadas e destrudas com ele. O diagrama de de classes lista todos os conceitos do domnio que sero implementados no sistema e as relaes entre os conceitos. Ele muito importante pois define a estrutura do sistema a desenvolver.

O diagrama de classes no surge do nada ele consequncia do prvio levantamento de requisitos , definio de casos de usos e classes. Como exemplo vamos supor que voc tivesse que desenvolver um sistema para automatizar um consultrio dentrio. As etapas bsicas envolvidas seriam: Levantamento e anlise de requisitos do sistema a ser desenvolvido. Entrevista com o dentista(s) e com as pessoas que trabalham no consultrio Definio dos objetos do sistema : Paciente , agenda , dentista , servio , contrato , consulta , pagamento , etc.. Definio dos atores do sistema : paciente, dentista , secretria Definio e detalhamento dos casos de uso: marcar consulta , confirmar consulta , cadastrar paciente , cadastrar servios , etc. Definio das classes : paciente , dentista , exame , agenda , servio Definir os atributos e mtodos das classes : Aps toda esta anlise voc chega no diagrama de classes do sistema (representado abaixo a ttulo de exemplo ilustrativo)

Atributo Um atributo representa uma propriedade que todos os objetos da classe tm (por exemplo, todos os cachorros tem pelo , orelhas , altura, ,etc. Mas cada objeto ter valores particulares para seus atributos (alguns cachorros so mais baixos , outros so maiores, etc.).

Uma classe pode ter qualquer nmero de atributos. Na UML, o nome de um atributo um texto contendo letras e dgitos e algumas marcas de pontuao. UML sugere de capitalizar todas as primeiras letras de cada palavra no nome menos a primeira palavra (ex.: "nome'', "nomeCachorro''). Num modelo, os atributos devem ser de um tipo simples (inteiro, texto, talvez data), no podem conter outros objetos. Mtodos Mtodos so aes que implementam uma operao. Uma classe pode ter qualquer nmero de mtodos e dois mtodos em duas classes podem ter o mesmo nome. Todos os mtodos que vo implementar a operao tem que respeitar exatamente a assinatura dela (mesmo nome, mesmo nmero de atributo, com os mesmo tipos e o mesmo ordem). Um mtodo no pode acrescentar ou cortar um parmetro. Isso seria um violao do polimorfismo. Para mandar a mensagem corretamente, teramos que saber qual a classe do objeto (cada classe tendo mtodo com assinatura diferente). O que possvel, no caso de cortar um parmetro, simplesmente ignor-lo na implementao. [Nicolas Anquetil] Voltarei falar sobre UML nos prximos artigos onde iremos abordar os seguintes diagramas UML: Seqncia : Mostra interaes entre vrios componentes do sistema enfocando a sequncia. Colaborao : Mostra interaes entre vrios componentes do sistema enfocando a colaborao entre as classes. Atividade : Mostra como um sub-sistema ou um objeto realizam uma operao. Estados : Mostra como um sub-sistema ou um objeto realizam uma operao. Componentes : Mostra a organizao dos componentes. Trata da implementao do sistema. Implantao : Mostra a configurao fsica sobre qual o sistema ser instalado. E estamos conversados.... Veja tambm a seo de UML-XML em : XML/UML Novas sees:

Vdeo-Aulas VB Prtico

Super CD Visual Basic Tudo sobre Visual Basic Super DVD .NET - Tudo sobre VB .NET , ASP .NET Para saber mais sobre o assunto veja tambm os seguintes artigos:

UML UML UML UML -

Apresentando os principais diagramas da linguagem Modelando sistemas - Casos de Uso Conceitos Bsicos Unified Modeling Language e Visual Modeler.

Jos Carlos Macoratti