Vilka av de 14 bör alltid ingå?
Det finns lika många svar som roller, produktfamiljer, eller applikationsområden. Michael A. Jackson (min forne arbetsgivare) kategoriserade applikationsområden i ett antal Problem Frames, som t ex operatörs- och övervakningsstöd, editorer (för text, bild, presentationer), styrsystem och automation, informationssystem, fil- och dataomvandling, osv.
När det klarnat vilket/vilka ”frames” som kommer att dominera projektet är det lätt att välja bland både diagram och metoder/processer/arbetssätt. I agil modellering är det syftet som avgör. I den vanliga jämförelsen med hus (där olika ritningar visar grund, byggnad, VVS, el, tele, bredband osv) fungerar Problem Frames även som arkitekturgrund. I en blivande ishall eller gym behöver man lyfta fram andra saker än i en villa, och på samma sätt blir arkitekturen för ett processtyrningssystem olik en editor.

Lika viktig är anpassning till mottagaren och situationen. Ett litet axplock från tidigare kunder där helt olika saker hamnat i fokus: arkitektur för ärendehandläggning (med event sourcing, pga strikta myndighetskrav på diarieföring), modellering av mjukvara för bilar, och ett grafiskt UML-baserat utbildningshjälpmedel för inskolning av nyanställda tjänstemän hos en storkoncern over there (visualiserar hur olika typer av ärenden passerar genom koncernens komplexa systemportfölj – för att förankra arkitekturen i organisationen). Alla tre applikationerna var ju IT och UML, men naturligtvis blev modellerna helt olika och började med var sin (olika) diagramtyp som grund.  
”Lagom” i modellering är lätt att orda om men sådär lagom lätt att pricka in för projektet. I det ena träsket lurar skakig arkitektur och luddiga krav med stort utrymme för dyra feltolkningar. I det andra lurar TAGRI (They Aren’t Gonna Read It) och en marginalkostnad som överstiger marginalnyttan. Scott Ambler (Ambysoft, tidigare IBM Canada) använder fem kriterier för lagom bra modeller: (1) verkningsfulla/anpassade till mottagaren, (2) ändamålsenliga i en given situation, (3) av tillräcklig kvalitet, (4) ändras och uppdateras när det behövs, (5) färdiga tidigare än man trott.
Oftast landar jag på 3 till 6 diagramtyper, aldrig på 14 (”you can still build significantly complex systems using only three diagrams” – som RT-UML gurun Bruce Powel Douglass uttryckt det).
Nästa gallringsomgång gäller innehållet – dels att delar som inte tas med i modellen verkligen är irrelevanta, dels att rätt saker hamnar i rätt diagram, och dels att var sak modelleras (enbart) på sin plats i modellen (”separation of concerns”). Detta för att slippa splittra fokus med ”too much to see” och för att undvika dubbelarbete – i nuet, i kommande iterationer, i nya versioner osv. Även den här gallringen kräver eftertanke. Det finns många exempel på överlapp, redundans (”var sak på sin uppsjö av platser”) och onödigt dubbelarbete som hämmar användningen av modeller.
Summan av detta leder in på strukturen för en agil modelleringskurs. Den bör använda ett smalt urval av diagram, visa var sak på sin plats, visa hur UML-diagrammen hänger ihop och kompletterar varandra i en modell, och lära ut notation (”alfabet” och ”ordförråd”) invävd i modellering (”skrivstilar”) – med andra ord, välkommen på kurs hos Informator (som tänkt på ”valuta för modelleringspengarna”, så kurserna utgår från praktisk användning och innehåller en hel del övningar).
Milan Kratochvil
konsult, Kiseldalen.com
UML 2 Professional, OCUP Advanced Level (certifikatnivå 3 av 3)
Huvudförfattare UML Xtra Light – How to Specify Your SW Requirements
Samarbetar med Informator sedan våren 1996 inom modellering, UML, krav, analys och design. Håller f.n. kurser i Arkitektur, i modellering (T2715, T2716), och (februari 2013) även Informators fullsatta Frukostseminarium om användningsfall.

Livet efter ITIL Foundation – En individ lär så länge hon lever, en organisation lever så länge den lär

