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 • Organisation of these affect the reusability of code and the build time of the system
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!
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?
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
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
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?
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
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?
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
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?
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
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?
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
Design tasks • Global analysis • Central design tasks • Global evaluation task • Final design tasks • Resource budgeting • Interface definition
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
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
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
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
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
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?
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?
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
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
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
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
Step 3: Identify related strategies • When a strategy belongs with more than one issue, don’t repeat the strategy
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
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
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, …