English | 2015 | 365 Pages | PDF, EPUB | 23 MB
This book sets out to show embedded software engineers how to model their designs using diagrams in an effective, clear and useful way. A key aspect in all of this is the sensible application of a set of diagrams defined within the Unified Modelling Language (UML) standard. It is aimed at those designing – or who intend to design – software for real-time embedded systems (RTESs).
The content of this book falls into two quite distinct categories. The first, covered by chapters 1 to 3, is a ‘selling’ mission, to try to make you understand why it really is a good idea to use modelling methods in your designs. The next set of chapters is organized on a model-by-model basis. The diagrams described are those that we have found to be especially useful in the development of RTESs. This isn’t limited to just the syntax and semantic aspects (such information is widely available) but also tries to show how and why such diagrams are used. Rounding things off is chapter 9, ‘Practical diagramming issues’. This is especially important as it provides practical guidance on using UML diagrams for the design and development of real-time systems.
Why bother to model in the first place?
The ‘meat’ of this book is all to do with UML diagrams and diagramming. Yet it’s a mistake to treat the production of these diagrams as an end in itself (though that seems to be the case with some organizations). No, they are a means to an end, which is the modelling of software systems.
One of life’s great truisms; doing pointless things is a total waste of time, energy, effort and, in a job setting, money. So, why bother to spend our precious resources on the modeling of systems? Good question. However, to answer that, we first need to be clear what we mean by models and modelling.
The modelling of software – key aspects
The software machine and object-oriented techniques
The central plank of modern software design is that software systems are built as sets of cooperating, communicating software machines. Please note; we’re not talking about program design, although this is a part of the overall development process.
Precise details of both system and individual machine construction methods vary, as do their cooperation and communication techniques. But the fundamentals are exactly the same across all design techniques. A software machine:
Put simply, software machines are the building blocks of software. And regrettably, if you don’t believe in using this approach, then much of what UML has to offer is irrelevant.
For simplicity, conciseness and personal choice, we’ll call the software machine an object. Another reason for doing this is that UML was developed originally as a notational method for object-oriented systems. And in those early days the ‘things’ that actually did the work during program execution were called objects. The alternative is to use words like instances, instantiations or representations.
Modelling OO software with UML diagrams – a broad perspective
Object Orientation has one simple, central feature. It is that designs may be structured as sets of interconnected, collaborating objects. These can be described using three models:
Diagramming and UML – a broad perspective
Setting the groundwork
I hope, by this time, that you truly appreciate that diagramming is an essential part of professional software development. I also hope that you fully understand what we set out to achieve by using diagrams. However, before getting into the nitty-gritty of UML, we need to do consider a very important question; just how well does UML fit the bill?
Now, this might seem to be a non-question if you believe the torrent of uncritical acclaim for UML. We are assured that by using of UML we will significantly improve our software. Reality, unfortunately, is somewhat different. There has been success, true. But there have also been many failures along the way. Mostly these have been due to the uncritical use of UML by software developers. And compounding this is the failure of many developers to really understand how to use it.
To effectively use tools, techniques or processes, you must understand their weaknesses and limitations. This is especially true for UML because it does have some serious drawbacks. What we’re going to do here is look at these issues and see how we can mitigate their effects. Once having done that we’re in a good position to actually achieve many of the claimed benefits of using UML.