Software Engineering - Software Design Intro

Intro to software design

Embury's law

Remember this?

The software has bugs in it, we just don't know what they are yet.

This applies to all non trivial software systems. It's fine to assume that some parts of software might be bug free though, for example something that has been translated from another language, as we can check it fully for errors/bugs.

You could say that reducing Embury's law is the primary goal of software engineering (although personally I think the primary goal is, you know, making software)

Bug types

• Errors to make a program freeze / crash


• Not providing functionality the user needs


• Not following the non-functional requirements


• Bad UI design for the context


• Bugs in the documentation / training materials


• Bugs in the requirements

Bugs can be subjective. As requirements are given in a natural language and not in a specific notation, they can be interpreted differently.

Things that can reduce the aforementioned bugs

• Testing. Lots of testing.


• Reviewing code


• Refactoring (remember that? Good)


• Frequent contact with users and the stakeholders


• A risk driven development


• Experience (which of course you won't have as it's your first SW engineering project probably)

The importance of good design

A good design is simple, easy to test, is easy for other developers to understand, and can adapt well when requirements change.

A design that seems good can change into a big ball of mud™

Refactoring

This is when you change the code without altering functionality, so for example you might split a class into two or replace an algorithm with a more efficient one.

You should refactor whenever and wherever possible, although it's hard to because other things are higher priority, but if things aren't working then do it asap.

Good design

• OO design is good


• Good to follow established patterns as you know they work


• You can find a lot of good ones in the General Responsibility Assignment Software Patterns (GRASP). They give guidance on which responsibilities go in which classes


• 'Gang of Four' design patterns are nice too

Note: The notes call them GRASP Patterns but that would mean the end stands for 'Patterns Patterns' and that's a bit stupid so here they are just GRASP

GRASP

High cohesion / low coupling

• High cohesion is where you make sure that a class represents a single well defined thing, like a bus or driver but not busanddriver


• Low coupling is making sure that your classes interact with as few classes as possible

Model-view separation

• Make sure that the internal data structures (the MODEL) is separate from the UI code that displays them (the VIEW)


• This means that if one changes the other isn't affected too much. This is called GRASP protected variations


• Here's an example: You might have Timetable as a class and DisplayTimetable as a class


• You might use a controller to get MV separation. This is called a Model View Controller (MVC)

Polymorphism

• You can reduce coupling by utilising inheritance and general classes / methods


• You could make operations 'live' in the superclass

Types of polymorphism in Java:

• Inheritance

public class Pizza extends DeliciousThings

• Genericity

list<Pizza> food

• Overloading

public void squeak()

public void squeak(int decibels)

Polymorphism generally means inheritance.

You should only use inheritance if <subclass> is a kind of <superclass>