Software Architecture Exam

Question 1

Define rigidity design smell.

Answer 1

It is characterized by resistance to change.

Even small changes are difficult.

For example large number of global vars and a lot of dependencies across the system.

Question 2

Define fragility design smell.

Answer 2

Is vulnerability to breaking.

Changes can lead to cascading effects often in unexpected places.

Bugs are hard to locate.

Question 3

Define immobility design smell.

Answer 3

Difficulty to “move” the code, so the problem with reusability in other places.

High complexity with a lot of tight coupling.

Question 4

Define viscosity design smell.

Answer 4

The software’s viscosity —it’s easier to introduce changes that break the intended design than those that keep it—encourages bad solutions.

Viscosity of the environment - same but for processes for example long compilation times.

Question 5

Define needless complexity design smell.

Answer 5

Inclusion of complex unnecessary design elements - to cover potential future needs.

This is ok when designing an application framework but otherwise it breaks agile principles.

Question 6

Define needless repetition design smell.

Answer 6

Repetition of similar parts of the code with missed abstraction - the same change has to be done in multiple places.

Question 7

Define opacity design smell.

Answer 7

The module becomes harder to understand as time passes - bad readability.

Question 8

Define Single-Responsibility Principle.

Answer 8

A class should have only one reason to change - a single responsibility.

This makes the system less coupled, such as in class drawing GUI and calculating area.

Question 9

Define Open–Closed Principle.

Answer 9

The software should be open for extension but closed for modification.

The existing code can have its functionality extended without changing it.

Strategy and template method patterns.

Needs to be balanced so as not to have the necessary complexity.

Question 10

Define Liskov Substitution Principle.

Answer 10

Subtypes should be substitutable for their base types.

So functions handling base types can also handle subtypes without knowing about the specifics.

Question 11

Define Depency-Inversion Principle.

Answer 11

High level modules should not depend on low level modules - both should depend on abstractions.

Abstraction should not depend on details and details should depend on abstractions.

Breaks the direct dependencies of higher levels, but not the lower levels.

Question 12

Define Interface-Segregation Principle.

Answer 12

Clients should not be forced to depend on methods that they do not use.

Many specific interfaces over one generic “fat” one.

Question 13

Define Reuse-Release Equivalence Principle

Answer 13

Anything intended for
reuse must also be properly released and tracked.
Human-centered - design responsibilities, including ensuring maintenance, providing notifications of future changes, offering users the option to
refuse new versions, and supporting older versions for a certain period.

Cohesion - partion for convenience of users

Question 14

Define the Common-Reuse Principle

Answer 14

The classes in a package are
reused together” and ”If you reuse one of the classes in a package, you reuse them all.

In essence, when you depend on a package, you depend on every class within that package. So classes that are tightly bound should be in the same package.

Cohesion - portion so the classes are tightly bound together

Question 15

Define the Common-Closure Principle

Answer 15

The classes in a package
should be closed together against the same kind of changes.” and ”A change that affects a closed package affects all the classes in that package and no
other packages.”

Basically single responsibility principle for packages.

Cohesion - partition so that a change is limited to one package

Question 16

Define the Acyclic-Dependencies Principle

Answer 16

Importance of avoiding cycles in the package dependency graph.
When cycles exist, packages within the cycle effectively merge into one.
By eliminating cycles, it becomes easier to compile, test, and release software in a ’bottom-up’ manner.

Coupling

Question 17

Define Stable-Dependencies Principle

Answer 17

The principle of stability emphasizes that a volatile package should not be relied upon by a package that is challenging to change.
Stability of a package is determined by how challenging it is to change,
taking into account factors such as its size, complexity, clarity, and the number of incoming dependencies.

Coupling

Question 18

Define the Stable-Abstraction Principle

Answer 18

”a package should be
as abstract as it is stable.”

Stable package
should also be abstract, ensuring that stability does not hinder its extensibility and unstable should be concrete because instability allows easy changes to the concrete.

Coupling

Question 19

Describe views in 1+4 View Model

Answer 19

Scenario view - as a user interacting with the system
Logical view - Functionality and its division in the system
Process view - Division into processes and their communication
Development view - How is system into implementation units
Physical view - Physical processing units and their connections and allocations

Question 20

Describe ATAM

Answer 20

Identifies tradeoffs in architecture 4 phases
Introduction - To the participants the ATAM, business objectives and constraints and the architecture is described
Analysis - The utility tree for each quality property has been defined scenarios (with importance) and linked with arch. decisions to find tradeoffs and risks
Testing - Other stakeholders define scenarios and priorities from their perspective and the results from Anal are evaluated
Reporting - Presenting results

