História da UML e Principais Métodos

Prévia do material em texto

ÍNDICE 
 
1. Introdução .......................................................................................................................... 4 
2. O que é a UML .................................................................................................................. 5 
2.1. História ............................................................................................................. 6 
3. Principais Metodologias ..................................................................................................... 8 
3.1. Método Booch .................................................................................................. 8 
3.1.1. Diagramas de classe ................................................................................. 9 
3.1.2. Diagramas de objetos ................................................................................ 9 
3.1.3. Diagramas de transição de estados ........................................................... 9 
3.1.4. Diagrama de módulos ................................................................................ 9 
3.1.5. Diagrama de processos ........................................................................... 10 
3.1.6. Diagramas de interação ........................................................................... 10 
3.2. Método Jacobson ........................................................................................... 10 
3.2.1. Análise .................................................................................................... 11 
3.2.2. Implementação ........................................................................................ 11 
3.2.3. Teste ....................................................................................................... 12 
3.3. Método Yourdon ............................................................................................ 12 
3.3.1. Modelo Essencial da Empresa ................................................................ 13 
3.3.2. Modelo Essencial do Sistema .................................................................. 13 
3.4. Método de coleta de dados ............................................................................ 13 
3. Conclusão ........................................................................................................................ 17 
4. Referências Bibliográficas ................................................................................................ 18 
5. Anexos ............................................................................................................................. 20 
 
 
4 
 
1. Introdução 
 
Em meados de 1970, surgiram as linguagens de programação 
orientadas a objetos. A partir delas foram criados modelos para a elaboração 
da estrutura dos softwares que viriam a ser desenvolvidos com essas 
linguagens, e isso contribuiu muito para análise dos mesmos e criação com 
maior qualificação. Modelos se reuniram para padronizar e formar a UML para 
ajudar no entendimento desses sistemas, além de vários outros métodos para 
desenvolvimento de aplicações. 
5 
 
 
2. O que é a UML 
 
A UML - Linguagem de Modelagem Unificada (Unified Modeling Language) é 
uma linguagem visual para a elaboração da estrutura de projetos de software por meio 
do parâmetro de orientação a objetos. A UML disponibiliza, através de conceitos, 
objetos, símbolos e diagramas, uma forma simples, mas objetiva e funcional, de 
documentação e entendimento de um sistema para auxiliar os analistas de software a 
definir as características do software, tais como seus requisitos, seu comportamento, 
sua estrutura lógica, a dinâmica de seus processos e até mesmo suas necessidades 
físicas em relação ao equipamento sobre o qual o sistema deverá ser implantado. 
Todas essas características são definidas por meio da UML antes do software 
começar a ser realmente desenvolvido. 
Por ser de modelagem, é independente das linguagens de programação, das 
ferramentas CASE, assim como o processo de desenvolvimento. Um princípio básico 
no esforço de definição do UML foi a simplicidade e a coerência na unificação de 
diferentes elementos existentes em vários métodos, entre outros Booch, OMT e 
OOSE, e introdução de novos elementos quando necessários. 
É promovida pelo Object Management Group (OMG), com contribuições e 
direitos de autoria das seguintes empresas: Hewlett-Packard, IBM, ICON Computing, 
i-Logix, IntelliCorp, Electronic Data Services, Microsoft, ObjecTime, Oracle, Platinum, 
Ptech, Rational, Reich, Softeam, Sterling, Taskon A/S e Unisys. 
A maioria dos problemas encontrados em sistemas orientados a objetos tem 
sua origem na construção do modelo, no desenho do sistema. Muitas vezes as 
empresas e profissionais não dão muita ênfase à essa fase do projeto, e acabam 
cometendo diversos erros de análise e modelagem, mas a questão é muito mais 
ampla, envolvendo fatores extremamente complexos, como levantamento e análise 
de requisitos, prototipação, tamanho do projeto, complexidade, prazos, custos, 
documentação, manutenção e reusabilidade. 
 
6 
 
2.1. História 
 
