T-76.3601 Software Architecture Introduction Tomi Männistö TEKNILLINEN KORKEAKOULU
SA teaching at SoberIT TEKNILLINEN KORKEAKOULU 2
Overview Motivation for software architectures Dealing with increasing complexity What is software architecture? Role of software architecture Architecture design Architecturally significant decisions Role of architect Variability management and software product families Software architectures, diversity and reuse Conclusions TEKNILLINEN KORKEAKOULU 3
Motivation TEKNILLINEN KORKEAKOULU
Building a doghouse Just do it! build and fix TEKNILLINEN KORKEAKOULU 5
TEKNILLINEN KORKEAKOULU 7
Building complex things Involve risk(s) in achieving crucial characteristics, thus: just do it, build and fix or first do, then think may not work. TEKNILLINEN KORKEAKOULU 8
Software complexity software architecture Software development has been, is, and will likely remain fundamentally hard Entire history of software engineering is one of rising levels of abstraction At the highest level of abstraction, every system has an architecture TEKNILLINEN KORKEAKOULU 9 [http://www.booch.com/architecture/]
Some sources of complexity in software development Size Size in terms of LOC, number of nodes, amount of data stored, manipulated or transferred, Important quality (quality attribute, non-functional requirement) Performance (competitive advantage, hard constraints), security, physical resources (memory, bandwidth, energy consumption, weight), Tough domain requirements Medical, military, banking, aviation, space exploration, tiny mobile gadget, Variability Different market segments, culture, personal preferences, price differentiation, legislation, hardware, context, TEKNILLINEN KORKEAKOULU 10
General definition for software architecture Architecture is the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. [IEEE Standard 1471-2000] TEKNILLINEN KORKEAKOULU 11
Roles of software architecture Provide overall structure Big picture Abstraction, high level architecture Document early design decisions and their rationale Enable communication Between stakeholders about architecturally significant decisions and trade-offs From architecture design to implementation Support variability management Addressing diversity Reuse within company Software product family architectures TEKNILLINEN KORKEAKOULU 12
Architecture design TEKNILLINEN KORKEAKOULU
From Problem Domain to Solution Domain Problem domain Solution domain Needs Requirements Business value Features SA System Context TEKNILLINEN KORKEAKOULU 14
Stakeholders are people for whom the system is being built Customer User Concerns General management Product manager System Project manager Developer Sales Marketing Legislation Constraints Solution provider Integrator 15 Maintenance Customer support
Architecturally significant decisions Difficult to fix or change if turn out to be wrong Changing an architecturally significant decision is not a simple matter of programming Cross-cutting Affect many or all components Cannot be fixed in one component Preclude or enable qualities of the system TEKNILLINEN KORKEAKOULU 16
It is the responsibility of the architect to decide what is architecturally significant TEKNILLINEN KORKEAKOULU 17
Role of architect Identify and engage stakeholders Understand and capture stakeholder s concerns Create and take ownership of the architecture definition that addresses the concerns To take leading role in realisation of architecture into a physical product or system [Rozanski & Woods 2005] TEKNILLINEN KORKEAKOULU 18
Software product family fundamentals The role of software architecture in dealing with variability TEKNILLINEN KORKEAKOULU
Software product family / line definitions Set of similar software-intensive systems sharing a common, managed set of features that satisfy the specific market needs and that are developed from a common set of core assets in a prescribed way [Clements & Northrop 2001] A software product family consists of an architecture and assets that are used for producing individuals of the family TEKNILLINEN KORKEAKOULU 20
Software product family Product family architecture Shared assets PF development Product individuals deployment TEKNILLINEN KORKEAKOULU 21
Product family architecture Software architecture By definition supports variation High level of abstraction multiple implementations Product family architecture Explicitly allowed variations Identifying the allowed variation is part of product family architectures responsibility Different variability implementation mechanism exits Build-time parameters, selection of components or subsystems, specialisation, plug-in components, interfaces, middleware,... TEKNILLINEN KORKEAKOULU 22
Conclusions TEKNILLINEN KORKEAKOULU
What are SAs all about? Ensuring that main requirements, qualities in particular, will be achieved before the system is built Managing the risk in achieving Complexity, variability, evolution, Making development of complex software systems routine Representing and documenting the architecture Communication between stakeholders = sharing knowledge = making right decisions (trade-offs) early enough TEKNILLINEN KORKEAKOULU 24