TU Wien:Advanced Software Engineering VO (Bernhart Strobl Mordinyi)/Fragenkatalog

Aus VoWi
Zur Navigation springen Zur Suche springen

Eine Sammlung aller noch relevanten Prüfungsfragen.

Stand: WS22

Compare manual and automatic master node election! Benefits/Drawbacks? (in 15.03.2023 exam, Lecture From prototype to product WS22)[Bearbeiten | Quelltext bearbeiten]

  • Used/needed for
    • Ensuring something is executed only once (e.g. scheduled job)
    • Ensuring messages are handled in correct order
    • Have one node to mediate or delegate
  • Automatic master node election is difficult to get right (unless you have a single resource to sync on)
    • ... and has some ugly constraints (split brain for example)
  • Manual master node election
    • Might result in down time
    • Possibility of human error

Local vs Global Explanation (Explainable Machine Learning lecture WS22)[Bearbeiten | Quelltext bearbeiten]

Explanation: Is a description of the model behavior. (explain how the model comes to a conclusion (with eg use of counterfactuals)) Global: Understand and explaining the whole model behavior, big picture biases; help to check at a high level if a model is suitable. Local: explain individual predictions, biases in a local neighborhood of given instance

What are counterfactuals, and what could they look like? (Possible exam questions for lecture on Explainable Machine Learning according to lecturer)[Bearbeiten | Quelltext bearbeiten]

Example: You broke your leg on a rainy day because you slipped. Counterfactual: It was not rainy Would you still have slipped and broken your leg?

Counterfactual: Alternate World where prior circumstances were changed to see what the consequences of this change would be. Counterfactuals in Explanation: If you had called class X instead of Y, your code would not be classified as a performance regression.

What is meant by Technical Debts? Name three examples of technical debts and their possible causes[Bearbeiten | Quelltext bearbeiten]

Technical debts are created when a developer opts for a faster solution instead of a more sustainable, readable, maintainable one.


  • no documentation of the architecture
    • possible cause: the customer didn't want to pay for it, so no documentation has been created
  • bad modularization or architecture
    • possible cause: the development team didn't have enough skills or experience when they created the software
  • a lot of TODOs in the code base
    • possible cause: the developers were under time pressure and decided to implement a "quick & dirty" solution and refactor it later

Explain the n+1 queries problem! How can it be avoided?[Bearbeiten | Quelltext bearbeiten]

Imagine a database where you have 2 row Cars, And Wheels.

Every car references a Wheel (Car -> Wheel (one to many)). Now print all cars with their wheels

Native Approach Get all cars: “SELECT * FROM Cars;” Then get the wheels for every car: “SELECT * FROM Wheel WHERE CarId = ?” This requires n+1 queries to the database!

Alternative Approach Get all cars “SELECT * FROM Cars;” Get all wheels “SELECT * FROM Wheel” Perform lookup in memory This requires 2 queries to the database

How can it be avoided: Better Queries or eager loading! (load references in the “SELECT * FROM Cars;” queries (join))

What is the Github dilemma?[Bearbeiten | Quelltext bearbeiten]

  • When copying code from Github that has no explicit license it is not clear if it can be used or not (US / Europe)

List and explain three empirical study types (prob. outdated)[Bearbeiten | Quelltext bearbeiten]

  • Controlled Experiments:
    • Measuring the effects of one or more variable(s) on other variable(s).
    • Detailed investigation in controlled conditions (relevant variables can be manipulated directly, precisely and systematically).
    • Example: Traditional (paper-based) reviews vs. tool-supported reviews.
  • Case Studies:
    • Development of detailed, intensive knowledge about a single case or of a small number of related cases.
    • Detailed investigation in typical conditions.
    • Example: Investigating effects in Scrum projects in SMEs.
  • Surveys:
    • Collection of information in standardized form within groups of people or projects.
    • The use of a technique/tool has already taken place; relationships and outcomes should be documented.
    • Example: Investigate challenges in context of requirements engineering.

What are cross-cutting concerns, why should they be decoupled from businesslogic?[Bearbeiten | Quelltext bearbeiten]

  • Cross-cutting concerns are the functions that span multiple points of an application.
  • Cross-cutting concerns are conceptually separate from the application’s business logic
  • Handling cross-cutting concerns separately from your business logic is a major factor for retaining clean, readable code

