1. Analyzing UML Descriptions of Architectures Using Information Theory
Lionel Briand
Systems and Computer Engineering

2. Goals From proposal: Assess In the architecture(s) being analyzed
Error propagation
Change propagation
Requirement propagation
In the architecture(s) being analyzed
Draw conclusions regarding the relative impact of one or several architectures on product external quality attributes

3. Working Assumptions
A full OO development process is followed, I.e., Analysis, Architectural Design, etc.
Analysis and Design only use standard UML representations, though their use may be tailored to our purposes
Information theory is the main underlying theory to be used to develop analysis instruments
We are mostly interested by what can be done at the end of the architectural design

4. UML Development - Overview
ACTORS
USE CASES
REQUIREMENTS
ELICITATION
Time
SCENARIOS D
SEQUENCE
DIAGRAMS A T A
ANALYSIS
ANALYSIS
CLASS DIAGRAM(S)
CLASS STATE DIAGRAMs D I
OPERATION CONTRACTS C T I
System
Design
SUBSYSTEM
DECOMPOSITION
&
INTERFACES
DESIGN COLLABORATION DIAGRAMS
DEPLOYMENT DIAGRAM O N
DESIGN CLASS DIAGRAMS A
DESIGN R Y
Object
Design
IMPLEMENTATION
CHOICES
IMPLEMENTATION
CLASS DIAGRAM
IMPLEMENTATION
PROGRAM

5. Information Available at Architectural Design
Use cases, Use case Diagram
Analysis and Arc. Design class diagrams
Analysis and Arc. Design Sequence/Collaboration diagrams
Statecharts for multi-modal classes
Subsystems + their public interface (API)
Subsystem dependencies
Mapping subsystems’ instances to Hardware (Deployment)
Data management, Security control

6. MyTrip Analysis Class Diagram
Location
Segment
Crossing
Direction
Destination
Trip
RouteAssistant
PlanningService
We can imagine that in reality there would be more details in the class diagram but it is not relevant here
PlanningService is an boundary class interfacing with another external system, a web server, that can supply a trip linking a number of destinations in the form of a sequence of crossings and segments

7. MyTrip Subsystems Location Segment Crossing Direction Destination
RoutingSubsystem
PlanningSubsystem
Trip
RouteAssistant
PlanningService
Only one association crossing subsystem boundaries
The Trip object group is shared and used for communicating information from one subsystem to another. We can either create a new subsystem to accommodate them or assign them to the subsystem that creates these objects (we retained the latter solution above).

8. Subsystem Interface
The set of public operations forms the subsystem interface or Application Programming Interface (API)
Includes operations but also their parameters, types, and return values
Operation contracts are also defined (pre- and post-conditions) and accounted for by client subsystems – they can be considered part of the API

9. MyTrip Deployment Diagram
:RoutingSubsystem
:PlanningSubsystem
:OnBoardComputer
:WebServer
We select here, for the myTrip system, a hardware configuration and a platform
RoutingSubsystem runs on the OnBoardComputer while PlanningSubsystem runs on a WebServer.
Let’s assume we select a UNIX machine as the virtual machine for the :webserver and the web browsers Netscape and Internet Explorer as the virtual machines for the :OnBoardComputer

10. New Classes and Subsystems
Trip
Location
PlanningService
Segment
Crossing
RouteAssistant
Direction
Destination
TripProxy
SegmentProxy
PlanningSubsystem
Message
Connection
CommunicationSubsystem
RoutingSubsystem
The assignment of objects and subsystems to nodes often triggers the identification of new objects and subsystems, e.g., for transporting data among nodes
In the myTRIP system, subsystems need to communicate via a wireless modem using some communication protocol
New subsystem to support communication: CommunicationSubsystem – responsible for transporting objects from the PlanningSubsystem to the RoutingSubsystem
Connection: A Connection represents an active link between the PlanningSubsystem and the RoutingSubsystem. A Connection object handles exceptional cases associated with loss of network services
Message: A Message represents a Trip and its related Destinations, Segments, Crossings, and Directions, encoded for transport.

