Twin examples of multiple trees: 1. UML models, 2. Machine Learning



“Today, professionals get trained in using tools…  there’s a lack of education of fundamentals like modeling, architecture, methods, or concepts... Getting value out of data needs professionalization based on education and practical experience.”                                                                 
Andreas Buckenhofer, Daimler TSS, in an interview by OODBMS on Big Data, July 2019 
In my opinion, he’s spot on.

My post from March mentions why new AI languages aren’t exactly heavies of a CV in a mainstream business; in April, a figure (at the end of the post) also touched on Forest structures in ML and eXplainable AI.

After a free-wind sail that took us from detail to architecture, we now go into some structural “forestry”. It’s about tackling the same domain from multiple viewpoints, instead of clinging on to one.

1. Multiple trees in UML: Generalization sets
This post from 2015 (in Swedish) discusses the sets in more detail, so let’s just recap the diagrams, in English, and add «powertype» on the fourth one (a power set’s instances are subsets, so by the same token, a UML2 powertype’s instances are “subtypes” of a general construct).






2. Multiple trees in Machine Learning: random Decision Forests
Here, a designer is not the one who maps out subclasses. Rather, an ML algorithm generates in training time, from (labeled) data, an ability to perform classification (i.e accurate “mapping-out” of “classes”). The decision nodes of a (classification) tree gradually subdivide the data into more and more fine-grained classes.
Why bother about decision trees when Deep Neural Networks are booming? Because explainability opens the door to acceptance in mission-critical apps. ML-generated logic has to be auditable. User enterprises are pushing for graphicness, conceptualization, traceability, V&V. Those are the strengths of decision trees, and weaknesses of Deep NNs (we know those work, but hardly how); same thing with learning time required, size of training data sets, execution speed, or partitionability (a hint for IT architects: a tree works independently, whereas a neuron relies on many other ones). Atop of that, decision trees offer a structural backbone of hybrid AI systems (see also the last paragraphs in this post).

You might remember that trees in woods sometimes fuse their roots and exchange materials. Unsurprisingly, we find some synergy in virtual forests too. Firstly, our trees are “grown” on a random sample each (hence some “biodiversity” too), from one training-data set (hence fewer terabytes of training data). Secondly, on each sample, its tree’s decision nodes use a random subset of all available attributes. This gives architects and other roles some room to tune the mix of efficiency and explainability; in forests, it’s is near the level of genetic algorithms (GAs too have possible “mix-tuning points” in “biodiversity steps” Crossover and Mutation).



The more trees and “biodiversity” our ML algorithm grows, the more accurate and robust the generated logic becomes, because the final step is vote counting. A forest’s output (a classification like here, or a forecast) is an aggregated value of the outputs of all trees (a statistical mode in classification, or a mean in regression). It prevents the random decision forest from getting stuck in local optima, that is, we minimize error rates and overfitting to a given training-data set (which may be both incomplete and biased).

Trainer at Informator, senior modeling and architecture consultant at Kiseldalens, main author : UML Extra Light (Cambridge University Press) and Growing Modular (Springer), Advanced UML2 Professional (OCUP cert level 3/3).
Milan and Informator collaborate since 1996 on architecture, modelling, UML, requirements, rules, and design. You can meet him in September at public courses (in English or Swedish) on AI, Architecture, and ML (T1913), Architecture (T1101, T1430) or Modeling (T2715T2716).



Yet another AI language you miss in your CV? 4 reasons why it will matter less and less.


It never hurts, but it varies how helpful a (fairly) new programming or script language is. From more or less a prerequisite in R&D and platform-vendor firms, to a nice-to-have CV footnote in mainstream businesses that rather emphasize extended SQL, analytics , data architecture, and automated ML platform/s.

Here are 4 reasonswhy you can live with it (ascending order by weight)

1. The fate of LISP, Prolog, Smalltalk, KQLM etc. (use comment form below to fill in what’s missing : ))
To drive the history of applied “AI 1.0” to the extremes, an enterprise in the 1980-ies was expected to achieve superpowers as soon as the CIO (and preferably, CEO : )) learned at least one exotic-enough AI language. The subsequent AI winter after 1990 happened supposedly because most CIO’s refused to so; best case: they got lost somewhere inside their fifth pair of nested parentheses in LISP (like most of us devs did too, including myself)…

