Software Design Question and Answers

Q1:
Characteristic of RUP that does not align with Agile:
– RUP requires a strong commitment to upfront design, while Agile prefers evolving design over time.

Q2:
What is a use case?
– A simple description of how a user (or actor) interacts with the system to achieve a goal.

Q3:
List a taxonomy of requirements:
– Functional, Non‑functional, Domain, and Interface requirements.

Q4:
Alternative to Use Case Diagram/Description:
– Use user stories or activity/sequence diagrams.

Q5:
How are key domain abstractions identified in data driven design?
– By analyzing the data model, its entities, and the relationships between them.

Q6:
Steps in Use Case Realisation:
– Identify actors/scenarios, define interacting objects, create interaction diagrams, assign responsibilities.

Q7:
Draw the sequence/communication diagram for the assignment:
– (Simple sketch) User → Controller → Service → Database, with responses flowing back in the reverse order.

Q8:
Name two interaction operators and their purpose:
– alt: to show alternatives (if/else conditions).
– loop: to indicate repetition (iteration).

Q9:
What is the purpose of a state chart?
– To show the different states of an object and the transitions between those states.

Q10:
Draw the state chart for the assignment:
– (Simple sketch) States like Idle → Processing → (Success or Error).

Q11:
Discuss one point from “Is Design Dead?” and your opinion:
– Fowler argues that heavy upfront design is less useful nowadays; I agree that agile, iterative design is better for adapting to changes.

Q12:
Draw a sequence diagram for the Interceptor pattern:
– (Simple sketch) Client sends a request to Dispatcher, which calls Interceptor1, then Interceptor2, before finally reaching the Target.

Q13:
Seven steps for interception points and three dispatcher options:
– Steps: Identify interception points, define interceptor interface, implement concrete interceptors, register them, design the dispatcher, determine order, and manage callback results.
– Options: Invoke all interceptors, stop early if one returns a result, or invoke conditionally based on criteria.

Q14:
Interceptor registration interface implementation (simplified):

java

CopyEdit

public interface InterceptorRegistry { void register(Interceptor interceptor); void unregister(Interceptor interceptor); List<Interceptor> getInterceptors(); }

Q15:
Dispatcher callback interface implementation (simplified):

java

CopyEdit

public interface DispatcherCallback { void dispatch(Context context); }

Q16:
Options when implementing the Context Object:
– Use a simple Map (flexible but not type-safe), a custom class (more structure and safety), or a hybrid of both.

Q17:
Critique the code in Figure 1:
– It uses many if‑else statements, which makes it hard to maintain, extend, and test.

Q18:
Diagram and sample code after refactoring with Command pattern (mediocre version):

• Diagram:
  Client → Dispatcher (with a Command Map) → [Command1, Command2, …]

• Sample Code (Step 4):

java

CopyEdit

public interface Command { HandlerResponse execute(Map<String, Object> params); } public class NewWorkshopCommand implements Command { public HandlerResponse execute(Map<String, Object> params) { // Simple code to create a new workshop return new HandlerResponse(new StringBuffer("New Workshop Created"), "WORKSHOP_STYLE"); } }

Q19:
Code using a map for configuring commands (mediocre example):

java

CopyEdit

Map<String, Command> commands = new HashMap<>(); commands.put("NEW_WORKSHOP", new NewWorkshopCommand()); commands.put("ALL_WORKSHOPS", new AllWorkshopsCommand()); // Execute command based on action name public HandlerResponse executeAction(String action, Map<String, Object> params) { Command cmd = commands.get(action); return (cmd != null) ? cmd.execute(params) : null; }

Q20:
Intent of MVC and structural diagram (simplified):
– Intent: Separate data (Model), UI (View), and input control (Controller) for easier maintenance.
– Diagram:

nginx

CopyEdit

Model <--> View ^ | Controller

Q21:
What is software architecture?
– The high‑level structure that defines the components of a system and how they interact.

Q22:
What is an Open architecture? Diagram:
– Definition: A design with modular components and standard interfaces.
– Diagram:

csharp

CopyEdit

[Core] | ---------------- | | | | Mod1 Mod2 Mod3

Q23:
What is a Closed architecture? Diagram:
– Definition: A monolithic design with tightly coupled parts.
– Diagram:

csharp

CopyEdit

[Monolithic Application]

Q24:
Compare Open vs. Closed architectures:
– Open: Flexible, modular, easier to extend.
– Closed: Simpler initially but harder to modify or extend.

Q25:
Sequence diagram for MVC startup (simple version):
– Sketch:
User → Controller (initializes) → Model (loads data) → View (renders UI).

Q26:
Sequence diagram for MVC runtime (simple version):
– Sketch:
User event → Controller → Model (update) → Model notifies View → View refreshes.

Q27:
Scenario where the controller is updated:
– When a new feature (like additional input validation) is added, the controller’s code must change to handle it.

Q28:
Why does the view own the controller in MVC?
– It simplifies handling user interactions by directly linking UI events to controller logic.

Q29:
Describe the Composite pattern (use headings):

• Motivation: Simplify client code by treating individual objects and compositions the same way.

• Applicability: When representing tree structures (like UI elements or file systems).

• Structure: A common interface for both leaves and composites; composites manage child objects.

Q30:
Adsequence integration diagram using Composite pattern:
– Diagram:

markdown

CopyEdit

MediaComponent / \ Adsequence MediaClip

– Note: Chose a transparent design for simplicity, so the client calls play() on both without checking type.

Q31:
Safety vs. Transparency in Composite pattern (with code fragments):

• Transparent:

