Software Architecture in Practice - PowerPoint PPT Presentation

View by Category
About This Presentation
Title:

Software Architecture in Practice

Description:

The decomposition may be neutral with respect to a quality scenario ... decomposition into components and relation between these components ... – PowerPoint PPT presentation

Number of Views:711
Avg rating:3.0/5.0
Slides: 80
Provided by: vcg
Learn more at: http://www.cin.ufpe.br
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Software Architecture in Practice


1
Software Architecturein Practice
  • RiSEs Seminars
  • Basss book Chapters 07
  • Eduardo Cruz

2
Summary
  • Designing the Architecture (Chapter 7)
  • Architecture in the life cycle
  • Designing the Architecture
  • Forming its team structure and its relationship
    to the architecture
  • Creatign a skeletal system
  • Evolutionary Delivery Life Cycle
  • When Can I begin Designing?
  • How to identify the architectural drivers?
  • Attribute-Driven Design

3
Evolutionary Delivery Life Cycle
Software Concept
Deliver Final Version
Preliminary Requirements Analysis
Design of Architecture and System Core
Develop a Version
Deliver the Version
Incorporate Customer Feedback
Elicit Customer Feedback
4
Evolutionary Delivery Life Cycle
Designing the Architecture Chapter 7
  • Goal
  • To get user and customer feedback
  • Microsoft strategy
  • Skeletal system
  • Early
  • Low-fidelity
  • Updates

5
When Can I begin Designing?
Designing the Architecture Chapter 7
  • Architecture shaped by
  • Functionality
  • Quality
  • Business requirements
  • Examples
  • Avionic system
  • Availability, Performance, Security...
  • COMPGOV
  • Availability, Performance, Security...

Architectural drivers
6
How to identify the architectural drivers?
Designing the Architecture Chapter 7
  • To priorize business goals few
  • To put these business goals into quality
    scenarios or use cases
  • Scenarys template
  • To choose the most importants
  • Impact on the architecture

7
Quality attribute parts
Designing the Architecture Chapter 7
ARTIFACT
STIMULUS
RESPONSE
RESPONSE MEASURE
SOURCE OF STIMULUS
ENVIRONMENT
  • Availability
  • Modifiability
  • Performance
  • Security
  • Testability
  • Usability

8
Attribute-Driven Design
Designing the Architecture Chapter 7
  • Approach to define a software architecture that
    bases the decomposition process on the quality
    attributes the software has to fulfill
  • Recursive decomposition process
  • Use
  • Tatics
  • Architectural Patterns
  • Systematic approach

9
Attribute-Driven Design (cont.)
Designing the Architecture Chapter 7
  • To satisfy quality attributes and functional
    requirements
  • RUPs extension
  • High-level design
  • Detailed design and implementation
  • ADD
  • Detailed high-level Rational
  • Input
  • Functional requirements (expressed as use cases)
  • Constraints
  • Quality attributes scenarios

10
ADD Steps (p. 157)
  • Choose the module to decompose
  • Module the system
  • Inputs requirements, quality attributes,
    constraints
  • Quality attributes scenarios
  • Refine the module
  • Choose the architectural drivers from the set of
    concrete quality scenarios and functional
    requirements
  • Choose an architectural pattern that satisfies
    the architectural drivers
  • Instantiate modules and allocate functionality
    from the use cases
  • Define interfaces of the child modules
  • Verify and refine use cases and quality scenaries
  • Repeat the steps above for every module that
    needs further decomposition

11
ADD Steps
  • Choose the module to decompose
  • System
  • Subsystem
  • Submodules
  • Choose the architectural drivers
  • Combination of functional and quality
    requirements that shape the architecture or the
    particular module under considerations
  • It is not always a top-down process
  • Prototype
  • Decomposition criterias
  • Based on architectural drivers
  • Requirements priorization

Subsystem
System
Subsystem
12
ADD Steps (cont.)
  • Choose an Architectural Pattern
  • Goal To establish an overall architectural
    pattern consisting of module types
  • Quality attributes -gt Tatics -gt Patterns
  • Instantiate Modules and Allocate Functionality
    using Multiple Views
  • Instantiate module
  • Use of responsability
  • Allocate functionality
  • Based on Use cases
  • Represent the architecture with views
    (flexibility)
  • Iterative process
  • One view is normally sufficient
  • Module decomposition
  • Concurrency
  • Deployment
  • Others aspects can be used

