SE2_01

Card Set Information

Author:
Anonymous
ID:
160927
Filename:
SE2_01
Updated:
2012-07-04 07:32:51
Tags:
Architecural Principles
Folders:

Description:
Architecural Principles
Show Answers:

Home > Flashcards > Print Preview

The flashcards below were created by user Anonymous on FreezingBlue Flashcards. What would you like to do?


  1. Value System:
    1.
    2.
    3.
    4.

    Problem: 
    Solution:
    • Value System:
    • 1. Evolvability
    • 2. Correctness
    • 3. Production- efficiency
    • 4. Reflection

    • Problem: too abstract
    • Solution: Architectural Principles / Mnemonics
  2. Evolvability
    1.
    2.
    3.
    • 1. Evolvability means, that software must have an internal structure that favors changes of that software
    • 2. The simpler the software can be adapted to changed conditions, the higher its evolvability  
    • 3. implementation of a feature costs a fixed amount that is independent of when the feature is implemented
  3. Correctness
    1.
    2.
    • 1. Correctness must be considered during the development
    • 2. Need clear defined requirements
  4. (High) Production-efficiency
    1.
    2.
    3.
    • 1. high SW price with inefficient production
    • 2. means that SW can be developed further for years
    • 3. moderate ratio to other values e.g. the correctness
  5. Reflection
    1.
    2.
    3.
    • 1. Without reflection no further development is possible
    • 2. always consider new findings
    • 3. is needed on all levels
    •    - Starting from pair programming or code reviews
    •    - Daily reflection of the team
    •    - Reflection after each iteration
    •    - Up to the reflection of the entire industry.
  6. APs:
    1.
    2.
    3. 
    ...
    12.
    • 1. Don't repeat yourself (DRY) / Duplication is Evil (DIE)
    • 2. You ain't gonna need it (YAGNI)
    • 3. Keep it Short and Simple (KISS)
    • 4. Principle Of Least Astonishment
    • 5. The Pareto Principle (a.k.a 80/20 rule)
    • 6. Convention over configuration
    • 7. Cyclic dependencies (they are evil!)
    • 8. Favour Composition over Inheritance (FCOI)
    • 9. Boy Scout Rule
    • 10. Dependency Injection
    • 11. Global Util Helper – a bad idea….
    • 12. Single Responsibility Principle (SRP)
    • 13. Open Closed Principle (OCP) 
  7. DRY / DIE:
    1. General:
    2. Applying DRY: 
    3. Example:
    4. Tools:
    • 1. General:
    •    - reduce repetition of information of all kinds

    • 2. Applying DRY: 
    •    - Use code generators and automatic build systems, NO COPY & PASTE
    •    - Single Source of Truth:
    •    >>> modifications does not affect logically unrelated  
    •           elements and related elements will change predictably,
    •           uniformly and are thus kept in sync
    •    - Implement and maintain functionality only once 

    • 3. Example:
    •    - model-driven architectures, in which software artifacts
    •      are derived from a central object model expressed in a
    •      form such as UML (by using data transformation and
    •      code generators)
    •    - makes large SWSystems easier to maintain
    •    - XDoclet and XSLT are ex. of DRY coding techniques
    •    >>>EJB2 needs duplicate information in Java Code and
    •          configuration files
    •    >>>RoR, EJB3 are better, reduce duplicate information

    • 4. Tools: 
    • PMD
  8. YAGNI:
    1. Funcionality
    • - costs time
    • - is not tested enough
    • - limits the possibilities in the future
    • - makes the code complicated
    • - falls into oblivion
    • - can lead to additional functionality that is implemented but not needed
    • - will probably never be used.
  9. KISS
    1. General 
    2. Benefit
    • 1. General:
    • - you can add s.th. but you cannot remove s.th.

    • 2. Benefit 
    • - Ability to solve more problems, faster
    • - Ability to produce code to solve complex problems in fewer lines of code
    • - Ability to produce higher quality code
    • - Ability to build larger systems, easier to maintain
    • - The code base will be more flexible, easier to extend, modify or refactor when new requirements arrive
    • - Ability to work in large development groups and large projects since all the code is stupid simple.
  10. Principle of least astonishment/surprise (POLA/PLA) (Erstaunen,Verwunderung, Überraschung)
    • - appies to user interface design, software design, and ergonomics
    • - the design match the user's experience and expecations
    • - Eg. the methode "multiply" should do a multiplication not any other calculation
  11. 80/20 rule - Pareto Principle
    states
    - that 80% of the requirements can be realized using 20% of the effort and the remaining 20% of the requirements are 80% of the effort
  12. Convention over configuration
    • CoC is a software design paradigm which seeks to decrease the number of decisions that developers need to make, gaining simplicity, but not necessarily losing flexibility
    • Ex. Class "SALE" in the model corresponds to DB table "sales"

    It supports KISS and DRY
  13. Cyclic dependencies are evil
    1.) Problems 
    2.) Causes and solutions 
    3.)  Slogan
    • 1.) Problems
    •    - unwanted effects in SW programs by coupling mutually
    •      dependent modules -> no re-use of a single module
    •    -  small local change in one module can cause /unwanted
    •       global effects / a domino effect  
    •    -  infinite recursion or other unexpected failures
    •    - difficult to test 

    • 2.) Causes and solutions 
    •    - SonarJ analyze SW and find unwanted CDs
    •    - Using design patterns 

    3.)Modifications in an upper-level layer should never lead to errors in deeper layers.
  14. Favour Composition over Inheritance
    • - use strategy pattern instead of Template method
    •     (example Actor-Role-Pattern)
    •    - Composition is dynamic, inheritance static and breaks    
    •       encapsulation
    •    Composition
    •    "+" flexible, because behavior can be swapped at runtime
    •    "-"  source code is harder to understand
  15. Boy Scout Rule
    • - Leave every code you read in better shape than you found it
    • -  "7 lines per method", and "Single Responsibility of a method" rules

    • (
    • - Adding to a Long Function
    • - Adding to a complex conditional 
    • - Copy/Paste/Tweak Temptation
    • - Cryptic Local Variable Name
    • - Deep Nesting
    • - Broken Glass and Beer Cans in the Fire Pit
    • )
  16. Dependency Injection /Hollywood principle /Inversion of control
    • - Target: Loose coupling
    • - Configuration and wiring with other components is taken out of the component.
    • - Examples:
    •    - ORM 
    •    - Spring
    •    - OSGi
    •    - CDI
  17. Global Util Helper / Single Responsibility Principle (SRP)
    • GUH is a bad idea
    • better usr SRP  
    • - There should never be more than one reason for a class to change
  18. Open Closed Principle (OCP)
    • Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification
    • - design module that never change
    • - new requirements leads to extend code, not to change (working) code 

What would you like to do?

Home > Flashcards > Print Preview