2.
The rise of expert-system development shells in business (near 1990)
Programming languages are versatile. You can get anything you need, given a generous timeframe. Development tools encapsulate a lot of technical detail. You can get more or less what you need, even under tight time constraints. No wonder it’s more appealing to CIOs than nested parentheses.

3. Success of those who used then-mainstream industry languages
 
Books on configurators, or on LISP, drill down into Digital (HP) XCON/R1, but in books on management and modular manufacturing, you read about Scania Trucks & Buses (reporting profits for 80 consecutive years). Scania’s smart proprietary configurator (an age fellow of XCON) became a backbone of the enterprise, and grew to several times the size of XCON. Unlike XCON, Scania did cope in maintenance and upgrades. For decades. Offering complex customized vehicles assembled from a cluster of common component types. Language: unglamorous then-mainstream Cobol and DL/1.

4. A trend toward frameworks, component libraries, automated analytics & ML platforms
It’s a two-way street. On one hand, “AI 2.0” and ML challenge current architectures, not least data architectures: big-data ingestion, parallelism, fast access aid for non-sequential access because learning (in both human and artificial neural networks) is essentially non-sequential (parallel).
On the other hand, ML offers a toolbox to tackle these challenges, and also, enables quite some automation of the entire data pipeline and of an architect’s (or dev’s) repetitive tasks. I won’t be surprised if automated-ML platforms for big data, using extended SQL instead of script languages, spark success stories of Scania’s magnitude. It’s about the augmentation (or automation) itself, and about architecture fit for business, rather than about the detail.
So from now on, Informator’s new one-day course is called AI, Architecture, and Machine Learning. Neither just AI for Architecture, nor just Architecture for AI. It’s a two-way street.

Rapid progress in the middle
Figure from course AI, Architecture, and Machine Learning (T1913)

Trainer at Informator, senior modeling and architecture consultant at Kiseldalen.com, main author : UML Extra Light (Cambridge University Press) and Growing Modular (Springer), Advanced UML2 Professional (OCUP cert level 3/3).

Milan and Informator collaborate since 1996 on architecture, modelling, UML, requirements, rules, and design. You can meet him this Spring at public Architecture courses in English or Swedish (T1913, T1101, T1430) or Modeling courses ( T2715T2716)
     


Konsument-IT som liknar företags-IT

Christer Norströms presentation under SICS Open House 2018 handlade om hans intelligenta träningstjänst Racefox. Den stödjer individanpassad uthållighetsträning för löpare och längdåkare. Arkitekturen och kraven på Intelligenta träningsassistenter ligger ungefär halvvägs mellan ”vanlig” konsument-IT (gadgets) och företags-IT (mission critical).

Expertanvändare i gränslandet
Christer (tidare VD på SICS) med sina slides fick mig att mer eller mindre ångra två saker. Dels att jag la av med triathlon för ett antal år sedan. Dels att jag brukar dra den vanliga gränsen mellan B2C (Business-to-consumer) och B2B lite väl skarpt, oftast för att lyfta fram skillnaden i kvalitetskraven mellan dem.

Med tiden har Racefoxs logik utökats med skadeförebyggande eller –rehabiliterande inslag i träningen, i realtid, och då landar vi i gränslandet: expertkonsumenter minst lika pålästa om sin nischproblematik som processägaren på ett företag är om sin. Höga krav på tillförlitlighet, snabbhet (RT), exakthet. Samtidigt högt ställda förväntningar på att behålla kunderna (Racefox är uppe in en customer-retention faktor efter 1 år på 95%).

Arkitektur och arkitektroll
Autonoma Machine Learning (ML) system är ofta indelade i fyra lager, inte så olikt RT-system:
1. Perception (från input genom t ex Racefox kroppssensorer eller bilens givare)
2. Mönsterigenkänning (t ex kroppsställning och stavtag hos Racefox eller ojämn gång i en motor)
3. Analys, resonemang, beslut (dvs mönsterutvärdering och val av nästa steg)
4. Direkt åtgärd (t ex minska varvtal) eller interaktion (t ex varning genom genererad röst i skidlöparens hörsnäcka, eller ett anrop på bilverkstadens diagnostiksystem över Internet of Things).

Layered (arkitekturmönster). Modifierat från Informators kurs Avancerad Modellering (T2716).

Varje lager kan innehålla även ML-komponenter (t ex neurala nätverk tränade för sin nisch). Det gör en stor och trogen användarbas extra intressant, eftersom systemet blir smartare med tiden då det lär av allt längre tidsserier data från alltfler individer.