Name 5 FOSS (Free and Open Source Software) business models.[Bearbeiten | Quelltext bearbeiten]

  1. Sell services: Customization, Integration, Training and Documentation (e.g. books)
  2. Sell extensions/components/features
  3. Forking (commercial) and porting-back with delay
  4. Forking (commercial) and financing maintenance
  5. Dual License models
  6. Publicity for other software or services
  7. Person publicity of the author and career opportunities
  8. Sponsorship and donations
  9. Academic research
  • Professional services (support, training)
  • Selling Merch
  • Software as a service (subscription fees)
  • Donations and Crowdsourcing
  • Delayed open-sourcing

Name 3 ways to monetize FLOSS and also 3 things to avoid while doing so.[Bearbeiten | Quelltext bearbeiten]

For ways to monetize, see previous question

  • Don't try to sell the same product you give away for free
  • Respect the freedom!
    • Don't force/restrict others to do something only because you need it
    • Respect the community
  • Don't rely (only) on a payroll
    • don't push a project into one corner just because a customer likes it that way
  • OSS project planing is different than company projects

Name 6 CI principles according to Martin Fowler.[Bearbeiten | Quelltext bearbeiten]

  1. Maintain a code repository
  2. Everyone commits to the baseline every day
  3. Automate the build
  4. Every commit (to baseline) should be built
  5. Keep the build fast
  6. Make the build self-testing
  7. Test in a clone of the production environment
  8. Everyone can see the results of the latest build
  9. Make it easy to get the latest deliverables
  10. Automate deployment


Explain configuration management. Name three main types of CM.[Bearbeiten | Quelltext bearbeiten]

"Configuration Management ... is a management process for establishing and maintaining consistency of a product's performance, its functional and physical attributes, with its requirements, design and operational information, throughout its life."

  1. Build configuration
  2. Product configuration
  3. Application server/database configuration
  4. OS configuration
  5. System configuration

Name and explain one reason for software aging, what problem it creates and preventive measures.[Bearbeiten | Quelltext bearbeiten]

  1. Lack of movement: Failure to modify the product to meet changing needs
  2. Ignorant surgery: Result of the changes that are made

Problems during lifecycle[Bearbeiten | Quelltext bearbeiten]

  • Inability to keep up (growth)
  • Reduced performance (poor design)
  • Decreasing reliability (error injection)

Preventive measures[Bearbeiten | Quelltext bearbeiten]

  • Design and plan for change
  • Documentation and Review
  • Restructuring including partial replacement
  • Plan for retirement and replacement

Compare Build Time Modularization and Runtime Modularization. Name a tool for each of them.[Bearbeiten | Quelltext bearbeiten]

Build Time[Bearbeiten | Quelltext bearbeiten]

  • Multiple JARs possible
  • Single bundle
  • Update requires complete redeploy
  • Easy operation
  • Easy & fast intermodule communication

Tool: Maven

Runtime modularization[Bearbeiten | Quelltext bearbeiten]

  • Multiple JARs required
  • Multiple Bundles
  • Update requires partial redeploy
  • Medium complex operation (single VM), highly complex operation (multi VM)
  • More complex but fast inter-module communication (single VM), complex and possibly slow inter-module communication (multi VM)

Tool: OSGI

Explain dependency injection by the help of a diagram.[Bearbeiten | Quelltext bearbeiten]

Dependency Injection is a pattern, where the gluing of objects is separated from the implementation. Therefore all implementation is against the API. There is a central definition and container that creates and binds objects together.

DI supports code reuse and independently testing classes. DI supports different bindings for different environments. DI supports lazy creation of objects.

A DI framework (often based on AOP) provides the runtime services for DI (e.g. Spring Framework).

"Dependency injection is basically providing the objects that an object needs (its dependencies) instead of having it construct them itself. It's a very useful technique for testing, since it allows dependencies to be mocked or stubbed out.

Dependencies can be injected into objects by many means (such as constructor injection or setter injection). One can even use specialized dependency injection frameworks (e.g. Spring) to do that, but they certainly aren't required. You don't need those frameworks to have dependency injection. Instantiating and passing objects (dependencies) explicitly is just as good an injection as injection by framework." [StackOverflow]

Sie wollen wohl eher das vom MesSEias Martin Fowler

What is the idea behind the DevOps Movement?[Bearbeiten | Quelltext bearbeiten]

The DevOps movement is a philosophical idea where traditional boundaries between development and operations are removed. It is more about breaking down walls than classic "who does what". It is not about who does it, but when and how it is done. It is about considering operations from the beginning. It is about knowing how "the other side" works. It is about facilitating communication!