13
ADD Steps (cont.)
  • Define Interfaces of the Child Modules
  • Documentation aspects
  • Verify and Refine Use cases and Quality Scenarios
    as Constraints for the Child Modules
  • Functional requirements
  • Requirements use cases -gt module
  • Constraints
  • The decomposition satisfies the constraint
  • The constraint is satisfied by a single child
    module
  • The constraint is satisfied by multiple child
    module

14
ADD Steps (cont.)
  • Quality scenarios
  • A quality scenario may be completely satisfied by
    the decomposition without any additional impact
  • A quality scenario may be satisfied by the
    current decomposition with constraints on child
    modules
  • The decomposition may be neutral with respect to
    a quality scenario
  • A quality scenario may not be satisfiable with
    the current decompostion
  • Result
  • Child module
  • Responsability
  • Use cases
  • Interfaces
  • Quality scenario
  • Constraints

15
References
  • L. Bass, P. C. Clements, R. Kazman. Software
    Architecture in Practice. Second Edition,
    Addison-Wesley, 2003.

16
Functionality-based architecture design
Design Use of Software Architectures
  • RiSEs Seminars
  • Jan Boschs book Chapter 4
  • Vinicius Cardoso Garcia

17
Summary
  • Introduction
  • Defining the system context
  • Identifying the archetypes
  • Decomposing the architecture into components
  • Describing system instantiations
  • Illustrating functionality-based architecture
    design
  • Fire-alarm system context
  • Summary

18
Introduction
  • Architectural design is the process of converting
    a set of requirements into a software
    architecture
  • Functionality-based architectural design
  • Focus on explicit evaluation of and for quality
    requirements
  • Does not mean that the functional requirements
    are irrelevant
  • Design phase consists of four main steps
  • Determining the context of the system
  • Identification of archetypes
  • Decomposing system into components
  • Description system instances using the archetypes
    and the system interfaces

19
  • Starting from the functional requirements does
    not preclude the optimization of quality
    requirements
  • An objective and repeatable architectural design
    method must be organized
  • Unlikely that architectural design process does
    not require iterations to optimize the
    architecture
  • An architecture based primarily on functional
    requirements is more general
  • It is unlikely that a SA which fulfils a
    particular set of quality requirements will be
    applicable in a domain with different FR

20
Defining the system context
  • No objects is an island (Beck and Cunningham,
    1989) -gt software systems in general
  • The role of the software architect is to convert
    the requirements of the stakeholder concerning
    the external visible properties of the system
    into a software architecture
  • Facilitates the fulfillment of these requirements
  • The externally visible behavior is present at the
    interfaces to its context
  • Explicitly defining the system in terms of the
    functionality and quality required on its
    interfaces is an important starting point

21
Defining the system context
Higher-level systems
Used by
uses
uses
System
Peer-level systems
Depends on
Lower-level systems
  • Additional reason for explicitly defining the
    system context and boundaries
  • Is a natural tendency to include more and more
    aspects during design
  • When this effort is spent on SA design -gt take
    time
  • When there is no extreme time pressure, software
    architects try to extend the domain of he design
  • Improve the applicability and allow for likely
    future requirements
  • That extensions increase the design and
    development cost

22
Defining the system context
  • Define the interfaces of the system to external
    entities.
  • These entities may be located at a lower level, a
    higher level or at the same level
  • Associate functional and quality requirements
    with each interface.
  • Both operational and development quality
    requirements can be associated with interfaces
  • In the case of software product line, the
    variability in the interfaces supported by the
    various products in the product line should be
    explicitly identified and specified.
  • The cost and resource efficiency of low-end
    products should not be sacrificed for the
    requirements of high-end products.