11. MyTrip Data Storage RoutingSubsystem PlanningSubsystem
MapDBStoreSubsystem
TripFileStoreSubsystem
RoutingSubsystem
CommunicationSubsystem
Subsystem decomposition of MyTrip after deciding on the issue of data stores (UML class diagram, packages collapsed for clarity).
Current trip is saved on a small removable disk in order to allow the recovery of the Trip in case the driver shuts off the car before reaching the final Destination. Using a file is the simplest and most efficient solution in this case, given that the RoutingSubsystem will only store complete trips to the file before shutdown and load the file at start-up. In the PlanningSubsystem all trips will be stored in a Database. All trips will be managed by this subsystem, for many drivers, as well as the maps needed to generate trips. It will allow us to perform complex queries using, for example, a Relational Database Management system and a language like SQL.

12. Static versus Dynamic Architecture Information
Subsystem Interfaces and dependencies provide static information
Interaction models provide dynamic information
Relationship between static and dynamic information and quantitative factors?
Change propagation (dependencies)
Requirements propagation (dependencies)
Error propagation (at run time)

13. Impact on Change and Requirements Propagation
Assuming a subsystem SSi undergoes change (correction or requirement)
Possible Relevant Information:
Does the change affect the interface of SSi?
How many other subsystems depend on SSi?
How much coupling (static) is there between SSi and the other subsystems?
What is the size and complexity of the *used* interface between SSi and the other subsystems?

14. Impact on Error Propagation
Assuming a subsystem SSi contains a fault, how likely is it to cause an incorrect execution in another, client subsystem? (propagate the error)
Relevant Information:
Message frequency between subsystems
Indirectly dependent on system operational profile
An error in a rarely invoked subsystem/class is not likely to propagate
A fault in in a operation where the ratio OutputRange / InputRange is small has low testability but errors are also less likely to propagate

15. Role of Information Theory
Quantify amount of information transmitted between two subsystems
Between subsystems at run time (dynamic information)
Between the people/teams designing the subsystems (static information)
Characterize the distribution of information flow among subsystems, I.e., the topology of relationships among subsystems

16. Information Theory Main Concepts
Channel
Noise
Equivocation
Information transmitted
Information loss
How do they match to our problems? Can they serve any purpose in our context?

17. Subsystem Usage Receiver (B) SS1 SS2 SS3 SS4 SS5 Sender (A) SS1 SS2
Services of SS2 used by SS1
SS1
SS2
SS3
SS4
SS5
Transition matrix
Among sybsystems in a system, or a higher level subsystem

18. Subsystem Usage: Cell Information
nab = 0 / 1, a does (not) depends on b
nab = # operations used in b by a
pab =probability for a of using any operation in b
The first to capture static information whether the third one is more complex to measure as it captures dynamic information and assume an operational profile

19. Operation Usage Receiver (B) Op1 Op2 Op3 Op4 Op5 Sender (A) Op1 Op2
One operation uses the other
Op1
Op2
Op3
Op4
Op5
e.g., Between two subsystems. Channel = dependency between subsystems.

20. Operation Usage: Cell Information
nab = 0 / 1, a does (not) use b
nab = weighted by information flow
pab =probability for a of using operation b

21. Example
(3)
(1)
(2)

22. Example II Subsystem usage case, nab = 0 / 1 Total Entropy: H(AB)
H1(AB) = log2 5
H2(AB) = log2 5
H3(AB) = log2 9
Noise: H(AB) – H(A)
H1A(B) = 4/5 = 0.8
H2A(B) = 3/5 log2 3 = 0.94
H3A(B) = log2 3 = 1.58

23. Example III Equivocation: H(AB) – H(B)
H1B(A) = 3/5 = log2 3 = 0.98
H2B(A) = 4/5 = 0.8
H3B(A) = log2 3 = 1.58
Information Transmitted: H(A) – HB(A)
T1 (A:B) = 0.57
T2 (A:B) = 0.57
T3 (A:B) = 0
Note: to compare architectures, probably need to normalize by log2 |A|* |B|

24. Interpretation
(1) High total entropy -> High (static) level of dependency between subsystems / operations
(2) High equivocation -> on average, subsystems/operations accommodate many uses / usages from different subsystems / operations
(3) High noise -> on average, subsystems / operations use many other subsystems / operations
(1) Has impact on communications between teams / developers
(2) and (3) provide additional insight explaining the source of entropy

25. Open Questions How to quantify and characterize usage?
Static information only (# services used),
Information flow weight (parameters, return value)
Frequency of invocation
Communication mode: asynchronous/synchronous
Distribution: remote/local invocation

26. Plan
Differences between information theory concepts and simple count measures
Characterize more formally how IT concepts react to changes in architectures (properties)
Explore different ways of characterizing usage
Relationship between information theory (IT) concepts and architecture styles