ソフトウェア工学Ⅱ
Software Engineering II
Professor 大平 雅雄
Report I
Software Usability Evaluation
Student: Ahmad EL GHAFARI
ID: 1051133
Table of Contents
Title Page Number
Table of Figures 3
I. Introduction 4
II. Sonargraph-Architect 5
III. Feature Inspection (Usability Evaluation Approach) 7
III.1 Inspecting the Architecture Recovery Feature 8
III.2 Inspecting the Architecture Violation Feature 11
IV. Comparison with Rational Rose and Visual Paradigm 19
V. Limitations of my Usability Evaluation and Conclusion 20
VI. References 21
Table of Figures
Figure Number and Title Page Number
Fig. 1 The main Screen of Sonargraph 9
Fig. 2 The 'Exploration' tab screen shows the interdependencies 10
Fig. 3 The ‘Architecture’ tab in Sonargraph 11
Fig. 4 Defining two layers A and B and an allowed dependency 13
Fig. 5 Consistency warning appears at the top of the logical architecture 14
Fig. 6 Sonargraph takes the user to this view ‘1 consistency warning’ 15
Fig. 7 The ‘Exploration’ tab views the architecture violation 16
Fig. 8 The ‘Source’ tab views the violation implementation in source code file 17
Fig. 9 Brief assessment information about the subject system 18
I. Introduction
The task is to evaluate the usability of a chosen software application by the student attending the course. The evaluation method may rely on standards and rules suggested by experts and professionals in the arena. I chose Sonargraph-Architect to evaluate. The application is an Architecture Recovery and a Management tool of software systems architectures. It recovers the architecture and internal structure of other software applications. It performs Static Analysis on the source code of the subject system. It assumes Object Oriented Java code.
Sonargraph evaluates the Dependency of the subsystems and building elements of the subject system. The measurements are displayed in Sonargraph’s dashboard screen. That is it measures the cyclic Dependency and Coupling among the elements of the subject system. It applies Object Oriented Analysis and techniques suggested by masters in the area including, John Lakos, Robert Martin and Erich Gamma and colleagues.
The Architecture Management feature of Sonargraph is like a craftsman tool that facilitates defining a Logical Architecture of the subject system. This feature provides the capability for architects to model the intended logical architecture for the subject system. Sonargraph then will assess how much the source code is consistent with the defined logical architecture. As a result, Sonargraph will show if there is any violation to the defined logical architecture by the source code. For example, suppose we have a package ‘A’ and a package ‘B’. A user of Sonargraph defined in the Logical Architecture that package ‘A’ depends on package ‘B’. However, in the source code that is differently implemented, package ‘B’ depends on package ‘A’. Sonargraph will highlight a violation case and show where that violation happens in the source code by locating the file and line. The applicability of Sonargraph is crucial with systems having more than 30,000 bytecode instructions. We know for complex systems and real enterprise systems the number of bytecode instructions is counted in millions.
Sonargraph is one of the very rare tools to find which can handle such massively huge number of information. I tried many Static Analysis tools, Architecture Recovery and Management tools, but I found Sonargraph is the most usable one and the most enjoyable.
II. Sonargraph - Architect
Product: Sonargraph Architect
(c) Copyright hello2morrow GmbH 2005 – 2011
www.hello2morrow.com
Author: Alexander von Zitzewitz
Evaluation Strategy: Feature Inspection and Comparison
I am using this tool with the ‘Community Free’ license provided by hello2morrow.
Overall Impression of Using Sonargraph
I have been using Sonargraph for four months. I use it to conduct experiments for my research. Download, installation and configuration are so straight and easy. Here we must notice that such kind of tools usually needs hard work until they finally can operate on the workstation of the user. Such kind of tools need lots of time to setup and configure with many daunting settings to make. However, Sonargraph is a powerful tool and at the same time it is unique in the simplicity of setup. Sonargraph never halted or crashed. Never let me wait or show me a sand-clock mouse icon. Start learning to use Sonargraph is so smooth. Starting a new project is so straight and takes three fast steps. The guidance and manual are clear. The supporting web page is helpful. The author supports the user-experience and willing to have your impression, comment and suggestion. Sonargraph uses seven colours1 [2] and their message is consistent everywhere in its screens. Feedback messages are so short and they are at the top of the screen. Sonargraph hands a huge amount of information however it only shows what is relevant to the user and what is only needed at the moment. Once the user wants to know more details or choose to follow the subsequent information and causes of some aspect, e.g., causes of a violation case, or why some dependency is highlighted in Red not in Green, and etc. Then Sonargraph will take the user to the next detail. Terminology used by Sonargraph is consistent with what any expert expects [4].
1. Seven colours is memorisable by humans, Don Norman found out this is an acceptable number of items for the user to easily recognise and memorise.
Overview of the Main Interface
Sonargraph gives results of analysis, feedback, exploration of interdependencies and architecture definition in screens organised in format of tabs. Sonargraph main interface has nine tabs. The number is still in the acceptable range for a human being to remember.
Outlines of the Evaluation Strategy
The following section, will evaluate in more details two of the most important features of Sonargraph. I applied ‘Feature Inspection’ approach to evaluate those two features on Sonargraph. Section IV will evaluate Sonargraph by comparison with two other tools.
III. Feature Inspection
Usability Issues Covered: Effectiveness.
The method [5] suggests one may pick up a set of features of the software being evaluated. The following table list the features I am going to inspect.
ID Feature (Use Case) End Result
UC.1 Architecture Recovery A visualisation is abstracted shown to the user
UC.2 Architecture Violation Number of cases, and pointers to the places where the violation occurs
1. Inspecting the Architecture Recovery Feature
Description of the Feature of UC.1
The feature is the starting point of conducting an analysis project with Sonargraph. In literature, Architecture Recovery (performing static analysis) is the process that parses a source code of software system and abstracts the contents in higher level of abstraction. The level of abstraction varies from a method to another and thus among tools available. Sonargraph considers the high level of architecture where packages and classes with their interdependencies. Architecture Revocery process typically ends up with a visualisation of these abstracts in models and views are comprehensible by the professionals. These models can be for example UML Diagrams, or alike.
The scenario
Step User Sonargraph
1 Click ‘New System’ from ‘File’ menu Displays ‘New system’ dialogue box
2 Specify a system name and directory. Then clicks ‘Next’ button Displays ‘Workspace Import’ dialogue. In this screen user specifies the nature of the source code of the subject system whether it is Eclipse, IntelliJ, and etc.
3 Select a radio button of the choices given and click ‘Next’ Display a dialogue box to let user specifies the directory where the source code of the subject system relies
4 Select a directory and click ‘Next’ Display a dialogue box to let the user select assigns the building units of the subject source code to be used in the new project
5 Click on the building unites desired and click ‘Finish’ button Parse the source code and display the elements of the source code with the Dependency and coupling measurements, exploration of the structure, and all other information. Each set of information is in different tab.
Comment about the feature Architecture Recovery (UC.1)
As we can see making a new project in Sonargraph is done in 5 steps. The user makes only five simple actions (clicks). There are only four dialogue boxes present from the start of the use case to the end. The feature of the use case is well named and easily recognised. It consists with the global convention and its End Result is just what is expected by the user.
By the End Result of UC.1 Sonargraph will show the following screen.
Fig. 1 The main Screen of Sonargraph with focus on the ‘Dashbaord’ tab UC.1 End Result
The ‘Dashboard’ tab gives a general overview of the status of the system. The most important things that any architect and engineer needs to know. Number of bytecode instructions, number of line; Dependency health like package cyclicity; Warnings like is there any duplicate code, and etc.
The user then selects other tabs one by one to see the relative information. This is one way that Sonargraph manages information shown to the user. It does not make the user sinks in a huge amount information. Especially the user still has not meant to know about them. Let’s say now the user wants to see the abstraction visualisation of the internal interdependency of packages and subsequent elements of the source code. The user needs to click the ‘Exploration’ tab. And the following image shows the screen.
Fig. 2 The 'Exploration' tab screen shows the interdependencies among the elements of the subject system
This step does not need the user to wait. It is already there parsed and drawn from the source code and ready. As in convention The ‘Green’ colour means ‘OK’. The arcs between packages, classes and interfaces are green that means the interdependency is correct and does not violate any architectural intention.
2. Inspecting the Architecture Violation Feature
Description of the Feature of UC.2
The feature is the Analysis that does assess the conformance of the source code of the subject system to the Logical Architecture that the user intends. When the user defined a logical architecture, the user wants the source code to be the exact implementation of the defined architecture. Manual inspection is daunting. Typically, it is a process that is beyond humans’ capability. Practitioners cannot comprehend the huge architecture that source code may possess. Here is the job of Sonargraph with UC.2 to show the user weather the source code parsed is really the correct implementation of the architecture intended.
Therefore, for this feature to be performed, a logical architecture needs to be defined by the user.
How does Sonargraph facilitate defining a new logical architecture?
In the ‘Architecture’ tab (Fig.3), Sonargraph displays on the top a bar of the architecture artefacts that a user needs to define a new logical architecture.
Fig. 3 The ‘Architecture’ tab in Sonargraph before defining a logical architecture
This bar has the artefacts needed to define a logical architecture.
There are only seven artefacts. From Left to write, the first symbol defines a group of layers, the second defines a group of vertical slices, the third defines a layer, the fourth defines a vertical slice, the green shape of blocks defines a subsystem, the green arrow defines an allowed dependency and finally the red arrow specify a disallowed dependency.
A Brief Introduction of the Architectural Artefacts
Layer: to cut the application into horizontal slices (layers) by using technical critera. Typical layer names would be ‘User Interface’, ‘Service’, ‘DAO’, etc.
Vertical slice: Functional aspects should determine the vertical organisation of your application. Typical slice names would be ‘Customer’, ‘Contract’, ‘Framework’, etc.
Subsystem: A subsystem is the smallest of the architectural artefacts. It groups together all types implementing a specific mostly technical functionality. Typical subsystem names would be ‘logging’, ‘Authentication’, etc. Subsystems can be nested in layers and slices [A. Von Zitzewitz 1].
The user selects the layer symbol and type a title. Then link packages from the source code to the layer. Linking source code elements to a layer can be done in two ways. The first is a typical drag and drop technique and the second by using the context menu.
Let’s say we have two layers A, and B and we want to define a correct dependency. With the green arrow one may click on the source layer (dependent) and move (keeping the click) the mouse to the subject layer and click over the layer. Fig. 4.
Fig. 4 Defining two layers A and B. Defining an allowed dependency from A to B by a green arrow.
Comment about defining a logical architecture in Sonargraph
Defining a logical architecture is so smooth and do not need extra skills. The artefacts that are used do not confuse the user.
Now, we can talk about the Architecture Violation in Sonargraph.
After defining a logical architecture and assign source code units to the architecture, Sonargraph instantly highlights any occurrence of violation when the implementation parsed from source code is not consistent with the architecture definition. For example, suppose there are two layers Logging and Data. The user defined a dependency from Logging layer to Data layer using the green arrow. See Fig. 5.
The user assigned the package com.cots.logging to Logging layer and assigned com.data.data package to Data layer.
However, in the source code Sonargraph finds out that com.data.data depends on com.cots.logging.
Fig. 5 Consistency warning appears at the top of the logical architecture definition. After defining an allowed dependency from Data layer on Logging layer; Sonargraphs finds out that the implementation in the source code violates the intention.
The user can click on ‘1 consistency warning’ and Sonargraph will take the user to view more details about this violations. Sonargraph will display the ‘Architecture Consistency’ tab under the ‘Summary’ tab; Fig. 6.
Fig. 6 Sonargraph takes the user to this view ‘1 consistency warning’ of the previous view was clicked. In the bottom section of the tab ‘Architecture Consistency’, one can see the Description feedback telling the user why this happens to be an architecture violation.
And for the user to know more about this violation, the Exploration tab view, as shown in Fig. 7, will show more details.
Fig. 7 The ‘Exploration’ tab views the red arrow between Logging layer and Data layer. The red arrow ends link the exact implementation units that cause the violation.
And finally, for the user to know how this violation happens and what the piece of code this is implemented, the user may click on the red arrow that appears in Fig. 7. Sonargraph will show the place of the violation in the source code by file and number of line, as shown in Fig. 8.
Fig. 8 The ‘Source’ tab view where Sonargraph opens the file where the violation is implemented and alos pointing to the line number of the code file.
Also, there is a description of each violation case at the bottom of the tab as usual.
There are more feedback are given in the bottom section of the ‘Source’ tab. Description of how the violation happens and why the code is not consistent with the defined logical architecture.
In general, the dashboard will always show the final status (assessment) of the architecture of the subject system including the architecture violation number of occurrence s and their types. Once the user wants more details, the user may click on the number appears in front of ‘Architecture violations:’ in the tab view. This is found in the ‘Architecture’ section of the view. Fig. 9.
Fig. 9 Brief assessment information about the subject system; The most important things to know and the entry point for each kind of assessment. The text written in blue is linked to the subsequent information and related details.
Comment about the feature Architecture Violation (UC.2)
The user does not need to go throw a daunting scenario to discover the architecture violation occurrences. Rather, Sonargraph has been evaluated the implementation of the source code and compares the structure and dependency and interconnections among the building units of the systems, including, packages classes, interfaces, etc. The analysis was made just with the first feature (UC.1 Architecture Recovery). Once the user defined the logical architecture intended, Sonargraph highlights instantly a warning for any event of violation. These warning are consistent everywhere in each tab, and visualised in a way that copes with the context and job of each tab.
IV. Comparison with Rational Rose and Visual Paradigm
I have used many Architecture Recovery tools, CASE tools, and Static Analysers. Some of these tools take lots of physical memory and they halt. They take noticeable amount of time to parse the source code of the subject system to abstract the architecture, for example, Visual Paradigm.
CASE Tools are powerful; they allow defining logical architectures. However they are so rigid and linking to the source code is almost artificial. I have used Rational Rose 2002 during my work at software industry.
With CASE tools there is no two-way path where each modification to the source code will be instantly reflected in the working project. However, Sonargraph can parse the source code and update the analysis instantly and by on key button: ‘F5’. That is if the user modified the source code, Sonargraph is capable and on the fly to notice any change. By comparison, I can give the effectiveness of Sonargraph to be the top. One more thing, Sonargraph deals with many levels of hierarchy of building units and naturally with their dependencies.
V. Limitations of my Usability Evaluation and Conclusion
I do not claim that this survey is enough to give an objective evaluation of Sonargraph Usability, because it lacks to have a pilot or systematic survey. For example, it would be much better to ask 10 users (who are experts) to use Sonargraph and to fill the questionnaire like the one provided by QUIS [4].
Although my evaluation is still subjective but I used “Feature Inspection” [5] approach which I found it can give reliable results with only taking the analysis of an expert who uses the subject system, and one expert is enough.
In conclusion, Sonargraph is very powerful, accurate, and effective. Sonargraph satisfies the user (the architect) needs and expectation. It takes little time to start using it and also little time and effort to master it. It is unique among other tools I have used.
VI. References
[1] The lectures handouts of Software Engineering II course provided by the professor.
[2] Don Norman, Don Norman and The Design of Everyday things, http://katsvision.com/canm606/session_3/03_norman_01.pdf
[3] A. von Zitzewitz 1 Reference Card Software Architecture Management, white paper provided in the web site of Sonargraph Architect, www.hello2morrow.com
[4] QUIS, http://lap.umd.edu/quis/
[5] http://www.usabilityhome.com/FramedLi.htm?FeatureI.htm
