Week 1
• A class is a blueprint that defines the structure for
objects, which are concrete instances of that class (Chiel
is an object of the class Cat)
o Every Cat has a lot of standard attributes: name,
weight, height, texture… etc. These are the fields.
o Every Cat also behaves similarly: they breathe,
eat, walk, sleep, … etc. these are methods.
• A superclass lists all common attributes and behaviors. A
superclass could be Animal, and the subclasses would be
Cat and Dog. All cats and dogs have a name, height…, they
breathe, eat, walk… the subclasses then could inherit
these attributes and behaviors, and themselves only
define attributes or behavior that differ (like a Cat can
have a meow method and a Dog can have a bark method)
• Class Animal(Cat), or Class Organism(Animal)
• Abstract base classes (@abstractmethod):
o same as regular classes but you can’t make an instance of them (serve as an
interface)
o serve as an interface
• Waterfall Model (aims to complete every phase before going to the next: not robust
against change)
1. Requirements analysis
2. Design
3. Coding and debugging
4. Testing and verification
5. Maintenance
• RUP (Rational Unified Process): iterative software development (iterations)
o Phases:
1. Inception – define the scope
2. Elaboration – plan the project, features, architecture
3. Construction – finish the construction
4. Transition – hand over the project to end users
o Best practices:
Develop software iteratively and involve users early
Manage requirements
Visually model software (UML)
Verify software quality – test, code reviews, release in every iteration
Embrace change
• Agile Manifesto
Individuals and interactions > processes and tools
Working software > comprehensive documentation
Customer collaboration > contract negotiation
Responding to change > following a plan
o RUP vs Agile:
RUP is iterative top-down: minimize change by carefully thinking about
requirements before implementing anything
Agile is both top-down and bottom-up: minimize work for developers, by
releasing prototypes quickly and involving users in each iteration
,• SCRUM (filmpje kijken)
o User stories: short, simple description of a feature told from the perspective of
the person who desires the rear capability, usually a user/customer
o Epic: a user-story that covers a lot of functionality. They are split in smaller user
stories, which can be completed in a single sprint.
o INVEST checklist to check user story: Independent – Negotiable – Valuable –
Estimable – Small – Testable
o SPRINTS (iterations)
2-4 weeks, team commits to a scope which can’t change
Sprint planning sprint backlog
Daily scrum (15m coordinating discussion)
Sprint review & sprint retrospective
o Scrum artifacts:
Product backlog: ordered list of all possible changes that could be made
to the product
Sprint backlog: collection of product backlog items selected for delivery
in the sprint
o Scrum DOD en Increment
Definition of Done: when a product backlog item is considered done
Increment: collection of product backlog items that is considered done
o Scrum roles
Product owner: determines what needs to be done and sets priorities
Scrum master: protecting the scrum process and preventing distractions
Development team: determines how to deliver chunks of work in
frequent increments.
, Week 2
• Requirements engineering:
o Elicitation
o Specification
o Validation & Verification
o Negotiation
• Perspectives on software development process, object is a set of…:
o Conceptual (responsibilities)
o Specification (methods)
o Implementation (code & data)
• Object Oriented Design
o Strong cohesion: all code is related to one another, which makes it easier to
maintain, understand and re-use
o Loose coupling: anything can be changed without disrupting the system
o Responsibility
o 4 pillars of OOD:
Abstraction: a model of a real-world object or phenomenon, limited to a
specific context, which represents all details relevant to this context with
high accuracy and omits all the rest.
Polymorphism: the ability of a program to detect the real class of an
object and call its implementation even when its real type is unknown in
the current context.
Encapsulation: the ability of an object to hide parts of its state and
behaviors form other objects, exposing only a limited interface to the rest
of the program and helps identifying responsibilities (e.g. starting a car
only requires to stick in the key, but there’s actually much more
happening that is hidden beneath the dashboard)
Inheritance: the ability to build new classes on top of existing ones (main
benefit: code reuse)
• GRASP (General Responsibility Assignment Software Principles): to help assign
responsibilities to the class in the domain model
o Information expert (who has the info)
What info is necessary to perform some computation?
Which class(es) already have this info?
o Creator (who should create instances)
Assign class B the responsibility to create instances of class A
o Loose coupling
o Strong cohesion
o Controller (which subsystem handles the event)
Assign responsibility for receiving or handling system events to a class
• That represents the overall system, device or subsystem
• That represents a specific use case within which the system event
occurs.
• A class is a blueprint that defines the structure for
objects, which are concrete instances of that class (Chiel
is an object of the class Cat)
o Every Cat has a lot of standard attributes: name,
weight, height, texture… etc. These are the fields.
o Every Cat also behaves similarly: they breathe,
eat, walk, sleep, … etc. these are methods.
• A superclass lists all common attributes and behaviors. A
superclass could be Animal, and the subclasses would be
Cat and Dog. All cats and dogs have a name, height…, they
breathe, eat, walk… the subclasses then could inherit
these attributes and behaviors, and themselves only
define attributes or behavior that differ (like a Cat can
have a meow method and a Dog can have a bark method)
• Class Animal(Cat), or Class Organism(Animal)
• Abstract base classes (@abstractmethod):
o same as regular classes but you can’t make an instance of them (serve as an
interface)
o serve as an interface
• Waterfall Model (aims to complete every phase before going to the next: not robust
against change)
1. Requirements analysis
2. Design
3. Coding and debugging
4. Testing and verification
5. Maintenance
• RUP (Rational Unified Process): iterative software development (iterations)
o Phases:
1. Inception – define the scope
2. Elaboration – plan the project, features, architecture
3. Construction – finish the construction
4. Transition – hand over the project to end users
o Best practices:
Develop software iteratively and involve users early
Manage requirements
Visually model software (UML)
Verify software quality – test, code reviews, release in every iteration
Embrace change
• Agile Manifesto
Individuals and interactions > processes and tools
Working software > comprehensive documentation
Customer collaboration > contract negotiation
Responding to change > following a plan
o RUP vs Agile:
RUP is iterative top-down: minimize change by carefully thinking about
requirements before implementing anything
Agile is both top-down and bottom-up: minimize work for developers, by
releasing prototypes quickly and involving users in each iteration
,• SCRUM (filmpje kijken)
o User stories: short, simple description of a feature told from the perspective of
the person who desires the rear capability, usually a user/customer
o Epic: a user-story that covers a lot of functionality. They are split in smaller user
stories, which can be completed in a single sprint.
o INVEST checklist to check user story: Independent – Negotiable – Valuable –
Estimable – Small – Testable
o SPRINTS (iterations)
2-4 weeks, team commits to a scope which can’t change
Sprint planning sprint backlog
Daily scrum (15m coordinating discussion)
Sprint review & sprint retrospective
o Scrum artifacts:
Product backlog: ordered list of all possible changes that could be made
to the product
Sprint backlog: collection of product backlog items selected for delivery
in the sprint
o Scrum DOD en Increment
Definition of Done: when a product backlog item is considered done
Increment: collection of product backlog items that is considered done
o Scrum roles
Product owner: determines what needs to be done and sets priorities
Scrum master: protecting the scrum process and preventing distractions
Development team: determines how to deliver chunks of work in
frequent increments.
, Week 2
• Requirements engineering:
o Elicitation
o Specification
o Validation & Verification
o Negotiation
• Perspectives on software development process, object is a set of…:
o Conceptual (responsibilities)
o Specification (methods)
o Implementation (code & data)
• Object Oriented Design
o Strong cohesion: all code is related to one another, which makes it easier to
maintain, understand and re-use
o Loose coupling: anything can be changed without disrupting the system
o Responsibility
o 4 pillars of OOD:
Abstraction: a model of a real-world object or phenomenon, limited to a
specific context, which represents all details relevant to this context with
high accuracy and omits all the rest.
Polymorphism: the ability of a program to detect the real class of an
object and call its implementation even when its real type is unknown in
the current context.
Encapsulation: the ability of an object to hide parts of its state and
behaviors form other objects, exposing only a limited interface to the rest
of the program and helps identifying responsibilities (e.g. starting a car
only requires to stick in the key, but there’s actually much more
happening that is hidden beneath the dashboard)
Inheritance: the ability to build new classes on top of existing ones (main
benefit: code reuse)
• GRASP (General Responsibility Assignment Software Principles): to help assign
responsibilities to the class in the domain model
o Information expert (who has the info)
What info is necessary to perform some computation?
Which class(es) already have this info?
o Creator (who should create instances)
Assign class B the responsibility to create instances of class A
o Loose coupling
o Strong cohesion
o Controller (which subsystem handles the event)
Assign responsibility for receiving or handling system events to a class
• That represents the overall system, device or subsystem
• That represents a specific use case within which the system event
occurs.
