Skip to content

Instantly share code, notes, and snippets.

@weitsang
Last active August 29, 2015 14:05

Revisions

  1. weitsang revised this gist Aug 27, 2014. 1 changed file with 1 addition and 1 deletion.
    2 changes: 1 addition & 1 deletion nus-cs3281-2014-l2.md
    Original file line number Diff line number Diff line change
    @@ -61,4 +61,4 @@ This [clean architecture is explained here](http://blog.8thlight.com/uncle-bob/2

    ### Design Documentation
    * 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 options according to the criteria.
    * Document your detailed design decision clearly. Starts with the QOC, then argue the pros and cons of each option according to the criteria.
  2. weitsang revised this gist Aug 27, 2014. 1 changed file with 11 additions and 3 deletions.
    14 changes: 11 additions & 3 deletions nus-cs3281-2014-l2.md
    Original file line number Diff line number Diff line change
    @@ -4,7 +4,8 @@ Semester 1, AY 2014/15

    20 August 2014

    You roughly know what to implement, now, how are you going to implement it?
    * 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?)

    ### Different Views of Architecture
    * Logical View (class diagrams, layers, components)
    @@ -51,6 +52,13 @@ This [clean architecture is explained here](http://blog.8thlight.com/uncle-bob/2
    * 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?"
    * **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 ..
    * **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:
    * [Autocompaste](https://wiki.nus.edu.sg/display/autocompaste/Design+Considerations)
    * [CIO](https://wiki.nus.edu.sg/pages/viewpage.action?pageId=103933178)

    ### Design Documentation
    * 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 options according to the criteria.
  3. weitsang revised this gist Aug 27, 2014. 1 changed file with 10 additions and 1 deletion.
    11 changes: 10 additions & 1 deletion nus-cs3281-2014-l2.md
    Original file line number Diff line number Diff line change
    @@ -44,4 +44,13 @@ This [clean architecture is explained here](http://blog.8thlight.com/uncle-bob/2
    * 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
    * Sketches on whiteboard is enough


    ### Design Desisions
    * 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?"
    * **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 ..
  4. weitsang revised this gist Aug 19, 2014. 1 changed file with 7 additions and 0 deletions.
    7 changes: 7 additions & 0 deletions nus-cs3281-2014-l2.md
    Original file line number Diff line number Diff line change
    @@ -38,3 +38,10 @@ Much has been written about the MVCs. To learn more, you can read about
    * External Tools: frameworks, web, database, cloud services, etc.

    This [clean architecture is explained here](http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html) 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
  5. weitsang revised this gist Aug 19, 2014. 1 changed file with 5 additions and 5 deletions.
    10 changes: 5 additions & 5 deletions nus-cs3281-2014-l2.md
    Original file line number Diff line number Diff line change
    @@ -13,7 +13,7 @@ You roughly know what to implement, now, how are you going to implement it?
    * 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")[http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf] by Philip Kruchten, IEEE Software 12 (6) November 1995, pp. 42-50.
    For more details, read about the ["4+1 View Model of Software Architecture"](http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf) 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
    @@ -27,14 +27,14 @@ For more details, read about the ("4+1 View Model of Software Architecture")[htt
    * 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)[http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html]
    * (an analysis of MVC by the GoF in their book on Design Pattern)[http://blog.iandavis.com/2008/12/09/what-are-the-benefits-of-mvc/]
    * (a detail explanation of MVC by Martin Fowler)[http://martinfowler.com/eaaDev/uiArchs.html]
    * [the original proposal for MVC in the context of Smalltalk](http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html)
    * [an analysis of MVC by the GoF in their book on Design Pattern](http://blog.iandavis.com/2008/12/09/what-are-the-benefits-of-mvc/)
    * [a detail explanation of MVC by Martin Fowler](http://martinfowler.com/eaaDev/uiArchs.html)

    ### 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)[http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html] as well as in several videos by Uncle Bob, which can be easily found online.
    This [clean architecture is explained here](http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html) as well as in several videos by Uncle Bob, which can be easily found online.
  6. weitsang created this gist Aug 19, 2014.
    40 changes: 40 additions & 0 deletions nus-cs3281-2014-l2.md
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,40 @@
    # 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")[http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf] 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)[http://st-www.cs.illinois.edu/users/smarch/st-docs/mvc.html]
    * (an analysis of MVC by the GoF in their book on Design Pattern)[http://blog.iandavis.com/2008/12/09/what-are-the-benefits-of-mvc/]
    * (a detail explanation of MVC by Martin Fowler)[http://martinfowler.com/eaaDev/uiArchs.html]

    ### 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)[http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html] as well as in several videos by Uncle Bob, which can be easily found online.