AOSD Glossary and Principles

AOSD (Aspect Oriented Software Design) is arguably the most important software concept and method developed in the past two decades. To understand it, a new vocabulary must be used. The most important ones, are: Concern, Aspect, Dominant Decomposition, and Weaving. The AOSD method focuses on solving the problem of “Tyranny of Dominant Decomposition”. When AOSD is used together with other software best practices (like Design by Contract method, Agile processes, Domain Specific Language tools), a nearly perfect software can be created with no much more cost than normal software.


Definitions

  • Concern: “A concern is an area of interest or focus in a system. Concerns are the primary criteria for decomposing software into smaller, more manageable and comprehensible parts that have meaning to a software engineer. Examples of concerns include requirements, use cases, features, data structures, quality-of-service issues, variants, intellectual property boundaries, collaborations, patterns and contracts. There are many formulations used to capture concerns as well-identified separate units, aspects are one such mechanism, that are tuned to capturing crosscutting concerns.”
  • Aspect: “Aspects are one kind of concern in software development. With respect to a primary or dominant decomposition aspects are concerns that crosscut that decomposition.”
  • Dominant Decomposition: “Traditional languages and modularization mechanisms suffer from a limitation called the Tyranny of the Dominant Decomposition: the program can be modularized in only one way at a time, and the many kinds of concerns that do not align with that modularization end up scattered across many modules and tangled with one another. This description is paraphrased from IBM’s T. J. Watson Research center’s research on Morphogenic Software. See also, Multi-Dimensional Separation of Concerns.”
  • Weaving: For short, it is the coding practice to add new features into a software. A new feature design sometimes can not be expressed with code textual clarity. When a new feature (new concern) needs to be added to a well-established system, chances are you need to scatter the new feature code across many existing components/modules. One way of scattering the code is by AOP (Aspect-Oriented Programming). In general the process can be referred to as “code weaving”.

Applying AOSD/AOP Principles

Aspect-Oriented method can be applied by using formal tools (e.g. AspectJ), or can be applied by loosely following a set of principles.

  • Flexible Fundamental Architecture: A fundamental architecture usually captures things more or less of an OS-Service nature, like multiple-tasking design, memory management strategy, task synchronization rules, etc. It should be processor-oriented system decomposition, for execution (hardware resource) efficiency purpose. Special care must be taken to consider the patterns in which later designs will use these fundamental services. It is of extreme importance to design the fundamentals flexible enough to suit the types of applications sitting on top of it. Also be aware of the impacts the application will impose on it, and beyond (impacts on other applications through OS).
  • Consistent Application Data Structure: By “Application Data Structure” we really imply that the design starts with “data design”, not the object design or something with a more fancy term. For a simple application you can jump straight into objects. To work on a large and complex system, you may better off with a consistent global data store. This is more obvious with database applications, but should be considered important to all types of software applications.
  • Features as Aspects: Features are usually directly derived from requirements. A common mistake in software process is to start with only features, and map them directly to the code structure. Worst sometimes we directly map features into tasks (OS tasks) and thought tasks are the only software partitioning units. The correct approach, is to keep in mind that a feature will need to be served by OS services (or more accurately, serviced by fundamental architecture constructs), scattered across global data store and multiple tasks. This (feature weaving) is, by itself, the most difficult part and worth a lot effort in a few iterations. Do think about it carefully and fine-tune it repeatedly.

A note: My previous post “Design by Overlay” is in some way thinking about the same thing, in a more Mozilla style. I created the term “Design by Overlay” because having not come up with a better expression, probably will consolidate the terms someday.

Creative Commons License
This work by minghuasweblog.wordpress.com is licensed under a Creative Commons Attribution 3.0 Unported License.
This work is licensed under the Creative Commons Attribution 3.0 Unported License. To view a copy of this license, visit http://creativecommons.org/licenses/by/3.0/ or send a letter to Creative Commons, 444 Castro Street, Suite 900, Mountain View, California, 94041, USA.
Published on minghuasweblog.wordpress.com on Sep 30, 2011 @ 20:10 GMT
Advertisements

About minghuasweblog

a long time coder
This entry was posted in All, Methods and tagged , , . Bookmark the permalink.

One Response to AOSD Glossary and Principles

  1. Pingback: Software Observability, Structure, and Automation – Why and How | minghuasweblog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s