Skip to main content

Software Architectural Styles

1.    Software Architectural Styles Description:

Sr. #
Style Name
Component Types
Connectors
Configuration / Topology
Quality Attributes
1.                 
Process Control Architecture
Processes
Message Protocol
Arbitrary
·         Performance
·         Reusability
2.                 
Message Bus Architecture
·         Schemas
·         Shared Data Infrastructure
Buses
Network
·         Extensibility
·         Scalability
·         Flexibility
·         Performance
3.                 
Component based Architecture
·         Software package
·         Service
·         Resource containing related functions
Interface
Components are put together on a single platform thus creating a new system
·         Maintainability
·         Performance
·         Reusability
·         Reliability
4.                 
Service Oriented Architecture (SOA)
Services
Communication protocol over network
Varying topology based upon business structure
·         Reusability
·         Maintainability
·         Interoperability
5.                 
Mobile- Code Architecture
·         Execution Dock – Code and State handler
·         Code compiler / interpreter
·         Network protocols
·         Elements for code packaging
·         Transmission data
Network
·         Performance
·         Adaptability
6.                 
Acyclic
Transducers
Data Stream
Acyclic
·         Modifiability
·         Simplicity
·         Robustness
7.                 
Fanout
Transducers
Data Stream
Hierarchy
·         Modifiability
·         Simplicity
·         Robustness
·         Reusability
8.                 
Dataflow Network
Transducers
Data Stream
Arbitrary
·         Modifiability
·         Simplicity
·         Robustness
9.                 
Closed Loop Control
·         Embedded process
·         Functions
Continuous Refresh
Fixed
·         Modifiability
·         Simplicity
·         Robustness
10.            
Information Hiding
Managers
Procedure Calls
Arbitrary
·         Decomposition
·         Abstraction
·         Accuracy
·         Encapsulation
11.            
Lightweight Processes
·         Lightweight Processes
·         Data Structures
·         Threads
·         Shared Data
Arbitrary
·         Performance
·         Scalability
12.            
Abstract Data Types
Managers
Static Procedure Calls
Arbitrary
·         Modifiability
·         Performance
13.            
Distributed Objects
Managers
Remote Procedure  Calls
Arbitrary
·         Performance
·         Scalability
14.            
Process – based Naive Client/Server
Processes
Reply/Request Messages
Star
·         Performance
·         Scalability
15.            
Token Passing
Processes
Message Protocols
Arbitrary
·         Performance
·         Scalability
16.            
Probe/Echo
Processes
Message Protocols
Incomplete Graph
Scalability
17.            
Replicated Worker
Processes
Message Protocol
Hierarchy
·         Performance
·         Scalability
18.            
Transactional Database
Memory Computations
Transaction Streams (queues)
Star
·         Performance
·         Scalability

2.    Software Architectural Style Representation:

1.     Process Control Architecture:


2.     Message Bus Architecture:


3.     Component Based Architecture:


4.     Service Oriented Architecture:


5.     Mobile Code Architecture:


6.     Acyclic Architecture:


7.     Fanout Architecture:


8.     Dataflow Network Architecture:


9.     Closed Loop Control Architecture:


10. Information Hiding Architecture:


11. Lightweight Processes Architecture:


12. Abstract Data Types Architecture:


13. Distributed Objects Architecture:


14. Process-based Naïve Client/Server Architecture:


15. Token Passing Architecture:


16. Probe/Echo Architecture:


17. Replicated Worker Architecture:


18. Transactional Database Architecture:


3.    References:

·         Len Bass, Paul Clements, Rick Kazman: Software Architecture in Practice, Second Edition. Addison-Wesley, 2003.
·         Fowler, Martin:Patterns of Enterprise Application Architecture. Addison-Wesley, 2002.
·         Microsoft Patterns and Practices. Microsoft Press, 2009.
·         David Garlan, Mary Shaw: An Introduction to Software Architecture. CMU, 1994


Comments

Popular posts from this blog

Software Architecture Views and Structures

Description of Views: In the year 1995 Kruchten presented his 4+1 architectural view model consisting of the following five types of views: Logical Development Process Physical Scenario Later with further development and research in the domain of architectural view following new views were developed to represent their respective structures: Views Sub-View of Description Logical None Highlights the functionalities provided by the system to the end-users. Unified Modeling Language (UML) diagrams such as the Class diagram, Domain diagram, Use Case diagram, State diagrams and Activity diagrams can be used to represent the logical view of the architecture. Development None It is also known as an implementation view. It is mainly concerned with the software project management. It represents the system with the programmer’s perspective. Process None It deals with the representation of...

Overview of MISRA C++ (2008)

Introduction Software to Control Autonomous Car MISRA C ++ is a software development standard for C and C++ programming language that aims to facilitate code portability and reliability in the context of embedded systems, specifically those systems programming in ANSI C. Its mission is:  “   To provide assistance to the automotive industry in the application and creation within vehicle systems of safe and reliable software ” MISRA - A Brief History In 1998 MISRA targeted only the automotive industry but later released it focus on generic rules for developing safety-critical applications such as: anti-lock braking system  (ABS), and auto-pilot software system etc. No major changes have been made to the MISRA C++ standard after the version released in the year 2008. Every autonomous vehicle developed can only be allowed for commercial or industrial use if each of its hardware and software component adheres to the required standards. ...

How traceability of non-functional requirements is managed throughout the software development process?

1. Requirements Traceability: Requirements traceability is the process of describing and keeping track of a set of requirements throughout the system’s lifecycle. The process assists in managing changing requirements of a particular software product. Requirements traceability of is two types, forward traceability where a particular requirement involved during the design and implementation phases of the software system, and backward requirement traceability where a particular requirement is being traced back to its source. 2. Proposed Solutions for the Traceability of Non - Functional Requirements : The author J. Merilinna [8], proposed a framework supported by a tool to trace the non-functional requirements in both forward and backward direction. The proposed method is based on the context of DSM (Domain Specific Modeling).  The NFR+1 framework involved are used for the elicitation, definition and redefinition of the system’s non-functional requirements. The...