Archive for the ‘UML’ Category

Diagramas de Seqüência

Outubro 1, 2006

Diagramas de Seqüência mostram a troca de mensagens (isto é chamada de método) entre diversos Objetos, numa situação específica e delimitada no tempo. Objetos são instâncias de classes. Diagramas de Seqüência colocam ênfase especial na ordem e nos momentos nos quais mensagens para os objetos são enviadas.

Em Diagramas de Seqüência objetos são representados através de linhas verticais tracejadas, com o nome do Objeto no topo. O eixo do tempo é também vertical, aumentando para baixo, de modo que as mensagens são enviadas de um Objeto para outro na forma de setas com a operação e os nomes dos parâmetros.

Mensagens pode ser síncronas, o tipo normal de mensagem de chamada onde o controle é passado para o objeto chamado até o método ter terminado sua execução, ou assíncronas onde o controle é passado diretamente para o objeto chamado. Mensagens síncronas possui uma caixa vertical no lado do objeto chamado para mostrar o controle do fluxo do programa.

Diagramas de Colaboração

Outubro 1, 2006

Diagramas de Colaboração mostram as interações que ocorrem entre os objetos participantes numa situação específica. Isto é mais ou menos a mesma informação mostrada pelos Diagramas de Seqüência, mas neste a ênfase é colocada em como as interações ocorrem no tempo, enquanto os Diagramas de Colaboração colocam os relacionamentos entre os objetos e sua topologia em destaque.

Em Diagramas de Colaboração as mensagens enviadas de um objeto para outro são representadas por setas, mostrando o nome da mensagem, parâmetros, e a seqüência da mensagem. Diagramas de Colaboração são especialmente indicados para mostrar um fluxo ou situação específica do programa e são um dos melhores tipos de diagrama para rapidamente demonstrar ou explanar um processo na lógica do programa.

Outros Ítens do Diagrama de Classe

Outubro 1, 2006

Diagramas de Classe podem conter diversos outros ítens além das classes.

Interfaces

Interfaces são classes abstratas que significam instâncias que não podem ser diretamente criadas delas. Elas podem conter operações mas não podem conter atributos. Classes podem derivar de interfaces (através da realização de uma associação) e instâncias podem então ser feitas destes diagramas.

Tipos de dados

Tipos de dados são primitivos uma vez que são tipicamente construídos numa linguagem de programação. Exemplos comuns são inteiros e lógicos. Eles não podem ser relacionados à classes mas classes pode se relacionar com eles.

Enumerações

Enumerações são uma lista simples de valores. Um exemplo típico é uma enumeração para dias da semana. As opções de uma enumeração são chamadas Literais de Enumeração. Como tipos de dados, elas não podem ter relacionamentos para classes mas classes podem relacionar-se com elas.

Pacotes

Pacotes representam um espaço de nomes numa linguagem de programação. Num diagrama eles são usados para representar partes de um sistema que contém mais de uma classe, talvez centenas de classes.

Associações de Classe

Outubro 1, 2006

Classes podem relacionar-se (ser associada com) com outras de diferentes maneiras:

Generalização

Herança é um dos conceitos fundamentais da programação Orientada à Objeto, na qual uma classe “herda” todos os atributos e operações da classe da qual deriva, e pode sobrescrever/modificar alguns deles, bem como adicionar mais atributos e operações próprios.

EM UML, uma associação Generalização entre duas classes coloca-as numa hierarquia representando o conceito de herança de uma classe derivada de uma classe base. Em UML, Generalizações são representadas por uma linha conectando duas classes, com uma seta no lado da classe base.

Associações

Um associação representa um relacionamento entre classes, e fornece a semântica comum e a estrutura para muitos tipos de “conexões” entre objetos.

