{"id":25174,"date":"2015-05-20T00:00:00","date_gmt":"2024-09-13T08:48:24","guid":{"rendered":"https:\/\/wordpress-583806-4798031.cloudwaysapps.com\/agile-modeling-and-architecture-under-paradigm-diversity\/"},"modified":"2024-11-15T16:22:35","modified_gmt":"2024-11-15T15:22:35","slug":"agile-modeling-and-architecture-under-paradigm-diversity","status":"publish","type":"post","link":"https:\/\/informator.se\/en\/agile-modeling-and-architecture-under-paradigm-diversity\/","title":{"rendered":"Agile modeling and architecture under paradigm diversity"},"content":{"rendered":"

<\/p>\n

Many expert notes here mention non-relational paradigms, and these coincide with non-procedural trends in programming \u2014 in contrast to a past of procedural\/imperative languages hosting non-procedural SQL-only statements<\/span><\/b>; a fine combination in theory, yet often misinterpreted by host-language programmers who habitually hand-wrote loops reading one table line at a time and thus duplicated (in the host language) the tedious work that SQL and RDBMS engines had automated in the first place.<\/span><\/div>\n
<\/div>\n
Today, there are several programming paradigms<\/i> to choose from, in both data-intensive applications and signal-intensive (e.g. the Ericsson ERlang language and its spinoffs), as well as data-architecture paradigms<\/i>. Also, architects now apply several integration patterns<\/i>, apart from shared data stores. These trends largely match with the Object Management Group\u2019s initial mission from 1990: to \u201cnarrow the communication gap\u201d between IT and business by lifting the level of abstraction. At the same time however, the diversity and rapid pace of hardly-predictable change have made it more difficult to revise the corresponding standards in time.<\/o_p><\/span><\/div>\n
<\/div>\n
Given an agile approach, architects communicate via lean documents that address known roles and their expected information needs, although the ever-expanding architectural landscape makes even these needs change faster.<\/o_p><\/span><\/div>\n
<\/div>\n
The detailed notation bloat within the Unified Modeling Language often gets in their way (even the slimmed, OMG UML 2.5 spec is still 800 pages), because abstraction is key in the job description of an architect.<\/o_p><\/span><\/div>\n
<\/div>\n
The difference in abstraction between two sequence diagrams (architecture level versus detailed level) is visible in this note<\/span><\/a> even if you don\u2019t read a Nordic language. A flight-price calendar on an airline-booking page is put together there, day by day. The text points out that the UML lifeline decomposition (resulting in the detailed <\/span>right-hand <\/span>part of the second diagram) is of little importance to architects and can be misleading too, because nobody knows in design time what the actual scenario path will look like, in run time, after access optimization by the DBMS. Given a non-procedural platform, we can suppress the detail without loss of clarity in communication (with most roles).<\/o_p><\/span><\/div>\n
<\/div>\n
Microsoft\u2019s architect Steve Cook mentioned already five years ago (on his <\/span>MSDN <\/span>blog<\/span><\/a>) that even mainstream OO PL<\/i>s are <\/span>all poorly represented by \u201cvanilla UML class diagrams\u201d<\/span>.<\/o_p><\/span><\/div>\n
That\u2019s very true in today\u2019s multitude of paradigms, and evolution of high-level constructs within Java, Dotnet\/LINQ, and more (<\/span>prof. Reichenbach\u2019s big-data article here<\/span><\/a> mentions that declarative languages \u201ccan offer the quickest path from idea to implementation\u201d<\/span>). With <\/span>multicore and multithread, non-procedural languages also facilitate automation by compilers, which makes them less prone to programmer error than procedural ones. To architecture, they add a reasonably restricted vocabulary (fewer ways to do one thing), improving semantic coherence and standards (and thereby maintainability and quick upgrades, to make the enterprise more responsive). <\/o_p><\/span><\/div>\n
<\/div>\n
I recently re-read Steve Cook’s and Ivar Jacobson’s article about the \u201croad ahead\u201d toward a slim UML3 kernel plus an extension mechanism (2010, on Dr Dobbs<\/span><\/a>), and it makes even more sense with today\u2019s diversified architectural toolbox. They are met with sympathy \u2014 but still a way to go, down the standardization road. <\/o_p><\/span><\/div>\n
<\/div>\n
Summing up, today\u2019s diversity <\/span>of integration patterns, programming paradigms, and data-architectures (including in-memory storage & computing) transfers and encapsulates a wider variety of detail into extended platforms and infrastructure. This in turn gives cause for a shift of emphasis in modeling, from \u201cvanilla-design detail\u201d and \u201cvanilla-code generators\u201d to an architect level in encapsulation (of, typically, procedural detail), <\/span>matching with the Object Management Group\u2019s initial mission<\/span>.   <\/o_p><\/span><\/div>\n
<\/div>\n
\n
<\/a><\/div>\n

\/\/ by <\/span>Milan Kratochvil<\/a>,  <\/span><\/span>Trainer at Informator, and senior modeling and architecture consultant, Kiseldalen.com, Author (w. Barry McGibbon) of UML Extra Light (Cambridge University Press). <\/span>Milan<\/u1_city><\/u1_place> and Informator collaborate since 1996 on modelling, UML, architecture, requirements, analysis and design. In June, you can meet Milan at Architecture ( T1101<\/a> , T1430<\/a>) or Modeling courses ( T2715<\/a>, T2716<\/a> , in Swedish).<\/span><\/p>\n

<\/o_p><\/span><\/div>\n<\/div>\n
\n

Posted by courtesy of  ODBMS.ORG<\/a><\/b> \u2014The Resource Portal for Big Data, New Data Management Technologies and Data Science<\/i><\/span><\/span><\/p><\/blockquote>\n<\/div>\n

<\/span><\/span><\/p>\n

\u00a0<\/span><\/span><\/h4>\n

<\/span><\/span><\/p>\n<\/div><\/div>","protected":false},"excerpt":{"rendered":"

Many expert notes here mention non-relational paradigms, and these coincide with non-procedural trends in programming \u2014 in contrast to a past of procedural\/imperative languages hosting non-procedural SQL-only statements; a fine combination in theory, yet often misinterpreted by host-language programmers who habitually hand-wrote loops reading one table line at a time and thus duplicated (in the […]<\/p>\n","protected":false},"author":6,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[570,922,1],"tags":[],"class_list":["post-25174","post","type-post","status-publish","format-standard","hentry","category-blogg","category-blogi","category-okategoriserad"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t