Bästa bakgrunden för en arkitekt blir då kunskap om domänen, om affären, om ML, om varje lager, och om samspelet mellan dem. Christer Norström kallade rollen value architect.

Milan Kratochvil
Informatorlärare, senior modeling & architecture consultant Kiseldalen.com, huvudförfattare: UML Extra Light (Cambridge University Press) and Growing Modular (Springer), Advanced UML2 Professional (OCUP cert level 3/3).


Milan och Informator samarbetar sedan 1996 inom arkitektur, modellering, UML, krav, och design. Du kan träffa honom på öppna kurser i Arkitektur på engelska eller svenska ( T1101, T1430) i maj och juni, eller i Modellering i maj ( T2715, T2716).

Leveled up: Auditability of AI and Machine Learning


Architects and many others remember the tightrope walk between flexibility/performance and testability/predictability/V&V in systems with many run-time parameters, or parallelism, or late binding time ranging from polymorphism to SOA-UDDI and ad-hoc computing. Now, it’s leveled up by ML (machine learning). Essentially the same tradeoff, but growing broader and trickier. 

Black box 

ML stirs up the fire; despite its roots (rule induction and mining) in the successful decryption of an unbreakable cipher, its near future looks encoded in weight values somewhere in deep neural networks. Whereas black-box flight recorders clarified the chain of events & decisions in past emergencies, more and more IT is now landing in black boxes that hide opaque logic.

Predictability wasn’t a big deal in consumer IT and entertainment (when Youtube or Spotify wrongly offered you a title you were avoiding like the plague, you rarely asked why)… If you just say “skis this wide apart look amusing”, I guess you’re in consumer IT, but if you insist on a layer-by-layer explanation why most artificial vision systems have a hard time in strong sunshine on white slopes, I bet you’re in corporate (image: Ski Robot Challenge, Korea). 

Tackle it one-way or two-way

Business apps are very different from apps for billions of consumers (see slides 9 to 15 in this talk by Oracle’s VP at SICS). Your enterprise or team can tackle the leveled-up tradeoff both top-down and bottom-up:

  • assuring a framework of corporate values and procedures (particularly transparency, governance & compliance, accountability, and a security & safety culture)
  • applying appropriate technologies and practices in IT to build in mechanisms upfront  for auditability, comprehensibility, predictability, traceability, testability/V&V (as well as fraud-prevention, such as restricted access to learning-data sets).       

On the latter (bottom-up) part, there’s ongoing AI research to “unpack” the opaque logic buried within deep learning systems, and to give them an ability to explain themselves. DARPA’s Explainable AI Program, XAI , aims at ML techniques (new or improved) that produce more explainable models, while maintaining a high level of prediction accuracy. New machine-learning systems will have the ability to explain their rationale, strengths, weaknesses, etc.

Hybrid-AI tech vendors often address organizations with more constrained schedules, budgets and levels of AI expertise. Hybrid learning systems combine “subsymbolic” ML with transparent symbolic computation (typically, wellknown knowledge-processing techniques). The combination lowers the total cost of entry into AI and ML, because it evolves from logic that domain experts already know (rules, decision trees, etc.)

From there, hybrid systems employ ML iteratively to fine-tune this explicit logic: for example, to narrow the IF-part of a rule to factors that prove most significant. That is, results of ML from big data decide about variables to be included (or omitted), about intervalization of a continuum of values, or about relevant threshold values of a particular variable.

Notably, a rule is still expressed as a rule yet with an ever-smarter and more accurate IF-part. This is transparent to humans, and paves the way to embedding AI and ML into daily IT-dev practice: devs and architects will gradually find thousands of decision points, enterprise-wide, suited for small AI apps in daily business. Those will generate valuable skills, know-how, and “tip feeling” as to where ML can work (or can’t).

Models, animations, transparency

Once the opaque logic is unpacked, or expressed as rules or trees, it’s time to revive your team’s modeling skills. Long story short, a decision tree (or an invocation path through a rule base) is an excellent input to animations or test executions of different scenarios, to make them transparent even to stakeholders and non-IT roles. That story is worth another blog post, later this spring.