23
Identifying the archetypes
  • Identify and define the core abstractions based
    on which the system is structured -gt archetypes
  • These entities form the most stable part of the
    system and are generally very stable and only
    changed in very limited ways.
  • Large systems often can be described in terms of
    a small number of archetypes
  • The identification is largely dependent on the
    creative insight and experience of the architect
    (or architects)
  • The primary starting point is a good
    understanding of the domains
  • It is possible to recognize recurring patterns
    whiting the system at various places -gt candidate
    archetypes!
  • The candidate archetypes are recorded and form a
    set
  • The set is analyzed to select the most
    appropriate archetypes

24
Identifying the archetypes
  • The identification of architectural entities is
    related to domain analysis methods (Prieto-Diaz
    and Arango, 1991)
  • Archetypes can be modeled as domain objects
  • After analyzing the various domain entities,
    abstracts the most relevant properties and models
    them as architectural entities
  • The iteration between them are defined in more
    detail
  • ADLs -gt architectures are described in terms of
    components and connectors

25
Identifying the archetypes
  • To conclude
  • Identification of candidate archetypes
  • The selection of a small and stable set of
    archetypes from the candidates. This may require
    the exclusion of candidates, but especially the
    merging of candidates is rather common
  • The identification and selection of relations
    between archetypes.

26
Decomposing the architecture into components
  • Archetypes do not represent the architectural
    structure of the system
  • They are generally instantiated in several places
    in the system in several concrete forms
  • The next step is to define the structure of the
    software architecture
  • decomposition into components and relation
    between these components
  • This decomposition does note need to be single
    level
  • Incorporate two or more recursive levels
  • Several approaches can be used to identify and
    select components

27
Decomposing the architecture into components
  • Interfaces Each of the system interfaces should
    be connected to a component. One possible
    approach is by associating a component with each
    interface
  • Domains A second source for components is to
    associate domains covered by the system. Two
    types of domains
  • application domains - problem intends to address
  • computer science domains - areas associated with
    the solution used to solve the problem
  • Abstraction layers horizontal layers that
    implement relevant functionality and simplify the
    specification of problem-domain functionality at
    higher levels. Are identified while interacting
    over the component selection of the system.

28
Decomposing the architecture into components
  • Domain entities The decomposition defined by the
    domain experts provides a highly valuable input
    to the identification and selection of components
    of the system, and software architects are often
    tempted to select these components right away.
  • Archetype instantiations Even the identified
    archetypes may provide valuable input to
    selection components. The archetypes are defined
    based on the identification of recurring patterns
    throughout the system. These archetype
    initiations may represent useful components.
  • Functional x Entity-based decomposition
  • Functional is concerned with the functions that
    he system supposed to provide C, Pascal
  • The primary concepts that can be identified in
    the systems C, Java, C

29
Decomposing the architecture into components
  • Problem-domain x Solution-domain
  • Both domains can be decomposed according to the
    main functions and entities in the domain

Problem domain
Compiler architecture
Control theory architecture
Functionality
Entity
Graphical User-interface architecture
3-tier architecture
  • To identifying relation on the origin on which
    component is defined, a second approach is to
    script scenarios for the architecture.
  • Following a logical sequence of execution in the
    architecture helps to identify what components
    need to be able to communicate with each other

Solution domain
30
Decomposing the architecture into components
  • To summarize...
  • Identification and specification of components
  • We have examined the possible sources for the
    identification of components, including the
    system interfaces, domains, abstraction layers,
    domain entities and archetype instantiation.
  • Identification and specification of relations
  • Once the components have been identified, the
    relations between them need to be identified. We
    have presented some guidelines and hints, based
    on the origin of the component.

31
Describing system instantiations
  • Design is typically an iterative process
  • integrating activities addressing the overall
    system
  • focusing activities on addressing parts of the
    system that require particular attention
  • The components of the software architecture are
    recursively decomposed into lower-level
    components
  • Each component is either populated with
    instantiated archetypes
  • fulfill the functionality required from the
    system or is represented by an individual
    instantiated archetype
  • The generic relations between the archetypes are
    instantiated for the instantiated archetypes
  • verification of the match between abstractions
    and the concrete system decomposition is
    performed
  • Sufficient variability of product-line
    architectures is verified by the definition of
    multiple system instantiations, representing
    different products.

