Architecture

Arnon Rotem-Gal-Oz
Product Line Architect
[email protected]
http://www.rgoarchitects.com
Agenda
Why Software Architecture?
What’s Software Architecture?
Architecture types ? Levels ???
Introduction to Architecture Documentation
Discussion
What’s Software Architecture
 Architecting a dog house

Can be built by one person

Requires
Minimal modeling
Simple process
Simple tools

Kruchten
 Architecting a house

Built most efficiently and timely by a team

Requires
Modeling
Well-defined process
Power tools

Kruchten
 Architecting a high rise

Kruchten
Differences
Scale
Process
Cost
Schedule
Skills and development teams
Materials and technologies
Stakeholders
Risks
Agenda
Why Software Architecture?
What’s Software Architecture?
Architecture types ? Levels ???
Introduction to Architecture Documentation
 Architecture defined
Software architecture is what software
architects do

Beck
 Architecture defined
Formal Definition
IEEE 1471-2000
Software architecture is the fundamental organization
of a system, embodied in its components, their
relationships to each other and the environment, and the
principles governing its design and evolution

IEEE 1471-2000
 Architecture defined
Another Go
Software architecture encompasses the set of
significant decisions about the organization of a
software system
Selection of the structural elements and their
interfaces by which a system is composed
Behavior as specified in collaborations among those
elements
Composition of these structural and behavioral
elements into larger subsystems
Architectural style that guides this organization

Booch, Kruchten, Reitman, Bittner, and Shaw

 Architecture defined
Few More
Perry and Wolf, 1992
A set of architectural (or design) elements that have a particular form

Boehm et al., 1995

A software system architecture comprises
A collection of software and system components, connections, and constraints
A collection of system stakeholders' need statements
A rationale which demonstrates that the components, connections, and constraints define a system that, if
implemented, would satisfy the collection of system stakeholders' need statements

Clements et al., 1997

The software architecture of a program or computing system is the structure or structures of the
system, which comprise software components, the externally visible properties of those
components, and the relationships among them

http://www.sei.edu/architecture/definitions.html
Common elements 1/2
Architecture defines major components
Architecture defines component relationships
(structures) and interactions
Architecture omits content information about
components that does not pertain to their
interactions
Behavior of components is a part of
architecture insofar as it can be discerned
from the point of view of another component
Common elements 2/2
Every system has an architecture (even a
system composed of one component)
Architecture defines the rationale behind the
components and the structure
Architecture definitions do not define what a
component is
Architecture is not a single structure -- no
single structure is the architecture
Architecture is Early

Architecture represents the set of earliest design

decisions
Hardest to change
Most critical to get right
Architecture is the first design artifact where a
system’s quality attributes are addressed
Architecture Drives

Architecture serves as the blueprint for the

system but also the project:
Team structure
Documentation organization
Work breakdown structure
Scheduling, planning, budgeting
Unit testing, integration
Architecture establishes the communication
and coordination mechanisms among
components
 Architecture vs. Design
Architecture: where non-functional decisions are cast, and functional
requirements are partitioned
Design: where functional requirements are accomplished

non-functional architecture
requirements
(“ilities”)

functional
requirements design
(domains)

Important : this is a general guideline – sometimes the borders are blurred

System Quality Attribute
Performance
Availability Time To Market
Usability Cost and Benefits
End User’s view Projected life time Business
Security Community
Targeted Market
view
Integration with
Legacy System
Maintainability
Roll back Schedule
Portability
Reusability Developer’s view
Testability

A list of quality attributes exists in

ISO/IEC 9126-2001 Information Technology – Software Product Quality
Agenda
Why Software Architecture?
What’s Software Architecture?
Software Architecture types ? Levels ???
Introduction to Architecture Documentation
Business Architecture
Concerned with the business model as it
relates to an automated solution.
E-business is a good candidate
Structural part of requirements analysis.
Domain Specific
Technical Architecture
Specific to technology and the use of this
technology to structure the technical points
(Technology Mapping) of an architecture
.NET
J2EE
Hardware architects
Solutions Architecture
Specific to a particular business area (or
project) but still reliant on being a technical
focal point for communications between the
domain architect, business interests and
development.
Enterprise Architecture
The organizing logic for a firm’s core
business processes and IT capabilities
captured in a set of principles, policies and
technical choices to achieve the business
standardization and integration requirements
of the firm’s operating model.
Concerned with cross project/solution
architecture and communication between
different practices in architecture.
Product Line Architecture
Common Architecture for a set of products or
systems developed by an organization
Product Line - Initiation
Evolutionary
Product line architecture and components evolve
with the requirements posed by new product line
members.
Revolutionary
Product line architecture and components developed to
match requirements of all expected product-line
members
Agenda
Why Software Architecture?
What’s Software Architecture?
Architecture types ? Levels ???
Introduction to Architecture Documentation
IEEE 1471 - Recap
Recommended Practice for Architectural
Description of Architectural Description of
Software-Intensive Systems
Define the Relations between
Stakeholders
Concerns
Views
Viewpoint
Models
Architectural Description
 Documentation Conceptual Model

IEEE 1471-2000
Stakeholders & their concerns
Maintainer Functionality
Price
End User
Dev Costs
Customer On Time Delivery
Sales
Performance
Stability & Maintainability
Dev Manager
Ease of Use
Developer Ease of Debugging
Modifiability

Sys Admin Testability & Traceability

Structure & dependency between component

Ease of Installation
Ease of Integration
 Documentation Conceptual Model

