Sem resumo de edição
Sem resumo de edição
Linha 1: Linha 1:
[[Arquivo:Exemplo.jpg]]-Ivar Jacobson:<br>
 


Bibliografia:
Bibliografia:

Edição das 01h54min de 16 de maio de 2012


Bibliografia: Mestre em Engenharia elétrica pelo Instituto de Tecnologia de Chalmers, em Gotemburgo,
Ph.D. no Royal Institute of Technology em Estocolmo. Teve o inicio do seu trabalho
na empresa Ericsson onde começou a trabalhar com orientação a objeto.
Após sua demissão começou a trabalhar com Grady Booch e Rumbaugh James.

História: No Rational, Jacobson e seus amigos, Grady Booch e James Rumbaugh , primeiro desenhou a UML ,
posteriormente desenvolvendo o Rational Unified Process.
Eles logo foram auxiliadas nos seus esforços por Ivar Jacobson, o criador do métodoorientado a
objeto de engenharia de software (OOSE). Jacobson juntou Rational em 1995,
após a sua empresa, Objectory AB, foi adquirida pela Rational.
Os três foram metodólogos coletivamente referidos como os Três Amigos.


No início da década de 90, viu-se o que ficou conhecido como a guerra dos métodos, vários "papas" da recém-definida engenharia de software diziam quem o seu método era o melhor e que iriam resolver todos os problemas. Na década de 80,surgiu a famigerada linguagem orientado a objeto. A quantidade de métodos orientados a objetos aumentou de pouco mais de 10 para mais de 50 durante o período de 1989 a 1994. Aprendendo com a experiência, novas gerações desses métodos começaram a surgir, com um claro destaque de alguns como o Booch, o OOSE (Object-Oriented Software Engineering), de Jacobson e o OMT, de Rumbaugh. Entre outros métodos importantes, encontravam-se Fusion, Shlaer-Mellor e Coad-Yourdon. Todos eram métodos completos, apesar de cada um conter pontos fortes e fracos. O OOSE de Jacobson, fornecia excelente suporte para os casos como uma maneira de controlar a captura de requisitos, a análise e o projeto em alto nível.

Infelizmente, as coisas não são tão simples assim e, em meados da década, decidiu-se que era mais prudente reunir o que hovesse de melhor em cada proposta e criar um modelo único. Foi assim que JACOBSON, Booch e Rumbaugh criaram a UML (Unified Model Language), onde se pretendia apresentar um modelo universal que servisse de sustentação ao desenvolvimento.

Ao iniciar a unificação dos três métodos, os criadores estabeleceram 3 objetivos:

1- Fazer a modelagem de sistemas, do conceito ao artefato executável, com a utilização de técnicas orientadas a objetos.

2- Incluir questões de escala, inerentes a sistemas complexos e de tarefas críticas.

3- Criar uma linguagem de modelagem a ser utilizada por seres humanos e por máquinas.

Em 1994 Booch e Rumbaugh se juntaram, na Rational focando a união dos seus métodos. Em 1995, JACOBSON se associou a Rational. Com isso o modelo UML foi evoluindo gradativamente e se espalhando pelo mundo, até chegar ao seu ápice.

Alguns conceitos sobre UML;

Classe: é uma descrição de um conjunto de objetos que compartilham os mesmos atributos, operações, relacionamentos e semântica. Uma classe é representada graficamente como um retângulo.

Relacionamentos: é uma conexão entre itens. Em uma modelagem orientada a objetos, os três relacionamentos mais importantes são as dependências, as generalizações e as associações. Um relacionamento é representado graficamente como um caminho, com tipos diferentes de linhas para diferenciar os tipos de relacionamentos.

Mecanismos: Uma NOTA é um símbolo gráfico para a representação de restrições ou de comentários anexados a um elemento ou a uma coleção de elementos. Ela é representada graficamente como um retângulo com uma dobra em um dos cantos, incluindo um comentário gráfico ou visual. Um ESTEREÓTIPO é uma extensão do vocabulário da UML, permitindo a criação de novos tipos de blocos de construção semelhantes aos existentes, mas específicos a determinado problema. Um estereótipo é representado graficamente como um nome entre ângulos, colocado acima do nome de outro elemento. Um VALOR ATRIBUÍDO é uma propriedade de um estereótipo, permitindo a criação de novas informações na especificação desse estereótipo. Um valor atribuído é representado graficamente como uma sequência de caracteres na forma "nome = valor" em uma nota anexada ao objeto. Uma RESTRIÇÃO é uma especificação textual da semântica de um elemento da UML, permitindo adicionar novas regras ou modificar as exitentes. Uma restrição é representada graficamente como uma sequência de caracteres entre chaves, colocada próxima ao elementos associado ou conectada a esse elemento ou elementos por meio de relacionamentos de dependência.

Diagramas: Um SISTEMA é uma coleção de subsistemas organizados para a realização de um objetivo e descritos por um conjunto de modelos, possivelmente sob diferentes pontos de vista. Um SUBSISTEMA é um agrupamento de elementos, alguns dos quais constituem uma especificação do comportamento proporcionado pelos outros elementos contidos. Um MODELO é uma abstração semanticamente fechada de um sistema, o que significa que representa uma simplificação autoconsistente e completa da realidade, criada com a finalidade de permitir uma melhor compreensão a respeito do sistema. No contexto da arquitetura, uma visão é uma projeção da organização e estrutura do modelo de um sistema, cujo foco está voltado para um único aspecto desse sistema. Um DIAGRAMA é a representação gráfica de um conjunto de elementos, geralmente representada como um gráfico conectado de vértices (itens) e arcos (relacionamentos). Na modelagem de sistemas reais, independentemente do domínio do problema, você criará os mesmos tipos de diagramas, pois eles representam visões de modelos comuns. Tipicamente, você visualizará as partes estáticas de um sistema, utilizando um dos seguintes diagramas:

1- Diagrama de classes;

2 - Diagrama de componentes;

3- Diagrama de estrutura composta;

4- Diagrama de objetos;

5- Diagrama de implantação;

6- Diagrama de artefatos;

Com frequência, você usará cinco diagramas adicionais para visualizar as partes dinâmicas de um sistema:

1- Diagramas de caso de uso;

2- Diagrama de sequências;

3- Diagrama de comunicação;

4- Diagrama de gráficos de estados;

5- Diagramas de atividades;

Diagrama de classes: Um DIAGRAMA DE CLASSES é um diagrama que mostra um conjunto de classes, interfaces e colaborações e seus relacionamentos. Graficamente, um diagrama de classes é uma coleção de vértices e arcos.

Referências bibliográficas:

- BOOCH, Grady. RUMBAUGH, James; JACOBSON, Ivar. UML: Guia do Usuário. 2ªed. Rio de Janeiro, 2005.

- CARDOSO, Caíque; UML na prática do problema ao sistema. 1ª ed. São Paulo, 2003.