32
Fire-alarm systems
  • Defining the context
  • Is a relatively autonomous system, but it does
    not provide a number of interfaces to its context
  • The first issue whether the mechanical and
    hardware parts of the detectors and alarm devices
    are part of the system or not
  • Those parts to be external -gt the interfaces
    exists between the software and the physical
    detectors and alarm devices
  • Second issue whether the communication of the
    system is part of the system -gt high distributed

33
Fire-alarm systems - Interfaces
operator
Building Automation systems
interface
interface
Fire-alarm system
interface
interface
Detector
Output
34
Identifying the archetypes
  • Point high-level abstraction concerning
    fire-alarm domain functionality. It is the
    abstraction of the two subsequent archetypes
  • Detector captures the core functionality of the
    fire-detection equipment, including smoke and
    temperature sensors
  • Output contains generic output functionality,
    including traditional alarms
  • Control unit connected to a network and can
    communicate.

35
Relations between the F-A archetypes
Control Unit
Point
Communicates with
Detector
Output
36
Decomposing the architecture into components
Physical points
Communication
  • Physical point is an instantiation of the point
    archetype, whereas the communication component is
    typically a component based on a solution domain
  • Section component is a domain entity in the
    system, it represents a controller and the
    physical points is monitored by it
  • Also represents a geographic area where the
    physical points are responsible
  • That architecture employs an entity-based
    decomposing and the entities are taken from the
    solution domain

37
Describing the system instantiations
Small fire-alarm system instantiation
Smoke detector
Smoke detector
Sound alarm
Smoke detector
Control unit
User interface
Smoke detector
Smoke detector
38
Describing the system instantiations
Two building fire-alarm system instantiation
point
Control Unit
Operator Interface
Control Unit
Control Unit
point
point
Control Unit
point
Control Unit
point
Control Unit
Control Unit
point
point
Control Unit
point
39
Summary
  • The method has a focus on the explicit evaluation
    of an d design for quality requirements, but that
    does not mean that the functional requirements
    are irrelevant.
  • Before one can start to optimize an architecture
    for quality requirements, the first step must be
    to design an initial version of the architecture
    based on the functional requirements.

40
Artefacts developed during process
41
References
  • Bosch, J. Design Use of Software Architectures,
    1st edition ed Addison-Wesley Professional,
    2000.
  • Prieto-Díaz, R. and Arango, G. Domain Analysis
    and Software Systems Modeling. IEEE Computer
    Society Press, 1991.

42
Software Architecturein Practice
  • RiSEs Seminars
  • Basss et al. Book Chapter 12
  • Fred Durão e Ednaldo Dilorenzo

43
Summary
  • The CBAM (Chapter 12)
  • Concepts
  • Decision Making Context
  • The Basis for the CBAM
  • Calculating ROI
  • The importance of Cost Modeling
  • Implementing CBAM
  • Case Study The NASA ECS Project

44
The CBAM A Quantitative Approach to
Architecture Design Decision Making
45
Concepts
The CBAM Chapter 12
  • The biggest tradeoffs in large, complex systems
    usually have to do with economics.
  • How should an organization invest its resources
    in a manner that will maximize its gains and
    minimize its risk?
  • perhaps more important than costs, are the
    benefits than an architecture decision may bring
    to an organization.
  • CBAM provides an assessment of the technical and
    economic issues and architectural decisions

46
Decision-Making Context
The CBAM Chapter 12
  • When ATAM is applied to a software system, we
    have as a result a set of artefacts
  • a set of architectural views
  • a set of stakeholders goals a set of risks
  • a set of tradeoffs points and more
  • The ATAM uncovers the architectural decisions,
    links the to business goals and quality attribute
    response measures.
  • The CBAM does not make decisions for the
    stakeholders. It simply aids in the elicitation
    and documentation of the costs and benefits
    (based on ATAM results).
  • The CBAM can aid the stakeholders in choosing
    architectural strategies based on their return on
    investment return on investment (ROI) the ratio
    of benefit to cost.

