Software Architecture Architecture represents different things from use cases –Use cases deal primarily with functional properties –Architecture deals primarily with non-functional properties Encompasses important decisions about –system organization –structural elements and their interfaces, together with their composite behavior –Composition of structural and behavior elements into progressively large subsystems –Architectural style that guides system organization

Why Architecture Important Complexity, Time and Cost Need architecture for –understanding the system –organize development –Foster reuse –Evolve the system Another perspective –nonfunctional properties play ever important role in software –software systems are developed to be changed, extended, ported –increasing need for enterprise systems - system of systems –base for component-based software development

Understanding Systems Challenges of (complex) software development –complex behavior –complex operating environment –technologically complex –combination of distributed computing, commercial products and platforms –large  development divided into multiple, geographically distributed projects with different time spans Common, sufficiently abstract (high-level) view of system composition and behavior is the basis for understanding and communication

Architecture and Reuse Effective reuse at high-level of abstraction Fundamental issue of reuse is compose-ability –I.e. the ability to insert an existing component into a new structure –Issue of consistent and compatible interfaces –Issue of interaction and control structure Standard is key to reuse –The basis for standardizing reusable components is standard architecture

Where Does Architecture Come From?

Multi-Facets of Architecture - Architecture Baseline

Architecture Patterns or Templates

Ideal Evolution of Architecture

Iterative And Incremental Process

Milestones and Criteria for Evolution Effective process has sequence of clearly articulated milestones that provide the criteria for moving from one phase to another in product cycle Series of iterations and increments within each phase lead to the satisfaction of criteria

Inception Phase Criterion: Viability Identify and reduce risks critical to the system’s viability Move from a key subset of requirements through use case modeling into a candidate architecture Make initial estimate with broad limits, of cost, effort, schedule, and product quality Initiate business case that the product is worth doing (economically) and within broad limits

Elaboration Phase Criterion: Ability to Build System in an Economic Framework Identifying and reducing the risks significantly affecting system construction Specify most of the use cases representing system’s functionality Extending candidate architecture to executable baseline proportions Prepare project plan in sufficient details Make estimate with limits narrow enough to justify a business bid Finalizing the business case - the project is worth doing

Construction Phase Criterion: System Capable of Initial Operation in User Environment A series of iterations, leading to periodic builds and increments, so that throughout this phase, viability of the system (hence the project) is always evident in executable form

Transition Phase Criterion: System Archives Final Operational Capability Modify the product to alleviate problems not identified in earlier phases Correcting defects

Why Iterative And Incremental Development? To get a handle on critical and significant risks early To set forth an architecture to guide development To provide a framework to better handle requirement and other changes To provide a development process through which the staff can work more effectively –Allowing for tactical changes to adjust plans, schedules, etc. –Archiving continuous integration, force developer to closure at regular intervals that accurately indicate the status of project –Attaining early learning

Risks Associated With Software Development Risks related to new technologies –distributed computation, process distribution, synchronization –functions depending on techniques/technologies yet to be developed –new technology changes during development Risks related to architecture –key to large scale development –stableness is essential –changes to architectural standards and frameworks

Risks - continued Risks related to building the right system –finding the right set of (functional and non-functional) requirements –handling requirement changes Risks related performance –response time –throughput, etc The iterative approach is risk driven

What Is An Iteration? Iteration is a mini-project - a more or less traversal of all core workflows - resulting in an internal release

Each iteration has distinctive emphases

Models Evolves From Iterations