Model-Based Software Architecture (MBSA) is an approach that uses formal

models and notations (such as UML) to represent the structure, behaviour, and
deployment of a software system. It acts as a blueprint for both technical and
management aspects of software development.
Importance of Model-Based Architecture
1. Clarity and Abstraction
 Provides a clear and structured representation of system components and
their relationships.
 Helps in managing system complexity by using views like component
view, deployment view, and behaviour view.
2. Communication Tool
 Serves as a common language between developers, architects, testers, and
managers.
 Reduces miscommunication and ensures alignment across stakeholders.
3. Support for Design Decisions
 Facilitates trade-off analysis (e.g., performance vs. scalability).
 Encourages early identification of design flaws or bottlenecks.

Management Perspective of Software Architecture

From a management perspective, software architecture is considered the most
important technical part of a software project. It defines how different
components work together and how teams collaborate efficiently. A good
architecture ensures smooth communication, while a poor one can lead to
project failure.
Three Aspects of Software Architecture
1. Architecture Concept (Blueprint)
o Like a system's master plan or design.
o Contains all needed technical information to build the system (just
like a blueprint in construction).
2. Architecture Baseline (Tangible Output)
 o A real and useful output that shows how the system’s vision can be
achieved within limits like cost, time, and technology.
3. Architecture Description (Human-readable)
o A simplified version of the architecture design.
o Helps people (especially non-technical stakeholders) understand
the system easily.
Why Software Architecture is Important
 It sets key goals and stages of the project (milestones).
 Acts as a bridge between the problem (what’s needed) and the solution
(final product).
 Improves communication between team members and departments.
 Prevents failure by ensuring the system is well-structured.
 Helps in planning, reduces risks, and ensures the project stays on track.
 Needs creativity, and can’t be done fully by automation.

Technical Perspective of Software Architecture

An architecture is made up of different views.
Each view gives a simplified picture of how the system works, instead of
showing every small detail.
There are five main views:
1. Design View
 Shows main structure and functions of the system.
 Explains how the system is organized using class and object diagrams.
2. Process View
 Explains how different parts of the system communicate during
execution.
 Covers topics like multitasking, threads, and communication between
processes.
  Uses deployment and behavioural diagrams (e.g., sequence, state, activity
diagrams).
3. Component View
 Focuses on the source code structure.
 Useful for developers during release and configuration.
 Uses component and behavioural diagrams.
4. Deployment View
 Shows where components run—on which hardware (e.g., servers, cloud).
 Uses deployment diagrams and behavioural diagrams.
5. Use Case View
 Shows how important functions (use cases) are implemented.
 Uses:
o Use case diagrams (static view)
o Behavioural diagrams (dynamic view)
What an Architecture Baseline Should Include
1. Requirement: Critical use cases, system goals, and how features are
prioritized.
2. Design: Details like class names, behaviours, and how components are
related.
3. Implementation: List of all components with details like name, purpose,
and cost (like a bill of materials).
4. Deployment: Working components that show whether key use cases and
quality goals are met.
Engineering Artifacts Sets
PRAGMATIC ARTIFACTS
 Sometimes, people need to review information but can’t understand
technical languages like UML. For example, managers or auditors may
ask: “I don’t know UML. Can you give me something simple like
flowcharts or plain text?”
 Sometimes, people want to review documents but don’t have the special
tools. Most people outside the team don’t have the software to open
technical files, so paper or simple electronic documents must be shared.
Standard formats like UML, spreadsheets, and common programming
languages, along with visualization tools and websites, now make it
easier to share documents online. Documents should use clear, proper
English words. Avoid confusing abbreviations or acronyms unless they
are widely known. This makes documents easier to read and understand,
reduces mistakes, and allows people to review them without paper.
 Good documents are those people actually use.
 Paper documents feel more real. But electronic documents can be
changed quickly, which makes some people worry because they can’t be
sure the document hasn’t been changed since they last saw it.