47
The Basis for the CBAM
The CBAM Chapter 12
  • Variations of Scenarios
  • a way to concretely express and represent
    specific quality attributes
  • Utility-Response Curves
  • Every stimulus-response value pair in a scenario
    provides some utility to the stakeholders, and
    the utility of different possible values for the
    response can be compared.
  • Priorities of Scenarios
  • Different scenarios within a given system have
    different levels of importance to the
    stakeholders and hence different utilities.
  • To characterize the relative importance of each
    scenario, a weigh is assigned through a two-step
    voting exercise.

48
The Basis for the CBAM 2
The CBAM Chapter 12
  • Architectural Strategies
  • In order to move from the current utility
    attribute response level to the desired or even
    best-case level.
  • Side Effects
  • Impact of the changes

49
Calculating ROI
The CBAM Chapter 12
  • R (ROI) B (Benefit) / C (Cost)
  • This can be used to determine the optimal order
    for implementation the various strategies.

50
The importance of Cost Modeling
The CBAM Chapter 12
  • How do I convince my boss to investing in
    availability ?
  • Maintain high availability requires a high level
    of redundancy with a rollover capability
  • This takes time an personnel
  • Personnel cost money as do purchasing highly
    available software and adapting it for particular
    needs
  • Cost models are imperfect for a wide variety of
    reasons, but they are the only tools available to
    constrain requirements.

51
Implementing CBAM
The CBAM Chapter 12
52
Case Study The NASA ECS Project
The CBAM Chapter 12
  • The Earth Observing System is a constellation of
    NASA satellites that gathers data for the U.S.
    Global Change Research Program.
  • The ECS processes an input stream of hundreds of
    gigabytes of raw environment-related data per
    day.
  • The ECS project manager had a limited annual
    budget to maintain and enhance his current system.