by Milan Kratochvil
Trainer at Informator, senior modeling and architecture consultant at Kiseldalen.com, main author : UML Extra Light (Cambridge University Press) and Growing Modular (Springer), Advanced UML2 Professional (OCUP cert level 3/3).Milan and Informator collaborate since 1996 on architecture, modelling, UML, requirements, and design. You can meet him at public Architecture courses in English or Swedish ( T1101T1430) in April, May, and June, or Modeling courses in May ( T2715T2716).



Auditability and V&V in the era of Machine Learning are worth a close review…

Developers, more often than architects, tend to get frustrated by declarative programming, because it boosts expressive power at the cost of less testability. Yet both the boost and the drop are a mild breeze compared to self-modifying and sub-symbolic Machine Learning (ML).

Reviews by humans
You can hardly get away without ML in today’s AI. It would be like a mainstream relational DB without SQL, or like a rule engine without declarative rules. And, you’ll run into auditability issues in all three, but they tend to be an order of magnitude bigger in “sub-symbolic” ML. It’s much easier to check whether the learning works accurately (a black-box test of a “black organism” ), than to see why or how. A clear-box view relates to the generated logic almost as loosely as an MRI-scan relates to what a patient is thinking.

Japanese industry robots started to assemble robots back in 2001. Today, robotics vendors offer complete lights-out manufacturing systems (in other sectors referred to as “no man in the loop” earlier). So, needless to say, auditability and reviews by humans are a key architectural issue. Be discrete precision manufacturing, avionics, automotive, power generation, medical equipment, or any other application where approval criteria (ISO etc.) are strict.

Decision-tree induction from data
 When the work of professor DonaldMichie (a distinguished codebreaker ahead of D-day) resulted in the first ML algorithms for rule mining and decision-tree induction from data, those were able to show the learnt-in logic as diagrams or rules, and even to generate conditional constructs in a mainstream programming language. This became particularly useful in the elicitation and processing of tacit knowledge (the implicit “knowwhy” underlying the explicit knowhow of a human).

Many IT roles are quite familiar with declarative rules, although in narrower contexts: In DB schemas (or UML models), the rules are typically about referential integrity along the lines of “on Delete cascade” in SQL DDL (see also the exclusive-or, {xor} , in the UML diagram). In design, rules are often invariants and preconditions/postconditions. In modeling, a UML state diagram defines visually the rules that govern event handling and state transitions. Etc.




A role model, UML pun intended, with an either-or referential integrity.
From Informator course AvanceradModellering, T2716 (structure-models chapter). 


Case Bases
The technology that followed in inductive ML (after decision-tree induction), Case Based Reasoning (CBR), was instance-based and used lazy generalization which expressed the induced commonalities (between cases in the learning-data set) only later, at test time. Although less explicit than decision trees or rules, this was still fairly comprehensible for humans to review.

Sub-symbolic “representation” of knowledge
However, the commercial breakthrough of self-modifying technologies, mainly neural networks and evolutionary algorithms, made audits both hot and tricky. In a neural network, the logic learnt during training is sub-symbolic, “packed” into weight values on connections and artificial neurons. Roughly speaking, a clear-box view relates to the generated logic almost as loosely as an EEG record relates to what a patient is thinking.

Therefore, many researchers argue that audit-related abilities of a subsymbolic-ML system, like reasoning about itself and meaningfully visualizing/animating/explaining its logic or its conclusions, improve greatly when its ML is combined with other (likely symbolic) AI techniques. If so, this is one of the rare cases in architecture where complexity and testability actually enhance each other rather than restrict.
     
Summing up
Architecture is not exempt from ML’s impact on AI, IT, and business processes. Although auditability was brought to the table already when robots started to assemble other robots, it is crucial today in all kinds of ML systems in a vast variety of applications and industry sectors.



Trainer at Informator, senior modeling and architecture consultant at Kiseldalen.com, Advanced UML2 Professional (OCUP cert level 3/3). Main author: UML Extra Light (Cambridge University Press) and Growing Modular (Springer).
Milan and Informator collaborate since 1996 on architecture, modelling, UML, requirements, analysis and design. In the next couple of months, you can meet him at Architecture ( T1101 , T1430, in English or Swedish) or Modeling courses ( T2715T2716 , mostly in Swedish).

Arkitektur, UML, och 3 varianter av ett vanligt Designmönster: Proxy


I min gästblogg i september nämnde jag i förbigående att några få mönster kvalar in som både design och arkitektur. Proxy (beskriven redan i boken Design Patterns av Gamma & GoF) är ett enkelt exempel på det. Skillnaderna mellan dess tre vanligaste varianter är små. Ändå prioriterar de var sina kvalitetsegenskaper (QA) och därmed också arkitekttaktiker.




