Software Engineering – Module 4

Module – 4
ARCHITECTURAL DESIGN: Architectural design decisions; Architectural views; Architectural
patterns- Layered architecture, Repository architecture, Client–server architecture Pipe and filter
architecture.
DESIGN AND IMPLEMENTATION: Object-oriented design using the UML- System context
and interactions, Architectural design, Object class identification, Design models, Interface
specification; Design patterns; Implementation issues.

Architectural design decisions:

Architectural design decisions are the critical choices made by a software architect that define the
overall structure, organization, and behavior of a system. These decisions are non-functional
(quality) requirements often dominate, shaping the system's ability to meet its functional goals,
quality attributes, and constraints.

Key Factors Influencing Decisions:

➢ Quality Attributes (Non-Functional Requirements): The most important factor.
Decisions are driven by needs for performance, security, maintainability, scalability,
usability, reliability, etc.
• Performance: Decisions relate to choosing synchronous vs. asynchronous
communication, caching mechanisms, or load-balancing techniques. Trade-off: High
performance often sacrifices simplicity.
• Scalability: Decisions involve distributing load across multiple servers (e.g., using
Client-Server or Microservices) or choosing stateless components. Trade-off: High
scalability adds complexity and deployment overhead.
• Security: Decisions involve authentication protocols, authorization layers, and data
encryption standards (often driving a Layered approach). Trade-off: High security
reduces performance and increases development effort.
• Maintainability/Modifiability: Decisions focus on coupling (how dependent
components are) and cohesion (how focused a component is). Layered and Pipe and
Filter architectures excel here.
Example: A requirement for high scalability might lead to choosing a microservices or
client-server architecture over a monolithic one.

Page | 1
Software Engineering – Module 4
➢ System Constraints: Limitations like budget, schedule, legacy systems, hardware
capabilities, and available technology or expertise.
• Technology/Legacy Systems: The need to integrate with existing systems can force
the adoption of specific protocols (e.g., SOAP/REST) or technology stacks.
• Schedule and Budget: Severe time or budget restrictions often lead to choosing
simpler, off-the-shelf solutions, even if they aren't optimal for long-term scalability.
Example: Limited budget might force the use of open-source technologies, impacting the
choice of database or framework.
➢ Functional Requirements: The core services the system must provide.
➢ Stakeholder Concerns: Addressing the specific needs and worries of different groups
(users, developers, managers).

The Decision Process:

➢ Identify the Drivers: Determine the most critical quality attributes and constraints.
This is the foundational phase where the architect establishes what matters most to the
system and its stakeholders. The goal is to define the boundary conditions and success
criteria for the architecture.
• Determine Critical Quality Attributes (QAs): QAs are the non-functional
requirements that dictate the system's success (e.g., performance, security, scalability,
modifiability). The architect must prioritize these, often recognizing that only a few
(usually 3-5) can be optimized simultaneously.
Example: If the system is a payment gateway, Security and Reliability will be top drivers,
while Usability might be a lower priority.
• Identify Hard Constraints: These are non-negotiable limitations. They can be external
(e.g., regulatory compliance, client requirements to use a specific database) or internal
(e.g., limited budget, fixed timeline, or mandated use of legacy components).
• Artifact: This phase results in a clear, prioritized list of architectural goals and
constraints.
➢ Generate Alternatives: Propose multiple architectural solutions.
Once the drivers are known, the architect explores viable options. This phase requires
creativity and a broad knowledge of architectural styles and patterns. The goal is not just to
find one solution, but to explore the design space.

