The Baker’s Dozen Of Use Cases – Part 2

RULE 1: Use Cases Aren’t Silver Bullets

There are a couple of popular misconceptions around use cases:

Misconception 1: The use cases are the requirements of the system

Contrary to what many engineers believe (and many authors have written) the complete set of use cases do NOT constitute its full set of requirements for the system.


A use case model is an analysis tool. They are a mechanism for organising the functional behaviour of the system and reflecting it back to the stakeholders. This is sometimes referred to as ‘Problem Reframing’. By re-framing the requirements to are aiming to achieve three things:

• Demonstrate you have understood the problem, as the customer perceives it.
• Capture information exchange and sequencing requirements.
• Identify any missing behaviours

In order to achieve this effectively you need to generalise and abstract the customer requirements into something more manageable. Thus the use cases ‘reflect’ the system requirements without actually being the system requirements.

In embedded systems design the functional behaviour is but a small part of the requirements of the system. System developers must comply with a vast number of other requirements, including performance, reliability, security, environmental, useability, etc. Many of these are system qualities – that is, they apply to the system as a whole, not just the software. Use Cases are simply not an effective tool for capturing this information, despite attempts by several authors to incorporate them.


Misconception 2: You must always build a use case model

Engineering problems can be classified into four basic categories:

Data-oriented
In a data-oriented problem it is the information, and its relationship to other information, that is important.

Modal
Modal problems are characterised by having separate, distinct behaviours at different times. Trigger events from the environment will cause the system to change its behaviour.

Transactional
Transactional problems tend to be event-driven: A behaviour is (externally) invoked, which either produces a result or a change in the environment.

Flow-of-materials
Problems tend to be control-oriented: data/materiel moves from ‘sources’ to ‘sinks’. Algorithms and rules control how the information is moved and transformed.

While it’s perfectly correct to say that almost all systems have all these elements to some extent, in most cases one of the categories tends to dominate the requirements of the system.


Use cases are most effective when used to describe Transactional problems. Using Use Case analysis on other types of system often yields less-useful information about the system. In some cases Use Cases actually obfuscate the problem by attempting to re-frame one type of problem into a Transactional problem. For example, attempting to describe a flow-of-materials problem with use cases tends to yield trivial Use Cases and obscures the fundamental nature of the problem by trying to re-frame ‘flows’ as descrete ‘events’.


Use cases are a very powerful analysis tool – when used in the right way and under the right circumstances. But they aren’t a silver bullet. Use cases don’t solve every requirements analysis problem and they don’t necessarily suit every type of problem.

In order to use Use Cases effectively you must understand what type of problem you are trying to solve and whether use cases are the right tool for the job.

The Baker’s Dozen of Use Cases

Use cases have become a core part of the requirements analyst’s arsenal.  Used well they can bring dramatic increases in customer satisfaction and a whole host of other subtle benefits to software development.

The use case itself is very simple in concept: describe the functionality of the system in terms of interactions between the system and its external interactors.  The focus of the use case is system usage,  from an external perspective.

Despite this apparent simplicity, requirements analysts frequently struggle to write coherent, consistent use cases that can be used to facilitate development.   Often, the use case analysis becomes an exercise in confusion, incomprehension and the dreaded ‘analysis paralysis’.

This article aims to aid use case writers by presenting a set of rules to follow when performing use case analysis.  The rules are designed to avoid common pitfalls in the analysis process and lead to a much more coherent set of requirements.


Your use case is not my use case

Since Jacobson defined use cases back in 1992 they have been subject to a vast range of interpretations.   Alistair Cockburn, author of Writing Effective Use Cases states:

“I have personally encountered over 18 different definitions of use case, given by different, each expert,

teachers and consultants”

I am no different: this is my personal interpretation of use case modelling and analysis.  To qualify this statement though, this methodology is based on nearly a decade of requirements definition work on a number high integrity projects, including military and aerospace.   That said, techniques that work in one environment may be less effective in another.  I haven’t been fortunate enough to work in every industry sector.   It may be, then, that you disagree with some of my techniques.  This is fine; I won’t think of you as a bad person.

In a series of articles I will present a set of guidelines, or rules-of-thumb.  Each of the ‘rules’ defines a good practice that I recommend when creating use cases.  Each rule forms a quality control on the requirements analysis process.  Ignoring a rule means there is an(other) opportunity for mistakes to creep into your requirements.