Bild: Klassdiagram i UML för Proxy Design Pattern (strukturen liknar Decorator, men syftet är något helt annat).  

Man börjar med frågan: hur mycket av det här har vi redan i  plattformen, ”på burk”? Först sedan kan det bli aktuellt att välja variant och att ev anpassa den vidare. Arkitekten tar även hänsyn till runtime, möjliga svagheter i samband med uppgraderingar, säkerhetshot, belastningstoppar, fel i handhavande osv.

Variant 1: Remote Proxy

Klassikern i distribuerade system, där den ofta tillhör ”rördragningen” i plattformen/mellanvaran, så att applikationsutvecklare slipper göra den för hand. Ett lokalt objekt (av klassen Proxy i diagrammet) företräder ett avlägset (av VerkligOrder), som kan ligga i en annan komponent, namespace, server, osv. Ett anrop på Proxyn vidarebefordras av den till rätt ställe, utan att avsändaren behöver känna till hur (det är Proxyns ansvar). De som gått kursen Agil Modellering med UML kommer nog ihåg sekvensdiagramsövningen, där bankomaten ”pratar” med sin bank-proxy, och slipper ”se” ”verkliga banken” (kommunikationen är inkapslad i proxyn).

Kvalitetsegenskaper: interoperabilitet (taktik: skräddarsy gränssnitt), modifierbarhet (kapsla in, använd mellanhand, begränsa beroenden, senarelägg bindningstid), testbarhet (begränsa komplexitet, abstrahera datakällor, förenkla sandboxing och fakes på delsystem- eller komponentnivå).        

Variant 2: Virtual Proxy

En mer kompetent ställföreträdare, för ett resurskrävande objekt. Minimerar antalet (resurskrävande) instansieringar, och undviker dem helt i enklare fall, genom att utföra ofta anropade operationer själv lokalt (i proxyn, i stället för att skicka vidare).

Anta i diagramexemplet att orderobjekten ligger i sina respektive län (t ex 1 server per län, alternativt index i cache per län). Om aktuellt värde i parametern(typ) till operationen extraRabatt betyder ”kampanj: efterskänk frakt på alla order i Norrbotten” så slipper Proxyn instansiera objekt från andra län. Proxyn kan alltså (i förbehandlingssteget i metoden) filtrera bort onödiga instansieringar. Om varje proxyobjekt dessutom byggs på med ofta efterfrågat orderspecifikt data (som tex orderdatum och summa) kan proxyn avlasta ordern från alla enkla anrop, och instansiera den bara i mer sällsynta komplicerade fall. Dvs dels liknande fördelar som med typen Lazy i dotnet, dels anpassningar från fall till fall.

Kvalitetsegenskaper: tillgänglighet (taktik: redundans), prestanda (minska resursbehov i enkla anrop, öka resurseffektivitet), modifierbarhet (kapsla in, begränsa beroenden, senarelägg bindningstid), testbarhet (abstrahera datakällor, förenkla sandboxing och fakes på delsystem- eller komponentnivå).       

Variant 3: Protection Proxy

Surrogat för eller säkerhetshölje för ett annat objekt. I likhet med Virtual kan den besvara en del (mindre känsliga) anrop själv. Dessutom styr den åtkomst till objektet (tex till verkligOrder) baserat på accessrättigheter. I exemplet skulle det kunna vara fritt fram att tex se orderdatum givet ett ordernr (proxyn kan verkställa själv mha ett index), men för att visa mer (dvs att få ”titta in i ordern”) skulle proxyn först göra en behörighetskontroll.

Kvalitetsegenskaper: säkerhet (taktiker: upptäck intrång, verifiera aktörer, begränsa åtkomst, begränsa exponeringsytan utåt), prestanda i mindre känsliga anrop (minska resursbehov, öka resurseffektivitet).      

Ett helt kapitel om Design Patterns finns bl a i kursen T2716 Avancerad modellering med UML. Kvalitetsegenskaper (QA) går man igenom i kursen T1101 Architecture Fundamentals. 

// Milan Kratochvil konsult, Kiseldalen.com och kursledare hos Informator inom IT-arkitektur.

