{"id":3949,"date":"2022-04-05T17:17:16","date_gmt":"2022-04-05T20:17:16","guid":{"rendered":"https:\/\/elemarjr.com\/arquiteturadesoftware\/?p=3949"},"modified":"2024-01-12T17:44:13","modified_gmt":"2024-01-12T20:44:13","slug":"modelo-visoes-do-modelo-e-alem","status":"publish","type":"volume-1","link":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/modelo-visoes-do-modelo-e-alem\/","title":{"rendered":"Cap 1.4 Modelo, vis\u00f5es do modelo e al\u00e9m"},"content":{"rendered":"

As pr\u00e1ticas de arquitetura de software, com frequ\u00eancia, est\u00e3o associadas a elabora\u00e7\u00e3o e manuten\u00e7\u00e3o de representa\u00e7\u00f5es, gr\u00e1ficas ou textuais, usando nota\u00e7\u00e3o livre ou uma ADL, destacando aspectos relevantes para o atendimento dos objetivos de neg\u00f3cio, respeito \u00e0s restri\u00e7\u00f5es e alcance de atributos de qualidade, com menor custo e risco.<\/strong><\/p>\n

\r\n

Defini\u00e7\u00e3o: ADL (Architectural Description Language)<\/p>\r\n

<\/p>\n

As linguagens de descri\u00e7\u00e3o de arquitetura (ADLs) fornecem meios de modelar e analisar arquiteturas de software, visando melhorar aspectos de qualidade interna e externa.<\/p>\n

Elas podem ter forma textual descritiva (formal ou informal), gr\u00e1fica ou ambas.<\/p>\n

C4<\/a>, Archimate<\/a> ou UML<\/a> s\u00e3o exemplos de ADLs<\/p>\n

<\/p>\r\n<\/div>\nImportante, entretanto, entender que tais representa\u00e7\u00f5es s\u00e3o “meios de trabalho” para a arquitetura e n\u00e3o a finalidade. Elas ajudam na comunica\u00e7\u00e3o e na orquestra\u00e7\u00e3o das atividades, mas n\u00e3o constituem um fim nelas mesmas.<\/strong>\n

\n

A finalidade da arquitetura de software<\/em> \u00e9 maximizar a entrega de valor para o neg\u00f3cio, SE NECESS\u00c1RIO, com software funcionando.<\/strong><\/p>\n

Modelo, vis\u00f5es do modelo, modelagem e reposit\u00f3rio da arquitetura<\/h2>\n

As representa\u00e7\u00f5es geradas nas pr\u00e1ticas de arquitetura cont\u00e9m “conceitos arquiteturais” relevantes ao design,\u00a0<\/em>como os elementos que ir\u00e3o comp\u00f4r os sistemas e forma como eles devem se relacionar.<\/strong> O conjunto de todos os “conceitos arquiteturais” que podem ser utilizados para descrever a arquitetura de um software<\/em> compreende o modelo arquitetural.<\/p>\n

\r\n

Defini\u00e7\u00e3o: Modelo arquitetural<\/p>\r\n

<\/p>\n

Conjunto de todos “conceitos arquiteturais” – incluindo m\u00f3dulos, componentes, relacionamentos e propriedades – que podem ou poder\u00e3o ser utilizados na descri\u00e7\u00e3o da arquitetura de um software<\/em>.<\/p>\n

<\/p>\r\n<\/div>\n

Representa\u00e7\u00f5es arquiteturais, sejam elas gr\u00e1ficas ou textuais, apresentam “recortes” do modelo da arquitetura, colocando em destaque algum aspecto e finalidade relevante – geralmente, quanto mais expl\u00edcita a finalidade, melhor.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" Muitas representa\u00e7\u00f5es arquiteturais pecam por ter finalidade muito abrangente ou indefinida. Antes de\u00a0 produzir um diagrama, por exemplo, responda duas perguntas: 1) a quem se destina essa informa\u00e7\u00e3o?” e 2) “qual \u00e9 a finalidade desejada (outcome<\/em>)?<\/strong>” <\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Os “recortes do modelo” s\u00e3o conhecidos como “vis\u00f5es do modelo”. Elas ajudam a explicitar aspectos da condi\u00e7\u00e3o atual real<\/span> (AS-IS<\/em>) ou parte do futuro ideal imaginado<\/span> (TO-BE<\/em>), ou ainda de alguma configura\u00e7\u00e3o intermedi\u00e1ria<\/span> (parte do roadmap<\/em>) entre esses dois momentos.<\/p>\n

\r\n

Defini\u00e7\u00e3o: Vis\u00e3o do modelo<\/p>\r\n

<\/p>\n

Representa\u00e7\u00e3o contendo um “recorte” do modelo arquitetural destacando algum aspecto relevante no AS-IS<\/em>, TO-BE<\/em> ou em algum est\u00e1gio do roadmap<\/em>.<\/p>\n

<\/p>\r\n<\/div>\n

Quanto mais vis\u00f5es coerentes com modelo forem produzidas, mais abrangente ser\u00e1 explicita\u00e7\u00e3o do modelo em si. O esfor\u00e7o para criar e manter as diversas “vis\u00f5es do modelo” \u00e9 reconhecido como modelagem.<\/strong><\/p>\n

\r\n

Defini\u00e7\u00e3o: Modelagem arquitetural<\/p>\r\n

<\/p>\n

Esfor\u00e7o despendido para produ\u00e7\u00e3o de representa\u00e7\u00f5es arquiteturais (vis\u00f5es do modelo), utilizando ou ampliando coerentemente o conjunto de conceitos expostos no modelo da arquitetura.<\/p>\n

<\/p>\r\n<\/div>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" O volume de vis\u00f5es de modelo que deve ser produzido depende, invariavelmente, do tamanho do escopo a atender e do equil\u00edbrio das toler\u00e2ncias a riscos e custos ao longo do tempo.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Idealmente, todas as vis\u00f5es do modelo s\u00e3o armazenadas de forma organizada constituindo o reposit\u00f3rio da arquitetura. Boas ferramentas permitem infer\u00eancias e an\u00e1lises do modelo atrav\u00e9s das vis\u00f5es mantidas no reposit\u00f3rio.<\/p>\n

\r\n

Defini\u00e7\u00e3o: Reposit\u00f3rio da arquitetura<\/p>\r\n

<\/p>\n

Conjunto organizado de todas as representa\u00e7\u00f5es (vis\u00f5es de modelo), gr\u00e1ficas ou textuais, constru\u00eddas utilizando conceitos descritos no modelo da arquitetura.<\/p>\n

<\/p>\r\n<\/div>\n

Que ADL utilizar?<\/h2>\n

A escolha de que ADL utilizar, principalmente em representa\u00e7\u00f5es gr\u00e1ficas, depender\u00e1 de diversos fatores: incluindo p\u00fablico destino, qualifica\u00e7\u00e3o das pessoas desempenhando atividades relacionadas a arquitetura e prefer\u00eancias.<\/strong><\/p>\n

Frequentemente, pessoas sem “forma\u00e7\u00e3o” para pr\u00e1ticas em arquitetura optam por utilizar nota\u00e7\u00f5es informais em ferramentas alternativas (PowerPoint, por exemplo). O problema de tais nota\u00e7\u00f5es \u00e9 a possibilidade de falhas de entendimento e ambiguidades. A grande vantagem \u00e9, eventualmente, serem mais l\u00fadicas e, consequentemente, compreens\u00edveis para pessoas de \u00e1reas n\u00e3o-tecnicas.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" Evite utilizar nota\u00e7\u00f5es informais para “documentar” a arquitetura. Recorra a elas, principalmente, para reuni\u00f5es com pessoas “n\u00e3o-t\u00e9cnicas”.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Como op\u00e7\u00e3o frequente, inclusive por sua simplicidade, h\u00e1 o C4 model. Tal ADL destaca-se por possuir representa\u00e7\u00e3o gr\u00e1fica e textual, entretanto, \u00e9 limitada quanto as ideias que consegue representar.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" Se n\u00e3o est\u00e1 habituado a utilizar ADLs formais, comece com C4 model.<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Para cen\u00e1rios mais complexos, onde h\u00e1 necessidade de mais “vocabul\u00e1rio”, o ideal \u00e9 utilizar linguagens mais formais como UML e Archimate.<\/p>\n

\r\n\r\n\r\n\r\n
\"\"<\/td>\r\n\"\" N\u00e3o se limite a utilizar uma \u00fanica ADL. Considere complexidade daquilo que deseja comunicar e familiaridade do time. N\u00e3o desconsidere UML precocemente!<\/p>\r\n<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/div>\n

Pensando em “m\u00f3dulos”<\/h2>\n

Do conjunto de objetivos do neg\u00f3cio, restri\u00e7\u00f5es e atributos de qualidade que precisam ser satisfeitos por uma implementa\u00e7\u00e3o de software, infere-se uma rela\u00e7\u00e3o de responsabilidades que precisam ser atendidas.<\/p>\n

\r\n

Defini\u00e7\u00e3o: Responsabilidade<\/p>\r\n

<\/p>\n

Uma responsabilidade<\/span> descreve a “expectativa de contribui\u00e7\u00e3o” de algum “conceito arquitetural” para o software como um todo<\/strong>, incluindo a\u00e7\u00f5es que dever\u00e1 executar, informa\u00e7\u00f5es que dever\u00e1 controlar e manter, decis\u00f5es que precisar\u00e1 realizar, ou qualquer outro papel que precisar\u00e1 desempenhar no atendimento dos objetivos de neg\u00f3cio, imposi\u00e7\u00e3o de restri\u00e7\u00f5es ou atributos de qualidade.<\/p>\n

<\/p>\r\n<\/div>\n

O trabalho fundamental das pr\u00e1ticas de arquitetura \u00e9 decompor as responsabilidades de um software em “unidades de implementa\u00e7\u00e3o”, identificadas como m\u00f3dulos<\/strong>. O n\u00edvel de granularidade dos m\u00f3dulos depender\u00e1 da complexidade e das prefer\u00eancias de quem est\u00e1 elaborando o design<\/em> de arquitetura (o arquiteto).<\/p>\n

\r\n

Defini\u00e7\u00e3o: M\u00f3dulo<\/p>\r\n

<\/p>\n

Um m\u00f3dulo<\/span> \u00e9 a “unidade de implementa\u00e7\u00e3o” no software respons\u00e1vel por atender um conjunto coerente de responsabilidades.<\/strong> Essa “unidade de implementa\u00e7\u00e3o” poder\u00e1 ser uma classe, cole\u00e7\u00e3o de classes, camada, aspecto ou qualquer outra unidade aceita de decomposi\u00e7\u00e3o, conforme o paradigma vigente.<\/p>\n

<\/p>\r\n<\/div>\n

M\u00f3dulos, obviamente, n\u00e3o “vivem” em isolamento.<\/p>\n

As rela\u00e7\u00f5es comuns entre m\u00f3dulos incluem is-part-of, depends-on <\/em>e is-a<\/em>. <\/strong>Is-part-of\u00a0<\/em> s\u00e3o explicita\u00e7\u00f5es de rela\u00e7\u00f5es entre “m\u00f3dulos\/subm\u00f3dulo” (partes) e m\u00f3dulos agregadores (todo).<\/strong> Agrega\u00e7\u00f5es<\/span> e composi\u00e7\u00f5es<\/span> s\u00e3o rela\u00e7\u00f5es is-part-of.<\/em><\/p>\n

\"\"<\/p>\n

Na vis\u00e3o do modelo<\/span>, representada no diagrama acima, temos uma “abordagem modular” indicado a exist\u00eancia de uma colabora\u00e7\u00e3o que agrega m\u00f3dulos de “compras” e de “or\u00e7amenta\u00e7\u00e3o” e que tem em sua composi\u00e7\u00e3o uma API.<\/p>\n

\r\n

Defini\u00e7\u00e3o: Composi\u00e7\u00e3o e Agrega\u00e7\u00e3o<\/p>\r\n

<\/p>\n

Composi\u00e7\u00e3o \u00e9 uma rela\u00e7\u00e3o todo\/parte que expressa uma depend\u00eancia de exist\u00eancia: se um composto \u00e9 exclu\u00eddo, suas partes (normalmente) tamb\u00e9m s\u00e3o exclu\u00eddas.<\/p>\n

Agrega\u00e7\u00e3o tamb\u00e9m \u00e9 uma rela\u00e7\u00e3o todo\/parte, por\u00e9m, ao contr\u00e1rio da composi\u00e7\u00e3o, n\u00e3o implica em depend\u00eancia de exist\u00eancia entre os elementos agregadores e agregados.<\/p>\n

<\/p>\r\n<\/div>\n

Depends-on <\/em>s\u00e3o explicita\u00e7\u00f5es de rela\u00e7\u00f5es entre m\u00f3dulos consumidores e fornecedores.<\/strong><\/p>\n

Ainda na\u00a0 vis\u00e3o do modelo<\/span>, representada tamb\u00e9m no diagrama anterior, percebemos que o website\u00a0<\/em>de vendas de viagens \u00e9 “servido” (tem depend\u00eancia) por uma API (dependendo dela).<\/p>\n

\"\"<\/p>\n

Ja na vis\u00e3o do modelo<\/span>\u00a0indicada no diagrama acima, temos o indicativo de que o m\u00f3dulo de venda de produtos “aciona” o m\u00f3dulo de cobran\u00e7a de clientes.<\/p>\n

Por fim,\u00a0is-a<\/em>\u00a0s\u00e3o explicita\u00e7\u00f5es de rela\u00e7\u00f5es de realiza\u00e7\u00e3o ou especializa\u00e7\u00e3o entre dois m\u00f3dulos.<\/strong><\/p>\n

\"\"<\/p>\n

Na vis\u00e3o do modelo<\/span>\u00a0indicada no diagrama acima, temos o indicativo de que o servi\u00e7o de pagamentos pode ser realizado atrav\u00e9s do\u00a0Paypal, Apple Play\u00a0<\/em>ou\u00a0Google Pay.<\/em><\/p>\n

\"\"<\/p>\n

Ja na\u00a0vis\u00e3o do modelo<\/span> indicada no diagrama acima, temos o indicativo de tr\u00eas “m\u00f3dulos” de pagamento (Visa, Mastercard e AMEX) desenvolvidos a partir de um “m\u00f3dulo abstrato”.<\/p>\n

\u00c9 improv\u00e1vel que a documenta\u00e7\u00e3o de arquitetura de qualquer software esteja completa sem pelo menos uma vis\u00e3o do modelo baseada em “m\u00f3dulos”<\/strong><\/p>\n

Pensando em “componentes e conectores”<\/h2>\n

Um m\u00f3dulo, para cumprir com suas responsabilidades, demandar\u00e1 “conceitos arquiteturais” com alguma presen\u00e7a em tempo de execu\u00e7\u00e3o – tais como processos e mecanismos de armazenamento. Tais “conceitos arquiteturais” costumam ser designados como “componentes”.<\/strong><\/p>\n

\r\n

Defini\u00e7\u00e3o: Componente<\/p>\r\n

<\/p>\n

Um componente \u00e9 um elemento computacional ou de armazenamento de dados, percept\u00edvel em runtime.<\/em><\/p>\n

<\/p>\r\n<\/div>\n

Componentes exp\u00f5e interfaces de comunica\u00e7\u00e3o, frequentemente identificadas como portas, que permite a eles interagir com o ambiente.<\/p>\n

Os diversos componentes, para interagir, demandam de algum meio. Os “conceitos arquiteturais” que viabilizam a comunica\u00e7\u00e3o entre dois componentes costumam ser designados “conectores”.<\/strong><\/p>\n

\r\n

Defini\u00e7\u00e3o: Conector<\/p>\r\n

<\/p>\n

Um conector \u00e9 um “meio de intera\u00e7\u00e3o” entre dois ou mais componentes da arquitetura. Componentes cujo prop\u00f3sito principal \u00e9 mediar intera\u00e7\u00f5es entre outros dois ou mais componentes \u00e9, por defini\u00e7\u00e3o, um conector.<\/p>\n

<\/p>\r\n<\/div>\n

Cada conector, em sua defini\u00e7\u00e3o, explicita poss\u00edveis pap\u00e9is que podem ser assumidos por componentes indicando como as intera\u00e7\u00f5es dever\u00e3o acontecer.<\/strong><\/p>\n

\"\"<\/p>\n

No diagrama indicado acima, temos um template<\/em> para projeto de vis\u00f5es de modelo com componentes e conectores RPC. Na ilustra\u00e7\u00e3o, fica indicado que componentes s\u00e3o realizados por m\u00f3dulos, expostos atrav\u00e9s de interfaces para serem consumidos por a) aplica\u00e7\u00f5es internas e 2) interfaces consolidadas<\/p>\n