What are two means against threats of dependability, explain them.[Bearbeiten | Quelltext bearbeiten]

  1. Fault prevention: Quality control, software design (i.e. structured programming, information hiding, modularization)
  2. Fault tolerance: Error detection and subsequent system recovery, error handling (roll-back vs. roll-forward), redundancy (fault masking, voting algorithms, ...), fault isolation.
  3. Fault removal: Verification (static, dynamic), diagnosis, correction, Fault injection (e.g. to test the error handling), corrective and preventive maintenance
  4. Fault forecasting: Qualitative (identify, classify, rank), quantitative (probability model, stochastic)

What do patterns and anti patterns have in common, what are their differences? (prob. outdated)[Bearbeiten | Quelltext bearbeiten]

Both patterns and anti patterns are commonly used solutions to problems in a specific context.

A pattern is a solution which generates positive consequences.

An anti-pattern is a solution which generates bad consequences.

Name 3 software project management anti patterns and explain one of them in detail. (not in WS2018) (prob. outdated)[Bearbeiten | Quelltext bearbeiten]

  1. Analysis paralysis: The problem scope is analyzed until it is fully understood in every minor detail without making decisions or taking actions. This prohibits delivery or at least postpones it significantly. A refactored solution is to use incremental development. Details of problem and solution will be learned in the process.
  2. Death by planning: Most of the time is spent on reporting to management and sticking to a cost plan instead of actually developing. Refactored solution: Define deliverables (products: sold to customers, components: technology artefacts), validation milestones, continuous update of the plan (e.g. weekly).
  3. Smoke and mirrors: Management makes commitments to the customer beyond organizational capabilities. Development is under pressure to deliver, the end user does not receive as promised. Refactored solution: Management of end user expectations.
  4. Fire drill: Months of monotony followed by demands for immediate delivery. Refactored solution: Limit the frequency of fire drills to real emergencies.

Name 3 success and 3 risk factors for collective intelligence.[Bearbeiten | Quelltext bearbeiten]


  1. Choosing the right type of CIS.
  2. Appropriate set of CI design patterns.
  3. Provide low friction, easy to use means on contributing content.
  4. Effective feedback mechanism, which make users aware about activities of other users.


  1. If CIS is not well integrated in users' workflow routine, the CIS will not be used.
  2. Focusing more on the software side, and neglecting the user base side.
  3. Cannibalization of user activity by other CIS.
  4. Handling of security and privacy of user data.

2 advantages and disadvantages of centralized CIS and also for decentralized CIS.[Bearbeiten | Quelltext bearbeiten]


  1. Pro: Constant quality of service for all participants.
  2. Pro: Data is stored in one place.
  3. Pro: More resources for system maintenance, data security, platform evolution.
  4. Pro: Single point of access.
  5. Pro: Effective information exchange due to very-large scale user base.
  1. Con: Single point of failure.
  2. Con: Prone to censorship and systematic infiltration by government organizations.
  3. Con: Often closed/proprietary system source code.
  4. Con: Lots of influence concentrated in a single organization


  1. Pro: Multiple points of access.
  2. Pro: Robust: infiltration only of individual points; easy hosting of new nodes.
  3. Pro: Often system source code is open source (= auditable)
  4. Pro: Easier to operate on non-profit basis due to lower resource needs of individual nodes.
  1. Con: Quality of service dependent on individual node.
  2. Con: Each node is responsible for its maintenance and data security.
  3. Con: Less effective information exchange due to fragmentation of user base.
  4. Con: User contributions are stored on an individual node.

Name 5 CI (Collective Intelligence) design patterns and explain their solutions.[Bearbeiten | Quelltext bearbeiten]

  1. Tagging: Enables users to categorize content on their own using keywords.
  2. Rating: Enables users to express their like or dislike about the content so that other users can benefit.
  3. Comments: Enable users to express their own opinion to a topic and encourages discussions with others.
  4. Hashtags: Enables users to add keywords/tags using # symbol among text to facilitate discoverability later.
  5. Recommendations: Seek to predict content the user might be interested in based on the other users' behavior and decisions.
  6. Generated lists: Enable users to get fast status overview of trending topics and news.
  7. Follow/subscribe: Enable users to define specific content they are interested in and that they would like to monitor.
  8. Activity indicator: Enables users to assess how relevant the content is based on other users' actions.
  9. User-generated Collections: enable users to create their own collections of curated content and to provide them other users

