This is part two in a series called Introduction to UML. In this section we will look at some basics of Analysis and Design and methodologies. Part one looked at a history of UML and some of the drivers behind the need for a standard modeling language.
Modeling is the design of systems and specifically in our area of interest software applications. The model can be compared to a plan when building a ship or a floor plan when building a house. They are used to assure themselves that business functionality is complete and correct, needs are met and the design supports the system requirements (i.e. scalability).
We all have read the statistics on success of software projects and the probability of success. Therefore, modeling should be a key player in increasing the odds for a successful completion of a project.
UML is used to specify, visualize and document models of software systems. It is not a methodology, it is the notation or common language used to specify a system. How you use it is not specified, or specifically the methodology. Go to
for a very (almost exhausting) description of methodologies.
Analysis and Design
At this point it may be beneficial to make the distinction between analysis and design. Analysis is the specification of a system’s requirements as an object model. Basically analysis determines the technical and business drivers, specifications and boundaries to gain a thorough understanding of a system. This is highly important as the main determiner of a successful software development project is user satisfaction (or the covering user requirements). If you fail to analyze a system or existing process properly it will be very difficult to build software that users are satisfied to use.
Design on the other hand is concerned with the development of an OO model of a system that will satisfy the requirements. Two main goals beyond the obvious implementation of the requirements is maintainability and reusability. Maintainability is accomplished through simplified designs due to a deeper understanding of the problem domain. Reusability is attainable through the same understanding and mapping to the features of a particular object-oriented programming language.
Software Development Process
Earlier it was mentioned we would not cover the process for OOD&A or methodology. There are hundreds of books and many well-known methodologies to choose from. However, irregardless of the process, the following steps must be performed.
- Requirements Capture – this is where the requirements of the system are understood. It is important to be able to do this in a language the users can understand or as it is called in the “problem domain”.
- Analysis – this is where the requirements are taken and one starts to mold into a possible solution or in the “solution domain”. An abstract manner is used, in other words it is kept at a high level.
- Design – the specification from the analysis phase is taken and a concrete solution is defined. This is done in full detail.
- Build Phase – the design is used as a base to actually program in the chosen programming language. This is just not programming, it is also testing to ensure requirements are met, testing that it solves the customer problem and documenting the system.
There are two basic ways to develop software, one traditional and one modern (I believe all software development methodologies are derived as a basis from these two foundations).
This is where each phase of the software development process is completed before the next phase is started. One downfall of this method is that it is often impossible to understand the requirements completely at the start of the project. Second, code does not become available until late in the project.
As you see, like in a series of waterfalls, once you move down to the next level it is extremely hard to get back to an earlier step.
Another negative point is that each consecutive step in the process requires more effort and this is increased if a phase needs to be revisited. This is depicted below. A basic premise is modifications in a software development project are cheaper the earlier they can be made.
The iterative method has as its main idea getting some code produced as soon as possible and then highlight any problems early in the development.
One way to visualize this is by looking at the development process as a series of small waterfalls. The analysis, design and build phases are first performed for the most important requirements and then after user feedback they are repeated and more of the requirements are covered. This continues until all requirements have been satisfied.
One advantage is the work is done in manageable pieces of work and project managers can retain an overview of progress.
Agile methods, such as Extreme Programming, Crystal or Scrum, have gained a lot of attention lately. This again heavily involves users in the entire development process and has some unique characteristics such as turning the requirements into test cases, pair programming among others.
Agile methods usually follow these general principles.
· Individual and interactions OVER processes and tools
· Working software OVER comprehensive upfront documentation
· Customer collaboration OVER contract negotiation
· Responding to change OVER following a plan
For more information on Extreme Programming go to