So you have a picture in your head. You can see it. From a variety of angles. What it looks like laying flat, how it stands, how it will work when it becomes real.
Of course, things we build start out as pictures in our minds and in many cases just sketching out some lines and words is enough to work out the dimensions, the layout, how it will look. Enough to show someone else what it will look like.
Software can get pretty complex, though. Will the developer across the world understand what your squiggle means? Will the guy who has to maintain the software three years from now? Luckily, engineers and others have studied how humans model things and the techniques they developed can be useful for both thinking through ideas thoroughly and communicating them in an unambiguous way to others. Universal Modelling Language is such a technique, a standard way to model and communicate software ideas.
UML defines standard ways of diagramming, which is probably its most used -- and useful -- contribution. The problem is there seems to be a pretty wide gulf between a simple napkin sketch and UML and it's 13 (!) types of diagrams (and thick instructional books).
It doesn't have to be that way, though. In my opinion the most useful aspects of UML boil down to some fairly simple bare essentials readily gleaned from examples which I attempt to provide in the following presentation.
It's true that refactoring is all the rage with the programming fashionistas. But really, is it ever advantageous to not take a little time to think things through? With a few basics UML can be a pretty useful napkin.
Saturday, June 1, 2013
Wednesday, March 13, 2013
Communication reliability
One
of the most important things to consider when designing communication
between two systems in an enterprise is reliability: Does the sender
need to know if messages were delivered to the receiver? If an error
occurs on the receiver, does the sender need to know? Does the sender
need to know what type of error occurred? Do messages need to be
received in the order they were sent? What about receivers that may go
offline or networks that go down? Does communication need to participate
in a transaction so state consistency is maintained across multiple
systems?
Before
designing interfaces and selecting network protocols, it's necessary to
understand the reliability requirements of the communication and how
requirements align with the capabilities of protocol standards and
industry techniques. Because the matrix of communications protocol
capability and techniques as related to reliability is rather complex,
it's useful to categorize communication reliability requirements based
the following:
- Unordered: Unordered is useful for providing information to one or more interested receivers quickly. Communication is one way and does not block. Receivers cannot return information back to the sender and senders don't know if communication with receivers was successful.
- Receive-reply: For communication to a single receiver, Receive-reply requires a sender wait for a reply or timeout. Both information and errors can be returned in the reply and senders know if communication was successful.
- Ordered: Provides ordered communication with one or more receivers. Information cannot be returned from receivers to senders but errors can. When configured to return errors, Ordered communication blocks but otherwise can be configured to be non-blocking.
- Guaranteed: A form of Ordered communication, Guaranteed cannot return information or errors but guarantees delivery even if the receiver isn't running when sent.
- Transactional: Either configured as Receive-reply or Ordered, Transactional can return information to the sender if configured as Receive-reply, can always return errors, and can further participate in a transaction as a durable resource.
Subscribe to:
Posts (Atom)