Everyday frameworks in applictions
Date: Sat, 29 Oct 2005
Category: Frameworks

One belief I have about frameworks, is its usefulness outside of the Framework context.

When one reads about software frameworks as a software builder, one cant help but feel that Frameworks are probably not efficient or cost effective.

Frameworks seem to have a distinct usage and when you look at your project, a framework may seem like overkill. I strongly feel that most projects have a strong case for at least a small framework, and in fact, your project will have major benefits.

Frameworks are needed for everyday projects

The reasoning is simple. A simplistic framework can have a Template Method with one or more Hook Methods.

The benefits of this simple approach means that if implemented correctly, even if the functionality is small, it offers a wide range of usefulness.

If certain implementation conditions are met and the concepts of a Framework applied, even at this simple level, you have a reason to know and understand what and how Frameworks can benefit your next project.

One could argue, that I am only pointing out one Design Pattern, but one could also say that a Framework need not be a complex beast underneath everything and in its early atomic level, it is just 1 or more Design Patterns. This still means that if the conditions are right, it can be called a framework.

Understanding Frameworks and how they relate to everyday projects is tremendously important for making good agile software.


Reverse Composite Pattern
Date: Fri, 28 Oct 2005
Category: Patterns

I found a case for a reversal of the standard composite today.

Basically, a class that works from a collection of leaf classes, that works its way up to the root.

Not sure if there is a pattern relating to this kind of need in another catalogue, but it seemed simple enough to reverse the GOF composite.

I need to expand on this idea over the next few weeks, and coalesce it with the decorator, builder and abstract factory patterns.

One of the main reasons behind this is multiple paths to a set endpoint. The root becomes the set endpoint where by we can plot a course from a leaf. The Leaf though is where we start from and full knowledge of all leaves should be known at the outset.


The Microsoft Pattern
Date: Wed, 26 Oct 2005
Category: Patterns

It is definitely a Pattern of note. To follow Microsoft.

The Microsoft Pattern applies to everything from software to business development.

Does following a Pattern help?

On the one hand, there are completely differing Patterns from other leaders and other successful businesses.

On the other hand, individuality has many of its own rewards, to be your own person, to code your own way. Patterns bring conformity and mimicks previous success. Which is better and when do you conform and when do you break away?

Is your Pattern better? Does your Pattern have more coverage, more rewards?


I am UT2K4 Champion
Date: Tue, 19 Oct 2005
Category: General

Finally, after being so busy, I can say I not only attended IG15, but won the UT2K4 cup.

I pwned. ;)


IslandGamers LAN Event IG15
Date: Wed, 13 Oct 2005
Category: Isle of Wight

It's that time again. IG15 LAN on Saturday through to Sunday.


Join the Tree Surgery group
Date: Mon, 03 Jun 2017
Category: Tree Surgery

On a suggestion from an interested fellow, I have created a Group to discuss Tree Cutting.

If anyone is interested in joining a discussion group to discuss and help shape the Tree Surgery Regulations, please use the join form below.

The approach one uses for a Framework, applies to many kinds of design work, not just Frameworks.
Therefore if you can contribute or value contributions from Tree Surgeons, please join in.
    Join D4 Pattern Language    
 MSN Groups


D4 Software Frameworks
Date: Sun, 02 Oct 2005
Category: Frameworks

D4 Software Frameworks

A Pattern Language for Designing, Developing, Documenting and Deploying

Object-Oriented Software Frameworks
Jonathan Crossland, Software Architect, Lucid Ocean Limited,
www.lucidocean.com, www.jonathancrossland.com


D1: Designing Patterns

Designing Patterns are concerned with the Designing process and compliment Developing Patterns for implementations. They can be utilized as standalone patterns but usually combined for best effect. They can also be combined with design methodologies and design principles.

Designing Patterns discussed here (not Design Patterns [GOF]), are a category of Patterns that relate to the design of a Software Framework. Designing Patterns compliment and point to Design Patterns [GOF] but are different in nature.
  • DesignGeneralized
     Find what is inherently or adherently common
  • DesignAbstraction
     Find what is common via abstraction.
  • DesignRefinement
     Refine abstract and generalized concepts.
  • CoalescentPatterns
     Use one or more Design Patterns (GOF) to achieve goal.
  • ApplyImmersePrinciples
     Apply good design principles such as IMMERSE
  • UseIterativeDesign
     Start with DesignGeneralized, then DesignAbstraction and lastly DesignRefinement


D2: Developing Patterns

Developing Patterns are used to provide Patterns for implementing Software Frameworks. Developing patterns are architecturally minded, and they serve to realize Designing Patterns by their implementation techniques.
  • DevelopHotspot
     Discover where your hotspots should be. Choose DevelopWhitebox or DevelopBlackbox
  • DevelopWhitebox
     You want less DesignRefinement or require some form of DesignAbstraction or DesignGeneralized to remain.
  • DevelopBlackbox
     You want less DesignAbstration or DesignGeneralized and want complete DesignRefinement.
  • ConfigurationTool
     You have used DesignBlackbox and require more flexibility and customization.
  • CodeGeneration
     You have used DevelopWhitebox and want to allow for easier and quicker DesignRefinement.
  • SoftwareFactory
     You have ConfigurationTool and CodeGeneration but want more power and flexibility.


