Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
• Software Architecture
• Need for Software Architecture
• Objectives of Software Architecture
• Types of IT Architecture
• Architectural patterns and Styles
A blueprint that satisfies the requirements of a
software application
Example software application:
Adrian D.
Smith
(Architect)
William F.
Baker
(Structural
Engineer)
Different Modules
Registration
Loan enquiry
Loan Approval
Customer Officer
Infrastructural
services layer
Presentation layer
Cryptography
Business layer
Access Control service
Authorization Authentication
Logging Services Interface
Audit Trail
Scope :
business
IT systems need to support the business
Policies and principles for governance
Enterprise Applications
conceptual view
logical view
physical view
More views are needed to cover the functional and non-functional
needs of an application
Is critical for domain intensive solutions (banking, financial
services, insurance, etc.)
Understanding the domain and mapping the business and
workflows to technical elements, and integration is the key
to success
IEEE 1471-2000 is a standard for software architecture
Blueprint of the solution described in terms of
technical elements
Their structure
Relationship with each other
Technology platform
What do they :
Review Technical Architecture
Sizing and capacity planning of application hosting
Storage systems
Identification of systems for
Provisioning
Fault-tolerance
Application deployment and security compliance
In the Text Book:
Technical Architect,
Infrastructure Architect are given
as separate roles
What is different?
architecture styles focus on components, connectors,
and their interaction. But not on rationale.
architectural patterns require:
Rationale
Capture common use
Aesthetic (a clever solution)
Provides context, problem, solution
Layers
Context: Decomposition of a complex system
Problem: To handle multiple levels of abstraction
Solution: Group elements into layers with each layer
interacting with the next layer
Broker
Context: Distributed system with autonomous interacting
components
Problem: To loosely couple interacting components
Solution: Uses a mediator component to connect clients to
servers
Model –view controller
Context: UI changes frequently, need to be ported to different
devices with a different look-and-feel
Problem: Model to allow changes to UI without affecting the
functional part
Solution: Separate application into model, view, and controller
Reflection
Context: System providing modification of its own persistence
Problem: Expose modifiable elements while hiding core
elements
Solution: Mechanism to allow change of structure and behavior
dynamically
Service-Oriented Architecture (SOA) is an architectural
style that supports communication between services.
Service :
Is a logical representation of a repeatable business activity that has a
specified outcome (e.g., check customer credit, provide weather data,
consolidate drilling reports)
Is self-contained/autonomous
Access through a well-defined interface
Coarse-grained
Stateless
Loosely coupled
Communicate via messages
May be composed of other services
Is a “black box” to consumers of the service
Service provider and service consumer applications are
loosely coupled by the use of service contract and data
contract.
Service Contract
Interface to use the service
Defines message types exchanged between the service provider and
service consumer
One or more operations to exchange messages (request-reply
exchanges)
Data Contract
Service Registry
Service Provider
Service contract is an interface.
Data contract is an agreement.
Service model :
Key aspect : service consumers and service providers
are loosely coupled to each other.
Service Registry : registry where the services register
Service Provider : publishes the service in the Service
Registry
Service Consumer : locate a service from the registry,
invoke operations on the service
Users
Dispatching
Component model
Distributed Objects
N-tier Applications
Structured Programming
To be more efficient and competitive in the
market, IT must align with the business needs
Reviewing several projects in different
organizations brought out several drivers
Business to adapt to the changing market place
Business Drivers
Technology Drivers
Business
1. Rapid business process changes
2. Reduction of process cycle times
3. Promotion of business through multiple channels
4. Protection of investments in legacy applications
5. Lower total cost of ownership
Technology
1. Application modernization
2. Technology change management
3. Integration and interoperability for enterprise wide
heterogeneous applications
4. Support by product vendors
Dimensions that enable business transformation
are:
Reuse (How many reusable components are
available)
Integration (How easy it is to integrate with
other systems)
Agility (agile infrastructure to make changes
with ease and minimal effort)
Reusability:
By using services
Hub –
Centralized
ESB
Orchestration
Services
Basic reusable components of SOA
Service Contract
Consumers invoke an operation published (in the
service contract) by the service
Data Contract
Consumers provide data as per the data contract
Autonomous
Services
Loosely coupled
Stateless
Composability
Discoverable