53
STEP 1 COLLATE SCENARIOS
The CBAM Chapter 12
Scenario Scenario Description
1 Reduce data distribution failures that result in hung distribution requests requiring manual intervention.
2 Reduce data distribution failures that result in lost distribution requests.
3 Reduce the number of orders that fail on the order submission process.
4 Reduce order failures that result in hung orders that require manual intervention.
5 Reduce order failures that result in lost orders.
6 There is no good method of tracking ECSGuest failed/canceled orders without much manual intervention (e.g., spreadsheets).
7 Users need more information on why their orders for data failed.
8 Because of limitations, there is a need to artificially limit the size and number of orders.
9 Small orders result in too many notifications to users.
10 The system should process a 50-GB user request in one day, and a 1-TB user request in one week.
54
STEP 2 REFINE SCENARIOS
The CBAM Chapter 12
Scenario Worst Current Desired Best
1 10 hung 5 hung 1 hung 0 hung
2 gt 5 lost lt 1 lost 0 lost 0 lost
3 10 fail 5 fail 1 fail 0 fail
4 10 hung 5 hung 1 hung 0 hung
5 10 lost lt 1 lost 0 lost 0 lost
6 50 need help 25 need help 0 need help 0 need help
7 10 get information 50 get information 100 get information 100 get information
8 50 limited 30 limited 0 limited 0 limited
9 1/granule 1/granule 1/100 granules 1/1000 granules
10 lt 50 meet goal 60 meet goal 80 meet goal gt 90 meet goal
55
STEP 3 PRIORITIZE SCENARIOS
The CBAM Chapter 12
Scenario Votes Worst Current Desired Best
1 10 10 hung 5 hung 1 hung 0 hung
2 15 gt 5 lost lt 1 lost 0 lost 0 lost
3 15 10 fail 5 fail 1 fail 0 fail
4 10 10 hung 5 hung 1 hung 0 hung
5 15 10 lost lt 1 lost 0 lost 0 lost
6 10 50 need help 25 need help 0 need help 0 need help
7 5 10 get information 50 get information 100 get information 100 get information
8 5 50 limited 30 limited 0 limited 0 limited
9 10 1/granule 1/granule 1/100 granules 1/1000 granules
10 5 lt 50 meet goal 60 meet goal 80 meet goal gt 90 meet goal
56
STEP 4 ASSIGN UTILITY
The CBAM Chapter 12
Scenario Votes Worst Current Desired Best
1 10 10 80 95 100
2 15 0 70 100 100
3 15 25 70 100 100
4 10 10 80 95 100
5 15 0 70 100 100
6 10 0 80 100 100
7 5 10 70 100 100
8 5 0 20 100 100
9 10 50 50 80 90
10 5 0 10 90 100
57
STEP 5 DEVELOP ARCHITECTURAL STRATEGIES FOR
SCENARIOS AND DETERMINE THEIR EXPECTED QUALITY
ATTRIBUTE RESPONSE LEVELS
The CBAM Chapter 12
Strategy Name Description Scenarios Affected Current Response Expected Response
1 Order persistence on submission Store an order as soon as it arrives in the system. 3, 5, 6 5 fail, lt 1 lost, 25 need help 2 fail, 0 lost, 0 need help
2 Order chunking Allow operators to partition large orders into multiple small orders. 8 30 limited 15 limited
3 Order bundling Combine multiple small orders into one large order. 9, 10 1 per granule 60 meet goal 1 per 1000, 55 meet goal, 2 hung
4 Order segmentation Allow an operator to skip items that cannot be retrieved due to data quality or availability issues. 4 5 hung 2 hung
5 Order reassignment Allow an operator to reassign the media type for items in an order. 1 5 hung 2 hung
6 Order retry Allow an operator to retry an order or items in an order that may have failed due to temporary system or data problems. 4 5 hung 3 hung
58
STEP 5 DEVELOP ARCHITECTURAL STRATEGIES FOR
SCENARIOS AND DETERMINE THEIR EXPECTED QUALITY
ATTRIBUTE RESPONSE LEVELS
The CBAM Chapter 12
Strategy Name Description Scenarios Affected Current Response Expected Response
7 Forced order completion Allow an operator to override an items unavailability due to data quality constraints. 1 5 hung 3 hung
8 Failed order notification Ensure that users are notified only when part of their order has truly failed and provide detailed status of each item user notification occurs only if operator okays notification the operator may edit notification. 6, 7 25 need help, 50 get information 20 need help, 90 get information
9 Granule level-order tracking An operator and user can determine the status for each item in their order. 6, 7 25 need help, 50 get information 10 need help, 95 get information
10 Links to user information An operator can quickly locate a users contact information. Server will access SDSRV information to determine any data restrictions that might apply and will route orders/order segments to appropriate distribution capabilities, including DDIST, PDS, external subsetters and data processing tools, etc. 7 50 get information 60 get information
59
STEP 6 DETERMINE THE UTILITY OF THE EXPECTED
QUALITY ATTRIBUTE RESPONSE LEVELS BY INTERPOLATION
The CBAM Chapter 12
Strategy Strategy Scenarios Affected Current Utility Expected Utility
1 Order persistence on submission 3, 5, 6 70, 70, 80 90, 100, 100
2 Order chunking 8 20 60
3 Order bundling 9, 10 50, 70 80, 65
4 Order segmentation 4 80 90
5 Order reassignment 1 80 92
6 Order retry 4 80 85
7 Forced order completion 1 80 87
8 Failed order notification 6, 7 80, 70 85, 90
9 Granule level order tracking 6, 7 80, 70 90, 95
10 Links to user information 7 70 75
60
STEP 7 CALCULATE THE TOTAL BENEFIT OBTAINED FROM
AN ARCHITECTURAL STRATEGY
The CBAM Chapter 12
Strategy Scenario Affected Scenario Weight Raw Architecural Strategy Benefit Normalized Architectural Strategy Benefit
1 3 15 20 300
1 5 15 30 450
1 6 10 20 200
2 8 5 40 200
3 9 9 30 300
3 10 10 -5 -25
4 4 4 10 100
5 1 1 12 120
6 4 4 5 50
7 1 1 7 70
8 6 6 5 50
8 7 7 20 100
9 6 6 10 100
9 7 7 25 125
10 7 7 5 25
61
STEP 8 CHOOSE ARCHITECTURAL STRATEGIES BASED ON
ROI VALUE SUBJECT TO COST CONSTRAINTS
The CBAM Chapter 12
Strategy Cost Total Strategy Benefit Strategy ROI Strategy Rank
1 1200 950 0,79 1
2 400 200 0,5 3
3 400 275 0,69 2
4 200 100 0,5 3
5 400 120 0,3 7
6 200 50 0,25 8
7 200 70 0,35 6
8 300 150 0,5 3
9 1000 225 0,22 10
10 100 25 0,25 8
62
Results of the CBAM Exercise
The CBAM Chapter 12
  • The most obvious results are the ordering of
    architectural strategies based on their predicted
    ROI.
  • The CBAM process provides a great deal of
    structure to what is always largely unstructured
    discussions

