A HISTÓRIA DA UML

HISTÓRIA DA UML

A Unified Modeling Language (UML) é uma linguagem de modelagem. A UML não é uma metodologia de desenvolvimento, o que significa que ela não diz para você o que fazer primeiro e em seguida ou como projetar seu sistema, mas ela lhe auxilia a visualizar seu desenho e a comunicação entre objetos.

Basicamente, a UML permite que desenvolvedores visualizem os produtos de seus trabalhos em diagramas padronizados. Junto com uma notação gráfica, a UML também especifica significados, isto é, semântica.

         Por volta de 1993 existiam três métodos que mais cresciam no mercado, eram eles: Booch’93 de Grady Booch, OMT-2 de James Rumbaugh e OOSE de Ivar Jacobson. Cada um deles possuía pontos fortes em algum aspecto. O OOSE possuía foco em casos de uso (use cases), OMT-2 se destaca na fase de análise de sistemas de informação e Booch’93 era mais forte na fase de projeto. O sucesso desses métodos foi, principalmente, devido ao fato de não terem tentado estender os métodos já existentes.

Em outubro de 1994, começaram os esforços para unificação dos métodos. Já em outubro de 1995, Booch e Rumbaugh lançaram um rascunho do “Método Unificado” unificando o Booch’93 e o OMT-2. Após isso, Jacobson se juntou a equipe do projeto e o “Método Unificado” passou a incorporar o OOSE. Em junho de 1996, os três amigos, como já eram conhecidos, lançaram a primeira versão com os três métodos - a versão 0.9 que foi batizada como UML.

OBJETIVOS DA UML

Os objetivos da UML são: especificação, documentação, estruturação para sub-visualização e maior visualização lógica do desenvolvimento completo de um sistema de informação. A UML é um modo de padronizar as formas de modelagem.

DIAGRAMAS DA UML

Um diagrama é uma representação visual estruturada e simplificada de um determinado conceito, ideia, etc. Os diagramas estão divididos em: Diagramas estruturais, comportamentais e de interações.

• Estruturais

• Classes
• Objetos
• Componentes
• Instalação
• Pacotes
• Estrutura

• Comportamentais

• Caso de uso
• Transição de estados
• Atividade

• Interação

• Sequência
• Interatividade
• Colaboração ou comunicação
• Tempo

DIAGRAMA DE CASOS DE USO (USE CASES)

        O diagrama é usado para descrever o que um novo sistema deverá fazer ou para descrever um sistema já existente, podendo mostrar como o sistema se comporta em várias situações que podem ocorrer durante sua operação. O diagrama de Casos de uso deve representar todas as funcionalidades que o software deverá possuir.

        Para construir diagramas de casos de uso, os itens a seguir devem ser considerados:

• Captar (entender) as funcionalidades necessárias para a resolução dos problemas existentes, sob a ótica do cliente ou usuários;
• Mostrar uma visão funcional coesa sobre tudo o que o software deverá fazer;
• Deverão ser aplicados testes de validação;
• Propiciar facilidades para transformação dos requisitos funcionais em classes e operações reais do software.

As etapas a seguir constituem um roteiro que pode ser seguido na elaboração do diagrama de casos de uso:

• Definir o sistema e entender de forma macro de seus objetivos;
• Identificar os possíveis atores (quem exerce alguma atividade pertinente ao sistema) e os casos de usos existentes (atividades que envolvem os atores identificados);
• Detalhar várias situações de funcionalidade para os casos de uso;
• Estabelecer os relacionamentos entre os elementos;
• Checar o modelo com usuários e cliente.

ATORES

        Pessoas, departamentos e mesmo equipamentos que possam de alguma forma interagir com o sistema que esta sendo modelado são considerados uma entidade externa ao sistema. Os use cases são desenvolvidos de acordo com os eventos que ocorrem entre as entidades externas e o sistema.

[pic 1][pic 2]

        A UML não se limita ao ciclo de desenvolvimento de determinado software. Porém para ter o máximo proveito da UML, será preciso levar em conta um processo com as seguintes características:

• Orientado a caso de uso = significa que esses casos são utilizados como o principal artefato para o estabelecimento do comportamento desejado do sistema, para a verificação e a validação da arquitetura do sistema, para a realização de testes e para a comunicação entre os participantes do projeto.

• Centrado na arquitetura = significa que a arquitetura do sistema é utilizada como principal artefato para a conceituação, a construção, o gerenciamento e a evolução do sistema em desenvolvimento.

