SOM Samenvatting
Begrippenlijst
Abstract class: class that cannot be instantiated. In UML: class name written in italics.
Adapter: Design pattern adapting the interface of a class so that it is compatible with client.
Aggregation relationship: Specifies a subjective part/whole relationship, without any
existential dependency
Association relationship: Specifies that 2 entities are associated with / know each other
Bridge: Design pattern decoupling an abstraction from its implementation
Composition relationship: Specifies an existential dependency.
Continuous development: Devops practice: new commits immediately go into production.
Continuous integration: Devops practice, integrate new code frequently, instead of using
branches.
Dependency inversion: Depend on abstractions rather than concrete implementations
Dependency relationship: Specifies a weak use relationship.
Design patterns: Reusable solutions in developing OO-systems
DevOps: principles of bringing development & operations together.
Façade: Design pattern providing a unified interface to a set of interfaces in a system
Factory: Design pattern, separating object creation (in factory) from object use
Inheritance relationship: Specifies a subclass/superclass relationship in UML class diagram
Liskov substitution principle: subclass should support all superclass behavior
Model-View-Controller: Design pattern, more architectural. Model = Database / storage,
View = representation, Controller = Intelligence
Monorepo: Version control: 1 big repository with different systems / applications as
directories
Multirepo: Version control, n repositories of different systems / applications
Observer: Design pattern, when certain events happen, another object is informed.
Open-closed principle: System should be open to extension, closed to modification
Software architecture: High-level software system structure
Strategy: Design pattern using inheritance to encapsulate varying strategy.
Trunk-based development: Devops practice, commit directly to master instead of branches
UML: Unified Modeling Language, used to analyze and design software
UML Activity Diagram: Diagram describing business processes
UML Class diagrams: Diagram representing classes & methods in a system at varying detail
levels.
UML Sequence Diagram: Diagram portraying dynamic aspects (as opposed to ‘static’ Class
diagrams.
Visibility: Determines which (other) classes can see a method or attribute.
HC11: UML
UML: transition from requirements & use cases: analyze & design software
Analysis: create abstract model of domain to oversee big systems.
● UML Activity diagrams: describe business processes, to validate agreement with
client on how it works.
Informal notation: not mathematically based.
● UML Class diagrams: Represents classes & methods in a system at varying detail
levels.
, Visibility: Which other classes can see this method or attribute?
+ : public. Every other class can access it.
- : private. Only same class can access it.
# : protected. Only visible for subclasses.
Abstract class: class name in <<italics>> (cannot be instantiated)
Relationship types:
● Inheritance: B is a subclass of A
Classes should only have 1 superclass!
● Aggregation: Subjective part/whole relationship (no
extra semantic meaning. B is part of A, but does not
depend on it / also exists outside of it.)
Association: associate type B is used in A.
● Composition: existential dependency. B is a
composite part of A.
● Dependency: weakest relationship,A uses
B / has is as a parameter, etc.
Aggregation and Composition are specific cases of
Association!
● UML sequence diagram: Captures dynamic /
behavioral aspects.
- Column: (main, :Data): object
- Arrows: (getData): object calls & returns
- White vertical rectangle: object lifetime
- Time: time flowing downwards
Analysis: make domain models / textual analysis
→ Validate: Is it correct, complete, consistent, unambiguous,
realistic?
HC12: Design patterns
Design patterns: reusable solutions, common terminology
→ Documents solutions, abstract from irrelevant details.
They all have tradeoffs!
Why? easy modification & maintainability, practice good OO-design.
● Façade: provide a unified interface to a set of interfaces in a system.
→ You don’t want to access internal organization → hide complexity with a facade.
When use it? If you only need subset of complex system / only particular interaction.
(+) Simplify system use (-) some functionality may not be accessible
Facade encapsulates original system, but can also add extra functionality.
Begrippenlijst
Abstract class: class that cannot be instantiated. In UML: class name written in italics.
Adapter: Design pattern adapting the interface of a class so that it is compatible with client.
Aggregation relationship: Specifies a subjective part/whole relationship, without any
existential dependency
Association relationship: Specifies that 2 entities are associated with / know each other
Bridge: Design pattern decoupling an abstraction from its implementation
Composition relationship: Specifies an existential dependency.
Continuous development: Devops practice: new commits immediately go into production.
Continuous integration: Devops practice, integrate new code frequently, instead of using
branches.
Dependency inversion: Depend on abstractions rather than concrete implementations
Dependency relationship: Specifies a weak use relationship.
Design patterns: Reusable solutions in developing OO-systems
DevOps: principles of bringing development & operations together.
Façade: Design pattern providing a unified interface to a set of interfaces in a system
Factory: Design pattern, separating object creation (in factory) from object use
Inheritance relationship: Specifies a subclass/superclass relationship in UML class diagram
Liskov substitution principle: subclass should support all superclass behavior
Model-View-Controller: Design pattern, more architectural. Model = Database / storage,
View = representation, Controller = Intelligence
Monorepo: Version control: 1 big repository with different systems / applications as
directories
Multirepo: Version control, n repositories of different systems / applications
Observer: Design pattern, when certain events happen, another object is informed.
Open-closed principle: System should be open to extension, closed to modification
Software architecture: High-level software system structure
Strategy: Design pattern using inheritance to encapsulate varying strategy.
Trunk-based development: Devops practice, commit directly to master instead of branches
UML: Unified Modeling Language, used to analyze and design software
UML Activity Diagram: Diagram describing business processes
UML Class diagrams: Diagram representing classes & methods in a system at varying detail
levels.
UML Sequence Diagram: Diagram portraying dynamic aspects (as opposed to ‘static’ Class
diagrams.
Visibility: Determines which (other) classes can see a method or attribute.
HC11: UML
UML: transition from requirements & use cases: analyze & design software
Analysis: create abstract model of domain to oversee big systems.
● UML Activity diagrams: describe business processes, to validate agreement with
client on how it works.
Informal notation: not mathematically based.
● UML Class diagrams: Represents classes & methods in a system at varying detail
levels.
, Visibility: Which other classes can see this method or attribute?
+ : public. Every other class can access it.
- : private. Only same class can access it.
# : protected. Only visible for subclasses.
Abstract class: class name in <<italics>> (cannot be instantiated)
Relationship types:
● Inheritance: B is a subclass of A
Classes should only have 1 superclass!
● Aggregation: Subjective part/whole relationship (no
extra semantic meaning. B is part of A, but does not
depend on it / also exists outside of it.)
Association: associate type B is used in A.
● Composition: existential dependency. B is a
composite part of A.
● Dependency: weakest relationship,A uses
B / has is as a parameter, etc.
Aggregation and Composition are specific cases of
Association!
● UML sequence diagram: Captures dynamic /
behavioral aspects.
- Column: (main, :Data): object
- Arrows: (getData): object calls & returns
- White vertical rectangle: object lifetime
- Time: time flowing downwards
Analysis: make domain models / textual analysis
→ Validate: Is it correct, complete, consistent, unambiguous,
realistic?
HC12: Design patterns
Design patterns: reusable solutions, common terminology
→ Documents solutions, abstract from irrelevant details.
They all have tradeoffs!
Why? easy modification & maintainability, practice good OO-design.
● Façade: provide a unified interface to a set of interfaces in a system.
→ You don’t want to access internal organization → hide complexity with a facade.
When use it? If you only need subset of complex system / only particular interaction.
(+) Simplify system use (-) some functionality may not be accessible
Facade encapsulates original system, but can also add extra functionality.
