Software Engineering - Design

Module aims

Software - this course is about the development of software systems. To a large extent it is about programming, but rather than considering, for example, the implementation details of particular algorithms, we look at combining components into larger systems.

Design - software development is a creative activity. There may be many different ways to solve the same problem. Different designs may be thought to be more effective, or more elegant, than others, but to be useful they must all perform their basic function satisfactorily.

Engineering - from an engineering standpoint, we are concerned with the assessment and balancing of forces that may affect our design decisions in solving a particular problem. There are likely many possible designs that solve a particular problem, how can we choose between them?


Communication of Design: students will learn mechanisms for communicating and discussing their design ideas, both through graphical notation and diagrams, and through a common vocabulary of well known design patterns and architectural styles.

Design Principles: we aim to instill a set of principles and guidelines to be followed during the design of a system, with the aim of increasing flexibility, maintainability and re-use in that system. Design Patterns: we aim to familiarise students with a collection of common solutions to common design problems. We introduce the notion of a Design Pattern and identify a set of key patterns and their applications.

Architectural Styles: we examine some common architectural styles for classes of application such as: interactive GUI applications, web applications, and data processing pipelines.

Concurrency and Distribution: we look at various models for performing work concurrently. We examine distributed systems of co-operating components and how we can implement communication between them.

Throughout the course we aim to examine design choices based on practical applications and examples.

Learning outcomes

Learning Outcomes - Knowledge and Understanding

• To identify various design patterns, describe the problem they solve, and any trade-offs involved.
• To consider design choices in light of the economic cost of future change.
• To describe software designs through appropriate notation
• To be able to recall a catalogue of commonly used design patterns and architectural styles
• To understand various qualities of design, and how taking different design decisions may affect these qualities.
• To understand the commercial and economic implications of the Design Stamina Hypothesis.
• To describe common design structures for a desktop application, web application, or data processing application
To be able to demonstrate the following practical skills
• To be able to constuct automated tests for their code through test-driven development
• To be able to perform refactoring operations on a codebase using appropriate tools
• To be able to consider and critique the qualities of the design of a given codebase 
• To be able to make informed engineering decisions to minimise the cost of change  

Module syllabus

• Test-Driven Development
• Refactoring
• Mock Objects
• Encapsulation and the Law of Demeter
• Design Patterns
• Reuse and Extensibility
• Code Quality Metrics
• Design Patterns
• Iterators and Higher-Order Functions
• Streams and Map Reduction
• Concurrency
• Publish-Subscribe Architectures
• Patterns for Object Creation
• Dependency Inversion
• Interactive (GUI) applications
• Web Applications
• Patterns for System Integration
• Patterns for Distribution 
• REST and Web Services


 Programming I and Programming II (compulsory first year courses).

Teaching methods

2 hours of lectures per week.

1 hour of tutorial in the computer lab per week.

Weekly assessed programming exercises, targeted on a particular element of design.

Peer instruction through pair-programming.

Weekly feedback on assessed exercises.


Weekly exercises combine to make up the coursework component of the course.

Exam in the summer term.

Module leaders

Dr Robert Chatley