Huvudförfattare: Growing Modular: Mass Customization of Complex Products, Services and Software samt UML Xtra Light: How to Specify Your SW Requirements
UML 2 Professional, OCUP Advanced Level (certifikatnivå 3 av 3)

Milan samarbetar med Informator sedan våren 1996 inom modellering, UML, krav, analys, arkitektur och design. Håller f.n. kurser i modellering, grundläggande arkitektur, Modular Product Line Architecture (T1430), och 2013 höll han också Informators fullsatta Frukostseminarium om användningsfall.



2 varianter, 1 Design Pattern - blir fler än 3 punkter för arkitekten

I min gästblogg i oktober, om att avlasta UML från ”notation bloat”, nämnde jag behovet av abstrakt arkitekttänkande.

Designmönster lyfter i sig abstraktionsnivån (i likhet med andra mönster) utöver notationen, samtidigt som man behöver arkitekturtänkande för att välja ett passande mönstervariant, och för att göra egna anpassningar (eller låta bli).

Det första man alltid frågar sig är: hur mycket av det som mönstret löser har vi (eller plattformen) redan färdigt ”på burk”? Först sedan funderar man på möjliga varianter. Ett mönster löste ett vanligt praktiskt problem när det publicerades (och därför fick det den spridning det har), men sedan dess har ju många plattformar löst och kapslat in en hel del sådant som applikationsutvecklare kan slippa göra för hand; vilket leder in på samma spår som mitt notations-inlägg i oktober, fast nu på Pattern-nivån.

Ett välkänt mönster är State: ett vanligt objekt (”context-objekt”, i diagrammet nedan en order) kopplas ihop med 1 separat state-objekt, vilket får det att fungera utåt som om objekt kunde byta klass (oavsett plattform – det är fritt fram för den som växte upp med Smalltalk80 att kalla det ”att härma Smalltalks Tillståndsklasser för hand på andra plattformar”). Om vi inte redan har den möjligheten ”på burk” så är vi framme vid tänkbara anpassningspunkter. En sådan är multipliciteten åt andra hållet på Klassdiagrammet, dvs på Context-sidan: ska ett State-objekt vara dedicerat till exakt 1 Context-objekt (det vanliga, alltsedan Gamma & GoF.) eller ska man tillåta att flera Context-objekt servas av samma State-Objekt (dvs multiplicitet ”*” ) ?

Sett med utvecklarglasögon behöver flera villkor vara uppfyllda för att ”*” skall komma ifråga: inga attribut i State-objektet (frånsett static, som t ex text för State-specifikt felmeddelande), möjlighet att vid nästa tillståndsövergång enkelt länka om objektet till nästa State-objekt, osv. Med arkitektglasögon ser man ytterligare villkor som bör vara uppfyllda: inga stora belastningstoppar (köer) på State-objektet, fördelarna med att byta minnesbehov (då multiplicitet 1 till 1 medförde fler State-objekt i runtime) mot ev processortid ska vara större än nackdelarna, inga ”single point of failure” problem, enkelt att göra State-objekt persistenta i minnet, ”D:et” i SOLID (Dependency inversion/injection, med t ex en Callback, eller direkt mha plattformen), replikering när man skalar ut (t ex ytterligare servrar), tillräckligt förklarande dokumentation för att utvecklare skall förstå anpassningen även framöver, osv. Även om notationen skiljer ”bara” ett tecken som i exemplet ( ”*” i stället för ”1”), så är konsekvenserna av anpassningar klart större än så.


   
Som applikationsutvecklare fokuserar man oftast på design och källkod; arkitekturtänk tar även med runtime-miljö, samspel med verksamheten och produkten, risken för svaga punkter i samband med uppgraderingar, säkerhetshot, belastningstoppar, fel av användaren m m, allt i ljuset av prioriterade krav på funktionalitet resp på övrig kvalitet (jfr t ex  40 ”kvalitetskarakteristika” i ISO 25010-bilden i min gästblogg den1 september).


En annan och mer långtgående anpassning av samma Design Pattern (State) kan man ev välja i en övning på kursen T2716 Avancerad modellering med UML (sekvensdiagram, avboknings-scenario med kö/väntelista till det som bokats av), som ett möjligt designalternativ till att byta state-objekt på vanligt sätt.   


// Milan Kratochvil konsult, Kiseldalen.com och kursledare hos Informator inom IT-arkitektur.

UML 2 Professional, OCUP Advanced Level (certifikatnivå 3 av 3)

