DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

How does AI transform chaos engineering from an experiment into a critical capability? Learn how to effectively operationalize the chaos.

Data quality isn't just a technical issue: It impacts an organization's compliance, operational efficiency, and customer satisfaction.

Are you a front-end or full-stack developer frustrated by front-end distractions? Learn to move forward with tooling and clear boundaries.

Developer Experience: Demand to support engineering teams has risen, and there is a shift from traditional DevOps to workflow improvements.

Related

  • Software Specs 2.0: An Elaborate Example
  • Exploring Intercooler.js: Simplify AJAX With HTML Attributes
  • Why Documentation Matters More Than You Think
  • Attribute-Level Governance Using Apache Iceberg Tables

Trending

  • Supercharge Your Java Apps With AI: A Practical Tutorial
  • OTel Me Why: The Case for OpenTelemetry Beyond the Shine
  • Kung Fu Code: Master Shifu Teaches Strategy Pattern to Po – The Functional Way
  • Operationalizing Data Quality in Cloud ETL Workflows: Automated Validation and Anomaly Detection
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. What the Heck is a Utility Tree?

What the Heck is a Utility Tree?

By 
Arnon Rotem-gal-oz user avatar
Arnon Rotem-gal-oz
·
May. 09, 12 · Interview
Likes (0)
Comment
Save
Tweet
Share
18.7K Views

Join the DZone community and get the full member experience.

Join For Free

i recently answered this question in stackoverflow :

what is an utility tree and what is it’s purpose in case of architecture tradeoff analysis method(atam)?


i did answer the question there but here’s a better explanation with lots of examples based on the initial version for chapter 1 of soa patterns (which didn’t make it into the final version of the book).

there are two types of requirements for  software projects: functional and non-functional requirements. functional requirements are the requirements for what the solution must do (which  are usually expressed as use cases or stories). the functional requirements are what the users (or systems) that interact with the system do with the system (fill in an order, update customer details, authorize a loan etc.).

non-functional requirements are attributes the system is expected to have or manifest. these usually include requirements in areas such as performance, security, availability etc. a better name for non-functional requirements is “quality attributes” . below are some formal definitions from ieee standad 1061 “standard for a software quality metrics methodology”  for quality attributes and related terms:

  • quality attribute a characteristic of software, or a generic term applying to quality factors, quality subfactors, or metric values.
  • quality factor a management-oriented attribute of software that contributes to its quality.
  • quality subfactor a decomposition of a quality factor or quality subfactor to its technical components.
  • metric value a metric output or an element that is from the range of a metric.
  • software quality metric a function whose inputs are software data and whose output is a single numerical value that can beinterpreted as the degree to which software possesses a given attribute that affects its quality.


most of the requirements that drive the design of a software architecture comes from system’s quality attributes. the reason for this is that that the effect of quality attributes is usually system-wide (e.g. you wouldn’t want your system to have good performance only in the ui – you want the system to perform well no matter what) –  which is exactly what software architecture is concerned with. note however, that few requirements might still come from functional requirements) [1] .  the question is how do we find out what those requirements are?

the answer to that is also in the software architecture definition. the source for quality attributes are the stakeholders. so what or who are these “stakeholders”? well, a stakeholder is just about anyone who has a vested interest in the project. a typical system has a lot of stakeholders starting from the (obvious) customer, the end-users (those people in the customer organization/dept that will actually use the software) and going to the operations personnel (it – those who will have to keep the solution running), the development team, testers, maintainers, management. in some systems the stakeholders can even be the shareholders or even the general public (imagine for example, that you build a new dispatch system for a 911 center).

one of the architect’s roles is to analyze the quality attributes and define an architecture that will enable delivering all the functional requirements while supporting the quality attributes. as can be expected ,sometimes quality attributes  are in conflict with each other – the most obvious examples are performance vs. security or flexibility vs. simplicity and the architect’s role is to strike a balance between the different quality attributes (and the stakeholders) to make sure the overall quality of the system is maximized.

contextual solutions (e.g. patterns) can be devised to solve specific quality attributes need. however saying that a system needs to have “good performance” or that it needs to be “testable” doesn’t really help us know what to do. in order for us to be able to discern which patterns apply to specific quality attribute ,  we need a better understanding of quality attributes besides the formal definition, something that is more concrete.

the way to get that concrete understanding of the effect of quality attributes is to use scenarios. scenarios are short, “user story”-like proses that demonstrate how a quality attribute is manifested in the system using a functional situation

quality attributes scenarios originated as a way to evaluate software architecture. the software engineering institute developed several evaluation methodologies, like architecture tradeoff analysis method  (clements, kazman and klein, 2002) that heavily build on scenarios to contrast and compare how the different quality attributes are met by candidate architectures. atam (and similar evaluation methods like laaam which is part of msf 4.0) suggest building a “utility tree” which represent the overall usefulness of the system. the scenarios serve as the leafs of the utility tree and the architecture is evaluated by considering how the architecture makes the scenarios possible.

i found that using scenarios and the utility tree approach early in the design of the architecture (see writings about saf ) can greatly enhance the quality of the architecture that is produced. when you examine  the scenarios you can also  prioritize them and better balance conflicting attributes.

the scenarios can be used as an input to make sure the quality attributes are actually met.  furthermore  you can use the scenarios to help identify the strategies or patterns  applicable to make the scenarios possible (and thus ensure the quality attributes are met) within the  system. we usually group scenarios into a “utility tree” which is a representation of the total usefulness (“utility”) of a system . as you can see in the diagram below we have the   key quality attributes (performance, security etc.). each of the quality attributes has sub categories (e.g. performance is broken into latency, data loss etc.). each sub category is demonstrated by a scenario that we expect the system to manifest.

the tree representation helps get the whole picture but the important bits here are the scenarios so let’s explore them some more. scenarios are expressed as statements that have  3 parts: a stimulus , a context and a response . the  stimulus is the action taken (by the system / user/ other system / any other person); response is how the system is expected to behave when the stimulus occur, and the context specifies  the environment or conditions under which we expect the to get the response. for example in the following scenario: “when you perform a database operation , under normal condition, it should take less than 100 miliseconds.”

  • “under normal condition” is the context
  • “when you perform a database operation” is the stimulus
  • “it should take less than 100 millisecond” is the response expected from the system.

here are a couple of  additional examples for quality attribute scenarios:

  • performance –>latency -> under normal conditions a client consuming multiple services should have latency less than 5 seconds.
  • security->authentications -> under all conditions, any call to a service should be authenticated using x.509 certificate

you can also check out this document for a few more scenario examples from a system i worked on in the past


[1] design has the ratios reversed  i.e. most of the requirements for design come from functional requirements and a few requirements might come from the quality attributes.

illustration by epsos.de

Attribute (computing) Software architecture Tree (data structure) Requirement

Published at DZone with permission of Arnon Rotem-gal-oz, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Software Specs 2.0: An Elaborate Example
  • Exploring Intercooler.js: Simplify AJAX With HTML Attributes
  • Why Documentation Matters More Than You Think
  • Attribute-Level Governance Using Apache Iceberg Tables

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • [email protected]

Let's be friends: