Tuesday, June 30, 2009
Wednesday, June 24, 2009
Unix based programming, a free hand to devils. Beyond the boundaries
- http://www.faqs.org/docs/artu/
- http://www.iu.hio.no/~mark/unix/unix_toc.html
- ..will provide more content....... "Unix made easy "
Design pattern, an idea for improvement.
- Abstract Factory Design Pattern
Intent
Provide an interface for creating families of related or dependent objects without specifying their concrete classes.
A hierarchy that encapsulates: many possible “platforms”, and the construction of a suite of “products”.
The new operator considered harmful.
Problem
If an application is to be portable, it needs to encapsulate platform dependencies. These “platforms” might include: windowing system, operating system, database, etc. Too often, this encapsulatation is not engineered in advance, and lots of #ifdef case statements with options for all currently supported platforms begin to procreate like rabbits throughout the code.
Discussion
Provide a level of indirection that abstracts the creation of families of related or dependent objects without directly specifying their concrete classes. The “factory” object has the responsibility for providing creation services for the entire platform family. Clients never create platform objects directly, they ask the factory to do that for them.
This mechanism makes exchanging product families easy because the specific class of the factory object appears only once in the application - where it is instantiated. The application can wholesale replace the entire family of products simply by instantiating a different concrete instance of the abstract factory.
Because the service provided by the factory object is so pervasive, it is routinely implemented as a Singleton.
Structure
The Abstract Factory defines a Factory Method per product. Each Factory Method encapsulates the new operator and the concrete, platform-specific, product classes. Each “platform” is then modeled with a Factory derived class.
Example
The purpose of the Abstract Factory is to provide an interface for creating families of related objects, without specifying concrete classes. This pattern is found in the sheet metal stamping equipment used in the manufacture of Japanese automobiles. The stamping equipment is an Abstract Factory which creates auto body parts. The same machinery is used to stamp right hand doors, left hand doors, right front fenders, left front fenders, hoods, etc. for different models of cars. Through the use of rollers to change the stamping dies, the concrete classes produced by the machinery can be changed within three minutes.
Check list
Decide if “platform independence” and creation services are the current source of pain.
Map out a matrix of “platforms” versus “products”.
Define a factory interface that consists of a factory method per product.
Define a factory derived class for each platform that encapsulates all references to the new operator.
The client should retire all references to new, and use the factory methods to create the product objects.
Rules of thumb
Sometimes creational patterns are competitors: there are cases when either Prototype or Abstract Factory could be used profitably. At other times they are complementary: Abstract Factory might store a set of Prototypes from which to clone and return product objects, Builder can use one of the other patterns to implement which components get built. Abstract Factory, Builder, and Prototype can use Singleton in their implementation.
Abstract Factory, Builder, and Prototype define a factory object that’s responsible for knowing and creating the class of product objects, and make it a parameter of the system. Abstract Factory has the factory object producing objects of several classes. Builder has the factory object building a complex product incrementally using a correspondingly complex protocol. Prototype has the factory object (aka prototype) building a product by copying a prototype object.
Abstract Factory classes are often implemented with Factory Methods, but they can also be implemented using Prototype.
Abstract Factory can be used as an alternative to Facade to hide platform-specific classes.
Builder focuses on constructing a complex object step by step. Abstract Factory emphasizes a family of product objects (either simple or complex). Builder returns the product as a final step, but as far as the Abstract Factory is concerned, the product gets returned immediately.
Often, designs start out using Factory Method (less complicated, more customizable, subclasses proliferate) and evolve toward Abstract Factory, Prototype, or Builder (more flexible, more complex) as the designer discovers where more flexibility is needed
#include
class Shape
{ public: Shape()
{ id_ = total_++; }
virtual void draw() = 0;
protected: int id_;
static int total_;
};
int Shape::total_ = 0;
class Circle : public Shape
{ public: void draw() { cout << "circle " <<>
};
class Square : public Shape
{ public: void draw() { cout << "square " <<>
};
class Ellipse : public Shape
{ public: void draw() { cout << "ellipse " <<>
};
class Rectangle : public Shape
{ public: void draw() { cout << "rectangle " <<>
};
class Factory
{
public: virtual Shape* createCurvedInstance() = 0;
virtual Shape* createStraightInstance() = 0;
};
class SimpleShapeFactory : public Factory
{ public: Shape* createCurvedInstance() { return new Circle; }
Shape* createStraightInstance() { return new Square; }
};
class RobustShapeFactory : public Factory
{ public: Shape* createCurvedInstance()
{ return new Ellipse;
}
Shape* createStraightInstance() {
return new Rectangle; }
};
int main()
{
#ifdef SIMPLE Factory* factory = new SimpleShapeFactory;
#elif ROBUST Factory* factory = new RobustShapeFactory;
#endif Shape* shapes[3]; shapes[0] = factory->createCurvedInstance(); // shapes[0] = new Ellipse;
shapes[1] = factory->createStraightInstance(); // shapes[1] = new Rectangle;
shapes[2] = factory->createCurvedInstance(); // shapes[2] = new Ellipse;
for (int i=0; i <>draw(); }}
Agile , The Philosophy For Software Engineering
The trouble with creating detailed requirements when you start a project, of course, is that by the time you get around to developing the feature you've discovered all sorts of things you didn't know when the original requirements were drafted. That's how we end up with all those change requests floating around. For some processes, that tradeoff may be perfectly acceptable. Others may prefer to trade certainty for flexibility. Some agile methodologies use this approach, by creating "user stories" to capture and track feature requirements in brief until it's time to develop them in detail, when all of the information is available to work with. This approach might work well for very small projects that can't easily bear the weight of a lengthy requirements discussion. You may be surprised at the issues dredged up by writing user सतोरिएस
Agile Technique Brief: Estimating
What this is
This technique brief discusses an agile approach to estimating the size of features for a software development project. The approach, called Planning Poker, provides a mechanism that allows the team to collaborate on an estimate that reflects their combined knowledge and experience.
Why it's useful
The approach to estimating described in this technique brief allows teams to produce useful estimates without spending a great deal of time focusing on unattainable accuracy. The approach uses relative size measurement instead of absolute duration estimates to avoid the variation introduced by different skill levels of team members developing features. The use of velocity to capture the team’s ability to develop features helps to reduce uncertainty.
How to use it
Teams can use the following steps to determine an initial estimate of duration for a project and then monitor progress toward that estimate as the project proceeds.
Establish a feature list for the project.
Gather the team together; the development members to estimate cost, the business members to estimate benefit.
Use Planning Poker to converge on an estimate for each feature. (Detailed instructions are provided in the guideline.)
Determine the desired length of the project’s iterations. The ideal length for an iteration is long enough that the team can deliver something of value, but short enough that it is not painful for the business to wait and change something. Typical iterations last between 2 and 4 weeks.
Determine an initial velocity. The best way to do this is to determine how many features the team can commit to delivering in the first iteration. Add up the story points associated with those features and use that as the initial velocity.
Divide the total story points included in the feature list by the velocity to determine how many iterations will be required, then convert the number of iterations to days or weeks depending on what is preferred by your organization. The result answer is the anticipated duration of the project.
After the first iteration, total up the story points from the features that were completed (i.e. accepted by the Product Owner). This is the actual velocity of the first iteration. Recalculate the expected duration based on this new velocity.
After the second iteration, recalculate the overall team velocity by averaging the velocity from the first two iterations.
Repeat after each iteration, monitoring the corresponding impact on the expected date that the feature list will be completed
Agile Technique Brief: Agile Planning
What this is
This technique brief provides an overview of agile planning, an iterative and feature-based approach to project planning.
Why it's useful
Agile planning is feature-based, iterative, owned by the team, and uses different levels of detail. These characteristics provide teams an opportunity to get rapid feedback on their designs and processes, apply learning from past experiences quickly, and keep their project plans simple, but effective. This approach to planning provides project teams with a means to produce features in a short amount of time in order to gain useful feedback from users, customers, and stakeholders. It also allows teams to defer decisions on detailed requirements until the feature is being developed, allowing them to apply the most current and accurate information possible.
This approach works when the team has decided to follow an iterative and incremental project approach and is most useful in situations where the product of the project can be delivered in small increments.
How to use it
There are several different layers of planning. This technique brief describes three of those levels—release planning, iteration planning, and daily planning. The following steps provide an overview of how to start planning at the beginning of a project. Assume the project has been approved to proceed and that there is a project value model with a defined project purpose, considerations, and cost-benefit analysis.
Gather the team together to refine and update the project value model with any new information and to establish a feature list.
Prioritize the feature list by determining the relative cost, benefit, and value of the features.
Determine in what releases those features will most likely be delivered. (See the Release Planning section.)
At the start of each iteration, pick features for that iteration and break them into tasks. (See Iteration Planning.)
On a daily basis, coordinate the team’s activities. (See Daily Planning.)
Repeat Steps 3–5 as appropriate.
Agile Technique Brief: Project Value Models
What this is
This technique brief describes an approach a team can use to make value-based, rational, objective decisions about what projects and features to do and in what priority to deliver them. It guides teams to:
Establish a shared understanding of the project purpose
Identify the various considerations that impact the project on a daily basis
Determine the expected costs and benefits realized by a project
Use this information to make informed decisions
Why it's useful
Informed decision-making is one of the key factors of success on projects, so it is very helpful for teams to understand the components of good decision-making. In the case of projects and features, these decisions should ideally be made on the basis of value, with the appropriate information available and at the appropriate time. The Project Value Model helps teams identify the information necessary to make value-based decisions, and organizes that information so it can be used to make decisions throughout the project as conditions change.
How to use it
Gather the team together to establish a shared understanding of the project purpose.
Establish a place to record project considerations. Use the collaboration process to create an initial list of risks, assumptions, and constraints. Add to this list whenever new items come up.
Determine your organization’s preferred approach to cost-benefit analysis, and create a spreadsheet that allows your team to quickly revise cost and benefit information throughout the life of the project, in order to determine the value delivered. Include a way of tracking assumptions related to various cost and benefit items, for quick tracing of how various cost and benefit numbers were determined.
Decide whether or not to pursue the project. Use the Purpose Alignment Model to identify how the project aligns with the organization’s strategy. Decide whether the project is worth pursuing based on its support of differentiating or parity activities. If there are any risks too large to overcome, or any constraints that cannot be met by the project, do not pursue the project.
Compare cost-benefit information with the organizational expectations and decide whether the initial instance of the project provides the expected value.
Determine the relative cost, benefit, and value of the requested features and produce an ordered features list