MIDTERM (Lec 1 - 8) Flashcards

(37 cards)

1
Q

How has the software development process evolved from the 1960s to today, and what are some of the key challenges developers face today compared to the early days of software development?

A

Early focus: basic functionalities and maintenance challenges.
Modern focus: scalability, complexity management, and security.
Challenges today: integrating new technologies, handling large-scale systems, ensuring reliability and performance​

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

What is the role of software architecture in software development, and how does it impact long-term cost and quality?

A
  • Impacts long-term cost and quality by influencing modifications and helps with managing complexity, especially with bigger systems
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

What is the difference between functional and non-functional requirements? Give an example of each in a real-world application.

A

Functional: Describes specific tasks that must be PERFORMED (e.g., “Users can log in”).

Non-functional: Describes qualities like performance, security (e.g., “System must handle 10,000 users”, usability).

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

What are design decisions in software architecture, and how do principal and temporal decisions influence system development? Give an example of each from a real-world application.

A
  • Choices made during the creation / planning phase

Principal: important choices that changes overall architecture, or behavior (Different language used, different architecture)

Temporal: choices made overtime (Changing the interface, etc)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

What is the difference between user stories and use cases? Provide an example of the same feature described using both a user story and a use case.

A

User stories: informal description of features of a software.

Use cases: a list of actions or event steps thru the UML

Example:
Feature: Being able to send messages
User story: As a person, I want to send messages so that I can interact with my contacts.
Use Case: 1. From home screen press option message
2. select a contact
3. Write the message and press send
4. Receive confirmation status

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

What is UML, and why is it important in software architecture?

A

UML: Unified Modeling Language

standardized way to visualize the design of a system.

Helps to understand, document and show the structure and behavior of the system.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

What is a Requirements Traceability Matrix (RTM), and how does it help in software development? List three key components of an RTM.

A

Maps relationship between requirements, architecture, and work.

Helps keep the requirements in check and provides a record and proof.

Components: Requirement ID, Description, Source, Status, Design Reference, Test Cases

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

What is the role of class diagrams in software architecture?

A

Visual representation of key components in a system.

Makes it easier to manage the complexity of a system by organizing it into logical units.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

What is decomposition in software architecture? How does it improve modularity and maintainability?

A

Breaking down larger entities into smaller, specialized ones

Modularity: separates functionality into specialized classes/units

Maintainability: small changes doesn’t affect the entire system

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

Explain the difference between tight coupling and loose coupling. Which one is preferred in software architecture?

A

Tight: classes are highly dependent on each other

Loose: classes are not that dependent

Loose is preferred, for more flexibility and modularity of classes

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

What is cohesion in software design? As a software architect, should you prioritize high or low cohesion? Explain why.

A

Closeness and unity within a class.

High cohesion is preferred to improve readability, ensuring each class has a clear specific task.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

How do coupling and cohesion relate to each other?

A

High Cohesion ←→ Low Coupling
Low Cohesion ←→ High Coupling

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

What is the difference between scalability and elasticity in software architecture? How do they relate to system performance under varying workloads?

A

Scalability: Handle increased work by adding resources (servers)

Elasticity: Dynamically ADAPTING and adjusting resources based on demand in real time

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

How do modularity and maintainability complement each other in software architecture?

A

Modularity: Dividing a system into smaller components

Maintainability: Easier to update a small component without disturbing the entire system.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

Compare testability, fault tolerance, and reliability.

A

Testability: How easily a system can be tested

Fault Tolerance: Continue functioning despite bugs / failures

Reliability: CONSISTENT performance under certain conditions

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

What is the relationship between security and interoperability?

A

Security: Protects systems from unauthorized access

Interoperability: Ensure different systems can communicate together.

Finding the right balance between them is important, without sacrificing one or the other.

17
Q

How do simplicity and reusability contribute to efficient software development?

A

Simplicity: reduce complexity, easier code to read

Reusability: allows code to be reused, to save time.

They reduce effort needed, take away redundancy, and improve maintainability

18
Q

Layered architecture is known for its modularity. What are some key characteristics of this architecture style?

A

Simplicity, Modularity, Maintainability, Scalability, Reusability, Testability, Interoperability, Flexibility

19
Q

Pipeline architecture processes data in stages. What are the defining characteristics of this architecture style?

A

Modularity, Scalability, Reusability, Flexibility, Testability

20
Q

How do the characteristics of different architecture styles (monolithic, layered, pipeline) impact deployment and testing? Provide specific examples.

A

MONOLITHIC:
Testing → Easier to test as everything is within one codebase, but harder to isolate issues in large systems
Deployment → Changes require redeploying the entire app

