Software Engineering

Ace your homework & exams now with Quizwiz!

Netflix Simian Army

"monkeys" constantly testing their resilience to all sorts of failures to increase reliability

UML-supported visibility types

+ public # protected - private ~ package

code smell categories

- Bloaters: Long Method, Large Class, Primitive Obsession, ... - Object-Orientation Abusers: Switch Statements, Refused Bequest, ... - Change Preventers: Divergent Change, Shotgun Surgery, ... - Dispensables: Comments, Duplicated Code, Dead Code, ... - Couplers: Feature Envy, Inappropriate Intimacy, ...

prototyping

- Creating a scaled-down or incomplete version of a system to demonstrate or test aspects of it

advantages of observer pattern

- Loose coupling between subjects and observer (Subject only knows observer interface, new observers can be added any time, changes to either will not affect the other) - different notification mechanisms can be used, push/pull

why is software change inevitable?

- New requirements emerge when the software is used - The business environment changes - Errors must be repaired - New computers and equipment is added to the system - The performance or reliability of the system may have to be improved key problem for organisations is implementing and managing change to their existing software systems

To reveal a fault a test must

- Reach some code - Trigger a defect - Propagate an incorrect result - The result must be observed - The result must be interpreted as incorrect

When following the traditional waterfall process for developing a system which of the following activities/steps have completed before any code should be tested? (Multiple can be correct) - Requirements, Design - Design, Implementation - Requirements, Verification

- Requirements, Design - Design, Implementation

in which situations do we usually think about refactoring?

- When adding a new feature is much harder than expected. - When fixing a bug (that should be cohesive) requires changes that are scattered across the system. - When performing a code review for a simple feature/defect that requires complex changes that are hard to understand.

advantage of decorator pattern

- adheres to open-closed principle - extends the functionality of object without affecting any other object

a data flow system is one which

- availability of data controls computation - design structure is determined by order motion of data between components - pattern of data flow is explicit

Pipe and filter architecture

- components: filters - connectors: pipes - constraints: filter must be independent entities and should not share state with other filters, filters do not know about other filters

negative consequences for performing a refactoring

- consumer risk - can impair existing developer mental models of the system (wide-ranging refactorings can impact many people) and can make the system harder to understand if they add new abstraction layers - expensive since they take developer time that could otherwise be spent developing new features - easy to get carried away when refactoring (similar to the second-system effect)

different types of design patterns

- creational (process of creating objects or classes) - structural (composition of classes or objects) - behavioral (the way in which classes or objects interact and distribute responsibility)

match between system and the real world heuristic

- design should speak the users' language. - Use words, phrases, and concepts familiar to the user, rather than internal jargon - Follow real-world conventions, making information appear in a natural and logical order

testing as a verification tool

- easiest kind of verification to do - as a practice, it has questionable efficacy: it is related to fewer defects in the future, but not strongly related, and it's entirely possible that it's not the testing itself that results in fewer defects, but that other activities (such as more careful implementation) - students are often not convinced of the return on investment of automated tests and often opt for laborious manual tests (even though they regret it later(blabla))

In what context is MVC not a good idea?

- small applications - if big model, notifications can be overbearing for views

challenges / disadvantages of white box testing

- you don't always have access to the code - a lot of complexity that can be overwhelming for other people besides the developer to test

PaaS use cases

-API development and management -Internet of Things -Agile Development and DevOps (CI/CD) -Cloud-native development and hybrid cloud strategy (microservices, containers, kubernetes)

mutation testing

-Goal: ensure that a test suite is able to detect faults (test suite quality) -Modify program in small ways and examine if test suite is able to find the errors/mutants (killing a mutant) -Mutation operators mimic typical programming errors -Effectiveness of your test suite is determined by the percentage of mutants killed (kill score, amount of mutants killed divided by all mutants) -can take a long time to execute

issue tracking systems

-Manage development requests (also called bug reports, work items, change requests, change tasks) -maintain a list of bugs in the software (in a database called bug repository) -assign responsibility for each bug, feature, or task -organize work to be done -break up the work into "releases" or other deadlines

surveys

-Used to collect quantitative data -Consider mixing open-ended with closed questions -Plan questions well (usually no follow-up questions possible) -short

user control and freedom heuristic

-Users often perform actions by mistake - make it easy for user to back out from process or undo action

reasons to do prototyping

-aids UI design - provides basis for testing -team-building -allows interaction with user to ensure satisfaction

drawbacks of canary release

-any shared resource(cache, services) need to work with all versions in production -may be supporting multiple versions in production

Benefits of PaaS

-build, test, deploy run, update and scale applications more quickly and cost-effectively than if they had to build out and manage their own on-premises platform -faster time to market -low to no risk testing and adoption of new technologies -simplified collaborations -more scalable approach -less to manage

when to apply usability methods

-early and often -the earlier you can validate certain approach, the less time is spent writing wasted code -prototype and test often! before and during development; best to have iterative testing cycle, not on-off phase

criteria product must meet to be usable

-effectiveness -efficiency -engagingness -error tolerance -ease of learning

principles of low-risk releases

-favour incremental changes -decouple deployment from releasing -focus on reducing batch size -optimise for resilience

CI challenges

-granularity, every change? -how to deal with failures (notify person, team, organisation) -adoption concerns -tool support

principles of CI

-invest in automated tools -frequent commits -only commit code that compiles -fix broken builds immediately -all tests must pass -only pull code from known good configurations

risks of not doing CI

-little confidence tests will pass after integration -long integration phases -inability to generate testable builds -fear of making changes (refactoring) -late defect discovery -low quality awareness

contextual inquiry

-looking over shoulders of people using application possible to ask questions afterwards -can also ask to say their thought out loud throughout process -more qualitative data

Benefits of SaaS

-offloads all infrastructure and application management to the SaaS vendor,All the user has to do is create an account, pay the fee and start using the application -minimal risk -anytime/anywhere productivity -easy scalability

bug report writing guidelines

-precise -clear -one bug per report -no bug is too trivial to report -clearly separate fact from speculation

Cognitive Walkthrough

-quick way to get first impressions

useful actions for full-stack web projects

-run test-suite and comment metrics like failed tests, code coverage etc. -run code linter -run static code analysis tool -attach labels to PR based on code changes -ensure that PRs have correct format -convert TODOs in code to issues

why is evolution hard?

-systems not robust under change -lack of traceability -poor documentation of code, of design process and rationale and of system evolution -"stupid" code features may not be so stupid -poor management attitudes and culture (maintenance isnt high-profile, easier or less important than design)

mechanisms to improve code quality

-testing -code reviews -pair programming -frequent demonstration of working software to stakeholders -code smell detection and refactoring -component reuse -coding standard -automatic tools (static analysts, IDEs) -Team building activities -process standards (CMMI)

anatomy of bug report

-title (also called summary) -description -status -assignee -priority -target milestone -comments

how can we reduce bias in design?

-user involvement -recognizing scripts and metaphors (while designing things, we use certain scripts explicitly or implicitly. obvious example is when we use personas and user scenarios(abby). We create characters and write scripts about what they think and do. Such scripts can reflect biases and wrong assumptions, even when based on user research. ) -designing accountably

steps to take in automated testing

