- The MDriven Book: Table of Contents
- What is MDriven
- Introduction - The MDriven Book
- Praise to UML
- What if UML was forbidden
- What is not to like
- What is next
- Information design
- Short introduction to UML– class diagram
- Association classes
- UML Inheritance
- Polymorphism
- Composite and Aggregate and what they imply
- Derived attributes & associations
- UML – State machines
- Constraints
- The ViewModel
- The declarative ViewModel
- Prototyping
- Taking It Further Still
- What an Action can do
- Global actions
- Action names
- Microsoft Office and OpenDocument as a Report generator
- Available Actions
- Introducing MDriven Server
- Security concerns for MDriven Server
- MDrivenServer Summarized
- Certain important constructs
- MDrivenServer periodic server-side actions
- Luckily UML is Not Forbidden
- Import data from other SQL servers
- SQLExport from MDriven Server
- Seeker view
- Installing TurnKey as an Azure WebApp
- Set up MDriven Turnkey on premise
- MDriven Turnkey architecture
- Security
- Information security
- Access control system in MDriven
- Testing
- The MDriven Book
The printed book can be purchased on Amazon: https://www.amazon.com/MDriven-effective-business-control-information/dp/1729341098
As I have worked as a software developer and architect in Sweden for the last 20 years, I have seen a lot. I am not going to bore you with my historic reflections at all.
That was my first attempt at an introduction to this book. Then, I realized that most of the things we have done with MDriven are very much anchored in the historic reflections of things we have experienced previously. So I guess what I need to say is more like this:
Having worked many years as a software architect, I have seen a lot of things that change – but also very much that stays the same over time – a stable core.
What is the stable core? The need to store and retrieve the information we are dealing with. The need to somehow display it for users and handle the users' need to update it according to the rules we want to enforce. This is the technology of any application or system and is what every system developer needs to deliver – using modern technology at the time of implementation. I will refer to this as system modernity.
Furthermore, we need to understand the business information in the system and how the rules that govern the information’s evolution and consistency protection work. This part I will refer to as the system gist.
On the other hand, we all know that to make our software sell – to an external market or in-house users - it must be perceived as modern and cool - but in the software business, modern and cool change every year or so, at least on the surface.
Thus, mixing the system gist down into a currently modern format that will be obsolete in a couple of years seems to be something one should avoid.
It would be better if the system gist could somehow be separated from the current modern implementation strategy – which we know will be less modern as time goes by.
This book contains my suggestions for how we deal with system gist and system modernity.
The MDriven Book - Next Chapter: Praise to UML