Here are some examples of common module-based software architecture structures:- Decomposition: A software system broken down into logical subsystems or modules, each with well-defined responsibilities and interfaces. Example: An e-commerce system decomposed into modules for payment processing, inventory management, order fulfillment etc. - Layered: The system organized as a set of layers where each layer provides services to the layer above and relies on the layer below. Example: Presentation-Business Logic-Data Access layers in a web application.- Class: Modules organized based on common properties or behaviors. Example: Classes in an object-oriented system that represent different entities like Customer, Order, Product etc. - Pipe and Filter
This document provides an overview of software architecture. It defines software architecture as the fundamental organization of a system embodied in its components, their relationships to each other, and the environment. This includes high-level structures like modules, components and connectors, as well as views like logical, process, development and physical. It also discusses architectural patterns, reference models, reference architectures and the importance of architecture in enabling qualities like performance and modifiability. The architecture business cycle and influences on architecture are described. Finally, it outlines common architectural structures like modules, layers, classes, and deployment.
Software Project Cost Management and estimationssuser9d62d6
More Related Content
Similar to Here are some examples of common module-based software architecture structures:- Decomposition: A software system broken down into logical subsystems or modules, each with well-defined responsibilities and interfaces. Example: An e-commerce system decomposed into modules for payment processing, inventory management, order fulfillment etc. - Layered: The system organized as a set of layers where each layer provides services to the layer above and relies on the layer below. Example: Presentation-Business Logic-Data Access layers in a web application.- Class: Modules organized based on common properties or behaviors. Example: Classes in an object-oriented system that represent different entities like Customer, Order, Product etc. - Pipe and Filter
Introduction to Modern Software ArchitectureJérôme Kehrli
Similar to Here are some examples of common module-based software architecture structures:- Decomposition: A software system broken down into logical subsystems or modules, each with well-defined responsibilities and interfaces. Example: An e-commerce system decomposed into modules for payment processing, inventory management, order fulfillment etc. - Layered: The system organized as a set of layers where each layer provides services to the layer above and relies on the layer below. Example: Presentation-Business Logic-Data Access layers in a web application.- Class: Modules organized based on common properties or behaviors. Example: Classes in an object-oriented system that represent different entities like Customer, Order, Product etc. - Pipe and Filter (20)
High Profile Call Girls Nagpur Meera Call 7001035870 Meet With Nagpur Escorts
Here are some examples of common module-based software architecture structures:- Decomposition: A software system broken down into logical subsystems or modules, each with well-defined responsibilities and interfaces. Example: An e-commerce system decomposed into modules for payment processing, inventory management, order fulfillment etc. - Layered: The system organized as a set of layers where each layer provides services to the layer above and relies on the layer below. Example: Presentation-Business Logic-Data Access layers in a web application.- Class: Modules organized based on common properties or behaviors. Example: Classes in an object-oriented system that represent different entities like Customer, Order, Product etc. - Pipe and Filter
2. Topics
What is Software Architecture?
ABC
Architectural Patterns, Reference Models and
Reference Architectures
Importance of Software Architecture
Architectural structures and views
Various Types of Structures
3. Software Architecture
As the size and complexity of software systems
increases, the design and specification of overall
system structure become more significant issue than
the choice of algorithms and data structures.
Structural issues include system organization as a
composition of components, protocols for
communication, interaction through interfaces, etc.
This is the Software Architecture level of design.
4. What is Software Architecture?
A natural evolution of design abstractions.
Involves the description of elements from
which system is built, interactions among
those elements, patterns that guide their
composition, and constraints on the patterns.
Considers system as a collection of
components and their interactions.
5. Components & their Interactions
Components are such things as clients and
servers, databases, layers, etc.
Interactions among components can be procedure
calls, shared variable access, etc.
At the architectural level, we also consider system-
level issues such as capacity, consistency,
performance, etc.
6. Software Architecture
the fundamental organization of a system embodied in its
components, their relationships to each other, and to the
environment, and the principles guiding its design and
evolution [IEEE standard 1471–2000 ].
Software Architecture defines the observable properties
of a software system
Software architecture of a program or computing system is
the structure or structures of the system, which comprise
software elements, the externally visible properties of
those elements and the relationships among them (Len
Bass)
Software architecting means the process of creating
software architectures
7. Architecture vs. Design
“All architecture is design, not all design is
architecture”.
Architectural design is outward looking
Focus on stakeholders, not technology
Architecture doesn't describe the complete
characteristics of components – Design does.
8. Architectural influences
Influences
System Stakeholders
Developing organization
Architects’ background and experience
Technical environment
Ramification of influences on architecture
Know your constraints
Early engagement of stakeholders
13. Architecture Business Cycle (ABC)
Software architecture is a result of technical,
business and social influences.
These are in turn affected by the software
architecture itself.
This cycle of influences from the environment
to the architecture and back to the
environment is called the Architecture
Business Cycle (ABC).
14. ABC Activities
Creating the business case for the system
Understanding the Requirements
Creating/selecting the architecture
Communicating the architecture
Analysing or evaluating the architecture
Implementation based on architecture
Ensuring conformance to an architecture
15. Software Architecture
What is the nature of the elements?
What are the responsibilities of the elements?
What is the significance of the connections?
What is the significance of the layout?
Figure: Underwater Acoustic System
16. Architectural Patterns
An architectural pattern is a description of
element and relation types together with a set
of constraints on how they may be used
these constraints define a set or family of
architectures that satisfy them
They exhibit known quality attributes
client-server is a common architectural pattern
Client and server two elements
Coordination described by the protocol server uses
Multiple clients can exist
17. Reference Model
A reference model is a division of
functionality together with data flow between
the pieces
reference model is a standard decomposition
of a known problem into parts that
cooperatively solve the problem
Show the maturity of a particular domain
What the various parts of a compiler?
How they interact with each other to perform a
particular task?
18. Reference Architecture
A reference architecture is a reference model
mapped onto software elements (that
cooperatively implement the functionality
defined in the reference model) and the data
flows between them.
Java Platform, Enterprise Edition (Java EE)
Java Platform, Enterprise Edition (Java EE) s
19. Other point-of-views
Software architecture is concerned with:
Stakeholders
System-Level Structures
System qualities
Software architecture involves:
Understanding domains, problems and solutions
Making design decisions & tradeoffs
Delivering working systems
20. Importance of Software Architecture
Communication among stakeholders
SA presents a common abstraction of a system
Customers are concerned that
Software is reliable and available
Architecture can be implemented on schedule and within
budget
SA allows teams to work independently
21. SA for early design decisions
Implementation constraints
Implementation must follow the structural design decisions
Describe prescribe elements, their interaction and the
responsibilities
Resource allocations as constraints on implementation
Organizational structure
SA defines the highest level system decomposition
This is used for the work breakdown
Planning, budgeting, scheduling, teams, communication
channels, configuration management etc.
22. SA for early design decisions …
SA as system quality enabler
Architecture defines whether a system will inhibit the
desired/required qualities or not
High performance – manage time base behavior of the elements
Inter-element communication ?
Modifiability – responsibilities to elements
Security – inter-element communication and access control
Scalability – localization of resources
Incremental release – manage inter-component usage
Re-usability – restrict inter-element coupling
23. SA for early design decisions …
Managing change
80% of the cost is after initial deployment
Change can be partitioned into 3 groups:
Local: modify a single element
Non-local: multi-element change
Architectural: change the way elements interact with
each other
Deep understanding of the relationships,
performance and behavior of the system is
required to decide on such changes
24. SA for early design decisions …
Evolutionary prototyping
An executable system in the early DLC
Cost and schedule estimation
Team/work distribution more clear
Identify challenging parts
Identify required resources/competencies
25. Architectural Structures and Views
A Structure is the set of elements itself, as they exist
in software or hardware.
A View is a representation of a coherent set of
architectural elements as written by and read by
system stakeholders
A module structure is the set of the system’s module and
their organisation.
A module view is the representation of that structure as
documented by and used by some system stakeholder
Both terms are used interchangeably
26. Types of Architectural Structures
Module structure
The elements are modules – units of
implementation
Assigned areas of functional responsibilities
What is the primary functional responsibility assigned to
each module?
What other software elements is a module allowed to
use?
27. Types of Architectural Structures …
Component-and-connector structures
elements are runtime components (which are the
principal units of computation) and
connectors (which are the communication
vehicles among components)
Can answer questions as:
major executing components and how do they interact?
What are the major shared data stores?
Which parts of the system are replicated?
How does data progress through the system?
What parts of the system can run in parallel?
How can the system's structure change as it executes?
28. Types of Architectural Structures …
Allocation structures
Allocation structures show the relationship
between the software elements and the elements
in one or more external environments in which
software is created or executed.
Can answer questions like:
What processor does each software element execute
on?
In what files is each element stored during development,
testing, and system building?
What is the assignment of software elements to
development teams?
29. broad types of decision that architectural
design involves
How is the system to be structured as a set
of code units (modules)?
How is the system to be structured as a set
of elements that have runtime behavior
(components) and interactions (connectors)?
How is the system to relate to nonsoftware
structures in its environment (i.e., CPUs, file
systems, networks, development teams,
etc.)?
31. Module based structures
Decomposition
Relationship between modules is “is a sub-module of”
The decomposition structure enhances system‘s
modifiability – changes fall in a small number of modules
The modules have associated products (interface
specifications, code, test plans etc)
Uses
The units are modules or procedures or resources on the
interfaces of modules.
One unit uses another if the correctness of the first requires
the presence of a correct version of the second.
Extend or abstract (extract) functionality
32. Module based structures …
Layered
a system of layers emerges when uses
relationship is controlled in a particular fashion
in which a layer is a coherent set of related functionality.
In strict layered structure: layer n may only use
the services of layer n – 1.
Layers are often designed as abstractions (virtual
machines) that hide implementation specifics
below from the layers above – portability
Think of an example?
33. Module based structures …
Class or generalisation
The module units in this structure are called
classes
The relation is "inherits-from" or "is-an-instance-
of."
This view supports reasoning about collections of
similar behavior or capability
34. Component-and-Connector
Process or communicating processes
deals with the dynamic aspects of a running
system
The units here are processes or threads that are
connected with each other by communication,
synchronization, and/or exclusion operations.
The relationship is of attachment, showing how
the components and connectors are hooked
together
It is important to design a system's execution
performance and availability.
35. Component-and-Connector …
Concurrency
A structure which allows the architect to determine
opportunities for parallelism and the locations
where resource contention may occur
The units are components and the connectors are
"logical threads."
A logical thread is a sequence of computation that can
be allocated to a separate physical thread later in the
design process.
Shared data, or repository
components and connectors that create, store,
and access persistent data
36. Component-and-Connector …
Client-server
A structure of components and connectors for a
system built as a group of cooperating clients and
servers
The components are the clients and servers
the connectors are protocols and messages they
share to carry out the system's work
Useful for
separation of concerns
for physical distribution, and
for load balancing (supporting runtime performance).
37. Allocation
Deployment
The deployment structure shows how
software is assigned to hardware-processing
and communication elements
The elements are software (usually a process
from a component-and-connector view), hardware
entities (processors), and communication
pathways.
Relations are "allocated-to,"
which physical units the software elements reside,
"migrates-to," if the allocation is dynamic
38. Allocation …
Implementation
This structure shows how software elements
(usually modules) are mapped to the file
structure(s) in:
system's development,
integration, or
configuration control environments.
Helpful in the management of development
activities and build environment
39. Allocation …
Work Assignment
This structure assigns responsibility for
implementing and integrating the modules to
the appropriate development teams
Work assignment structure has architectural
as well as management implications
40. Which structure to choose?
Not all of them may be relevant
one of the obligations of the architect is to
understand how the various structures lead to
quality attributes
Can you relate the 4+1 approach from the
Rational Unified Process ?
41. Use Case View
Logical View
Dynamic View
Implementation View
Deployment View
ud Manage Employees
AutoEdge System
Manager
(from Actors)
Browse Employees
Update Employee
Create Employee
Delete Employee
Create User
«extend»
«include»
«use»
«use»
cd Users
Architecture Entities::User
- UserEmail: CHARACTER
- UserLogin: CHARACTER
- UserPassword: CHARACTER
Architecture Entities::UserGroups
- UserGroupDescription: CHARACTER
- UserGroupName: CHARACTER
Business Entities::Employee
+ Address: CHARACTER
+ City: CHARACTER
+ email: CHARACTER
- EmployeeLanguage: CHARACTER
+ employmentEndDate: DATETIME-TZ
+ employmentStartDate: DATE
+ FirstName: CHARACTER
+ LastName: CHARACTER
+ MobilePhoneNumber: CHARACTER
+ Notes: CHARACTER
+ PhoneNumber: CHARACTER
+ Position: CHARACTER
+ PostCode: CHARACTER
+ createEmployee() : void
+ deleteEmployee() : void
+ findEmployee() : void
+ isAvailable() : LOGICAL
+ updateEmployee() : void
+ validateEmployee() : void
Architecture Entities::
Language
- Description: CHARACTER
- Language: CHARACTER
0..*
1
1
1
0..* 1
sd Login
Client
(from Architecture Components)
Server Gateway
(from Architecture Components)
Security
(from Architecture Components)
Session Context
(from Architecture Components)
Request("Security", "Login", ...)
isValidUser(Login, password)
ValidUser
[if Valid User]: createSession
sessionID
[if valid user]: sessionID
id Business Entity (Client)
«Program»
proSIproxy.p
- NEW GLOBAL SHARED VARIABLE ghttProxySIproc: HANDLE
+ fetchWhere(CHARACTER, HANDLE, DATASET-HANDLE*) : void
+ saveChanges(CHARACTER, HANDLE, CHARACTER*) : void
«Program»
ClientXxx.p
«Include»
proSIproxyStart.i
- NEW GLOBAL SHARED VARIABLE ghProxySIproc:
«Include»
dsXxx.i
- DEFINE DATASET <dataset-def>:
«Include»
etXxx.i
«include»
ttContext.i
«includes»
includes
includes
«includes»
«realize PERSISTENT»
includes
dd Integration
HQ System
Sonic
Dealer
System 1
Sonic
Dealer
System 2
Sonic
Dealer
System 3
Sonic
Dealer
System n
Sonic
42. 4 + 1 View
Logical. The elements are "key abstractions,"
objects or object classes
Process. This view addresses concurrency and
distribution of functionality.
Development. This view shows the organization of
software modules, libraries, subsystems, and units
of development.
Physical. This view maps other elements onto
processing and communication nodes
43. References and further readings
Chapter 1 &2 from “Software Architecture in
Practice” by Len Bass