  java

  CopyEdit

  interface Component { void add(Component c); // implemented even by leaves (may throw error) void play(); }

• Safe:

  java

  CopyEdit

  interface Component { void play(); } interface Composite extends Component { void add(Component c); void remove(Component c); }

– Summary: Transparent is simpler but less safe; safe requires extra interfaces but avoids invalid operations.

Q32:
Intent of the State design pattern:
– Allow an object to change its behavior when its internal state changes.

Q33:
Who manages state transitions in the State pattern? Options:
– Context-managed: The object itself handles transitions (simple but can be bulky).
– State-managed: Each state handles its own transition (more modular but harder to follow).
– External controller: A separate component manages transitions (clear but adds extra complexity).

Q34:
Movie rental refactoring using a design pattern:

(i) Pattern: Strategy (or Replace Conditional with Polymorphism).

(ii) Diagram:

csharp

CopyEdit

Movie | [Price Strategy] / \ Childrens NewRelease

(iii) Movie class code:

java

CopyEdit

public class Movie { private String title; private Price price; // Price is the strategy interface public Movie(String title, Price price) { this.title = title; this.price = price; } public double getCharge(int daysRented) { return price.getCharge(daysRented); } public int getFrequentRenterPoints(int daysRented) { return price.getFrequentRenterPoints(daysRented); } }

Q35:
Intent of the Strategy pattern:
– To allow interchangeable algorithms by encapsulating each one in its own class.

Q36:
Diagram for the Strategy pattern:

css

CopyEdit

Strategy (interface) / \ ConcreteA ConcreteB ... etc. \ / Context (uses a Strategy)

Q37:
Compare Strategy vs. State patterns:
– Strategy: Lets you swap algorithms easily (focus on choice).
– State: Lets an object change behavior as its state changes (focus on state transitions).
Both use delegation but for different purposes.

Q38:
Diagram for the Singleton pattern:

lua

CopyEdit

+-------------------+ | Singleton | +-------------------+ | - instance | +-------------------+ | + getInstance() | +-------------------+

Q39:
What is a pattern? Provide a taxonomy:
– A pattern is a reusable solution to a common design problem.
– Taxonomy: Creational, Structural, Behavioral, and sometimes Architectural patterns.

Q40:
Two dimensions for classifying design patterns (and six categories):

– Dimensions:

1. Implementation Level: Class-level vs. Object-level

2. Purpose: Creational, Structural, Behavioral

– Examples:

• Class-level Creational: Factory Method

• Object-level Creational: Prototype

• Class-level Structural: Adapter

• Object-level Structural: Decorator

• Class-level Behavioral: Template Method

• Object-level Behavioral: Strategy

Q41:
Discuss sketching/blueprinting’s role in software engineering:
– Even though sketches are informal, they help communicate ideas, guide design decisions, and support early planning. They are useful for brainstorming and clarifying thoughts before detailed design work.