Software Architecture Session1

SOFTWARE ARCHITECTURE

Contents

• Why architecture?• What is architecture?• Why Software Architecture?• What is Software Architecture?• The Architecture Business Cycle (ABC)• The Architecture Process• What makes a Good Architecture?

05:20 PM 2SEPS ZG651 Software Architectures

Analogy with Traditional Architecture

Architecting a doghouse Architecting a house

Built most efficiently and timely by a teamRequires ModelingWell-defined processPower tools

Can be built by one person Requires Minimal Modeling Simple process Simple tools


Architecting a high rise ?

What will it require?05:20 PM 4SEPS ZG651 Software Architectures

Kinds of civil architecture• Community

– houses, flats and apartments, gardens, education, hospitals, religion

• Commerce– shops and stores, restaurants, hotels, office buildings, banks, airports

• Industry– industrial buildings, laboratories, farm buildings

• Leisure– sport, theaters and cinemas, museums


Why Software Architecture?

• Communication among stakeholders• Early design decisions• Transferable, reusable abstraction of a system


What is Software Architecture?

• Bass, Clements, and Kazman. Software Architecture in Practice, “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.”


What is Software Architecture?

• Implications of this definition:– architecture defines components– systems can comprise more than one structure– every software system has an architecture– the behavior of each component is part of the architecture


Influences on Architecture

Source : Bass, Clements, and Kazman. Software Architecture in Practice,


The Architecture Business Cycle

• For decades, software designers have been taught to build systems based exclusively on the technical requirements.

• Software architecture encompasses the structures of large software systems:– abstract view– eliminates details of implementation, algorithm, &

data representation– concentrates on the behavior & interaction of “black

box” elements


Architecture Business Cycle (ABC)



Where do Architectures Come From?

• The result of a set of business and technical decisions.

• In any development effort, the requirements make explicit some - but only some - of the desired properties of the final system.

• Failure to satisfy non-documented constraints can cause as many problems as if it functioned poorly.


Influence of stakeholders on the Architect



Architectural Influences

• Stakeholders– Each stakeholder has different concerns & goals, some

contradictory• Development Organization

– immediate business, long-term business, and organizational (staff skills, schedule, & budget)

• Background & Experience of the Architects– repeat good results, avoid duplicating disasters

• The Technical Environment– standard industry practices or common SE techniques


Ramifications of Influences

• Almost never are the properties required by the business & organizational goals consciously understood, let alone fully articulated.– Architects need to know & understand the nature,

source, and priority of constraints on the project as early as possible.

• Architects must identify & actively engage the stakeholders to solicit their needs & expectations.– Use architecture reviews & iterative prototyping.


The Architecture Process

• Creating the Business Case for the system• Understanding the requirements• Creating or Selecting the Architecture• Representing or Communicating the Architecture• Analyzing or Evaluating the Architecture• Implementing based on the Architecture and

Ensuring Conformance


What makes a Good Architecture?

• No such thing as an inherently good or bad architecture.

• Architectures are more or less fit for some stated purpose.

• Architectures can be evaluated - one of the great benefits of paying attention to them - but only in the context of specific goals.

• Rules of Thumb: process & product (structural) recommendations


Rules of Thumb (pg 15 & 16)

• Process Recommendations:– include functional requirements and a prioritized list of

quality attributes the system must satisfy– analyze & formally evaluate before it is too late to change

• Product Recommendations:– well-defined modules using principles of information

hiding & separation of concerns– separate modules that produce data from those that

consume data to increase modifiability & staged upgrades

– write tasks or processes to allow easy reallocation, perhaps at runtime


Summary

05:20 PM SEPS ZG651 Software Architectures 19
