Lecture Notes, CS3281 AY 1415, Lecture 2-3

nus-cs3281-2014-l2.md

On Software Architecture and Design

CS3281/CS3282 Lecture Notes

Semester 1, AY 2014/15

20 August 2014

You roughly know what to implement, now, how are you going to implement it?

Different Views of Architecture

• Logical View (class diagrams, layers, components)
• Physical View (Web server, proxy, mobile clients)
• Process View (threads, processes, synchronization, parallel execution)
• Development View (software packages, external libraries, tools, framework)
• Scenarios (walkthrough, interaction between components)

For more details, read about the "4+1 View Model of Software Architecture" by Philip Kruchten, IEEE Software 12 (6) November 1995, pp. 42-50.

Two Key Properties

• Two properties of good software architecture: low coupling and high cohesion
• Ask yourself
  • If I swap out one component for another (e.g., MySQL to MongoDB, Web to Native App) what do I need to change?
  • If I change the user requirements (e.g., to allow users to edit something they cannot edit before), what do I need to change?

Example 1: Model-View-Controller (MVC) for UI-centric applications

• Model: abstraction that the data in the system
• View: abstraction for how the users see the data; a view ``presents'' a model
• Controller: abstraction for how the users control the data; a control ``modifies'' a model

Much has been written about the MVCs. To learn more, you can read about

• the original proposal for MVC in the context of Smalltalk
• an analysis of MVC by the GoF in their book on Design Pattern
• a detail explanation of MVC by Martin Fowler

Example 2: ``The Clean Architecture''

• Entities: where the domain knowledge/logic/rules are implemented.
• Use Cases: where application-specific rules are implemented.
• Adapters: a layer of indirection between use cases and external tools to allow swapping of external tools and to translate between data formats used internally and externally.
• External Tools: frameworks, web, database, cloud services, etc.

This clean architecture is explained here as well as in several videos by Uncle Bob, which can be easily found online.

Agile Design

• Requirements may change -- so may design/architecture as a result.
• No need for complete, formal, architectural diagram up front.
• Design "just enough" to start coding
• Design with future changes in mind is therefore important.
• Sketches on whiteboard is enough