Architectural Views and Fundamental Questions in System Architecture Design

Part 1: Different Architectural Views

Software architecture cannot be fully described by a single diagram or perspective. Multiple architectural views are used to represent different aspects of a system, each addressing the concerns of different stakeholders.

The most widely accepted model is the "4+1" View Model proposed by Philippe Kruchten.

1. Logical View (Design View)

• Describes the functional requirements of the system -- what the system should provide to end users.
• Focuses on the object model of the design (classes, objects, relationships).
• Stakeholders: End users and designers.
• Represented using: Class diagrams, Object diagrams, State diagrams.

Example: How the system is decomposed into key abstractions and objects.

2. Process View

• Describes the dynamic aspects of the system -- how processes communicate and run concurrently.
• Addresses concerns of concurrency, distribution, performance, and scalability.
• Stakeholders: System integrators and performance engineers.
• Represented using: Activity diagrams, Sequence diagrams.

Example: How threads interact and how tasks are scheduled at runtime.

3. Development View (Implementation View)

• Describes the system from a programmer's perspective.
• Focuses on the organization of software modules in the development environment (packages, components, subsystems).
• Addresses concerns of software management, reuse, and portability.
• Stakeholders: Programmers and software managers.
• Represented using: Component diagrams, Package diagrams.

Example: How source code is organized into modules and libraries.

4. Physical View (Deployment View)

• Describes the mapping of software onto hardware.
• Addresses concerns of topology, distribution, delivery, and installation.
• Stakeholders: System engineers and network administrators.
• Represented using: Deployment diagrams.

Example: Which server hosts which component, and how nodes are connected.

5. Scenarios View (Use Case View) -- The "+1"

• Describes the system from the end user's perspective using use cases.
• Acts as the central view that ties all other views together.
• Used to validate and illustrate the architecture.
• Stakeholders: All stakeholders.
• Represented using: Use case diagrams, Interaction diagrams.

Example: A user logs in -- this scenario involves logical, process, development, and physical views simultaneously.

Summary Table

Part 2: Fundamental Questions in Designing a System Architecture

When designing a system architecture, an architect must answer the following fundamental questions:

1. What are the system's functional requirements?

• What must the system do?
• What are the core features and services the system must provide to users?

2. What are the non-functional requirements (Quality Attributes)?

• What are the performance, scalability, reliability, security, and maintainability requirements?
• These often drive major architectural decisions.

3. How should the system be decomposed?

• How should the system be broken down into components, modules, or subsystems?
• What are the responsibilities of each component?

4. How will components communicate and interact?

• What interfaces and protocols will components use?
• Will communication be synchronous or asynchronous?
• How will data flow between components?

5. How will the system be distributed?

• Will the system run on a single machine or multiple nodes?
• How will it handle distributed computing, load balancing, and fault tolerance?

6. What architectural style or pattern should be used?

• Should the system follow layered, microservices, event-driven, client-server, or pipe-and-filter architecture?
• Which pattern best fits the requirements?

7. How will the system handle change and evolution?

• How flexible and extensible is the architecture?
• Can new features be added without major restructuring?

8. What are the technology and platform constraints?

• What programming languages, frameworks, databases, and hardware will be used?
• Are there legacy system constraints?

9. How will the system ensure security?

• How will authentication, authorization, and data protection be handled?
• Where are the security boundaries?

10. How will the system be tested, deployed, and maintained?

• What is the deployment strategy?
• How will the system be monitored and updated after deployment?

Conclusion

Architectural views provide multiple perspectives on a system to satisfy the concerns of different stakeholders. The 4+1 model (Logical, Process, Development, Physical, and Scenarios) is the standard approach. Answering the fundamental architectural questions ensures that the system is well-structured, meets both functional and non-functional requirements, and can evolve over time.

Short Notes

a. Agile Software Development

Agile software development is an iterative and incremental approach to software development that focuses on delivering working software quickly, responding to change, and close collaboration between developers and customers.

Key Principles (Agile Manifesto):

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Characteristics:

• Development is done in short cycles called sprints or iterations (typically 2-4 weeks)
• Requirements are allowed to evolve throughout the project
• Continuous feedback from the customer is incorporated
• Self-organizing, cross-functional teams work together
• Regular reflection and adaptation of processes

Popular Agile Methods:

• Scrum - uses sprints, daily stand-ups, sprint reviews
• Extreme Programming (XP) - focuses on coding practices
• Kanban - visual workflow management

Advantages:

• Faster delivery of working software
• Better adaptability to changing requirements
• Higher customer satisfaction

b. Context Model

A context model is used to illustrate the operational context of a system - it shows what lies outside the system boundaries (the environment in which the system operates) and defines what is included in and excluded from the system.

Purpose:

• To define the system boundary
• To identify external entities (other systems, people, organizations) that interact with the system
• To show the relationships and interactions between the system and its environment

Key Features:

• It does not show the nature of the relationships in detail
• It helps stakeholders understand the scope of the system
• External entities are shown as boxes or actors outside the system boundary

Example Representation:

[Payroll System] <---> [Employee Database]
[Payroll System] <---> [Bank System]
[Payroll System] <---> [HR Manager]

Types of Models Used:

• Activity diagrams can supplement context models to show how the system is used in business processes
• UML use case diagrams can also represent context

Importance:

• Helps avoid scope creep by clearly defining boundaries
• Assists in identifying all external dependencies
• Provides a foundation for further detailed modeling

Version Management

Definition

Version management (also called version control or revision control) is the process of tracking and controlling changes made to software source code, documents, and other files over time. It allows multiple versions of a software system to be stored and retrieved, enabling developers to manage the evolution of software components systematically.

Key Concepts in Version Management

• Version/Revision: A distinct state of a software component at a particular point in time.
• Baseline: A tested, approved version that serves as the basis for further development.
• Repository: A central storage location where all versions of files are maintained.
• Check-in / Check-out: The process of submitting changes to or retrieving files from the repository.

How Version Management is Carried Out

1. Version Identification

Each version of a component is assigned a unique identifier (e.g., v1.0, v1.1, v2.0). Versions may be identified by:

• Sequential numbering
• Date/time stamps
• Attribute-based identification (author, date, purpose)

2. Storage and Repository Management

All versions are stored in a version control repository (e.g., Git, SVN, CVS). The repository maintains:

• Complete history of all changes
• Who made the change and when
• Why the change was made (commit messages)

3. Check-out and Check-in Mechanism

• A developer checks out a file to work on it (may lock it to prevent conflicts).
• After modification, the developer checks in the updated file, creating a new version.

4. Branching and Merging

• Branching: Creating a separate line of development (e.g., for a new feature or bug fix) without affecting the main codebase.
• Merging: Combining changes from different branches back into the main branch.

Main:    v1.0 -----> v1.1 -----> v2.0
                \               /
Branch:          --> fix-branch

5. Change Logging

Every version change is recorded with:

• Description of changes made
• Author name
• Date and time
• Version number

6. Conflict Resolution

When two developers modify the same file, the version management system detects conflicts and assists in resolving them before merging.

Benefits of Version Management

Common Version Management Tools

• Git (most widely used, distributed)
• SVN (Subversion) (centralized)
• CVS (Concurrent Versions System)
• Mercurial

Note: Version management is a core part of Software Configuration Management (SCM), which also includes build management, change management, and release management.