Best Practices for Design in Agile

August 7, 2015 § 1 Comment

A Bibliography, mostly discussing UX Design but a little on the related issue of Architectural Design.

SIDA: Moving Object-Oriented Design beyond Model-View-Controller

September 16, 2011 § 2 Comments

[Update: this post has been obsoleted by RIBS: Marrying the REST and MVC Design Patterns « iHack, therefore iBlog]

SIDA stands for “State • Interface • Data • Algorithm“, and is a refinement of my earlier “DIDA” model (where the “D” stood for Design).  DIDA in turn was an expansion of the well-known Model–View–Controller design pattern based on insights from the Data-Context-Interactions architecture.

State • Interface • Data • AlgorithmThe key premise of SIDA is that there are four primary artifacts that need to be designed, from the most important on down:

  1. Concrete States
  2. Clear Interfaces
  3. Consistent Data
  4. Concise Algorithms
These in turn are related in a particular system via the:
  1. Presentation of Views
  2. Controlling of Actions
  3. Binding of Roles

as shown in the accompanying diagram.

In a simple system, the state is implicit and the relations are absorbed into one of the artifacts, reducing SIDA to the traditional View, Model, and Controller, respectively.  For more complex systems, however, it may make sense to design explicit objects for each relation, e.g., traits for roles, presenters for views, and strategies for actions.

In addition, SIDA is intended as a general architecture, describing the internal structure of everything from databases to web services to GUI applications.  An interface as defined from inside the system may appear as data or an algorithm from outside the system.

The most interesting (and perhaps unusual) aspect of this diagram is how it makes state a central features, something developers never use. If state really is so central to the design process, perhaps it deserves explicit language support, as provided by UnrealScript or typestates (as in Rust).

This is all still merely a hypothesis on my part, as I haven’t actually put any of this into practice yet.  Anyone with more experience care to comment?

DIDA: Reinterpreting MVC object modelling in light of DCI

September 15, 2011 § 2 Comments

[UPDATE: This post has been obsoleted by SIDA: Moving Object-Oriented Design beyond Model-View-Controller]

I recently read about The DCI Architecture: A New Vision of Object-Oriented Programming, a successor/complement to the original Model–View–Controller design pattern, by one of the original authors.  The DCI stand for:

  • Data
  • Context
  • Interaction
I was both impressed and confused.  Impressed because I’ve been thinking for a while that MVC wasn’t quite sufficient, and this seems like a big leap forward.  Confused, because most of their discussion revolved around roles (typically implemented as traits) and algorithms, so I couldn’t quite figure out where exactly Context and Interactions fit in — much less how they related to MVC objects.
Design Interface Data AlgorithmTo help me sort it all out in my head, I developed a comprehensive picture I call DIDA, which attempts to incorporate both MVC and DCI in a single unified design pattern. DIDA stands for:
  • Design
  • Interface
  • Data
  • Algorithms
In a sense, it uses the critique from DCI to tease apart to the components of MVC.   In particular, traditional MVC tends to combine the roles and data into model classes, the presentation and interface into a view hierarchy, and all the actions and algorithms into a single controller.  The key insight of DCI (as best I understand it) is that  roles should be kept distinct from the “mostly dumb” data, and only bound in the context of a particular algorithm, which should be clearly spelled out in its own software construct. I used the same logic to similarly extract the Presenter Pattern from views and to separate controllers from algorithms.
The basic idea is that the Interface, Data and Algorithms are three primary nouns you need to Design as part of an application (roughly in that order).  Those in turn determine the roles, presentation, and actions necessary to wire everything together.  Depending on the use cases, it may make sense to implement everything as traditional MVC objects, but it might be wiser to use, e.g., traits, presenters, and strategies to enable weaker coupling.
As far as I can tell, this approach captures the key benefits of DCI, but is much easier to understand and apply. Of course, I could easily be overlooking something. Please let me know what you think.

Where Am I?

You are currently browsing entries tagged with design at iHack, therefore iBlog.