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
Nenhum comentário:
Postar um comentário