As linguagens de modelagem orientadas a objetos surgiram entre a metade da 
década de 1970 e o final da década de 1980, à medida que as pessoas envolvidas 
com metodologia, diante de um novo gênero de linguagens de programação 
orientadas a objeto e de aplicações cada vez mais complexas, começaram a 
experimentar métodos alternativos de análise e projeto. 
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. Muitos usuários desses métodos 
tiveram dificuldades para encontrar uma linguagem de modelagem capaz de atender 
inteiramente às suas necessidades. 
Houve métodos importantes como Fusion, Shlaer-Mellor e Coad-Yourdon, mas 
os que mais se destacaram foram os que formaram a UML, que surgiu da união de 
três metodologias de modelagem que cresciam no mercado: 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, 
OMT-
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. Seus métodos já convergiam de maneira 
independente, então seria mais produtivo continuar de forma conjunta, o que começou 
a ser feito por volta de 1994. A notação definida para a UML é uma união das diversas 
notações preexistentes, com alguns elementos removidos e outros adicionados com 
o objetivo de torná-la mais expressiva. 
Em outubro de 1995, o esboço da versão 0.8 foi lançada 
e o OMT-2 como Método Unificado (Unified Method). Após isso, Jacobson que 
trabalhava na General Eletric ingressou na Rational Software e se juntou a equipe e a 
versão passou a incorporar o OOSE, com isso, em junho de 1996 foi lançada a versão 
0.9 da UML, o que fez muitas empresas ficarem ineressadas. 
Em janeiro de 1997 foi liberada a versão 1.0 da UML com a participação das 
empresas: Rational Software; Digital; Hewlett-Packard; I-Logix; Intelicorp; IBM; Icon 
Computing; MCI SystemHouse; Microsoft; Oracle; Texas Instruments e Unysis, que 
7 
 
foi adotada como padrão segundo a OMG (Object Management Group) em novembro 
de 1997. 
A versão 1.1 foi entregue a OMG em julho de 1997. Em setembro do mesmo 
ano, essa versão foi aceita pela ADTF (Analysis and Design Task Force) e pelo 
Architecture Board do OMG e, posteriormente submetida a votação de todos os 
membros da OMG. A versão 1.1 foi adotada pela OMG em 14 de novembro de 1997. 
A manutenção da UML foi então assumida pela RTF (Revision Task Force) do 
OMG, sob a responsabilidade de Cris Kobryn. A RTF lançou uma revisão editorial, a 
UML 1.2., em junho de 1998. No final do mesmo ano, a RTF lançou a UML 1.3, em 
2001 foi lançada a versão 1.5 e em 2003 a 2.0. Atualmente,a UML está na versão 
2.5.1, tendo sido lançada em dezembro de 2017 segundo o site da OMG. 
A Figura 1.1 e 1.2 dão uma visão do enquadramento histórico relativamente ao 
contexto das linguagens de modelação de software orientado por objetos e, em 
particular, do UML. 
 
8 
 
3. Principais Metodologias 
 
Ao longo das décadas de 1980 e de 1990 surgiram inúmeras propostas de 
metodologias à medida que a programação orientada a objetos foi se popularizando 
e há uma grande diversidade de ideias entre esses métodos. Assim são apresentados 
os seguintes: 
3.1. Método Booch 
O método de diagramas de Booch foi projetado por Grady Booch quando 
trabalhava na Rational Software e é um método para desenvolvimento de software 
orientado a objetos composto de uma linguagem de modelagem de objetos, um 
processo de desenvolvimento e um conjunto de práticas recomendadas. Foi publicado 
em 1992 e revisado em 1994. Os aspectos metodológicos do método de Booch foram 
incorporados em várias metodologias e processos. 
Nele são definidos diferentes modelos e símbolos para descrever o sistema, 
mas nem sempre todos serão utilizados. A análise vai se refinando em várias etapas, 
e quando puder gerar código e o documentar, adicionando vários símbolos de design. 
Também abrange as fases de análise e design de um sistema orientado a 
objetos e o desenvolvimento iterativo e incremental, que são nomeados macro e micro 
processo. São eles: 
Processo macro 
 Estabelece requisitos fundamentais (conceituação). 
 Desenvolve um modelo do comportamento desejado (análise). 
 Cria uma arquitetura (design). 
 Evolui a implementação (evolução). 
 Gerencia a evolução pós-entrega (manutenção). 
