Software Engineering – Software Design Intro
November 23, 2009 Leave a comment
Intro to software design
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)
- 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™
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.
- 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
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
- 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)
- You can reduce coupling by utilising inheritance and general classes / methods
- You could make operations ‘live’ in the superclass
Types of polymorphism in Java:
public class Pizza extends DeliciousThings
public void squeak()
public void squeak(int decibels)
Polymorphism generally means inheritance.
You should only use inheritance if <subclass> is a kind of <superclass>