Software Engineering Institute | Carnegie Mellon University

SEI Insights


SEI Architecture Technology User Network (SATURN) News and Updates

SATURN 2013 Modeling and Documentation Session (notes)

Posted on by in

Notes by Brendan Foote

How to Build, Implement, and Use an Architecture Metamodel

Chris Armstrong, Armstrong Process Group, Inc.
Armstrong discussed the architecture-description standard UML model, showing how an architecture description expresses an architecture, fulfills the concerns of stakeholders, and more. He uses the difference between raw accounting data and the common views the way, say, a CFO would need to because of the way that an architecture is standardized by the RFC 42010 (that is, what subset of the entire UML model is particularly useful?).

This leads to his refined viewpoint metamodel. His process group has added the "architecture scenario" to the metamodel, which he points out is not in conflict with the standard. This scenario is defined by a stakeholder, and it contextualizes an architectural concern. He goes on to show how stakeholders and concerns are also connected by architecture viewpoints, of which there are several types. Those types are defined differently depending on whether you talk to TOGAF, DoDAF, etc., but a modeling system should allow you to render your viewpoints in different ways for different consumers (e.g., a grid, diagram, catalog, or dashboard).

They then created a workflow for gathering modeling requirements. There are three roles in this workflow: an architecture framework manager, an architecture viewpoint librarian, and an architecture framework designer. These roles work together to see if there is already an existing viewpoint for the task at hand. If not, then the designer needs to help create a new viewpoint, which can be added to the library for future reuse. Armstrong then went through an example modeling framework that he made. He has a UML profile for depicting stakeholders and scenarios. The same three roles from the workflow make appearances here as stereotyped actors. He defines the way that the relationship between each actor and scenario has been stereotyped, which makes more sense in this context.

Off of each scenario (the "why" for each of those actors in this metamodeling), he hangs off the architectural concerns. For example, "which applications are impacted by this project?" At this point, it is possible to link those concerns to the viewpoints that render them. This provides easy visualization and traceability to ensure the concerns have coverage by the viewpoints. It also allows each viewpoint to be customized through its attributes to meet the needs of the specific concerns it covers. Armstrong reflected on creating this example metamodel. The exercise helped him remove elements that he thought he wanted to track but concluded that they were non-essential and therefore cluttering the metamodel.

Quickly looking at an example of applying the metamodel he created, he showed two different projects (one for event management, another for portal technology implementation), using this metamodel and color coding of the links between the projects and the applications involved to make the diagram more readable. In conclusion, Armstrong said that architects need to exploit existing architecture standards to determine how to model for what purpose, and we should use conventional modeling techniques for understanding. In the Q&A, there was a question about when is it really necessary to define a new viewpoint. He says the thing that really matters is figuring out how to best meet the key stakeholder concerns across models. This might take time to work out over different trial applications of the model, but you will come out at the end with a standard set of viewpoints that everyone is familiar with and agrees on. Modeling the Contributions of Software Architecture to the Success of an Ecosystem John McGregor and Yates Monteith, Clemson University Simone Amorim and Eduardo Almeida, University Federal of Bahia McGregor proffers that companies exist within an ecosystem, which he defines as containing predators and prey, but where the predatory hierarchy comes from who know things that others do not know and uses that information to become a more successful business. The definition of a successful ecosystem varies by the type of company: for a platform, the primary concern is attracting developers, for example.

To study this, McGregor created the STRategic Ecosystem Analysis Method (STREAM), which links three business views. More important is that software architecture can affect all three of them. The first view is the business view, showing how a business space has potential entrants, substitutes, suppliers, and consumers. The innovation view looks at how companies come up with new ideas, which are often the largest source of profit for a company. The software view looks at flexibility, scalability, and extensibility of software used by a company. He tied this back to the morning's keynote address by Stephan Murer, who mentioned how CORBA wasn't mature enough when they first adopted it. Dependency analysis is used for identifying critical points in the implementation and the relationships that link them.

Consider the amount of software in a modern BMW: decision makers can't examine 11,000 files, but using betweenness centrality (the number of shortest paths between two points on the graph), they can understand the connections. The modeling method that McGregor uses is largely cribbed from the RUP people, to whom he gives credit. It has five practices, four phases (exploration, construction, exploitation, and evolution), and three views. Each phase has distinct actions: exploration involves gathering the relevant questions, construction involves gathering the data necessary to work on the decision, and so forth. STREAM provides a structured representation for the information describing the ecosystem, a set of views that makes implicit information explicit for the decision maker (and two other bullet points we had to buzz through due to time constraints). An ecosystem's health can be measured with robustness, niche creation, and productivity. For example, Hadoop lives in the ecosystem of high-performance computing environments. The ecosystem is robust in that fault-tolerant HPC architecture is gaining widespread acceptance.

An Architecturally Evident Coding Style

George Fairbanks, Google
Design intent is lost between design and code. Some things can be inferred from the code, but the questions are what we can do to help with that and what are the limits of that. Proof that it is hard to infer intent from implementation is how the United States doesn't want certain countries getting better ICBMs, and yet there are missiles on display for anyone to come and see. For expressing design intent, it is necessary to go back to Kent Beck's book, Smalltalk: Best Practice Patterns. Beck writes, What's going on? Communication. ... Intention Revealing Messages are the most extreme case of writing for readers instead of the computer. As far as the computer is concerned, both versions are fine. The one that separates intention (what you want done) from implementation (how you want it done) communicates better to a person. (p. 49) Beck's example is how to invert the colors in a callback. The obvious solution is to simply do the switching in the callback. But better would be to create a function called "highlight," which is called by the callback. Of course, the highlight function does the color switching, but now we know why this is happening. The main point is that he's written more code than is strictly necessary, but it will be of great benefit to the reader. This hinting comes up all the time, to some extent. Instead of naming all variables with a single letter (which at one point was necessary for space reasons), we give them descriptive names. Eric Evans has the strongest take on this in his book Domain-Driven Design. But can we get information about the architecture in there as well? What would we like to know about when reading code?

  • Who talks to whom
  • Invariants and constraints
  • etc.

But not all architectural intent can be placed in the code. Extensional things (defined by enumerated instances) can easily be seen in the code: if you have a client and a server, there will be corresponding classes in the code. But intentional things are difficult to show (e.g., always acquire locks in this order). Fairbanks has created a pattern catalog for this:

  • Module dependencies
  • Package structure
    • Don't just put everything under "src."
    • Align modules (source code at compile time) with components (instances at run time).
  • Module → runtime (How many instances of this class will there be at runtime?)
    • Centralized startup code
    • If you are going to create only one instance of one class, two copies of another, and wire them together, do this up front and all together.
    • Another way to tackle this is by pulling out configuration into a configuration file (à la Spring, Struts, etc.), where it can be easily read.
  • Visible components
    • Create an abstract class called "Component" and have classes implement them. That way, you can use an IDE to search the code for the classes that implement "Component" to see the intended boundaries.
  • Visible connectors
    • Similar to the technique for visible components, but create an abstract class called "Connector"
  • Properties, styles, and patterns
    • Express properties with names.
    • Express properties with annotations.
    • Express styles/patterns with names.

About the Author

Bill Pollak

Contact Bill Pollak
Visit the SEI Digital Library for other publications by Bill
View other blog posts by Bill Pollak



We welcome comments with a wide range of opinions and views. To keep the conversation focused on topic, we reserve the right to moderate comments.

Add a Comment


Type the characters you see in the picture above.