Micro processo 
 Identifica as classes e objetos em um determinado nível de abstração. 
 Identifica a semântica dessas classes e objetos. 
 Identifica os relacionamentos entre essas classes e objetos. 
 Especifica a interface e, em seguida, a implementação dessas classes e 
objetos. 
9 
 
Além desses processos, são definidos seis tipos de diagramas nesse método: 
3.1.1. Diagramas de classe 
Neste tipo de diagramas são mostradas as classes com suas relações e se 
constrói a arquitetura e o modelo estático. 
O gráfico correspondente a uma classe na notação Booch é um tipo de nuvem 
pontilhada em cujo interior o nome da mesma é escrito, separado por uma linha de 
seus atributos (estado) e métodos (comportamento). Um exemplo desse gráfico pode 
ser visualizado na figura 2. Cada classe está associada a um nome que, em geral, 
deve ser exclusivo. Nem todos os métodos e atributos são sempre especificados. 
3.1.2. Diagramas de objetos 
Serve para mostrar a existência de objetos e seus relacionamentos no design 
lógico de um sistema, também rastreia a execução de um cenário e ajuda a descrever 
o comportamento dinâmico. 
3.1.3. Diagramas de transição de estados 
O diagrama de transição de estado (DTE) enfatiza o comportamento 
dependente do tempo do sistema. Um diagrama de transição de estado descreve um 
conjunto de mudanças que podem ocorrer em uma entidade, sendo mais voltados 
para sistemas de tempo real. 
Exemplos desses sistemas são controle de processos, sistemas de comutação 
telefônica, sistemas de captura de dados de alta velocidade e sistemas de controle e 
comando militares. 
3.1.4. Diagrama de módulos 
O diagrama do módulo mostra a atribuição de classes e objetos ou módulos na 
alocação física de um sistema. Um diagrama de módulo único representa uma visão 
da estrutura dos módulos de um sistema e suas dependências. 
Em C ++, os módulos são arquivos. O padrão alocaria cada classe para um 
arquivo separado. Se existem diferentes classes em um arquivo, esse diagrama é 
recomendado. 
O programa principal identifica o arquivo que contém a raiz do programa e a 
especificação e corpo identificam os arquivos que contêm a declaração e a definição 
10 
 
dos objetos ou procedimentos ou funções necessárias para a operação correta do 
aplicativo. 
3.1.5. Diagrama de processos 
É uma representação gráfica dos passos que são seguidos em toda uma 
sequência de atividades, dentro de um processo ou procedimento, identificando-os 
por símbolos de acordo com sua natureza, em outras palavras, mostra a sequência 
cronológica das operações de um sistema. Também inclui todas as informações 
consideradas necessárias para a análise, como distâncias percorridas, quantidade 
considerada e tempo necessário. 
Para fins analíticos e como uma ajuda para descobrir e eliminar ineficiências, é 
conveniente classificar as ações que ocorrem durante um dado processo em cinco 
classificações. Estes são conhecidos sob os termos de operações, transporte, 
inspeções, atrasos ou atrasos e armazenamento. 
3.1.6. Diagramas de interação 
Diagramas de interação mostram uma interação, que consiste em um conjunto 
de objetos e seus relacionamentos, incluindo as mensagens que podem ser feitas 
entre eles. Eles são importantes para modelar os aspectos dinâmicos de um sistema 
e para construir sistemas executáveis por meio de engenharia avançada e engenharia 
reversa. 
 