Three Human fauls that can make a Project fail. (prob. outdated)[Bearbeiten | Quelltext bearbeiten]

1. Poor Preparation : You need to have a clear picture of what you’re going to do, in advance – as much as possible. Otherwise, you may find yourself up stream without a paddle. You need to know what project success looks like at the beginning and don’t loose focus of it. Hence, if you don’t have a clear focus at the at the earliest stage of the process, you are making things harder on yourself. Have a meeting, even if it is lengthy, with stakeholders to discuss their expectations on cost, time and product quality. Know how you will execute your tasks in order to meet everyone’s expectations.

2. Inadequate Documentation and Tracking : This is the responsibility of the project manager. Tracking milestones is how you are going to know whether you are meeting expectations. Proper recording and monitoring lets the PM identify where more resources are needed to complete a project on time.

3. Bad Leadership : When we see this word, leader, we usually think, the project manager. However, the people at each management-level have a responsible to ensure that the project is successful. Management should not micromanage but provide support to ensure that the PM can follow through with the expectations placed upon them.

4. Failure to Define Parameters and Enforce Them : When you’re a leader, PM, it’s imperative that you’re able to work well with your team. If and when tasks or goals are not met to standard, there should be ramifications. Rank tasks by priority and assign them to the most proficient individual.

5. Inexperienced Project Managers : A project manager has a lot of responsibility. You need to assign people to management roles who have matching education and experience. In some cases, and perhaps more often than not, inexperienced managers are given projects. They may be very capable of managing projects, but the key is to keep them at a level where they can succeed. Otherwise, you will set them up for failure. On the other hand, there’s nothing wrong with a challenge, just don’t make it beyond their reach.

Four steps of build release, when is it recommended, when necessary?[Bearbeiten | Quelltext bearbeiten]

Always build the full project after every commit


  1. Execute tests
  2. Create VCS tag
  3. Publish build artifacts
  4. Update version in repository

Three qualities of a software engineer, explain them. (not in WS2018) (prob. outdated)[Bearbeiten | Quelltext bearbeiten]

(I'm not sure about those. I've tried to extract the answers from ASE-VO-Lecture7-Software_Development_in_Startups.pdf.)

  1. Personal Excellence
    • Experience to come up with solutions and ideas for a new problem.
    • Process to tackle any new problem.
    • Ability to ship high quality software quickly.
  2. Working with and understanding people
    • Software engineering is a teamsport
    • Motivations: Why is somebody choosing a technology or direction?
    • Wants: What do they want to gain out of this project? What is the direction they are going into next in their career?
    • Needs: What do they need to be successful? How can you help them become successful?
    • Leadership is not getting what you want, but helping the team hit the goal.
  3. Connecting business and technology
    • Short and concise arguments in writing or verbal (really key for getting your point across easily)
    • Talk to your co-workers regularly how they feel, what they are looking for and what things they have planned in their future
    • Understanding of the key business metrics and how you can help meeting the goals of the company. Ask your Boss about this, be engaged

Three agile principles of the agile manifesto[Bearbeiten | Quelltext bearbeiten]

  1. Individuals and interactions ... over processes and tools.
  2. Working software ... over comprehensive documentation.
  3. Customer collaboration ... over contract negotiation.
  4. Responding to change ... over following a plan.

3 Exception Handling Anti-Patterns[Bearbeiten | Quelltext bearbeiten]

  1. Log an exception and rethrow it: Do either one of them.
  2. Catch "Exception" (i.e. all exceptions, not one in particular): It's like a fisher's net - you do not know what you will catch.
  3. Destructive wrapping: Always pass the causing exception.
  4. Catch and ignore: This one will come back to bite YOU.
  5. Throw from within finally: Will swallow any other exception.

Explain firedrill or golden hammer anti-pattern symptoms and refactoring solutions. (prob. outdated)[Bearbeiten | Quelltext bearbeiten]

  • Fire drill: Months of monotony followed by demands for immediate delivery. Refactored solution: Limit the frequency of fire drills to real emergencies.
  • Golden hammer: Universally applicable technology that solves all problems (in any context) without drawbacks. Same tools are used for a set of diverse products. Refactored solution: Expanding the knowledge of developers and commiting to exploring new technologies. Always choose your tooling according to your use case.

