Sequence Diagrams are associated more with UML and object oriented design than embedded software design. But UML sequence diagrams are very useful for describing system behavior over time. They also help us understand how the system interacts with its environment. The sequence diagram basically shows system actions based on fixed inputs over a given time line.

There are three elements to consider when creating a sequence diagram example.

1. The objects or libraries used in the sequence of events placed horizontally in a row across the top
2. The life line which is a dashed line that drops down vertically from each object
3. The events that occur in sequence as we go down the lifeline

Sequence diagrams are ideal for remote communications projects using modems because each step in the communications process can be described in sequence over time. All the clutter of control structures and data structures is removed, and we are left with a very clear picture of the communications events only.

This concept can be applied to almost any peripheral especially when a human interface is involved.

Although we keep the design methodology close at hand when think about our programs, we do not always design and document a sequence diagram for you unless requested. As mentioned before there are several advantages to having your documentation on hand:

· You have a better idea about what your program does without trying to figure it out from code
· You can clearly explain to your next programmer, who may be your employee what exactly was done
· You can leverage documentation to your end user which describes the device application

It is best to request a documentation package during initial stages of the project, while we are working on the elements of the project that need to be documented. It will take twice as long to go back and correctly document what has been done in the past.