Development models:

The text starts off with a description of the older style waterfall development model, quickly details its disadvantages (rigidity, unable to cope with changing requirements, assumes all design is nailed down from the start), and moves on to newer and much more useful models.

Incremental and iterative models are given as examples of more appropriate implementations. These models have the distinct advantage of being able to cope with changing requirements – in these models, feedback is provided constantly through the use of prototypes, whereby users can review the current work, alter their requirements to fit new criteria, and then proceed onwards with new ones.  It introduces the concept of risk management – if some of your biggest risks are changing requirements, then it makes sense to find a way to manage these, by reviewing and updating the requirements and expectations at frequent intervals.

There are various ways to implement these models – timeboxing (define a set time in which to complete a subset of requirements), prioritising (where requirements are prioritised and implemented in order), and others. For any project planner will need to decide which planning model is appropriate for their work.

The Unified Process is one of these. It advocates short time-boxed iterations – the advantage here is that a lot of functionality can be prioritised, implemented and reviewed in a short time, but it can also leave you open to time constraints if there are unforeseen difficulties with the work planned. A UP project has 4 phases – inception, elaboration, construction and transition. The correct use of these phases is what makes the UP a powerful tool.

Modelling and UML:

Next the problem needs to be modelled. The concepts of domain, specification and design modelling need to be discussed. Domain involves understanding the situation/problem we are trying to solve. Specification involves describing a system to solve the problem. Design is the low-level implementation of that system. One of the biggest advantages of modelling a system is the ability to use a defined language or process to lay out the design in precise notation. One such notation is UML. It allows a designer to specify the various levels of interaction within a system, such as classes, models, functions, etc… and all of the connections and dependencies between them.

Object-Oriented Development:

The concept of OO development was a natural outgrowth of the search for a better development model. On the surface it seems deceptively simple, create a system of interacting objects utilising tight cohesion and low coupling. It gives the developer an enormous amount of power though – you can use this simple idea to model alsmot anything you would come into contact with. Take the example of a car. A vehicle has X no. of wheels and an engine. It is your base object. A car then is an extension of this concept, being a more concrete example of a real world use case. A truck is another. Both of these inherit they’re base attributes from the base object. These objects have other attributes that they encapsulate, and can be interacted with, and can in turn interact with other objects.

This OO paradigm is the natural successor to functional programming. Functional programming would get the job done in most cases, but would not supply the power and simplicity required for large scale systems. For enterprise design this would have been essential. Extrapolating further from the concept of objects you now have whole hierarchy trees of branching, related objects, and looking a further level out you see that you can have networks of unrelated but still interacting objects. Communication across systems spanning various protocol levels are now much easier to envisage.

I won’t go into detail on the basics of how to explain, create and use samples of objects, other wiser heads have done a far better job than I could. Suffice it to say that by using this implementation you can achieve powerful results, particularly when aligned with object modelling, which can give you almost a 1-1 correlation from design to implementation, effectively speccing out the entire system from the very beginning.

Software Reuse:

Let’s say you’re tired of having to rewrite your software from scratch every time you need to use it. Perfectly understandable, nobody wants to do that. It has long been an unfulfilled promise of the software engineering discipline to provide frameworks of readily available software modules that can be clicked together in any configuration to build the required system. This has never really been delivered. A core ideal of software design is local reuse. This is great within the design of a single system, as it allows code reuse within a system to achieve a high degree, and encourages developers to correctly consider all of the design needs ahead of time.

But up until now this hasn’t really been applied from a larger scale perspective. Say you’ve designed this lovely system where not a single line of code is duplicated, nothing is unused, cohesion is high and coupling is low. Great. But it doesn’t click in as a module for larger products. Or you can’t break the constituents down easily into a bunch of plug and play components.. This is the long sought after reuse that has been promised but not delivered.  The idea of the product line comes in here – a set of base line objects that can be combined into any configuration such that the final system produced completely satisfies all of the user’s requirements. Hey presto, you have your Grail.

One way of achieving this reuse are design patterns – design patterns are open solutions to common problems: take for instance the Singleton pattern (there can be only one…) the Singleton is a pattern which defines a component such that there can only ever be one of it in existence at any time. This can be extremely useful for things like persisting system state and so on.. There are dozens of them out there, exceedingly powerful, and well worth consideration.

CASE Tools:

A CASE tool (Computer Assissted Software Engineering) is one created to assisst in the design of middle to large scale systems, or even small ones if you really feel the need. What it allows you to do is express your design in a modelling language in a structured way. There are a wide number of such tools available, some of them very expensive and useful, though the first does not neccessarily imply the second. Tools such as Rational Rose would be a good example of a CASE tool. Some of them allow for a creation of a model from first principles right through to the barebones implementation of the system itself, with just the code implementation details to be filled in after. However most of them are not quite that good yet, so some coding skills are still required

Related articles by Zemanta

• Interesting Resources to learn Object Oriented Design (woork.blogspot.com)
• Real Ultimate Programming Power (codinghorror.com)
• Model Driven Architecture: Feasibility or Fallacy? (tc.eserver.org)
• Back to Basics: Interfaces (codebetter.com)
• The Building Blocks Of Modularity (slideshare.net)