1. TAL 7011 - Lecture 1 Introduction to Software Architecture

2. Lecture 1 - Outline What is software architecture?
Why is architecture important?
Architecture structures, views and models
Types of software architecture
What makes good architecture? – Some recommendations
Software architect
Introduction to Software Architecture

3. Architecting a dog house
Can be built by one person
Requires
Minimal modeling
Simple process
Simple tools

4. Architecting a house Built most efficiently and timely by a team
Requires
Modeling
Well-defined process
Power tools

5. Architecting a high-rise

6. Early architecture
Progress
- Limited knowledge of theory

7. Contemporary architecture
Progress
- Advances in materials
- Advances in analysis
Scale
- 5 times the span of the Pantheon
- 3 times the height of Cheops

8. Modeling a house

9. Software Architecture: Definition
The 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.
The Software Engineering Institute
Introduction to Software Architecture

10. Software Architecture: Definition
IEEE
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
Introduction to Software Architecture

11. Software Architecture: Definition
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
Introduction to Software Architecture

12. Software Architecture: Definition
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
Introduction to Software Architecture

13. A typical representation of architecture13
A typical representation of architecture
Discuss what information is missing.
Introduction to Software Architecture 13

14. 14
Definition… again
The 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, an the relationships between them.
We see the elements (CP, MODP, MODR, MODN), but what properties do they or their relationships have?
Introduction to Software Architecture 14

15. Externally visible properties15
Externally visible properties
The assumptions that other elements can make of an element, such as:
its provided services,
performance characteristics,
fault handling,
shared resource usage,
Introduction to Software Architecture 15

16. Why is architecture important?16
Why is architecture important?
Three fundamental reasons:
Communication among stakeholders
a basis for mutual understanding, negotiation, & consensus
Early design decisions
earliest point at which decisions can be analyzed
Transferable abstraction of a system
can promote large-scale reuse
Introduction to Software Architecture 16

17. Earliest Set of Design Decisions17
Earliest Set of Design Decisions
Defines constraints on implementation
Dictates organizational structure
Inhibit or enable a system’s quality attributes
Studying it can predict system qualities
Easier to reason about and manage change
Helps in evolutionary prototyping
Enables more accurate cost & schedule estimates
Introduction to Software Architecture 17

18. Architecture: Transferable & Reusable18
Architecture: Transferable & Reusable
Software Product Lines share a common architecture.
Composing with large, externally developed elements.
It pays to restrict the vocabulary of design alternatives
Permits template-based development
Used as the basis for training.
Introduction to Software Architecture 18

19. Importance of Architecture
If architecture is strategic design, then the rest of the design is the tactical design.
Architecture establishes the context for design and implementation
architecture
design
implementation
CODE
Architectural decisions are the most fundamental decisions; changing them will have significant ripple effects.

20. Architecture vs. Design
Architecture: where non-functional decisions are cast, and functional requirements are partitioned
Design: where functional requirements are accomplished
architecture
non-functional requirements (“ilities”)
design
functional requirements (domains)
Important : this is a general guideline – sometimes the borders are blurred .

21. Architectural Structures21
Architectural Structures
Module structures
Decomposition
Uses
Layered
Class (or generalization)
Component-and-Connector structures
Process (or communicating processes)
Concurrency
Shared data (or repository)
Client-server
Allocation
Deployment
Implementation
Work assignment
Introduction to Software Architecture 21

22. Relating structures to each other22
Relating structures to each other
Each structure provides a different perspective and design handle on a system
Each is valid and useful in its own right
However the structures are not independent, as elements from one structure will be related to elements of others
Many projects have one structure dominant and be the reference for other structures
In larger systems, more structures would be required to manage them compared to smaller systems
Structures represent primary engineering leverage points and provide power to manipulate one or more quality attributes
Introduction to Software Architecture 22

23. 23
Architectural views
Kruchten [1995] identified four views to concentrate on
Logical – “key abstractions” (module view)
Process – addresses concurrency and distribution of functionality (component-and-connector view)
Development – organization of software modules, libraries, subsystems, and units of development (allocation view)
Physical – maps other elements onto processing and communication nodes (allocation or deployment view)
Introduction to Software Architecture 23

24. RUP 4+1

25. Architectural Models Non-standard Models
ADL (Architecture Description Language)
UML (Unified Modelling Language)
DSL (Domain-Specific Language)
Introduction to Software Architecture

26. “Non Standard” - Block Diagrams
Signing
Authentication
Authorization
Rich UI
Monitoring
Log & Trace
Exception Management
Configuration
Controls
Web UI
Service Interface
Activity
Business Rules
Human Workflow
Workflow
Service Agents
DAL
E-Publish
EAI
ECM DW
OLTP
Introduction to Software Architecture

27. 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} }
client
send-request
server
receive-request
caller
callee
rpc
Introduction to Software Architecture .

28. 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
Introduction to Software Architecture .

29. 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
Introduction to Software Architecture .

30. UML 2.0
13 diagram types
Introduction to Software Architecture

31. UML
Introduction to Software Architecture

32. Applications, Endpoints
DSL
Business
Capabilities
Manual
Procedures
Technology
Architecture
Constraints
Reconciliation
Business Processes
and Entities
Reconciliation
Services, Messages,
Applications, Endpoints
Logical
Data Center
Constraints
Abstraction/
Refinement
Abstraction/
Refinement
XML, Projects,
DBs, Classes, Code
Physical servers & segments
Deployment
Units
packaged into
deployed on
Introduction to Software Architecture .

33. Types of Software Architectures33
Types of Software Architectures
Business architecture
Technical architecture
Solutions architecture
Enterprise architecture
Introduction to Software Architecture 33

34. 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

35. 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

36. 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.

37. 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.

38. What makes a good architecture?
Process Recommendations
Architecture should be the product of a single architect or a small group of architects with identified leader.
Architect should have clear functional requirements, prioritized list of quality attributes.
Architecture should be well documented.
Stakeholders should actively involved in review.
Architecture should be analyzed for applicable quantitative measures (eg: max throughput, etc)
Architecture should enable incremental development.
Introduction to Software Architecture

39. What makes a good architecture?
Structural Rules of Thumb
Architecture should have well-defined modules.
Each module should have well-defined interface.
Architecture should never depend on a particular version of commercial product or tool.
Modules that produce data should be separate from modules that consume them.
Use architectural patterns and design patterns whenever possible.
Introduction to Software Architecture

40. Software Architect
An architect is the person, team, or organization responsible for a system’s architecture
The life of a software architect is a long and sometimes painful succession of suboptimal decisions made partly in the dark
Not just a top level designer
Need to ensure feasibility; has skin in the game
Not the project manager
But “joined at the hip”
Not a technology expert
Purpose of the system and “fit”,
Not a lone wolf
Communicator and leader
Introduction to Software Architecture

41. Responsibilities of the architect
Define and validate the system’s architecture
Maintain the conceptual integrity of the system
Assess and attack technical risks to the system
Propose the order and contents of the continuous stream of executable releases
Facilitate communication among team members and resolve conflict
Mentor team members
Along with the project manager, serve as the public persona of the project
Introduction to Software Architecture

42. Learning Outcomes
After completing this lecture, you should be able to:
Define and describe software architecture.
Explain the significance of software architecture.
Describe the different architecture structures, views and models
Describe the different types of software architecture
Identify characteristics of a good architecture.
Explain the role of software architect
Introduction to Software Architecture