3.2. Método Jacobson 
O método OOSE (Object-Oriented Software Engineering - Engenharia de 
Software Orientada a Objeto) foi desenvolvido por Ivar Jacobson em 1992 e se 
caracteriza principalmente por utilizar casos de uso para descrever o sistema, também 
descrita em como uma abordagem orientada a cenários. É um dos precursores da 
UML, como Booch e OMT. 
A ferramenta Objectory foi criada pela equipe da Objectory AB para 
implementar a metodologia OOSE. Esta foi a pioneira, porém após o grande sucesso, 
outras ferramentas que suportavam esse método surgiram. 
A Objectory AB foi fundida com a Rational e com isso a notação, metodologia 
e ferramentas da OOSE foram substituídas pelas usadas pela Rational. Com o 
11 
 
desenvolvimento da UML e da metodologia RUP (Rational Unified Process - Processo 
Unificado Racional), o OOSE foi se tornando obsoleta, pois o RUP já havia integrado 
os principais conceitos. 
O desenvolvimento do projeto se divide em 3 processos: análise, 
implementação e teste. 
3.2.1. Análise 
Nesse processo se inclui a análise de requisitos e a de robustez. Como a base 
desse modelo são os requisitos do cliente, ou do usuário final, é extremamente 
importante o entendimento (por parte do analista) dessas exigências. Para isso, faz-
se uso do modelo de Casos de Uso (Use Cases) com as descrições de interface e o 
modelo dos objetos do domínio em questão. 
Após ter desenvolvido o modelo de requisitos, e o mesmo ter sido aprovado 
pelo cliente, se inicia a criação e estruturação do sistema. Como o modelo gerado é 
totalmente orientado a aplicação, cria-se então um modelo conceitual de configuração 
do sistema, criando uma base para a sua futura construção. Esse processo é retratado 
na figura 3. 
Há também uma fase de projeto, que realiza o refinamento dos casos de uso 
da análise, e faz os diagramas com as especificações necessárias para a fase de 
implementação. 
3.2.2. Implementação 
Essa parte é composta pelo desenho e construção, onde há o refinamento e 
formalização do processo anterior e se considera o ambiente de implementação. Nele 
é definido as interfaces dos objetos e a semântica das operações, além da base de 
dados e a linguagem de programação que será utilizada. 
Após isso, é preciso descrever como os packages (onde os objetos estão 
agrupados) e os design objects irão se comunicar. Como tem uma descrição bem 
simplificada, os termos se tornam mais fáceis para compreensão, já que não 
dependem de uma linguagem de programação. O processo é mostrado na figura 4. 
12 
 
3.2.3. Teste 
Nessa fase deve ser realizada uma verificação do sistema que já foi construído. 
O objetivo desse processo é a integração de diferentes classes criadas pela utilização 
de Casos de Uso para verificar e validar a consistência do sistema. 
 
3.3. Método Yourdon 
Nosanos 80, Edward Yourdon desenvolveu o método estruturado Yourdon 
(YSM Yourdon Systems Method) em SSADM baseado na estruturação funcional. O 
método suporta duas fases de design distintas: análise e design. 
O método usa técnicas voltadas aos diagramas de fluxo de dados e modelos 
entidade-relacionamento. Requer ao analista primeiramente desenhar o diagrama de 
contexto e então fazer uma lista dos eventos para que o sistema proposto deve 
responder. Em seguida, a documentação é concluída usando técnicas tradicionais 
como modelagem de entidade, normalização, entre outros. 
Há um conjunto definido de ferramentas de desenvolvimento, procedimentos, 
modelos e técnicas estruturadas para construir predominantemente modelos de 
sistema gráfico. 
Dois modelos principais são feitos em YSM: o modelo corporativo e o modelo 
de sistema essencial. Para estes, provavelmente haverá outros modelos: o essencial 
modelo e modelo de implementação. Um modelo essencial mostra a política enquanto 
um modelo de implementação descreve considerações tecnológicas. 
O YSM inclui três etapas distintas: o estudo de viabilidade, modelagem 
essencial e modelagem de implementação. 
 Estudo de viabilidade: analisa o sistema atual e seu ambiente; 
 Modelagem essencial: visa descrever a essência de um sistema de 
