Designing good software is a constant battle with complexity. Great software designers know this and mercilessly strip away all unnecessary complexity. They are intolerant of unnecessary complication, flexibility and cleverness in designs and code. Nevertheless, some complexity is unavoidable, often where performance needs to be optimised or when, ironically, it is needed to create an illusion of simplicity in the user experience. Here, good design encapsulates the complexity, hiding it behind much simpler service-oriented and object-oriented interfaces of carefully selected abstractions. The best software designs are ingeniously simple or at least present a perception of simplicity to their users. The elegance of such solutions can be truly delightful.
Understanding the Problem
Great software designers know that one of the primary keys for creating simple, elegant designs is an intimate understanding of the structure and dynamics of the problem they are trying to solve. They also accept that for more complex problem domains, this is always and iterative process and analysis cannot be fully separated from design, implementation, and testing too.
One of the most documented problems of the old waterfall Critical to doing this is an intimate understanding of the domain you are working within, the inevitable trade-offs of the design options available, and a passionate intolerance of low quality work. This is regardless of whether we do all the analysis and design within dedicated phases of a traditional, waterfall-style process or iteratively as part of a modern agile approach.
One of the very best techniques for initial analysis of the problem domain of an enterprise software system is Peter Coad's somewhat simplistically-named 'modeling in color'. The culmination of a number of years work by Peter Coad and colleagues, modeling in colour is a set of concepts, strategies and patterns for fast, pragmatic, problem domain analysis for both agile and traditional development teams. It helps pick better domain classes quicker and gives your software a more resilient, extensible foundation; far less serious refactoring needed later.
All teams working in .Net, Java or Cocoa have some sort of object
model at the heart of their software. Modeling in colour helps ensure
it is robust, flexible, and extensible from day one. Use it with a Scrum-like approach to produce
a better backlog earlier, or as an integral part of a more Feature-Driven
Development (FDD)-style project.
Since the turn of the century, the Unified Modeling Language (UML) has been the de facto graphical notation for modeling and communicating software analysis and design. From its relatively simple start, UML grew into a large, over-complicated, clumsy, and frequently impractical standard. Nevertheless, the enormous benefit of a common, shared notation for software analysis and design means it remains important. Thankfully, it is not necessary to learn every different symbol and squiggle of the language to use it. Like any language, you only need to know a very small proportion to be able to communicate effectively. Neither do you need an expensive UML modeling tool to use UML. The best UML tools for the job are often coloured, sticky notes, flip-chart paper, and marker pens.
Notes on various aspects of designing applications, components or systems using the standard and enterprise editions of Java. Although details may differ, the design principles are often just as applicable for .Net languages such as C# and VB.Net and developing in Objective C and Cocoa.
Analysis and Design
A set of introductory notes and notes on topics that do not fit naturally into any of the other categories above. Topics range from object modeling to list management and layered architectures
Jim Highsmith, InformIT Article, 2002
One of the most common initial strategies for selecting the types of object needed in a software system, service or component is to define a set of logical layers into which we can place candidate classes. There are various layering schemes but they are generally variations of a similar theme.
Object Modelling: Why would I waste time doing this?
All software teams writing in programming languages like Java and the .Net family of languages have an underlying object model represented by the classes of objects they define in their source code. Therefore, it is not a question of whether to build an object model or not...
Object Modeling in Colour
Object-oriented analysis with class archetypes: 'Modeling in Color' is a set of patterns and strategies that can help produce better object-oriented analysis and design models.
'Modeling in Color' is a set of patterns and strategies that can help produce better object-oriented analysis and design models...