Software Systems Design

All about modelling and designing software systems professionally. By the end of the module I'll probably have made some design document with all sorts of UML diagrams on it.

Source:
B. Bruegge and A.H.Dutoit: Object-Oriented Software Engineering Using UML, Patterns and Java, 3rd edition

Introduction to Software Design

Contents

  1. Where do you begin?
  2. Why bother with design?
  3. Types of Software Design Models
  4. How do we create designs?
  5. Methodologies of Software Development
  6. Test-Driven Development (No Design)
  7. Object-Orientation

Where do you begin?

The first step to designing software is to gather the functional and non-functional requirements. Functional requirements are the more important of the two as they describe what the system is actually supposed to do.

Functional requirements are usually defined by the users/clients of the system whereas the non-functional requirements are defined by the developers and involve more technical considerations.

Non-functional requirements are about usability. They have no impact on the functionality of the system (idk why i wrote this down, it's literally in the name).
Things like speed, availability, capacity and reliability.

Why even bother with design?

It's good to have a plan of the system you want to build?
In more model-driven approaches, having models can let you auto generate boilerplate code. That can save a lot of time.

We use the Unified Modelling Language (UML) when making these diagrams and models. UML has a lot of features that let us communicate different aspects of a system's design.
So having these designs is useful when you want to show stakeholders with different backgrounds what the plan is.

Anyway, it makes sense for large projects with many subsystems, resources and their relationships to be properly planned and visualized, especially when a large team is involved.

Types of Software Design Models

Like I mentioned before, there's many ways to communicate the same system. Some ways more technical than others.

Showing how subsystems work together is high level (architectural perspective).

Showing how the individual classes and functional modules work together are lower level (detailed design perspective).

Eventually you get to the deployment perspective where the model shows the physical resources involved, like individual PCs, user's phones or servers and stuff like that. EVERY software system will involve physical resources in some way.

How do we create designs?

UML is popular object-orientated design modelling language. Here is the best UML reference guide I could find. It varies a bit but this is close to how they taught me in my undergrad course.

Besides UML we can also use flowcharts (operation-orientated) or data flow diagrams (data orientated).

Methodologies of Software Development

The actual development process is split up into stages. How these stages are carried out is determined by the methodology you choose. There are many, some newer and more popular than others.

Honestly, it's just astrology for developers. You could improvise your method (within reason) and still somehow convince a reader that you followed any one of these established ones. On the other hand it's useful to know them since they are referred to in practice (it's better to keep people on the same page and know what the workflow is like).

The Waterfall Model is one of the more established models, with each stage coming after the other. It's gone out of fashion in recent years but it's seen as the "safer" option by some.

Next is the V Model. Similar to waterfall but at each stage you think about how you will test and validate it. So there's more consideration on testing.

The Spiral Model is a cyclical process where you build improved prototypes each cycle. Good for when not all the requirements are able to be captured initially, sometimes the client doesn't know what they want.

The Unified Process (or Iterative Development) model is closer to the waterfall model in that it's driven by requirements but overlaps each stage slightly. However, testing is done throughout. Prototyping can also work in this model.

Test-Driven Development (No Design)

Why would you go through all this effort for a small project? If it has one or few subsystems and few requirements then it's best to go for test-driven development.
Just write unit tests first. The test initially fails, then you make it pass. Then you clean up the code and move on to writing the next test.
Eventually you'll have a large framework of testing. With each increment, you'll need to test everything.

Object Orientation

Software developers define objects from the problem domain.
Objects are given attributes (values) and methods (actions) and interact with each other.
Objects keep their contents encapsulated (restrict their access from other classes) in order to better control what connections can be made. In systems with many objects and subsystems, it would confusing if connections were allowed anywhere.

Back to Notes List