software em termos de como o sistema necessário deve se comportar e quais dados 
devem ser armazenados para permitir que isso aconteça; 
 Modelagem de implementação: visa incorporar os recursos 
encontrados na declaração de requisitos do cliente usando o modelo essencial e 
dependerá do uso apropriado da tecnologia disponível. 
13 
 
Oferece também uma série de modelos: 
 Diagramas de fluxo de dados 
 Modelos de relacionamento de entidade 
 Diagramas de transição de estado 
 Mini-especificações 
 
3.3.1. Modelo Essencial da Empresa 
Este modelo usa algumas das ferramentas empregadas nos modelos 
essenciais do sistema (por exemplo, modelos E-R). Atualmente, este modelo 
compreende dois aspectos. 
1. Aspecto da informação empresarial: descreve as informações utilizadas pela 
empresa. 
2. Aspecto de desempenho da empresa: aqui descrevemos frequências de 
eventos e o número de ocorrências de componentes do aspecto da informação. 
Planejamento estratégico e iniciação de projetos de desenvolvimento de 
sistemas precisa deste modelo, possibilita o possível impacto sobre outros sistemas 
dentro da empresa para serem visualizados e as mais rentáveis soluções a serem 
identificadas. 
3.3.2. Modelo Essencial do Sistema 
O Modelo Essencial do Sistema existe para representar a política subjacente 
do sistema. Esta política é aquela que deve ser executada pelo sistema 
independentemente da implementação escolhida. Assim, este modelo é efetivamente 
uma declaração de requisitos para o sistema. É suposto se concentrar no assunto do 
mundo real do sistema e, como tal, deve desconsiderar questões tecnológicas. É 
possível pensar nisso como um modelo lógico em vez de um modelo físico. 
 
3.4. Método de coleta de dados 
Coletar dados é pesquisar, juntar documentos e provas, pesquisar informações 
sobre um tema e agrupá-las para facilitar uma análise. Esse método ajuda para avaliar 
fatos ou fenômenos que estão ocorrendo, sendo esse o primeiro passo para a 
14 
 
elaboração e execução de um trabalho. Sem a coleta de dados, o estudo da realidade 
e de suas leis seria reduzido a simples conjectura e adivinhação. 
A coleta de dados possibilita meios diretos para estudar uma ampla variedade 
de fenômenos e permite a análise sobre um conjunto de atitudes comportamentais
Para a coleta desses dados é recomendável a busca de acordo com os seguintes 
tópicos: 
Utilização de documentos 
Esta pode ser feita através de jornais, revistas, arquivos históricos, livros, dados 
estatísticos e biografias. Essas fontes na maioria das vezes auxiliam para não haver 
perda de tempo na busca por materiais em campo e é muito necessária se outras 
opções não forem viáveis. 
Entrevista 
É um meio muito utilizado em pesquisas de mercado e de opinião pública. 
Atores citam a entrevista como um método fundamental e foi muito importante para o 
desenvolvimento das ciências sociais nas últimas décadas. É uma técnica muito 
eficiente quando se precisa de informações mais pessoais, pois abrange diversos 
aspectos da vida social e os dados podem ser classificados e quantificados. Há 
desvantagens, como a probabilidade do fornecimento de respostas falsas, a influência 
da presença de um entrevistador e custos para treiná-los pois há a necessidade de 
ser cordial com o entrevistado. 
Podem ser classificadas em quatro tipos: 
 Entrevista informal: se assemelha a uma conversa, mas tem objetivo de 
coletar dados; 
 Entrevista focalizada: é uma conversação com um tema específico e 
com o mesmo intuito da anterior; 
 Entrevista por pautas: há uma estruturação e elas são guiadas pelo 
entrevistador 
 Entrevista estruturada: parte de um conjunto de perguntas fixas sobre 
algum assunto 
Questionários 
15 
 
