Por que UML?<\/h2>\n
\u00c0 medida que as arquiteturas de software crescem em tamanho e complexidade, aumenta a necessidade de modelos de software. UML \u00e9 a linguagem de modelagem dominante na ind\u00fastria de software. Atualmente \u00e9 um padr\u00e3o de fato adotado pelo Object Management Group, o maior cons\u00f3rcio de software do mundo. \u00c9 dif\u00edcil encontrar um projeto de software com mais de 10 desenvolvedores que n\u00e3o use UML de alguma forma para especificar sua arquitetura.<\/p>\n
Aqui est\u00e3o alguns outros fatos sobre o uso de UML no nosso processo de desenvolvimento de software:<\/p>\n
- \n
- O software est\u00e1 se tornando cada vez mais complexo: uma vers\u00e3o bastante antiga do Windows XP tem mais de 40 milh\u00f5es de linhas de c\u00f3digo.<\/li>\n
- Um \u00fanico programador n\u00e3o consegue gerenciar essa quantidade de c\u00f3digo por completo.<\/li>\n
- O c\u00f3digo n\u00e3o \u00e9 facilmente compreens\u00edvel por desenvolvedores que n\u00e3o o escreveram.<\/li>\n
- Precisamos de representa\u00e7\u00f5es mais simples para sistemas complexos: a modelagem \u00e9 um meio de lidar com a complexidade.<\/li>\n<\/ul>\n
O que \u00e9 um modelo?<\/h2>\n
- \n
- Um modelo \u00e9 uma abstra\u00e7\u00e3o da coisa real, deixando de lado os detalhes.<\/li>\n
- \u201cA cole\u00e7\u00e3o de todos os elementos que descrevem seu sistema, incluindo suas conex\u00f5es m\u00fatuas, constitui seu modelo.\u201d (Russ e Hamilton 12).<\/li>\n<\/ul>\n
quando usamos UML para criar modelos de um sistema em desenvolvimento antes de codificar o software, eles representam o problema de forma simplificada. Eles fornecem uma estrutura para a resolu\u00e7\u00e3o de problemas. Eles ajudam a compreender como se pode proceder com o problema em quest\u00e3o. Tamb\u00e9m permitem experimentar v\u00e1rias solu\u00e7\u00f5es. Como os modelos s\u00e3o criados antes do desenvolvimento real do sistema, podemos entender diferentes possibilidades, problemas, op\u00e7\u00f5es, etc. Isso tamb\u00e9m leva \u00e0 redu\u00e7\u00e3o dos custos de desenvolvimento. Como o tempo n\u00e3o ser\u00e1 desperdi\u00e7ado em tentativas e erros, o produto estar\u00e1 pronto em menos tempo. Modelos tamb\u00e9m ajudam a gerenciar a complexidade do problema, permitindo planejar o desenvolvimento e a aloca\u00e7\u00e3o de recursos como m\u00e1quinas, programadores e testadores de forma mais f\u00e1cil.<\/p>\n
O que UML N\u00c3O \u00c9?<\/h2>\n
- \n
- UML n\u00e3o \u00e9 uma nota\u00e7\u00e3o, mas sim uma linguagem.<\/li>\n
- UML n\u00e3o pertence a ningu\u00e9m. \u00c9 aberto para ser usado por qualquer pessoa que deseje us\u00e1-lo. N\u00e3o \u00e9 propriet\u00e1rio.<\/li>\n
- UML n\u00e3o \u00e9 um processo nem um m\u00e9todo.<\/li>\n
- UML incentiva o uso de t\u00e9cnicas orientadas a objetos e ciclos de vida iterativos de desenvolvimento de software.<\/li>\n
- UML n\u00e3o \u00e9 dif\u00edcil. \u00c9 amplo, mas n\u00e3o \u00e9 necess\u00e1rio conhec\u00ea-lo por completo. Al\u00e9m disso, n\u00e3o h\u00e1 necessidade de usar ou entender cada pequeno aspecto dele.<\/li>\n
- UML n\u00e3o \u00e9 demorado. Se usado corretamente, o uso de UML reduz os custos de desenvolvimento. Ao mesmo tempo, oferece a vantagem de compreens\u00e3o e comunica\u00e7\u00e3o mais f\u00e1ceis, produtividade aumentada e melhor qualidade.<\/li>\n
- UML n\u00e3o \u00e9 limitado. \u00c9 flex\u00edvel o suficiente para permitir novos vocabul\u00e1rios (conceitos, palavras e termos), propriedades (informa\u00e7\u00f5es adicionais sobre as palavras) e sem\u00e2nticas (regras da linguagem) que s\u00e3o necess\u00e1rios para um dom\u00ednio espec\u00edfico.<\/li>\n<\/ul>\n
Objetivo do UML<\/h2>\n
- \n
- Uma linguagem de modelagem visual e n\u00e3o uma linguagem de programa\u00e7\u00e3o visual. Embora algumas ferramentas de modelagem tenham geradores de c\u00f3digo e algumas possam realizar a engenharia reversa de modelos a partir de c\u00f3digo.<\/li>\n
- \u00c9 destinado a criar diagramas que possam apoiar o processo de desenvolvimento de software, no entanto, UML N\u00c3O \u00e9 um processo ou m\u00e9todo de desenvolvimento de software. Portanto, UML \u00e9 independente de processo.<\/li>\n
- Uma linguagem padr\u00e3o para criar plantas de software.<\/li>\n
- Uma ferramenta de comunica\u00e7\u00e3o.<\/li>\n
- Uma linguagem para documentar requisitos, arquitetura, testes, planejamento de projetos, etc\u2026<\/li>\n
- \u00c9 destinado a sistemas de software, mas pode modelar outros sistemas.<\/li>\n
- \u00c9 destinado a apoiar o processo de desenvolvimento orientado a objetos.<\/li>\n
- Pode capturar tanto estruturas est\u00e1ticas quanto comportamentos din\u00e2micos de um sistema.<\/li>\n
- Diagramas UML podem ajudar os interessados a compreender, discutir e concordar com os requisitos.<\/li>\n
- Diagramas UML podem ajudar a abstrair processos complexos at\u00e9 um n\u00edvel mais f\u00e1cil de entender.<\/li>\n
- Diagramas UML ajudam a facilitar a resolu\u00e7\u00e3o de problemas.<\/li>\n<\/ul>\n
O que uma linguagem de modelagem oferece?<\/h2>\n
- \n
- Elementos de Modelo<\/i><\/b>: Conceitos e Sem\u00e2ntica<\/li>\n
- Nota\u00e7\u00e3o<\/i><\/b>: Representa\u00e7\u00e3o Visual dos Elementos de Modelo<\/li>\n
- Diretrizes<\/i><\/b>: Dicas e Sugest\u00f5es para o Uso de Elementos na Nota\u00e7\u00e3o<\/li>\n<\/ul>\n
Breve Hist\u00f3ria<\/h2>\n
Na d\u00e9cada de 80, quando come\u00e7amos a modelar, havia muitas metodologias diferentes. E cada metodologia tinha sua pr\u00f3pria nota\u00e7\u00e3o. O problema era que, se pessoas diferentes usavam nota\u00e7\u00f5es diferentes, em algum momento algu\u00e9m precisava fazer uma tradu\u00e7\u00e3o. Muitas vezes, um s\u00edmbolo significava uma coisa em uma nota\u00e7\u00e3o e algo totalmente diferente em outra nota\u00e7\u00e3o. Em 1991, todos come\u00e7aram a lan\u00e7ar livros. Grady Booch lan\u00e7ou sua primeira edi\u00e7\u00e3o. Ivar Jacobson lan\u00e7ou a sua, e Jim Rumbaugh lan\u00e7ou a sua metodologia OMT. Cada livro tinha suas for\u00e7as, bem como suas fraquezas. OMT era realmente forte na an\u00e1lise, mas fraco no design. A metodologia Booch era mais forte no design e mais fraca na an\u00e1lise. E o Objectory de Ivar Jacobson era muito bom em experi\u00eancia do usu\u00e1rio, algo que nem Booch nem OMT realmente consideravam naquela \u00e9poca. Booch e Jacobson uniram os dois m\u00e9todos em 1994 e, em seguida, Rumbaugh juntou-se em 1995. A UML 1.1 foi publicada em 1997 pela OMG, incluindo contribui\u00e7\u00f5es de outros, por exemplo, Yourden. A UML v2.x \u00e9 a vers\u00e3o mais atual.<\/p>\n
Datas de Lan\u00e7amento<\/h3>\n
- \n
- 1995 \u2013 UML 0.8<\/li>\n
- 1996 \u2013 UML 0.9 \u2013 Tr\u00eas Amigos<\/li>\n
- 1997 \u2013 OMG assume o controle.<\/li>\n
- 1997 \u2013 OMG UML 1.1<\/li>\n
- 1998 \u2013 OMG UML 1.2<\/li>\n
- 1999 \u2013 OMG UML 1.3<\/li>\n
- 2001 \u2013 OMG UML 1.4<\/li>\n
- 2003 \u2013 OMG UML 1.5<\/li>\n
- 2003 \u2013 OMG UML 2.0 \u2013 Adotada<\/li>\n
- 2005 \u2013 OMG UML 2.0 \u2013 Final<\/li>\n
- 2006 \u2013 OMG UML 2.1<\/li>\n
- UML2.1.2<\/b>(11\/04\/07) \u2013 Vers\u00e3o atual at\u00e9 27\/05\/08<\/li>\n<\/ul>\n
![\"\"](\"https:\/\/www.archimetric.com\/wp-content\/uploads\/2017\/05\/What-is-UML.png\")
<\/a><\/p>\nA motiva\u00e7\u00e3o da unifica\u00e7\u00e3o de m\u00e9todos pelos \u201ctr\u00eas Amegos\u201d<\/h2>\n
- \n
- Fato de os m\u00e9todos individuais evolu\u00edrem uns em dire\u00e7\u00e3o aos outros de forma independente<\/li>\n
- Unifica\u00e7\u00e3o de sem\u00e2ntica e nota\u00e7\u00e3o para trazer estabilidade ao mercado de design OO<\/li>\n
- Expectativa de que a unifica\u00e7\u00e3o melhoraria os m\u00e9todos individuais anteriores<\/li>\n<\/ul>\n
Parceiros UML<\/h3>\n
\n
- \n
- Corpora\u00e7\u00e3o Rational Software<\/li>\n
- IBM<\/li>\n
- Hewlett-Packard<\/li>\n
- I-Logix<\/li>\n
- ICON Computing<\/li>\n
- Intellicorp<\/li>\n
- MCI Systemhouse<\/li>\n
- Microsoft<\/li>\n
- ObjecTime<\/li>\n
- Oracle<\/li>\n
- Platinum Technology<\/li>\n
- Taskon<\/li>\n
- Texas Instruments\/Sterling Software<\/li>\n
- Unisys<\/li>\n<\/ul>\n<\/blockquote>\n
Entrada de nota\u00e7\u00e3o UML para diferentes m\u00e9todos antes da unifica\u00e7\u00e3o<\/h2>\n
O UML representa a unifica\u00e7\u00e3o das nota\u00e7\u00f5es Booch, OMT e Objectory, bem como das melhores ideias de diversos outros metodologistas, conforme mostrado na figura abaixo. Ao unificar as nota\u00e7\u00f5es utilizadas por esses m\u00e9todos orientados a objetos, a Linguagem de Modelagem Unificada fornece a base para um padr\u00e3o de fato no dom\u00ednio da an\u00e1lise e do design orientados a objetos, fundamentado em uma ampla base de experi\u00eancia do usu\u00e1rio.<\/p>\n
![\"\"](\"https:\/\/www.archimetric.com\/wp-content\/uploads\/2017\/05\/UML-Imnput.png\")
<\/a><\/p>\n<\/h3>\n
O papel da nota\u00e7\u00e3o<\/h2>\n
A nota\u00e7\u00e3o desempenha um papel importante em qualquer modelo: \u00e9 a cola que mant\u00e9m o processo unido. A nota\u00e7\u00e3o tem tr\u00eas fun\u00e7\u00f5es:<\/p>\n
- \n
- Serve como a linguagem para comunicar decis\u00f5es que n\u00e3o s\u00e3o \u00f3bvias ou n\u00e3o podem ser inferidas diretamente do c\u00f3digo.<\/li>\n
- Oferece sem\u00e2ntica suficientemente rica para capturar todas as decis\u00f5es estrat\u00e9gicas e t\u00e1ticas importantes.<\/li>\n
- Oferece uma forma suficientemente concreta para que os humanos possam raciocinar e que as ferramentas possam manipular.<\/li>\n<\/ul>\n
A Linguagem de Modelagem Unificada (UML) fornece uma nota\u00e7\u00e3o muito robusta, que evolui da an\u00e1lise para o design. Certos elementos da nota\u00e7\u00e3o (por exemplo, classes, associa\u00e7\u00f5es, agrega\u00e7\u00f5es, heran\u00e7a) s\u00e3o introduzidos durante a an\u00e1lise. Outros elementos da nota\u00e7\u00e3o (por exemplo, indicadores de implementa\u00e7\u00e3o de conten\u00e7\u00e3o e propriedades) s\u00e3o introduzidos durante o design.<\/p>\n
Benef\u00edcios do UML<\/b><\/h2>\n
O UML pode ser aplicado a diversosdom\u00ednios de aplica\u00e7\u00e3o<\/strong>\u00a0(por exemplo, banc\u00e1rio, finan\u00e7as, internet, aeroespacial, sa\u00fade, etc.) Pode ser usado com todos os principais objetos e componentes\u00a0m\u00e9todos de desenvolvimento de software<\/strong>\u00a0e para diversos\u00a0plataformas de implementa\u00e7\u00e3o.<\/strong><\/p>\n
- \n
- Voc\u00ea sabe exatamente o que est\u00e1 recebendo<\/li>\n
- Voc\u00ea ter\u00e1 custos de desenvolvimento menores<\/li>\n
- \u00a0Seu software se comportar\u00e1 como voc\u00ea espera. Menos surpresas<\/li>\n
- \u00a0As decis\u00f5es corretas s\u00e3o tomadas antes de voc\u00ea receber c\u00f3digo mal escrito. Custos totais menores<\/li>\n
- Podemos desenvolver sistemas mais eficientes em mem\u00f3ria e processamento<\/li>\n
- Os custos de manuten\u00e7\u00e3o do sistema ser\u00e3o menores. Menos reaprendizado ocorre<\/li>\n
- Trabalhar com um novo desenvolvedor ser\u00e1 mais f\u00e1cil.<\/li>\n
- A comunica\u00e7\u00e3o com programadores e contratistas externos ser\u00e1 mais eficiente.<\/li>\n<\/ul>\n
Vis\u00f5es UML 4 + 1<\/h2>\n
O UML consiste nas seguintes quatro vis\u00f5es do sistema em desenvolvimento (veja a Fig. 3) [Eriksson & Penker, 1998; Kruchten, 2000]:<\/p>\n
- \n
- Vis\u00e3o de caso de uso:<\/em> mostra a funcionalidade do sistema conforme percebida por atores externos; \u00e9 descrita em diagramas de casos de uso e ocasionalmente em diagramas de atividades.<\/li>\n
- Vis\u00e3o l\u00f3gica: <\/em>mostra como essa funcionalidade \u00e9 projetada dentro do sistema, em termos da estrutura est\u00e1tica e do comportamento din\u00e2mico do sistema; \u00e9 descrita em diagramas de classes e objetos (modelo est\u00e1tico) e diagramas de transi\u00e7\u00e3o de estado, sequ\u00eancia, colabora\u00e7\u00e3o e atividades (modelo din\u00e2mico)<\/li>\n
- Vis\u00e3o de componente:<\/em> mostra a organiza\u00e7\u00e3o dos componentes de software; \u00e9 descrita em diagramas de componentes.<\/li>\n
- Vis\u00e3o de implanta\u00e7\u00e3o:<\/em> mostra a configura\u00e7\u00e3o f\u00edsica (implanta\u00e7\u00e3o) dos n\u00f3s de processamento em tempo de execu\u00e7\u00e3o dentro de computadores e dispositivos e os componentes, processos e objetos que neles residem; \u00e9 descrita em diagramas de implanta\u00e7\u00e3o.<\/li>\n
- Vis\u00e3o de processo:<\/em> mostra o aspecto concorrente do sistema em tempo de execu\u00e7\u00e3o, como tarefas, threads, processos e intera\u00e7\u00f5es e aborda problemas de comunica\u00e7\u00e3o e sincroniza\u00e7\u00e3o desses threads; \u00e9 descrita em diagramas din\u00e2micos (diagramas de transi\u00e7\u00e3o de estado, sequ\u00eancia, colabora\u00e7\u00e3o e atividades) e diagramas de implementa\u00e7\u00e3o (diagramas de componentes e de implanta\u00e7\u00e3o).<\/li>\n<\/ul>\n
![\"4+1](\"https:\/\/www.ibm.com\/developerworks\/rational\/library\/05\/0816_Louis\/figure-2.gif\"\/)
<\/p>\nCada sistema consiste no est\u00e1tico<\/em> e o din\u00e2mico<\/em> modelo. O modelo est\u00e1tico \u00e9 representado nos diagramas de classes e objetos. No entanto, revela pouco sobre o comportamento do sistema. O comportamento do sistema \u00e9 capturado graficamente usando cen\u00e1rios (ou seja, diagramas de casos de uso), diagramas de sequ\u00eancia, diagramas de transi\u00e7\u00e3o de estado e diagramas de atividades. Esses constituem o modelo din\u00e2mico do sistema. O comportamento do sistema \u00e9 o comportamento total de todos os objetos pertencentes ao sistema.<\/p>\n
Se quisermos mapear as cinco visualiza\u00e7\u00f5es acima para as fases do ciclo de vida iterativo da Figura 3, poder\u00edamos dizer o seguinte:<\/p>\n
- \n
- An\u00e1lise Orientada a Objetos (OOA), que desenvolve um modelo dos requisitos dos usu\u00e1rios a partir da perspectiva do usu\u00e1rio, mapeia-se para a visualiza\u00e7\u00e3o de caso de uso.<\/li>\n
- Projeto Orientado a Objetos (OOD) adiciona detalhes e decis\u00f5es de projeto (da perspectiva do desenvolvedor) \u00e0 an\u00e1lise e mapeia-se para a visualiza\u00e7\u00e3o l\u00f3gica.<\/li>\n
- Finalmente, a Implementa\u00e7\u00e3o ou Programa\u00e7\u00e3o Orientada a Objetos (OOP) mapeia-se para as visualiza\u00e7\u00f5es de processo, implanta\u00e7\u00e3o e componente.<\/li>\n<\/ul>\n
Diagramas UML 2<\/b><\/h2>\n
O UML possui v\u00e1rios tipos diferentes de diagramas que podem ser usados para descrever um modelo a partir de diferentes pontos de vista. Existem duas categorias amplas de diagramas, que s\u00e3o novamente divididas em subcategorias:<\/p>\n
- \n
- Diagramas Estruturais \u2013 Odiagramas estruturais<\/i>representam o aspecto est\u00e1tico do sistema. Esses aspectos est\u00e1ticos representam aquelas partes de um diagrama que formam a estrutura principal e, portanto, est\u00e1veis. Essas partes est\u00e1ticas s\u00e3o representadas por classes, interfaces, objetos, componentes e n\u00f3s.<\/li>\n
- Diagramas Comportamentais \u2013 Qualquer sistema pode ter dois aspectos, est\u00e1tico e din\u00e2mico. Portanto, um modelo \u00e9 considerado completo quando ambos os aspectos s\u00e3o abrangidos plenamente.\n
Os diagramas comportamentais capturam basicamente o aspecto din\u00e2mico de um sistema. O aspecto din\u00e2mico pode ser descrito ainda mais como as partes que mudam\/movem-se em um sistema.<\/div>\n<\/li>\n<\/ul>\n![\"UML](\"https:\/\/www.archimetric.com\/wp-content\/uploads\/2022\/02\/02-uml-diagram-types.png\"\/)
<\/p>\nDiagramas Estruturais<\/h2>\n
Odiagramas estruturais<\/i>representam o aspecto est\u00e1tico do sistema. Esses aspectos est\u00e1ticos representam aquelas partes de um diagrama que formam a estrutura principal e, portanto, est\u00e1veis.<\/div>\nEssas partes est\u00e1ticas s\u00e3o representadas por classes, interfaces, objetos, componentes e n\u00f3s. Os quatro diagramas estruturais s\u00e3o:<\/div>\n- \n
- Diagrama de Classes<\/b> \u2013 diagrama da estrutura est\u00e1tica das classes e interfaces do sistema e suas rela\u00e7\u00f5es ou associa\u00e7\u00f5es (incluindo heran\u00e7a, agrega\u00e7\u00e3o e associa\u00e7\u00e3o), incluindo as opera\u00e7\u00f5es e atributos das classes. Os modos de apresenta\u00e7\u00e3o s\u00e3o: Associa\u00e7\u00e3o, Heran\u00e7a, Depend\u00eancia. Este \u00e9 um diagrama muito comum no UML.<\/li>\n
- Diagrama de Objetos<\/b> \u2013 \u00e9 um diagrama da estrutura est\u00e1tica de um sistema em um momento ou situa\u00e7\u00e3o espec\u00edfica (instant\u00e2neo), ilustrando uma rela\u00e7\u00e3o em um sistema.<\/li>\n
- Diagrama de Componentes<\/b> \u2013 \u00e9 um diagrama que descreve a organiza\u00e7\u00e3o e as depend\u00eancias dos componentes dentro do sistema.<\/li>\n
- Diagrama de Estrutura Composta<\/b> \u2013 \u00e9 um diagrama que explora inst\u00e2ncias em tempo de execu\u00e7\u00e3o de inst\u00e2ncias interconectadas colaborando por meio de links de comunica\u00e7\u00e3o.<\/li>\n
- Diagrama de Pacotes<\/b> \u2013 \u00e9 um diagrama que representa como um sistema \u00e9 dividido em agrupamentos l\u00f3gicos e quais depend\u00eancias podem existir entre esses agrupamentos.<\/li>\n
- Diagrama de Implanta\u00e7\u00e3o<\/b> \u2013 \u00e9 um diagrama que descreve como unidades f\u00edsicas distribu\u00edveis (componentes de software implant\u00e1veis, aplica\u00e7\u00f5es, servidores, aplica\u00e7\u00f5es, hardware etc.) comp\u00f5em a arquitetura do sistema distribu\u00eddo.<\/li>\n<\/ul>\n
Diagramas Comportamentais<\/b><\/h2>\n
- \n
- Diagrama de Caso de Uso<\/b> \u2013 diagrama dos casos de uso (fun\u00e7\u00f5es\/servi\u00e7os de software) e do papel dos atores (usu\u00e1rios \u2013 tanto humanos quanto sistemas). Este diagrama \u00e9 do ponto de vista do usu\u00e1rio.<\/li>\n
- Diagrama de Atividade<\/b> \u2013 \u00e9 um diagrama da natureza din\u00e2mica de um sistema ao modelar o fluxo de controle de atividade para atividade. Diagrama como um sistema (por exemplo: objeto\/classe) responde a um evento interno. (observa\u00e7\u00e3o: eventos externos s\u00e3o descritos por um Diagrama de Estado). Para modelagem de processos de neg\u00f3cios, voc\u00ea pode usar este diagrama para modelar a l\u00f3gica de um caso de uso ou regra de neg\u00f3cio.<\/li>\n
- Diagrama de Estado<\/b> (tamb\u00e9m conhecido como Diagrama de Estado, Diagrama de M\u00e1quina de Estados) \u2013 \u00e9 um diagrama de como um sistema (por exemplo: objeto\/classe) responde a um evento externo. (observa\u00e7\u00e3o: eventos internos s\u00e3o descritos por um Diagrama de Atividade).<\/li>\n<\/ul>\n
Diagramas de Tipo de Intera\u00e7\u00e3o<\/b>\u2013 intera\u00e7\u00f5es das partes organizacionais do modelo.<\/p>\n
- \n
- Diagrama de Sequ\u00eancia<\/b> \u2013 \u00e9 um diagrama da intera\u00e7\u00e3o e fluxo de mensagens entre objetos e a ordem temporal relativa das mensagens<\/li>\n
- Diagrama de Comunica\u00e7\u00e3o<\/b>(tamb\u00e9m conhecido como <\/b>Diagramas de Colabora\u00e7\u00e3o do UML1) \u2013 \u00e9 um diagrama de como sistemas colaboram entre si para realizar uma tarefa e os relacionamentos que devem existir entre os sistemas. O diagrama de colabora\u00e7\u00e3o \u00e9 o resultado de tomar o diagrama de sequ\u00eancia e descrever sua intera\u00e7\u00e3o com o Diagrama de Classe. Em resumo, este diagrama mostra o fluxo de mensagens entre objetos e as associa\u00e7\u00f5es b\u00e1sicas (relacionamentos) entre classes<\/li>\n
- Diagrama de Tempo<\/b> \u2013 \u00e9 um diagrama que explora os comportamentos de um ou mais objetos ao longo de um per\u00edodo de tempo determinado.<\/li>\n
- Diagrama de Vis\u00e3o Geral de Intera\u00e7\u00e3o<\/b> \u2013 \u00e9 um diagrama da intera\u00e7\u00e3o e controle de fluxo entre os diagramas de intera\u00e7\u00e3o (diagrama de sequ\u00eancia, diagrama de comunica\u00e7\u00e3o, diagrama de tempo, diagrama de vis\u00e3o geral de intera\u00e7\u00e3o).<\/li>\n<\/ul>\n
Perfil UML<\/h3>\n
O Perfil UML n\u00e3o \u00e9 exatamente um diagrama, mas um perfil para descrever extens\u00f5es e subconjuntos do UML. Subconjuntos s\u00e3o descritos usando a Linguagem de Restri\u00e7\u00e3o de Objetos (OCL). Extens\u00f5es s\u00e3o criadas definindo estere\u00f3tipos, que s\u00e3o tags que podem decorar qualquer elemento do modelo. Por exemplo, podemos marcar uma classe como \u201cpersistente\u201d e usar essa tag para identificar uma classe cujas inst\u00e2ncias s\u00e3o armazenadas ap\u00f3s o tempo de vida da execu\u00e7\u00e3o do sistema. De forma informal \u2013 e isso \u00e9 ideologicamente incorreto \u2013 um perfil \u00e9 qualquer conjunto de extens\u00f5es e subconjuntos do UML, independentemente de serem escritos usando esses mecanismos ou n\u00e3o. Formalmente, um perfil \u00e9 a defini\u00e7\u00e3o de OCL e estere\u00f3tipos que descrevem as regras, que no UML 2, s\u00e3o capturadas em um pacote.<\/p>\n
Diagramas Relacionados para Desenvolvimento de Software<\/h3>\n
Entre as diferen\u00e7as entre metodologias de OOAD e a evolu\u00e7\u00e3o dos padr\u00f5es UML, os nomes dos diagramas e suas fun\u00e7\u00f5es podem evoluir ao longo do tempo. Aqui est\u00e3o alguns exemplos de diagramas e\/ou produtos de trabalho que podem ou n\u00e3o fazer parte do UML1 ou UML2, mas que poderiam ser usados em metodologias de OOAD:<\/p>\n
- \n
- Diagrama de Contexto do Sistema<\/b><\/li>\n
- Diagrama de Relacionamento de Entidades (semelhante ao Diagrama de Classe) com ERD conceitual, l\u00f3gico e f\u00edsico<\/b><\/li>\n
- An\u00e1lise de Robustez<\/b><\/li>\n<\/ul>\n
Conclus\u00e3o<\/h2>\n
Tivemos uma vis\u00e3o geral sobre as origens e defini\u00e7\u00e3o do UML para fornecer uma compreens\u00e3o simplificada do que ele \u00e9 e do que o UML pode nos oferecer. Tamb\u00e9m examinamos como podemos se beneficiar do seu uso em nosso pr\u00f3ximo projeto de desenvolvimento e exploramos brevemente as vis\u00f5es arquitet\u00f4nicas e modelos e o tipo de diagramas dispon\u00edveis no UML 2. O UML n\u00e3o \u00e9 um processo, mas uma nota\u00e7\u00e3o visual padr\u00e3o aberta para o desenvolvimento de sistemas intensivos em software. Os componentes necess\u00e1rios para um projeto bem-sucedido exigem tr\u00eas aspectos: uma nota\u00e7\u00e3o, um processo e uma ferramenta:<\/p>\n
\u00a0<\/p>\n
![\"\"](\"https:\/\/www.archimetric.com\/wp-content\/uploads\/2017\/05\/Triangle-of-Success.gif\")
<\/a><\/p>\n\u00a0<\/p>\n
Apenas Nota\u00e7\u00e3o<\/strong> \u2013 voc\u00ea pode aprender uma nota\u00e7\u00e3o (por exemplo, UML)<\/strong>, mas se voc\u00ea n\u00e3o souber como us\u00e1-la (processo<\/strong>), voc\u00ea provavelmente falhar\u00e1.<\/p>\n
Processo Apenas<\/strong> \u2013 Voc\u00ea pode ter um \u00f3timo processo<\/strong>, mas se voc\u00ea n\u00e3o puder comunicar o processo (nota\u00e7\u00e3o<\/strong>), voc\u00ea provavelmente falhar\u00e1. E por fim<\/p>\n
Sem Suporte de Ferramenta<\/strong> \u2013 se voc\u00ea n\u00e3o puder documentar efetivamente os artefatos do seu trabalho (ferramenta<\/strong>), voc\u00ea provavelmente acabar\u00e1 perdendo muito tempo e, eventualmente, falhar\u00e1.<\/p>\n
\u00a0<\/p>\n
Ferramenta Automatizada de UML<\/h2>\n
Visual Paradigm<\/a> \u00e9 uma ferramenta automatizada que garante que voc\u00ea ter\u00e1 sucesso em seus projetos de software com:<\/p>\n
- \n
- Edi\u00e7\u00e3o de sintaxe f\u00e1cil para minimizar a necessidade de memoriza\u00e7\u00e3o de nota\u00e7\u00e3o<\/li>\n
- Suporte a processos e conjunto de ferramentas de desenvolvimento de software \u00e1gil e mais populares<\/li>\n
- Automatizado para simplificar qualquer tamanho de projeto e relat\u00f3rio de produto e artefato em tempo real<\/li>\n<\/ol>\n
Recursos de UML<\/h2>\n
- \n
- Guia Completo sobre os 14 Tipos de Diagramas UML \u2013 Cybermedian<\/strong>\n
- \n
- Este guia fornece uma vis\u00e3o geral dos 14 tipos de diagramas UML suportados pela edi\u00e7\u00e3o comunit\u00e1ria do Visual Paradigm. Explica como os diagramas UML ajudam na visualiza\u00e7\u00e3o de sistemas intensivos em software e descreve a funcionalidade fornecida por cada tipo de diagrama. O guia tamb\u00e9m destaca a versatilidade do Visual Paradigm ao suportar diversos diagramas UML para diferentes necessidades de modelagem11<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- Aprenda modelagem UML com as melhores ferramentas gratuitas de UML (tanto online quanto freeware para desktop) \u2013 Cybermedian<\/strong>\n
- \n
- Este artigo discute os benef\u00edcios de usar o Visual Paradigm para modelagem UML, enfatizando seu suporte ao mais recente padr\u00e3o UML 2.x e sua ampla variedade de tipos de diagramas. Tamb\u00e9m menciona as capacidades de integra\u00e7\u00e3o da ferramenta com plataformas de desenvolvimento populares e sua ado\u00e7\u00e3o generalizada na academia e na ind\u00fastria12<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- Aprendendo por Exemplo: Diagramas de M\u00e1quina de Estados UML \u2013 Cybermedian<\/strong>\n
- \n
- Este recurso se concentra nos Diagramas de M\u00e1quina de Estados UML e recomenda o Visual Paradigm como uma ferramenta ideal para criar esses diagramas. Oferece uma an\u00e1lise aprofundada sobre como os Diagramas de M\u00e1quina de Estados podem modelar o comportamento din\u00e2mico de sistemas e destaca a integra\u00e7\u00e3o do Visual Paradigm com ferramentas e plataformas de desenvolvimento13<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- Diagramas UML: Um Guia Completo \u2013 Cybermedian<\/strong>\n
- \n
- Este guia completo explica a import\u00e2ncia dos diagramas UML no desenvolvimento de software e como o Visual Paradigm suporta diversos tipos de diagramas UML. Ele aborda diagramas estruturais, comportamentais e de intera\u00e7\u00e3o, fornecendo insights sobre como o Visual Paradigm pode ser usado para criar modelos UML eficazes14<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- FERRAMENTA ONLINE GRATUITA DE DIAGRAMAS UML \u2013 Cybermedian<\/strong>\n
- \n
- Este artigo apresenta o Visual Paradigm Online (VP Online) Edi\u00e7\u00e3o Express, uma ferramenta online gratuita para criar diagramas UML. Destaca a facilidade de uso da ferramenta, a aus\u00eancia de limita\u00e7\u00f5es e a compatibilidade com v\u00e1rios navegadores da web, tornando-a uma op\u00e7\u00e3o acess\u00edvel para a cria\u00e7\u00e3o de diagramas UML pessoais e n\u00e3o comerciais15<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- Compreendendo Diagramas de Tempo UML: Um Guia Completo \u2013 Cybermedian<\/strong>\n
- \n
- Este guia explica os Diagramas de Tempo UML e sua import\u00e2ncia em sistemas em tempo real. Discute como o Visual Paradigm pode ser usado para criar esses diagramas, focando na representa\u00e7\u00e3o visual das restri\u00e7\u00f5es de tempo e dura\u00e7\u00e3o dentro de um sistema16<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- O Guia Completo sobre Diagramas UML 2.5 \u2013 Cybermedian<\/strong>\n
- \n
- Este guia fornece uma vis\u00e3o geral dos diagramas UML 2.5 e destaca o Visual Paradigm como uma escolha principal para modelagem abrangente. Discute a versatilidade da ferramenta, sua interface amig\u00e1vel e suas poderosas capacidades de gera\u00e7\u00e3o de c\u00f3digo, tornando-a adequada para profissionais de diversas \u00e1reas17<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- Um Guia Completo sobre Diagrama de Classes UML \u2013 Cybermedian<\/strong>\n
- \n
- Este guia se concentra nos Diagramas de Classes UML e em como o Visual Paradigm apoia sua cria\u00e7\u00e3o. Discute a ado\u00e7\u00e3o generalizada da ferramenta na academia e seu uso no design e an\u00e1lise de sistemas e bancos de dados. O guia tamb\u00e9m menciona a disponibilidade de exemplos e modelos para in\u00edcio r\u00e1pido na modelagem UML18<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- Tutorial de Diagrama de Pacotes UML Usando o Visual Paradigm \u2013 Cybermedian<\/strong>\n
- \n
- Este tutorial passo a passo explica como criar um Diagrama de Pacotes UML usando o Visual Paradigm. Explica a import\u00e2ncia dos diagramas de pacotes na organiza\u00e7\u00e3o de sistemas grandes e fornece um guia passo a passo para sua cria\u00e7\u00e3o usando o Visual Paradigm19<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- O Guia Completo sobre Modelagem Visual para Desenvolvimento \u00c1gil de Software \u2013 Cybermedian<\/strong>\n
- Tutorial de Diagrama de Pacotes UML Usando o Visual Paradigm \u2013 Cybermedian<\/strong>\n
- Um Guia Completo sobre Diagrama de Classes UML \u2013 Cybermedian<\/strong>\n
- O Guia Completo sobre Diagramas UML 2.5 \u2013 Cybermedian<\/strong>\n
- Compreendendo Diagramas de Tempo UML: Um Guia Completo \u2013 Cybermedian<\/strong>\n
- FERRAMENTA ONLINE GRATUITA DE DIAGRAMAS UML \u2013 Cybermedian<\/strong>\n
- Diagramas UML: Um Guia Completo \u2013 Cybermedian<\/strong>\n
- Aprendendo por Exemplo: Diagramas de M\u00e1quina de Estados UML \u2013 Cybermedian<\/strong>\n
- Aprenda modelagem UML com as melhores ferramentas gratuitas de UML (tanto online quanto freeware para desktop) \u2013 Cybermedian<\/strong>\n
- Este guia fornece uma vis\u00e3o geral dos 14 tipos de diagramas UML suportados pela edi\u00e7\u00e3o comunit\u00e1ria do Visual Paradigm. Explica como os diagramas UML ajudam na visualiza\u00e7\u00e3o de sistemas intensivos em software e descreve a funcionalidade fornecida por cada tipo de diagrama. O guia tamb\u00e9m destaca a versatilidade do Visual Paradigm ao suportar diversos diagramas UML para diferentes necessidades de modelagem11<\/a>.<\/li>\n<\/ul>\n<\/li>\n
- Guia Completo sobre os 14 Tipos de Diagramas UML \u2013 Cybermedian<\/strong>\n
- Diagrama de Relacionamento de Entidades (semelhante ao Diagrama de Classe) com ERD conceitual, l\u00f3gico e f\u00edsico<\/b><\/li>\n
- Diagrama de Comunica\u00e7\u00e3o<\/b>(tamb\u00e9m conhecido como <\/b>Diagramas de Colabora\u00e7\u00e3o do UML1) \u2013 \u00e9 um diagrama de como sistemas colaboram entre si para realizar uma tarefa e os relacionamentos que devem existir entre os sistemas. O diagrama de colabora\u00e7\u00e3o \u00e9 o resultado de tomar o diagrama de sequ\u00eancia e descrever sua intera\u00e7\u00e3o com o Diagrama de Classe. Em resumo, este diagrama mostra o fluxo de mensagens entre objetos e as associa\u00e7\u00f5es b\u00e1sicas (relacionamentos) entre classes<\/li>\n
- Diagrama de Atividade<\/b> \u2013 \u00e9 um diagrama da natureza din\u00e2mica de um sistema ao modelar o fluxo de controle de atividade para atividade. Diagrama como um sistema (por exemplo: objeto\/classe) responde a um evento interno. (observa\u00e7\u00e3o: eventos externos s\u00e3o descritos por um Diagrama de Estado). Para modelagem de processos de neg\u00f3cios, voc\u00ea pode usar este diagrama para modelar a l\u00f3gica de um caso de uso ou regra de neg\u00f3cio.<\/li>\n
- Diagrama de Objetos<\/b> \u2013 \u00e9 um diagrama da estrutura est\u00e1tica de um sistema em um momento ou situa\u00e7\u00e3o espec\u00edfica (instant\u00e2neo), ilustrando uma rela\u00e7\u00e3o em um sistema.<\/li>\n
- Diagramas Comportamentais \u2013 Qualquer sistema pode ter dois aspectos, est\u00e1tico e din\u00e2mico. Portanto, um modelo \u00e9 considerado completo quando ambos os aspectos s\u00e3o abrangidos plenamente.\n
- Diagramas Estruturais \u2013 Odiagramas estruturais<\/i>representam o aspecto est\u00e1tico do sistema. Esses aspectos est\u00e1ticos representam aquelas partes de um diagrama que formam a estrutura principal e, portanto, est\u00e1veis. Essas partes est\u00e1ticas s\u00e3o representadas por classes, interfaces, objetos, componentes e n\u00f3s.<\/li>\n
- Vis\u00e3o l\u00f3gica: <\/em>mostra como essa funcionalidade \u00e9 projetada dentro do sistema, em termos da estrutura est\u00e1tica e do comportamento din\u00e2mico do sistema; \u00e9 descrita em diagramas de classes e objetos (modelo est\u00e1tico) e diagramas de transi\u00e7\u00e3o de estado, sequ\u00eancia, colabora\u00e7\u00e3o e atividades (modelo din\u00e2mico)<\/li>\n
- Vis\u00e3o de caso de uso:<\/em> mostra a funcionalidade do sistema conforme percebida por atores externos; \u00e9 descrita em diagramas de casos de uso e ocasionalmente em diagramas de atividades.<\/li>\n
- Nota\u00e7\u00e3o<\/i><\/b>: Representa\u00e7\u00e3o Visual dos Elementos de Modelo<\/li>\n
- Elementos de Modelo<\/i><\/b>: Conceitos e Sem\u00e2ntica<\/li>\n