This summary contains everything you need to know for the midterm exam of Systeemontwikkelingsmethoden (System design methods) (INFOB2SOM). They are based on my lecture notes, and the lecture slides. In case the topics of the course are mixed up in between the exams and you miss something in this s...
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
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,96. Vous n'êtes lié à rien après votre achat.
