Introduction to Software Architecture: Chapter 1

1
Introduction to Software Architecture Chapter 1

• Csci501
• Fall2008
• reza_at_aero.und.edu

2
Objectives

• Software Architecture A preview
• The importance of SA
• Architecture vs. Design
• The State of the practice
• The State of Research
• The issues

3
Software Engineering Programming at large

• What is Software Engineering?
• Producing products (or solving real world
  problems) in a cost-effective way using
  scientific knowledge

4
Software Engineering (Cont)

• Key elements of well-engineered software
• The software should be maintainable
• The software should be reliable
• The software should be efficient
• The software should be usable

5
The waterfall model of Software life cycle
Req. analysis specification
Software Architecture design
Coding unit testing
Integration system testing
maintenance
6
What IS SOFTWRAE ARCHITECTURE ? 1

• From 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

7
What IS SOFTWRAE ARCHITECTURE ? 2

• From Unified Process (Jacobson, Booch, Rumbaugh)
• Software architecture encompasses the set of
  significant decisions about the organization of a
  software system
• Selection of the structural elements and their
  interfaces
• Behavior as specified in collaborations among
  those elements
• Composition of these structural and behavioral
  elements into larger subsystems
• Architectural style that guides this organization

8
Capturing Software Architecture - Problem

• Identify architecturally significant requirements
• Actors
• Use cases
• Non-functional
• Constraints
• Use cases vs. User interfaces vs. User Experience

9
Example - Peripheral Actors key to adoption

• Problem provide a way of controlling the sharing
  of PDF files
• Includes posting on the web, sending email, etc.
• Solution provide server
• Supports both simple and complex policies
• PDF Reader operation confirms with server
• How is the system managed? (backup/recovery, load
  balancing, )
• Early on different (better?) methods
• Now can use standard methods from major vendors
  (DB, J2EE app server, )
• Observation be sure that all actors are
  considered
• CMU/SEI - many views/solution
• select the ones you need and you know it works

10
Capturing Solution using 41 Views
Project management Development team
End user functionality
System topology, delivery, installation..
System Integrators Dynamic properties
performance,scalability, availability...
11
Logical Views

• Logical view (or CC-View)
• Describe the architecturally significant elements
  of the architecture such as components (classes)
  and their communication
• Can be specified
• Using UML (class diagram)
• Using ADL

12
Physical view

• Represents how the major processes and components
  are mapped on to application hardware
• E.g. how the database and web servers working
  with database are distributed across a number of
  servers machines

13
Development view

• Represents the internal organization of the
  software components
• E.g., the depiction of a nested package and class
  hierarchy for a java application would constitute
  the devlopment view of an architecture

14
Process view

• Describes the concurrency and coordination
  elements of an architecture
• E.g.,
• in IT application, the main concerns are
  describing multi-threaded or replicated
  components, and the synchronous or asynchronous
  communication mechanism used

15
Use-case view

• Used tie all these views
• They capture the requirements for the
  architecture
• Can be related to one or more views
• Can be used to test/validate the archiecture

16
Alternative to 41 SEI Work known as views and
beyond

• Documents an architecture using
• Module view
• Describe a structural view of the architecture
• Code modules, classes, packages, and subsystems
  in the design
• Component-and-Connector view (uses ADL)
• This view describe the behavioral aspects of the
  architecture using component (e.g., objects) and
  the connectors (e.g., procedure call, CORBA)
• Allocation view
• Shows the mapping between the processes and
  their hardware How they talk to each other using
  NTW or DBASE

17
Why Software Architecture?

• Understanding
• simplifies our ability to understand large
  systems using the right level of abstractions
• Reuse
• Supports reuse at design level
• Evolution
• Exposes the blueprint of the system, which makes
  it easier to understand the implications of
  change
• Analysis
• Provides new opportunities for analysis including
• High-level system consistency checking (type
  checking)
• Conformance to styles (P/F)
• Conformance to system level properties (e.g.
  Performance)

18
Why Software Architecture? 2

• Management issue
• The precise specification of SAs initial
  operational capability requirements and
  possible/future growth allows mgt to identify
  key milestones
• Design
• Routine/normal Design Vs. Innovative/radical
  Design

19
The Current State of the practice 1

• Much of architectural presentation is informal
• Drawings
• Boxes representing processing components
• Arrows representing connections among those
  components
• Useful to present high-level overviews of the
  software (good)
• Useful for commutations (good)
• Ambiguous (bad)

20
The State of Practice 2
21
Hardware DESIGN Vs. Software Design

• Software
• High level design (Architecture)
• Low level design (algorithms Data Structure)
• Code level
• Executable

• Hardware
• Programming
• Logic design
• Circuit

22
The Importance of Architectural design

• Explicit use of architectural design can be seen
• Standardized components
• common set of components forms the basis for a
  set of related operations
• Specific systems can be realized by just adding
  the specialized components