• Iterativo e incremental = é aquele que envolve o gerenciamento de seqüências de versões executáveis. Um processo incremental é aquele que envolve a integração contínua da arquitetura do sistema para a produção dessas versões, de maneira que cada nova versão incorpora os aprimoramentos incrementais em relação às demais. Em conjunto, um processo iterativo e incremental é orientado a riscos, ou seja, cada nova versão tem como foco atacar e reduzir os riscos mais significativos para o sucesso do projeto. 

RESUMO

Introdução: UML (Unified Modeling Language) é a sucessora da onda de métodos de análise e projeto orientado a objetos(OOA & D) que surgiu no final dos anos oitenta e no início dos anos noventa. UML é chamada de linguagem de modelagem, não é um método. A maioria dos métodos consiste pelo menos em principio de uma linguagem de modelagem e de um processo, a linguagem de modelagem é a notação (principalmente gráfica) utilizada por métodos para expressar projeto, é a sugestão de quais passos devem ser seguidos. A linguagem de modelagem é a parte mais importante do método. Ela é certamente a parte-chave para a comunicação. Para poder desencadear uma discussão sobre um determinado projeto, tem que se compreender a linguagem de modelagem, não o processo utilizado para desenvolver o projeto Objetivo: Abordagem do processo, de modo a colocar as técnicas de linguagem de modelagem em contexto. Desenvolvimento: UML é uma linguagem de modelagem, não uma metodologia. UML não tem noções do processo, que é uma parte importante de uma metodologia. Um processo de desenvolvimento interativo e incremental, no qual o software não é implementado em um instante no fim do projeto, mas é, ao contrario, desenvolvido e implementado em partes. A fase de construção consiste de várias iterações, nas quais cada iteração constrói software de qualidade de produção, testado e integrado, que satisfaz um subconjunto de requisitos de projeto. A entrega pode ser externa, para usuários iniciais, ou puramente interna. Cada iteração contém todas as fases usuais do ciclo de vida da análise do projeto, da implementação e do teste. Teoricamente você pode começar pelo inicio, escolhendo alguma funcionalidade e construindo, escolhendo outra funcionalidade, e assim por diante. Entretanto, vale a pena passar algum tempo planejando. As duas primeiras fases são a concepção e a elaboração. Durante a concepção, é estabelecido a logica do domínio da aplicação para o projeto e decide o escopo do projeto. É aqui que você obtem o comprometimento do patrocinador do projeto para seguir adiante. Na elaboração é feito a coleta mais detalhada de requisitos, é feito uma analise e um projeto de alto nível para estabelecer uma arquitetura básica, e cria-se um plano para a construção do sistema. Mesmo com este tipo de processo iterativo, algum trabalho tem que ser deixado para ser feito no fim, na fase de transição. Requisitos são importantes e são onde as técnicas de UML podem ser postas mais obviamente em uso. O ponto inicial são os casos de uso. Casos de uso dirigem todo o processo de desenvolvimento. Além de Riscos de Requisitos, também temos que nos preocupar com Riscos Tecnológicos, Riscos de Especializações e Riscos Políticos. A técnica de diagrama de classes tornou-se realmente central nas metodologias orientadas a objetos. Praticamente cada metodologia incluiu algumas variações nesta técnica, o diagrama não é somente usado, mas também o receptáculo para o maior escopo de conceitos de modelagem, embora os elementos básicos sejam necessários para todos, os conceitos avançados são utilizados com menos frequência. Um diagrama de classes descreve os tipos de objetos no sistema e os vários tipos de relacionamento estático que existem entre eles. Há dois tipos principais de relacionamento estáticos, sendo eles, associações (por exemplo, um cliente pode alugar vários vídeos) e subtipos (uma enfermeira é um tipo de pessoa). A técnica de diagrama de classes, entretanto, promoveu a criação de dezenas de notações para conceitos adicionais por exemplo os Estereótipos onde são o núcleo do mecanismo de extensão de UML, se deseja usar uma construção de modelagem que não existe em UML mas é semelhante a algo que já existe, você trata a sua construção como um estereótipo da construção UML, por exemplo a interface de UML é uma classe que tem somente operações publicas sem métodos nem atributos, isso corresponde a interfaces em Java, COM, CORBA. Conclusão: O UML sem duvidas é um fator de sucesso na qualidade de desenvolvimento de aplicativos. O mapeamento direto dos modelos para as linguagens de programação orientadas a objeto e vice-versa também é um dos grandes ganhos da UML. Esses são alguns dos inúmeros benefícios que a UML nos fornece, sem que percamos a liberdade de criar, de tal forma que garante que os sistemas sejam criados, testados e corrigidos, evitando riscos em fase de projeto.