Software Architecture

1. Software Architecture
Ahmed Misbah

2. Agenda (Day 1)
• Defining Software Architecture
• Architecture Decomposition
– Decomposition Strategies
– Tiers
– Layers
• Service-Level Requirements (SLRs)
– List of SLRs
– Impact of Dimensions on SLRs
– Common Practices for Improving SLRs

3. Agenda (Day 2)
• Technologies used in Tiers:
– Client Tier Technologies
– Web/Presentation Tier Technologies
– Business Tier Technologies
• Integration and Messaging
• Security
• Topics we did not cover
• Software Architecture Document
• Workshop

4. Rules
• Phones silent
• No laptops
• Questions/Discussions at anytime welcome
• 10 minute break every 1 hour

5. DEFINING SOFTWARE
ARCHITECTURE

6. What is Software Architecture?(1/2)
Architecture can be summarized as being about
structure. It’s about the decomposition of a
product into a collection of components/modules
and interactions. This needs to take into account
the whole of the product, including the
foundations and infrastructure services that deal
with cross-cutting concerns such as
security/configuration/error handling (for a piece
of software).

7. What is Software Architecture?(2/2)
Architecture is a set of structuring principles that
enables a system to be comprised of a set of
simpler systems each with its own local context
that is independent of but not inconsistent with
the context of the larger system as a whole
Both definitions focus on system structure

8. Difference between Design and
Architecture
• Architecture is about the what and where
• Design is about the how

9. Difference between Design and
Architecture
“All architecture is design but not all design is
architecture. Architecture represents the
significant design decisions that shape a system,
where significant is measured by cost of change”
Grady Booch

10. Difference between
Architecture/Design and Coding
• Architecture and Design are not coding,
coding is not design nor architecture
• Even when detailed procedural designs are
created for program components, the level of
abstraction of the design model is higher than
source code

11. Software Architecture Roles

12. Architectural Drivers
• Functional Requirements:
– The system shall provide a facility to display the
current account balance
• Software Quality Attributes:
– The balance should appear within 1 minute
• Constraints:
– The system must be developed using Java
technologies

13. Seven Layers of Architecture
• Global Architecture -> Standards (e.g. OSI
model)
• Enterprise Architecture -> System of Systems
• System Architecture -> Architecture Styles
• Application Architecture -> Subsystems
• Macro-Architecture -> Frameworks
• Micro-Architecture -> Design Patterns
• Objects -> Idioms (Do and Don’ts)

14. Architect’s Responsibilities
• Find and monitor architectural drivers
• Determine architectural significance
• Perform technology and teaming selections
• Devise the big picture
• Evaluate the architecture
• Evolve the architecture
• Sell the architecture
• Communicate the architecture
• Guard the architecture
• Program and review code
• Harvest and communicate idiomatic patters

15. ARCHITECTURE DECOMPOSITION

16. DECOMPOSITION STRATEGIES

17. Decomposition Strategies
• Decomposition can be broken down into ten
basic strategies:
– Group 1 — Layering or Distribution
– Group 2 — Exposure, Functionality, or Generality
– Group 3 — Coupling and Cohesion or Volatility
– Group 4 — Configuration
– Group 5 — Planning and Tracking or Work Assignment
• For any strategies that are grouped together, you
choose one of the strategies and then move on to
the next grouping

18. Group 1 - Layering
• Layering decomposition is some ordering of
principles, typically abstraction
• The layers may be totally or partially ordered
• Layering can be by layers or tiers, as explained
later

19. Group 1 - Distribution
• Distribution is a primary technique for
building scalable systems
• Distribution is among computational
resources

20. Group 2 - Exposure
• Exposure decomposition is about how the
component is exposed and consumes other
components
• Any given component fundamentally has three
different aspects:
– Services deals with how other components access this
component
– Logic deals with how the component implements the
work necessary to accomplish its task
– Integration deals with how it accesses other
components services

21. Group 2 - Functionality
• Functionality decomposition is about grouping
within the problem space. That is, order
module or customer module.

22. Group 2 - Generality
• Generality decomposition is determining
whether you have a reusable component that
can be used across many systems
• Be careful not to make assumptions that a
component may be used by another system in
the future and build a reusable component for
a requirement that does not exist yet

23. Group 3 - Coupling and Cohesion
• Cohesion
o the degree to which the elements of a module belong
together
• Coupling
o is the manner and degree of interdependence
between software modules
• What we want is High Cohesion and Low/Loose
Coupling

24. Group 3 - Volatility
• Volatility decomposition is about isolating
things that are more likely to change
• For example, GUI changes are more likely than
the underlying business rules