LAYERED
Testing → Each layer can be tested independently or together
Deployment → Can deploy as a whole or separately in layers

PIPELINE
Testing → Each stage can be tested separately
Deployment → Components deployed as separate processes or services

21
Q

Compare microkernel and microservices architectures. How do they differ in terms of component independence, communication, and deployment?

A

COMPONENT INDEPENDENCE
Kernel → microkernel handles essential tasks. additional features run as plug-ins
Service → each microservice is self-contained unit and deployed independently

COMMUNICATION
Kernel → Plug-ins communicate or message passing
Service →communicate through APIs like REST

DEPLOYMENT
Kernel → deployed as a single system
Service → each service deployed independently

22
Q

What are the key characteristics of microservices architecture? How does this style improve scalability and fault tolerance?

A

Scalability, Flexibility, Deployability, Testability, Fault Tolerance, Performance

Each service can be tested / deployed independently.
One service having errors won’t crash the entire system.

23
Q

How does event-driven architecture work, and what are some real-world applications where it is beneficial?

A

Components REACT to events (sensor, user, messages).

Examples: Ecommerce (order processing, payment, inventory, etc)

24
Q

List and explain at least three key factors that software architects should consider when selecting an architecture style for a system. Provide an example where these factors influenced an architecture choice.

A

3 Key factors:

Design: Style must align with the requirements of the system.

Cost: Microservices might be chosen for large-scale systems

Schedule: Consider time constraints. (Monolithic for smaller projects and tight deadlines)

25
Refactoring is the process of restructuring existing code without changing its external behavior. Why is refactoring important in software development?
Improves readability, understandability and flexibility. Reduces technical debt and finds bugs more easily. Long-term efficiency
26
Define code smells and explain how they differ from actual software bugs
Code smells: improper code structure that make the code hard to read or maintain but can still work Bugs: cause errors or crashes
27
Provide three examples of common code smells and describe how refactoring can address them.
1. duplicated code: use shared logic into separate method 2. long method: split method into smaller methods 3. poor cohesion:break into multiple classes or modules focused on a single responsibility
28
Refactoring can occur at different levels, including data, statement, routine, class, and system levels. Provide two examples of specific code smells identified in each of these levels.
DATA: use constants, renaming variables, replace arrays STATEMENT: simplifying expressions, splitting statements CLASS: breaking down classes, combining classes, changing hierarchy ROUTINE: moving and rearranging methods, deleting method SYSTEM: changing the architecture, security enhancements
29
What is the difference between "Duplicated Code" and "Long Method" as code smells? How does each impact system maintainability, and what refactoring techniques can be used to address them?
Duplicated Code: same/similar code appearing in multiple places → Use common logic in a separate method Long Method: too many functionalities in a single method → Break down method into smaller methods with a specific task in mind It can make it hard to read and debug.
30
Software systems evolve over time, requiring ongoing maintenance and refactoring. What are the risks of neglecting refactoring in long-term projects?
- Rise of technical dept - Higher risk of bugs - Slower performance - Less productivity
31
How does technical debt affect software architecture and team productivity?
Increases the cost, delayed releases Makes it much harder to maintain, more bugs Reduces morale and productivity of team
32
What are the different types of technical debt? Explain with an example.
1. Code Debt: poor and messy code (quick fixes) 2. Test Debt: poor or lack of tests 3. Design Debt: (undocumented decisions, lack of foresight) short term design choices with no regard for long term 4. Infrastructure Debt: outdated databases or servers.
33
What is the difference between pair programming and code walkthroughs in managing technical debt?
Pair programming: One-on-one, one person codes, the other one watches Code Walkthrough: structured walkthrough involving multiple parties (developers, stakeholders)
34
Compare informal code reviews with technical inspections. How do their structures and goals differ in addressing technical debt?
Code Reviews:Unstructured review, focus on general feedback and identify obvious problems, just looking at the general structure Technical Inspection: systematic inspection, using structured guidelines and rules, thorough inspection
35
Code smells indicate areas where software design could be improved. How are poor cohesion and tight coupling related to code smells?
Poor cohesion: class has unrelated responsibilities, harder to maintain and scale Tight coupling: changing one class changes others, code dependent on each other too much
36
Requirements engineering and software architecture are closely linked. How do non-functional requirements influence the choice of architectural styles?
Scalability → might push for more microservices Security → might push for layered architecture
37
Software development teams must balance short-term project goals with long-term system sustainability. What are the roles of intentional and unintentional technical debt in this context?
Intentional debt is useful for short-term goals and quick deadlines, the team agrees to take on the debt. Unintentional debt builds up over time because of poor practices making the code very hard to maintain and manage.