IEEE 1471-2000
Discussion
What views do you know / use
Views, Views and more Views
RUP – 4 + 1
RM-ODP – 5
DODAF – 3 (top level)
Zachman – 36(!)

MS – Well…
RUP – 4+1
 RM-ODP Viewpoints (2001)
Manager
Business model
Database Modeler Enterprise Designers
Logical, data modeling Logical view of services

Information Computational

Operating Sys. Engineer Developer

Servers, Comm, Physical view of
data and services
Technology (IDL, WSDL)
Engineering
DODAF (3 Main Views)
DoDAF Products 1/2
DoDAF Products 2/2
Zachman Framework
Data Function Network People Time Motivation
(What) (How) (Where) (Who) (When) (Why)

Scope (Ballpark) view

Owners View (Enterprise Model)

Designers View (System Model)

Builder’s View (Technology Model)

Out of Context View (Detailed Model)

Operational View (Functioning)

Old Model
MSF 3.0 + Views
Aimed at business
Contextual executives

Conceptual
Aimed at business
process owners

Logical Aimed at architects and

designers

Physical
Aimed at designers and
developers
Old Model
MSF 3.0 + Views
Business strategies &
Contextual processes
Applications View

Technology View
Information View
Applications to facilitate
Business View

Conceptual business process

Information needed to
Logical
manage business

Technology to support
Physical
business & application
needs
New Model
set of views and artifacts -
Business
Business Technology
Technology
Capabilities
Capabilities Manual
Manual Architecture
Architecture
Reconciliation Procedures
Procedures
BusinessProcesses
Business Processes Constraints
andEntities
and Entities
Reconciliation

Services,Messages,
Messages, Logical
Logical
Services, Constraints DataCenter
Center
Applications,Endpoints
Applications, Endpoints Data
Abstraction/
Abstraction/ Refinement
Refinement Physical servers &
XML,Projects,
XML, Projects,
segments
DBs,Classes,
DBs, Classes,Code
Code
Deployment
Deployment
packaged into Units deployed on
Units
Can be mapped…
Business Applications Information Technology
Business
Business Technology
Technology
Capabilities
Contextual
Capabilities Manual
Manual Architecture
Architecture
Reconciliation Procedures
Procedures
BusinessProcesses
Business Processes Constraints
Conceptual and Entities
and Entities
Reconciliation
Logical
Logical
Logical Services,Messages,
Services, Messages,
Applications,Endpoints
Endpoints Constraints DataCenter
Data Center
Applications,
Abstraction/
Abstraction/ Refinement
Physical
Refinement
XML,Projects,
Projects,
Physical servers &
XML, segments
DBs,Classes,
DBs, Classes,Code
Code
Deployment
Deployment
packaged into Units deployed on
Units
 Documentation Conceptual Model

IEEE 1471-2000
Models
Non-standard Models
ADL
UML
DSL
 “Non Standard” - Block
Diagrams
Rich UI Web UI Controls

Exception Management
Service Interface
Authentication

Configuration
Authorization

Log & Trace

Monitoring
Activity Business Rules
Signing

Human Workflow Workflow

Service Agents DAL

E-Publish EAI ECM DW OLTP

An ADL Example (in ACME)
System simple_cs = {
Component client = {Port send-request}
Component server = {Port receive-request}
Connector rpc = {Roles {caller, callee}}
Attachments : {client.send-request to rpc.caller;
server.receive-request to rpc.callee}
}

rpc
client server
caller callee
send-request receive-request
ADL - Pros
ADLs represent a formal way of representing
architecture
ADLs are intended to be both human and machine
readable
ADLs support describing a system at a higher level
than previously possible
ADLs permit analysis of architectures –
completeness, consistency, ambiguity, and
performance
ADLs can support automatic generation of
simulations / software systems
ADL - Cons
There is not universal agreement on what ADLs
should represent, particularly as regards the behavior
of the architecture
Representations currently in use are relatively
difficult to parse and are not supported by
commercial tools
Most ADLs tend to be very vertically optimized
toward a particular kind of analysis
Most ADL work today has been undertaken with
academic rather than commercial goals in mind
UML 2.0
13 diagram types
UML
DSL
Business
Business Technology
Technology
Capabilities
Capabilities Manual
Manual Architecture
Architecture
Reconciliation Procedures
Procedures
BusinessProcesses
Business Processes Constraints
andEntities
and Entities
Reconciliation

Services,Messages,
Messages, Logical
Logical
Services, Constraints DataCenter
Center
Applications,Endpoints
Applications, Endpoints Data
Abstraction/
Abstraction/ Refinement
Refinement Physical servers &
XML,Projects,
XML, Projects,
segments
DBs,Classes,
DBs, Classes,Code
Code
Deployment
Deployment
packaged into Units deployed on
Units
ADL - revisited
ADLs are essentially a DSL for architecture
The Architecture DSLs in VSTS – can be
considered as an ADL
The difference – VSTS has a set of languages
instead of one trying to encompass all views
Discussion
What’s the “best” modeling techniques
 Documentation Conceptual Model

IEEE 1471-2000
Discussion
How much documentation
Famous Last Words…
“It is a very humbling experience to make a
multimillion-dollar mistake, but it is also very
memorable….” (Fred Brooks - “Mythical Man-Month”
p.47)
The Need of Architecture
The Winchester “Mystery” House

38 years of construction – 147 builders 0 architects

160 rooms – 40 bedrooms, 6 kitchens, 2 basements, 950 doors
65 doors to blank walls, 13 staircases abandoned, 24 skylights in floors
No architectural blueprint exists