25. Group 4 - Configuration
• Configuration decomposition is having a target
system that must support different
configurations, maybe for security,
performance, or usability
• It’s like having multiple architectures with a
shared core, and the only thing that changes is
the configuration

26. Group 5 - Planning and Tracking
• Planning and Tracking decomposition is an
attempt to develop a fine-grained project plan
that takes into account:
– Ordering is understanding the dependencies
between packages and realizing which must be
completed first
– Sizing is breaking down the work into small-
enough parts so you can develop in a iterative
fashion without an iteration taking several months

27. Group 5 – Work Assignment
• Work Assignment decomposition is based on
various considerations, including physically
distributed teams, skill-set matching, and
security areas

28. Group 5 – Work Assignment
Conway’s Law:
organizations which design systems ... are
constrained to produce designs which are
copies of the communication structures of
these organizations
Melvin Conway
1967

29. TIERS

30. What is a Tier?
• A tier can be logical or physical organization of
components into an ordered chain of service
providers and consumers
• Components within a tier typically consume
the services of those in an “adjacent” provider
tier and provide services to one or more
“adjacent” consumer tiers

31. Tiers in Architecture
• Client
• Web/Presentation
• Business
• Integration
• Resource

32. 2 Tier Architecture
• Also called Client-Server Architecture
Server
Clients
Protocol

33. 3/Multi Tier Architecture
• Typically has a Client/Presentation Tier,
Business Tier and Database Tier

34. 3/Multi Tier Architecture

35. LAYERS

36. What is a Layer?
• A layer is the hardware and software stack that
hosts services within a given tier
• Layers, like tiers, represent a well-ordered
relationship across interface-mediated
boundaries
• Whereas tiers represent processing chains across
components, layers represent
container/component relationships in
implementation and deployment of services

37. Example

38. Typical Layers in Architecture
Networking Infrastructure
Compute and Storage
Enterprise Services (OS and VM)
Virtual Platform (APIs)
Application

39. Strict an relaxed layering
• Strict layering is where each layer use only
APIs offered by the one layer beneath it
• Relaxed layering is where each layer may use
APIs offered by any layer beneath it

40. SERVICE LEVEL REQUIREMENTS

41. Service Level Requirements (SLRs)
• Also called Non-Functional Requirements or
Software Quality Attributes
• Also called xabilities or ilities

42. List of SLRs (1/4)
• Performance:
– Response Time
• Scalability:
– Increasing load without changing the system
– Vertical Scalability
– Horizontal Scalability
• Reliability:
– Integrity
– Consistency

43. List of SLRs (2/4)
• Availability:
– System is always accessible
• Extensibility:
– Add/modify functionalities without impacting
existing system functionalities
• Maintainability:
– The ability to correct flaws in the existing
functionality without impacting other components
of the system

44. List of SLRs (3/4)
• Manageability:
– The ability to manage the system to ensure the
continued health of a system with respect to
scalability, reliability, availability, performance, and
security
– Deals with system monitoring of the QoS
requirements and the ability to change the system
configuration to improve the QoS dynamically
without changing the system

45. List of SLRs (4/4)
• Security:
– The ability to ensure that the system cannot be
compromised
– Key concepts:
• Integrity
• Availability
• Confidentially
• Non-repudiation

46. Impact of Dimensions on SLRs
• As you are creating your architecture, you can
think of the layout of an architecture (tiers
and layers) as having six independent
variables that are expressed as dimensions:
– Capacity
– Redundancy
– Modularity
– Tolerance
– Workload
– Heterogeneity

47. Capacity
• The capacity dimension is the raw power in an
element, perhaps CPU, fast network
connection, or large storage capacity
• Capacity is increased through vertical scaling
• Capacity can improve performance,
availability, and scalability

48. Redundancy
• The redundancy dimension is the multiple
systems that work on the same job, such as load
balancing among several web servers
• Redundancy is increased through horizontal
scaling
• Redundancy can increase performance,
reliability, availability, extensibility, and
scalability
• It can decrease manageability and security

49. Modularity
• The modularity dimension is how you divide a
computational problem into separate elements
and spread those elements across multiple
computer systems
• Modularity can increase scalability, extensibility,
maintainability, and security
• It can decrease performance, reliability,
availability, and manageability

50. Tolerance
• The tolerance dimension is the time available
to fulfill a request from a user
• Tolerance can increase performance,
scalability, reliability, and manageability

51. Workload
• The workload dimension is the computational
work being performed at a particular point
within the system
• Workload is closely related to capacity in that
workload consumes available capacity, which
leaves fewer resources available for other
tasks
• Workload can increase performance,
scalability, and availability