There’s no way I could capture every possible method or practice needed to create, analyse, review and maintain your use cases (well, short of writing a book on the subject).  I have decided to focus on a manageable number.  Ten would have been ideal; but that was too few and left out some important points.  Twelve still fell short, so I decided on a “baker’s dozen” – 13 rules.

To start, though, let’s have a quick review of Use Cases.


A brief overview of use cases

Use cases are a requirements analysis technique based on the conceit that (software) systems exist to fulfils the needs and desires of their stakeholders.  Stakeholders don’t use systems for the sake of it - they want to achieve something with the system that is of worth to them.  That is, the system must do something useful for the stakeholder, and in a fashion they expect or desire.

A use case is partial definition of a system’s behaviour, described in terms of a goal that a stakeholder of the system (called an ‘Actor’) wants to achieve, and how they achieve it.  A use case is described in terms of the interaction between the Actor and the system; specifically, it is defined in terms of the information that is exchanged between the actor and the system.

Fig 1.1 – The Basic Use Case Diagram

It is useful to think of a use case in terms of scenarios.  A scenario is a particular instance of interactions.  A scenario describes one possible way of interacting with the system (whilst trying to achieve that particular goal). When trying to achieve their goal, the Actor may have to make choices.  Also, things have a habit of going wrong.  Each variation is a different scenario.  The use case, therefore, is described by every possible scenario.  Obviously, attempting to document a use case by writing every scenario would be ludicrous for anything but the most trivial system.  The way round this is via a Use Case Description.

A Use Case Description is a structured English definition of all the use case steps.  It can be thought of as a’ blueprint’ for generating use case scenarios.  It should be possible to re-create any scenario from the use case specification.  In its basic form, a use case description is a series of steps showing how information is exchanged between the Actor(s) and the system until the Actor’s goal is met.  This flow is always initiated by an Actor (we don’t really want software doing stuff of its own accord!)  This basic form is called the Basic flow, or Main Success Scenario.  In the Basic flow nothing goes wrong and the Actor does the most normal, obvious things (this is sometimes called the “Sunny Day” scenario!)

However, when the Actor must make a choice, the use case description must fork – one path for each option the Actor can make.  Each of these descriptions is described in an Optional flow (sometimes called a Sub flow).

Similarly, not everything always goes right.  If something can go wrong in a scenario, chances are it will at some point (probably when the Actor least expects or wants it to!).  Typically, these conditions are not resolved by giving the Actor an option; they happen beyond the Actor’s control.  We have to record what happens when that ‘something’ goes wrong.  These descriptions are called the Exceptional flows.

Another very useful way of looking at a use case specification is in terms of its start and end conditions.  We can record all the possible start conditions that the system could be in; similarly, we can identify what state we expect the world to be in after we’ve finished.  The use case steps, then, map the initial conditions to the appropriate final conditions.

Finally, we throw in constraints.  A constraint is a requirement on not what the system does, but how it does it.  A constraint may define a performance requirement, a reliability requirement, a safety requirement, etc.  Each step in the use case specification can have one or more constraints applied to it.  It is difficult to document how the constraint manifests itself in the use case but it is easier to document what happens when a constraint is not met.  In this case the failure is treated as an exceptional condition.

Coming next…

In Part 2 we’ll begin to look at the rules, starting with “Use Cases Aren’t Silver Bullets”

Elizabethan guidance on Object-Oriented software design

So what did the Elizabethans know about software development?  Well, in truth, nothing whatsoever.  But what they had begun to do is codify and systematise the knowledge and experience of masters in manuals, treatises and books.  Some of the earliest documents of this form refer to the martial arts or, as it was known at the time the ‘Arts of Defence’

In martial arts one learns practical skills (in this case how to defend oneself against any enemy) through practice and training.  The practical skills are usually an extension of some ‘core’ principles, which form the basis of the art.  These core principles state some fundamental truth about the nature of the art.  Without understanding these fundamental principles one is merely performing a ‘dance’ and one will never be truly effective.

George Silver

In the late 16th century George Silver, an English gentleman, wrote a martial arts treatise called ‘Paradoxes of Defence’ (A transcription of the original can be found here).  The treatise is well known in the Western Martial Arts community for being one of the earliest treatises in English; and also for Silver’s prolonged and somewhat vitriolic attacks against the Italian fencing masters of his day, who he saw as frauds.

Silver followed up his ‘Paradoxes of Defence’ with a more practical publication ‘Brief Instructions Upon My Paradoxes of Defence’  where he attempted to set out his fighting principles and practices (a transcription can be found here)

