1 / 30

Applied Software Architecture

Applied Software Architecture. Quality attributes, scenarios, tactics. Four Views to Software Architecture. Code view Many files, many kind of files Object code, binary code Multiple versions Configuration management

sandra_john
Download Presentation

Applied Software Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Applied Software Architecture Quality attributes, scenarios, tactics

  2. Four Views to Software Architecture • Code view • Many files, many kind of files • Object code, binary code • Multiple versions • Configuration management • Organisation of these affect the reusability of code and the build time of the system

  3. Four Views to Software Architecture con’t • Module view • The design of individual classes or procedures is too fine grained to be considered part of the software architecture design • But the decomposition of the system and the partitioning of modules into layers is!

  4. Four Views to Software Architecture con’t • Execution view • The dynamic aspect • How to map functional components to runtime entities? • How to handle communication, coordination and synchronisation among components?

  5. Four Views to Software Architecture con’t • Conceptual view • Describes the system in terms of its major design elements and the relation among them • Usually tied closely to the application domain • Can be used to specify the software architecture of a system with some attributes to guide the mappings of the other views

  6. Conceptual view • Identify the conceptual components and connectors • Problems and solutions are viewed primarily in domain terms • But independently of particular software and hardware techniques

  7. Conceptual view con’t • Engineering concerns addressed: • How does to system fulfill the requirements? • How are COST components integrated and how do they interact with the rest of the system? • How is domain-specific hardware and/or software incorporated into the system? • How is functionality partitioned into product releases? • How does the system incorporate the product’s prior generations and support future generations? • How can the impact of changes in requirements be minimised?

  8. Module view • Conceptual components and connectors are mapped to subsystems and modules • The architect addresses how the conceptual solution is realised with today’s software platforms and technologies

  9. Module view con’t • Engineering concerns addressed: • How is the product mapped on to the software platform? • What system support/services does it use and where? • How can testing be supported? • How can dependencies between modules be minimised? • How can reuse of modules and subsystems be maximised? • How to insulate the product from changes in COST software, in software platform, standards?

  10. Execution view • Map the modules to the elements of the runtime platform • Defines the system’s runtime entities including their attributes • Memory usage, hardware assignment, … • Flow of control from the point of the runtime platform

  11. Execution view con’t • Engineering concerns addressed: • How does the system meet its performance, recovery and reconfiguration requirements? • How can one balance resource usage? • Load balancing? • How to achieve concurrency, replication, distribution without too much additional complexity in control? • How to minimise the impact of changes in the runtime platform?

  12. Code view • Map the runtime entities from the execution view to deployment components (e.g. executables) • Map modules from the module view to source components • Determine how the deployment components are produced from source components

  13. Code view con’t • Engineering concerns addressed: • How can the time and effort for product apgrades be reduced? • How should product versions and releases be managed? • How can build time be reduced? • What tools are needed to support the development environment? • How are integration and testing supported?

  14. Using the views • Gives a systematic way of designing a software architecture • Gives guidance in • Tracing influencing factors and requirements through the architecture • Sequencing design activities • Making design trade-offs • Supporting system-specific qualities like performance or reliability • Supporting general qualities like buildability, portability, testability, reusability • Ensuring that no aspects of the architecture are overlooked • Producing documentation

  15. Design tasks • Global analysis • Central design tasks • Global evaluation task • Final design tasks • Resource budgeting • Interface definition

  16. Global analysis • Identify the external influencing factors and critical requirements that could affect the architecture • Analyse them to come up with strategies for designing the architecture • If all cannot be satisfied, decide which has priority, renegotiate a requirement, or change some external factor to come up with workable strategies

  17. Global analysis con’t • Influencing factors • Organisational factors • Development schedule, budget • Organisational attitudes, software process • Technological factors • Available hardware and software technology • Product factors • Performance, depemdability, cost • May be different in future versions

  18. Global analysis con’t • Many factors affect the entire system • Strategis should address global concerns, but provide guidance for implementing them locally • Occurs throughout the design • New factors, issues or strategies can arise at any time • Consider factors as a group • Might be contradictiong • Sort out conflicts and resolve them

  19. Global analysis con’t • Complements the risk analysis and/or requirements analysis • Requirements and risk analyses might give the anlysed factors • Then develop strategies to the design • Provides a systematc wayof identiying, accomodating and describing the affecting factors

  20. Global analysis con’t • Analysing factors • Take as input the organisational, technological and product factors • Make them explicit • Three (3) step procedure • Step 1: Identify and describe the factors • Step 2: Characterise the flexibility or the changeability of the factors • Step3: Analyse the impact of the factors

  21. Step 1: Identify and describe the factors • Can the factor’s influence be localised to one component or not? • During which stages of development is the factr important? • Does the factor require any new expertise or skills?

  22. Step 2: Characterise the flexibility or the changeability of the factors • Flexibility • Is it possible to influence or change the factor so that it makes your task of architecture development easier? • In what way can you influence it? • To what extent can you influnce it? • Changeability • In what way could the factor change? • How likely will it change during or after development? • How often will it change? • Will the factor be affected by changes in the other factors?

  23. Step3: Analyse the impact of the factors • If a factor was to change, which of the following would be affected and how: • Other factors • Components • Modes of operation of the system • Other design decisions

  24. Global analysis con’t • Develop strategies • Three (3) steps procedure • Step 1: Identify issues and influencing factors • Step 2: Develop solutions and specific strategies • Step 3: Identify related strategies

  25. Step 1: Identify issues and influencing factors • Idetify a handful of important issues that are influenced by the factor and their chageability • Limitations or constraints imposed by factors • Aggressive developemnt schedule • A need to reduce the impact of changeability of factors • Design for portability • Difficulty in satisfying product factors • High throughput req. may overload CPU • A common solution to global requirements • Error handling and recovery

  26. Step 2: Develop solutions and specific strategies • For each issue, develop strategies that address the issue and ensure the implementation changeability of the architecture design • Reduce or localise the factor’s influence • Reduce the impact of the factor’s changeability on the design and other factors • Reduce or localise required aread of expertise or skills • Reduce overall time and effort

  27. Step 3: Identify related strategies • When a strategy belongs with more than one issue, don’t repeat the strategy

  28. Global Analysis Summary • Consider three kinds of influencing factors • Organisational factors • Constrain design choises • Technological factors • Embedded or embodied in the product • Product factors • Functional features and qualities of the product

  29. Global Analysis Summary con’t • At the end of architecture design you will have • Characterised the important influencing factors and • Developed strategies for ensuring • Buildability • Implementation • changeability

  30. IS2000: The Advanced Imaging Solution • IS2000 key marketing features • Has a user-friendly operator environment • Has a comprehensive catalog of built-in acquisiion procedues • The user can define custom acquisition procedues • Throughput of image acquisition 50% higher than before • Image display as fast as the max. hardware spreed • User defined trade-off between speed and image quality • Designed for easy upgrade • Open platform connectivity • Can be connected to prnters, digital images, …

More Related