É o método mais utilizado para pesquisa qualitativa, principalmente as de 
grande escala, como de opinião pública ou de consumidores. Atingem um grande 
número de indivíduos e sem gasto com entrevistadores, pois podem ser 
disponibilizados quando o pesquisado preferir e ainda por anonimato. Algumas 
controvérsias são as pessoas analfabetas que ficam incapazes de realizar o 
questionário, e também não há como tirar dúvidas. 
Um questionário não precisa ser muito longo para o público não perder o 
interesse e deve passar por um pré-teste para assegurar que foi bem redigido. 
Formulários 
São um meio-termo entre entrevista e questionário, mas a semelhança é que 
também é apresentado por escrito e o pesquisador assinala as respostas, que são 
dadas oralmente pela pessoa entrevistada. 
Observação 
Uma observação pode ser realizada no local que um certo evento ocorre, 
normalmente, enquanto os dados são coletados. Se por acaso o lugar for um 
laboratório, é necessário que seja cuidadosa e controlada para observações 
rigorosas. 
 Observação assistemática ou não estruturada: essa é espontânea, 
informal e simples. Os dados são obtidos por uma experiência casual, sem 
antes ter planejado o que deveria ser observado; 
 Observação sistemática ou estruturada: o observador sabe o que procura 
e o que precisa saber de determinada situação. Há um planejamento 
prévio de ações; 
 Observação participante: o pesquisador participa como membro do grupo 
analisado nas atividades; 
 Observação não participante: toma contato com a comunidade sem se 
integrar a ela; 
 Observação individual: somente um pesquisador participa; 
 Observação em grupo: um grupo observa uma ocorrência por vários 
ângulos para analisar dados coletados. 
Sociometria 
16 
 
É uma técnica quantitativa que procura explicar relações pessoais entre 
indivíduos de um mesmo grupo. Revela a estrutura interna dos grupos, indicando as 
posições de cada indivíduo em relação aos demais. Permite analisar os grupos, 
identificar seus líderes, os subgrupos e os desajustados, tem sido utilizada nos mais 
diversos campos de estudos. 
Histórias de vida 
São as diferentes experiências de alguém, suas vivências, que tenham 
significado importante para o conhecimento do objeto em estudo. 
A técnica permite estudar o impacto da interação social sobre as crenças e 
decisões dos indivíduos. Por exemplo, como as pessoas agem nas organizações e 
como as rotinas diárias influenciam seu trabalho, assim como o efeito das decisões 
ao longo do tempo. 
Testes 
Testes são muito usados nas organizações, especialmente no processo de 
seleção e na área de desenvolvimento gerencial, quando se deseja medir o potencial 
dos indivíduos. 
Os testes possuem alguns requisitos como a sua validade, a sua precisão e 
sua padronização. São apresentados de várias formas como, por exemplo, verbais, 
de lápis e papel, visuaise podem ser feitos individualmente ou coletivamente. 
Escalas Sociais 
As escalas sociais são criadas para medir a intensidade das opiniões e atitudes 
da maneira mais objetiva possível. Criar uma escala social é algo muito trabalhoso 
que requer muito esforço e disciplina para se seguir os passos corretamente. As mais 
usadas são as escalas de ordenação, de graduação, de distância social. 
Amostragem 
A amostragem se fundamenta em leis estatísticas que lhe conferem 
fundamentação científica. Na pesquisa social são utilizados diversos tipos de 
amostragem, que podem ser classificados em dois grandes grupos: amostragem 
probabilística (com dados rigorosamente científicos) e não-probabilística (não 
apresentam fundamentação matemática ou estatística). 
17 
 
3. Conclusão 
 
O desenvolvimento do presente trabalho permitiu a análise de diversas 
metodologias para criação de sistemas, antes mesmo de programá-los. Os métodos 
para desenvolvê-las, como Booch, Jacobson, Yourdon foram os mais conhecidos e 
serviram de base para novas implementações. A coleta de dados que pode parecer 
uma tarefa complexa, pode ser realizada de maneira informal por diversos meios. 
Ao passo que Booch, Rumbaugh e Jacobson poderiam ter seguido em frente 
com seus modelos de modelagem, eles se uniram para ajudar na padronização que é 
a UML, o que também ajudou na evolução dos métodos.
18 
 