Silver used the phrases ‘True Fight’ and ‘False Fight’ to describe effective fighting techniques.  True fight was correct application of the principals of fighting; False Fight was to ignore, misunderstand or misuse the principals of fighting.  He also talked of ‘Perfect’ and ‘Imperfect’ fighting.  Perfect fighting had nothing to do with being a great fighter: as long as you used the correct technique all the time (the True Fight) then your fight was perfect; however skilled you were.  So a beginner, using the principals of the True Fight, even if slow and ungainly, was fighting a Perfect fight.  On the other hand, even if you were fast, skilled and deadly, if you used ‘False’ techniques Silver considered your fight to be ‘Imperfect’.   In Silver’s mind using correct principles was always superior to using ineffective techniques.  That didn’t mean the Perfect Fight always won; but that the Imperfect fighter was doomed, by definition, eventually to fail.

Silver based his techniques on what he called his Four Groundings and Four Governors.  The Four Groundings were the fundamental principles upon which all fighting – irrespective of the weapon used – were based.   The Four Groundings are tightly inter-related to each other.  Ignoring one principle will affect all the others (and lead to False fight).  Each Grounding must be understood, and how it affects all the others, also understood.

The Four Governors were the elements of a fight that controlled its outcome.  The Governors control your actions and your approach to the fight.  As the Governors change, so must your approach to the fight, and the techniques you can, or must, use.

The question is: can we apply Silver’s ideas of True Fight and False Fight to software development?  What is ‘True’ development; and what is ‘False’?  What are the Groundings of software development; and what are the Governors?  Can we define ‘Perfect’ and ‘Imperfect’ software?

‘Imperfect’ software development

Firstly we need to make a distinction between Correctness and Intrinsic Quality.  Correctness is the ability of software to fulfil its requirements.  Intrinsic Quality refers to how the software is designed and built – that is, how ‘good’ or ‘bad’ the software is.

Incorrect software, irrespective of how good it is, must be considered ‘Imperfect’ by our definition.  No matter how ‘good’ the software is, if it doesn’t fulfil its requirements, it’s useless (and if the requirements are wrong it’s also useless, or at least of questionable value).

Correct software must be our starting point.  Is all correct software Perfect?  Or should the ‘perfection’ of software be judged by its Intrinsic Quality?

If we apply Silver’s logic ‘Perfect’ software will always result from ‘True’ software development.  True development is that which applies the Four Groundings and Four Governors of software development.  So we need to understand what the Groundings and Governors are for software development.

The Groundings and Governors for software development must be those principles that give our software high intrinsic quality, both in its development (its static design, coding) and at runtime (its dynamic testing and execution).

What makes poor software?

It is challenging to define what makes ‘good’ software since we so rarely see it.  On the other hand most engineers are used to seeing (and maintaining!) what they consider ‘bad’ software.  Often engineers cannot qualify what makes the software bad; it just is.  Typically, though, bad software suffers from one or more of the following maladies:

It is difficult to understand.

The code is difficult to read; variable names are unhelpful; comments are missing (or worse, incorrect); code is badly structured and laid-out; etc.

It is fragile.

Fragile code will break at the slightest provocation.  Fixing a bug in one part of the code can cause a cascade of other bugs in other parts of the code; often quite un-related to the problem.

It is rigid.

Rigid code has been designed to fulfil one requirement – and that is all it will ever do.  If the requirements change the software must be almost completely re-written to support the new behaviour.

It is immobile.

Engineers often build really useful software modules.  However, if the useful module is so tightly intertwined with the structure of the program it’s in, the effort involved in unpicking the useful code is so great is often impractical to even try to re-use it somewhere else.  Sometimes it’s just easier to write it again from scratch.

The Four Governors

In Silver’s system understanding and controlling your Governors determined how successful you were in a fight.  If you fail to control your Governors you will ultimately lose the fight.  In engineering terms success can be measured in terms of money.  That is, failing to understand and control the software Governors will ultimately lead to spending more money (or making less money, however you want to look at it) than you need to.

Our Governors must therefore relate to the effectiveness of our software development.  Effectiveness is about doing things that add value; in contrast to efficiency, which is focussed on doing more work with less resource.

If the above qualities define bad software then the opposite must define good software.  Thus we can use our definition of bad software and invert them to give us our Four Governors of software development.  They are:

Comprehension

Good software must be easy to read and understand.  There should be no surprises in the code; its purpose and implementation should be obvious and equivalent.

Flexibility

It should require little effort to adapt existing software to new requirements.

Robustness

Software should be tolerant to invalid inputs.  Performance should be unhindered by incorrect inputs, or should be degraded in a known, controlled, way.  The impact of change should be controlled and limited.

Mobility

Software should be easily adapted to new environments, platforms or problem domains, without requiring major modification.

The Four Groundings

The Groundings are the set of (inter-related) principles upon which all actions are based.  The principles are normally inter-dependent – adjusting one principle often affects the others.  Thus the Groundings must be ‘balanced’ to meet the needs of the Governors.  As the Governors change, so must the application of the Groundings.

In software our Groundings are the principles of good, modular, design.  A module, in this case, refers to a unit of software construction (or decomposition, if you prefer).  A program is constructed of one or more modules.  A module should ideally be self contained, with a well-defined interface and a well-defined, localised purpose and functionality.

By correct application of the Groundings we achieve high intrinsic quality software.  Once again, our Groundings are inter-dependent – focussing on any one Grounding at the expense of the others is no guarantee of producing good software.

The Four Groundings of software development are:

Coupling

Coupling is the inter-dependence between modules.  The inter-dependence depends on the number of, and complexity of, connection between any two modules.

Ideally, we aim for low coupling – that is, a small number of simple connections.  Reducing the inter-dependency between modules allows greater flexibility in design and greater potential for re-use.

There is a compromise to be made between coupling and performance.  Typically, low-coupling comes at the expense of system performance; highly-coupled systems can often be much higher performance than lower coupled systems.

The engineer’s skill is in understanding when to design for low coupling and when to design for performance.

As a rule-of-thumb always design for intrinsic quality of code, monitor the actual performance, and only then optimise the coding or coupling of the key areas that need it. Most times the problem isn’t where you think it is (dynamically).

Encapsulation

Encapsulation literally means ‘to put in a capsule’.  Encapsulation is separating ‘what’ the module does (its interface) from ‘how’ it does it (the implementation).  Ideally, clients should never be able to directly access the module’s implementation – or even need to if the interface is designed well.

Strong encapsulation can reduce coupling by eliminating the ability of one module to access the internal behaviour or data of another module.

It enables the module to be easily tested in isolation before combining it with other modules that make up the program.

Encapsulation also provides ‘insulation’.  By separating the interface from its implementation the implementation may be changed without affecting the client code – in other words, the client is ‘insulated’ from change.

Cohesion

Cohesion defines how well elements fit together.  There are several models for cohesion in software (The most well known being Constantine’s 7-level scale of cohesion)  but most cover the following aspects:

Functional cohesion focuses on the coherence of the interface of a module.  For high cohesion the operations that form a module’s interface must be mutually self-supporting.  The operations should all contribute to a unified overall behaviour for the module   By contrast, the operations in a low cohesion module are independent and unrelated.  Removing or replacing any operation has no effect on any other operation in the module.  A highly cohesive module typically performs a single, high-level responsibility.

Temporal cohesion focuses on the concurrent or parallel execution behaviour of modules.  Modules that execute in sequence with one another executing in the same thread of control are temporally cohesive.  Modules that must run in parallel but are executing within the same thread of control are not temporally cohesive.

Contextual cohesion refers to design abstraction.  During design engineers should organise the design into different levels of detail; each level used to focus on a different aspect of problem definition.  For example, high level design should focus on architecture and design validation; lower level designs should focus on implementation and verification.  A cohesive design does not mix high and low level constructs on the same design.   For example, focussing on implementation artefacts during architectural design is inappropriate and therefore contextually non-cohesive.

Cohesive modules tend to limit the impact of change, since the change typically affects only the (related) operations/data in a single module; and has no impact on other modules.

Abstraction

Abstraction may be defined as filtering out detail that is unnecessary in the context being considered.

When we build software we are constructing models of the problem domain and manipulating them to provide some benefit to the customer.  Context is important because it defines how you view the situation:  what is relevant, that is, the abstractions that are useful in that context.

For any particular problem domain there are concepts that are important, and concepts that have no relevance.   A good abstraction captures the relevant information about the problem domain, and ignores the superfluous.  You could think of this as looking at a problem from a particular viewpoint.

Basing a design on problem domain abstractions provides resilience to change since the concepts of any particular domain are likely to remain stable over time; unlike implementation technologies which are likely to change rapidly.