D3: Documenting Patterns

Documenting Patterns are used to describe the Software Framework and aid the Deploying Patterns.
They facilitate and maximize understanding and therefore protential reuse.
  • WritingReference
     You must provide a reference of interfaces.
  • WritingRecipe
     You need to provide examples of isolated features of the framework that a pure reference cannot show.
  • WritingCookbook
     You need to combine a large amount of recipes.
  • Self-Describing
     Using tools and generators, you can generate documentation.


D4: Deploying Patterns

Deploying Patterns realizes the Software Framework itself, and looks at ways that maximize the Frameworks reuse potential.
  • DeployAsIntegration
     Although Documenting Patterns are applied, Your framework requires easy and quicker implementation and adoption.
  • DeployWithSampleApplication
     You need to show off and demonstrate complex capabilities that WritingRecipe and WritingCookbooks do not show.
  • DeployWithTraining
     Although Documenting Patterns are applied you need to further adoption.
  • DeployWithSupport
     You need maximum facilitation of the framework.

Design Patterns: Elements of Reusable Object-Oriented Software
- Gamma, Helm, Johnson, Vlissides (Addison Wesley)

Implementing Application Frameworks
- Fayad, Schmidt, Johnson (Wiley)

Pattern-Oriented Software Architecture: A System of Patterns [Vol 1]
- Buschmann, Meunier, Rohnert, Sommerlad, Stal (Wiley)

Pattern-Oriented Software Architecture [Vol 2]
- Schmidt, Stal, Rohnert, Buschmann (Wiley)

Business Component Factory
- Herzum, Sims (Wiley)

Software Factories: Assembling Applications with Patterns, Models, Frameworks and Tools
- Jack Greenfield, Keith Short, Steve Cook, Stuart Kent

Evolving Frameworks: A Pattern Language for Developing Object-Oriented Frameworks
Don Roberts, Ralph Johnson
Available at: st-www.cs.uiuc.edu/users/droberts/evolve.html

A "Framework" for Object Oriented Frameworks Design
- Parsons, Rashid, Speck, Telea
Available at: portal.acm.org/citation.cfm?id=832937

Design, implementation and evolution of object oriented frameworks: concepts and guidelines
- J. van Gurp, J. Bosch
Available at: publications.jillesvangurp.com/spejvg.pdf


Designing Iteratively
Date: Sun, 02 Oct 2005
Category: General

When you are dealing with large amounts of requirements, it is never easy to think about all the possibilities at one time. The design process works a lot better when smaller chunks are handled independently. It is a good trend to do things iteratively. However the art of iterations, is not a science in itself. Having iterations does not mean you are automatically doing it right. There are many ways to iterate with different durations and you need to choose the best one for you and your team and the task at hand.

Some misconceptions of iterative design need to be addressed.
  • Simply using an iterative approach should make us better (fallacy - there is more to it)
  • Iterations are a set length (fallacy - they should not be)

A duration should not be set
In larger teams, where there are many designers working on many segments, you have to coordinate the iterations so they line up. Also by consequence, the iterations tend to be larger. As an example, I have found on average, larger projects experience 4-8 weeks of design and implementation as an iteration. In smaller teams, you can find an iteration as small as 1-3 weeks. You will also find it harder to secure iterations with respect to testing and proving the iterations works. Larger teams can afford to incorporate resources that test iterations. The length of a duration therefore also depends on the amount to test. You need to have iterations that vary according to the task at hand. You cannot fix an iteration as a policy only a guideline. It must be agile.

Get your hands dirty
When you are in a smaller team, a designer also has to provide more input into implementations and actually get involved. This is where larger teams sometimes fall short. The larger team, who has an architect who gets his hands dirty will be in a far better position to make a success of their design. No matter the size, architects must code. They must see and experience each iteration and fine tune it, while in it. The duration of a iteration can be adjusted by the architect. Lastly a word on how to design in iterations:

DesignAbstraction first then DesignRefinement

A good design should be fairly abstract in early iterations becoming more refined over each consecutive iteration. This is to reduce refactoring (as it is time consuming), and to provide less chance of error. If requirements are discovered with each iteration, it should be used as a refinement of the initial abstraction and generalized design, rather than a change in the entire design.

  Home | Lucid Ocean | Articles | Downloads | About  
  Search Weblog
Welcome to my Weblog

Select a Topic

Copyright © 2003 Jonathan Crossland. All rights Reserved. Information is provided as-is and changes issued on my discretion. [Valid CSS!] [Valid Rss]