ii-theme-font: minor-latin; mso-bidi-font-family: "Times New Roman"; mso-bidi-theme-font: minor-bidi; mso-fareast-font-family: Calibri; mso-fareast-language: EN-US; mso-fareast-theme-font: minor-latin; mso-hansi-theme-font: minor-latin;”>

CSS selectors are evil and JS is the solution

rder-bottom-right-radius: 0px; border-top-left-radius: 0px; border-top-right-radius: 0px; border: 1px solid #cccccc; box-sizing: border-box; color: #333333; font-family: Menlo, Monaco, Consolas, ’Courier New’, monospace; font-size: 13px; line-height: 1.42857143; margin-bottom: 10px; overflow: auto; padding: 9.5px; word-break: break-all; word-wrap: break-word;”>h2 {

 font-family: Verdana;

 font-size: 14px;

}

.explanationBox {

 border-radius: 15px;

 padding: 10px;

 border: 2px solid springgreen;

 background-color: moccasin;

 color: magenta;

}

.explanationBox__headline {

 font-weight: normal;

 letter-spacing: 5px;

 padding-left: 15px;

 font-style: italic;

}

It is now slightly more clear what styles are applied where. Both the earlier questions are easier to answer, since we can do a search for the more precise class names.
But we still have the problem of the generic h2 selector. Also class names might be dynamically created and/or added to an element, so again, in a dynamic setting it might still be hard to find out exactly what’s going on.

Take 3 – inline styles in a React component

The basic idea in BEM, as well as in OOCSS or any of the other attempts at bringing structure to CSS, is to think in terms of components. All style definitions, as far as possible, should be tied to a certain component.
This jives very well with modern JS frameworks, who (almost) all have a component-centric architecture. If components are our main abstraction, then it is very easy to make an API to style individual components.
React (and most of the competition) does this by letting us provide a CSS-like JS object to the style prop:
const box = {

 borderRadius: "15px",

 padding: "10px",

 border: '2px solid springgreen',

 backgroundColor: 'moccasin',

 color: 'magenta'

};



const headline = {

 fontFamily: 'Verdana', // should live in generic h2 styling, but we're cheating for now

 fontWeight: "normal",

 letterSpacing: "5px",

 paddingLeft: "15px",

 fontStyle: "italic",

 fontSize: '14px'

};



export class ExplanationBox extends React.Component {

 render() {

   return (

     <div style={box}>

       <h2 style={headline}>{this.props.title}</h2>

       {this.props.children}

     </div>

   );

 }

}
Elsewhere in our React app we can now do this…
<ExplanationBox title="Did you know?">

 <p>Ozelots hate maccaws!</p>

</ExplanationBox>
…and we have our reusable, styled component!

Take 4 – imported inline styles

However, what you just saw was really nothing but a regression to our Take 0 attempt, where we put all styles inline. Like an animal.
But we can improve on this super easily, simply by migrating the styles to a separate file! Imagine the following living in a file named styles.js:
export const typography = {

 h2: {

   fontFamily: 'Verdana',

   fontSize: '16px'

 }

};



export const explanation = {

 box: {

   borderRadius: "15px",

   padding: "10px",

   border: '2px solid springgreen',

   backgroundColor: 'moccasin,

   color: 'magenta',

 },

 headline: {

   ...typography.h2,

   fontWeight: "normal",

   letterSpacing: "5px",

   paddingLeft: "15px",

   fontStyle: "italic",

   fontSize: '14px'

 }

};
Note the handling of the basic h2 styles!
Our React component now becomes this:
import {explanation} from styles;



export class ExplanationBox extends React.Component {

 render() {

   return (

     <div style={explanation.box}>

       <h2 style={explanation.headline}>{this.props.title}</h2>

       {this.props.children}

     </div>

   );

 }

}
We have now sort of reinvented the stylesheet! Except, where before the stylesheet used selectors to fire blindly into the dark…
 
cssinjs-selector.svg
…we now let the components go get exactly the styles they need via imports:
 
cssinjs-import.svg
It might not be immediately obvious, but the flipping of this arrow makes a world of difference!

Finding the killer

Remember the first unanswerable question?

What styles are applied to this element?

In our imported inline style setup, this becomes trivial to answer. I simply follow the thread backwards from the style prop!
 
cssinjs-findkiller.gif

Finding the victim