The Four Groundings are all inter-dependent, but not necessarily mutually inclusive:  Although a good problem domain abstraction domain is likely to be cohesive, it can be made incoherent through bad design; a coherent module should provide strong encapsulation, but that can be broken through poor design; strong encapsulation should provide lower coupling, but poor cohesion in the design and poor abstractions may lead to increased coupling.

A good engineer must understand the Four Groundings in detail and how they inter-relate.

‘Perfect’ software development

True development is one that applies the Groundings and Governors:

A design with well-chosen abstractions of problem domain elements, strongly and cohesively encapsulated with low coupling.  Such a design is likely to be comprehensible, robust, flexible and mobile.

False development is one that ignores the Groundings and Governors:

An incoherent design, focussing on implementation elements, with poor encapsulation, weak cohesion and high coupling.  Such a design is likely to be incomprehensible, rigid, fragile and immobile.

A Perfect development is therefore one that is always True; Imperfect development is one where we use False techniques.

Of course, we can always ignore the Groundings and Governors and still produce working software; but this will always be (in Silver’s view) Imperfect.

Even if we aren’t particularly skilled with the Groundings and Governors as long as we apply them our development will always be True.  And we can always improve.

If we always choose the False development (cutting corners) our software can never be Perfect.

As it suggests Perfect development is an ideal; it is something to strive for.  We will almost certainly have to compromise our development because of time, resource or money constraints.  Wherever possible, though, we should aim for True development.

Perhaps those Elizabethans knew more about software development than we realise, after all.

Summary of the True development

The Four Governors

The Four Groundings

Polymorphism in C++

The term polymorphism is central to most discussions in and around object oriented design and programming. However I find that many people are still confused or don’t have a complete understanding of the advantages and disadvantages of using polymorphism.

I have heard many different simplified definitions of the root term for polymorphism, usually relating to chemistry or biology. Rather than trying to justify the name, I’ll give you my very simplistic definition from a software perspective.  Simply put polymorphism means:

Multiple functions with the same name.

Yep, as simple as that.

Most C programmers don’t realise they have been using polymorphic operations since they started programming. Take, for example, the following code:

b + c

That’s a polymorphic expression. Why?  Well we know nothing about the types of b and c. If b and c are of type int then the code generated is significantly different to if they are double.

But, I hear to shout, what about virtual functions and all that?

So herein lies on of the main problems. When most people use the term polymorphism they are actually referring to Dynamic Polymorphism. The expression b + c is related to Static Polymorphism.

With static polymorphism, the actual code to run (or the function to call) is known at compile time. C++ Overloading is static polymorphic, e.g.

void swap(int* a, int* b);

void swap(double* a, double *b);

int main()
{
   int x = 10, y = 20;
   double a = 1.2, b = 3.4;
   swap(&x, &y);            // swap(int,int)
   swap(&a, &b);            // swap(double, double)
}

Here the compile, based on the number and type of arguments, can determine which function to call.

Dynamic polymorphism, which in C++ is called Overriding, allows us to determine the actual function method to be executed at run-time rather than compile time.

For example, if we are using the  uC/OS-II RTOS and have developed a Mutex class, e.g.

class uCMutex
{
public:
   uCMutex();
   void lock();
   void unlock();
private:
   OS_EVENT* hSem;
   INT8U err;
   // not implemented
   uCMutex( const uCMutex& copyMe );
   uCMutex& operator=( const uCMutex& rhs );
};

And have also implemented  a very simple stack class (note this code is just for explanation purposes and has many shortcomings) that requires mutual exclusion, it may look something along the flowing lines:

class myStack
{
public:
   myStack();
   bool push(int val);
   int pop();
private:
   static const int sz = 10;
   int m_stack[sz];
   unsigned int count;
   uCMutex tm;   // uCMutex Object
};

myStack::myStack(iMutex& m):count(0), tm(m)
{
   memset(m_stack,0,sizeof(m_stack));
}

bool myStack::push(int val)
{
   bool retval = false;
   tm.lock();    // LOCK
   if (count < sz) {
      m_stack[count++] = val;
      retval = true
   }
   tm.unlock();     // UNLOCK
   return retval;
}

int myStack::pop()
{
   int val = -1;
   tm.lock();       // LOCK
   if (count != 0) {
      val = m_stack[--count];
   }
   tm.unlock();     // UNLOCK
   return val;
}

