This summary contains everything you need to know to excel in the endterm exam of Systeemontwikkelingsmethoden (System design methods) (INFOB2SOM). The summary is about different design patterns, as well as good object-oriented design and DevOps. The summary is based on my lecture notes, and the le...
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!
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.
Les avantages d'acheter des résumés chez Stuvia:
Qualité garantie par les avis des clients
Les clients de Stuvia ont évalués plus de 700 000 résumés. C'est comme ça que vous savez que vous achetez les meilleurs documents.
L’achat facile et rapide
Vous pouvez payer rapidement avec iDeal, carte de crédit ou Stuvia-crédit pour les résumés. Il n'y a pas d'adhésion nécessaire.
Focus sur l’essentiel
Vos camarades écrivent eux-mêmes les notes d’étude, c’est pourquoi les documents sont toujours fiables et à jour. Cela garantit que vous arrivez rapidement au coeur du matériel.
Foire aux questions
Qu'est-ce que j'obtiens en achetant ce document ?
Vous obtenez un PDF, disponible immédiatement après votre achat. Le document acheté est accessible à tout moment, n'importe où et indéfiniment via votre profil.
Garantie de remboursement : comment ça marche ?
Notre garantie de satisfaction garantit que vous trouverez toujours un document d'étude qui vous convient. Vous remplissez un formulaire et notre équipe du service client s'occupe du reste.
Auprès de qui est-ce que j'achète ce résumé ?
Stuvia est une place de marché. Alors, vous n'achetez donc pas ce document chez nous, mais auprès du vendeur danielgeelhoed. Stuvia facilite les paiements au vendeur.
Est-ce que j'aurai un abonnement?
Non, vous n'achetez ce résumé que pour €5,99. Vous n'êtes lié à rien après votre achat.