\"\"<\/p>\n

J\u00e1 no diagrama indicado acima, temos um template para a representa\u00e7\u00e3o de dois componentes que se comunicam de maneira ass\u00edncrona atrav\u00e9s de uma fila (que \u00e9 o conector) em um padr\u00e3o conhecido como producer\/consumer.<\/em><\/p>\n

\"\"<\/p>\n

No diagrama indicado acima, temos um template para a representa\u00e7\u00e3o da poss\u00edvel comunica\u00e7\u00e3o de um componente, para m\u00faltiplos outros atrav\u00e9s de um t\u00f3pico (que \u00e9 um conector) em um padr\u00e3o conhecido como\u00a0publisher\/subscriber.<\/em><\/p>\n

Quem n\u00e3o comunica …<\/span><\/h2>\nVis\u00f5es de modelo ajudam a explicar as inten\u00e7\u00f5es da arquitetura para a realiza\u00e7\u00e3o dos objetivos do neg\u00f3cio, respeito as restri\u00e7\u00f5es e atributos de qualidade. S\u00e3o excelentes mecanismos para acelerar a compreens\u00e3o e promover o alinhamento de prop\u00f3sitos que promove a autonomia de atua\u00e7\u00e3o. A utiliza\u00e7\u00e3o de representa\u00e7\u00f5es, gr\u00e1ficas ou visuais, \u00e9 um impulso a agilidade!<\/strong>\n
\n

