close

Вход

Забыли?

вход по аккаунту

?

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
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
пЃ®
пЃ®
пЃ®
Technological factors
пЃ®
пЃ®
Development schedule, budget
Organisational attitudes, software process
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
пЃ®
пЃ®
Occurs throughout the design
пЃ®
пЃ®
Strategis should address global concerns, but
provide guidance for implementing them locally
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
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
пЃ®
пЃ®
A need to reduce the impact of changeability of
factors
пЃ®
пЃ®
Design for portability
Difficulty in satisfying product factors
пЃ®
пЃ®
Aggressive developemnt schedule
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
пЃ®
пЃ®
Technological factors
пЃ®
пЃ®
Constrain design choises
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, …
Документ
Категория
Презентации
Просмотров
11
Размер файла
84 Кб
Теги
1/--страниц
Пожаловаться на содержимое документа