Mostrando postagens com marcador UML. Mostrar todas as postagens
Mostrando postagens com marcador UML. Mostrar todas as postagens
sexta-feira, 21 de agosto de 2009
Diagrama de Implantação
O diagrama de implantação é utilizado para descrever uma visão da arquitetura a ser utilizada, ou seja, mostra a integração entre a parte física (hardware) da solução de software.
Diagrama de Componentes
O diagrama de componentes é utilizado para exibir como os módulos de um sistema são interligados.
Diagrama de Atividades
O diagrama de atividades é semelhante a um fluxograma, ou seja, esse diagrama é focado no fluxo de controle de uma atividade.
Preocupa-se em descrever os passos a serem seguidos para a conclusão de um método e não de um processo (isso é responsabilidade do digrama de sequência e de colaboração).
Preocupa-se em descrever os passos a serem seguidos para a conclusão de um método e não de um processo (isso é responsabilidade do digrama de sequência e de colaboração).
Diagrama de Colaboração
O diagrama de colaboração é muito parecido com o diagrama de sequência, pois preocupa-se com a comunicação entre os objetos entretanto, este diagrama não leva em consideração a temporalidade em que as "coisas" (troca de mensagem) acontecem.
Diagrama de Sequência
O objetivo do diagrama de sequência é determinar a ordem temporal ou a sequencia de eventos que ocorrem em um determinado processo.
Nesse diagrama é possível se visualizar as mensagens trocadas entre os objetos, as restrições impostas para a troca dessas mensagens, os métodos que são chamados, a interação entre os objetos e em que momento essas coisas acontecem.
Nesse diagrama é possível se visualizar as mensagens trocadas entre os objetos, as restrições impostas para a troca dessas mensagens, os métodos que são chamados, a interação entre os objetos e em que momento essas coisas acontecem.
Diagrama de Objetos
O diagrama de objetos complementa o diagrma de classes representando os objetos e seus estados em um determinado momento.
É recomendável criar vários diagramas de objetos enfocando pequenas partes do diagrama de classe evitando assim um diagrama poluído.
Conceitos
Classes Entity - Classes que mantem as informações apenas na memória principal.
Classes persistentes - Classes que devem obrigatoriamente preservam suas informações fisicamente, ou seja, em memória secundária.
Esteriótipos de classe
<<>> usado para indicar classes do tipo Entity
<> indica que a classe é uma interface
<> indica que a classe ser para ligar a interface a outras classes
É recomendável criar vários diagramas de objetos enfocando pequenas partes do diagrama de classe evitando assim um diagrama poluído.
Conceitos
Classes Entity - Classes que mantem as informações apenas na memória principal.
Classes persistentes - Classes que devem obrigatoriamente preservam suas informações fisicamente, ou seja, em memória secundária.
Esteriótipos de classe
<<>> usado para indicar classes do tipo Entity
<
<
quinta-feira, 20 de agosto de 2009
O Diagrama de Classes
Neste post vamos falar sobre outro diagrama da UML - O diagrama de classes.
Sua função é proporcionar uma visão das classes que comporão um sistema, seus atributos e métodos, além do relacionamento entre as classes e como essas classes se complementam e se relacionam entre si.
Tem se também uma representação da visibilidade dos atributos e métodos que formam a classe.
É uma evolução do diagrama de entidade e relacionamento, pois além das entidades (atributos) , se representa nesse diagrama os comportamentos das classes (métodos).
Observação importante: Esse diagrama não se preocupa com a sequência em que as funcionalidades irão ocorrer, sendo está responsabilidade de outros diagramas.
Perspectivas
Um diagrama de classes pode oferecer três perspectivas, cada uma para um tipo de observador diferente. São elas:
Relacionamentos
Tem a função de representar os relacionamentos entre as classes mostrando como elas colaboram umas com as outras. Existem 6 tipos de relacionamento:
Associação Binária
Classes Associativas - Devem ser criadas quando a multiplicidade é *..* (muitos para muitos)
Agregação - Um pedido é composto por um ou mais itens. Um pedido compõe vários itens de pedido
Composição - Uma revista possui uma ou mais edições e no mínimo 6 e no máximo 10 artigos
Abaixo um diagrama para o sistema bancário:
Repare que não é necessário representar chaves primárias e nem estrangeiras nesse diagrama. Isso fica implícito.
Sua função é proporcionar uma visão das classes que comporão um sistema, seus atributos e métodos, além do relacionamento entre as classes e como essas classes se complementam e se relacionam entre si.
Tem se também uma representação da visibilidade dos atributos e métodos que formam a classe.
É uma evolução do diagrama de entidade e relacionamento, pois além das entidades (atributos) , se representa nesse diagrama os comportamentos das classes (métodos).
Observação importante: Esse diagrama não se preocupa com a sequência em que as funcionalidades irão ocorrer, sendo está responsabilidade de outros diagramas.
Perspectivas
Um diagrama de classes pode oferecer três perspectivas, cada uma para um tipo de observador diferente. São elas:
- Conceitual - Representa os conceitos do domínio em estudo.(Perspectiva destinada ao cliente)
- Especificação - Tem foco nas principais interfaces da arquitetura, nos principais métodos, e não como eles irão ser implementados (Perspectiva destinada as pessoas que não precisam saber detalhes de desenvolvimento, tais como gerentes de projeto).
- Implementação - A mais utilizada de todas, aborda vários detalhes deimplementação, tais como navegabilidade, tipo dos atributos, etc.(Perspectiva destinada ao time de desenvolvimento).
Relacionamentos
Tem a função de representar os relacionamentos entre as classes mostrando como elas colaboram umas com as outras. Existem 6 tipos de relacionamento:
- Associação (unária, binária, ternária)
- Agregação (semelhante ao relacionamento todo-parte)
- Composiçao (usado para representar um vínculo mais forte entre as entidades, ou seja um nível de dependência maior entre as classes)
- Generalização/especialização - relacionamento entre superclasses e subclasses.
- Dependência - Uma classe dpende da outra.
- Realização - utilizada para representar os relacionamentos entre interfaces e classes
Associação Binária
Classes Associativas - Devem ser criadas quando a multiplicidade é *..* (muitos para muitos)
Agregação - Um pedido é composto por um ou mais itens. Um pedido compõe vários itens de pedido
Composição - Uma revista possui uma ou mais edições e no mínimo 6 e no máximo 10 artigos
Abaixo um diagrama para o sistema bancário:
Repare que não é necessário representar chaves primárias e nem estrangeiras nesse diagrama. Isso fica implícito.
quarta-feira, 19 de agosto de 2009
A UML
A UML
Conforme mencionado em posts anteriores, a análise estruturada/essencial se utilizava dos diagramas de contextos e de fluxo para modelar conceitualmente os sistemas.
Com o surgimento da programação orientada a objetos, novos diagramas foram criados possibilitando ao arquiteto de software prover várias visões sobre os componentes dos sistemas.
A UML é uma proposta da OMG (Object Management Group) para padronização de modelos conceituais de software. Basicamente, a UML permite que desenvolvedores visualizem os produtos de seu trabalho em diagramas padronizados. Junto com uma notação gráfica, a UML também especifica significados, isto é, semântica. É uma notação independente de processos, embora o RUP (Rational Unified Process) tenha sido especificamente desenvolvido utilizando a UML. Falaremos do RUP em outra ocasião.
Até sua versão 1.x a UML provia 8 diagramas (caso de uso, classes, sequência, colaboração, gráfico de estados, atividades, componentes e implantação).
Houve um incremento de mais três diagramas na versão 2.0 e uniu-se dois diagramas totalizando assim, um total de 10 diagramas.
Esses diagramas podem ser separados em duas categorias. Estruturais ou estáticos e Comportamentais ou dinâmicos..:
* Estruturais (objetos, classes, componentes, pacotes)
* Comportamentais (Caso de uso, atividades, estado, colaboração, sequência, tempo).
A figura abaixo mostra a hirarquia entre esses diagramas.
É possível que seu navegador não suporte a exibição desta imagem. Elementos acessórios
Existem elementos acessórios que podem estar presentes em todos os diagramas definidos pela UML são eles:
* Nota - sua função é apresentar textos explicativos sobre os outros elementos presentes nos digramas;
* Pacotes - permitem organizar elementos em grupo. É muito utilizado em sistemas extensos ou que possuam subsistemas envolvidos. Os pacotes podem se relacionar (um pacote pode depender de outro para que um sistema possa funcionar);
* Estereótipos - possibilitam ao analista estender a UML. Sua função é enfatizar características diferentes para um mesmo tipo de elemento. Existem dois tipos de estereotipo (de rótulo e de gráfico). O estereotipo de rotulo enfatiza que um caso de uso se trata de um processo, diferenciando o mesmo dos demais casos de uso. Já o estereotipo gráfico serve para indicar que um objeto representa uma interface entre usuário X sistema.
Diagrama de Casos de uso
O diagrama de casos de uso corresponde a uma visão externa do sistema e representa graficamente os atores, os casos de uso, e os relacionamentos entre estes elementos. Ele tem como objetivo ilustrar em um nível alto de abstração quais elementos externos interagem com que funcionalidades do sistema, ou seja, a finalidade de um Diagrama de Caso de Uso é apresentar um tipo de diagrama de contexto que apresenta os elementos externos de um sistema e as maneiras segundo as quais eles as utilizam.
Componentes: atores, casos de uso e suas associações. A seguir, a figura mostra um exemplo desse tipo de diagrama.
Repare na simbologia utilizada. A elipse representa uma funcionalidade (um caso de uso), o boneco palito um ator e as setas ou linhas as associações de interação entre atores e casos de uso além de setas que expressam certo grau de dependência entre os casos de uso.
Existem dois tipos de grau de dependência:
* Inclusão - quando uma funcionalidade depende obrigatoriamente de outra;
* Extensão - quando uma funcionalidade usa opcionalmente uma outra funcionalidade.
Como sugestão fica aqui um curso muito bom e gratuíto disponível na Internet Entendendo casos de uso da empresa aspercom.
Nos próximos posts falarei dos demais diagramas.
Até mais!
HUGO
Conforme mencionado em posts anteriores, a análise estruturada/essencial se utilizava dos diagramas de contextos e de fluxo para modelar conceitualmente os sistemas.
Com o surgimento da programação orientada a objetos, novos diagramas foram criados possibilitando ao arquiteto de software prover várias visões sobre os componentes dos sistemas.
A UML é uma proposta da OMG (Object Management Group) para padronização de modelos conceituais de software. Basicamente, a UML permite que desenvolvedores visualizem os produtos de seu trabalho em diagramas padronizados. Junto com uma notação gráfica, a UML também especifica significados, isto é, semântica. É uma notação independente de processos, embora o RUP (Rational Unified Process) tenha sido especificamente desenvolvido utilizando a UML. Falaremos do RUP em outra ocasião.
Até sua versão 1.x a UML provia 8 diagramas (caso de uso, classes, sequência, colaboração, gráfico de estados, atividades, componentes e implantação).
Houve um incremento de mais três diagramas na versão 2.0 e uniu-se dois diagramas totalizando assim, um total de 10 diagramas.
Esses diagramas podem ser separados em duas categorias. Estruturais ou estáticos e Comportamentais ou dinâmicos..:
* Estruturais (objetos, classes, componentes, pacotes)
* Comportamentais (Caso de uso, atividades, estado, colaboração, sequência, tempo).
A figura abaixo mostra a hirarquia entre esses diagramas.
É possível que seu navegador não suporte a exibição desta imagem. Elementos acessórios
Existem elementos acessórios que podem estar presentes em todos os diagramas definidos pela UML são eles:
* Nota - sua função é apresentar textos explicativos sobre os outros elementos presentes nos digramas;
* Pacotes - permitem organizar elementos em grupo. É muito utilizado em sistemas extensos ou que possuam subsistemas envolvidos. Os pacotes podem se relacionar (um pacote pode depender de outro para que um sistema possa funcionar);
* Estereótipos - possibilitam ao analista estender a UML. Sua função é enfatizar características diferentes para um mesmo tipo de elemento. Existem dois tipos de estereotipo (de rótulo e de gráfico). O estereotipo de rotulo enfatiza que um caso de uso se trata de um processo, diferenciando o mesmo dos demais casos de uso. Já o estereotipo gráfico serve para indicar que um objeto representa uma interface entre usuário X sistema.
Diagrama de Casos de uso
O diagrama de casos de uso corresponde a uma visão externa do sistema e representa graficamente os atores, os casos de uso, e os relacionamentos entre estes elementos. Ele tem como objetivo ilustrar em um nível alto de abstração quais elementos externos interagem com que funcionalidades do sistema, ou seja, a finalidade de um Diagrama de Caso de Uso é apresentar um tipo de diagrama de contexto que apresenta os elementos externos de um sistema e as maneiras segundo as quais eles as utilizam.
Componentes: atores, casos de uso e suas associações. A seguir, a figura mostra um exemplo desse tipo de diagrama.
Repare na simbologia utilizada. A elipse representa uma funcionalidade (um caso de uso), o boneco palito um ator e as setas ou linhas as associações de interação entre atores e casos de uso além de setas que expressam certo grau de dependência entre os casos de uso.
Existem dois tipos de grau de dependência:
* Inclusão - quando uma funcionalidade depende obrigatoriamente de outra;
* Extensão - quando uma funcionalidade usa opcionalmente uma outra funcionalidade.
Como sugestão fica aqui um curso muito bom e gratuíto disponível na Internet Entendendo casos de uso da empresa aspercom.
Nos próximos posts falarei dos demais diagramas.
Até mais!
HUGO
Assinar:
Postagens (Atom)