Na medida certa, a utiliza\u00e7\u00e3o de ADLs formais ajuda a garantir que aspectos importantes, durante a elabora\u00e7\u00e3o do design sejam considerados.<\/p>\n

\/\/ TODO<\/h2>\n

Antes de avan\u00e7ar para o pr\u00f3ximo cap\u00edtulo recomendo as seguintes atividades:<\/p>\n

    \n
  • Empenhe-se em construir algumas vis\u00f5es de modelo, para seus sistemas, com base nos exemplos e\u00a0templates\u00a0<\/em>indicados nesse cap\u00edtulo<\/li>\n
  • Revise conceitos fundamentais de UML<\/li>\n<\/ul>\n","protected":false},"featured_media":3966,"parent":0,"comment_status":"open","ping_status":"closed","template":"","url":[72],"sessoes":[57],"apendices":[],"capitulos":[61],"class_list":["post-3949","volume-1","type-volume-1","status-publish","has-post-thumbnail","hentry","url-permanente","sessoes-secao-1","capitulos-capitulo-1-4"],"acf":[],"yoast_head":"\nCap 1.4 Modelo, vis\u00f5es do modelo e al\u00e9m - Manual do Arquiteto de Software<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/modelo-visoes-do-modelo-e-alem\/\" \/>\n<meta property=\"og:locale\" content=\"pt_BR\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Cap 1.4 Modelo, vis\u00f5es do modelo e al\u00e9m - Manual do Arquiteto de Software\" \/>\n<meta property=\"og:description\" content=\"As pr\u00e1ticas de arquitetura de software, com frequ\u00eancia, est\u00e3o associadas a elabora\u00e7\u00e3o e manuten\u00e7\u00e3o de representa\u00e7\u00f5es, gr\u00e1ficas ou textuais, usando nota\u00e7\u00e3o livre ou uma ADL, destacando aspectos relevantes para o atendimento dos objetivos de neg\u00f3cio, respeito \u00e0s restri\u00e7\u00f5es e alcance de atributos de qualidade, com menor custo e risco. A finalidade da arquitetura de software […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/modelo-visoes-do-modelo-e-alem\/\" \/>\n<meta property=\"og:site_name\" content=\"Manual do Arquiteto de Software\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/facebook.com\/eximiaco\" \/>\n<meta property=\"article:modified_time\" content=\"2024-01-12T20:44:13+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/capitulo-1-4.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"600\" \/>\n\t<meta property=\"og:image:height\" content=\"338\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:site\" content=\"@eximiaco\" \/>\n<meta name=\"twitter:label1\" content=\"Est. tempo de leitura\" \/>\n\t<meta name=\"twitter:data1\" content=\"9 minutos\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/modelo-visoes-do-modelo-e-alem\/\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/modelo-visoes-do-modelo-e-alem\/\",\"name\":\"Cap 1.4 Modelo, vis\u00f5es do modelo e al\u00e9m - Manual do Arquiteto de Software\",\"isPartOf\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/modelo-visoes-do-modelo-e-alem\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/modelo-visoes-do-modelo-e-alem\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/capitulo-1-4.jpg\",\"datePublished\":\"2022-04-05T20:17:16+00:00\",\"dateModified\":\"2024-01-12T20:44:13+00:00\",\"breadcrumb\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/modelo-visoes-do-modelo-e-alem\/#breadcrumb\"},\"inLanguage\":\"pt-BR\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/modelo-visoes-do-modelo-e-alem\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-BR\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/modelo-visoes-do-modelo-e-alem\/#primaryimage\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/capitulo-1-4.jpg\",\"contentUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/capitulo-1-4.jpg\",\"width\":600,\"height\":338},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/modelo-visoes-do-modelo-e-alem\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Volume 1\",\"item\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"Cap 1.4 Modelo, vis\u00f5es do modelo e al\u00e9m\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/\",\"name\":\"Manual do Arquiteto de Software\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"pt-BR\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization\",\"name\":\"EximiaCo\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"pt-BR\",\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg\",\"contentUrl\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg\",\"width\":150,\"height\":150,\"caption\":\"EximiaCo\"},\"image\":{\"@id\":\"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/facebook.com\/eximiaco\",\"https:\/\/x.com\/eximiaco\"]}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Cap 1.4 Modelo, vis\u00f5es do modelo e al\u00e9m - Manual do Arquiteto de Software","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/modelo-visoes-do-modelo-e-alem\/","og_locale":"pt_BR","og_type":"article","og_title":"Cap 1.4 Modelo, vis\u00f5es do modelo e al\u00e9m - Manual do Arquiteto de Software","og_description":"As pr\u00e1ticas de arquitetura de software, com frequ\u00eancia, est\u00e3o associadas a elabora\u00e7\u00e3o e manuten\u00e7\u00e3o de representa\u00e7\u00f5es, gr\u00e1ficas ou textuais, usando nota\u00e7\u00e3o livre ou uma ADL, destacando aspectos relevantes para o atendimento dos objetivos de neg\u00f3cio, respeito \u00e0s restri\u00e7\u00f5es e alcance de atributos de qualidade, com menor custo e risco. A finalidade da arquitetura de software […]","og_url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/modelo-visoes-do-modelo-e-alem\/","og_site_name":"Manual do Arquiteto de Software","article_publisher":"https:\/\/facebook.com\/eximiaco","article_modified_time":"2024-01-12T20:44:13+00:00","og_image":[{"width":600,"height":338,"url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/capitulo-1-4.jpg","type":"image\/jpeg"}],"twitter_card":"summary_large_image","twitter_site":"@eximiaco","twitter_misc":{"Est. tempo de leitura":"9 minutos"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/modelo-visoes-do-modelo-e-alem\/","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/modelo-visoes-do-modelo-e-alem\/","name":"Cap 1.4 Modelo, vis\u00f5es do modelo e al\u00e9m - Manual do Arquiteto de Software","isPartOf":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website"},"primaryImageOfPage":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/modelo-visoes-do-modelo-e-alem\/#primaryimage"},"image":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/modelo-visoes-do-modelo-e-alem\/#primaryimage"},"thumbnailUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/capitulo-1-4.jpg","datePublished":"2022-04-05T20:17:16+00:00","dateModified":"2024-01-12T20:44:13+00:00","breadcrumb":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/modelo-visoes-do-modelo-e-alem\/#breadcrumb"},"inLanguage":"pt-BR","potentialAction":[{"@type":"ReadAction","target":["https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/modelo-visoes-do-modelo-e-alem\/"]}]},{"@type":"ImageObject","inLanguage":"pt-BR","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/modelo-visoes-do-modelo-e-alem\/#primaryimage","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/capitulo-1-4.jpg","contentUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/capitulo-1-4.jpg","width":600,"height":338},{"@type":"BreadcrumbList","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/modelo-visoes-do-modelo-e-alem\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/"},{"@type":"ListItem","position":2,"name":"Volume 1","item":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/volume-1\/"},{"@type":"ListItem","position":3,"name":"Cap 1.4 Modelo, vis\u00f5es do modelo e al\u00e9m"}]},{"@type":"WebSite","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#website","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/","name":"Manual do Arquiteto de Software","description":"","publisher":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"pt-BR"},{"@type":"Organization","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#organization","name":"EximiaCo","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/","logo":{"@type":"ImageObject","inLanguage":"pt-BR","@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/","url":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg","contentUrl":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-content\/uploads\/2022\/04\/simbolo-eximiaco.jpg","width":150,"height":150,"caption":"EximiaCo"},"image":{"@id":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/facebook.com\/eximiaco","https:\/\/x.com\/eximiaco"]}]}},"_links":{"self":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/volume-1\/3949","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/volume-1"}],"about":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/types\/volume-1"}],"replies":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/comments?post=3949"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media\/3966"}],"wp:attachment":[{"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/media?parent=3949"}],"wp:term":[{"taxonomy":"url","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/url?post=3949"},{"taxonomy":"sessoes","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/sessoes?post=3949"},{"taxonomy":"apendices","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/apendices?post=3949"},{"taxonomy":"capitulos","embeddable":true,"href":"https:\/\/elemarjr.com\/livros\/arquiteturadesoftware\/wp-json\/wp\/v2\/capitulos?post=3949"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}