1. 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

2. 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

3. 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

4. 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

5. Where Does Architecture Come From?

6. Multi-Facets of Architecture - Architecture Baseline

7. Architecture Patterns or Templates

8. Ideal Evolution of Architecture

9. Iterative And Incremental Process

10. 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

11. 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

12. 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

13. 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

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

15. 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

16. 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

17. 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

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

19. Each iteration has distinctive emphases

20. Models Evolves From Iterations