52. Heterogeneity
• The heterogeneity dimension is the diversity
in technologies that is used within a system or
one of its subsystems
• Heterogeneity can increase performance and
scalability
• It can decrease performance, scalability,
availability, extensibility, manageability, and
security

53. Common Practices for Improving SLRs
• Redundancy:
– Load Balancing
– Failover
– Clustering
• Availability:
– Active replication: is performed by processing the
same request at every replica
– Passive replication: involves processing each single
request on a single replica and then transferring its
resultant state to the other replicas
• Performance:
– Increase system capacity
– Increase computational efficiency

55. Common Practices for Improving SLRs
• Extensibility:
– Clearly define the scope in the service-level
agreement
– Anticipate expected changes
– Design a high-quality object model
• Scalability:
– Vertical Scalability: more processors, memory, and
disks
– Horizontal Scalability: more servers

56. Common Practices for Improving SLRs
• Reliability:
– Increase computational efficiency
– Transactions
– Monitor and restart
– Redundancy
– Degradation
– Bound execution time

57. TECHNOLOGIES USED IN TIERS

58. Client Tier Technologies
• Java AWT and Swings
• Java Applets
• Android SDK
• HTML/CSS/JS

59. Web/ Presentation Tier Technologies
• JSPs and Servlets
• JSF
• Spring MVC
• Thymleaf
• Velocity
• Freemarker

60. Business Tier Technologies
• Spring
• EJBs

61. INTEGRATION AND MESSAGING

62. System Integration Choices
Style Share what? Good Bad Examples
Remote
Procedure Call
Functionality Less Complex High Coupling
Less Reliability
RMI
Corba
File
Transfer/Shar
ed File
Data Loose
Coupling
Less Timely
Shared
Database
Data Timely High Coupling
Messaging Both Loose
Coupling
Timely
Middleware
dependency
SOAP
REST
JMS
*MQ

63. Messaging
• Channel (Queue): Virtual pipe between
sender and receiver
• Message: Atomic unit of data
• Endpoint: Gateway of each system or
application to the messaging infrastructure

65. Message Interaction Types
• Request-driven interaction: A client requests
a service from a server and waits for the
response
• Event-driven interaction: An agent publishes
an event about a happening. Interested
subscribers receive the event and may choose
to act accordingly

66. Common Integration Technologies
• JDBC
• JCA
• JAX-WS
• JMS
• ActiveMQ
• RabbitMQ
• Apache Camel
• Spring Integration

67. SECURITY

68. Terminology
• Principal: is an entity (a person or system that
can be uniquely identified) that can be
authenticated by a security module before
system access is allowed or denied
• Credential: is a container of information used
to authenticate a principal (e.g. username and
password)
• Authentication and Authorization

69. Application Security
• Authentication and authorization—Using
credentials
• Message-level data integrity—Using XML
signatures
• Message-level and transport
confidentiality—Using encryption (SSL)

70. Defining Security behavior
• Declarative (e.g. Spring Security
configurations)
• Programmatic (e.g. isUserInRole in JEE)

71. What a Security Model should
contain?
• Underlying system infrastructure (hardware,
including the networking layer and
components)
• User authentication
• User authorization
• Auditing
• Data encryption
• System hardening against specific attacks

72. Common Security Threats
• Man in the middle attacks
• Session hijacking (replaying data)
• Password cracking
• Phishing
• Social hacking/engineering
• Network sniffing
• Cross-site scripting
• SQL Injection
• Denial-of-service

73. Common Technologies
• Java Authentication and Authorization Service
(JAAS)
• Spring Security
• LDAP Servers (e.g. OpenLDAP)
• Apache Shiro

74. TOPICS WE DID NOT COVER

75. Topics we did not cover
• Documenting Architecture using UML
• Design Patterns
• Architecting for the Cloud:
– Resource Pooling
– Rapid Elasticity
– Multi-tenancy

76. SOFTWARE ARCHITECTURE
DOCUMENT

77. Software Architecture Document
1. Front Page
2. Motivation and purpose
3. Product overview
4. Architectural drivers
5. Technology selection and
rationale
6. Main architectural
decisions and rationale
7. Naming and coding
standards
8. Module view
9. Module catalogue
10. Components and
connectors view (C&C)
11. Relevant allocations view
12. Module and Layer API
13. C&C Proto
14. Idiomatic Design Patterns
15. Volatilities and weaknesses
16. Glossary of terms
17. References

78. Thanks You!
Questions?