Semester 1, AY 2014/15
20 August 2014
- You roughly know what to implement, now, how are you going to implement it?
- Two steps: (i) high-level software architecture (e.g., what are the components in the systems?), (ii) detailed design of implementation/solution (e.g., what language/algorithm/software library/database/database schema/etc to use?)
- 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 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?
- 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
- 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.
- 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
- A clean software architecture allows you to defer your design decisions as long as possible.
- YAGNI ("You ain't gonna need it") principle: don't commit to a solution until you need it.
- But when you need to make a decision on a solution, consider the "QOC":
- Q: what is the question? E.g., "how do I perform OCR on the input image?" "what algorithm should I use for image matching?"
- O: what are the options available? E.g., (i) write my own OCR engine; (ii) use Tesseract, an open source library; (iii) use Aspire, a proprietery software, (iv)...
- C: what are the criteria? E.g., (i) fast and small enough to run within the time limit on iPhone 5, (ii) accurate enuogh, (iii) cheap, (iv) able to get it done quickly, (v) availability of technical support, etc ..
- Examples of software design decisions made in past projects:
- Keep track of you architectural design evolution. Please explain how it evolves over time (and why).
- Document your detailed design decision clearly. Starts with the QOC, then argue the pros and cons of each option according to the criteria.