Software Development: Analysis and Design
Put simply, analysis in software development is understanding what needs to be done and design is working out how to do it. More formally:
- analysis is the examination of the elements and structure of the problem to be solved
- designis the conceiving of a solution to the problem.
In analysis we break down a complex subject into smaller parts, study each of the parts to gain an understanding of each one, and then combine our understanding of the parts to form a better understanding of the whole. Analysis, therefore, plays a critical part in defining the requirements for a piece of software.
In design we develop a plan for a new or enhanced software system, application or component. Design is about trade offs and compromise. All designs have different strengths and weaknesses. A poor design is one where, no matter what the point of view, the weaknesses of the design outweigh the strengths. Conversely a good design is one where the strengths of the design outweigh the weaknesses from the most important perspectives if not all of them.
Two approaches to analysis and design have dominated in software development over the last two or three decades:
- structured analysis and design
- object-oriented analysis and design
Structured Analysis and Design
Becoming popular in the 1980's, structured analysis and design approaches are used to produce a set of processes executing functions (subroutines) that operate on a set of data structures held in data stores. The technique was inspired by systems thinking and suited the third generation procedural programming languages like C and Pascal that were prevalent at the time.
My only experience with formal structured analysis and design approaches was looking over the shoulder of colleagues at Instem. They were using the Coad/Yourden method to design the software for monitoring and supervisory control systems for processes at a UK nuclear power station.
With the growing recognition of the need for encapsulation and information hiding in software design and the related rise in popularity of object-oriented programming languages, structured analysis and design was largely replaced by object-oriented analysis and design during the 1990's.
Object-Oriented Analysis and Design
Achieving mainstream popularity in the 1990's, object-oriented analysis and design is all about identifying the types of objects that we need in our software. Objects can represent anything from business ideas like Sales and Payments to things like user interface windows, database tables, and network messages. Each object remembers bits of information about the item it represents and depending on its type has a specific set of operations that answer questions about and modify that data. Object-oriented software applications consist of sets of objects working together to provide the application's required functionality.
Therefore, object-oriented analysis and design is all about answering two questions:
- What types of object do we need to define?
- What are the most appropriate responsibilities for each of those types of object?
Objects hide the data and algorithms they use behind a well-defined interface. Objects ask questions of and requests actions to be performed by other objects. Generally this is done by invoking one of the operations defined in the object's interface.
This encapsulation is intended to serve two related purposes:
- Firstly it is intended to prevent detailed knowledge of the data structures within an object becoming scattered across a large software application or system and creating a lengthy, error-prone, updating job when the data structures need to change for some reason.
- Secondly, when done properly, encapsulation guards against the data structures within an object becoming inconsistent or invalid through erroneous or even malicious manipulation. For example, if an object represents some interval of time, the operations in its interface should prevent the start time of the interval being set to after the end time of the interval.
Each object either represents a distinct item in the problem domain (field of endeavor) like an order in an order processing system, for example, or some software item such as a user interface control, network message or database table. For this reason each object is said to have its own identity.
Each different type of object is defined by a class that specifies the interface and optionally some of the implementation behind that interface. Classes can be defined as extended or specialized versions of another class. When this happens objects of the extended class are said to inherit the interface and implementation of the parent or super
class (class inheritance). Also, when done properly, objects of the extended classes can be used wherever the objects of the more general class are expected (polymorphism).
Service-Oriented Approaches
So far this century, attention has largely been focused on integrating larger chunks of functionality sitting on different systems, possibly in different organizations. During the last few years, the popular buzzwords have been component-based development (CBD), service-oriented architecture (SOA), and web services.
Analysis and design of a service-oriented architecture is all about identifying what services can be provided by various applications, systems, or components including specifying the data that needs to be sent to and received back from those services. Once established, these services are strung together to form larger business solutions or automate more complex business processes.
Therefore, analysis and design of a service-oriented architecture is all about answering the two questions:
- What services do we need to provide?
- What types of data do we need to send to and receive back from those services?
In both cases object modelling can help answer those questions.
Object Modelling
Object modelling is an object-oriented analysis and design technique. Object modeling uses a graphical notation or language like the Unified Modeling Language (UML) to build a set of related diagrams. These show classes of object, their responsibilities, and how they relate to each other. They also show how the objects defined by these classes interact with each other to perform the required functions of the software.
More about object modelling...
Like any modelling activity, we build object models primarily for two reasons, firstly to gain understanding and secondly to communicate. Most software systems are too complex to easily understand in their entirety at any significant level of detail. Building an object model enables us to explore and understand the overall structure and function of a system from different perspectives and at a higher levels of abstraction where we can temporarily ignore the details of specific programming languages and software operating environments.
Pictures nearly always help communicate complex constructs and object modelling is no exception. When used well, object model diagrams can help the different disciplines involved in a software development project to communicate much better with each other. A good object model clarifies the structure behind functional requirements, establishes a shared vocabulary for the project, and provides a shared conceptual framework within which to implement the required functionality of the software.
More model and domain-centric techniques are becoming fashionable again. Already we have a growing set of new model-centric acronyms with which to confuse people including: Model Driven Architecture (MDA), Model Driven Development (MDD), Model Driven Engineering (MDE), Agile Modeling (AM) and Domain Driven Design(DDD). Therefore, object modelling techniques look like they will continue to be useful for at least the next few years.
More about object modelling...
Unified Modeling Language
One of the early problems with object modelling was choosing which of the numerous different graphical notations available to use. This problem was solved by the introduction of the Unified Modeling Language (UML). Grady Booch, Ivar Jacobson, James Raumbaugh at what was then Rational Corp, created UML by merging their three notations and ideas from other notations into a single standard. The Unified Modeling Language (UML) is now managed by the Object Management Group (OMG) and has become the de facto standard notation for object-oriented and component-based software analysis and design.
Although far from perfect, UML does provide software architects, analysts, designers and developers with a single graphical language immediately avoiding the tedium, miscommunication, misunderstanding, and errors that arise in translating from one notation to another.
My notes and articles about UML include a short introduction to UML aimed at Java programmers published on the InformIT.com web site, and an article considering the future of UML for the old Coad Letter newsletter from my perspective as an object modeller and developer. This article was also translated into German and appeared in the German magazine, Java Spektrum.
Articles and notes about UML...
Modelling in Color
Design patterns and strategies promote better design by recording good designs for common problems.
The 'modeling in color' strategies, and patterns were developed by Peter Coad and grew out of work he and his colleagues did throughout the 1990's. The modelling in colour technique has influenced my thinking about software analysis and design more than anything else in the last few years and continues to be useful in much of the service-oriented and component-based work I do now.
Modelling in colour is an object modeling technique that recognises four general kinds of significant class in problem domain object models. These general kinds of classes are called class archetypes. For each of these class archetypes, the technique identifies the typical responsibilities of that kind of class, and their typical patterns of collaboration and interaction with classes of the same and other class archetypes.
More about 'modeling in color'...
Proven in practice, time and time again, the modelling in colour technique offers a simple but powerful, pattern-based approach to building more robust, more extensible, problem domain models quickly. It can also act as the basis for reviewing and improving existing problem domain models. The name of the technique comes from the simple colour coding used for the class archetypes in diagrams.
Most of my software analysis and design articles and notes relate to lessons learnt applying and teaching others the modelling in colour ideas. I was a lead designer/developer on the first project to use the modelling in colour technique, and I taught and consulted on it during my time as a senior mentor at TogetherSoft. Whenever I get the chance, I continue to do so as part of my role as a principle consultant at Borland. UML is the usual notation used when 'modeling in color'.