ATAM needs lots of time and resources, but advantage is testing from the view of multiple different stakeholders.

Question 21

What is Product Lines, pros and cons

Answer 21

Artifacts, tools, and processes supporting one product family.
Enables more streamlined approach with better reuse.

Example is game series, starts with building a framework and then the games.

Pros
- Reuse of code and knowhow
- Faster product cycle and growth in long run
- Better standardisation
Cons
- The first product takes lot of time
- Hard to test initial stages
- Challenge to focus resources product vs. framework
- Education for new programmers

Question 22

What is Frameworks and pros and cons

Answer 22

Framework is a a collection of classes implementing a common architecture and functionality to the product family.

The application specific code is often called by the framework - opposite to library.

White box - specialisation by inheritance and overloading
Black box - specialisation by parameters and configuration
Plugin - specialization by implementing interfaces.

Pros
- Can be based on experts - GUI frameworks
- Open for extension
- Supports layered architectures
Cons
- Not worth for single apps
- Demanding to create
- Can grow really complex
- Testing can be challenging
- Education for devs
- Limited flexibility

Question 23

What is layered architecture, pros and cons

Answer 23

Layered architecture consists of levels organized according to some abstraction principle into ascending order.

It is partion by structure.

Communication can be only to levels neighboring or bypassing layers - pure is just top down request/response.

Typical is UI, App logic and Data base layers.

Pros
- Applicable to most usecases
- Easy to understand
- Less dependencies and good reusability
- Easy to test individual layers
Cons
- Information has to go through multiple layers
- Error handling is difficult

Question 24

What is Pipes and filters architecture, pros and cons

Answer 24

Consists of filters that are processing units and pipes that carry data in between them.

It is partition by functionality.

Each filter is independent with input and output stream - there is no state being shared.

Parallelism is possible using FIFO buffers between filters.

Example is image processing program with series of steps applied to the image

Pros
- Possibility of incremental processing of complex process
- Possibility to combine and replace filters - reuse and maintenance
- Support concurrency
Cons
- Specific usecase, not for interactive systems
- Similar to layered sometimes unnecessary work
- Difficult testing
- Difficult error handling

Question 25

What is client-server architecture, pros and cons

Answer 25

Service base architectural style Consists of servers providing resources and clients requesting them. Servers do not know clients and clients don't know each other. Clients and servers are running on separate processes and getting the services in connections as transactions. Examples web apps, data storage servers - and mostly everything else as well. Pros - Division of labor - Easier control of resources - Easy maintenance Cons - Performance could be bad - Server centric - failure of one point destroys the system - Error handling

Question 26

What is P2P architecture, pros and cons

Answer 26

Service oriented architecture working as a specialization for client server. Where all of the clients are also servers sharing together resources. Also hybrid with centralised server and P2P. Used for filesharing like Torrent or computing power. Pros - Removed bottleneck of server - Good fault tolerance - Good scalability Cons - Complex implementation - Security - Hard to service

Question 27

What is Message-passing architecture, pros and cons

Answer 27

Service oriented architecture For components communicating in the system not knowing about each other or the quality of the information. There is a message channel where the components register and can post or read the messages posted there. Used in engine/IOT systems, or any loosely coupled system. Pros - Easy to modify components - Fault tolerant - Very flexible Cons - Performance of reading/writting messages - Difficult to implement and test - Connections are not implicit and have to be documented

Question 28

What is Model-View-Controller Architecture, pros and cons

Answer 28

Solution for interactive systems Separates the system into Models - Has the logic and data of the apps, registers to it interested views - Observers Views - displays the state, updates on the change of model Controlers - reads user commands and interacts with the model Typicaly used in websites Pros - Automatic sync of views - Reusability - Separation of concerns - easy expand Cons - Too much work for simple apps - Possibly unnecessary requests to update the view

Question 29

What is Interpreter Architecture, pros and cons

Answer 29

Used when there is a need to pass the functional descriptions as the input to the system. Examples is a SQL DB system, or Java virtual machine. Pros - Easy modification language changes don't invalidate old descriptions - Runtime can be modified during execution Cons - Performance compared to the native platform

Question 30

What is command and active object

Answer 30

The request is being made into an object decoupling the sender. It has abstract interface Command with do()/execute() method with concrete command classes implementing it and invoker having reference to it. Active object separates invocation and execution - in case of command would be adding a class responsible for storing and running the commands.

Question 31

Template Method and Strategy