If, then, in our new design we are going to use VxWorks rather than uC/OS-II, our stack class would require reworking, thus:

class VxMutex
{
public:
   VxMutex();
   void lock();
   void unlock();
private:
   …
};

class myStack
{
private:
   ...
   VxMutex tm;
};

Even though the change from the uC/OS-II mutex to the VxWorks mutex class is within the private part of the stack class, this still has many detrimental knock on effects. Significantly, we have changed the stack class’s definition, so all files that use the stack now need recompiling. This, then, has a knock on effect to the amount of regression testing that is required.

An alternative strategy is to use dynamic polymorphism and interfaces to make our code more testable and reusable.  So, by defining an interface class for the mutex abstraction:

class iMutex
{
public:
   iMutex(){}
   virtual ~iMutex(){}
   virtual void lock() = 0;      // pure virtual function
   virtual void unlock() = 0;    // pure virtual function
private:
   // not implemented
   iMutex( const iMutex&);
   iMutex& operator=( const iMutex&);
};

We can alter the stack code so the mutex object is passed in as a constructor parameter (also the mutex classes require changes to inherit from the iMutex interface):

class uCMutex : public iMutex
{
}

class VxMutex : public iMutex
{
}

class myStack
{
public:
   explicit myStack(iMutex& m);
   bool push(int val);
   int pop();
private:
   static const int sz = 10;
   int m_stack[sz];
   unsigned int count;
   iMutex& tm;   // Mutex Reference
};

Our main code now becomes:

uCMutex ucm;
myStack ms(ucm);

or

VxMutex vxm;
myStack ms(vxm);

This is dynamic polymorphism in operation. Depending on the actual object passed (vxm or ucm), the actual code called when

tm.lock();

is executed, will either be VxMutex::lock() or uCMutex::lock().

Dynamic polymorphism is an incredibly powerful construct and, used well, creates code that can easily be adapted in the face of changing requirements with minimal impact.

However it all comes at a cost. The run-time lookup for virtual functions requires additional code and data. Each dynamic polymorphic class requires a virtual table (v-table), and each object of that type a v-table pointer (vtptr). To call the polymorphic function the run-time system requires indexing into the v-table via the object’s vtptr to actually call the function. In certain environments this can be twice as slow as a normal function call.

So how can we get the benefits of dynamic polymorphism, allowing us to abstract the code from how we’re doing it (e.g. VxWork’s lock call) to what we’re doing (Mutex lock call), but not have to extra overhead of virtual functions.

Well we have C++ templates. So modifying the stack class to become:

template <typename mutex_t>
class myStack
{
public:
   myStack();
   bool push(int val);
   int pop();
private:
   static const int sz = 10;
   int m_stack[sz];
   unsigned int count;
   mutex_t tm;   // Mutex Template Instance
};

and main becomes

 myStack<uCMutex> ms;

 ms.push(10);

With template based code we revert back to static polymorphism from dynamic polymorphism, as the actual call to tm.lock() will be compile time resolved at the possible expense of code readability and complexity.

Finally, I have found that the terms for polymorphism have a number of different names, e.g.

Dynamic Polymorphism

• Subtype polymorphism
• Overriding
• Late binding

Static Polymorphism

• Parametric polymorphism
• Overloading
• Early binding

We Have Met the Enemy and He Is PowerPoint

This the headline to the central story in today’s New York Times. The story is about the overuse of PowerPoint by the US military, especially in Afghanistan. It centers around a particular PowerPoint slide (shown below) attempting to portray the complexity of US strategy in the region.

The article discusses that a Brig. Gen. H. R. McMaster banned PowerPoint presentations when he led the successful effort to secure the northern Iraq city of Tal Afar.

Leading on from this,  you may be aware, that next weeks UK event the Embedded Masterclass has also banned PowerPoint from its technical presentations. To quote from the website:

This year we have asked the presenters of the 40 min Technical Presentations to ‘abandon Power Point’ . Instead they will have a white board, a flip chart and hand-outs and of course – their wit and charm ! We want to bring a bit of life back into these kinds of events and raise the standards. We are hoping this will lead to a better and more inter-active presentation. It is already causing the presenters to think more carefully about what they intend to present and how it will be structured.

I understand the sentiment, but I’m sorry but No; PowerPoint is just a tool. Banning (or abandoning) PowerPoint is not addressing the root problem.