Milan samarbetar med Informator sedan våren 1996 inom modellering, UML, krav, analys, arkitektur och design. Håller f.n. kurser i grundläggande Arkitektur, Modular Product Line Architecture (T1430), i modellering (T2715T2716), och 2013 höll han också Informators fullsatta Frukostseminarium om användningsfall.

6 reasons to prefer a «use» Dependency to «instantiate» and «create».

Less is more in UML models.

My guest blog on May 20th mentioned that Ivar Jacobson's and Microsoft architect Steve Cook's article about the “road ahead”, toward a slim UML3 kernel with extension mechanisms (2010, on Dr Dobbs), makes even more sense in 2015 than back in 2010.

1. Standard subtleties
The new, slimmed UML 2.5 spec (March 2015, by the OMG), table C.1 (included keywords) lists only «use» and none of «create» or «instantiate»; the text also states it's an open list. That makes it one of the steps down the Jacobson & Cook road to a much-welcome smaller kernel with a very simple extension mechanism.  

2. Practical subtleties
The distinction between a «create» and an «instantiate» Dependency is tiny.
Both are shades of usage, so that «use» would suffice in most cases: the source uses the target (for some reason — be instantiation or other).

3. Interpretation subtleties
I’ve often wondered whether the slightly higher expressive power was worth the hike in notation bloat. I used «create» the standard way, for instantiation with full initialization of attribute values, typically from in-parameters passed through the constructor operation. By the same token, I used «instantiate» for raw instantiation (with just zeroes or similar default values instead), but that didn't make any difference to the many who interpreted «create» and «instantiate» as synonyms anyway… The 2.0 notation, especially arrow direction, hardly made things easier to explain:
 - Creation: a dashed arrow (…) to the creation operation.
 - Instantiation: a dashed arrow from the operation performing the instantiation.

4. Usefulness subtleties
Middleware, SOA UDDI, auxiliary classes, object-relational mappers such as Hibernate, and Design Patterns such as Factory, automate and encapsulate more and more of object loading, instantiation, or creation. That is, mainstream technologies make it less and less meaningful to model its detail, see diagram 1 (I might imagine a simple illustration in an architecture document, to explain the architectural principle and the mechanism once and for all, i.e. once per company or group of companies, definitely not every time applications incorporate the mechanism).

In contrast, I occasionally showed «create» explicitly, back in the early days of UML, to explain why there were both a «call» Dependency to an «interface» (operations in the interface are called, «call» being a third stereotype of «use» ) and along with that one, another Dependency ( «create» ) as a "shortcut" actually bypassing my nice «interface», see diagram 2.

That was pretty common in a simple environment without any automatism: the designer of the caller ensured "by hand" that there was an implementing object behind the «interface», to begin with. Which meant, the caller «create»d this object before the first call.

Some people argued that two «use» Dependencies (one for the creation, one for the calls) would be too generic for such cases. So, for the incorrigible «create» fan, remember the “open list” in the current UML 2.5 standard: no big deal extending the list, for company-internal purposes (e.g. for code generation).










5. Separation of concerns
This is a key idea underlying both the UML and Informator’s courses (T2715 and T2716): avoid a split of focus, don’t force-fit a whole bunch of areas of concern into a Class Diagram. Sequence diagrams show creation graphically (ever since UML 1) without a keyword, plus they do it “in context” of the actual scenarios where it happens. So, where detail really matters, they’re better and more precise to show creation. 

6. Abstraction
Abstraction is a vital point in architects’ job description. With the current shift of focus from detailed design to architecture, the level of abstraction thus shifts as well: to components or subsystems.

A Dependency between Components “summarizes” the fact that some Class/es or subcomponent/s in one Component have relationships to their counterparts in another Component; at this level of abstraction, it rarely makes sense to show the detail of loading or creation (unless you're a platform & infrastructure vendor). Rather, the UML 2.5 “kernel” seems to take mainstream built-in functionality into account.  


// Milan Kratochvil consultant, Kiseldalen.com and teacher in IT architecture at Informator.

UML 2 Professional, OCUP Advanced Level (level 3, of 3)


In addition to consulting, Milan cooperates with Informator since 1996 in modeling, UML, requirements, analysis, architecture and design. He currently teaches courses and workshops on Architecture fundamentals, Modular Product Line Architecture (T1430), agile modeling (T2715T2716), and formerly also Informator’s full-up Seminar on Use Cases.