Associações são o mecanismo que permite objetos comunicarem-se entre si. Elas descrevem a conexão entre diferentes classes (a conexão entre os objetos atuais é chamada conexão do objeto, ou link.

Associações podem ter um regra que especifica o propósito da associação e pode ser uni ou bidirecional (indicadando se os dois objetos participantes do relacionamento podem mandar mensagens para o outro, ou se apenas um deles sabe sobre o outro). Cada ponta da associação também possui uma valor de multiplicidade, que dita como muitos objetos neste lado da associação pode relacionar-se com o outro lado.

Em UML, associações são representadas como linhas conectando as classes participantes do relacionamento, e podem também mostrar a regra e a multiplicidade de cada um dos participantes. A multiplicidade é exibida como um intervalo [min…máx] de valores não negativos, com uma estrela (*) no lado máximo representando infinito.

Agregação

Agregações são um tipo especial de associação no qual as duas classes participantes não possuem em nível igual, mas fazem um relacionamento “todo-parte”. Uma Agregação descreve como a classe que possui a regra do todo, é composta (tem) de outras classes, que possuem a regra das partes. Para Agregações, a classe que age como o todo sempre tem uma multiplicidade de um.

Em UML, Agregações são representadas por uma associação que mostra um rombóide no lado do todo.

Composição

Composições são associações que representam agregações muito fortes. Isto significa que Composições formam relacionamentos todo-parte também, mas o relacionamento é tão forte que as partes não pode existir independentes. Elas existem somente dentro do todo, e se o todo é destruído as partes morrem também.

Em UML, Composições são representadas por um rombóide sólido no lado do todo.

Diagrama de Classe

Outubro 1, 2006

Diagramas de Classe mostram as diferentes classes que fazem um sistema e como elas se relacionam. Os Diagramas de Classe são chamados diagramas “estáticos” porque mostram as classes, com seus métodos e atributos bem como os relacionamentos estáticos entre elas: quais classes “conhecem” quais classes ou quais classes “são parte” de outras classes, mas não mostram a troca de mensagens entre elas.

Classe

Um Classe define os atributos e os métodos de um conjunto de objetos. Todos os objetos desta classe (instâncias desta classe) compartilham o mesmo comportamento, e possuem o mesmo conjunto de atributos (cada objeto possui seu próprio conjunto). O termo “Tipo” é algumas vezes usado ao invés de Classe, mas é importante mencionar que estes dois termos não são a mesma coisa, e Tipo é um termo mais genérico.

Em UML Classes são representadas por retângulos, com o nome da classe, e podem também mostrar os atributos e operações da classe em dois outros “compartimentos” dentro do retângulo.

Atributos

Na UML, atributos são mostrados com pelo menos seu nome, e podem também mostrar seu tipo, valor inicial e outras propriedades. Atributos podem também ser exibidos com sua visibilidade:

  • + indica atributos públicos
  • # indica atributos protegidos
  • - indica atributos privados
Operações

Operações (métodos) também são exibidos com pelo menos seu nome, e podem também mostrar seus parâmetros e valores de retorno. Operações podem, como os Atributos, mostras sua visibilidade:

  • + indica operações públicas
  • # indica operações protegidas
  • - indica operações privadas
Modelos

Classes podem ter modelos, um valor que é usado para uma classe ou tipo não especificado. O tipo de modelo é especificado quando uma classe é iniciada (isto é um objeto é criado). Modelos existem no C++ moderno e foram introduzidos no Java 1.5 onde eles são chamados de Genéricos.

Diagrama de Caso de Uso

Setembro 23, 2006

Diagramas de Caso de Uso não são adequados para representar o desenho, e não podem descrever os mecanismos internos de um sistema. Diagramas de Caso de Uso são feitos para facilitar a comunicação com os futuros usuários do sistema, e com o cliente, e são especialmente úteis para determinar os recursos necessários que o sistema deve ter. Diagramas de Caso de Uso dizem o quê o sistema deve fazer, mas não fazem e não podem especificar como isto será conseguido.

Um Caso de Uso descreve um grupo de atividades num sistema que produz um resultado concreto e tangível.

Casos de Uso são descrições de interações típicas entre os usuários de um sistema e o sistema propriamente dito. Eles representam a interface externa do sistema e especificam um conjunto de exigências do que o sistema deve fazer

algumas regras simples Quando trabalhar com Casos de Uso

  • Cada Caso de Uso está relacionado com no mínimo um ator
  • Cada Caso de Uso possui um iniciador (isto é um ator)
  • Cada Caso de Uso liga-se a um resultado relevante (um resultado com “valor de negócio”)
  • Casos de Uso também podem ter relacionamentos com outros Casos de Uso. Os três tipos mais comuns de relacionamento entre Casos de Uso são:

    • <<inclui-se>> que especifica que um Caso de Uso toma lugar dentro de outro Caso de Uso
    • <<estende>> que especifica que em determinadas situações, ou em algum ponto (chamado um ponto de extensão) um Caso de Uso será estendido por outro.
    • Generalização especifica que um Caso de Uso herda as características do “Super” Caso de Uso, e pode sobrepor algumas delas ou adicionar novas de maneira semelhante a herança entre classes.

    Ator

    Um ator é uma entidade externa (fora do sistema) que interage com o sistema participando (e freqüentemente iniciando) um Caso de Uso. Atores podem ser pessoas reais (por exemplo usuários do sistema), outro sistema de computador ou eventos externos.

  • Descrição do Caso de Uso são narrativas de texto do Caso de Uso. Elas usualmente tomam a forma de uma nota ou um documento que é de alguma maneira ligado ao Caso de Uso, e explana o processo ou atividades que tomarão lugar no Caso de Uso.

Elementos UML

Setembro 7, 2006

Diagrama de Caso de Uso mostra atores (pessoas ou outros usuários do sistema), casos de uso (os cenários onde eles usam o sistema), e seus relacionamentos

Diagrama de Classe mostra classes e os relacionamentos entre elas

Diagrama de Seqüência mostra objetos e uma seqüência das chamadas do método feitas para outros objetos.

Diagrama de Colaboração mostra objetos e seus relacionamentos, colocando ênfase nos objetos que participam na troca de mensagens

Diagrama de Estado mostra estados, mudanças de estado e eventos num objeto ou uma parte do sistema

Diagrama de Atividade mostra atividades e as mudanças de uma atividade para outra com os eventos ocorridos em alguma parte do sistema

Diagrama de Componente mostra os componentes de programação de alto nível (como KParts ou Java Beans).

Diagrama de Distribuição mostra as instâncias dos componentes e seus relacionamentos.

Diagramas UML

Setembro 7, 2006

Existem vários tipos de diagramas UML:

->Diagramas estruturais:

           *Diagrama de objetos – mostra objetos instanciados das classes

           *Diagrama de classes – é uma representação da estrutura e relações das classes que servem de modelo para objetos. Existem dois tipos de associação entre classes: agregação(quando um objeto não depende do outro para existir) e composição(quando um objeto não existe sem o outro)

Surgimento

Setembro 7, 2006

A UML surgiu em meados de 1996 com o objetivo de criar uma notação padronizada para modelagem de sistemas orientadas a objetos.

Permite aos desenvolvedores visualizarem os produtos de seu trabalho em diagramas padronizados.

Unified Modeling Language

Setembro 4, 2006

é uma linguagem de modelagem não proprietária de terceira geração. A UML não é um método de desenvolvimento, o que significa que ela não diz para você o que fazer primeiro e em seguida ou como desenhar seu sistema, mas ele lhe auxilia a visualizar seu desenho e a comunicação entre objetos.

O UML tem origem na compilação das “melhores práticas de engenharia” que provaram ter sucesso na modelagem de sistemas grandes e complexos. Sucedeu aos conceitos de Booch, OMTT (Rumbaugh) e OOSE (Jacobson) fundindo-os numa única linguagem de modelagem comum e largamente utilizada. O UML pretende ser a linguagem de modelagem padrão para modelar sistemas concorrentes e distribuídos.

tirado do site http://pt.wikipedia.org/wiki/UML

 pessoalmente acho a Parte de diagrama interessante para apresentar a um cliente pois ateh mesmo um leigo consegue enteder o funcionamento, assim fica melhor saber exatamente oque o cliente deseja e é mais facil para espressar seu programa!


Seguir

Get every new post delivered to your Inbox.