Answer 31

The template method defines the structure of the algorithm and leaves the implementation on the subclasses. The strategy does create a family of algorithms based on the defined interface that can be used interchangeably by clients without knowing the concrete implementation details. For example ApplicationRunner that is running implementation of App interface that are Strategy1 ext. Both are heavily based on the open-closed principle.

Question 32

Mediator

Answer 32

An object that handles the references so other objects don't have to have direct references to each other decoupling the system. Policy "from bellow". Example is UI classes

Question 33

Null object

Answer 33

Instead of classic null programming, there is a default object for a class instead of a null value. It has neutral behavior (doing nothing) so no need for null checks.

Question 34

Observer

Answer 34

Subscription mechanism where a subject has a list of its dependencies “observers” and informs them about changes to itself. Pull model - observers periodically actively ask for update on state Push model - subject actively pushes update when change occurs

Question 35

Facade

Answer 35

Decouples complex subsystems into one interface - clients have one point of interaction. Simplifies usage but limits flexibility. Implements policy "from above".

Question 36

Composite

Answer 36

Allows interaction with individual objects or their compositions in the same way. Example is shape and composite shape class having more shapes inside that both have draw(). It can be combined into composites and commands to combine commands.

Question 37

Abstract server and Adapter

Answer 37

Abstract server - You have a Switch and Light class. You want to add the Fan class that can be switched on and off like a switch. Instead of FanSwitch you add a Switchable interface that is implemented by Light and Fan. Adapter - To adhere to the SRP (Switchable and Light can change for dif reasons) you add a class LightAdapter in between the Switchable and Light. - so allows the use of a class working with another class without modifying its code

Question 38

Bridge

Answer 38

Separates abstraction from implementation. Used when the type of hierarchy has more than one degree of freedom - than separate based on that and tie them together with a bridge. An example is the animal class with different num of legs and different possible movements.

Question 39

Singleton and Monostate

Answer 39

The class has only one instance and offers a global point of access to that instance - allows to create only once. Its not multithreaded safe, no inheritance and polymorphism. Monostate is a version that supports inheritance by using static data for all instances. It is multithreaded safe, has inheritance and polymorphism.

Question 40

Proxy

Answer 40

Seamlessly adding functionality in between two collaborating parties without them knowing about it. Used in APIs and DBs. Example could be letting implementing order method without the knowledge of DB by another class. Dependency inversion.

Question 41

Stairway to heaven

Answer 41

Separates DB details from the business rules of the app. PersistentObject class knowing how to read/write from DB is inherited by the other classes on top of their other inheritances - only in multiple inheritance langs. Dependency inversion.

Question 42

The visitor family

Answer 42

The visitor family allows adding new methods without modifying the existing hierarchies. Problem - Modem interface with different brands, but I want to add configuration for each brand for different OS. Visitor - add interface ModemVisitor with a function to visit() each Modem brand and to Modem interface add accept() for modem visitors. The OS configs classes are implementing the ModemVisitor. Acyclic visitor - Solves the bad flexibility for changing dependencies. Move the visit() from ModemVisitor interface (leaving it empty) to the separate interface for each Modem implementation. Decorator - allows modification during the runtime. Alternative to subclassing. For the modem interface would be a LoudDialModem implementing it as well being able to take the brand implementation and modyfing it to be louder. Extension object - More complex and powerful. Each object in the hierarchy has list of special extension objects and a method to look them up - getExtension() and addExtension().

Question 43

State

Answer 43

Provides a mechanism for an object to modify its behavior when its internal state changes - separates actions and states. For example Door class manages the context and transitions between states. DoorState interface has implemented classes LockedDoor and UnlockedDoor representing states. Every state is also an instance of Strategy but with extra reference to the context class.

Question 44

What is a design smell?

Answer 44

Design smell is a symptom of poor design, representing common issues and problems with design.

Question 45

Factory pattern

Answer 45

Instead of depending directly on objects that might change and breaking DIP. We can use a factory class that handles the object creation for us. This is useful because in a case of a change of the class the change is only needed in the factory class and not in the rest of the code. For example is instead of App directly creating Shapes we add a ShapeFactory that creates it on request of App.

Question 46

Microservices, pros and cons

Answer 46

Service oriented architecture Separates services into individual units communicating among each other with lightweight protocols like HTML. Each service is small and does one thing. Pros - Good modularity - Very good scalability - Indepent units can developed with different teams and technologies Cons - Overkill for most use cases - monolith is much more simpler - Lot of communication in the network leading to latency - Difficult testing