Management Artifact Set

The management set includes documents that help track, plan, and control the
software development process.
These documents help make sure the project:
 Runs smoothly
 Stays on budget
 Meets its goals
1. Business Case:
 Checks if the project is worth investing in.
 Includes expected revenue, cost, risks, and return on investment (ROI).
 Is updated regularly as new information becomes available.
2. Software Development Plan (SDP):
 Explains how the project will be executed.
  Needs to be regularly updated and shared with all team members.
3. Work Breakdown Structure (WBS):
 Helps track costs and budget.
 Breaks the project into smaller tasks for better management.
4. Software Change Order Database:
 Manages changes in the project.
 Tracks updates efficiently to allow flexibility during development.
5. Release Specifications:
 Defines goals, scope, and evaluation for each software release.
 Adapts as the project grows and needs change.
6. Release Description:
 Summarizes what was achieved in each release.
 Includes performance evaluation compared to original goals.
7. Status Assessment:
 Provides regular updates on progress and risks.
 Includes financial info, staffing, risk assessments, and project milestones.
8. Environment:
 Lists the tools and technologies used for development.
 Includes tools like automation, testing, defect tracking, and programming.
9. Deployment Documents:
 Guides for installing, operating, and transitioning the software.
 Includes user manuals, training materials, and marketing plans.
ARTIFACT SETS
To make building a complete software system easier to manage, different groups
of information are organized into artifact sets. An artifact is a collection of
related information that is usually created and reviewed together as one piece.
During the software life cycle, artifacts are divided into five main sets. Each set
is grouped by the kind of language it uses:
• Management artifacts, which include documents in free-form text, like plans
and reports
• Requirements artifacts, which include organized text and models describing
what the system must do (the problem space)
• Design artifacts, which include models that show how the system will work
(the solution space)
• Implementation artifacts, which include source code files written in
programming languages
• Deployment artifacts, which include files in formats that computers can use
for installation and operation
1. The Management Set
This includes all the documents needed to plan and run a software project.
Examples:
 Work breakdown structure: Lists tasks and tracks money.
 Business case: Shows cost, schedule, and profit.
 Release specs: What features each version will have.
 Development plan: Steps to build the project.
 Change orders & status reports: Track changes and progress.
 Deployment docs: Installation and training materials.
 Environment details: List of tools and platforms used.
These documents are reviewed by team members and stakeholders to make sure
everything is correct and on track.
2. The Engineering Sets
These are grouped into 4 main sets used to build the software:
a. Requirements Set
 Describes what the software must do.
 Checked to make sure it's complete, consistent, and matches the plan.
b. Design Set
 Includes UML diagrams that show how the system works.
 Ensures the design is clear and follows the requirements.
c. Implementation Set
 Includes the actual source code.
 Checked by testing and comparing with the design and requirements.
d. Deployment Set
 Includes the finished product: executable files, installation scripts, etc.
 Tested for real-world use (installation, usage, updates, errors).
Each set is most important at a different project phase:
 Requirements → Inception phase
 Design → Elaboration phase
 Implementation → Construction phase
 Deployment → Transition phase
 Management → Ongoing throughout all phases
3. Modern Tools Used
 Management tools: For planning, tracking, and documentation.
 Requirements tools: To organize what the system should do.
 Design tools: For diagrams and modeling.
 Implementation tools: For coding, testing, debugging.
 Deployment tools: For delivery and system setup.
4. Test Artifacts
These are test files and programs created alongside the software from the start
to end.
Key points:
 Tests are made for each phase (requirements, design, code, deployment).
 Tests are automatic and reusable.
 Testing tools are the same as development tools.
Example (Seismic Data Project):
 Management set: Test plans and issue logs.
 Requirements set: What features need to be tested.
 Design set: Simulators and performance tools.
 Implementation set: Test scripts and test data.
 Deployment set: Final testing tools for the user environment.