Use of Architecture Centric
Engineering for Improving
a Software System
Felix H. Bachman
Senior Technical Staff
October 17, 2012
© 2010 Carnegie Mellon University
The layout of your screen is completely customizable by you
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Felix H. Bachman
Senior Technical Staff
Felix H. Bachmann is a senior member of the technical staff at the Software
Engineering Institute (SEI) working in the Research, Technology, and System
Solutions Program on both the Architecture Practices and Product Line Practice
initiatives. There he is the team lead for architecture-centric product line practices,
a co-author of the Attribute-Driven Design Method, a contributor to and instructor
for the Architecture Tradeoff Analysis Method (ATAM) Evaluator Training, and a
co-author of Documenting Software Architectures: Views and Beyond.
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Use of Architecture
Centric
Engineering
Do You Have
the Right
Architecture?
for Improving a Software System
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Agenda: Architecture-Centric Engineering
Formulate the problem
BUSINESS
AND MISSION
GOALS
ACE/TSP
ARCHITECTURE
ACE/TSP
SYSTEM
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Agenda: Architecture-Centric Engineering
Create the plan
BUSINESS
AND MISSION
GOALS
ACE/TSP
ARCHITECTURE
ACE/TSP
SYSTEM
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Agenda: Architecture-Centric Engineering
Design alternatives
BUSINESS
AND MISSION
GOALS
ACE/TSP
ARCHITECTURE
ACE/TSP
SYSTEM
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Agenda: Architecture-Centric Engineering
Document solution
BUSINESS
AND MISSION
GOALS
ACE/TSP
ARCHITECTURE
ACE/TSP
SYSTEM
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Agenda: Architecture-Centric Engineering
BUSINESS
AND MISSION
GOALS
ACE/TSP
ARCHITECTURE
ACE/TSP
SYSTEM
Challenge the solution
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Agenda: Architecture-Centric Engineering
Provide implementation
details
BUSINESS
AND MISSION
GOALS
ACE/TSP
ARCHITECTURE
ACE/TSP
SYSTEM
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Agenda: Architecture-Centric Engineering
Active design review
BUSINESS
AND MISSION
GOALS
ACE/TSP
ARCHITECTURE
ACE/TSP
SYSTEM
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Agenda: Architecture-Centric Engineering
Not part of this
presentation
BUSINESS
AND MISSION
GOALS
ACE/TSP
ARCHITECTURE
ACE/TSP
X
SYSTEM
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Agenda: Architecture-Centric Engineering
BUSINESS
AND MISSION
GOALS
ACE/TSP
ARCHITECTURE
ACE/TSP
SYSTEM
Conformance review
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Let’s Get Started
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Architecture-Centric Engineering (ACE)
Formulate the problem
BUSINESS
AND MISSION
GOALS
ACE/TSP
ARCHITECTURE
ACE/TSP
SYSTEM
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
ACE – Formulate the Problem – 1
Changes to an architecture are typically driven by some quality attribute
property of the system that is undesirable to some stakeholders, such as end
users or system administrators.
Often there are statements like:
The system doesn’t work
The system is too slow
It is too expensive to add new features
Those statements are not helpful at all because they do not provide any insight
into which property/properties are affected.
Statements such as
The system does not have the function X
Seldom lead to architecture changes.
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
ACE – Formulate the Problem – 2
The developers’ quick answer such as, “Let’s fix it” (something in the system)
is risky because
The fix may not address the root cause
The fix may introduce other undesirable properties
The fix is more expensive than it could have been
The stakeholder may say: “That is not what I meant!”
Before any work starts there needs to be a problem statement that describes
the undesired property the stakeholder observes.
When I click this button it takes 10 seconds
before I get an answer
A problem statement describes some
function/activity with a measurable property, such
as timing, that is observable.
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
ACE – Formulate the Problem – 3
The problem statement can easily be transformed into a quality attribute
scenario describing the desired outcome:
The end user clicks the “submit” button. The system executes the request and
returns the result in 2 seconds on average.
A customer requests the implementation of a new report. The report is
implemented, tested, and ready for deployment within two weeks of effort.
Never, never, and did I mention: Never …
… start an architecture-change exercise without scenarios that state the
desired outcome of the change in a measurable way.
The involved stakeholders need to agree to those scenarios:
Would you be happy if the system would behave as stated in the scenario?
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Architecture-Centric Engineering
Create the plan
BUSINESS
AND MISSION
GOALS
ACE/TSP
ARCHITECTURE
ACE/TSP
SYSTEM
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
ACE – Create the Plan
Why create a plan? That’s overkill! Let’s just fix it!
If you are lucky, you will be asked when the problem will be fixed, but management
will be unhappy with your answer and will give you a tighter deadline.
Mostly you will be given a deadline that seems unreasonable to you.
You typically will give in and say, “We will try.”
Without a plan, you yourself will not know what is involved and how long it
will take.
Without a sound plan you have no negotiation position to convince your
management how long the task really takes and what is involved.
Management is NOT evil. When you present a sound plan, they will agree (mostly).
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
ACE – Create the Plan – Content
What should the plan include?
The first step is always to begin with what is clearly understood and identify the
areas that are uncertain or unknown.
If everything was clear and understood, this problem most likely would
not exist.
Start with a rough sketch of the part of the
architecture that is likely involved in the solution.
The sketch does not depict a full solution.
It shows what you now think the problem is and
how it can be solved.
It is the basis for planning, not a complete design.
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
ACE – Create the Plan – Estimate
List the tasks that must be done. If you don’t know the high-level tasks you
have to go through, use the outline of this webinar!
If something is not clear, add a task that gets necessary information, such as
prototyping.
Estimate the effort involved in executing those tasks.
A measure that correlates well to effort for architecture tasks is
the number of diagrams it takes to describe the
solution with enough details for implementation
So, instead of story points or function points you can use “diagram points”
Example:
The solution for one scenario can be described in five diagrams (structure and
behavior) at average.
It takes about one day to create a complete diagram including the description.
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
ACE – Create the Plan – Validate
Do not forget to add a task for validating your solution.
How do you know that your solution will work?
How do you know that the side effects of your solution
will not introduce new problems?
This is required before the implementation begins.
The evidence can be obtained by prototyping, system monitoring, expert reviews,
stakeholder interviews, etc.
With some experience, creating the first plan should not take longer then 3 to 10
hours, depending on the complexity of the task.
Present your plan to management and get approval.
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Architecture-Centric Engineering
Design alternatives
BUSINESS
AND MISSION
GOALS
ACE/TSP
ARCHITECTURE
ACE/TSP
SYSTEM
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
ACE – Design Alternatives
There is never just one solution.
There is no perfect solution. Every solution comes with a price.
• development and maintenance cost
• diminishing of other quality attributes (e.g., the system will be slower)
• possible change of operational processes
• lengthy implementation
• Etc.
It takes at least two people to brainstorm and discuss possible solutions.
List all the plausible solutions in a table and add columns for Pros and Cons.
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
ACE – Design Alternatives – Impact
Understand the impact your solution has.
List desired impact as a “Pro” and undesired as a “Con.”
Use the Pros and Cons table to converge on an appropriate solution.
In most cases, the solution is a combination of the proposed solutions to
alleviate the negative impact.
If there is more than one appropriate solution
• Pick your favorite and describe it in more detail.
• Describe the differences the other solutions have.
• Present your findings to the stakeholders to come to a decision.
In most cases, the stakeholders will follow your suggestion.
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Architecture-Centric Engineering
BUSINESS
AND MISSION
GOALS
ACE/TSP
ARCHITECTURE
ACE/TSP
SYSTEM
Document solution
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
ACE – Document Solution
composite structure Bid Processor
Change the architecture
model/documentation to reflect
your solution.
«thread»
Bid Processor
Time Events Command
{1..*}
«flow»
Auction
AuctionManager
«use»
Collect/create convincing
evidence that your solution will
work.
Auction Transaction
Sequence Number
Auction
Information
«flow»
«flow»
«flow»
Auction Information,
Sync Message
Bid Response, Sync
Message
«flow»
Business Rules Processor
Bid Validation
Bid
«flow»
«use»
«use»
«use»
Bid, Sync Message
Administrative Data Object access
«flow»
Document the evidence!
sd Order Process Latency - Matching Engine Lev el processing
«connector»
«thread»
:Communication Bus
:Communications
Peer
:Dispatcher
«connector»
«thread»
:Queue
:Bid Processor
Administrative 1
Data Objects
(from Components)
send(Message)
{0.002 msec.}
onReceive(Order)
If you do not have evidence
that your solution will work,
how can you convince anyone
else?
This is a generic call to
access data from the
ADO.
{0.008 msec.}
put(Order)
When this method is
called, the timer starts.
{0.005 msec.}
get(Order)
This time includes
serializacion and
deserialization.
getInformation() :ADO Information
«invariant»
{Response time less or
equals to 0.980 msec}
When this method is
called, the timer stops.
send(Order Response)
{0.005 msec.}
send(Message Response)
Find out the
incomming order rate,
so we will know if we
can process faster than
the orders arrive or the
other way which will
affect the queue size.
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
ACE – Document Solution – Get Help
You are not required to do everything on your own.
As soon as you have some idea which components will be involved in the
change, involve the people who know these components.
Ask for their opinions.
You may have to include other stakeholders, such as end users or system
administrators, if the change influences how they work with the system.
Get feedback early and often.
In this step, you will probably discover that your initial plan was wrong.
Fix it! Do not throw the plan away.
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
ACE – Document Solution – Package it
Create a documentation package with all the information required to understand
the change.
This makes reviews easier and helps the developers understand what is involved
and to implement correctly.
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Architecture-Centric Engineering
BUSINESS
AND MISSION
GOALS
ACE/TSP
ARCHITECTURE
ACE/TSP
SYSTEM
Challenge the solution
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
ACE – Challenge the Solution – Peer Review
It is great that you believe your solution will work!
Have a peer review with an expert that understands the quality attribute
involved in the scenario, e.g. a performance expert or usability expert.
It is always a good idea to invite the developers who will implement the
change.
In some cases, you may have to invite other important
stakeholders.
Keep the number of invited people low. A peer review
should not last longer then three hours.
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
ACE – Challenge the Solution – Peer Review
In the step before (documentation), you created a document package
with all the necessary information describing your change. There is
nothing else required for the peer review.
The architecture evaluation process has to answer the
following questions:
Do the quality attribute properties of the
identified components support the given quality
attribute scenario sufficiently?
Is the negative impact of the chosen
architecture approaches on other quality
attribute scenarios acceptable?
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
ACE – Challenge the Solution
It is the architect of the system who has to answer these questions.
• If the answers are documented, examining the
documentation is sufficient for the evaluation.
• If not, the architect has to provide the answers
in a review.
The evidence provided must be sufficient to convince quality attribute experts
and the stakeholders.
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Architecture Evaluation using the ATAM®
Business
Drivers
Quality
Attributes
Scenarios
Analysis
Software
Architecture
Architectural
Approaches
Architectural
Decisions
Tradeoffs
impacts
Sensitivity Points
distilled
into
Risk Themes
Non-Risks
Risks
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
ACE – Challenge the Solution - Results
Sometimes a review shows that a proposed solution is not as good
as expected.
It is better to now go back and work on another solution than to have the
big surprise after a lot of time and money was invested.
If the review result shows that your solution is acceptable, move on to
the next step.
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
ACE – Design Cycle Complete
Plan
Quality Attribute
Scenario(s)
BUSINESS
AND MISSION
GOALS
Attribute Driven
Design
ACE/TSP
ARCHITECTURE
Architecture
PROCESS
Views
and Beyond
Scenario-based peer review
Architecture Tradeoff Analysis Method
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Polling Question
What do you think:
How much effort will it take to go through the design cycle as presented
once?
•
1 Day?
•
1 Week?
•
1 Month?
•
4 Month?
•
6 Month?
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Polling Question – All of It!
If there is just one scenario and it can be fixed by introducing a
known concept into the architecture, it can be done in one day.
If there is one scenario that requires introducing a new concept,
it may take one week.
If a scenario requires some new technology, it may take up to
one month.
If there are several scenarios, it will take longer.
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Architecture-Centric Engineering
BUSINESS
AND MISSION
GOALS
ACE/TSP
ARCHITECTURE
ACE/TSP
Provide implementation
details
SYSTEM
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
ACE – Provide Implementation Details
Thus far, we have executed the design cycle of architecture
development. This led to
•
documented solution organized around quality attribute scenarios
•
a level of detail that is sufficient to provide the required evidence
All the information obtained so far is usually not sufficient to begin
implementation of the system.
•
more details especially for module interfaces and responsibilities
•
documentation organized around work packages for developers
(modules)
•
installation of a feedback loop between developers and architects
UML-based tools work well for the implementation cycle – because
that’s what they were made for.
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
What We Have So Far
class Dependencies
MSLiteServ er
«instantiate»
This is typically what
exists after the design
cycle is done.
Adapter Manager
«use»
«use» «use»
Serv ices
Adapter Interface
«instantiate»
«instantiate» «use»
«use»
«use»
«use»
«Version 1»
Adapter
There is important
information missing
to allow for easy
implementation.
«use»
«Version 2»
Adapter
BTW! It is a good idea to revisit the plan now.
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Work Packages for the Development – 1
The purpose of a work package is to provide the information needed
with sufficient detail to an individual or team to support an implementation
as envisioned.
Multiple work packages are required if multiple individuals or teams are involved.
A work package contains the descriptions of one or more modules.
•
context
•
structural description
«instantiate»
Adapter Manager
«use»
•
behavioral description
«use» «use»
Serv ices
Adapter Interface
«use»
«use»
«Version 1»
Adapter
«instantiate»
«instantiate» «use»
«use»
«use»
«Version 2»
Adapter
Context
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Work Packages for the Development – 1
The structural description contains description of the
•
module(s) to implement or change
•
external interfaces the module has to provide
•
external interfaces this module is allowed to use
«interface»
IAdapterV2
+
+
+
«interface»
IIAdapterV2
alarmAcknowledge(Alarm) : void
alarmEvent(string) : void
setValue(int, string) : void
+
+
alarmEvent(Alarm) : void
command(object, string) : void
«use»
«Version 2»
Adapter
«interface»
IServ icesFactory
responsibilities
Communicated via interface instance
Manages the connected field system
Receives alarms
Receives commands
«use»
+
+
getAlarmInstance(string) : Alarm
getAuthenticationInstance(string) : void
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Work Packages for the Development – 2
The behavioral description contains
•
a set of use cases that are relevant for these modules
•
a description of the typical interaction of the modules with the external
elements, e.g. sequence diagrams
«Version 2»
:ServicesFactory
:IAdapterV2
:Adapter Manager
:Adapter
FSS
alarmEvent(string)
FSS sends alarm
message
getAuthenticationInstance(string)
:AuthenticationCredentials
new()
FSS sends alarm
message w ith
authentication
FSS
getCredientials() :credentials
authenticate(string) :boolean
Send command to
FSS
getAlarmInstance(string)
:Alarm
new()
Use Case Diagram
:AlarmSingle
Sequence Diagram
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Architecture Documentation Complete
At that point, we understand enough to be sure the solution will work.
This understanding is documented sufficiently to inform others on
how to implement the solution.
At least that is what we think!
ACE Development Life-cycle
Twitter #seiwebinar
•
Next step is the detailed design.
© 2012 Carnegie Mellon University
Architecture-Centric Engineering
Active design review
BUSINESS
AND MISSION
GOALS
ACE/TSP
ARCHITECTURE
ACE/TSP
SYSTEM
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
ACE – Active Design Review
Are we sure that if we hand the documentation to development that they have
the necessary information to implement the solution as envisioned?
We know that we cannot create the perfect documentation. No one pays for it!
We need to document only what is necessary
and not more.
If some documentation is not used then why
create it?
We tend to create minimal documentation, and that is good!
But it carries the risk that we will not make sufficiently clear how to implement
the solution.
Therefore we need to check the documentation for its fitness for purpose.
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Active Design Review – Purpose and Setup
The purpose of an active design review is to
•
effectively communicate the designed solution to the developers
•
get feedback about the documentation and possible areas for
improving it
Before the review
•
Developers already have their areas of responsibility assigned,
which are usually sets of modules they have to implement
or maintain.
•
Developers have the documentation and have had a chance
to read it.
•
If the documentation was done using a tool (such as a UML
tool), the developers are familiar with that tool and have access.
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Active Design Reviews – Process – 1
Architects and developers meet for about three hours. It is best if the group
meets face to face.
•
One architect presents one or two use cases to the group, which may or
may not be documented.
•
Using diagrams or text, the architects describe in principle how the use
case would utilize the modules.
•
Every developer has about two hours to sketch what they would have to
implement in their modules to make the use case work correctly.
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Active Design Reviews – Process – 2
•
At any point during the review, developers are allowed to ask questions.
One of the architects acts as scribe and notes all the questions that came
up.
•
After two hours, every developer presents their sketched work plan to the
architects.
•
Architects check the presented work plans against the architecture and
clarify and note any discrepancies.
After the review, the developers should know what they have to do, while the
architects have a list of possible improvements to the architecture and its
documentation.
And those sketches the developers produced
during the review are a wonderful basis for
planning the implementation effort.
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Architecture-Centric Engineering
Not part of this
presentation
BUSINESS
AND MISSION
GOALS
ACE/TSP
ARCHITECTURE
ACE/TSP
X
SYSTEM
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Architecture-Centric Engineering
Conformance review
BUSINESS
AND MISSION
GOALS
ACE/TSP
ARCHITECTURE
ACE/TSP
SYSTEM
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Architecture Drift
Guidelines for transforming architecture
elements into implementation
Architecture
?
Drift
Mapping Functions
Implementation
Evidence that implementation
conforms to the architecture
For the implementation to exhibit the quality attributes engineered at the
architectural level, it must conform to the architecture.
There will be discrepancies between the architecture and the implementation for
a variety of reasons; also known as “architectural drift.”
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Conformance Reviews
The purpose of conformance reviews is to discover the drift and to remove it.
•
If the reason for the drift is a misinterpretation of the architecture during
implementation, adjusting the code reduces the drift.
•
If the reason for the drift is discovery of problems with the architecture
during implementation, adjusting the architecture reduces the drift.
It is the responsibility of the developers to provide
sufficient evidence to the architects that the
implementation follows the architecture.
Without proper preparation before starting the implementation, it will be
difficult to almost impossible to show that the implementation conforms
to the architecture.
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Conformance Guidelines
An architectural element (module) will most likely be implemented by a set of
classes/functions.
There are many ways that this can be done. Some of those make conformance
reviews easy, some make them almost impossible.
Provide guidelines to development before they start implementing, such as
•
Have a single class (main class) with the same name as the module
that implements the defined interface and acts as a façade.
•
Use decomposed classes/functions to provide interfaces that are used
only within the decomposition.
•
Have the main class route requests to the decomposed
classes/functions.
These kind of guidelines support creating/using tools that can scan the code
and produce output that can easily be compared against the architecture.
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Conformance Guidelines – From Module
composite structure Auction Manager - Detail Design
AuctionManager
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
create(Configuration Value) : void
deleteBid(Object) : void
getBusinessStatistics() : Business Statistics
getLock() : boolean
getStatisticalInformation() : Statistics Interface
getSyncOperations() : Sync Message
insertBid(Bid) : void
modifyBid(Bid) : void
nextSequenceNumber() : long
processSyncMessage(Sync Message) : void
queryBids(Bid) : Order
releaseLock() : void
resetBuffers() : void
setInformation(Book Information) : void
setSymbol(Symbol Interface) : void
An architectural element,
in this case a module
responsibilities
Create and buffer sync operations when a method is invoked
Create the auction
Delete
Get lock
Insert
Keep the state of the instrument
Manage a unique transaction sequence number
Modify
Obtain statistics
Process sync operations in order
Query
Release lock
Reset Buffers
Send alert when possible corrupted transaction sequence number
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Conformance Guidelines – To Code
Auction Manager Module Implementation
«interface»
IAuctionManager
+
+
+
+
+
+
+
+
+
Detailed design of the
implementation of this
module
This is an easy case where
the developers stayed close
to a one-to-one mapping of
the module to the
implementation
deleteBid(bidId) : boolean
getBestPrice() : Bid
getBookStatistics() : AuctionStatistics
getStatistics() : OBPStatistics
insertBid(Bid) : void
updateExpirationDate(BidId, Date) : void
updateExpirationTime(BidId, Timestamp) : void
updateMaxPrice(BidId, BigInteger) : void
updatePrice(BidId, BigInteger) : long
Statistics
AuctionManager
BStatistics
-
auctionStatistics: AuctionStatistics
maxBidId: int
statistic: BStatistics
+
+
+
+
+
+
AuctionManager(OBStatistics, List<ConfigurationValue>)
getAuctionStatistics() : AuctionStatistics
getStatistics() : OBPStatistics
getStatistics() : AuctionStatistics
insertBid(Bid) : void
updatePrice(BidId, BigInteger) : long
-
numberOfBidsProcessed: long
numberOfCancelledBids: long
Statistics
AuctionStatistics
-
«use»
«use»
«interface»
IBidValidation
Auction
-
buyView: SortedMap<BigInteger, SortedSet<Bid>>
sellView: SortedMap<BigInteger, SortedSet<Bid>>
+
Auction()
bestBid: BigInteger
totalNumberOfBids: long
+
+
+
BidValidation(BStatistics) : void
getStatisticalInformation() : Statistics
validate(Bid) : ValidationResult
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Conformance Review
A conformance review does not last longer than three hours.
The developer uses tools to provide evidence showing how the code maps to
the architecture element (module).
For all discrepancies, the developer has to provide a written reason why it is
there; the fewer the discrepancies, the less work.
In the review, it is decided how to deal with those discrepancies by changing
either the code or the architecture.
After the results of the review are implemented, the architecture drift should
be zero.
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
ACE – Implementation Cycle
Implementation
Details
ARCHITECTURE
Active Design
Review
ACE/TSP
SYSTEM
Development
PROCESS
Conformance
Review
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
Architecture-Centric Engineering
BUSINESS
AND MISSION
GOALS
ACE/TSP
ARCHITECTURE
ACE/TSP
SYSTEM
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
NO WARRANTY
THIS MATERIAL OF CARNEGIE MELLON UNIVERSITY AND ITS SOFTWARE ENGINEERING INSTITUTE
IS FURNISHED ON AN “AS-IS" BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF
ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED
TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS
OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY
WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR
COPYRIGHT INFRINGEMENT.
Use of any trademarks in this presentation is not intended in any way to infringe on the rights of the
trademark holder.
This Presentation may be reproduced in its entirety, without modification, and freely distributed in written or
electronic form without requesting formal permission. Permission is required for any other use. Requests for
permission should be directed to the Software Engineering Institute at permission@sei.cmu.edu.
This work was created in the performance of Federal Government Contract Number FA8721-05-C-0003 with
Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded
research and development center. The Government of the United States has a royalty-free governmentpurpose license to use, duplicate, or disclose the work, in whole or in part and in any manner, and to have or
permit others to do so, for government purposes pursuant to the copyright license under the clause at
252.227-7013.
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University
As projects continue to grow in scale and complexity, effective collaboration across geographical, cultural, and technical boundaries is increasingly
prevalent and essential to system success. SATURN 2012 will explore the theme of “Architecture: Catalyst for Collaboration.”
St. Petersburg, Florida May 7-11
Call for Submissions until January 7, 2013
http://www.sei.cmu.edu/saturn/2013/call-for-submissions/
ACE Development Life-cycle
Twitter #seiwebinar
© 2012 Carnegie Mellon University