• Product family
• common set of components that form the basis to
  produce a family of closely related producer
• Frameworks (platform)
• A generic set of components that forms the basis
  of a variety of related products need to be
  tailored for specific system
• Domain-specific architectures
• architectural abstractions designed for specific
  class of systems (e.g., DoD and avionic systems)

23
The state of research1

• Architectural Description Languages (ADLs)
• Architecture must be (formally) specified so it
  can verified/evaluated
• Main focus is on glue for integrating system
  elements
• Formal underpinnings of software architecture
• Addresses the imprecision using formal methods
• Formal description of non-functionalities (e.g.,
  security)
• Theories of architectural connection
• Architectural analysis and simulations techniques
• Focus is on new technique to test, predicate, or
  simulate properties of SA
• Architectural development methods
• Finds better processes and methods to integrate
  architectural techniques (e.g., model-oriented
  software architecture)

24
The state of research2

• Architectural recovery and re-engineering
• Focus is on extraction of architectural design
  from legacy code
• Architectural codification and guidance
• Focus is on codifying/documenting architectural
  expertise using patterns/styles
• Used to validate early design decision because
  they have already (e.g., C/S) tested/analyzed and
  work with the existing technologies
• Tools and environments for architectural design
• Focus is on Creation of tool to support various
  kind of architectural activities
• Case studies
• Experiences and lessons learned from
  architectural design and analysis, etc.

25
Key issues

• Trade off between
• Precision vs. understandability
• Precision vs. usability
• formalism vs. incompleteness and incrementally
• identification of a system as an instance of a
  particular architecture for a given problem
• Heterogeneous Architecture vs. Homogenous one
• Suitability of one ADL vs. another ADL
• Single model/view vs. multiple model/views

26
Content Missing Today in Practice

• Understanding and capturing the driving
  qualities of the architecture (NFR)
• Use of a set of Views (blueprints) in
  representing architectures
• Reuse in terms of architectural styles
• Identifying, evaluating, and documenting
  architectural decisions with a rationale
• Use of Architecture Evaluation to ensure system
  level qualities

27
Stakeholders and their Concerns
End-users how dependable is the system?
Maintainers how to change?
Management how to keep track of milestones,
budget, etc
Acquirers Neat features, low cost, short time to
market, parity with competing products!
Developers Low cost, timely delivery, not change
very often!
Software Architect
28
Examples of Driving Qualities

• observable at Runtime
• Performance
• Security
• Availability
• Reliability
• Usability
• Scalability

• Not observable at Runtime
• Modifiability
• Portability
• Reusability
• Integrability
• Testability

• Business Qualities
• Time to market
• Cost
• Projected lifetime of the system
• Targeted market
• Rollout schedule
• Extensive use of legacy systems

• Qualities of the Architecture
• Conceptual integrity
• Correctness and completeness

29
Architecture Evaluation 1

• Why undertake architecture evaluation?
• Architectural decisions have a big bearing on the
  product quality attributes (performance,
  evolution, availability,)
• Architecture influences team structure and other
  project management decisions
• Any change in future, can be very costly
• How/who Architecture is evaluated?
• A team of independent technical experts try to
  demolish the design by locating the potential
  problems if any.

30
Architecture Evaluation 2

• Inputs to an architecture evaluation
• Proposed architecture and supporting
  documentation
• Outputs from an architecture evaluation
• Selecting between competing architectures
• Ability/inability to meet quality attribute
  expectations, a risk mitigation approach rather
  than precise value prediction
• Improved representation, more clarity on product
  quality requirements, architectural hotspots
• Who participates in an architecture evaluation?
• Evaluators, Development team stakeholders like
  project manager, architect, tech leads, customers
  and other stakeholders
• When is an architecture evaluation done?
• Early when core requirements are clear and
  candidate approaches identified
• 5. Some of the methods ATAM, SAAM

31
Benefits of Evaluation

• Risk mitigation/ Confidence giving
• Improves clarity of the architecture being
  evaluated
• Architect explains the architecture to a
  knowledgeable set of people who are not part of
  the project, which helps to improve its clarity
• In the evaluation, new diagrams may be created,
  which can be refined to become part of the
  architecture documentation
• Uncovers opportunities for reuse
• Evaluators are from other projects,
• They may identify reuse for the proposed project
  from past expereinces
• Improves the quality of architectures created in
  the organization
• As many architecture evaluations happen in an
  organization, people get sensitized to the
  questions and issues that get raised in these
  evaluations

32
What Is a Good Architecture Anyway?

• Given a functional specification,the number of
  architectures that can be created to meet the
  specification will be too many
• But which is the better one?
• The architecture that best meets the identified
  driving qualities

33
Acknowledgement

• Some of the slides in this work were originally
  produced
• by Sergey Baranov, Chief Software Architect at
  Motorola
• by Rich Reitman at Cornell University