What is the Exception Translation Pattern, when to use it, why use it?[Bearbeiten | Quelltext bearbeiten]

Do not expose "lower level" exceptions to upper layers of code to avoid "API bleeding". If exception cannot be handled at the current stage, wrap it in a module specific exception.

try {
} catch (LowerLevelException e) {
    throw new MyBusinessException("message", e);

Difference between sampling and tracing in performance profiling[Bearbeiten | Quelltext bearbeiten]


  • Usually done through byte code instrumentation. Delivers invocation counts. Can significantly influence runtime performance. Not suitable for production environments.


  • Periodically queries stacks of running threads to estimate the slowest parts of the code. No invocation counts. Negligible performance impact.

Name and describe 4 properties of dependable software[Bearbeiten | Quelltext bearbeiten]

  1. Confidentiality - Absence of unauthorized disclosure of information
  2. Integrity - Absence of improper system alterations
  3. Availability - Readiness for correct service
  4. Reliability - Continuity of correct service
  5. Safety - Absence of catastrophic consequences on the users and environment
  6. Maintainability - Ability to undergo repair and modification

Name and describe 4 properties of FOSS according to Bruce Perens (not in WS2018) (prob. outdated)[Bearbeiten | Quelltext bearbeiten]

  1. Free Redistribution
  2. Source code
  3. Derived works: allow modifications and derived works
  4. Integrity of the author's source code: the license may restrict source code from being distributed in modified form only if the license allows the distribution of patch files with the purpose of modifying the program at build time.
  5. No discrimination against persons or groups
  6. No discrimination against fields of endeavor: no restriction against making use of the program in a specific field
  7. Distribution of the license: The rights attached to the program must apply to all to whom the program is redistributed.
  8. License must not be specific to a product: Rights attached must not depend on the program's being part of a particular software distribution.
  9. License must not restrict other software
  10. License must be technology-neutral

Describe Kanban (with drawing). What's the difference between Kanban and Scrum.[Bearbeiten | Quelltext bearbeiten]

  • Kanban is flow oriented and does not force a time frame like Scrum does with sprints.
  • Kanban does not require specific roles like Scrum with Project owner, Product owner etc.
  • Prioritization and changes in a project can be done on-demand in Kanban, Scrum discourages significantly changing a sprint.

Focus on flow, avoding bottlenecks. Visualisation of current process flow and activities. Real-time metrics.

Kanban vs. Scrum:

  • Kanban: No different roles. Scrum: each team member has a predefined role
  • Kanban: Continuous delivery. Scrum: deliverables are defined by a sprint
  • Kanban: best for projects with widely varying priorities. Scrum: best for teams with stable priorities that don't change much over time.

Name two setup approaches of CI. Name 4 tools used in CI[Bearbeiten | Quelltext bearbeiten]

  • Enterprise (self hosted): on premise, high cost of entry, full control & flexibility
  • Cloud: externally hosted, easy setup, good scalability, source code leaves network

Hudson/Jenkins, Apache Continuum, CruiseControl, Atlassian Bamboo, Travis CI, CircleCI, Gitlab CI

Difference between Design Pattern and Idiom? Is the Factory Pattern implemented in Java a pattern or an idiom? Argue why (not in WS2018) (prob. outdated)[Bearbeiten | Quelltext bearbeiten]

Design patterns: Describe the structure and relations at the level of classes

Idioms: Focus on low-level details, programming language specific.

Factory Pattern: Creational design pattern

Describe the Cathedral and the Bazaar model (free software development) and give an example project for each (not in WS2018) (prob. outdated)[Bearbeiten | Quelltext bearbeiten]

  • Cathedral: Source code is open sourced with each release, but code developed between releases is restricted to an exclusive group of software developers (e.g. GCC, Android)
  • Bazaar: Source code is open source during the development phase (e.g. Linux)

PubSubHubbub (now called WebSub) (prob. outdated)[Bearbeiten | Quelltext bearbeiten]

Protocol for server-to-server, webhook-based publish/subscribe for web resources.

Used to provide real-time updates via pushed HTTP notifications.

3 Concepts: Publishers, Subscribers and Hubs.


  1. Hubs can be run by publishers or 3rd parties (e.g. Google)
  2. Publisher provides topic URL to hub server
  3. Subscribers subscribe to hub (instead of publisher)
  4. Hub multicasts publisher updates to registered subscribers

Has been adopted by w3c and renamed to "PubSub" (2016-09-23) and later renamed to WebSub (2016-11-18) [1]

Big benefit if you hit a bug in FOSS[Bearbeiten | Quelltext bearbeiten]

You don't need workarounds in your own code, instead you can fix bugs directly in the OSS libraries you use.

What is localization, internationalization. Main difference? What are typical focus points?[Bearbeiten | Quelltext bearbeiten]


  • preparation of the program so that it can use different languages, text layout, and other cultural things
  • usually done only once


  • when a concrete local is implemented in a program (should not be a problem if the program was designed with internationalization in mind)

Focus Points

  • Language & Text
    • char encoding, orientation. sorting, pluralization, collation
  • Culture
    • Name titles, measurements, addresses
  • Conventions
    • timezone, currency, number format

Difference between role based and permission based authorization. Benefits of permission based?[Bearbeiten | Quelltext bearbeiten]

  • Role-based authorization is simple and easy to grasp but permission based authorization is more flexible.
  • Permission-based authorization can be much more fine-grained which can result in bigger administration costs.

Difference between Clustering and Load-Balancing? Name an example where they interweave. Name two modes each.[Bearbeiten | Quelltext bearbeiten]

Clustering means you run a program on several machines (nodes). One reason why you want to do this is: Load balancing. If you have too much load/ work to do for a single machine you can use a cluster of machines instead. A load balancer then can distribute the load over the nodes in the cluster.

Clustering vs. Load-Balancing

  • Different clustering modes, different implications
    • Application level clustering: full/delta session replication
    • Database level clustering
  • Load balancing
    • Sticky session
    • Round robin
    • Active/passive
    • Hardware vs. software
  • Trade-off between load distribution and fault tolerance
  • Always perform fail-over tests on your setup

Difference between re-licensing and sub-licensing.[Bearbeiten | Quelltext bearbeiten]

  • re-licensing: allows to change the license of all existing code
  • sub-licensing: allows adding your own code to the existing one in any license you like

Difference between logging and auditing.[Bearbeiten | Quelltext bearbeiten]

Logging is ephemeral and usually used for debugging or informational purposes, e.g. to understand how the system works or in what state the system is. The output is not suitable for automated processing.

Auditing is persistent and audit logs are kept also for compliance reasons. An audit log enables to see what actions users performed.

  • Technical, text based output primarily used for detecting and debugging problems
  • Level of detail can usually be configured at runtime
  • Output is not (easily) understandable for regular users of the system
  • Output is not suitable for automated processing
  • Short term retention (months)
  • Domain specific, fine grained and structured output for tracing user activity
  • Requirements are specified by legal and/or company specific policies
  • Used by (limited) end user group (e.g. internal revision)
  • Frequently coupled with long term retention requirements (e.g. 10+ years for regular businesses, 30+ for medical)

Name at least two common problems when keeping dependencies in a SCM?[Bearbeiten | Quelltext bearbeiten]

  • Difficult to (manually) find new libraries and updated versions
  • Loose trace to source (e.g. download page)
  • Loose version information (unless included in filename or package)
  • No information about transitive dependencies
  • SCM not built for versioning binaries (no diff, bad handling of binary files, high resource usage)
  • DSCM (e.g. Git) especially bad (by design) at working with large binaries

What does a tool like Sonatype Nexus manage? (prob. outdated)[Bearbeiten | Quelltext bearbeiten]

Nexus is a repository management tool. Alternatives are Apache ARchiva or jFrog Artifactory. A repository management tool manages all used third party dependencies and repositories. It manages all artifacts created by the project (binaries but also source, documentation, configuration). Central location for all artifacts ensures accessibility (and easy backup). No need to always build complete project.

What are threats of dependability / Difference error, fault and failure + an example to each of them[Bearbeiten | Quelltext bearbeiten]

  • Error - Discrepancy between a computed, observed or measured value or condition, and the true, specified, or theoretically correct value or condition. (e.g. null value when not valid)
  • Fault - Abnormal condition that can cause an element or an item to fail.(e.g. Uncaught NullPointerException)
  • Failure - Termination of the ability of an element, to perform a function as required. (e.g. Malfunction, nonfunction or crash of a service)

What is advanced in Software Engineering?[Bearbeiten | Quelltext bearbeiten]

Dependable software, large, complex, integrated software

Compare Human Based Computing and CIS, what are the differences, Name two types of CIS and an example for each.[Bearbeiten | Quelltext bearbeiten]

  • Human Based Computing utilizes human processing power to solve problems that computers cannot (yet) solve.
  • CIS harness the collective intelligence of connected groups of people by providing a web-based environment to share, distribute and retrieve topic-specific information.
  • Differences: In HBC the "humans serve the computation" and in CIS the "computation serves the human". Both are (more or less) driven by users who contribute.
  • Two types and examples: 1. Social Network Services (Twitter, Facebook), 2. Media/Content Sharing (Wikipedia, Youtube)

What is the idea behind aspect-oriented programming?[Bearbeiten | Quelltext bearbeiten]

  • The key unit of modularity in AOP is the aspect (as compared to the class in OOP)
  • AOP helps you decouple cross-cutting concerns from the objects that they affect
  • Aspects are "woven in" at compile time or run time

What are build pipelines?[Bearbeiten | Quelltext bearbeiten]

Logically structures a CI build into a series of steps. Information about CI configuration is stored alongside the code (e.g. .gitlab-ci.yml)

What is Scrum poker and what is the result of it/a turn (not sure which from both was asked)? (not in WS2018) (explained in the lecture in WS22)[Bearbeiten | Quelltext bearbeiten]

Scrum poker, is a consensus-based, gamified technique for estimating, mostly used to estimate effort or relative size of development goals in software development. In planning poker, members of the group make estimates by playing numbered cards face-down to the table, instead of speaking them aloud. The cards are revealed, and the estimates are then discussed. By hiding the figures in this way, the group can avoid the cognitive bias of anchoring, where the first number spoken aloud sets a precedent for subsequent estimates.

What is a software license and how does it matter?[Bearbeiten | Quelltext bearbeiten]

A software licence is a conglomerate of conditions under which a license gets to use code. It is consensual, and although it is juristically viewed not a contract, it is very close. It matters because it is a form of securing for your own code.

What is the core concept of a micro service? Name three challenges for developing.[Bearbeiten | Quelltext bearbeiten]

A microservice architecture is a method of developing software applications as a suite of independently deployable, small, modular services in which each service runs a unique process and communicates through a well-defined, light-weight mechanism to serve a business goal.

  • Are MicroServices really independent of each other?
  • How about versioning?
  • How to detect if a feature is unused?

Monoliths:[Bearbeiten | Quelltext bearbeiten]

  • extremely recursive inner dependencies
  • No clear separation of concerns
  • No clear inner design ("take whatever you need")
  • Not easy to scale
  • Hard to roll outs

What is the difference between a component and a service according to Fowler?[Bearbeiten | Quelltext bearbeiten]

  • A component is a glob of software that is intended to be used, without change, by an application that is out of the control of the writer(s) of the component. 'Without change' means that the using application does not change the source code of the component, although they may alter the component's behavior.
  • A Service is used by foreign application similar to a component.
  • The main difference is that a component is used locally (e.g. a JAR file, assembly file) and a service is used remotely through some interface, either synchronous or asynchronous.

When should which Transaction Management Type be used?[Bearbeiten | Quelltext bearbeiten]

Transaction Types depend on who is responsible for the Transaction:

  • Local Transaction Model: The underlying database handles the transaction (e.g. via auto commit)
  • Programmatic Transaction Model: The developer handles the transaction through code
  • Declarative Transaction Model or Container Managed Transactions: Developers only specify the behaviour, the application container handles the transaction.

How to choose:

  1. If running inside a suitable container, declarative transactions are usually the safest bet
  2. Completely managing transactions manually results in a lot of boiler-plate code and is error prone
  3. CMT makes automating tests hard(er) – an embedded container is necessary to provide a suitable environment

What are the differences between easy and simple? What are the differences between complex and complicated? Specify 2 examples for each of the 4 quadrants. (WS18)[Bearbeiten | Quelltext bearbeiten]

  • Simple: One Task, One Role, One Concept, One Dimension (Opposite is Complex)
  • Easy: Near at hand, familiar, near to our capabilities, relative (Opposite is Complicated)
    • Simple and Easy: Angry Birds, Mensch ärgere dich nicht, Ein Imbiss Stand
    • Simple and Complicated: Flugverkehr, Raumsonde, Spieleuhr, Auto, Persistenz
    • Easy and Complex: Schach, MMORPG
    • Complex and Complicated: Internet, Finanzsystem, Ökosystem, Mensch

Explain semantic version and the connection to backwards compatibility[Bearbeiten | Quelltext bearbeiten]

For software with public API

  • X – major version must be incremented if any backward incompatible changes are introduced to the public API
  • Y – minor version must be incremented if new backwards compatible functionality is introduced to the public API
  • Z - patch version must be incremented if only backward compatible bug fixes are introduced

Name two types of CIS, and for each 3 examples[Bearbeiten | Quelltext bearbeiten]

  • Social network services – twitter, Facebook, LinkedIn, Instagram
  • Media/content sharing – YouTube, SoundCloud, Flickr
  • Knowledge creation – Wikipedia, Yelp, Stack Overflow

Name and describe 4 naming conventions, that help maintaining clean code[Bearbeiten | Quelltext bearbeiten]

  • choose descriptive (long) and unambiguous names over short names
  • use precise names for small classes over generic names for large classes
  • clarity is king
  • length of name should correspond to the size of its scope
  • make meaningful distinctions
  • use pronounceable names
  • use searchable names
  • replace magic numbers with named constants
  • avoid encodings – don’t append prefixes or type information
  • clarity is king
  • if you need a comment then you’re doing something wrong

Name and describe 4 advantages and disadvantages of microservices, compared to a monolith[Bearbeiten | Quelltext bearbeiten]

What are wicked problems?[Bearbeiten | Quelltext bearbeiten]

  • No definitive formulation of a wicked problem
    • No simple test
    • No enumerable set of solutions
  • There is no stopping rule or simple true/false solution
    • Solution stopped when resources run out
    • Solution stopped when good enough or better than before
  • Every wicked problem is unique
    • Not open to trial and error
    • One-shot operation
  • Wicked problems extend laterally and vertically
    • Seen as a symptom of another problem (vertical)
    • Described in different ways (horizontal) leads to different solution approaches

What is the "open-closed-principle"?[Bearbeiten | Quelltext bearbeiten]

classes should be open for extension – closed for modification

Explain dependability and name all attributes[Bearbeiten | Quelltext bearbeiten]

Dependability is an integrative concept that encompasses the following attributes:

  • availability: readiness for correct service
  • reliability: continuity of correct service
  • safety: absence of catastrophic consequences on the user(s) and the environment
  • confidentiality: absence of unauthorized disclosure of information
  • integrity: absence of improper system state alterations
  • maintainability: ability to undergo repairs and modifications

Explain the difference between authentication and authorization and name two examples for each one[Bearbeiten | Quelltext bearbeiten]

Authentication – process of verifying who someone is

  • Username – password
    • Easiest to implement & use
    • Most wide-spread
    • Increasingly insecure
  • Certificate based (client authentication)
    • Complex to roll out & manage
    • Used in high security environments
  • Smart card, biometric
    • Needs client-side support
  • Token based / Single Sign On (SSO)
    • SAML, OAUTH 2.0, OpenID Connect

Authorization – process of verifying what specific data, methods a user has access to

  • Role based access control (RBAC)
    • Used for resource-based systems
    • Simple and easy to grasp
  • Permission based
    • Flexible (more than role based)
    • Simple action based
    • Complex expressions
    • Can be much more fine-grained  result in bigger administration costs
  • Access control lists (ACL)
    • Delivers fine grained control on an object / instance level
  • Rule based
    • Suitable for complicated and frequently changing business requirements

Authorization – What to choose?

  • Permission / role based: simple security requirements
    • Easy to govern
    • Well supported by standard technologies
    • Performance implications minimal
  • ACLs / rules: complex
    • Complex to maintain
    • Complexity needed
    • Significant performance implications possible

Explain patent grant (licenses) and name two examples[Bearbeiten | Quelltext bearbeiten]

A patent gives its owner the right to exclude others from making, using and selling the claimed invention. In contrast open-source licenses grant broad rights to modify, compile, distribute and use the software

  • Some licences contain a patent grant
    • Apache Licence v 2.0 (ALv2)
    • Gnu Public Licence v3.0 (GPLv3)
    • Mozilla Public License v1.1 (MPL)
  • Software patents not allowed in EU! Only in US
  • Patents registered as a defence weapon

Name four aspects of naming (clean code)[Bearbeiten | Quelltext bearbeiten]

  • Choose descriptive names for variables and functions (long > short)
  • Avoid to use comments -> refactor instead
  • Try to make it as clear as possible
  • Use more classes with precise naming instead of creating a large one with a generic name