SE2_01

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

• Problem: too abstract
• Solution: Architectural Principles / Mnemonics

• 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

• 1. Correctness must be considered during the development
• 2. Need clear defined requirements

• 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

• 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.

• 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) 

• 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

• - 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.

• 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.

• - 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

- 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

• 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

• 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.

• - 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

• - 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
• )

• - Target: Loose coupling
• - Configuration and wiring with other components is taken out of the component.
• - Examples:
•    - ORM 
•    - Spring
•    - OSGi
•    - CDI

• GUH is a bad idea
• better usr SRP  
• - There should never be more than one reason for a class to change

• 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