4. Referências Bibliográficas 
 
A HISTÓRIA DA UML E SEUS DIAGRAMAS: 
https://projetos.inf.ufsc.br/arquivos_projetos/projeto_721/artigo.tcc.pdf 
UMA BREVE HISTÓRIA DA UML: 
http://www.dsc.ufcg.edu.br/~sampaio/cursos/2007.1/Graduacao/SI-
II/Uml/historia_uml/historia_uml.htm 
WHAT IS UML: http://www.uml.org/what-is-uml.htm 
O QUE É UML E DIAGRAMAS DE CASO DE USO: https://www.devmedia.com.br/o-
que-e-uml-e-diagramas-de-caso-de-uso-introducao-pratica-a-uml/23408 
UML: https://www.devmedia.com.br/uml/8579 
MÉTODOS DE COLETA DE DADOS: 
http://darleisimioni.blogspot.com.br/2010/09/metodos-de-coleta-de-dados.html?m=1 
HISTÓRIA DA UML: https://www.projetodiario.net.br/historia-da-uml 
UML INTRODUÇÃO E HISTÓRICO: 
http://www.linhadecodigo.com.br/artigo/763/uml-unified-modeling-language-
introducao-e-historico.aspx#ixzz5B5EVpH4K 
OMG SPEC: https://www.omg.org/spec 
BOOCH DIAGRAMS: http://worldofdiagrams.blogspot.com.br/2008/09/booch-
diagrams.html 
BOOCH METHOD: https://en.wikipedia.org/wiki/Booch_method 
THE BOOCH METHOD ODD: http://cs-exhibitions.uni-klu.ac.at/index.php?id=447 
MÉTODO BOOCH: http://metodologia-de-booch.blogspot.com.br/2009/06/metodo-
booch.html 
BOOCH, RUMBAUGH, JACOBSON E A UML: http://www.fabiobmed.com.br/booch-
rumbaugh-jacobson-e-a-uml-unified-modeling-language/ 
MÉTODOS ORIENTADOS A OBJETOS: 
https://monografias.brasilescola.uol.com.br/computacao/metodos-orientados-
objetos.htm 
19 
 
THE MODELS OF OBJECT-ORIENTED ANALYSIS AND DESIGN: 
https://web.archive.org/web/20060925165739/http://www.ifra.ing.tu-
bs.de/docs/BoochReferenz/overview.html 
ENGENHARIA DE SOFTWARE ORIENTADA A OBJETOS OOSE: 
https://renatogbj.files.wordpress.com/2012/10/trabalho_ps.pdf 
OBJECT ORIENTED SOTWARE ENGINEERING: 
https://en.wikipedia.org/wiki/Object-oriented_software_engineering 
OBJECT ORIENTED SOFTWARE ENGENEERING OOSE: http://cs-
exhibitions.uni-klu.ac.at/index.php?id=448 
OOSE: http://www.deinfo.uepg.br/~furquim/oose.htm 
YOURDON SYSTEMS METHOD: 
http://computing.unn.ac.uk/staff/cgpv1/downloadables/CD3005/ch8-12.pdf 
YOURDON SYSTEM METHOD (YSM): http://www.perflensburg.se/Privatsida/cp-
web/aaafysm.htm 
EDWARD YOURDON: https://en.wikipedia.org/wiki/Edward_Yourdon 
20 
 
5. Anexos 
 
 
Figura 1.0-1 Gráfico do histórico da UML e suas fases 
 
Figura 1.2 Timeline da UML 
21 
 
 
 
Figura 2 Classes representadas pelo método Booch 
Figura 3 - Processo de análise no método Jacobson 
Figura 4 Processo de construção no método Jacobson OOSE