1) choose what we're going to test, what is more important 2) create individual test cases 3) execute test 4) examine the results (are we allowed to commit code with not running tests?) 5) evaluate if we have tested the system enough

refactoring process

1. Identify the property of the code you want to improve and the transformations required to solve the problem. 2. Run the test suite to ensure the system is fully working before the change (sometimes saving the output/logs of the test suite can also be helpful). 3. Perform the refactoring. 4. Run the full test suite again and ensure the system is functioning the same as before the refactoring.

Call sequence in the MVC

1. user clicks on sth in the view 2. controller updates the model 3. model notifies view that there have been changes in the model 4. view retrieves new state

call sequence of MVP

1. user performs some kind of action and passes it to the presenter(if action includes data, only primitive types will be passed) 2. presenter will change its internal state and update the model 3. model notifies presenter with event bus(presenter doesn't need to retrieve data, it is sent with the event bus) 4. presenter will update the view, again with primitive types

percentage if people with disabilities

15-20%

Industry averages regarding errors

30-85 errors per 1000 lines of code 0.4-3 errors per 1000 lines of code in product, so not discovered before product is delivered

why do users leave websites?

46% of users leave a website because they can't tell what the company does (i.e., a lack of effective messaging), 44% of users leave due to lack of contact information, and 37% of users leave due to poor design or navigation.

color blindness

8% males and 0.4 females

Boundary Value Analysis

A black box test design technique in which test cases are designed based on boundary values.

Serverless Architecture

A cloud computing execution model in which the cloud provider allocates machine resources on demand, taking care of the servers on behalf of their customers. part of PaaS, auto-scales underlaying servers without you noticing

canary release

A selective deployment to a subset of users so outage risk can be mitigated.

scrum methodology

A software development methodology where a team works together in sprints to reach a common development goal, with team members meeting daily in face to face communication, until development is concluded do a little bit of everything instead of doing all of one thing at once

Single Responsibility Principle

A software module should do one thing and do it well. Problem: often seems easier to add code to an existing module than to create a new module from scratch design patterns that encourage single responsibility: strategy, command, state pattern

unit test

A test of each individual component (often a program) to ensure that it is as defect-free as possible

api contract compatibility

API changes must not invalidate formerly legal client code

most popular cloud provider

AWS (amazon web services)

Examples for PaaS

AWS Elastic Beanstalk, Google App Engine, Microsoft Windows Azure, and Red Hat OpenShift on IBM Cloud

Which type of test is best when you want to test if your application satisfies your customer's expectations? [Unit / Integration / Acceptance]

Acceptance

software quality definition

According to IEEE: Degree to which a system, component or process meets the specified requirements / customer or user needs and expectations According to Roger Pressman: Conformance to explicitly stated functional and performance requirements, explicitly documented development standards, and implicit characteristics that are expected of all professionally developed software

state pattern

Allows an object to alter its behavior when its internal state changes. The object will appear to change its class. support open/closed by making it easy to extend the system by adding new states while still keeping the core of the system oblivious of the new states

Liskov Substitution Principle

Any object can be interchanged with any other object that has the same parent type. You need to check if subtype could replace parent class, for example with Is-A test: Eagle Is-A bird check check

API

Application Programming Interface interface program component use to interact with each other

Examples for modularity in real life?

Apps on your phone you can download it, it's separate you can build on top of it or libraries while coding

large class smell

As with long method, large class captures classes that have grown beyond their original mandate. Extract class and extract method refactorings are often used in these cases.

configuration

Bind components and connectors in a specific way, differentiates a bag of components and connectors from an implementable system An architectural configuration, or topology, is a set of specific associations between the components and the connectors of the system's architecture

cases of discrimination and suppression in software engineering history

Black American entrepreneurs began to explore how to use software to connect and build community well before the internet was ubiquitous, creating some of the first web-scale online communities and forging careers at IBM, ultimately to be suppressed by racism in the workplace And despite the central role of women in programming the first digital computers, managing the first major software engineering projects, and imagining how software could change the world, women were systematically excluded from all of these efforts, their histories forgotten, erased, and overshadowed by pervasive sexism in commerce and government.

Downside of monolithic applications

Change cycles are tied together - a change made to a small part of the application, requires the entire monolith to be rebuilt and deployed. Over time it's often hard to keep a good modular structure, making it harder to keep changes that ought to only affect one module within that module.

Dependency Inversion Principle

Classes should depend on abstractions, not implementations. This principle helps engineers to design implementations that are as decoupled from one another as possible. This usually happens by injecting an interface between the two concrete classes and having the classes take dependencies on the interface instead.

Interface segregation Principle

Clients should not be forced to depend on interfaces they do not use. This principle exists because as we evolve our systems we often do so by adding new methods to our interfaces rather than by creating new ones to succinctly capture the added feature additions.

Ok to worst type of coupling

Data Coupling (interacting through simple data types) Stamp Coupling (interacting through data structures or composite objects and only using parts of it) Control Coupling (zb so en boolean status mitge wo beiflusst wie d function executed, git info über d implementation use) Global/common coupling (mit globale variable, beiflusst all modules wos benutzen) Content coupling (internal modification of other classes)

observer pattern

Defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically. pull or push: pulling means observer is responsible for pulling its particular window of interest from the subject, pushing means subject pushes what has changed to all observers push model compromises reuse, while pull model is less efficient

binary compatible

Describes a file that requires no conversion when used on various computer platforms

Common implementations of IaaS

Disaster recovery (geographically-dispersed infrastructure) Ecommerce (regular spikes in traffic) AI (good for applications that work with huge volumes of data) Startups (cant afford to have on-premise IT infrastructure) Software development(however better suited to PaaS)

equivalence class partitioning (input class partitioning)

Divide the input into several classes that are considered "equivalent" for the purposes of finding errors

Help users recognize, diagnose, and recover from errors heuristic

Error messages should be expressed in plain language (no error codes), precisely indicate the problem, and constructively suggest a solution.

Refactoring doesn't integrate well with agile methodologies (True/False)

False

Types of cohesion from good to bad

Functional Cohesion (model does single well-defined task) Sequential Cohesion (output from one step used as input in next step) Communicational Cohesion (operate on same data) Procedural Cohesion (follows certain sequence of execution, e.g. protocol) Temporal Cohesion (processed at a particular time in program execution, but not the same thing, e.g. function which is called after catching exception which closes open files, creates error log, notifies user) Logical Cohesion (logically related but otherwise different) Coincidental Cohesion (functionality arbitrarily grouped)

Software Quality Attributes

Functionality, reliability, maintainability, efficiency, usability, probability

error prevention

Good error messages are important, but the best designs carefully prevent problems from occurring in the first place

What are the benefits of designing to interfaces?

Helps decouple implementation from the design so we can reuse parts of our system, without having to worry about the rest

Which design principle is violated the most: public class System { public void changeCarSpeed(); public void changeCarColor(); public void changeHighwayMaxSpeed(); public void updatePoliceCarPosition(); }

High cohesion

Is the product owner inside or outside of the company or inside the development team

I'd say part of development team. He has to deliver work with the team.

three most popular cloud computing service models

IaaS, PaaS, SaaS

when should you fix a code smell?

If it is bad enough to legitimate the effort: -if it appears more than three times - if it affects the ability of making a change - if the code is no longer understandable

OR check

If you can say that a class can do that or that, it should be multiple classes. -> single responsibility "A description that describes a class in terms of alternatives is not one class but a set of classes" "A classroom is a location where students attend tutorials or labs"

how should the interdependence and independence be regarding modules?

Interdependence within and independence across modules

Abstract Factory

Interface for creating families of related or dependent objects without specifying their concrete class because service provided by the factory object is so pervasive, it is routinely implemented as a singleton The stamping equipment is an Abstract Factory which creates auto body parts. The same machinery is used to stamp right hand doors, left hand doors, right front fenders, left front fenders, hoods, etc. for different models of cars. Through the use of rollers to change the stamping dies, the concrete classes produced by the machinery can be changed within three minutes.

aesthetic and minimalistic design heuristic

Interfaces should not contain information which is irrelevant or rarely needed doesn't mean you have to use a flat design — it's about making sure you're keeping the content and visual design focused on the essentials

help and documentation heuristic

It's best if the system doesn't need any additional explanation. However, it may be necessary to provide documentation to help users understand how to complete their tasks.

Which design principle is violated the most: public class Road extends Highway {..}

Liskov Substitution

Which design principle is violated the most: public class Kid extends Person { \** Inherited from parent class. does nothing because kids do not know how to "reason" *\ public void reason(){} }

Liskov Substitution Problem Not Interface segregation, since it is not an interface

"An object of a superclass should always be substitutable by an object of a subclass" refers to?

Liskov substitution principle --> subclass has same or weaker preconditions subclass has same or stronger postconditions derived classes should assume less, deliver more

Which design principle is violated the most: 52 different import statements at the top of java file

Low Coupling

between the MVC and MVP, which one uses a pull-based observer and which one a push-based observer?

MVC pull, MVP push

Recognition rather than recall heuristic

Minimize the user's memory load by making elements, actions, and options visible

MVC

Model View Controller widely used meta-pattern that employs several other design patterns

MVP

Model View Presenter modernisation on MVC forces controller or in this case presenter to be more featureful decreases code in views

Do developers spend most of their time coding?

No

Can we avoid all coupling?

No, and we shouldn't. If we have multiple classes with absolutely no interaction between them, we wouldn't have a working code

Is MVC often used in gaming context?

No, because of performance reasons

Can an organisation without development team have a need for PaaS?

Open/Closed Principle

Open to extension but closed to modification.

Which design principle is violated the most: public final class Bird{..}

Open/Closed final: doesn't allow extension

According to the Liskov substitution principle, could square be a subtype of rectangle?

Passes the Is-a test, but preconditions are actually tighter for squares than for rectangles, so no

what is software engineering actually?

People working together to create a robust software system that satisfies the client.

most common refactorings

Rename (class/field/method). Move (class/field/method). Extract class/interface/method. Push down/pull up field/method. Replace magic number/string with constant. Replace inheritance with delegation.

REST

Representational State Transfer

what does the controller in MVC do?

Responds to changes in the view and updates the model accordingly

Design Symptoms

Rigidity Fragility Immobility Viscosity Needless Complexity Repetition Opacity (--> meh info 13.04 Design Guidance and symptoms)

regarding PaaS, IaaS, SaaS: which one takes the most responsibility away from the costumer?

SaaS>PaaS>IaaS

benefits of IaaS

Savings in up-front costs Flexibility and on demand capacity, High availability, comprehensive security, faster access to best-of-breed technology

Flexibility and efficiency of use heuristic

Shortcuts — hidden from novice users — may speed up the interaction for the expert user such that the design can cater to both inexperienced and experienced users. Allow users to tailor frequent actions

SOLID Design Principles

Single Responsibility Principle Open/Closed Principle Liskov Substitution Principle Interface Segregation Principle Dependency Inversion Principle only guidelines, not rules

slips vs mistakes

Slips are unconscious errors caused by inattention. Mistakes are conscious errors based on a mismatch between the user's mental model and the design.

TDD methodology

Test-Driven-Development expectation of quality became more and more important heavy emphasis on automated unit testing write tests first (forces coders to write code in a very testable manner)

White Box Testing

Testing based on an analysis of the internal structure of the component or system. (example: opening the hood of the car to check if it is working)

What do people think is software engineering?

The process of transforming a mental plan of desired actions for a computer into a representation that can be understood by the computer.

Utility + Usability =

Usefulness

consistency and standards heuristic

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform and industry conventions

At which point of designing software should one check the design for design symptoms, is there a specific slot?

Usually as soon as you develop your code and then in phases if you have the time to refactor the code

verification vs validation

Verification: "Are we building the product right?" Validation: "Are we building the right product?"

Is not all coupling equally detrimental?

Yes, coupling elements by simple data types is less problematic than coupling them through global variables (common coupling) or internal field access (content coupling

how do we represent an abstract class in a class diagram?

abstract classes are in italic

Presenter in MVC

acts as a mediator between view and model only interacts with the view using primitive types, won't actually get objects

downsides of MVC

also called massive view controller paradigm it is really easy to put way to much functionality in the view, which is a problem since view is the hardest part to test --> put more functionality from the view into the controller, where it is easier to test

monolithic application

application built as a single unit

largest category of defects

arrive from faulty requirements (garbage in, garbage out) if we specify wrong software in the first place, we will get the wrong software

Decorator pattern

attaches additional responsibilities to an object dynamically, provides flexible alternative to subclassing for extending functionality. Ex: starbucks drinks

Continuous deployment

automatically releasing developer's changes from the repository to production where it is usable by costumers solves problem of overloading operations team with manual processes that slow down app delivery so developers change to cloud application could go live within minutes of writing it(assuming passes automated tests)

heuristic evaluations

based on nielsen's 10 principles of UI design

two types of aggregation

basic aggregation/aggregation (children can outlive parents, diamond is not filled in) composite aggregation/composition (children's life depends on parent, diamond is filled in)

To which of the three different classes of patterns does the observer belong to?

behavioural

how does a microservice architecture scale?

by distributing the services across servers, replicating as needed

how does a monolithic application scale?

by replicating the monolith on multiple services

api contract compatibility if api is web service

can version URLs used to access service. Basically, no great solution yet to thomas's knowledge

positive aspect of waterfall

clear and explicit hand off from step to step, much clarity between the phases good for well-understood but complex projects since it tackles all planning upfront and since it is an efficient process because there are no midstream changes provides support for an inexperienced team

What does SaaS provide

cloud-hosted, ready-to-use application software complete application from within a web browser, desktop client or mobile app

elements of software quality

code (but not only!!) documentation the people other factors

code under test (cut) or system under test (sut)

code individual test case or test suite are evaluating

middle man

common smell that occurs when a method does not do anything itself but just ends up delegating all work to another class. frequently arises after refactorings that move functionality to other methods but the original base method remains

5 properties of requirements

complete consistent precise (exact or accurate) concise (short and to the point) unambiguous

what pattern do views often use?

composite

what does a sprint consist of in scrum methodology?

daily stand-up meetings at end of sprint ceremony phase where progress is discussed

object scope

deal with object relationship that can be changed at run-time and are more dynamic

class scope

deal with relationships between classes and their subclasses

Is Git a centralized or decentralized version control system?

decentralized

main positive aspect of MVC

decouples view from the rest of the system - we can add multiple views which work with the same data sets - usually it is a separate team anyway

Strategy pattern

define a family of algorithms that can easily be interchanged with each other. allows to vary behaviour based on new requirements support open/closed principle by abstracting algorithms behind an interface; clients use the interface while subclasses provide the functionality

Cloud Computing Services: Who manages what?

demit ichs mit cmd+f finde: SaaS, IaaS, PaaS

does adding API field break binary compatibility?

depends if subclassable you can not add a public field, would break compatibility if not subclassable, doesn't matter

visibility of status heuristic

design should always keep users informed about what is going on, through appropriate feedback within a reasonable amount of time

best way to support ease of learning

design systems that match user's existing mental models (trash, folders, buttons)

benefits of CI

detect and fix problems faster measurable software health global failure feedback; developers trust their changes

Code Smells examples

duplicated code long method large class long parameter list message chain divergent change shotgun surgery middle man feature envy ...

characteristics of a good API

easy to learn easy to use, even without documentation hard to misuse easy to read and maintain code that uses it sufficiently powerful to satisfy requirements easy to understand appropriate audience

test case

evaluates single explicit behavior within your program

vast majority of software development is performed on...

existing systems software maintenance and evolution are primary components of the total budget

drawbacks of green-blue deployment

extra cost in infrastructure data migration issues

For software service providers, the product owner is always the end-costumer. True or false?

false

types of coverage

flow independent: - block (proportions of block in a system that are executed by test suite) - line - statement (similar to line coverage, proportion of statements that are executed by test suite) flow dependent: - branch (have we tried true and false coverage of if statement?) - path (makes sure that we execute all paths possible) - MCC (ensures that all statements are independently evaluated with respect to the outcome of a function)

release strategies

green-blue deploy canary releasing

design errors

happen when we take high level specification and translate it down into low level design

How to tell if a class is cohesive

have a set of private fields and the functions act on those fields. if there is a method that doesn't do anything regarding those fields it is probably not cohesive

why is it important to label our effort regarding rewriting/refactoring?

helps to better set expectations, others will have a better idea about how much time and effort is going to be invested

advantage/disadvantage of bottom up composition?

helps us write reusable code and gets us building the system early once we get to high levels abstraction we realise we made low level implementation decisions upfront that causes high level inconsistencies

layered system

hierarchically organised providing services to upper layers and acting as clients for lower layers lower levels provide more general functionality to more specific upper layers

architectural design is _ level

high

Design Principles are what exactly

high level guidelines that can help ensure our designs are robust in the face of defect fixes and feature additions

down sides of observer pattern

high notification cost if there are many observers

What does PaaS provide?

hosts, manages and maintains all the hardware and software included in the platform - servers (for development, testing and deployment), operating system (OS) software, storage, networking, databases, middleware, runtimes, frameworks, development tools - as well as related services for security, operating system and software upgrades, backups and more.

user-centered design process

how and why a user will adopt a product and seeks to evaluate that use iterative

deployment diagram

how system components are distributed on hardware

shotgun surgery

if a change in one class requires cascading changes in several related classes, consider refactoring so that the changes are limited to a single class

pull up field

if there are identical fields in more than one subclass, move the field to superclass

When are two program elements considered independent?

if they can function without the presence of the other

Why does usability matter?

if users cannot achieve their goals efficiently, effectively and in a satisfactory manner, they are likely to seek an alternative solution to reach their goals

benefits of green-blue deploy

incremental, stress-free deployment preparation of blue environment supports rapid rollback

IaaS

infrastructure as a service, is on-demand access to cloud-hosted physical and virtual servers, storage and networking - the backend IT infrastructure for running applications and workloads in the cloud

One common code smell for violating the open/closed principle

instanceof or typeof checks within the code

Interface vs Abstract Class

interface only has method signatures, no method body, can have only constants as well. abstract class can have method body

Why is it more helpful for front-end development to be more decoupled from other development activities?

interfaces change more frequently than their backend data models and business logic By decoupling views and logic, MVC enables front-end teams (including designers) to work independently from the rest of the team

technical debt

irresponsible (obe links) intentional (obe rechts) incompetent (une links) accidental (une rechts)

Code linting

linting is the automated checking of your source code for programmatic and stylistic errors using a linter many IDEs have a built in linter that compiles with the standards of the respective language

what to avoid in API design

long parameter lists of the same type exceptional return, like giving back a null type

design patterns are really _ level

low

errors from ignored or modified requirements

made decisions at development time to satisfy the team, usually bcs of time constraints (good for development team but not for users)

Singleton Pattern

make sure a class has a single point of access and is globally accessible private constructor

downside of MVP

makes presenter quite large

types of verification

manual testing, automated testing, inspection, program analysis

what is CI/CD used for?

method to frequently deliver apps to customers by introducing automation into the stages of app development. continuous integration, continuous delivery, continuous deployment

Metapatterns are _ level

middle

In an MVC, what part is the object and what part is the observer?

model is the object, view the observer if something in the model is updated, the observer gets notified and the observer will retrieve the new state

implementation errors

most common cause of fault when we translate low level design into actual code, so missing guards and other small mistakes etc

duplicated code smell

most common code smell if in same class: extract method refactoring to have have all copies in the class use the same single implementation, else more complex analysis needed

pull up method

moving a method to the superclass

Are IaaS, PaaS, SaaS mutually exclusive?

no

Does the Model in MVC know how to render itself?

no

does refactoring need to change the semantics of the program?

no

is TDD a process like waterfall or XP?

no

is refactoring the only way to get rid of code smells?

no

is there a a formal definition of the microservices architectural style?

no but we can attempt to describe what we see as common characteristics for architectures that fit the label.

Functional or non-functional request: As a user I want the site to be available 99.9% of the time I try to access it so that I don't get frustrated and switch to another site.

non-functional

is improving the reliability or performance of the system a functional or non-functional?

non-functional

Functional or non-functional request: As a costumer, I want to be able to run the game on all versions of Android.

non-functional is a property of the whole system

what used to be the use of computers earlier?

not creating new realities or facilitating new tasks, it was accelerating old tasks

Are patterns usually used in isolation?

not usually

default of automated testing

only shows presence, not absence of defects

are the return message an optional or mandatory part of the sequence diagram?

optional

services definition

out-of-process components who communicate with a mechanism such as a web service request, or remote procedure call. (This is a different concept to that of a service object in many OO programs [3].)

how does the costumer consume cloud computing service models

over the internet

PaaS

platform as a service, is on-demand access to a complete, ready-to-use, cloud-hosted platform for developing, running, maintaining and managing applications

software maintenance/evolution

producing new (versions of) the existing software under constraints of existing software aka brownfield development backward compatibility is often assumed/required

failure

program behavior that results from a defect executing. In our sorting example, the failure is the incorrectly sorted list printed on the console

software defect

program continues to execute but behaves incorrectly

Model in MVC

programmatic representation of the application's data knows how to persist itself

Coupling

property that indicates the strength of connections between different program elements

usability methods

prototyping surveys context inquiry/task analysis cognitive walkthrough heuristic evaluation

core design decisions behind REST

provide unifrom interface to access layered independent systems that is simple reliable scalable extensible

Rewriting

re-building the same functionality that exists in a legacy application but using a different language/framework, maintaining within a new code repository (not just a branch), and deploying as an entirely new artifact (possibly to a different platform - e.g. servers, hardware, serverless, client, etc.)

are sequence diagrams high or low level?

really low-level

refactor vs. rewrite

refactoring: we're going to keep the application mostly as it is, but make some minor, internal improvements to solve specific problems (like maintainability, extensibility, etc.) rewriting: "start again from scratch", or in other words to make major changes

View part go the MVC

renders the data from the model, so that user can see them

Most common form of agile methodology

scrum based methods

test suite

set of test cases

Cohesive classes are generally

smaller

message chains

smell person.getDepartment.getManager() bad because any change to an intermediate relationship causes the client to have to change refactoring: hide delegate

benefit of code reviews

so (at least) someone looks over your new code - knowledge sharing - find flaws early on - new perspective - reduce rework ( the later bug is found, the more expensive it is to fix them)

SaaS

software as a service, is on-demand access to ready-to-use, cloud-hosted application software

code smells

symptoms of specific code deficiencies never absolute: they are usually informally identified and are sometimes not signs of poor code highlight properties of code that could be detrimental to debugging, understanding, quality

acceptance test

test of a new system using real transactions to determine if user-developed acceptance criteria are met, usually done by the user/client alpha test: at production site beta test: at user's site

line coverage

the fraction of lines visited when running a suite, is simple but gives limited confidence

continuous integration

the idea of completely automating not only builds, but also the running of a collection of tests, every time a bundle of changes is pushed to a central version control repository helps devs merge their code more frequently

MVC splits responsibilities into three broad groups:

the model, the view, and the controller

What changes the most in an application?

the views

how does composition work

through delegation you have an object and are going to invoke methods upon that object. drives you to much smaller classes

how is PaaS accessed?

through graphical user interface

Why was MVC created?

to help developers think about how to decouple responsibilities within Smalltalk applications. This guidance has proven so successful that it has been widely adopted by many modern UI frameworks.

the controller in the MVC is tightly bound to what exactly?

to the view it is associated with

Blue-Green Deployment

two identical production environments: blue environment is live, new software release is tested on green environment, as soon as works, switch router so that incoming requests go to green environment

around what should design be centered?

user

Does the vendor or client manage patches and upgrades of SaaS?

vendor

API Design Process

what is the goal? (languages, protocols, platform, formats) who is the costumer? (versioning, licensing, authentication) start with short specification (0.5-1 page) solicit feedback prototypes (at least 3) documentation

what the costumer wants might not be

what they need the most cost-efficient or effective solution to meet their need achievable within the available time and budget

feature envy

when a method uses the data from other classes more than it uses its own state which often suggests that the method is in the wrong place

procedural error (user error)

when user makes mistake while using the software

Red-Green-Refactor

write test, which fails first, then make it pass and then refactor it

Desings should have x cohesion and y coupling

x high y loose

Do all the components in the MVC know about each other?

yes

Do many design patterns heavily rely on inheritance?

yes

Is coupling a natural part of software?

yes

can an object in a sequence diagram call itself?

yes

do the aesthetics fall under usability?

yes

Can process methods be combined?

yes for example waterfall but combined with some iterations

are the model components in MVP and MVC the same?

yes, but small difference: while you can use observer pattern within MVP like in MVC, often the case that the model will interact with the presenter using an event bus(third party component that moderates the interactions)

waterfall model

A series of steps in which we make one step after another without going back

Select all the functional requirements The crucial components of the software systems should have a 96% statement test coverage. As a user I want to see a loading bar when I upload a document to a website. The whole website must be accessible to people who are color blind. The website source code must be maintainable by non-experienced programmers.

As a user I want to see a loading bar when I upload a document to a website.

When writing a code: until when can you get away without much organisation?

As long as program has only a few hundred lines

Disadvantages of modularity

For example if we use a library, sometimes we have to tweak a lot of things just to make it work and in the end it is more effort with than without the library

is it possible to combine top-down or bottom up?

In order to make optimum use of both approaches, both planning procedures are often used in combination with each other as required. If top-down and bottom-up planning are applied simultaneously, this is referred to as countercurrent planning or a countercurrent method.

how to write effective user stories

Independent (user stories should be independent, so that we actually have a choice for which stories to pick) Negotiable (consider user stories as work in progress) Value (user story needs to have a value) Estimable (need to provide effective cost for a feature) Small (small features are easier to estimate, more negotiable, more independent) Testability (definition of done, both costumer and developer needs to be able to test if feature is acceptable for both parties)

agile manifesto, most important ones

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer interactions over contract negotiation Responding to change over following a plan

Can the scrum master also be the product owner?

No, they have different goals The Scrum Master is one individual who focuses on supporting the team and protecting the team. The Product Owner is focused on prioritizing, getting the backlog ready, and they're asking for "more, more, more" when it comes to business value. So, those two can be in conflict, and that can be healthy.

Difference between software design and software architecture?

Software architecture exposes the structure of a system while hiding the implementation details. Architecture also focuses on how the elements and components within a system interact with each other. Software design delves deeper into the implementation details of the system.

Given the following user-story: "As a user, I want to be able to recover my password such that I don't get locked-out of the system when I forget my login credentials." Which of the following statements are correct? The user-story has a clear value according to INVEST. This user story is a good example for the role-goal-benefit format. In this user-story, the benefit is that the user can reset his password.

The user-story has a clear value according to INVEST This user story is a good example for the role-goal-benefit format.

what does performance consist of?

Time (response, throughput (nr of transactions per seconds that the system can handle) during peak or off-peak) space (Memory, Disk)

what is the goal of all software design techniques?

To break a complicated problem into simple pieces

one of the first really influential agile methodologies

XP

modern processes for structuring development of software products

XP, scrum

What are the advantages of modularity?

You can focus on one thing without having to think about another, you can make changes more localised, don't have to change things everywhere if you want to fix a single thing. allows parallel work on independent parts of the system

wicked problem

a problem that can only be clearly defined and understood by solving it usually no definitive formulation no stopping rule (never really "done") solutions are not right or wrong usually (just better or worse) software development often considered a wicked problem

user story needs to be implementable in..

a single iteration

scoping

a strategy for information hiding hides variables and names from other parts of the program outside a scope

preferences

a type of requirement costumer has a long list of things they want the system to do

design constraints

a type of requirement for example regulatory framework in a company

environmental constraints

a type of requirement software doesn't run in isolation system needs to work with other systems

component design principles

acyclic dependencies (no cycles in the dependencies graph between components) common closure (change that affects class within component should not affect classes outside of it) common reuse (If you reuse one class in a component you reuse them all) open-closed(Software elements should be open for extension but closed for modification.) stable dependencies (Depend on the direction of stability - If component A depends on component B, then B should be more stable (e.g. less likely to change) than A.)

connectors

an architectural entity tasked with effecting and regulating interactions between components often consist of method calls, but can be much more often more challenging than components in large heterogenous systems

what does the lollipop notation mean in component diagrams?

an interface is provided

Problems with the Denver International Airport baggage system

bad planning (started software production only 17 months before opening) physical problems (building was built before baggage system was designed, architecture wasn't a good fit) change of management not accepting changing requirements lack of experience

What are the two ways to decompose a system?

bottom-up (vo chlinnere zu grössere) or top-down (splitting large systems into smaller ones)

software failure

causes program to crash or requires one to reboot the computer

advantage of TDD

clear deliverables, you know exactly when you are done and what is expected

5 key principles of XP methodology

communication simplicity (avoid over-engineering) feedback courage (try out different experiments to make system better, be willing to throw things away, honest about failure) respect(for all stakeholder's opinions, don't break code: any code that is committed always works so no-one is slowed down)

component vs deployment diagram

component: make sure to specify who requires and provides something deployment: make sure to identify all the physical devices and associate each component with a device

architectural mismatch

components that were not developed specifically for your system may not meet all of your requirements-they may not even work with the components you pair them with. can happen even with carefully selected architectures

software requirements

define what the system should be doing, NOT how help to understand, communicate, connect and define when done everyone must understand them (designers, developers, testers, costumers)

stakeholders in software engineering

developers QA (quality Assurance) DevOps (Zusammenführung von Development & Operations) Managers Sales Users Support

downside of TDD methodology

developers struggle with writing tests before the code in practice

components

elements that encapsulate processing and data at architectural level architectural entity that: encapsulates subset of functionality restricts access via explicit interface has explicit environmental dependencies for example: client/server

the iterative process of finalising a specification

elicitation (gathering requirements for a system from various stakeholders) analysis (looking at requirements we gathered and check for consistency, negotiation phase between customer and developers) reification/specification (formalising output of the analysis in form of user stories for example, documentation) validation (go back to customer with final list of requirements and see if it matches their expectations)

agile methodologies definition

emerged as response to more traditional methodologies tightening the feedback loop between developers and costumers, enabling developers to be more flexible and making development faster

Spiral Methodology

emerged in 1980s as response to some of the shortcomings of waterfall methodology a cycle between planning, risk analysis, engineering and validation (not only QA, also checking with costumers if they actually need that etc.) takes about 1 year per iteration, always a new prototype

information hiding vs encapsulation

encapsulation is a information hiding strategy

XP methodology

extreme programming all about having a buildable system at all times starting small and slowly grow system over time in response to costumer feedback

Why design?

facilitates communication eases implementation helps discover problems early on increases product quality eases system understanding reduces maintenance cost facilitates product upgrade

True or false: The more information hiding is used when designing a new software system, the harder it is to understand.

false

True or false: A requirement is "precise" if it also describes the implementation details of a certain feature.

false we don't want the implementations details in there, it should be understandable for everyone.

cross-cutting concerns

features and functionality that span multiple different components of a system, or even an entire system. risks: defects, low modifiability, etc.

Functional or non-functional request: As a user I want to be able to change the mouse sensitivity to change the moving speed

functional

Functional or non-functional request: The system must allow the user to undo the last changes

functional

Functional or non-functional request: As a user I want to see a warning when the connection fails to know what's going on.

functional here you want a direct feedback a specific function if it was more general like I want the system to be easy to use it would be non-functional

Functional vs Non-Functional Requirements

functional requirements are for example I want to be able to log out with a single click on a button. non-functionalities are performance, scalability, complexity, testability for example, so qualities

technical dept (/ code dept / design dept)

implied cost of additional rework caused by choosing an easy (limited) solution instead of using a better approach that would take longer

What are the topological goals?

minimize coupling between different components maximize cohesion within each component

disadvantage of top-down decomposition?

often low level leaf nodes end up conflicting with one another, because we made some decisions there, that we didn't make with other parts of the "tree"

scrum artefacts

product backlog (prioritised list of requirements/PBIs that describe all desired functionality) product backlog item (user story form, costumer-centric feature, effort estimated by team, business value and priority estimated by PO) sprint backlog (contains list of sprint items broken down into specific tasks) turndown chart (total remaining team task hours within one sprint)

roles in scrum based methods

product owner (proxy for client or client themselves, see if product matches expectations) scrum master (manage development process, not manager of team but of process, sees if team is working on the issues of that sprint that PO prioritised) team (5-7 people, diff. disciplines)

birth of software engineering occurred when

programmers started solving problems that didn't have existing solutions, or were new ideas entirely

shortcomings of spiral methodology

risk analysis can be quite overwhelming waiting for costumer feedback for a year at the time can really slow down process

what do user stories need to contain?

role-goal-benefit (as a .. I want to .. in order to ..) notes/limitations of the feature definition of done / acceptance tests engineering tasks/notes (valuable for developers) effort estimate

Software supply chains

software we write today is often dependent on a chain of software modules we may or may not even know about. As a developer I may take a dependence on a module but we don't know what it actually depends on These chains can have unintended consequences

forms of documentation

specification (requirements etc for managers for example) development (more architecture etc. for developers, managers etc) validation (test plans, risk assessments for QA) deployment / evolution (devOps plans and maintenance strategy for longterm)

What happens if you can't finish a sprint item during a sprint?

task is put back into the product backlog

developers feel productive when ..

they make progress on tasks with few expensive context switches / interruptions

The product owner chooses features from the product backlog and assigns them to a spring in the spring-planning phase. True or false?

true

True or false: A java interface is a good example if information hiding, since an implementation of it might change while the interface itself remains the same.

true

modularity

two ideas: 1) a module is a unit whose structural elements are powerfully connected among themselves and relatively weakly connected to elements in other units. 2) captured by three terms: abstraction, encapsulation, information hiding. Abstraction technique that help identify which specific information should be visible and which should be hidden. Encapsulation is technique to hide information that should be hidden and make visible what is intended to be visible.

Software Project Risks

user (resistance of change, negative attitude towards project, lack of commitment or cooperation) requirements project complexity (new or immature technology, first use) planning & control (ineffective communication, unclear milestones, poor oversight) team (lack of experience or training) organisational environment (change of management, ongoing restructuring, unstable organisation)

what can the role of role-goal-benefit in user stories be?

user, developer, even non human entities like backend etc.

traditional processes for structuring development of software products

waterfall, spiral

downsides of waterfall model

we only know in the very end of the process if system is actually useful in practice sometimes we need to take a step back if for example business conditions change difficult to get requirements right upfront

"ball of mud" or "spaghetti code"

when information hiding strategies fail they have no apparent organisation, which makes it difficult to understand how parts of the implementation interact

when are component diagrams particularly useful?

with large teams

Ways to decrease the coupling between program elements

- Minimize the number of interfaces between elements - Minimize complexity of interfaces (reducing the complexity of this coupling to its core elements can make the interaction between the program elements clearer and easier to reason about and evolve) - avoid control flow coupling (It can often be convenient to pass objects that control the flow of computation within another element. While this is ok if the element being passed is some type of data structure, it can be more problematic if the control flow is being influenced by simple control flow flags (e.g., some kind of boolean flag that takes one program path over another).)

disadvantages of decorator pattern

- can create lots of small classes and overuse can be complex - increases complexity of code needed to instantiate a component - can be harder to debug

three guidelines to operationalise the high-level design into to sth we can turn directly into code

- encapsulate what varies - ensure to design to interfaces - favour composition over inheritance

kinds of defects

- errors from ignored or modified requirements - faulty requirements - design errors - implementation errors - untested implementations - procedural errors

strong coupling negatively influences the evolvability and maintainability of a program because:

- makes it easier for errors in one part of the system to affect other unrelated parts. - increases the degree to which a single bug fix or feature addition is scattered across the codebase. - much harder to reuse independently than code which is loosely coupled. - harder to understand a source code element that is coupled to other elements because individual elements cannot be considered (and understood) in isolation.

unit test contains

- meaningful name that indicates the point of the test (just one thing!) - setup portion (sometimes refactored into the @Before code) -Invocation of the code to be tested -check the result against expectations, assertions

high level properties that we want our test cases to have

- need to be fast - reliable (when test case fails, there is an actual defect in the code) - need to isolate failures, if test case fails it needs to be clear where the defect is - should simulate users

time spent during change tasks

- reading code - editing code - navigating dependencies - searching for names - testing - other

typical refactoring workflow, personal project

- refactor at the start of the sprint - implement changes - refactor new parts - release the code

typical refactoring workflow, industry setting

- refactoring the portions you'll be changing at the start of the sprint - implement your changes - release the code (not refactoring right before the release)

Cohesion

Degree to which members of a class serve a unifying task or concept

principles for designing good APIs

Do one thing and do it well APIs should be as small as possible, but no smaller minimize access, maximise information hiding names should be largely self-explanatory documentation matters

which one was the original "as a service" offering?

IaaS Every major cloud service provider - Amazon Web Services, Google Cloud, IBM Cloud, Microsoft Azure - began by offering some form of IaaS

k-anonymity

Idea for data sets that a person must be identical to at least k other records

Scrum of Scrums

Meetings used to organize large projects with scrum masters from different teams.

MVVM

Model View ViewModel most recent modification of MVC In MVVM the ViewModel acts more like the Presenter in MVP and contains most of the application logic for the system, where the ViewController instead focuses on preparing data in a way that is amenable for data binding (and responding to user-driven events appropriately).

Lehman's Laws

Observations on large systems developed by large organizations + Continuing change + Increasing complexity + Large program evolution + Organizational stability + Continuing growth and declining quality + Feedback system

Black Box Testing

Testing, either functional or non-functional, without reference to the internal structure of the component or system. easier for external people to write (example: driving the car, starting the engine to check if it is working)

usability

The extent to which a product can be used by specified users to achieve specified goals, with effectiveness, efficiency and satisfaction in a specified context of use

What does the MVC try to separate?

The implementation of the application from its view

Aspect of loose coupling in MVC

The notify connection from the model to the view, model doesn't need to know anything about the views

Integration tests

They verify that when all of the functionality of a program is put together into the final product, it behaves according to specifications. Integration tests often operate at the level of user interfaces, clicking buttons, entering text, submitting forms, and verifying that the expected feedback always occurs. Integration tests are good for ensuring that important tasks that users will perform are correct.

benefit of cloud providers

agility, scalability, cost, reliability, security

which of the following are binary compatible: -adding a non-API package -deleting a non-API package - Adding a class or interference to a non-API package

all

statelessness is a core architectural constraint for

all REST based systems

which steps from changing code to deployment can be automated?

all besides changing the code, so get code & dependencies, build, run tests, deploy

how does high coupling look like in a class diagram?

all classes connected, every class know about all the other classes

system test

an integration test of an entire system or independent subsystem also security testing, stress testing, performance testing

Static Analysis

analysis of a program by examining it, but without running it These tools read programs and identify potential defects using formal proofs. typically result in a set of warnings, each one requiring inspection by a developer to verify, since some of the warnings may be false positives compiler is also static analysis tool

refactoring

application does what is supposed to do, but is lacking the how - the non-functional quality attributes of the system "disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior"

smoke test

application is tested to ensure a minimum level of functionality, to qualify the application for more-advanced forms of testing. subset of integration test

Microservices

approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API components: services connectors: network protocols benefits: independently deployable, easier to scale drawbacks: additional complexity of deployment/oeration, testing service interaction is more difficult, increased memory consumption

Classes with low cohesion

are responsible for a wide variety of tasks. harder to reason about as they often have many competing concerns within the implementation that might conflict. Can cause maintenance problems because changes to fix one defect within a class might be by design for another feature of the class

upside of MVP

changes the performance, increases testability

conventions regarding class and method names

class names singular nouns or doers, start with capital letter method names verbs, actions or isX checks, start with lowercase letters, camelCase

magic number

code smell your code uses a number that has a certain meaning problem: meaning will be forgotten any use of an actual number actually

unit test suite contains

collection of tests for the project, sometimes broken down by component (like tests for a particular class)

libraries defiinition

components that are linked into a program and called using in-memory function calls

software architecture defines

components, connectors, configurations

Composite pattern

compose objects into tree structures. lets clients treat individual objects and compositions uniformly At the heart of this pattern is the ability for a client to perform operations on an object without needing to know that there are many objects inside "Menus that contain menu items, each of which could be a menu."

Margret Hamilton

computer scientist who was director of software engineering division of the MIT Instrumentation laboratory. Key project was developing the on-board flight software for the Apollo space program. She led the development of error detection and recovery among other things whole managing team of computer scientists who helped. As part of this project many central problems and software engineering began to emerge, incl. verification of code, coordination of teams, managing versions.

What enables the statelessness property of a REST based system?

connectedness

core principles of web content accessibility guidelines WCAG or ISO 40500 or EN 301 549

content needs to be perceivable (so people can see or hear content) operable (people can use it by typing or voice) understandable (clear language) robust (so people can use different assistive technologies)

what does CD refer to?

continuous delivery or deployment both are about automating further stages of the pipeline

what does CI refer to

continuous integration

tool to help evaluating whether we have path/branch/ statement coverage

control flow graph

What parts of an MVC are easy to unit test?

controller and model

software maintenance categories

corrective adaptive perfective preventative

How to measure coupling or cohesion

coupling: by saying how many Classes a class depend on cohesion: harder to measure, evt. by using natural language processing to see if functions are similar

one of the challenges with automating deployment

cut-over taking software from final stage of testing to live production need to do quickly to minimize down time

Authoring Tool Accessibility Guidelines (ATAG)

defines requirements for content management systems, code editors and other software

User Agent Accessibility Guidelines (UAAG)

defines requirements for web browsers and media players

refactoring tools

degree of support depends on the language and is generally best for statically typed languages (like Java and C#). in practice the most commonly used refactoring tool is for rename refactoring; most other refactorings end up being undertaken manually (due to a lack of knowledge about tools, but often because of the perception that the tools do not actually save that much time).

biggest advantage of IaaS, PaaS, SaaS or any 'as a service' solution

economic customer can access and scale the IT capabilities it needs for a predictable cost, without the expense and overhead of purchasing and maintaining everything in its own data center. But there are additional advantages specific to each of these solutions.

Effectiveness vs. Efficiency

effectiveness is whether users can complete their goals with a high degree of accuracy (example:fixing a credit card field so that it only accepts a valid credit card number entry can reduce data entry errors and help users perform their tasks correctly) Efficiency is all about speed

System tests typically run faster than unit tests.[True/False]

false

True or false: The more requirements we have for a system, the better.

false

In Red Green Refactor, we first write the failing test case, then we refactor and extend the code, and finally we create the implementation to make the test pass. true/false

false, we don't refactor in between

Y2K Scare

fear that on jan 1, 2000 we would have electrical, water failure and food shortage, thought computers couldnt put 2000 in

steps of decomposing user-stories

find entities (nouns) link entities bind actions (verbs) prototyping (step through a scenario) formalize implement

Does an increase in the number of interfaces also lead to an increase of coupling?

generally no, you should only depend on what you need

most commonly used access methods for parameterizing the requests from the client to the REST service

get, put, post, delete

goals and not-goals while testing

goals: to ensure out code implements its specification - to try to find defects in out implementation - to understand where we can expect to have found defects not goals: to ensure our system is bug-free (key constraint: time)

long method smell

goes against single responsibility principle fitting the code on one screen is a simple rule of thumb extract method refactorings are often used to split up these methods, as could extract class if functionality is to be delegated to another class

othering

happens when we categorize people based on some features, such as gender or ethnicity, and distinguish groups that we belong (ingroup) and don't belong (outgroup). We see ingroup people positively and outgroup people negatively, because we want to have a positive self-image.

what to favour in API design

immutability private classes

Why should we favour composition over inheritance?

makes code more dynamic at runtime and makes it easier to add new features subtypes in an inheritance relationship are more tightly coupled to their superclasses than classes that are coupled through composition

Long parameter list smell

methods with many parameters are hard to understand and are again often symptomatic of code that is doing too much. These methods can either be split, or one can introduce parameter object to better capture and enforce the parameters for the method.

does adding an unchecked exception thrown to an API method break binary compatibility?

no (if checked, not binary compatible because catch must be implemented)

what is the problem with testing?

no amount of testing can prove a program correct with respect to its specifications. Why? It boils down to the same limitations that exist in science: with empiricism, we can provide evidence that a program does have defects, but we can't provide complete evidence that a program doesn't have defects. This is because even simple programs can execute in a infinite number of different ways.

Should the presenter have dependencies on user interface components?

no, bcs presenter needs to be easy to test

does coverage ensure correct code?

no, it only executes system. => assertions check behaviours

are rewrites and refactors strategies to improve the functionality of an application?

no. fixing defects, delivering new features, cleaning up user interface are enhancements

testing control flow paths

notion of coverage is executing all possible control flow paths trough the various conditionals in your program

inputs to always check in your tests

null and undefined

code review/inspection

reading the program analytically, following the control and data flow inside the code to look for defects. This can be done alone, in groups, and even included as part of process of integrating changes, to verify them before they are committed to a branch. Modern code reviews, while informal, help find defects, stimulate knowledge transfer between developers, increase team awareness, and help identify alternative implementations that can improve quality

benefits of canary release

rolling back is easy can combine with Alpha/Beta testing can check if you meet capacity requirements gradually ramping up the load

What does IaaS provide?

servers, storage capacity and networking resources - that customers can provision, configure and use in much the same way as they use on-premises hardware you can choose between VMs and or physical hardware

continuous delivery

solves problem of poor visibility & communication between dev and business team devs changes are automatically bug tested an uploaded to repository where they can be deployed to live production environment by operations team goal is to always have codebase that is ready for deployment to productive environment

defect

some subset of a program's code that exhibits behaviour that violates a program's specifications For example, if a program was supposed to sort a list of numbers in increasing order and print it to a console, but a flipped inequality in the sorting algorithm made it sort them in decreasing order, the flipped inequality is the defect.

What pattern should we look into if the decorated behaviours start to become heavy weight

strategy pattern

The different design patterns in MVC

strategy pattern in the controller composite pattern for nested views observer , model&view interact through observer pattern

strategy vs state pattern

strategy static, state dynamic Strategy pattern is really about having a different implementation that accomplishes (basically) the same thing, so that one implementation can replace the other as the strategy requires. For example, you might have different sorting algorithms in a strategy pattern. state pattern actually changes behaviour depending on state

software architecture encompasses

structure, behaviour, non-functional properties

cognitive bias

systematic pattern of deviation from norm or rationality in judgement -based on information we have, perceive to have or lack -"mental shortcuts the human brain produces to quickly help it make sense of what it is seeing" -may lead to perceptual distortion, inaccurate judgement, illogical interpretation and severe and systematic errors

what challenges come up in Software Engineering?

technical and interpersonal ones

rule of three

to avoid extraneous refactorings is to think about the 'rule of three'. This says that the first time you add a new feature you just do it the simplest way you can. The second time you need to make the same kind of change you do it again (but you cry inside and make a mental note of the duplicate change). The third time you encounter the same change you refactor.

MVP and MVVM

two more recent modifications to MVC increasingly common in practice as they provide enhanced testability decrease the amount of boilerplate code required in web and mobile application development

unit vs system test

unit tests can give false sense of security, we need system tests to know that it is meaningful for the user

usability vs. utility

usability is how easy is it to use utility is how useful something is

Usability vs User Experience

usability of a product is a crucial part that shapes its UX, and hence falls under the umbrella of UX

assertions

used in white and black box testing what are the specifications, the rules, (example: what is the car is supposed to do when this happens? and to assertion with what really happens)

Github Actions

used to help automate software development workflows from within GitHub scripts for example whenever someone commits or pulls

usability is the outcome of

user-centered design

how do rest based services communicate

using intermediate representations like JSON, HTML, XML

difference statement coverage / line coverage

usually one statement per line but you can also have multiple statements in one line

bug

vaguely refers to either the defect, the failure, or both. When we say "bug", we're not being very precise, but it is a popular shorthand for a defect and everything it causesA bug vaguely refers to either the defect, the failure, or both. When we say "bug", we're not being very precise, but it is a popular shorthand for a defect and everything it causes

Regression tests

verify that behavior that previously worked doesn't stop working. not new test, repetition of existing tests important not to write "throwaway tests"

Unit tests

verify that functions return the correct output They're good for ensuring widely used low-level functionality is correct

Properties of API usability

visibility (possible actions and states must be exposed) conceptual model (helpful, consistent and complete abstractions clarify the correct model of the system) mapping between action and results feedback about results of actions

equivalence class partitioning (output class partitioning)

we look at expected outputs instead at parameters being passed into function write test cases to make sure that range of outputs expected to see

deployment

what happens when you install some version of your software into a particular environment

divergent change

when making changes to a class, you have to change many unrelated methods

release

when you make a system part or a part of it (for example feature) available for users

can we have 100% line coverage but still have defects?

yes

does changing API method from public to protected break binary compatibility?

yes

should global and content coupling be avoided completely?

yes

Should we write comments in bug reports, if developers have a mean of communicating face-to-face?

yes, important to provide a way of documenting the history of the development process and rationale

Do the low-level design guidelines overlap with the high-level design principles?

yes, very much

disadvantage singleton

you access singleton through static get instance method, static makes it harder for system to evolve singleton makes it hard to test code

abstract class vs class

you can't instantiate an abstract class, you have to extend it to implement the abstract parts of the abstract class


Related study sets

Methods of Instruction for Students with Disabilities

View Set

Personal Finance Midterm Chapters 1-6

View Set

CLC - Managerial Accounting Exam 2 (ch.6)

View Set

Chapter 6 - Protein: Amino Acids

View Set