63
References
The CBAM Chapter 12
  • Bass L., Clements P. and Kazman R. Software
    Architecture in Practice. Second Edition, 2003.
  • a felicidade pode esperar

64
DAGAR A Process for Domain Architecture
Definition and Asset Implementation
  • RiSE Workshop
  • Eduardo Santana de Almeida

65
Agenda
  • DAGAR
  • Context
  • Problem
  • Motivation
  • Proposal
  • Key definitions
  • Activities
  • Brief Analysis
  • Software architecture x Domain architecture

66
DAGAR A Process for Domain Architecture
Definition and Asset Implementation
  • Context
  • Software Technology for Adaptable, Reliable
    Systems (STARS) program
  • 1996
  • Sponsored
  • U.S. Defense Advanced Research Projects Agency
    (DARPA)
  • Military services
  • Software Engineering Institute (SEI)
  • MITRE

67
Context
DAGAR A Process for Domain Architecture
Definition and Asset Implementation
  • Reuse
  • Oportunistic x Planned
  • Software Product Lines

Problem
  • Organization Domain Modeling (ODM)
  • Lack of Methods for Develop Doman Architecture

Proposal
  • Repeatable
  • Documented
  • Tools GenVoca Don Batory

68
Differences
DAGAR A Process for Domain Architecture
Definition and Asset Implementation
  • Software architecture
  • Domain architecture

Key DAGAR definitions
  • Realms specification
  • Module
  • Interfaces
  • Components instance
  • Specification
  • Body

69
Overview
70
Approach for Architecting the Asset Base
DAGAR A Process for Domain Architecture
Definition and Asset Implementation
71
Asset Base Architecture Definition
DAGAR A Process for Domain Architecture
Definition and Asset Implementation
72
Develop Top-Level Architecture
DAGAR A Process for Domain Architecture
Definition and Asset Implementation
73
Develop Realm Descriptions
DAGAR A Process for Domain Architecture
Definition and Asset Implementation
74
Recommendations for Architecting the Asset Base
DAGAR A Process for Domain Architecture
Definition and Asset Implementation
  • Domain engineering projects should focus their
    domain modeling efforts on domain models that
    supports the creation and application of a domain
    architecture
  • DAGAR requires a new way of thinking about asset
    base architecture. Domain engineers need training
    in DAGAR and domain architecture development
  • An asset base architect must be concerned with
    all possible applications of the assets in a
    domain

75
Implementing the Asset Base
DAGAR A Process for Domain Architecture
Definition and Asset Implementation
76
Recommendations for Implementing the Asset Base
DAGAR A Process for Domain Architecture
Definition and Asset Implementation
  • An Asset base, devoid of its architecture, is not
    intended to be generally useful and reusable.
    Asset base success cannot be measured apart from
    the architecture within which it was created
  • The domain engineering team must be sufficiently
    knowledgeable about Ada to be able to complete
    the DAGAR component
  • DAGAR requires that up front effort be applied in
    developing both assets and CLIPS rules. The
    payoof comes from being able to automate
    generation of subsystem after subsystem from the
    domain asset base

77
Applying the Asset Base to Generate a Subsystem
DAGAR A Process for Domain Architecture
Definition and Asset Implementation
78
Brief analysis
DAGAR A Process for Domain Architecture
Definition and Asset Implementation
  • Very general
  • Flexible
  • Based on ADA
  • Not useful currently
  • Useful Template
  • Learned lessons, project description...

79
References
  • C. Klinger, J. Solderitsch. DAGAR A Process for
    Domain Architecture Definition and Asset
    Implementation, STARS program. 1996, p. 33.
About PowerShow.com