Everyday frameworks in applictions
Date: Sat, 29 Oct 2005
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
with one or more
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
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
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
Finally, after being so busy, I can say I not only attended
, 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.
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
If anyone is interested in joining a discussion group to discuss and help shape the
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
, please join in.
Join D4 Pattern Language
D4 Software Frameworks
Date: Sun, 02 Oct 2005
A Pattern Language for Designing, Developing, Documenting and Deploying
Object-Oriented Software Frameworks
Jonathan Crossland, Software Architect, Lucid Ocean Limited,
D1: 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.
Find what is inherently or adherently common
Find what is common via abstraction.
Refine abstract and generalized concepts.
Use one or more Design Patterns (GOF) to achieve goal.
Apply good design principles such as
Start with DesignGeneralized, then DesignAbstraction and lastly DesignRefinement
D2: Developing Patterns
are used to provide Patterns for implementing Software Frameworks. Developing patterns are architecturally minded, and they serve to
Designing Patterns by their implementation techniques.
Discover where your hotspots should be. Choose DevelopWhitebox or DevelopBlackbox
You want less DesignRefinement or require some form of DesignAbstraction or DesignGeneralized to remain.
You want less DesignAbstration or DesignGeneralized and want complete DesignRefinement.
You have used DesignBlackbox and require more flexibility and customization.
You have used DevelopWhitebox and want to allow for easier and quicker DesignRefinement.
You have ConfigurationTool and CodeGeneration but want more power and flexibility.
D3: Documenting Patterns
are used to describe the Software Framework and aid the Deploying Patterns.
They facilitate and maximize understanding and therefore protential reuse.
You must provide a reference of interfaces.
You need to provide examples of isolated features of the framework that a pure reference cannot show.
You need to combine a large amount of recipes.
Using tools and generators, you can generate documentation.
D4: Deploying Patterns
the Software Framework itself, and looks at ways that maximize the Frameworks reuse potential.
Although Documenting Patterns are applied, Your framework requires easy and quicker implementation and adoption.
You need to show off and demonstrate complex capabilities that WritingRecipe and WritingCookbooks do not show.
Although Documenting Patterns are applied you need to further adoption.
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
A "Framework" for Object Oriented Frameworks Design
- Parsons, Rashid, Speck, Telea
Design, implementation and evolution of object oriented frameworks: concepts and guidelines
- J. van Gurp, J. Bosch
Date: Sun, 02 Oct 2005
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.
October 2005 (*)
September 2005 (12)
August 2005 (23)
July 2005 (9)
June 2005 (6)
May 2005 (0)
April 2005 (6)
March 2005 (0)
February 2005 (0)
January 2005 (6)
December 2004 (0)
November 2004 (3)
October 2004 (0)
September 2004 (3)
August 2004 (3)
July 2004 (11)
June 2004 (48)
May 2004 (8)
April 2004 (8)
March 2004 (9)
February 2004 (25)
January 2004 (13)
December 2003 (23)
November 2003 (13)
October 2003 (3)
September 2003 (13)
August 2003 (17)
July 2003 (11)
June 2003 (12)
May 2003 (9)
MS Patterns and Practices
MS Architects Journal
GotDotNet Architectural Repository Workspace
XP Agile Universe
Welcome to my Weblog
Select a Topic
Everyday frameworks in applictions - Frameworks
Reverse Composite Pattern - Patterns
The Microsoft Pattern - Patterns
I am UT2K4 Champion - General
IslandGamers LAN Event IG15 - Isle of Wight
Join the d4 group - Frameworks
D4 Software Frameworks - Frameworks
Designing Iteratively - General
Copyright © 2003 Jonathan Crossland. All rights Reserved. Information is provided as-is and changes issued on my discretion.