01-06-2013, 04:14 PM
Software Architecture
Software Architecture[.ppt (Size: 2.48 MB / Downloads: 240)
Characteristics
Iteration mainly on functional requirements
Few stakeholders involved
No balancing of functional and quality requirements
Why Is Architecture Important?
Architecture is the vehicle for stakeholder communication
Architecture manifests the earliest set of design decisions
Constraints on implementation
Dictates organizational structure
Inhibits or enable quality attributes
Architecture is a transferable abstraction of a system
Product lines share a common architecture
Allows for template-based development
Basis for training
Software Architecture, definition (2)
The software architecture of a 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.
(from Bass, Clements, and Kazman, Software Architecture in Practice, SEI Series in Software Engineering. Addison-Wesley, 2003.)
Architectural Structures
module structure
conceptual, or logical structure
process, or coordination structure
physical structure
uses structure
calls structure
data flow
control flow
class structure
Other points of view
Architecture is high-level design
Architecture is overall structure of the system
Architecture is the structure, including the principles and guidelines governing their design and evolution over time
Architecture is components and connectors
Uses of design decisions
Identify key decisions for a stakeholder
Make the key decisions quickly available. E.g., introducing new people and make them up2date.
..., Get a rationale, Validate decisions against reqs
Evaluate impact
If we want to change an element, what are the elements impacted (decisions, design, issues)?
..., Cleanup the architecture, identify important architectural drivers
Pointers on design decisions
Hofmeister et al, Generalizing a Model of Software Architecture Design from Five Industrial Approaches, Journal of Systems and Software, 2007
Tyree and Ackerman, Architecture decisions: demystifying architecture, IEEE Software, vol. 22(2), 2005.
Kruchten, Lago and van Vliet, Building up and exploiting architectural knowledge, WICSA, 2005.
Lago and van Vliet, Explicit assumptions enrich architectural models, ICSE, 2005.
Deployment Viewpoint
The deployment viewpoint defines how the various elements identified in the logical, process, and implementation viewpoints-networks, processes, tasks, and objects-must be mapped onto the various nodes.
It takes into account the system's nonfunctional requirements such as system availability, reliability (fault-tolerance), performance (throughput), and scalability.
Component and connector views
Process: units are processes, connected by communication or synchronization
Concurrency: to determine opportunities for parallelism (connector = logical thread)
Shared data: shows how data is produced and consumed
Client-server: cooperating clients and servers
Abstract-data-type style
problem: identify and protect related bodies of information. Data representations likely to change.
context: OO-methods which guide the design, OO-languages which provide the class-concept
solution:
system model: component has its own local data (= secret it hides)
components: managers (servers, objects, adt’s)
connectors: procedure call (message)
control structure: single thread, usually; control is decentralized
variants: caused by language facilities
Summary
new and immature field
proliferation of terms: architecture - design pattern - framework - idiom
architectural styles and design pattern describe (how are things done) as well as prescribe (how should things be done)
stakeholder communication
early evaluation of a design
transferable abstraction