Our second unanswerable question was:

To which elements are these styles applied?

Again, because of the explicit imports, this becomes very easy to answer (if you have a semi-competent editor):
 
cssinjs-findvictim.gif
LESS isn’t more
Through moving our style definitions to JS land, the need for CSS preprocessors goes out the window. Remember how we used the ... spread operator to mix in the h2 styles into our headline rules?
headline: {

 ...typography.h2,

 fontWeight: "normal",

 letterSpacing: "5px",

 paddingLeft: "15px",

 fontStyle: "italic",

 fontSize: '14px'

}
That was the equivalent of a LESS/SASS mixin! You’ll quickly find that the other syntax they give us can be easily replicated with pure JS. For example, having global variables becomes trivial:
export const palette = {

 softcolor: 'moccasin',

 hardcolor: 'magenta',

 accentuationcolor: 'springgreen'

}



export const explanationBlock = {

 box: {

   borderRadius: "15px",

   padding: "10px",

   border: '2px solid ' + palette.accentuationcolor,

   backgroundColor: palette.softcolor,

   color: palette.hardcolor,

 },

 // ...truncated
As do implementing helper functions to add vendor prefixes, saturate colours, etc.

Wrapping up

To recap; by turning the arrows around through using JS and inline styles, almost all opaqueness of regular CSS goes away. Previously difficult tasks such as…
…suddenly become easy or entirely moot.
While there are still a lot of questions to be answered regarding moving CSS to JS space, there’s no doubt in my mind that just being able to flip the arrow of responsibility makes it all worth it.
One of the primary downsides of inline JS styles is that we can’t use pseudoselectors such as :hover or @media. I hope to show how we can get around that using helper libraries in an upcoming post.

Våra 5 populäraste kurser i oktober

Dags att presentera våra populäraste kurser i april! Vi har ett par nykomlingar på nr 1 och nr 5! 1. Cyber Security Expert 3 dagar Vår utbildning i cybersecurity för IT-tekniker och Supporttekniker är utformad för att ge dig de nödvändiga kunskaperna och färdigheterna för att hantera och motverka cyberhot i dagens teknikintensiva arbetsmiljöer. Vi kommer […]

Kreativitet, originalitet och initiativförmåga

Det livslånga lärandets väg – kreativt, originellt, initiativ eller något annat? I rapporten ”The future of Jobs report 2020” listade World Economic Forum framtida arbete och kompetens. En av kompetenserna på TOP 10-listan är ”Kreativitet, originalitet och initiativförmåga”. Med utgångspunkt i rapporten undrade jag vad dessa betydde ur livslångt lärande – särskilt för mig själv. […]

On Smart Configurators, for IT Architects

Manufacturing is the key player in applied intelligent configuration, but software businesses are catching up too. Factoring out dependencies between components (or classes, services etc.) to separate configuration issues from application logic, is a well-tried SW-variability principle likely to evolve further in the era of machine learning (ML).   

Product Owner – Scrum or SAFe? We got it!!

Become a super-hero-Product-Owner with Informator! Are you an aspiring Product Owner? Not sure if you should chose to take next step with Scrum or SAFe? Don’t worry, @informator offer guaranteed start in June for both T1712 Professional Scrum Product Owner™ with certification – June 14-15 https://informator.se/utbildningar/agila-metoder/rollspecifik-agile/professional-scrum-product-owner-with-certification M1709 SAFe® 4.5 Product Manager/Product Owner with PMPO Certification […]

Informator ger fortsatt och utvecklat stöd till Kodcentrum

Informator ger för fjärde året i rad ett fortsatt och utvecklat stöd till Kodcentrum i rollen som huvudpartner. Med över 25 års erfarenhet av att producera och leverera utbildningar inom systemutveckling vill Informator verka för att skapa möjligheter för barn och unga att få en kostnadsfri introduktion till programmering och de digitala färdigheter som näringslivet behöver idag och i framtiden.

EdTech in 2017 – The digital transformation continues

It was one of the hottest week in ages in London and a premonition of one of the most interesting conferences I’ve attended lately, EdTechX 2017.

Koda i skolan – Nytt läromedel ska få lärare att bli digitala

2018 implementeras regeringens beslut att införa programmering och digitalt skapande i läroplanen för grundskolan.