SOM samenvatting
Belangrijke begrippenlijst
Abstract class: class containing (at least 1) abstract method.
Abstract method: method that can only be realized by subclasses, but not by superclasses.
Acceptance test: test if the user accepts the final product
Agile development: development embracing change and flexibility, receiving continuous
feedback
Class: collection of objects with same characteristics (defining a concept)
Code review: Some reviews the code made by someone else
Code smells: code problems indicating bad design
Cohesion: how closely code inside method / object is related
Concern (in requirements): intention or objective of a stakeholder
Control coupling: method tells other method what to do
Controller: subsystem handling events
Coupling: how closely different elements / objects in a program are related
Creator: part of system which creates (new) instances
Daily scrum: 15 minute standup meeting, to plan activities for the coming day.
Data coupling: a method relies on other method output
Definition of Done (DoD): criteria for backlog item to be reached
Development team (scrum): team that delivers product, decides how sprint is performed
Domain-driven design: Designing using independent domain (e.g. User, Order in a webshop
system)
Domain model: representation of a business domain, general description but not technically
Elicitation: Talking to clients / users to gather requirements
Encapsulation: abstraction from internal state of an object
Epic: user story covering large functionality
F.I.R.S.T. principles: Fast, Independent, Repeatable, Self-checking, Timely (testing)
Fake object: behaves as the same as real object, but simplistic
Flaky test: non-repeatable test
Framework: libraries (code) + patterns (structure)
Functional requirement: specifies what the system should do (functionality)
Global data coupling: methods use same global variable
Horizontal scaling: adding more machines (in microservices)
Increment: backlog items that reached Definition of Done during sprint
Information expert: part of system which has certain information
Information hiding: private methods of object are hidden for other objects.
Inheritance: Subtypes inherit all variables & methods from supertype
Inheritance coupling: this is natural, but is worse when superclass depends on subclass
Instantiation: realization of an object (for example, a specific green bike is an instantiation of
the Bike class.)
Integration test: test if components work together
INVEST: assessment checklist for user stories: Independent, Negotiable, Valuable,
Estimable, Small, Testable
Iterative development: development in iterative mini-projects, each one leading to a working
(part of the) system.
, Library: a library of code you can import and use
License: reciprocal contract between user & provider of service / product
Linter: automatic tool for checking code quality
Microservices: architectural pattern with different parts, connected via API. One microservice
is a small autonomous service working together with others.
Mock: test checking if interaction / object calls are properly done.
Monolith: 1 big system with interwoven functionality (opposed to microservices)
Negotiation: prioritizing requirements together with customer (which one is most important?)
Non-functional requirement: specifies system qualities (performance, usability, etc)
Object: state (variables) + behavior (functions)
Pathological coupling: method relies on exact implementation of other method
Product backlog; list with possible options of changes to be made
Product owner (scrum): (ideally) represents customer, manages product backlog, addresses
conflicts
Refactoring: changing internal software structure to make it easier to understand & modify
Reference semantics: assignment of a variable to another variable references to the same
memory address.
Regression test: test that is regularly ran to find bugs after code update
Remote Procedure Calls (RPC): call used by microservices calling each other via an API.
Requirements engineering: process of defining, documenting & maintaining requirements
Responsibility: which class is responsible for this? (in object-oriented design)
Scenario: narrative description of people using the system
Scrum: An agile method of organizing software development process, by organizing into
sprints
Scrum master: scrum expert / coach, ensures team lives up to scrum principles. Is not a
boss, but a servant.
Sprint (scrum): Period from 2-4 weeks, during which a team works on a software part of a
fixed scope. Goal: working software!
Sprint backlog: list of items / tasks the team will be working on during sprint
Sprint planning: planning before sprint, leads to sprint backlog
Sprint retrospective: reflection with team how process went
Sprint review: review sprint with stakeholders, leading to feedback
Stakeholders: entity with interest in a project
Stub object: always returns same response
System test: development team tests entire system
Test-driven development: Write tests first, code afterwards to meet tests
Unified process: iterative software development process with 4 phases, tries to acknowledge
but also minimize change.
Unit test: test if a single code unit works
Use case: documents interaction yielding value
User story: description from user perspective who wants a certain feature
Validation: formal mathematical analysis of requirement
Verification: check if requirement is consistent / complete / accurate
Vertical scaling: adding more power to the current machines (in microservices)
Waterfall model: Linear (not iterative) model of software development process, does not
work in practice
Belangrijke begrippenlijst
Abstract class: class containing (at least 1) abstract method.
Abstract method: method that can only be realized by subclasses, but not by superclasses.
Acceptance test: test if the user accepts the final product
Agile development: development embracing change and flexibility, receiving continuous
feedback
Class: collection of objects with same characteristics (defining a concept)
Code review: Some reviews the code made by someone else
Code smells: code problems indicating bad design
Cohesion: how closely code inside method / object is related
Concern (in requirements): intention or objective of a stakeholder
Control coupling: method tells other method what to do
Controller: subsystem handling events
Coupling: how closely different elements / objects in a program are related
Creator: part of system which creates (new) instances
Daily scrum: 15 minute standup meeting, to plan activities for the coming day.
Data coupling: a method relies on other method output
Definition of Done (DoD): criteria for backlog item to be reached
Development team (scrum): team that delivers product, decides how sprint is performed
Domain-driven design: Designing using independent domain (e.g. User, Order in a webshop
system)
Domain model: representation of a business domain, general description but not technically
Elicitation: Talking to clients / users to gather requirements
Encapsulation: abstraction from internal state of an object
Epic: user story covering large functionality
F.I.R.S.T. principles: Fast, Independent, Repeatable, Self-checking, Timely (testing)
Fake object: behaves as the same as real object, but simplistic
Flaky test: non-repeatable test
Framework: libraries (code) + patterns (structure)
Functional requirement: specifies what the system should do (functionality)
Global data coupling: methods use same global variable
Horizontal scaling: adding more machines (in microservices)
Increment: backlog items that reached Definition of Done during sprint
Information expert: part of system which has certain information
Information hiding: private methods of object are hidden for other objects.
Inheritance: Subtypes inherit all variables & methods from supertype
Inheritance coupling: this is natural, but is worse when superclass depends on subclass
Instantiation: realization of an object (for example, a specific green bike is an instantiation of
the Bike class.)
Integration test: test if components work together
INVEST: assessment checklist for user stories: Independent, Negotiable, Valuable,
Estimable, Small, Testable
Iterative development: development in iterative mini-projects, each one leading to a working
(part of the) system.
, Library: a library of code you can import and use
License: reciprocal contract between user & provider of service / product
Linter: automatic tool for checking code quality
Microservices: architectural pattern with different parts, connected via API. One microservice
is a small autonomous service working together with others.
Mock: test checking if interaction / object calls are properly done.
Monolith: 1 big system with interwoven functionality (opposed to microservices)
Negotiation: prioritizing requirements together with customer (which one is most important?)
Non-functional requirement: specifies system qualities (performance, usability, etc)
Object: state (variables) + behavior (functions)
Pathological coupling: method relies on exact implementation of other method
Product backlog; list with possible options of changes to be made
Product owner (scrum): (ideally) represents customer, manages product backlog, addresses
conflicts
Refactoring: changing internal software structure to make it easier to understand & modify
Reference semantics: assignment of a variable to another variable references to the same
memory address.
Regression test: test that is regularly ran to find bugs after code update
Remote Procedure Calls (RPC): call used by microservices calling each other via an API.
Requirements engineering: process of defining, documenting & maintaining requirements
Responsibility: which class is responsible for this? (in object-oriented design)
Scenario: narrative description of people using the system
Scrum: An agile method of organizing software development process, by organizing into
sprints
Scrum master: scrum expert / coach, ensures team lives up to scrum principles. Is not a
boss, but a servant.
Sprint (scrum): Period from 2-4 weeks, during which a team works on a software part of a
fixed scope. Goal: working software!
Sprint backlog: list of items / tasks the team will be working on during sprint
Sprint planning: planning before sprint, leads to sprint backlog
Sprint retrospective: reflection with team how process went
Sprint review: review sprint with stakeholders, leading to feedback
Stakeholders: entity with interest in a project
Stub object: always returns same response
System test: development team tests entire system
Test-driven development: Write tests first, code afterwards to meet tests
Unified process: iterative software development process with 4 phases, tries to acknowledge
but also minimize change.
Unit test: test if a single code unit works
Use case: documents interaction yielding value
User story: description from user perspective who wants a certain feature
Validation: formal mathematical analysis of requirement
Verification: check if requirement is consistent / complete / accurate
Vertical scaling: adding more power to the current machines (in microservices)
Waterfall model: Linear (not iterative) model of software development process, does not
work in practice
