Introdução:
UML, ou Unified Modeling Language é a última buzz-word a chegar por estas plagas. O seu charme é a promessa de ser a última e definitiva metodologia de modelagem de sistemas. Outro apelo, é integrar todas as demais expressões (métodos empíricos todos eles) que atestam sua origem "nobre": orientação a objeto, padrões, GRASP. Sendo posterior a todas elas, promete ser uma maneira de se atualizar sobre todas elas de uma só vez.
Muitos dos exemplos, foram retirados de telas criadas com Rational Rose 98, uma ferramenta CASE da Rational. Convém mencionar que esta ferramenta não implementa inteiramente o UML, havendo diferenças de notação. Sempre que for o caso, a origem da imagem será indicada.
Perto do final do semestre descobrimos em [HAR97] referência a outra ferramenta CASE, a SA/Object, disponível em www.popkin.com, mas não conseguimos avalia-la ainda.
UML pretende:
1- Modelar sistemas, sejam eles empresas ou softwares, usando conceitos de orientação a objeto.
2- Estabelecer um acoplamento explícito tanto entre artefatos conceituais como executaveis (reais).
3- Encaminhar as questões de escala (num intendi...) inerentes em sistemas complexos e/ou de missão crítica.
4- Criar uma linguagem de modelagem usável por ambos: humanos e máquinas.
Método é uma maneira explícita de estruturar ações e pensamentos. Um método diz o que fazer, como, quando e porque. Métodos contém modelos e estes modelos são usados para descrever algo e comunicar os resultados do uso do método.
Um modelo é descrito em termos de uma linguagem de modelagem. Uma linguagem é composta por símbolos que compõem uma notação e regras sobre seu uso. Estas regras correspondem a três planos de entendimento:
- intaxe - Diz como devem parecer e como devem ser combinados os símbolos utilizados
- Semântica - Diz o que cada símbolo significa. São (a semântica e a sintaxe) referidos à própria relação entre os símbolos (regras internas )
- Pragmática - Define a intenção dos símbolos, de modo que o propósito do modelo é expresso e torna-se inteligível para outras pessoas. É uma referência externa/cultural à relação representada, é funcional e finalística
UML se vale de use cases; diagramas para capturar o requisitos do usuário. Através dos use cases, atores externos são modelados em suas interações com o sistema. Semelhante ao DFD contextual, mas usando bonequinhos de palitos para representar os atores/agentes externos. Não é tão simples assim, mas a semelhança é óbvia.
2) Análise:
Nesta fase nos preocupamos com as abstrações primárias (classes e objetos) e mecanismos no domínio do problema. As classes são identificadas e representadas no diagrama de classes. Também são representadas as relações e colaborações entre as classes, de modo que as funcionalidades descritas nos use cases sejam alcançadas. Também se vale dos diagramas dinâmicos (estado, seqüência, colaboração e de atividades).
Na análise, somente classe do domínio do problema são modeladas. Aquelas que definem detalhes e soluções da implementação de software (interface, comunicação com banco de dados, concorrência, etc..) ficam para outra fase.
3) Projeto:
Na fase de projeto (design), o resultado da análise é expandido para uma solução técnica. Novas classes são acrescentadas para prover uma infraestrutura técnica: interface, manipulação de dados em um banco de dados, salvamento de arquivos, comunicação com outros sistemas e dispositivos. Nesta etapa as classes da análise são "embutidas" (embedded) nesta infraestrutura técnica, sendo possível alterar ambas independentemente.
O resultado é uma descrição detalhada para a fase seguinte, de programação.
4) Implementação:
As classes são convertidas para código real em uma linguagem OO (procedural não é recomendado).
5) Teste:
Idêntico a qualquer outro método de modelagem. Dividida em testes de unidades, testes de integração, teste de sistema e testes de aceitação.
São cinco visões (ou vistas, tradução para view) e nove diagramas.
| Visão dos Uses Cases | É central no UML, e define as funcionalidades do sistema e seu conteúdo define o desenvolvimento subseqënte das outras visões. É usado para validar o sistema junto ao usuário (é assim que você quer/queria ?). Usa o diagrama de use case. |
| Visão Lógica | Descreve como a funcionalidade do sistema é alcançada. Em contraste com os use cases, a visão lógica vê o sistema internamente. descre tanto a estrutura estática como a colaboração dinâmica que ocorre quando os objetos se comunicam para prover alguma função. Usa para a estrutura estática os diagramas de classes e objetos. Para a modelagem dinâmica usa os diagramas dinâmicos: estado, colaboração, seqüência e atividade. |
| Visão dos Componentes | É uma descrição dos módulos da implementação com suas estruturas e dependências. Consiste no diagrama de componentes e outros diagramas de caráter administrativo, tasi como relatório de progresso. |
| Visão Concorrente | Lida com a divisão do sistema em processos e processadores. É um aspecto não-funcional do sistema, que visa desempenho, eficiencia no uso dos recursos e manejo de eventos de eventos assíncronos do ambiente. |
| Visão do Desenvolvimento | Mostra o desenvolvimento físico do sistema, com computadores, sites, nós e como eles se conectam. Esta visão inclui um mapeamento que descreve como os componentes da visão lógica tornam-se componentes reais, e qual a sua localização física subseqüente. |
Em amarelo, os diagramas estáticos. Em verde os dinãmicos.
| Diagrama de Use Cases | Mostra atores externos e suas conecções com os use cases do sistema. Cada use case é a descrição de uma funcionalidade (um uso específico do sistema) que o sistema oferece. |
| Diagrama de Classes | Um diagrama de classes mostra a estrutura estática das classes. As classes são "as coisas" com as quais o sistema lida. São representadas por retângulos, com o nome da classe em negrito. Classes podem se relacionar umas com as outras de várias maneiras: associação, dependência, especialização ou empacotamento |
| Diagrama de Objetos | O diagrama de objetos se parece muito com o diagrama de classes, apenas mostra as classes instanciadas como objetos, como um snapshot possível da execução do sistema. A mesma notação é adotada, apenas o nome do objeto é escrito sublinhado. Diagrama de objetos é utilizado em diagramas de colaboração |
| Diagrama de Estados verdes:diagramas dinâmicos | O diagrama de estados é tipicamente um complemento do diagrama de classes. Mostra todos os possíveis estados de uma classe e quais eventos causam a mudança de estados. Mudanças de estado são chamadas de transições Ele é desenhado apenas para aquelas classes que tem um número bem definido de estados e cujo comportamento é mudado pelas transições. Pode também ser desenhado para o sistema inteiro. |
| Diagrama de Seqüência | O diagrama de seqüência mostra uma colaboração dinâmica entre objetos. O aspecto mais importante é mostrar uma seqüência de mensagens trocadas entre os objetos. Objetos são descritos como linhas verticais e mensagens como linhas horizontais entre os objetos. A mensagen bifuracada (uma origem, vários destinos aparece em [ERI97], mas o Rose98 não foi capaz de representá-la. |
| Diagrama de Colaboração | Mostra uma colaboração dinâmica, exatamente como o diagrama de seqüência. Freqüentemente é uma alternativa ao diagrama de seqüência, quando se deseja mostrar os objetos e seus relacionamentos (chamado de contexto). Se o tempo é mais importante, escolhe-se o de seqüencia e caso o contexto seja mais importante, escolha o de colaboração. |
| Diagrama de Atividades | Mostra uma seqüência de atividades como um grafo, o que permite representar decisões (bifurcações) graficamente, bem como estado inicial e final. |
| Diagrama de Componente | Traz uma visão interna da estrutura física do código, em termos de componentes. Um componente pode ser um código fonte, um componente binário ou um executável. É um mapeamento entre a visão lógica e a visão de componentes. Dependências entre componentes são mostradas, tornando fácil analizar alterações. |
| Diagrama de Desenvolvimento/Entrega | Mostra a arquitetura física - hardware e software no sistema. Representa-se os computadores e dispositivos reais e as conecções entre eles. |
São os conceitos (o vocabulário) utilizados nos diagramas. Um elemento de modelo tem uma representação gráfica que o representa nos diagramas.
São exemplos de elementos: classe, objeto, estado, caso de uso, nó, interface, package, nota, componentes.
Também os relacionamentos são considerados elementos: associação, generalização, dependência e agregação.
Detalhes gráficos (chamados em inglês de adornos) podem ser acrescentados aos elementos dos diagramas, de modo a acrescentar significado semântico. Por exemplo, se um elemento representa um tipo, usa-se negrito, se representa um objeto aparece sublinhado. No caso de um nodo, no diagrama de desenvolvimento, pode-se escreve "impressora" ou "HP 5J - Sala dos professores".
Notas:
Uma nota pode ser acrescentada a qualquer diagrama, para lembrar de algo que a linguagem não possa representar. Como a UML e todas as suas predecessoras são abstrações limitadas, muitos detalhes do problema ficam de fora e precisam encontrar seu caminho dentro do projeto acomodadas, por exemplo, em notas acompanhado os diagramas.
Especificações:
Os elementos de modelo têem propriedades que guardam valores sobre os elementos. Uma propriedade é definida por um valor etiquetado . Existe um certo número de propriedades pré-especificadas: documentação, responsabilidade, persistencia e concorrência.
Tipicamente, é necessário acrescentar algum texto descritivo, existindo uma janela para este fim para cada elemento de modelo no Rose98.
UML pode ser extendida para cumprir funções específicas. Em [ERI97] encontramos três exemplos destas extensões, que enriquecem a notação do Rose98:
Esteriótipos: é um mecanismo de extensão que traz uma semântica. Baseia-s em todos os elementos básicos (classe, nós, componentes e notas), bem como nos relacionamentos (associação, generalização e dependência).
É descrito colocando o seu nome entre << >> (referidos como guillemets, ou angle brackets), ou lhe atribuindo um ícone específico, como o do ator.
Valores etiquetados: elementos podem ter propriedades que contém pares de nomes-valores, com informação sobre eles. São valores marcados ou valores etiquetados. Qualquer informação pode ser acrescentada nestas etiquetas: informações administrativas, informações específicas do problema, dados para outras ferramentas.
Restrições: Um vínculo restritivo é uma limitação em um elemento, que resulta em limitação na sua associação. Por exemplo: a classe "grupo da terceira idade" relaciona-se com a classe "pessoa", com a restrição de que {idade > 60} (ou 110, para moradores do Caúcaso), ou seja, somente pessoas com mais de 60 anos podem participar da associação (ou funcionários-gerentes, outro exemplo).
Postagens
Nenhum comentário:
Postar um comentário