Page | 2
Software Engineering – Module 4
• Brainstorming Patterns: Based on the drivers, relevant architectural patterns are
identified (e.g., if scalability is key, consider Client-Server or Microservices instead
of a simple Layered approach).
• Developing Scenarios: For each alternative, the architect drafts a high-level
conceptual design that addresses the key drivers. The alternatives should represent
genuinely different approaches to the problem.
Example: For a social media feed:
• Alternative A: Traditional Layered Monolith (simple to deploy).
• Alternative B: Microservices (high scalability/modifiability).
• Alternative C: Event-Driven Architecture (optimized for real-time updates).
• Artifact: High-level conceptual diagrams and brief descriptions for 2-4 distinct
candidate architectures.
➢ Evaluate: Assess each alternative against the drivers (often using tools or techniques like
ATAM - Architecture Trade-off Analysis Method).
This is the most critical analytical step, where candidates are rigorously tested against the
success criteria defined in Step 1.
• Architecture Trade-off Analysis Method (ATAM): A formal evaluation technique
often used. ATAM involves analyzing the system's architecture in the context of its
goals and identifying potential trade-offs and risks.
• Scenario Walkthroughs: The architect uses predefined usage scenarios (e.g., "The
system must handle 1 million simultaneous users requesting a profile load") and
traces the execution path through each architectural alternative. This reveals how well
each design satisfies the quality attributes.
• Trade-off Analysis: This involves explicitly identifying where one architecture
excels at one driver but fails another.
Example: Architecture A (Monolith) might be cheaper and faster to develop
(Time/Budget), but Architecture B (Microservices) provides superior Scalability. The
decision rests on whether time or scalability is the more critical driver.
• Artifact: A detailed comparison matrix or a formal ATAM report listing the pros,
cons, risks, and trade-offs for each alternative relative to the primary drivers.

Page | 3
Software Engineering – Module 4
➢ Select and Document: Choose the best solution and record the decision, including the
rationale and the alternatives considered. The final phase involves making the commitment
and formalizing the choice for future reference.
• Selection: The alternative that offers the optimal balance among the prioritized
quality attributes and constraints is chosen. It is rarely the alternative that performs
best on all fronts, but the one that meets the most critical ones without introducing
unacceptable risks.
• Documentation (Architectural Decision Record - ADR): This is essential. The chosen
solution, the context, and the rationale are formally recorded. The documentation
must include:
• The Problem/Context: Why was the decision necessary?
• The Chosen Solution: The specific pattern or structure selected.
• The Rationale: Why this solution was better than the others, specifically citing
the trade-offs that were accepted (e.g., "We chose Microservices despite the
higher initial cost because Scalability was the ultimate business driver").
• Alternatives Considered: A summary of the designs that were rejected.

Architectural Views
An Architectural View is a representation of the architecture from the perspective of a specific set
of concerns. Since no single drawing or document can capture the complexity of an entire system,
multiple views are used to communicate the design to different stakeholders.
The most widely accepted framework for defining these views is Kruchten's 4+1 View Model. This
model organizes the architectural description into four main views, with a central "plus one" view
that ties them all together.
1. Logical View
• This view focuses on the system's functional requirements and its structure from a
developer's perspective.
• It shows how the system is designed in terms of its abstract components, classes, and
their relationships.
• It’s primarily concerned with the system's logical design and the key abstractions that
are implemented.
• Think of this as the "what" the system does.

Page | 4
Software Engineering – Module 4
• It helps developers understand the system's core services and how they are organized
into a cohesive whole.
2. Process View
• The process view is all about the system's concurrency and runtime behavior.
• It shows how the system is structured as a set of interacting processes or threads.
• The main concerns here are performance, scalability, and inter-process
communication.
• This view is crucial for system integrators and developers who need to understand
how the system's components work together in a live environment to handle
concurrent tasks and data flows.
3. Development View
• Also known as the implementation view or module view, this perspective describes
the system's static organization as a collection of modules, files, and libraries in the
development environment.
• It's the view that programmers use daily.
• It helps in understanding dependencies, managing codebases, and organizing the
source code into manageable chunks for development and maintenance.
• Concerns like code reusability, modularity, and ease of compilation are central to this
view.
4. Physical View
• This view maps the software components onto the system's hardware topology.
• It shows how and where the software runs on the physical network.
• Key concerns are deployment, distribution, network communication, and hardware
resource allocation.
• This view is essential for system engineers and administrators who are responsible
for deploying, installing, and managing the physical system.
• It addresses questions about how the system will handle load, where data will be
stored, and how components will communicate across the network.
5. +1. Scenarios View
• The scenarios view is the "plus one" that binds the other four views together.
• It's not a separate view but a set of key use cases or scenarios that are used to drive
the design and validate the architecture.

Page | 5
Software Engineering – Module 4
• These scenarios illustrate how the system behaves under specific conditions, showing
the interaction between components across the logical, process, development, and
physical views.
• This view is invaluable for communicating the architecture to all stakeholders and
ensuring that the design meets the critical functional and non-functional
requirements.

Architectural Patterns:
Architectural patterns are fundamental blueprints for structuring software systems. They offer
proven solutions to recurring design problems, guiding the organization of components, their
responsibilities, and how they interact.
Layered Architecture:
The Layered Architecture is one of the most common and intuitive patterns, organizing the system
into distinct, horizontal layers. Each layer provides services to the layer directly above it and uses
services from the layer directly below it.

Typical Layers:
1. Presentation Layer (UI Layer): This is the outermost layer, responsible for handling user
interaction, displaying information, and translating user input into system commands. It
typically contains UI components, controllers, and formatters.
Example: A web browser rendering HTML, a mobile app's activity/view, a desktop GUI.
2. Application Layer (Service Layer): This layer orchestrates business tasks and acts as a
facade (an entry point) for the layers below. It contains application-specific logic that
coordinates actions between the UI and the domain layer. It might handle transaction
management and security checks but doesn't contain core business rules itself.

Page | 6
Software Engineering – Module 4
Example: A UserService that handles user registration flow by interacting with the
UserDomain and EmailService.
3. Domain Layer (Business Logic Layer): This is the heart of the system, encapsulating the
core business rules, entities, and policies. It's often where the "smart" objects and the crucial
business processes reside. It should be independent of specific UI or database technologies.
Example: A User entity with methods like changePassword() or business rules like
isValidOrder().
4. Data Access Layer (Persistence Layer): Responsible for abstracting the details of data
storage and retrieval. It provides an interface for the domain layer to interact with databases,
file systems, or external APIs without knowing the specific implementation details (e.g.,
SQL queries, NoSQL commands).
Example: A UserRepository that handles saving and fetching User objects from a database.
Advantages:
• High Modifiability: Changes in one layer (e.g., swapping database technology in the
Persistence Layer) ideally only affect the adjacent layers, making updates easier.
• Enhanced Testability: Layers can be tested in isolation by mocking out the layers below
them.
• Simplified Development: Teams can focus on developing specific layers.
• Standardization: Provides a clear structure that's easy to understand for new developers.
Disadvantages:
• Performance Overhead: Data often has to pass through multiple layers, which can introduce
latency (though often negligible for typical applications).
• "Architecture Tunneling": Developers might be tempted to bypass layers ("tunnel through")
to improve perceived performance or reduce code, which undermines the pattern's benefits.
• Tight Coupling (within a layer): While coupling between layers is loose, internal layer
components can still be tightly coupled.
• Monolithic Tendency: Can still lead to a large, single deployable unit, making independent
scaling of specific functionalities difficult.
Best Suited For: Traditional business applications (CRMs, ERPs), systems with well-defined
separation of concerns, and applications that need to be highly maintainable and testable over long
periods.

Page | 7
Software Engineering – Module 4
Repository Architecture (Blackboard System)
The Repository Architecture, often referred to as a Blackboard System in its more dynamic form,
is a data-centric pattern where independent components interact primarily through a shared, central
data store. Components operate by observing or reacting to changes in this central data.
Mechanism:
• Centralized Data: All shared information and intermediate results are stored in a single,
accessible repository.
• Decoupled Components: Processing components (often called "Knowledge Sources" in
Blackboard systems) are largely independent. They don't communicate directly with each
other but interact solely through the repository.
• Opportunistic Processing: In a Blackboard system, a control component decides which
knowledge source to execute next based on the current state of the data in the blackboard.
This makes it suitable for complex problem-solving where there isn't a fixed sequence of
steps.
Key Components:

➢ Central Data Repository (Blackboard): This is the shared memory where all data is
stored. It can be a simple database, a complex object graph, or a domain model. It acts as
the communication medium between components.
➢ Independent Components (Knowledge Sources): These are modules that perform specific
processing tasks. They read data from the repository, apply their logic, and write updated
data back to the repository. They are typically unaware of other components.
➢ Control Component (Scheduler/Monitor): (More prominent in Blackboard systems) This
component monitors changes in the repository and decides which knowledge source should
execute next based on the system's goals and current state. This allows for flexible,
opportunistic problem-solving.

Page | 8
Software Engineering – Module 4
Advantages:
• High Extensibility: New components (knowledge sources) can be added easily without
affecting existing ones.
• Data Consistency: All components work on the same, centralized data, simplifying
consistency management.
• Adaptability: Well-suited for problems where the solution path is not known in advance,
allowing for flexible, incremental problem-solving.
Disadvantages:
• Performance Bottleneck: The central repository can become a bottleneck if access is
highly contended.
• Single Point of Failure: If the repository goes down, the entire system fails.
• Complexity of Control: Designing the control component for complex problem domains
can be challenging.
• Data Schema Coupling: Components are tightly coupled to the schema of the data in the
repository, making schema changes potentially difficult.
Best Suited For: Artificial intelligence applications (e.g., speech recognition, image processing,
expert systems), complex data analysis, and systems where multiple diverse knowledge sources
contribute to a common solution, incrementally building it up.

Client–Server Architecture
The Client-Server Architecture is a distributed application structure that partitions tasks between
service providers (servers) and service requesters (clients). Clients initiate communication,
requesting services from servers, which then provide them.
Mechanism:
➢ Request-Response: The fundamental interaction model. A client sends a request to a server,
and the server processes the request and sends a response back to the client.
➢ Asymmetry: Clients are active requesters, while servers are passive listeners.
➢ Resource Sharing: Servers typically manage and provide access to shared resources (e.g.,
databases, files, printers).
➢ Stateless vs. Stateful: Servers can be stateless (each request is independent, no memory of
previous client interactions) or stateful (maintain session information for clients).
Statelessness generally improves scalability.

Page | 9
Software Engineering – Module 4
Key Components:
• Client: The component that initiates communication and requests services. It usually
provides the user interface and translates user actions into server requests. Clients can be
web browsers, mobile apps, desktop applications, or other servers.
• Server: The component that listens for client requests, processes them, accesses shared
resources (like a database), and sends responses back to the client. A server typically
provides services like data storage, computation, or resource management.
• Network: The communication medium (e.g., Internet, LAN) that connects clients and
servers.
Variations:
• 2-Tier Architecture: A direct connection between the client and the server. The client often
contains UI and some business logic, while the server handles data storage and more
complex business logic.
Example: A desktop application directly connecting to a database.
• 3-Tier Architecture: Introduces an intermediate "Application Server" or "Middleware"
layer.
• Client (Presentation Tier): Handles the user interface.
• Application Server (Logic Tier): Contains most of the business logic, processing
requests from the client and interacting with the database tier.
• Database Server (Data Tier): Manages data storage and retrieval.
• Example: A typical web application with a web browser (client), a web
server/application server (logic), and a database server.
• N-Tier Architecture: Extends the 3-tier model with more specialized tiers (e.g., separate
authentication server, caching layer, messaging queue server).

Page | 10
Software Engineering – Module 4
Advantages:
• Centralized Control: Simplifies security management, resource access control, and data
consistency.
• Scalability: Servers can be upgraded (vertical scaling) or replicated (horizontal scaling) to
handle increased load.
• Platform Independence: Clients and servers can run on different operating systems and
hardware platforms, as long as they adhere to communication protocols.
• Ease of Maintenance: Server logic can be updated without redeploying clients.
Disadvantages:
• Network Dependency: The system is unusable if the network connection or the server is
unavailable.
• Server Bottlenecks: A single server can become overloaded if traffic is too high (though
this can be mitigated with scaling techniques).
• Complexity: Managing distributed transactions and ensuring reliable communication
across a network adds complexity.
• Security Risks: Requires robust security measures on the server and during network
communication.
Best Suited For: Web applications, database applications, email services, file sharing, network
printing, and most internet-based services.

Pipe and Filter Architecture

The Pipe and Filter Architecture structures a system as a series of independent processing steps
(filters) connected by data channels (pipes). Data flows unidirectionally through this pipeline, with
each filter transforming its input into an output for the next stage.
Mechanism:
➢ Data Stream Processing: Data flows continuously or in batches through the system.
➢ Independent Filters: Each filter is a self-contained unit that performs a specific
transformation. They typically read input from one or more pipes, process the data, and write
output to one or more pipes.
➢ Stateless Filters: Filters are generally stateless, meaning they don't retain information about
previous data processed. This makes them highly reusable and easy to test.

Page | 11
Software Engineering – Module 4
➢ Unidirectional Pipes: Pipes act as buffers that connect filters, transmitting data from a
source filter's output to a sink filter's input. The communication is one-way.
Key Components:
• Filter (Processor): An independent component that consumes data from its input pipe(s),
performs a specific transformation (e.g., sort, encrypt, parse, format), and produces data to
its output pipe(s). Filters are often categorized as:
• Source Filter: Initiates the data stream.
• Sink Filter: Terminates the data stream.
• Transformer Filter: Modifies the data stream.
• Pipe (Connector): A communication channel that connects the output of one filter to the
input of another. Pipes are typically stateless and buffer data, allowing filters to run at
different speeds or in parallel.

Advantages:
• High Reusability: Filters are self-contained and stateless, making them highly reusable in
different pipelines.
• High Modifiability: New filters can be added, existing ones can be replaced, or the order
can be rearranged easily.
• Parallelism: Filters can often run concurrently, as long as the pipes can buffer data,
improving throughput.
• Simplicity: The overall design is easy to understand, as each filter has a clear, single
responsibility.
• Testability: Individual filters can be tested in isolation by providing input and checking
output.

Page | 12
Software Engineering – Module 4
Disadvantages:
• Data Transformation Overhead: Filters often require data to be converted to a common
format (e.g., text, XML, JSON), which can incur performance overhead.
• Batch Processing Bias: Better suited for batch processing than for interactive, real-time
systems that require quick, two-way communication.
• Difficulty with State: Filters are typically stateless; managing shared state or complex
interactions that require state across filters can be challenging.
• Error Handling: Propagating and handling errors across multiple filters can be complex.
Best Suited For: Compilers (lexical analysis -> parsing -> semantic analysis -> code generation),
Unix shell utilities (e.g., grep | sort | uniq), ETL (Extract, Transform, Load) processes, data
conversion systems, and any scenario involving sequential data processing pipelines.

Object-Oriented Design using the UML

Object-Oriented Design (OOD) translates requirements into a system structure using concepts like
encapsulation, inheritance, and polymorphism. The Unified Modeling Language (UML) serves as
the visual blueprint for this process.

System Context and Interactions

This initial design step focuses on understanding the system's external boundaries and dynamic
behavior.
1. System Context: Defining Scope
The System Context Diagram is often the first visual artifact. It establishes the "Level 0"
view.
• System Boundary: The central element, representing the entire software product
being built.
• Actors (External Entities): These are the entities (people, other systems, hardware)
that interact with the system. They are crucial for defining interfaces.
• Flows/Interfaces: Labeled arrows showing the input and output data or messages
exchanged between the system and the actors.
• Purpose: To define the project scope (everything inside the box) and identify all
external dependencies that the system must communicate with.

Page | 13
Software Engineering – Module 4
2. System Interactions: Dynamic Modeling
UML Interaction Diagrams model the flow of control and messages during a use case
execution.
• Sequence Diagram (Time-focused): Models the dynamic collaboration of objects
showing the ordering of events over time. This is essential for verifying business
logic flow.
• Notations: Lifelines (objects), Messages (method calls), Execution
Specifications (active processing), and Combined Fragments (e.g., opt for
optional steps, loop for repetition, alt for alternative paths).
• Communication Diagram (Structure-focused): Models the same information as a
Sequence Diagram but emphasizes the structural relationships (links) between
collaborating objects rather than the sequence of time. Messages are numbered to
show sequence.
• Purpose: To detail the required operations and determine the responsibilities of each
object, directly feeding into object class identification.

Architectural Design
➢ This phase establishes the macro-structure, guiding how major software units are partitioned
and deployed.
➢ Component Identification: Subsystems or major functional units (e.g., Authentication
Service, Payment Gateway Component).
➢ Architectural Pattern Selection: The decision here (e.g., Layered for maintenance,
Microservices for scalability) dictates the organization of these components.
➢ UML Component Diagram: Models the structure of the system's implementation. It shows
components, their Provided Interfaces (the services they offer) and Required Interfaces (the
services they need from others). This diagram emphasizes modularity and portability.
➢ UML Deployment Diagram: Crucial for distributed systems. It maps software components
(artifacts) to physical nodes (hardware devices, servers, containers). This addresses physical
constraints and NFRs like performance and availability.

Page | 14
Software Engineering – Module 4
Object Class Identification
This bridges the gap between the requirements domain and the software design by finding the
classes that will populate the system.
Technique 1:
• Noun Phrase Abstraction: Reviewing requirements and creating a list of candidate classes
based on common nouns. Candidates are then filtered:
• Keep: Business entities, external interfaces, and abstract concepts/roles.
• Discard: Redundant terms, attributes (properties of a class), and implementation details
(unless they are major components).

Technique 2:
• Responsibility-Driven Design (RDD) via CRC: Focuses on what an object must be
responsible for and who it needs to talk to. This encourages creating classes with high
cohesion (doing one thing well) and low coupling (minimal dependencies).
• Result: The initial Domain Model, showing key concepts, attributes, and relationships (like
Aggregation/Composition) using UML Class Notation.

Design Models
The central output of OOD—the detailed static blueprint.
UML Class Diagram: The Static Structure: This diagram details the features and relationships of
every class.
➢ Attributes: Member variables. Notation includes Name: Type and Visibility (- for private,
+ for public).
➢ Operations (Methods): Functions provided by the class. Notation includes
Name(parameters): ReturnType and Visibility.
➢ Associations (Links):
• Navigability: Shown with an arrow, indicating if one class can access the other
(important for implementation).
• Multiplicity (Cardinality): Shows how many instances participate in the relationship
(e.g., 1 for exactly one, * for zero or more, 1..* for one or more).
➢ Inheritance (Generalization): Used to capture "is-a" relationships, promoting code reuse
and establishing polymorphism.

Page | 15
Software Engineering – Module 4
Interface Specification
• Interfaces are contracts that define boundaries between system parts, promoting the core
OOD principle of programming to an interface, not an implementation.
• UML Interface Notation: Represented using the «interface» keyword in a class box, or the
stylized Lollipop and Socket notation in component diagrams.
• Lollipop (Provided Interface): Indicates the services a class offers to the outside world.
• Socket (Required Interface): Indicates the services a class needs from another component to
function.
• Realization: A class implements (realizes) an interface, meaning it guarantees all methods
defined in the interface are implemented.
• Benefit (Decoupling): When Class A uses Interface B, Class A is loosely coupled from the
specific implementation of B. This is the Dependency Inversion Principle.

Design Patterns
Design patterns provide micro-architectures for specific, common problems. They are categorized
by the intent of the problem they solve.
Creational Design Patterns
• Creational patterns focus on managing object creation mechanisms, aiming to abstract and
control the way objects are instantiated.
• By deferring the responsibility of object creation to specialized factory classes or methods,
they decouple the client code from the specific, concrete classes being created.
• This improves flexibility and maintainability, as the system can easily switch between
different product families without altering the core client logic.
• Key examples include the Factory Method, which provides an interface for creating objects
in a superclass but lets subclasses decide which class to instantiate, and the Singleton pattern,
which ensures a class has only one instance and provides a global point of access to it, often
used for centralized resource managers like loggers or configuration settings.

Structural Design Patterns

• Structural patterns deal with organizing and composing classes and objects to form larger,
more efficient structures.

Page | 16
Software Engineering – Module 4
• These patterns focus on how entities are connected and organized, striving to ensure that if
one part of the system changes, the entire structure doesn't need to be fundamentally
redesigned.
• They emphasize the principle of composition over inheritance to achieve flexibility.
• Notable examples include the Adapter pattern, which allows objects with incompatible
interfaces to collaborate (acting like a physical plug adapter), and the Facade pattern, which
provides a simplified, unified interface to a large, complex subsystem, making the subsystem
easier for clients to use.

Behavioral Design Patterns

• Behavioral patterns are concerned with communication, interaction, and the assignment of
responsibilities among objects.
• They describe complex control flows and how objects collaborate to perform specific tasks,
increasing flexibility in communication.
• These patterns often define algorithms and delegate control, making the system's behavior
easier to understand and modify.
• A critical example is the Observer pattern, which defines a one-to-many dependency where
a central Subject automatically notifies all its registered Observers when its state changes,
which is fundamental to event handling and user interface (UI) development.
• Another is the Strategy pattern, which defines a family of algorithms, encapsulates each one,
and makes them interchangeable, allowing clients to select an algorithm at runtime.

Implementation Issues
This final phase translates the models into executable code, where theoretical design meets practical
constraints.
• Model to Code Mapping: Ensuring the design's structural integrity is maintained in the
code. For example, a Composition relationship in UML must be enforced by managing the
lifecycle of the contained object in the code (e.g., creating the part when the whole is
created).
• Handling Exceptions and Error Codes: The design must specify how exceptions are
raised and caught, often using checked vs. unchecked exceptions, to ensure Robustness.

Page | 17
Software Engineering – Module 4
• Code Optimization and Refactoring: Initial implementation often reveals areas of
inefficiency or overly complex code. Refactoring (improving the internal structure without
changing external behavior) is a continuous process guided by design principles.
Example Refactoring: Extracting a method, replacing conditional logic with the Strategy
pattern.
• Testing Strategy: Unit testing is fundamentally driven by the OOD. Each Class must have
unit tests covering its responsibilities and ensuring all implemented interfaces fulfill their
contracts. Integration tests then verify the correct messaging modeled in the Sequence
Diagrams.
• Build and Deployment: Managing build scripts, dependency resolution, and packaging the
final artifacts. This aligns directly with the Deployment Diagram, ensuring the right code
lands on the right server nodes.

Page | 18