Training:Information design: Difference between revisions

Information design

Latest revision as of 05:25, 2 April 2024

I claim that for understanding a business, you should understand its information – what it deals with – the information it creates while it produces its product. Others may argue that the processes are the most important part – but I differ. If you know the information first, you know – or can figure out - what processes must be present that create this information. If you just know the processes, you still do not really know the information.

As a software architect, you can use the phrase “follow the information” in the same sense as detectives of crime use “follow the money”. You will find the truth this way.

When you follow information, it is easy for all to see if it is valuable information or not, but when following processes, you track work that is performed currently. Suppose you found an unneeded process step – how will you know that it is unneeded? You cannot get a correct answer from the ones performing it now – since they are biased that it is important - and no one else will have enough information to really know.

If you learn the important information first, you can easily see what the process step at hand does to that information. It should evolve the information in some way. If it does not create or change information in a valuable way the process step is unnecessary – for this business at least.

The Information

There are many ways to describe Information. My recommendation is UML – the Unified Modeling Language. UML contains a set of rules – and it lets you describe everything you need without further need for interpretation. UML is the core defining the models available in MDriven. This book will use UML extensively.

See: Short introduction to UML– class diagram

This page was edited 48 days ago on 04/02/2024. What links here

@@ Line 1: / Line 1: @@
-I claim that for understanding a business you should understand its information – what they deal with – the information they create while they produce their product. Others may argue that the processes are the most important part – but I differ – if you first know the information you know – or can figure out - what processes must be present that creates this information. If you just know the processes you still do not really know the information.
+I claim that for understanding a business, you should understand its information – what it deals with – the information it creates while it produces its product. Others may argue that the processes are the most important part – but I differ. If you know the information first, you know – or can figure out - what processes must be present that create this information. If you just know the processes, you still do not really know the information.
-As a software architect you can use the phrase “follow the information” in the same sense as detectives of crime use “follow the money”. You will find the truth this way.
+As a software architect, you can use the phrase “follow the information” in the same sense as detectives of crime use “follow the money”. You will find the truth this way.
-When you follow information it is easy for all to see if it is valuable information or not, but when following processes you track work that is performed currently. Suppose you found an unneeded process step – how will you know that it is unneeded? You cannot get a correct answer from the ones performing it now – since they are biased that it is important - and no one else will have enough information to really know.
+When you follow information, it is easy for all to see if it is valuable information or not, but when following processes, you track work that is performed currently. Suppose you found an unneeded process step – how will you know that it is unneeded? You cannot get a correct answer from the ones performing it now – since they are biased that it is important - and no one else will have enough information to really know.
-If you first learn the important information you can easily see what the process step at hand does to that information. It should evolve the information in some way. If it does not create or change information in a valuable way the process step is unnecessary – for this business at least.
+If you learn the important information first, you can easily see what the process step at hand does to that information. It should evolve the information in some way. If it does not create or change information in a valuable way the process step is unnecessary – for this business at least.
 == The Information ==
-There are many ways to describe Information. My recommendation is UML – the Unified Modeling Language. UML contains a few set of rules – and it lets you describe everything you need without further need for interpretation. UML is the core defining the models available in MDriven. This book will use UML extensively.
+There are many ways to describe Information. My recommendation is UML – the Unified Modeling Language. UML contains a set of rules – and it lets you describe everything you need without further need for interpretation. UML is the core defining the models available in MDriven. This book will use UML extensively.
-== Short introduction to UML– class diagram ==
-UML class diagram is the preferred way to describe the statics of information.
-A UML class diagram shows classes and their relations.
-A Class differs from an Object. The Object is of a Class. The Class may have many instance objects each being of the Class. “Instance” and “object” are treated as interchangeable in this document – they both mean an object instance of a class.
-Class can be regarded as the “Concept” of something. Like if I have class named “Car” – it is likely to symbolize the fact that there are Cars and Car is a concept that exists and that there are probably instance objects of this class as “my car”, “your car” and the car with license plate ABC.
-[[File:Image of Car.png|left|frameless]]
-A class typically has attributes. One attribute of Car might be License plate number. Attributes must have types. Typical types are string, integer, double, Boolean and datetime.
-[[File:One attribute of Car might be License plate number (image).png|left|frameless]]
-This means that once we have objects of class Car – these objects will have a place to store the License plate number of that particular car.
-Classes typically has relations to other classes (relation, association, link are sort of synonyms and can be used interchangeably)
-[[File:Classes typically has relations to other classes (image).png|left|frameless|272x272px]]
-A relation has two endpoints. An endpoint has a name. When you read a class diagram and your eye follow a relation you should use the name on the far side of the relation. So in this example I would say: “There is the concept of Car. Cars have LicensePlate strings. Cars also point out the BrandOfTheCar with a Name”.
-If I was talking about brand – looking on the model from another direction: “There is the concept of Brand. Brand has a name. Brands also have Cars of the brand that in turn has LicensePlates”.
-Relation endpoints also have Cardinality. Cardinality is a rule that describes how many instances there can be in the relation endpoint. The cardinality marking of star (*) means “unlimited”. Valid cardinality markings are: 0..1 (zero or one instance allowed), 1 (must always have 1 instance), y..x or x where y and x is any number or x is star (*).
-This was the basics of UML – there are more of course – but this is what you need to get started.
+See: [[Training:Short introduction to UML– class diagram|Short introduction to UML– class diagram]]
 [[Category:The MDriven Book]]