For anyone who wants to do a professional job of presenting then there are great reference materials out there (e.g. Presentation Zen, silde:ology, beyond bullet points, etc.).

In reality many poor presentations are due to a lack of a proper review process prior to the event(admittedly some people just can’t present). All presentations should be backed up by a hand-out technical paper and not just a print-out of the slides (eliminating the need for lots of technical detail on a slides). Finally, being someone who has to regularly present  5 days of detailed technical training on embedded systems, white boards and flip charts just aren’t big enough for a large audience (unless you can write REALLY BIG).

To combat this problem of free form notes to a large audience, at Feabhas we have been using a really cool tool called PaperShow to augment the slides. Ideally we’d use two projectors, but this isn’t typically practical. Alternatively you could go back to the “good old days” on OHPs, foils and pens.

As I’ll be at the Cambridge event (as we’re running an Embedded Linux training class) I’m really interested in how it actually works and my concerns will hopefully be proven wrong. Hopefully see you there…

Embedded Systems Conference – Silicon Valley

As I’m sure you’re well aware, the ash cloud from the Eyjafjallajokull volcano (which began erupting in mid-March) pretty much brought much of European airspace to a standstill over last weekend and into this week. Now that UK airspace has been reopened, it appears I can resume plans for my visit to the Embedded Systems Conference in San Jose next week.

The sessions I’m directly involved with are:

Examining ARM’s Cortex Microcontroller Software Interface Standard – CMSIS
Date/Time: Tuesday (April 27, 2010)   3:15pm — 4:15pm
In this session I shall be examining ARM’s Cortex Microcontroller Software Interface Standard (CMSIS -  typically pronounced C-M-Sis) . CMSIS aims to provide a framework of reusable components for software developers, silicon and compiler vendors to utilize. Aspects such a power-up boot management and interrupt control have been abstracted and defined by ARM for their Cortex-M family of microcontroller cores. I’ll spend time explaining the CMSIS framework, examining the code from a compiler and chip perspective, and finish off by discussing the pros and cons I see in such an approach.

Understanding Mutual Exclusion: The Semaphores vs. the Mutex
Date/Time: Wednesday (April 28, 2010)   12:00pm — 12:50pm
Location (room): ESC Theater 2
This presentation is based around much of the material in some of my previous postings (see RTOS related blog postings ). One of the things I like about ESC events is that some of the sessions are free. So if you happen to be attending just the exhibition, then you can still attend this session.

The State of Embedded
Date/Time: Wednesday (April 28, 2010)   4:00pm — 4:50pm
Location (room): ESC Theater 1
Finally, I have been invited to participate in an informal session along with Jack Ganssle and Dan Saks (moderated by Rich Nass of Embedded.com and EE Times) to discuss some of the latest trends in embedded systems. We did a similar session at ESC UK back October 2009, which was very well received. It shall be interested to see how being the token European with a US audience differs from the UK event. This is also a free session.

If you’re at the event look me up and say hello.

Why is technical training so hard to get funding for?

Over many years of delivering technical training to the embedded systems sector, two questions have always bothered me:

• Why, when the economy gets difficult, are training budgets one of the first things to get cut?
• Why do delegates, who have waited months (sometimes years) to attend training, get pulled off mid-course?

Even though a myriad of articles tell us why businesses should invest in training during an economical downturn (Why Invest in Training During an Economical Downturn?) funding for training is very hard to come by. So why does this happen?

In reality there are only two types of training:

• Must-do
• Everything-else

Read the rest of this entry »

Close but no cigar…

After not too much of a learning curve we’ve migrated the website to support wordpress and the associated tools (SQL, PHP, etc.). After checking everything was fine and giving the go ahead for the “go live” for some reason it’s lost the links to all the diagrams from the posts! So I’ll be retrofitting the diagrams over the next week.

First impressions, WordPress is a wonderful leap forward from blogger.

Next post: reflections from embedded world 2010.

The Psychology of Everyday Things

Blogger.com to discontinue support for FTP

Unfortunately Google (via blogger.com) have announced that as of the 26th March 2010 they will discontinue support for FTP uploads from blogger accounts. Current the Feabhas blog is created and managed from blogger but uploaded to our Feabhas server. So having really just got my head around blogging it’s got to be all change. We have a number of posts to publish (including my trip report to embedded world 2010), but I plan to hold off until we have resolved the best route forward (ideally wordpress) . I’m hoping it has no impact on the atom feed, but only time will tell. Watch this space…

Next Page »